Thanks Decrepit!

Correct me if I'm wrong:
Doppler = Doppler, no discussion about that. Sdop gives the possible inaccuracy of the speed measurement. I guess Sdop is calculated by the points measured + doppler speed + number of satellites + Hdop. (or some more measurements, if Yes: which?)

And what is the speed outcome on the final results on GPSteamchallenge for the speed measured at point 18902? Is that 15,667 or 15,667 minus 1,672 or somewhere in between?

Velocity accuracy is an integral part of velocity computation. Start here: www.insidegnss.com/auto/marapr15-SOLUTIONS.pdf

Select to expand quote

JulienLe said..
Velocity accuracy is an integral part of velocity computation. Start here: www.insidegnss.com/auto/marapr15-SOLUTIONS.pdf

Nice theoretical explanation Julien, but no answer to my question... i'm not asking about speed accuracy specific do i?
Refrasing the question to its essence: Two devices, identical position: one has 12 satellites and hdop value 0.8, the second has 16 satellites and hdop value 1.6, which of the two is the most accurate?

I had my last answer deleted by a moderator without explanation and will thus retire from the forum. There's no point in coming here to read BigSnut or GreenEgg's type of messages. Trolls can play with other trolls. I noticed a few weeks ago that Derryn had a message deleted too when she replied to one of these. If you need to reach me: julien@motion-gps.com In a month, the waiting list will be done and workload will halve leaving me more time for documentation/firmware/emails.

A few emails and a bit of thinking later, I'll keep on watching the forum. I shouldn't penalize the hundreds of you who have legitimate questions.

I also shouldn't bother with new accounts from non-users with all/most messages on topics related to my devices. Surely they have good reasons to do it that way. I'll keep on replying to users and interesting questions. Let's ignore the obvious bait.

Hi Julien, minis for DAC arrived via Matt Dowse. Appreciated.

Select to expand quote

GreenEgg said..
When 2 doppler devices are being being compared where one receives 12 satellites with a 0.8 Hdop and the other receives 16 satellites with a 1.6 Hdop ... which of of both devices will be most accurate ?

"Most accurate" is not sufficiently specific.

HDoP relates to the horizontal position accuracy, so it is largely irrelevant for doppler speed measurements. If you're concerned about position accuracy, you'd have to also consider the nominal accuracy of the device. In the example you give, it would be quite possible that the 12 satellite unit has a stated 3 m accuracy, while the 16 satellite unit has a 1.5 m accuracy. Then, the actual horizontal accuracy estimate for both devices would be the same at 2.4 meter (1.5 m x 1.6, and 3 m x 0.8).

HDoP is based on the 3 D position of the satellites used. The formulas to calculate HDoP are easy to find, and all devices should use the same formula. But the same is not true for speed accuracy (called SDoP for Locosys units, and sAcc for u-blox based units like the Motion). Neither company has made public how exactly speed accuracy is calculated, and they clearly use different methods. The only things that seems reasonably certain is that they both use some kind of measurement of the signal-to-noise measurement from the individual satellites and/or the solution, but as I said, the details are unknown. But it is clear that the SDoP/sAcc estimates are calculated quite differently from HDoP numbers (which completely ignore S/N ratios, except at the point where the GPS decides which satellites to include in the solution).

With respect to speed accuracy, your question can be rephrased: will doppler speeds be more accurate when a unit uses fewer satellites that are more distributed in space (lower HDoP), or more satellites that are less distributes (higher HDoP), assuming that both units have plenty of satellites for a solution? The answer to that question is basically unknown. You could certainly develop theories pointing either way, and I' sure that there is anecdotal evidence pointing this way or that way. But lest I am accused again of developing "Grand Theories of Everything GPS" by people who don't understand the scientific process, I keep my thoughts to myself.

But the question at hand is how this relates to the Motion, which apparently limits the number of satellites used in the solution to allow for higher rates (10 Hz). During a typical windsurf session, a Motion may see 24-28 satellites with enough signal to possibly include it in the computation. In the Motion setup, it will pick the 16 with the best signal-to-noise ratio. One major thing that introduces noise are atmospheric distortions. Since the signal from satellites closer to the horizon travels through denser atmospheric layers, it will have more noise, which means the GPS will prefer satellites right above it over satellites on the horizon. This, then, leads to a higher HDoP number. But we also know that, for a constant number of satellites in the solution, having better S/N ratios will give more accurate speed results. So it is entirely possible, if not likely, that the 16-satellite unit in your example would have higher speed accuracy.

Julien certainly has done some tests to verify that the setting he uses are reasonable. You could, of course, so a large empirical study to get an exact answer. But that is pretty pointless, as long as the major source of inaccuracies can be traced to "user error". For example, using a GW-60 with an underhand grip reduces accuracy a lot more than any limits on satellites used possibly could. Similar problems can occur with a GPS worn on the upper arm if the armband slips and the GPS points down.

Thanks boardsurfr for your long reply, learned a lot. Much appreciated!

The following two articles are worth a read if you want some more definitive info.

The first discusses the usefulness of HDOP as an indicator of GPS speed accuracy.

The second discusses the usefulness of SDOP as an indicator of GPS speed accuracy.

www.researchgate.net/publication/303759072_Accuracy_of_Speed_Measurements_using_GNSS_in_Challenging_Environments

nujournal.net/estimating-accuracy-of-gps-doppler-speed-measurement-using-speed-dilution-of-precision-sdop-parameter/

At no point does he talk about Motion. This question shouldn't be in this topic. No one sane would use HDOP. And if your Motion has a 1.6 HDOP in regular use, email me for an exchange: it should have been binned when I trialed it here. The fastest 500m windsurfing run on a Motion, Valkenaers' 53kn at Luderitz 2019, has an 0.8 HDOP. The best new Minis at rest reach an 0.3 HDOP. Again, for our use, it has no importance whatsoever and I've never ever made mention of it. It's just not useful to us. It's a whole different computation branch to velocity and thus speed.

Valkenaers' best 500m on an LCD: imgur.com/a/DMIUFsO
A random Mini's best 500m I was just sent: imgur.com/a/AE7XTzQ
And another one because why not: imgur.com/a/1WK4X5R

It's interesting to notice how the LCD device with its omnidirectional antenna reaches a +/-.200 but it isn't reflected in its HDOP. In the same vein, the Mini's HDOP is better but it isn't reflected in its speed accuracy. It's expected from two different type of devices that should share the same speed accuracy but the Mini's antenna type give it a small advantage in position. Thus, lower HDOP doesn't mean lower speed accuracy and lower speed accuracy doesn't mean lower HDOP. It's two uncorrelated figures coming from two different computation paths.

John's first paper makes two other interesting points I agree with too: satellites used isn't an useful metric either, and more constellations make for marginal improvements.

GNSS isn't unknown or magical or guesswork. There's research and data freely available all over Google Scholar. And for those who prefer code, read RTKLIB's github. It makes good work of showing the various decisions, various layers of filters and various layers of error correction involved.

I'd also like to make the point that I disagree with most of boardsurfr's post and that the block related to Motion is wrong.

Select to expand quote

JulienLe said..
At no point does he talk about Motion. This question shouldn't be in this topic. No one sane would use HDOP. And if your Motion has a 1.6 HDOP in regular use, email me for an exchange: it should have been binned when I trialed it here. The fastest 500m windsurfing run on a Motion, Valkenaers' 53kn at Luderitz 2019, has an 0.8 HDOP. The best new Minis at rest reach an 0.3 HDOP. Again, for our use, it has no importance whatsoever and I've never ever made mention of it. It's just not useful to us. It's a whole different computation branch to velocity and thus speed.

Valkenaers' best 500m on an LCD: imgur.com/a/DMIUFsO
A random Mini's best 500m I was just sent: imgur.com/a/AE7XTzQ
And another one because why not: imgur.com/a/1WK4X5R

It's interesting to notice how the LCD device with its omnidirectional antenna reaches a +/-.200 but it isn't reflected in its HDOP. In the same vein, the Mini's HDOP is better but it isn't reflected in its speed accuracy. It's expected from two different type of devices that should share the same speed accuracy but the Mini's antenna type give it a small advantage in position. Thus, lower HDOP doesn't mean lower speed accuracy and lower speed accuracy doesn't mean lower HDOP. It's two uncorrelated figures coming from two different computation paths.

John's first paper makes two other interesting points I agree with too: satellites used isn't an useful metric either, and more constellations make for marginal improvements.

GNSS isn't unknown or magical or guesswork. There's research and data freely available all over Google Scholar. And for those who prefer code, read RTKLIB's github. It makes good work of showing the various decisions, various layers of filters and various layers of error correction involved.

I'd also like to make the point that I disagree with most of boardsurfr's post and that the block related to Motion is wrong.

Clear Julien, thanks.
One thing in your text is not correct I guess: Thus, lower HDOP doesn't mean lower speed accuracy and lower speed accuracy doesn't mean lower HDOP. I think lower should be higher.

One other question: And if your Motion has a 1.6 HDOP in regular use, email me for an exchange: it should have been binned when I trialed it here.....So a 1.6 HDOP is not OK?

Select to expand quote

GreenEgg said.......So a 1.6 HDOP is not OK?

I think the OBVIOUS point is that it is pretty much irrelevant as far as Doppler speed is concerned.

One does not impact the other. To the downside and to the upside. They are uncorrelated.

I try every device here at multiple stages of build and if one exhibited such different numbers than the norm, I'd throw it away. Thus, if any ever made its way out and showed such bad numbers, I'd exchange it.

It turns out there could be an issue with a parser filling its HDOP column using Motion's PDOP value (which is 3D, PDOP = sqrt(HDOP*HDOP+VDOP*VDOP)) and thus, some users are seeing wrong and elevated values. I'll make some trials as soon as the rain stops. It's purely cosmetical, no parser relies on this.

Select to expand quote

JulienLe said..
One does not impact the other. To the downside and to the upside. They are uncorrelated.

That's a slight overstatement. There is asomecorrelation if you look at the entire spectrum from very poor to very good reception, but it's nowhere near 1. For example, if you check the values in an environment where reception is poor (e.g. urban jungle or inside), both values will go up. But for windsurfing, that's irrelevant.

Select to expand quote

JulienLe said..
It turns out there could be an issue with a parser filling its HDOP column using Motion's PDOP value (which is 3D, PDOP = sqrt(HDOP*HDOP+VDOP*VDOP)) and thus, some users are seeing wrong and elevated values. I'll make some trials as soon as the rain stops. It's purely cosmetical, no parser relies on this.

The Motion uses and reformats the NAV-PVT sentences from the GPS, which only contain PDOP, not HDOP. The first program to support UBX files, and the one that has historically been the "gold standard" for accuracy, uses the PDOP value in the HDOP column (at least for typical UBX files), so other software does the same.

As Julien points out, PDOP is 3-dimensional, so it includes a vertical component (VDOP). The vertical DOP factor is generally several times larger than the horizontal DOP due to the constellation of the satellites used (mostly above the receiver). The actual formula is slightly different than the one Julien gives, but the conclusion is correct: when you see reported "HDOP" numbers for Motion devices or u-blox based prototypes, they will be higher that the real HDOP numbers.

So that's another reason you cannot compare HDOP numbers from Locosys devices to "HDOP" numbers from Motion and other u-blox based devices.

The importance of HDOP is really just historical. When all GPS units received only one satellite system, they'd often be in a situation where they'd get just a low number of satellites, say 4-6. If all of those are high in the sky, the positional accuracy is a lot lower than if they are spread towards the horizon in all directions (HDOP would be higher). That information then could be used for filters. But ever since we have doppler speed and speed accuracy estimates, HDOP has lost all practical relevance for speed analysis.

In my opinion, though, asking questions to better understand something is never a bad thing. Calling stuff OBVIOUS because you possibly know more than the person asking, however, is.

We could have gone for years more without noticing the switcharoo. :D

I'll give NAV-DOP a go next week and bring out them excel sheets.

Ran some quick static tests. 3D PDOP from NAV-PVT: 1.56, 2D HDOP from NAV-DOP: 0.72. I got fleeced! I'll run some dynamic trials soon.

An example: pastebin.com/raw/G1u3yqEq

So that's why Manfred wanted NAV-DoP in his units, and Probably why Peter doesn't include HDoP in GPSSpeadreader. It would be better if GPSResults just reported, "HDoP not available," instead of using PDoP.

That would be much less confusing.

Select to expand quote

decrepit said..
So that's why Manfred wanted NAV-DoP in his units, and Probably why Peter doesn't include HDoP in GPSSpeadreader. It would be better if GPSResults just reported, "HDoP not available," instead of using PDoP.

That would be much less confusing.

Except that I got the HDoP figure when I ran mine in GPSAR-Pro?????

This is from a Motion Mini which was not using NAV-DOP afaik.

Bit of a mystery for us GPS nerds, but actually of no practical consequence.

I think I may have found the explanation. NAV-PVT does include a report of "Horizontal accuracy estimate" called hAcc. This a seperate record from PDoP which is also included. It appears that perhaps GPS-Results is picking up PDoP and GPSAR is picking up hAcc?

the question is now, is hAcc the same as HDoP?

GPSAR uses hacc. And you can see the difference between hacc, hdop and pdop here: pastebin.com/raw/G1u3yqEq

It seems hdop <= hacc < pdop at first glance. But then units are unrelated anyway.

I'll wait to have some windsurf trials but I got nothing against adding NAV-DOP. It's nothing like adding NAV-SAT.

Nice to see all your comments op the Hdop question, learned a lot! I will forget about the need for low HdoP values.
Have another question (I'm just curious... hope to get some answers from all the experts here present).

Besides GPS-only, GPS devices also use Glonass / Galileo. Is combining all different systems (GPS/Galileo/Glonass) a step ahead? Some say adding Glonass is not always a better path to follow for accuracy.

Another thing I heard is Dual Frequency, L1 and L5 band. Does that help the accuracy?

Select to expand quote

GreenEgg said..
...Does that help the accuracy?

Again, there's two different, but related, "accuracies": position accuracy and speed accuracy (and it you want to get picky, you can sub-divide position accuracy in 3 dimensions). Practically all papers I have seen about GPS accuracy only looked at position accuracy, which is only somewhat correlated to speed accuracy. Pretty much all claims about "better accuracy" are about position accuracy, and to what extend (if any) they apply to speed accuracy is an open question. They certainly do not apply all of the time - there are GPS chips available that claim very high positional accuracies, but report "speed" that is not doppler based, and therefore substantially less accurate than doppler speeds (where "less accurate" means "much more prone to spikes"). I've seen "top speeds" of several hundred knots from windsurfing sessions when using such chips which, according to their descriptions, were among the best available. They did indeed have the highest data rates, but in reality, that meant that they'd be best in producing lots of crap faster than anyone else.

- You do want a low HDOP. But it's not a metric for our sport.

- Yes. You want to give your receiver the best chances. Although, GPS and Glonass have added so many space vehicles lately that I find these two sufficient nowadays. I made many trials earlier today and I'd say the average pick was 9 GPS + 7 Glonass + 2 Galileo. So having Galileo or not is more of a luxury.

- No. It solves issues not really affecting us on a lake or at sea. It also requires effort, area/volume and money from the manufacturer to actually see real world improvements rather than just boasting about it on a marketing slip.

Select to expand quote

JulienLe said..
GPSAR uses hacc.

That is incorrect, at least for ubx files containing only NAV-PVT sentences. GPSAR Pro shows "-1" for HDOP, indicating that it does not have a value for it:

I'll rephrase then: when loading a Motion file as Sailquik did above, GPSAR populates its HDOP field with the file's accuracy_horizontal field which is better known as ublox's hAcc field.

I'll do some trials and if it suits KA72/GPSSpeedreader/GPSSpeedResults/GPSAR, I'll now publish HDOP from NAV-DOP in Motion's frame instead of PDOP which no one uses anyway. Last field in each frame, "16-bit unsigned Position DOP", would become "Horizontal DOP". As the value in current logs is PDOP, it can only be higher than HDOP could have been so it creates no historical issue. And then we can all enjoy the true HDOP.

Tell you what, the quest for accuracy hasn't been this exciting in a while.

Select to expand quote

JulienLe said..
And you can see the difference between hacc, hdop and pdop here: pastebin.com/raw/G1u3yqEq

The values you show at this link are NOT hAcc values. As can be seen in the screen shot from the u-blox specifications that sailquik posted, the hAcc values in NAV-PVT records are integers, not real numbers. They are in millimeters, and since they describe horizontal accuracy estimates, values below a few hundred are quite unlikely. Here's graph that compares hAcc and PDOP from a recent session:

The horizontal accuracy estimates were between 5 meters at the start of the session, when the GPS had only 6 satellites, and about 35 cm later, when the GPS used 24 satellites.

But, as was said before, for the purpose of measuring speed and speed accuracy, PDOP, HDOP, and hAcc are irrelevant.

"UTC milliseconds, satellites, horizontal accuracy from NAV-PVT (meters, used by GPSAR), HDOP from NAV-DOP, PDOP from NAV-PVT (used by GPSResults)"

I converted them millimeters in meters, like GPSAR does.

Here's a graph from one set of tests that shows the inverse relation between number of satellites used and three different accuracy measures:


In two of the three tests, the number of satellites used was restricted by using only satellites with good signal-to-noise ratios (min CNO 25 and 28).
Using more satellites improves all three accuracy measures similarly, with smaller improvements as the number of satellites increases.

The hAcc estimates seem a bit optimistic. In the stationary test with the highest number of satellites (no minimum CNO set), the hAcc values were around 0.5 meters, but the observed variations were in the 1-2 m range (relative to the center):

The observed point-to-point differences are a lot less than hAcc, though, at 3 cm in x and 5 cm in y direction.

- Notice how it bottoms out at 18 satellites used. ;) ;)

- Filtering by C/N0 had a short lifespan in Motions. It was overall a bad idea. Not recommending it to anyone.

- Cold stationary tests are always a bad idea. The dynamic filter needs movement to sort itself out.

- Anyway, it's HDOP they want. So it's HDOP they'll get if everyone is cool with it.

Select to expand quote

JulienLe said..>>
- Anyway, it's HDOP they want. So it's HDOP they'll get if everyone is cool with it.

So who is "they"? It's certainly not the GPSTC, we think it's irrelevant.
But if you feel the need to cater to people that think it means something, go for it. As you say, it doesn't make the file much bigger. And will remove the discrepancies between the way different programs handle it.