Well, we have simulations with and without GPS assisted attitude calculations. The trick with this is GPS is delayed & prone to glitches. U have to dilute the GPS corrections over many output samples and delay the accelerometer readings.

The accelerometer reading corrected with GPS is blended with the gyro readings. We do not apply GPS corrections directly to gyros.

The corrected acceleration never hits magnitude 9.81 like it's supposed to.

The GPS corrections gave more accurate but seriously delayed gyro results. Finding the less inputs U put into the attitude, the faster and less accurate the result. The more inputs U put in, the slower and more accurate the result.

Should reduce blade pitch one of these days. Raised it to lift HD cameras, but it made wind very hard for even humans.

Wishlist:

30" monitor: $1400
900Mhz video set: $200
Laptop: $600
Laptop video capture: $150
HD cam: $660

Have over $100 invested in worthless SD cards. The Canon A450 seems the most practical way to recover that investment with less crash risk. Still having post budget stress syndrome from the Canon TX1 crash. With official inflation at 4.3%, it's easer to blow cash & crash cameras.

What is the time scale on these graphs?

That plot was 1 minute in total.

GPS output messages should be synchronized with the PPS time mark out of the GPS.
Any Idea how much of the GPS delay is the time to transfer the serial data and parse it?

GPGGA is ~ 72 Chars ~ 10 bits per char
At
4800 ~ 150msec
9600 ~75 msec
115200 ~ 6.25msec

I've got my GPS spitting out binary messages at 115200 as that
is the shortest message and shorteest delay. I'm also only outputting the exact messages I need, no extras.

Does your GPS output vertical velocity (not just diferentiated height)?
I've been told that the velocities are doppler derived and are of very good quality.
The early Armadillo aerospace vehicle used integrated GPS velocity for hover height exclusively. (They were also using a $2500 Ashtech/Thales GG12 and high quality GPS antenna)

The uBlox has an 85ms delay in serial communication since it requires the following transaction to get a reading:

$GPRMS response
$PUBX request
$PUBX response

The vertical velocity was discussed here

https://www.rcgroups.com/forums/atta...mentid=1593888

It generates a worthless dZ and may not even generate useful altitude above 1Hz.

Originally Posted by pbreed

Any Idea how much of the GPS delay is the time to transfer the serial data and parse it?

115200 ~ 6.25msec

True, true.
I made the following approach: after CRLF received, I clear the buffer counter and note my embedded system time (32bit seconds and 8 bit 1/32th seconds which corresponds to 31.25ms per processing frame). After receiving the whole line, checking CRC and confirming this was $GPGGA (which arrives first in a series), I add this 'reception time' to parsed GPS data structure. In the future, I will be able to calculate GPS age easily, and extrapolate the data linearly (but not further than 1s, in case of GPS signal loss).
Another idea would be to go 230K baudrate, which is not supported by PC uarts, but uC could do it. The problem is that it is rarely clearly stated in the datasheet what is the maximum baudrate for given GPS receiver - looks like endusers rarely build cruise missiles
BTW this is mabe the moment to start using SIRF binary or UBLOX binary protocol. There should be also ETEK flavor for EB-85A I am using.

Ok so far EB-85 ignored 230400 and 250000 baudrates available at ATMEGA.
USARTGPS_putstr("$PMTK251,230400*1D\r\n");// 230400 8n1
USARTGPS_putstr("$PMTK251,250000*1F\r\n");// 250000 8n1

the fastest setting is USARTGPS_putstr("$PMTK251,115200*1F\r\n");// 115200 8n1