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.

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.

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.

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.

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.