So fabricated this board to see if the wrapping wire & radio interference was making the C328 unreliable. It writes all the control codes for the C328 to make it output continuous JPEGs.
Sadly, it's no more reliable than the previous methods. The C328 needs exact baud rates. It can't convert the 115740 from a PIC into 115200. The set baudrate command isn't very reliable either.
You're looking at spending tons of money on a crazy 14.7456Mhz crystal or sending all codes including ACKs over XBees. XBees seem to do exact baud rates.
In the end, got rid of the airborne microprocessors & just passed the XBees directly to the C328. Reduced their baud rate to 57600 & increased the C328 package size to 384. The trick is to send data slow enough to not overload the XBees & send the largest packages possible before the C328 crashes. This gives 7 seconds per frame, slightly faster than 115200 & 128 byte packages.
The ground XBee is locking up from packet collisions. It needs frequent power cycles. If by some miracle taxes only go up 4% next year, we might have enough dough for crazy crystals.
This is our C328 software. It does everything from full control on the ground to full control on the airframe.
To conserve battery power, it's basically a 3m/s descent to 33m, 1m/s descent to 10m, & 0.5m/s to ground. The 33m transition lets you descend into your downwash without smashing into the ground. This was the 1st flight using it, a very low nose pitch caused the radio to drop out at a certain high altitude, followed by execution of the Marcy Maneuver to quickly get back down.
Here's the radio graph.
Here's the altitude showing the tapering at 33m.
XBEE DIVERSITY BUSTED
Tried making an XBee diversity system. Fortunately it didn't cost anything.
Mocked up with switching circuits.
Switcher thrown in the ground station.
Ground station with dual XBees.
Aircraft with dual XBees.
The switcher. It must use 2N2222 transistors, not 2N3904.
Unfortunately, it was a total failure. Each switching circuit worked when tested separately with 1 XBee. With all 4 XBees connected, nothing worked. It also had other problems. It was a ton of extra electronics, wires, stuff that can break. It should really be done on the main board instead of another breakout board. It probably needed another voltage regulator.
Even though both XBees were on different frequencies, they probably detected enough power on the channels to back off. There could also be crosstalk in our UART multiplexer.
Another problem is to be most effective, each transmitter would need 2 receivers rotated at 90deg, bringing the hardware to 8 Xbees. Since our problem isn't fuselage obstruction but antenna polarity, you probably don't need diversity as much as turnstile antennas, but this requires a quadrature hybrid.
Time to "back off" of diversity & look at antenna placement or alternative radios. Merely keeping the antenna unobstructed by anything including foam may be enough.
Took a roundabout path, but finally got those MRF49XA's to work.
They do indeed reach all the way across the apartment at
least. These were intended as single chip radio modems for an indoor
copter & super cheap XBee replacements, hopefully without the lockup
The trick is to copy the reference software & ignore the datasheet. The
game is all about setting a low enough baud rate & a high enough SPI
rate so the FIFO's are kept up to date. If the transmit FIFO empties,
it transmits 0x00. If the receive FIFO overflows, you drop bytes.
The rate at which it fills & empties FIFOs is determined by the baud
rate register, DRSREG. Both receiver & transmitter need the same baud
All communication can be done with just the SPI interface, ignoring the
INT, FINT, FSK pins that the demo uses.
To make it run fast, you have to use the extra pins in addition to SPI.
Lowering the FSK pin causes SPI to read directly from the receive FIFO
instead of the register memory. The alternative to the FSK pin is
reading the RXFIFOREG register.
You also need the FINT & the INT pins to know if the receive FIFO has
data. The alternative to the FINT & INT pins is polling the STSREG
It has some odd tricks like how all the registers are 16 bits framed by
CS pulses, but for the TXBREG register you can write bytes indefinitely
in a single CS pulse & those bytes are transmitted.
It's designed for packet communication. It scans the incoming signal
for a 2 byte start code. Then it begins filling the receieve FIFO with
the incoming signal, including the start code, until you reset the start
code scanner. You can also scan the entire incoming signal yourself.
When no transmitter is on, it outputs noise in the FIFO.
With pure SPI, no interrupt lines, 6 MIPS microprocessors, & wrapping wire, got 60kbps out of them.
This is our firmware, which is supposed to run on the same chip as the flight controller.
Did several pirouettes at a very high altitude in a secret country where
it's allowed. These were demos of high altitude capability but
pirouetting video is not the reason for doing it. It's for getting
better images of M.M. world headquarters.
This was higher altitude coverage of the area around M.M's dishes but not
as high as the previous video. Made a point of documenting this
land before it was completely developed.