The context is a GPS app running on a phone or a tablet.

AIUI (I am a C programmer, embedded systems, no idea about android/ios
APIs) there are two ways the app can get GPS data

- NMEA, typically from a bluetooth external GPS, via a serial port
(dev/tty under android)

- something similar under IOS (Apple never supported NMEA but defined
a different stream)

- the positioning API in the OS (which uses wifi assist etc)

There also appear two ways to get velocity:

- use successive position points and work it out from the timings

- use the GPS doppler velocity (much better)

The Q is whether the app gets actual speed, when there is a gradient?

Searching around, it appears that everything delivered via either NMEA
or the API is horizontal i.e. 2D, so if say you drive a car down a 45
degree slope with the (assume accurate) speedo showing 100, the GPS
speed will be 70.7. One could test this with a satnav app but it is
hard to find a road with a significant enough slope.

Apparently the GPS receiver itself computes the 3D velocity naturally
but this is not presented via either NMEA or the API.

The reason I am digging around in this is because all phone apps used
in skiing have great difficulties getting the right speed.

Talking to somebody in the business, it appears that the app cannot
get the 3D velocity so it gets the 2D velocity and then calculates the
vertical velocity vector from the way the altitude varies, and adds
that in.

The result is usually poor because GPS altitude is not all that
reliable. I am involved with high-end GPS products in my day job so I
know how this works and the reasons. Normally GPS altitude is pretty
reasonable (within some 10-20m) but if you are trying to calculate a
velocity vector from its variation, that's going to be massively prone
to errors. An altitude delta of say 2m in 1 second, barely noticeable
in most applications, is a massive error if added as a 2m/s Z vector
to the horizontal (2D) velocity vector.

Does the above make any sense to the experts here?

Is there any way to get the original 3D velocity, via the device API?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2020-02-06 12:27, Peter wrote:

The context is a GPS app running on a phone or a tablet.

AIUI (I am a C programmer, embedded systems, no idea about android/ios
APIs) there are two ways the app can get GPS data

- NMEA, typically from a bluetooth external GPS, via a serial port
(dev/tty under android)

NMEA is a pretty blunt instrument due to its origins and purpose.

- something similar under IOS (Apple never supported NMEA but defined
a different stream)

Apple obfuscate all GPS 'internal' data from the phone's sensor. All
you can get out of it are very basic info (L/L, altitude, speed,
direction of travel, "quality").

No telling what filtering they have thrown on it either.

- the positioning API in the OS (which uses wifi assist etc)

There also appear two ways to get velocity:

- use successive position points and work it out from the timings

You'll end up with a noisy velocity.

- use the GPS doppler velocity (much better)

Best to use GPS VNorth, VEast and VDown (up?) to compute the velocity.

Using Doppler is more complicated and won't give you a better velocity
in the than VNorth, VEast, VDown (up?).

And you won't get Doppler from iOS. You should from Android (may be
version or device limited).

The Q is whether the app gets actual speed, when there is a gradient?

Searching around, it appears that everything delivered via either NMEA

NMEA is not very useful for whatever it is you seem to be aiming for.

or the API is horizontal i.e. 2D, so if say you drive a car down a 45
degree slope with the (assume accurate) speedo showing 100, the GPS
speed will be 70.7. One could test this with a satnav app but it is
hard to find a road with a significant enough slope.

See what I write above about VNorth/East/Down (up?).

Apparently the GPS receiver itself computes the 3D velocity naturally
but this is not presented via either NMEA or the API.

The reason I am digging around in this is because all phone apps used
in skiing have great difficulties getting the right speed.

If skiers are twisting and turning, then you'd need a higher sample rate
(10 Hz) than most GPS receivers, and some nicely tuned filters. Indeed
you'd probably want the filters to adapt to the skier's "style".

Talking to somebody in the business, it appears that the app cannot
get the 3D velocity so it gets the 2D velocity and then calculates the vertical velocity vector from the way the altitude varies, and adds
that in.

That would be noisy and inaccurate.

The result is usually poor because GPS altitude is not all that
reliable. I am involved with high-end GPS products in my day job so I
know how this works and the reasons. Normally GPS altitude is pretty reasonable (within some 10-20m) but if you are trying to calculate a
velocity vector from its variation, that's going to be massively prone
to errors. An altitude delta of say 2m in 1 second, barely noticeable
in most applications, is a massive error if added as a 2m/s Z vector
to the horizontal (2D) velocity vector.

Does the above make any sense to the experts here?

You're on the right path. If you can get the VNorth/East/Down values
from the GPS you'll be far better off. If you can get them at a higher
rate (10Hz) even more so.

Is there any way to get the original 3D velocity, via the device API?

On Android, most certainly. On iOS, no. Apple are dicks that way.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Peter wrote:

The context is a GPS app running on a phone or a tablet.

[snip]

The Q is whether the app gets actual speed, when there is a gradient?

Searching around, it appears that everything delivered via either NMEA
or the API is horizontal i.e. 2D, so if say you drive a car down a 45
degree slope with the (assume accurate) speedo showing 100, the GPS
speed will be 70.7. One could test this with a satnav app but it is
hard to find a road with a significant enough slope.

It is actually quite hard to find even double black diamond slopes where
the vertical component really matters, until you get into Kitzbühl type Steilhang.

Apparently the GPS receiver itself computes the 3D velocity naturally
but this is not presented via either NMEA or the API.

Every GPS fix has to return 7 parameters (x,y,z,dx,dy,dz & time), of
these the (fractional/differentional) doppler-based delta values are the
least accurate. This is the main reason most GPS apps tend to use some
form of filtered position measurements for the horizontal velocity
instead, simply because it will be more accurate.

The reason I am digging around in this is because all phone apps used
in skiing have great difficulties getting the right speed.

Talking to somebody in the business, it appears that the app cannot
get the 3D velocity so it gets the 2D velocity and then calculates the vertical velocity vector from the way the altitude varies, and adds
that in.

You can do far better if you have a barometer to measure short term
altitude changes, then using the long term gps alitude measurements to calibrate the barometer.

The result is usually poor because GPS altitude is not all that
reliable. I am involved with high-end GPS products in my day job so I
know how this works and the reasons. Normally GPS altitude is pretty reasonable (within some 10-20m) but if you are trying to calculate a
velocity vector from its variation, that's going to be massively prone
to errors. An altitude delta of say 2m in 1 second, barely noticeable
in most applications, is a massive error if added as a 2m/s Z vector
to the horizontal (2D) velocity vector.

Does the above make any sense to the experts here?

Is there any way to get the original 3D velocity, via the device API?

I do know that the Norwegian researchers who helped our alpine team
dominate super-G and downhill for some years use a solution based on
GPS+INS, possibly also adding barometer and/or a differential base
station somewhere on the hill. I do know that they need very high
frequency updates (5-20 Hz?) to get the best results.

I also know that if a brand new 4-band cell phone gnss could ignore the
power budget for a minute or two, just grabbing all the sats all the
time and save away all the raw pseudorange data, then you could probably
get down to cm-level with some post-processing.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)