Infamous "reversed polarity"

There were some problems with the analog to digital conversion board (the Demodulator).

Basically the sound input did not match expected bit output. And since we're fresh out on oscilloscopes, the next best thing was an USB sound card, baudline signal analyzer and a test signal composed of a start bit, all zeros and, stop bit and half a sinus wave for debuging:


From this it was discovered that for some reason the audio signal was inverted and (since WAV files shorter then 5 milliseconds weren't recognized as audio clips, so the rest was filled with silence) that the start bit should in our case be composed of two bits, first one setting the threshold to one and the second one to zero, so that the transition from hight to low will be registered (since it obviously does not from zero to low). Probably the same thing should be applied for "stop bit" as well.

All this means the audio samples containing bit info have to be regenerated and then can the module be retested.

Including GPS in the Mix

Processing new information brings new knowledge.

First things first, one absolute thing to avoid is putting the plane in the stall position. Listen to the sound of the wind just before the crash:

This includes aircraft speed and airfoil angle of attack (which is what happened in this case).

This set of experiences also includes aircraft dynamics such as roll and pitch tolerance during navigation maneuvers (using rudder for course correction puts the plane out of stable flight position), using ailerons for larger and faster turns (requires pitch and roll coordination) or climbing and descending (which was, surprisingly to me, more depended on aircraft speed then motor power or thrust).

And with GPS data we can visualize the flight and put it in to perspective:

The data indicates the flightpath was around 850 meters and it lasted for about 72 seconds. That puts the aircraft average speed at good 11 meters per second (40 km/h), which is consistent with the GPS measurements.

Next issue to solve is the GPS speed measurement spikes (accruing with the change of GPS accuracy or used used satellites in computing), which could be done with checking for accuracy changes and substituting with kalman filter values (to avoid needles calculations).

And the altitude offset (kind of important to know the correct altitude), caused by mathematical model used to calculate altitude from the center of the earth, with possible fix by manually adjusting for the WGS 84 model of Ellipsoid for planned flight path. Quick research shows that mathematical model of sea level in the Europe region is about 30 meters about actual sea level, combining that with (rule of thumb) 3 times the GPS accuracy margin, the GPS measurements came within map altitude. With enough altitude clearance probably good enough, but landing will take some more work!

Accelerometer and Orientometer sampling and smoothing is progressing well:

One thing left is to manage or wrap around the transitions in orientometer such as compass going from 350° to 10° trough North, which would be transition for 20° but is computed with kalman as transition for 340°.

"Demodulator"

When looking for alternate ideas to transmit data off the G1 other then the serial connection (which would require Linux kernel modification on the Android platform, but we're saving that for another time), the idea came to do it "old school".

So my electronically gifted little brother came up with this design:


We output plain pregenerated analog audio signals describing bits with the same modulation as the serial line to an amplifier and a micro controller which in turn converts them to the digital serial stream.

P.S. First test was done using the Christian Bale Terminator 4 outbreak remix ... looks like swearing would look like a string of p, @ and P characters :P

Learning Kalman Filter

After some research for what and advice for how, the data smoothing will be done with Kalman filter.

Some filter modeling tested in Octave:

Filter modeled to trust sensor measurements over state prediction (motor off) .

Filter modeled to trust state prediction over noisy measurements (motor on).

Next stop, implementation in to the sensors app, check time complexity and take measurements with known positions (for reference and better filter model) for dynamic adaptation.