New Products Flash Sale
Jack Crossfire's blog
Posted by Jack Crossfire | Sep 16, 2008 @ 02:48 AM | 3,355 Views
HP's (latest) 25,000 mass layoff should get the message across. Jobs which don't have to be done near corporate headquarters can be done in Bangalore, and corporate headquarters are always in Calif*.. We predicted EDS in Dallas would be eliminated & it was. Well, half of them can still move to Bangalore.

Had a successful radio test. 8 hours without a failure.

Time to tabulate the radio settings that work & the radio settings that don't.

Good radio settings:
---------------------------------------
Ground:
115200 bps
40ms beacon interval


Copter:
57600 bps
3.3V - 5V comparator



Failed radio settings:
---------------------------------------
Ground:
115200 bps
21ms beacon interval

Copter:
115200 bps
3.3 - 5V comparator
Copter UART failed.
---------------------------------------
Ground:
57600 bps
40ms beacon interval
Ground XBee failed.

Copter:
57600 bps
3.3 - 5V comparator

Well, 57600 is a draconian reduction in bandwidth but it seems to be required to keep the PIC UART from locking up. The ground station seems to handle 115200. The 3.3V - 5V comparator did nothing. What a disappointment.

The XBee lockup has moved from the UART into the transceiver. Now feels like too many collisions at just the right time may lock it up. Maybe it was designed to wait for ACKs after broadcasting instead of having packets pushed into it.

Even though no-one uses all that mesh networking, their investors keep forcing it on us...Continue Reading
Posted by Jack Crossfire | Sep 15, 2008 @ 01:19 AM | 3,498 Views
So we're down to only testing radio, probably until October. Got a few crashes with the PIC receive even though it was supposed to be resetting the registers. Got a few crashes with the ground station XBee even though it was spacing apart the activity. Looks like reset & permanent configuration are going to be required. Never had this problem with the airborne Xbee.

It seems a number of circumstances may cause an XBee lockup, like using a high powered RF source nearby, using a microwave oven nearby, using the module for many hours, a stray packet coming out simultaneously with a sent packet. The reset pin seems to be the only solution & that means hard flashing the XBees with configuration, not fun.
Posted by Jack Crossfire | Sep 13, 2008 @ 07:06 PM | 3,338 Views
Leave the radio test on overnight & you're going to have a bad day. Looks like the XBees lock up on simultaneous full duplex UART again. All U can do to guarantee the XBees aren't doing 2 things simultaneously is cut out half the ground beacons & half the bandwidth (radio bailout mode).

Digi/Maxstream/??? has a note on full duplex operation.

http://www.digi.com/support/kbase/kb...tl.jsp?id=2037

Which basically means nothing for our problem. You're stuck running drastically below the capability of the $64 because of a firmware bug.

Narrowed down the PIC to suddenly not receiving UART interrupts. Only a corrupt register could cause that. Don't have the budget for a debugger & there's nothing which could corrupt a register.

Looks like the rule is just don't run analog over 120Hz but forget about knowing why. It could also be heating or power supply glitches.

Surprised that the chance of random noise passing a CRC check over many hours is quite high. The chances go up as the packets get smaller.

RADIO=fdf1 522d 0ef2 fcf6 SWITCHES=0000
RADIO=78eb 5d7d 30ec ddf5 SWITCHES=0000
RADIO=f3b4 ff7a 7efe 76df SWITCHES=0000
Posted by Jack Crossfire | Sep 11, 2008 @ 03:28 AM | 3,467 Views
Ground based autopilot has already exceeded the cost of a 400Mhz Gumstix because of mistakes, it's much more complicated, & it has endless bugs. The only good news is none of the extra expenses have actually been used.

A bit of oscilloscoping revealed that a packet timeout of 1 was causing the XBee to split packets. Setting it back to 3 caused the XBee to align packets as intended & the data rate suddenly surged to 100% error free. Still could not increase the frequency of ground beacons.

The oscilloscope also showed the downlink came roughly 1 beacon behind the ground beacons & overlapped ground beacons. Overlapping TX & RX was not crashing the XBee. No idea what crashes the XBee. It's related to fragmented packets, asynchronous I/O, & Uba Acka Bama Racka.

With the IMU packets up to 125Hz & the downlink grinding at 30000 bits/sec, we have a crash somewhere in the aircraft. The XBee still works. The PIC is still alive. Resetting the PIC recovers the downlink.

Also lost all of the 72Mhz feed once.

Next, we have swashplate training & a tiny magnet for solving the washout woes in swashplate training. This aspect is much easier since U can reconfigure the computer without disturbing the machine vision setup.
Posted by Jack Crossfire | Sep 10, 2008 @ 02:12 PM | 3,150 Views
So the LHS had $20 receivers but our attempt at finishing off 72Mhz problems ended in fried diode. That's how to get nothing for the price of a short range XBee. Goog says the diode can be replaced easily, but we're out of time in this commute.

For the cost of those GWS receivers, U can get a short range XBee, use it as a receiever only, & get the same range as an XBee-Pro in a fraction of the space of 72Mhz gear.

After the radio IMU test, no-one doubts it can fly itself. The issue is it's dropping more packets than it should. Once the USB dongles are replaced, we'll have spent more on ground based autopilot than the cost of a 3rd Gumstix.

PICs send a lot of bad bits at 115200 baud, but it turns out full duplex falls over below 115200. Because the XBee UARTs can't send & receive simultaneously, they need more time between beacons to transfer downlink packets.

There are strange interactions between CCPM, UART, timer2, timer3 modules on the PIC. U really only have timer0 & timer1 for user space.

The IMU is sampled at 1680Hz & lowpass filtered. The bandwidth is 1/256. Every 16th sample is sent to the ground for a 105Hz downlink rate.

The downlink rate is currently limited by PIC memory. It can probably do 120Hz. One idea is to send 120Hz & intentionally drop packets on the ground station until the dropped packet rate is always the same regardless of the downlink quality. The issue is timing. You're just filling gaps by copying packets from the wrong time slot.
Posted by Jack Crossfire | Sep 09, 2008 @ 02:48 PM | 3,568 Views
Good news: we're a lot better off than most people who R tied to their ground station.

Bad news: In the latest test, 72Mhz only reached 140ft. Fortunately, the 72Mhz part is the cheapest.

Finished the first full inertial navigation test by 600ft radio link. Amazingly, with all the dropped packets, the gyros didn't drift as much as feared. The dropped gyro contributions are just too small compared to all the other factors to make a huge difference.

Interpolating the gyro amounts to fill in dropped packets degraded the result. There's definitely more drift at 600ft.
Posted by Jack Crossfire | Sep 06, 2008 @ 08:12 PM | 3,232 Views
No-one ever ran an XBee in 2 threads before, we doubted it would work, & it didn't work after all. The XBee UART appears to freeze if U send data while it's sending. Running the XBee in 1 thread & so far it hasn't frozen anymore. Unfortunately U have no way of knowing if the XBee is about to send a stray packet just before U send something.

Like we said, humans R fascinated by sending more data farther. Did try the Airtronics receiver again with the HiTec transmitter & it was horrible. It only got 2000 bits/sec & was pretty unreliable. Maybe it has to be matched with the Airtronics transmitter or maybe the 80's weren't the Jesus decade.

Next, U may be able to get 8000 bits/sec over 72Mhz but it does reduce the range. Knew it in 2006 & rediscovered it again. Fortunately with the modulation routines all using hardware, the bitrate with the 2006 settings is up to 4700.

So today we learned those fixer uppers Northwest North Idaho really were worth $1 million & those ocean front condos in Phoenix really were ocean front condos. Can't wait for the Social Security Mae bailout, & the Barrack Mac bailout.

The funk has changed names again. Now he's Uba 'Ack. Uba 'ack, the ultimate savings & loanama with a free porshama for every cat. Pretty soon he'll figure out how to get it to 1 syllable 4 U lions.
Posted by Jack Crossfire | Sep 05, 2008 @ 01:28 PM | 3,170 Views
On the test range, managed to get receiver lockups every 5 minutes on the ground station XBee. Nailed it down to precisely the receive direction on the ground. Have only a half duplex test, running it in API mode, reducing the frequency of transmits left.

So currently we're using 2 serial ports on the ground station for the 72Mhz & 2.4Ghz channels. Could use 1 serial port & multiplex the 2 channels. That would eliminate a thread & $12 for a serial port.

It would require rebuilding the ground station board yet again & adding another chunk of assembly language for buffering. The PIC goes from $5 to $12. Weight & miniaturization isn't an issue on the ground. Heroine 2200 uses 2 serial ports & we never notice it. Mainly, serial ports are platform independant.

In other news, both our XCite Batteries puffed. They puff in temperatures over 90F & harden in lower temperatures. Thinking of keeping them around for winter use only....Continue Reading
Posted by Jack Crossfire | Sep 04, 2008 @ 01:16 PM | 2,484 Views
Got capture compare to work on the PIC18F1320. The capture modules on PICs are Schmitt triggers. They turn on at 4V & turn off at 1V, so 3.3V sources won't work even though reading the pin directly gives U proper values.

Hardware capture compare makes a mean software UART when used for capturing GPS as we have. Don't forget to amplify your 3.3V uBlox signal with more MOSFET magic.

So the answer is yes. U need to use interrupts in microcontrollers. Interrupts R always faster than polling, even with the context switches. Interrupts are very accurate, always happening exactly the same time after the event instead of whenever the loop happened to run the test.

To reduce the chance of radio dropouts glitching the INS, we take as many analog readings as humanly possible & rebroadcast every 3rd reading twice. Also rebroadcast every GPS reading twice.

The XBee crashes continue. The best hope is that it's a firmware crash in the ground XBee & giving it a reset every 30 minutes will fix the problem.
Posted by Jack Crossfire | Sep 03, 2008 @ 01:13 PM | 2,699 Views
Well, the replacement XBee's arrived & they didn't work.

Turns out the problem wasn't a 5V frying but a software bug. The flight computer was reprogrammed to only send to its radio when it receieved a packet from the ground, but that also meant it couldn't send any commands to initialize its own radio until it received a packet from the ground on the same radio. It worked on the bench because it was never unplugged, but once unplugged, it lost its configuration & could never reinitialize.

$100 gone & no more 900Mhz money. Enough spare XBee's to build 2 more UAV's & conquer Idaho. Stay away from 5V.

Have found with the XBee's the full duplex latency depends on the amount of time it takes to switch between reception mode and transmission mode. It doesn't seem to depend on the RF bitrate or any of that other stuff.

Still having problems with the ground XBee shutting down after a certain amount of time although it stopped after a certain time. Could be a WAP. Saw no interference between 72Mhz receiver & 2.4Ghz transmitter.

This ground based business gets more problematic every 2 hours per day we're up there. It turned from a latency problem to a dropout problem. If too many analog packets are dropped, the INS drifts.
Posted by Jack Crossfire | Sep 02, 2008 @ 02:31 AM | 2,715 Views
Managed to get 8000 bits/sec over 72Mhz. There's probably enough bandwidth in 72Mhz to carry 9600 bits/sec but this would involve diabolical assembly language. The hardware capture module doesn't work on the PIC18F1320. The next test will be range with full duplex XBee + 72Mhz + fully functional copter. Probably need another 72Mhz receiver since the GWS really is flaky.
Posted by Jack Crossfire | Sep 01, 2008 @ 04:26 AM | 2,600 Views
Still over 3 days away from XBee replacement, managed to get 72Mhz solidly over 600ft using our spare collapsible antenna on the receiver. You'd never fly a receiver with a collapsible antenna, but on a ground station anything is possible. U still wouldn't want to go over 300ft, since antenna position gets very temperamental over 300ft & the 2.4Ghz link is going to fall over long before this.

Mind U, this is glitch free PCM. Glitching analog would go farther.

In other news, once again stumped in our quest for the schematic diagram scene from ET which was cut out of the 2002 release, but was in the theatrical release. Unfortunately no goo tuber is old enough to remember the theatrical release.

All humans are fascinated by any hand made gadget using spare parts which sends a message to the great beyond.
Posted by Jack Crossfire | Aug 31, 2008 @ 10:13 PM | 3,209 Views
What's on your mind is how accurate the PPM is with all that 72Mhz rejection. What's on our mind is ground station software. It's a lot easier to go from ground based autopilot to embedded autopilot than the other way. Mainly, the embedded autopilot only needed 1 thread.

The ground based autopilot needs 4 threads handling information from the copter & transmitter, all crashproof.

Now some artificial intelligence notes. Hardware neural networks were done in the 80's. They're mostly abandonned. The most famous was the Intel 80170NX. It couldn't train itself in hardware.
Posted by Jack Crossfire | Aug 30, 2008 @ 06:19 AM | 3,262 Views
So the answer is still no. U can't sample analog levels near a 72Mhz transmitter. The inductor method on Goog didn't work. The PPM wire was still tempermental. After a day of trying everything, ended up converting the PPM wire to an open drain inside the shielded part of the transmitter. There was only enough room in the shielded area for a transistor. It was a one component bullseye & the PPM became 72Mhz immune.

So use open drains with direct grounding & U don't need to worry about 72Mhz energy. Still no idea how precise the PPM is. It seems a bit noisy....Continue Reading
Posted by Jack Crossfire | Aug 28, 2008 @ 12:52 PM | 3,376 Views
For the first time in years, actually found useful information on The Goog. Punching in "extracting buddy box ppm" is the sweet spot.

Mainly, U can capture analog levels near a 72Mhz transmitter. U need to isolate all the transmitter connections with RF chokes. The Goog recommends 100uH, so we're using 200uH. In an unshielded board, it's still tempermental even for PPM.
Posted by Jack Crossfire | Aug 27, 2008 @ 05:45 PM | 3,342 Views
So in the RC rescue bill your government is putting together, conforming loans for aircraft are being offered to $415,000 with 0 down. Owers of expensive aircraft like copters & UAV's can borrow up to $750,000, as long as they prove they can't afford it.

We also have an $8000 first time pilot credit. $3.9 billion to buy & rehabilitate wrecks. $30 billion to help JP Morgan acquire Align. $25 billion to nationalize E-flight. Best of all, crashes R now FDIC insured up to $100,000. At least your taxes R funding something useful instead of worthless mcmansions.
Posted by Jack Crossfire | Aug 27, 2008 @ 12:51 PM | 3,479 Views
Lets get one thing perfectly clear. If we had any money, this would be a stock 9 channel transmitter & stock 9 channel receiver, with 9 servo wires going into the ground station where they would be converted to autopilot functions & resent by a 2.4Ghz full duplex XBee. No soldering. No PPM decoding. That would be a truly untethered plug N play system.

Google searches for 9 channel radios R ugly. Ubama's RC stimulus bill looks better every day.

The binary to PPM modulation from last year works again & the link is sending binary from the transmitter directly to the laptop for the first time.

To use a 72Mhz transmitter, U can't capture any analog signals. Previously got good results by moving the antenna away from the transmitter, but analog readings drifted slightly & we now need very stable analog readings for autopilot commands. Decoding PPM is much easier, but not as accurate & fast as direct analog readings were.
Posted by Jack Crossfire | Aug 25, 2008 @ 08:09 PM | 3,520 Views
The cost of 900Mhz came down again, but we decided to pass on it again & stick with another round of 2.4Ghz. U can wrestle a 900Mhz 115200bps Jesus modem out of Digi but it's going to stay a painful & expensive process until 2009. Interference between 900Mhz & GPS is a high risk, followed by unknown performance, followed by higher price. Already have run 2.4Ghz downlinks successfully & showed the 2.4Ghz can do 32000 bits/sec full duplex & 40ms latency.

In the mean time, the focus is advancing a 72Mhz link between transmitter & laptop.

Transmitter ---72 Mhz---> laptop <---2.4Ghz----> aircraft

Untethering the pilot in command is still a high priority, so there's no way to use 72Mhz as an uplink.

Practical ground based autopilot only seems to have appeared in the last year. Just 2 years ago, long range wireless modems were super expensive, heavy, & impractical compared to embedded computers. 802.11 cards were the gold standard & going over 300ft required an obscenely expensive brick that only did 19200bps.