Menu Sign In Contact FAQ
Welcome to our forums

Does GPS measure actual distance travelled, and actual speed, when there is a gradient?

Surprisingly I can’t find an answer to this online.

This is in the context of a typical GPS receiver, in a phone, tablet, or a piece of avionics.

AFAIK in all cases the data includes the velocity, which comes from the GPS solution. It is not calculated by the device, by taking consecutive position points and the time from one to the next. That would produce an inaccurate result with a lot of jitter.

IOW, if a rocket, on an F15, is flying up vertically, what ground speed does the GPS show?

Stuff I found online suggest that the velocity determination is done by doppler shift and is 3D which would be logical, but the figure delivered by the typical API is just the 2D one, so if your movement has a vertical component, your speed is under-estimated.

Some of the stuff online regarding device GPS APIs shows numbers which seem completely unrelated to the very accurate data we see in flying. For example this is from Android, and it states:

Shoreham EGKA, United Kingdom

Peter wrote:

IOW, if a rocket, on an F15, is flying up vertically, what ground speed does the GPS show?

I’ll try that in one of our 172s and will report back.

What is the typical GPS postion update frequency? and how that compares to time lapse of GS changes from ASI lags, pilot maneouvring and wind changes

I think these facrors are far more pronounced for GA flying than changes in height/terrain, but it will be interesting to know what GS one would see in GPS when the Swiss AF are doing Alps topography using F5s in windy days ?

ESSEX, United Kingdom

Doppler is mentioned in Peter’s android reference, and I have seen that somewhere else too (aviation related).
I.e., speed is not just derived from delta position observations, but is (also) part of the raw data from the GPS receiver, yielding more accurate speed information.
Then again, for all I know, some receivers could have tiny accelerometers installed like our smartphones have, and that could also improve the speed of updating both speed and position during accelerated movements. I have no idea whether that is the case.
Obviously this could all be very GNSS receiver technology/software dependent.

EKRK, Denmark

My humble opinion would be that velocity is provided in 2D for reasons of navigation (think ETE and so on).
For example, if you were at 30k ft with a fuel problem, it would be precarious to display and calculate ETA and range based on a 3D velocity. (you’re flying much faster than your groundspeed and therefore range calculations on a 2D map would not reflect the groundspeed – if calculated in 3D).

Additionally, pilots might be confused into thinking that it was some sort of airspeed indicator (or alternate) but given that there is no direct measurement of wind, it couldn’t serve as such.

GNSS is a navigation technology and pilots navigate in 2.5D so I’m 99% certain that the velocity values provided are 2D with respect to latitude and longitude

Last Edited by AF at 02 Feb 18:29

The 1st link above local copy shows several ways to get velocity, but I see no info on what the typical GPS app on a phone or tablet does with regard to the original Q.

Yet they do all manage to display the ground speed of vehicles and aircraft pretty accurately. You can check the GPS GS by flying directly towards a DME. But then the gradient is insignificant.

Shoreham EGKA, United Kingdom

I don’t think there is an authoritative answer for that as every app can do as it chooses.

Velocity values are provided in three vectors, latitude longitude and altitude from most GNSS boards.

My experience with mapping and geodesy (my profession) tell me that most apps report 2D velocity by combining lat and long velocities.

But every app is different. They all receive data in streams from the GNSS receiver (NMEA, GGA ZSA, etc) and parse that data and often run a Kalman or similar smoothing filter on the data before displaying results to the user.

OK; I wondered if they might just be using the velocity bit of the API.

Shoreham EGKA, United Kingdom

Most of the GNSS receivers provide velocity in 3 vectors as a standard output, but there are a ton of messages available which are typically configurable to the integrating hardware developer.

If I had to guess, (really forced) I’d guess that most systems use the standard NMEA stream with the speed-over-ground velocity message GPVTG. See here for explanation of messages within the typical NMEA stream:

Last Edited by AF at 02 Feb 19:41

On iOS…

This value reflects the instantaneous speed of the device as it moves in the direction of its current heading. Because the actual speed can change many times between the delivery of location events, use this property for informational purposes only.

… they categorically say not to trust it.. I certainly would not use that to display a speed in my own app – I’d rather calculate this myself.

On the almost ubiquitous uBlox modules, it is also interpolated. No doppler stuff of anything ‘clever’ is used – it’s purely a function of the INS. The interpolation happens at the ‘measurement’ rate, though, not the reporting rate. So even if the module may only be reporting back to the host at 1Hz or 5Hz, the calculations are being done at 50Hz for example.

The accuracy and reliability of this data depends which ‘dynamics’ mode the module is configured to use. This is where you choose from automotive / sea / airborne etc., and everything is tuned to the particular application and certain assumptions are made. For example in Sea mode, the device assumes you are (obviously) at sea level at all times, and so doesn’t need to waste effort even computing a vertical element. By contrast, in airborne mode overall accuracy (and even the ability to acquire a 2D fix) can be sacrificed in order to ensure that the device can deal with dynamic multi-G events in all three dimensions.

Last Edited by stevelup at 03 Feb 08:35
42 Posts
Sign in to add your message

Back to Top