Freesteel Blog » GPS velocity records

GPS velocity records

Thursday, August 13th, 2015 at 5:27 pm Written by:

I’ve got a Global Top Inc FGPMMOPA6H GPS module (datasheet) in my hang-glider data logging device. Using the command packet:

$PMTK314,0,50,1,1,10,0,0,0,0,0,0,0,0,0,0,0,0,0,0

I’ve programmed it to give me a GPRMC every 50 cycles, a GPVTG every cycle, GPGGA every cycle and a GPGSA every 10 cycles.

The command $PMTK220, 200 is used to set the length of the cycle at 200ms, so I’m getting a positional and velocity reading 5 times a second.

The code for controlling all this is here. Note that my code does not contain hundreds of lines of #defines of the form:

#define PMTK_API_SET_NMEA_OUTPUT 314

that you tend to get in other people’s programs for the purpose of referencing the this-will-never-change-hardware-encoded 3-digit string ‘314’ by the arguably more readable (ie I will argue with you) string ‘PMTK_API_SET_NMEA_OUTPUT’ that serves no purpose, isn’t interpreted by anything except the preprocessor, and you have to look it up to get back to the number that is actually documented in the manual. Why is this controversial? </rant>

The GPS device records I’m interested in are the GPGSA (GPS Time, Position and fix related data) and the GPVTG (Course and speed information relative to the ground).

I gave up on the default GPRMC (recommended minimum navigation information) record that claims to contain both, except it’s missing the crucial value of the altitude (which is only in GPGSA) and the speed is given in knots rather than kph. I do, however, need it for the date record (GPGGA only has time from midnight), which is why it’s maxed out at every 50 records to avoid wasting bandwidth. The GPGSA is for the “dilution of position” data, which is not enough to compute accuracy, so I should get rid of that one.

Accuracy is actually controlled by matters like the analog timing conversions done inside the device, so it’s probably not observable to itself. I mean, if you really had to have this number then you could carry a super-accurate second device that really knows its position, and then compare the readings to this cheap device. But then why not throw the cheap device away and use the super-accurate one? And repeat for the next generation of accuracy.

There’s a theory that the velocity record is computed from the doppler shift of the satellite signals, rather than taking the difference between subsequent GPS positions, but there’s no mention of this in the datasheet.

Let’s check this out.

The first thing to establish is what does the velocity record correspond to. The records come down the serial line like so: GPGSA, GPVTG, GPGSA, GPVTG,… a pair every 200ms.

I need to know if the GPVTG corresponds to the GPGSA in front or behind or if it’s calculated in the middle of the cycle.

After some experimenting with different cycle rates and baud rates I’m satisfied that all the records are computed at once, and then serialized out back-to-back in the order GPGGA, [GPGSA, GPRMC,] GPVTG, so I’ve associated the velocity to the preceding position record, and the position record contains a time value while the velocity record doesn’t.

Suppose we’ve got a sequence of times, positions and velocities:

(t1,p1,v1), (t2,p2,v2), (t3,p3,v3), …

A cycle rate of 200ms means that t2-t1=t3-t2=0.200seconds.

Now, if the velocities are computed by differencing the positions, then as it could only refer to positions in the past, you would expect v2 to match the value (p2-p1)/(t2-t1).

However, if the velocity is instantaneously calculated from the doppler shift, then v2 would match the value (p3-p1)/(t3-t1), in other words an average that spans the forward and backward position samples.

For this I’ve written the EstimateVelocityChord() function which takes one of my flight GPS sequences and generates some graphs

gpsvel
[avg error is by height on the grid where d0 is the sample count before present, and d1 is sample count after present (intuitively speaking), and the green splurge is showing the scatter plot of errors at the optimal selection]

The answers are different for each of the different flight recordings, of course, and this is highly dependent on the turning circles of the glider (it’s an unusual trace where there’s never a straight line and there are no sharp movements), but generally if you take the chord length from the position at around -1.2seconds to the position at around +0.8seconds and divide the time then your average velocity error is 0.65m/s.

I wonder if we can use this to predict GPS error.

Reason I ask is I’ve been carrying around two GPSs (if you don’t count the one in the vario) and they disagree at times, like in this example at the start of a flight:
gpspair

Unfortunately I can’t work with the data on that flight because it’s in Austria and I’ve not made the conversions from those GPS coordinates into metres. But I can do it for a recent flight in England nailed to a hill for four hours where the second flight computer datalogger was in the tail of my harness and crashed after the first half hour.

Here’s the overlayed GPS traces, which look more globally offset than locally glitched like the one above.
gpspair2

Below I’ve plotted along the time axis (horizontal) the difference between the two positions (in white) against the sum of the error between the instantaneous measured velocity of the doppler and the velocity calculated from the GPS positions.
gpspairerr
I don’t see a correlation.

I’ll keep this pile of code to hand for when I’ve got more data. I’ll try to mount the second device next to the first one on the base-bar instead of in the harness where it’s moving around. And I’ll look for cases where there is a distortion as in that first diagram as it’s extremely unlikely that the errors in the velocity measurements will have tracked that crazy unflight-like motion exactly.

The point is to be able to filter for the sections where the data is reliable in order to extract the flight constants. I’ve still not got anywhere with this data analysis — other than to prove that most of my original ideas aren’t going to work.

My current strategy is to snip out short sequences of the flight of about 5 to 10 seconds in length and then hope to categorize them before deriving the flight envelope characteristics. Being able to discard segments where the GPS data is bogus will be a useful stage in the processing.

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <em> <strong>