New Products Flash Sale
Jack Crossfire's blog View Details
Posted by Jack Crossfire | Sep 06, 2008 @ 08:12 PM | 3,279 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,220 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,512 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,737 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,743 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,634 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,274 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,328 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,445 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,407 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,550 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,580 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.
Posted by Jack Crossfire | Aug 24, 2008 @ 06:13 AM | 5,498 Views
No-one read the last blog post. How about this. It's "cloud" autopilot.

Remarkably, Google's entire XBee search database is advertisements or people trying to sell XBee's but no tests of its performance. Now for the first time, we have discovered the XBee sux at full duplex.

With the link saturated & no flow control, U get 88000 bits/sec in 1 direction. This seems to be the limit of the PIC.

Saturate in both directions & U get nothing even with the flow control.

The only way to get full duplex is to have 1 be the master & the other wait for a master packet, then send as much as possible & back off just before the next master packet is due. In this arrangement, the master packets need to be 20ms apart & U get 32000 bits/sec each way.

This isn't the 115200 bits/sec low latency we wanted & no-one wants to spend $70 on double XBees for every aircraft.

Well the XBee's got less & less reliable over time. The ground XBee occasionally stopped receiving while still transmitting successfully. Finally 1 or the other died.

Contrary to many social network hits & according to 1 of the many datasheets floating around, the $32 ones were not 5V tolerant. Only the new $36 ones are. Fortunately, a web page for a future $39 900Mhz XBee has appeared. This one has been upgraded to 115200 & the range downgraded to 1 mile. Probably not available until 2009.
Posted by Jack Crossfire | Aug 23, 2008 @ 05:25 AM | 3,477 Views
Despite the getto measures, ground based autopilot would have some huge benefits.

VicaGlider would get a lot cheaper & easier. A lot of assembly language problems just vanish. A UAV fleet becomes possible by eliminating the embedded computer cost & the custom programming. Indeed, the first consumer UAVs from China R going to use extremely powerful ground based computers & the smallest possible bluetooth radios on the aircraft.

Got the PICs doing 115200 baud on the hardware UART. They only generate 17500 baud in telemetry. 100% of the bits have to make it. Have some range tests.

Definitely need a warning sound for when the bitrate drops below a certain amount, so the pilot can take over. Probably need someone pointing a directional antenna at it. Maybe a hand held laptop arrangement.
Posted by Jack Crossfire | Aug 21, 2008 @ 06:21 PM | 3,826 Views
Before the first Gumstix, considered sending all the sensor data to the ground & doing all the control on the laptop. The idea seemed hopeless because the laptop didn't work, we didn't have fast radios, an embedded computer seemed like a 1 time purchase, but times have changed. Now the math.

A/D: 90 * (2 + 2 + 2 + 2 + 2 + 2 + 2)
Mag: 40 * (2 + 2 + 2)
GPS: 4 * (4 + 4 + 4 + 4 + 4 + 4 + 1)

Total down: 12800 bits/sec

The laptop would do all CCPM & send only PWM. The XBee sends 100 bytes at a time. Assuming it could work at the full 115200,

800/115200 + 800/115200 + some delay for the physical layer 1600/115200

28ms latency

You'd never reach that in wireless & there's a huge penalty for full duplex. The highest we ever got out of a PIC was 57600. Previously, the minimum delay for navigation was 50ms. All this would be done on the PIC.

Now what about doing control on the airframe & sending weights from the laptop. This would need a Netburner.

INS: 25 * (4 + 4 + 4)
GPS: 4 * (4 + 4 + 4 + 4 + 4 + 4)

Total down: 3168 bits/sec

Assuming 4 networks of 296 weights uploaded once a second, 50% compression, U need 80,000 bits/sec for the upstream.

Any laptop computation would unleash a massive amount of computing power for artificial intelligence. The barrier to entry would be much lower. The laptop would require new batteries eventually exceeding the cost of an airborne computer. It would require a lot of equipment. Things...Continue Reading
Posted by Jack Crossfire | Aug 21, 2008 @ 02:36 AM | 4,025 Views
Well, another few hours of reboots, flexing & playing, & the problem moved to 1 of the SDRAM chips. Looks like Gumstick #2 is dead. Also another PIC lost an analog pin.

Unfortunately, we're out of money for August. Now some options for September:

Draconian downgrade to a netburner or something & just get the job done with a software rewrite.

$100 Downgrade to the cheapest 200Mhz Gumstick & just get the job done with existing software.

$130 - $170 Replace with another 400Mhz to 600Mhz Gumstick & commit to a bigger neural computing campaign + a heavy case.

$195 Upgrade to a 500Mhz Blackfin & commit to a bigger neural computing campaign + a software rewrite.

All a main computer needs is 3 serial ports & not many clockcycles. The Blackfin has neither hardware floating point nor A/D, so it's a miss. The Netburner would need some hardware magic to make flight recordings & we all know what happened to the SD card campaign.

Nothing has happened with neural networks because it's unlikely such a small aircraft can get more stable. The way the pros do it is by developing a plant neural network & a controller neural network. The plant learns to predict results of control inputs & the controller uses the plant to train itself. They can't just flip the inputs & the outputs to make a controller out of a predictor.

We would have 2 networks for an attitude controller & 2 networks for a velocity controller. The networks themselves R black boxes, redesigned to suit the latest whim. The plant & controller are where the programming is & fixed components.
Posted by Jack Crossfire | Aug 20, 2008 @ 03:13 AM | 3,421 Views
The Hirose connector is still killing us. Got it booting again with the Hirose in just the right angle. A Blackfin "camera board" appeared in the last year which can do PIC & Gumstick functions much faster. Either this guy is going to figure out he can make a lot more money calling it a computer or embedded computing is really a graveyard.
Posted by Jack Crossfire | Aug 19, 2008 @ 03:31 AM | 3,598 Views
There it is. Board #2. Had a handful of errors & a few more reworks to fit in more heat sinks. The Gumstix isn't booting. Suspect power supply noise. Did another NASA & permanently soldered the radio to eliminate the connector from the next crash. These headers won't break off from vibration. Have a few more days of tests, calibration, cyclic training, & repairs. Time to forget about weight & spread the connectors out.
Posted by Jack Crossfire | Aug 18, 2008 @ 12:47 AM | 3,650 Views
Despite all the communism, slavery, & steroids, ended up focusing more on the olympics this time. During the marathons, NBC snagged some aerial shots of Beijing which simply didn't exist before. Finally figured a way to get HDTV from the tuner which only works on an obsolete computer, to the computer fast enough to decode HD, to the 30" monitor. No DVR unfortunately.

China is going to be the world's largest economy again & the technology leader again. The only reason anyone else got ahead was petroleum, but those days R over.