GPS doppler velocity should be the most accurate.
Getting velocity by taking consecutive position samples (from NMEA etc) is ok if one is moving fast, and you do a fair bit of averaging. There will be a lot of jitter, due to position error. And if you want 3D velocity then you have to use altitude also which has even more jitter.
NMEA does give you velocity (from here)
RMC – NMEA has its own version of essential gps pvt (position, velocity, time) data. It is called RMC, The Recommended Minimum, which will look similar to:$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A
Where:
RMC Recommended Minimum sentence C
123519 Fix taken at 12:35:19 UTC
A Status A=active or V=Void.
4807.038,N Latitude 48 deg 07.038’ N
01131.000,E Longitude 11 deg 31.000’ E
022.4 Speed over the ground in knots
084.4 Track angle in degrees True
230394 Date – 23rd of March 1994
003.1,W Magnetic Variation
*6A The checksum data, always begins with *VTG – Velocity made good. The gps receiver may use the LC prefix instead of GP if it is emulating Loran output.
$GPVTG,054.7,T,034.4,M,005.5,N,010.2,K*48where:
VTG Track made good and ground speed
054.7,T True track made good (degrees)
034.4,M Magnetic track made good
005.5,N Ground speed, knots
010.2,K Ground speed, Kilometers per hour
*48 Checksum
These values appear to be velocity over the ground i.e. a 2D velocity.
This strongly suggests that GPS velocity is 2D and not 3D in the real world.
I would think part of the problem is velocity in relation to what, and then the relevance of that relative velocity. The earth is not a perfect sphere, and the velocity by the GPS chip will be relative to the satellites. The added accuracy from Doppler, what is it worth in reality? Would that be more accurate than using position and INS system?
I don’t know, interesting stuff.
Is it worthwhile to consider gradient? On a typical GA flight you’re only on a non-level gradient for a small proportion of the time, and even when you are, the gradient is pretty shallow. Typical GA climbs and descents are only about 5 degrees (about 1 in 10), in a 1 in 10 gradient, you are on the hypoteneuse which is sqrt(10^2 + 1^2) which is sqrt(101) = 10.04, so 10.04 units long rather than 10, so the difference between measuring your speed along the hypoteneuse versus just your ground speed will be trivial.
I agree the gradient is insignificant in most scenarios. It’s like the DME distance versus GPS distance. Unless you are flying almost over the top of a DME station, they are really close, and in most cases where you want DME distance to be spot on is on an IAP and then you are descending towards the DME anyway 
However, if a device is attempting to display a 3D velocity, and it is using the NMEA data stream, then it may have to do it by working out the three x y z velocities by looking at successive position samples, and the altitude in particular is going to have significant jitter.
Apparently a GPS receiver always computes the 3D velocity internally but the info I found online suggests that this is not delivered via the usual data streams.
The above NMEA data comes via a “com port”. The app has to be configured for that port. Under unix these are called e.g. dev/tty0. But new and “consumer” apps just use the API for the internal GPS. And, what data you get via an Android or IOS positioning API is another matter. These devices use wifi as an initial positioning aid (looking up access point MAC numbers in some database, etc).
On z-axis vertical speeds, I doubt we experience more than -20kts and +15kts (any 100fpm = 1kts) in things that fly at less than 200kts, in the other hand to do 200kts (20kfpm) vertically you need to show 1500kts before pulling up
I expect most of GPS software calculations/filters on typical Garmin/Tablets to be highly optimized for pedestrians, cyclists, cars, boats before they went to aircraft navigation business
In the other end, what do you see as GS in Space X GPS? tricky question if the rocket is carrying a next-gen GPS satellites 
I guess calculations have more Doppler/Relativity than normal GPS and load of smoothing/filter corrections from inertial sensors, weather simulations, earth gravity fluctuations, coriolis force and even internal rocket state
GNSS positions are calculated in earth centered earth fixed X Y and Z coordinates.
These values are converted to latitude and longitude.
The same is true of velocities. Although they’re computed relative to each satellite for doppler shifts, computing a coordinate conversion from the satellite body frame to the ECEF frame isn’t that hard.
Doppler is far more precise than using 3D discrete positions…
For example, height error in 3D autonomous positions (uncorrected) is typically 5-20m whereas horizontal error is typically 1-3m.
For 1hz that equates to the following (forgive me if this is pedantic) :
True groundspeed: 130kts or 66.8 m/s
3m / 66.8m = <5% error
20m / 66.8m = 30% error
So, it doesn’t make sense to use the altitude value to compute a 3D velocity… (WAAS is completely different, as it is far more accurate)
Typically, precision of each epoch is much better than the accuracies, which is what velocitywould be calculated from.
Just watch your GNSS coordinates sometime and see how much more the vertical coordinate “wanders” than the horizontal values.
Obviously this is by design.
Just looked at FR24 from my last flight in the Extra, which included several loops and vertical manoeuvres (hammerheads and vertical rolls). Looks like it must be using Doppler.
Does anyone know how to get the finer grained ADS-B data? On the Bryant thread on Pprune someone shows 0.5 second data which would be a lot more illuminating here. The tail number is N98TJ.
I’m pretty sure this is a straightforward loop, showing 58 at the top, which is about right. There are some missing datapoints, no doubt because of the strange attitude of the aircraft.
1579291470 2020-01-17T20:04:30Z N98TJ 37.928375,-121.760132 5000 126 99
1579291481 2020-01-17T20:04:41Z N98TJ 37.927231,-121.750076 4500 166 97
1579291491 2020-01-17T20:04:51Z N98TJ 37.926956,-121.749031 5600 58 278
1579291539 2020-01-17T20:05:39Z N98TJ 37.929367,-121.761894 5675 58 278
1579291658 2020-01-17T20:07:38Z N98TJ 37.93108,-121.787209 6399 100 244
1579291670 2020-01-17T20:07:50Z N98TJ 37.928371,-121.790306 5048 100 217
1579291678 2020-01-17T20:07:58Z N98TJ 37.926395,-121.791252 6200 100 205
I think this is a hammerhead (stall turn in transatlantic):
1579291817 2020-01-17T20:10:17Z N98TJ 37.924107,-121.794197 5200 138 289
1579291830 2020-01-17T20:10:30Z N98TJ 37.926807,-121.802971 5700 83 281
1579291838 2020-01-17T20:10:38Z N98TJ 37.926544,-121.80764 5700 112 264
What interests me specifically is what part of the API an android app might be using.
Apps can certainly get NMEA from an external GPS but apps using the internal GPS, I believe, don’t get NMEA. They use the positioning API.
Just got hold of the fine grained data from my flight (it’s in the KML file). Unfortunately there are too many points missing to be sure what happens when aispeed goes to zero, at the top of a hammerhead, but it does all look about right e.g. at the top of a loop.
I guess I could try a flat spin next time, in the Pitts the IAS goes to 0, never tried one in the Extra.
Johnh – is that ADS-B OUT data, from a WAAS GPS?
That may have 3D velocity, even if the data stream gives you only 2D doppler velocity, because you can get the vertical velocity vector if you have a fairly stable altitude, which you should have on a WAAS GPS.
A mobile device like a phone won’t have WAAS/EGNOS so getting a 3D velocity if this is not provided from the API is not likely to be viable (or reliable if you were to do it).
