The number of sats used is pretty irrelevant for comparison purposes. What's more important is the strength of the signal used. The best indication of this from the limited data recorded by the GPS units is the HDOP, the figure in the left column. With the UBlox it is 1.25, the GW52 has 0.8. HDOP and VDOP all influence SDOP/Sacc and are more important than number of sats used.

Select to expand quote

sailquik said..

For the same reason stated above, we don't actually 'know' that the method used is different. It actually seems logically most likely that it is based on the same first principles, and is therefore either the same , or very similar. In fact, I think, for all practical purposes, even if there is a slight difference in the way they go about it, it is reasonably comparable.

I can think of one way it might be possible to do a direct comparison. That would be using the same method that Dr. Chalko used to validate the error accuray for the Locosys GW devices. But that would require Dr Chalko giving us access to his data and methods, and he has already said that he can't do this for the reasons stated above.

Another way might be to examine the software code (firmware) in the devices, but I would think that would be encrypted, or locked down in some way.

Actually, if you compare Locosys SDoP to u-blox sAcc numbers, it is quite obvious that there are some fundamental differences. Specifically, Locosys accuracy estimates are about 5-20-fold lower than u-blox estimates when the GPS is stationary (or almost so). Here's a graph (speed on top, SDoP/sAcc at the bottom):


Locosys GW-60 is red, u-blox 8 is blue. The Locosys chip appears to use a filter where it sets near-stationary speeds to zero, or keeps them near 0; the u-blox does not.

The error characteristics of u-blox data also look different from Locosys data. In Locosys data, poor data quality can lead to artificially high speeds for several seconds (for examples, check the posts at boardsurfr.blogspot.com/search/label/artifacts). In u-blox data, artifacts that extend over several seconds can also be seen, but they almost always show a drop in speed. Locosys error estimates also often show a sinus-wave behavior that is not present in u-blox data.

It is quite likely that both companies use similar principles in determining their accuracy estimates, using residuals, S/N ratios, and so on. But they are definitely computing it differently, and I have yet to see a statement from either company about what the mathematical or statistical definition of their numbers is. Even GPSResults displays different numbers in the "+-" columns - sometimes using raw data provided by the data files, sometimes using plain error averages, sometimes using two standard deviations calculated by Gaussian error propagation.

It is quite possible that Locosys SDoP and u-blox sAcc are calculated with the intent to give the same number. But it's also possible that one company's number describes a 90% probability range, and the other company's number a 99% probability range. Basically, we don't know if we are comparing apples and oranges - we may be comparing lemons and grapefruits, and should not be surprised if one is bigger.

Select to expand quote

Roo said..
The number of sats used is pretty irrelevant for comparison purposes. What's more important is the strength of the signal used. The best indication of this from the limited data recorded by the GPS units is the HDOP, the figure in the left column. With the UBlox it is 1.25, the GW52 has 0.8. HDOP and VDOP all influence SDOP/Sacc and are more important than number of sats used.

A bold statement. HDOP is a measurement of horizontal position accuracy, and therefore quite loosely related to Doppler speed measurements. Here's an example from GW-60 data where a better HDoP of 0.8 has a threefold worse speed accuracy estimate than an HDoP of 1.0:

Wow, as usual barking up the wrong tree! Decrepit was comparing two gps at the same time on same day. HDOP is the key, as I said it along with VDOP give an indication of accuracy of the GPS signal without recourse to signal strength numbers.

Select to expand quote

Roo said..
What's more important is the strength of the signal used. The best indication of this from the limited data recorded by the GPS units is the HDOP

Just for the record, this statement is blatantly wrong. The HDOP and VDOP values only depend on the geometry of the satellites used in the solution, and have nothing to do with signal strength. You don't have to take my word for it:

"DOP can be computed without the need for any measurements -- only the satellite positions are required (from an appropriate ephemeris) and an approximate receiver position."
This is from "Principles of Satellite Positioning", web.archive.org/web/20141122153439/http://www.gmat.unsw.edu.au/snap/gps/gps_survey/chap1/149.htm

Or you could check the article on Wikipedia that explains how the "classical" DOP values (HDOP, VDOP, PDOP, TDOP) are calculated - en.wikipedia.org/wiki/Dilution_of_precision(navigation)#Computation_of_DOP_Values

A bit simplified, HDOP tells you a little bit about how well distributed the satellites were that the GPS tracked. That's it. And that's why HDOP values in a track are usually pretty constant, with only small changes, and therefore of very limited use for filtering.

OK, I must admit to a little confusion here.
GW52, 11 sats and HDop of 0.8. Ublox module 17 sats and HDop of 1.25. With the antennas about a centimeter apart.

So if HDop is dependent only on satellite geometry, how come more sats aren't better?

Select to expand quote

decrepit said..
So if HDop is dependent only on satellite geometry, how come more sats aren't better?

You can see HDOP as a measurement about how close the satellites are together. If you have 4 satellites close together right above your head, the HDOP will be higher than if they are nicely spread out to the 4 corners.

The Locosys units seem to use only the American GPS system; u-blox units also use the Russian GLONASS a lot. The GLONASS satellites are positioned differently, giving better accuracy than GPS far north and far south, but less accuracy at low latitudes. So (I guess) that adding the GLONASS satellites introduces a position bias that's unfavorable in Australia (and the US), and leads to higher HDOP/PDOP values.

But note that the HDOP/PDOP measures are old accuracy measures. Their usefulness is somewhat limited to catching "very bad" situations where the GPS can track only very few satellites, and/or the satellites are bunched together. With a clear view of the sky as we usually have when windsurfing, it is indeed only determined by the geometric arrangement of the satellites. In that case, having a (slightly) higher HDOP does not mean lower accuracy. There are several reasons for that; one is that HDOP uses a least-squares algorithm that weighs all satellites evenly, while a smart positioning algorithm probably will weight contributions by signal quality. The ublox units give better accuracy estimates where signal-to-noise ratios certainly come into play; the relevant one is hAcc, "Horizontal Accuracy Estimate", at offset 40 in the NAV-PVT records. You can see the values in u-center when you watch a connected dongle or play a .ubx file.

The ublox units can also save detailed information about satellites, including S/N ratios (for the Pi logger, check the settings file for a flag you can set). Unfortunately, the Locosys binary formats do not have this information. However, if you still have a GT-31 around, you can set it to record NMEA files, which contain satellite info if you have the right sentences selected.

Thanks Peter,

Bugger!!!! Organised it all to fit in the Dolphin box, so I can do an on the water test, and now it's producing rubbish again.
To much handling must have upset something.

I thought I had made a good fit into the box, but the usb plug into the converter, and the Pi are jammed up against each other.



Would be OK except for the plugs and cables!

That could be the cause, or maybe I've static fried something. I've taken it out of the box and spread every thing out again, but still rubbish.

Think I'll sleep on this, before deciding what to do next.

Looks like the bluetooth module will be here soon, so I may just have a play with that, It should show where the problem is, module or converter.

Select to expand quote

decrepit said..
Looks like the bluetooth module will be here soon, so I may just have a play with that, It should show where the problem is, module or converter.

You may also want to order an Openlog; I find it a bit easier than the bluetooth, since you can configure it with a text file, and pop the card into the computer to get the file. There are huge price differences, I have seen anything from $5 to $35. The place I ordered from delivers in a couple of days for $9 per chip, but that's in the US.

Getting another GPS chip may also be a good idea. I've gotten very good results with the BEITIAN 280 and 880 chips, they both seem to give better results than the GW-60. The 880 has a compass and costs a bit more; the 280 costs $21 here, which is about half of the Drotek chip. It may be a while before I get that one, it's on the way from France.

I've already ordered a US m8n v5 module, but I think you're right I'll get an openlog as well.

Ok order placed with banggood AU$11.47.

So have you tried a higher baud rate and 10hz with this? It looks like it can handle it.

Select to expand quote

decrepit said..
So have you tried a higher baud rate and 10hz with this? It looks like it can handle it.

Yes, I have tried 10 Hz, it worked without a problem, even when the GPS also spits out SVINFO sentences, which increase the data about 3-4-fold.

Always good to learn new things and keep an open mind. So today I went HDOP hunting, to see if there are other influences on it (I never trust Wikipedia!). As I expected there's more to it that sat position, just as I had assumed. Situation was GW60 at 5hz and UBlox at 10 hz, Same location same number of sats, 7 , but different HDOP; UBlox was 1.33 and GW60 was 1.0 to 1.2. Exactly the same sats were used for the solution but they had different HDOP values. The UBlox was located on the upper arm and GW60 on the wrist on the same arm. Looked at three different runs where the same sats were used and the result was the same each time. Conclusion: never believe Wikipedia...written by idiots for idiots, probably why you can't use it as a citation source at a lot of universities!

Select to expand quote

Roo said..
, The UBlox was located on the upper arm and GW60 on the wrist on the same arm.

Surely the different orientation due to the different positions would have a bearing on the HDOP

Select to expand quote

decrepit said..
Looks like the bluetooth module will be here soon, so I may just have a play with that, It should show where the problem is, module or converter.

HMMMM,

Looks like another seniors moment!!!!!!!!!!!!!!!!!!!!!!!
What arrived today was another USB tester!
And checking the orders, yes instead of a USB tester and a blue tooth module, there's two different testers.
How could I do that??????????????????

Now, how is brain transplant technology coming along?

So I guess, I'll wait for the authentic US V5 module and open logger to arrive, before I do much else.
Unless of course I get bored and have another go at re-soldering the converter to module connections.

Select to expand quote

decrepit said..

decrepit said..
Looks like the bluetooth module will be here soon, so I may just have a play with that, It should show where the problem is, module or converter.

HMMMM,

Looks like another seniors moment!!!!!!!!!!!!!!!!!!!!!!!
What arrived today was another USB tester!
And checking the orders, yes instead of a USB tester and a blue tooth module, there's two different testers.
How could I do that??????????????????

Now, how is brain transplant technology coming along?

So I guess, I'll wait for the authentic US V5 module and open logger to arrive, before I do much else.
Unless of course I get bored and have another go at re-soldering the converter to module connections.

I have had seconds thoughts on the bluetooth setup. Yes, it's very easy to hook up and configure, but otherwise limited. You always have to use it with a phone, and you have to remember to press the "Start logging" button on the phone. With Openlog, you don't need the phone if you just want to log the session (that's often all I want), and the assembly can be a bit smaller.

Select to expand quote

Roo said..
Always good to learn new things and keep an open mind. So today I went HDOP hunting, to see if there are other influences on it (I never trust Wikipedia!). As I expected there's more to it that sat position, just as I had assumed. Situation was GW60 at 5hz and UBlox at 10 hz, Same location same number of sats, 7 , but different HDOP; UBlox was 1.33 and GW60 was 1.0 to 1.2. Exactly the same sats were used for the solution but they had different HDOP values. The UBlox was located on the upper arm and GW60 on the wrist on the same arm. Looked at three different runs where the same sats were used and the result was the same each time. Conclusion: never believe Wikipedia...written by idiots for idiots, probably why you can't use it as a citation source at a lot of universities!

"Wikipedia...written by idiots for idiots". Leave it to Roo to insult everyone who used or contributed to Wikipedia.

The citation "only the satellite positions are required" was not from Wikipedia, but rather from an University web site. It is from a text book by a Professor Chris Rizos from UNSW Sydney. But of course, Roo thinks he knows better than someone who teaches and writes text books about GNSS systems.

Name calling usually falls back on those who do it. Roo has proven that quite nicely.

Select to expand quote

decrepit said..
GW52, 11 sats and HDop of 0.8. Ublox module 17 sats and HDop of 1.25. With the antennas about a centimeter apart.

Mike, I discovered another reason why the HDoP you saw was higher. It's because the number you are looking at for the u-blox chip is probably not HDOP! In all likelihood, the number that GPSResults shows in the HDoP column is PDOP, not HDOP. PDOP includes both horizontal (HDOP) and vertical (VDOP) components. VDOP is generally much higher than HDOP, so PDOP is higher than HDOP.

Apparently, GPSResults silently used PDOP values in the HDOP column if HDOP values are not present. Hence the confusion.

I am saying "probably" because the logger program never does anything about the NAV-DOP messages, which are the only ublox messages that contain HDOP. It never enables or disables them, so if you enabled them manually, your files may contain them. You can check that by playing files using the "Player" menu in u-center.

My previous explanation that adding the GLONASS satellites to the GPS satellites might increase HDOP because of biased satellite orientation was most likely incorrect. When I look at the HDOP/VDOP/PDOP numbers in u-center, I get lower HDOP/PDOP numbers when I enable GLONASS than when only GPS satellites are enabled.

This entire discussion about HDOP values is somewhat pointless, since "GPS/GNSS users should have been ignoring them for awhile now" (cited from http://www.resourcesupplyllc.com/what-is-pdop-and-why-its-obsolete/).

Select to expand quote

boardsurfr said..

Roo said..
Always good to learn new things and keep an open mind. So today I went HDOP hunting, to see if there are other influences on it (I never trust Wikipedia!). As I expected there's more to it that sat position, just as I had assumed. Situation was GW60 at 5hz and UBlox at 10 hz, Same location same number of sats, 7 , but different HDOP; UBlox was 1.33 and GW60 was 1.0 to 1.2. Exactly the same sats were used for the solution but they had different HDOP values. The UBlox was located on the upper arm and GW60 on the wrist on the same arm. Looked at three different runs where the same sats were used and the result was the same each time. Conclusion: never believe Wikipedia...written by idiots for idiots, probably why you can't use it as a citation source at a lot of universities!

"Wikipedia...written by idiots for idiots". Leave it to Roo to insult everyone who used or contributed to Wikipedia.

The citation "only the satellite positions are required" was not from Wikipedia, but rather from an University web site. It is from a text book by a Professor Chris Rizos from UNSW Sydney. But of course, Roo thinks he knows better than someone who teaches and writes text books about GNSS systems.

Name calling usually falls back on those who do it. Roo has proven that quite nicely.

I defer to the Wikepedia supporters. "Never argue with an idiot. They will only bring you down to their level and beat you with experience." Now to get some popcorn out and enjoy the responses! Making speedsailing great again in the USA.

Select to expand quote

Roo said..
I defer to the Wikepedia supporters. "Never argue with an idiot. They will only bring you down to their level and beat you with experience." Now to get some popcorn out and enjoy the responses! Making speedsailing great again in the USA.

You are absolutely correct, Roo, I should not have argued with you. Your slogan shows who you try to imitate.

Select to expand quote

boardsurfr said..
Mike, I discovered another reason why the HDoP you saw was higher. It's because the number you are looking at for the u-blox chip is probably not HDOP! In all likelihood, the number that GPSResults shows in the HDoP column is PDOP, not HDOP. PDOP includes both horizontal (HDOP) and vertical (VDOP) components. VDOP is generally much higher than HDOP, so PDOP is higher than HDOP.

Apparently, GPSResults silently used PDOP values in the HDOP column if HDOP values are not present. Hence the confusion.

I am saying "probably" because the logger program never does anything about the NAV-DOP messages, which are the only ublox messages that contain HDOP. It never enables or disables them, so if you enabled them manually, your files may contain them. You can check that by playing files using the "Player" menu in u-center.

My previous explanation that adding the GLONASS satellites to the GPS satellites might increase HDOP because of biased satellite orientation was most likely incorrect. When I look at the HDOP/VDOP/PDOP numbers in u-center, I get lower HDOP/PDOP numbers when I enable GLONASS than when only GPS satellites are enabled.

This entire discussion about HDOP values is somewhat pointless, since "GPS/GNSS users should have been ignoring them for awhile now" (cited from http://www.resourcesupplyllc.com/what-is-pdop-and-why-its-obsolete/).

Thanks Peter that would explain it, Next time I'm in windows, I'll try to remember to play that data and see what's on it

I've done a few tests and saw a surprisingly large interference effect from having bluetooth turned on - here's a picture to illustrate:



It's a stationary test, speed on top, sAcc on the bottom. The left side is with bluetooth turned off, right side turned on. Pretty big effect. More details at http://boardsurfr.blogspot.com/2018/06/interference-and-data-overload.html. I'll focus on Openlog prototypes.
RF interference can also be an issue with the Pi. Turning off WiFi and HDMI in the script might help, especially when testing near Wifi networks (at home or driving/biking).

Very interesting Peter, May be there needs to be so,e shielding, if we use blue tooth. I guess it's getting into the antenna, but could also be the first amp in the chip

Select to expand quote

decrepit said..
Very interesting Peter, May be there needs to be so,e shielding, if we use blue tooth. I guess it's getting into the antenna, but could also be the first amp in the chip

For the Pi, yes. I don't see a reason to use Bluetooth. For feedback on the water, the built-in GPS is good enough. For GPSTC postings, looking at the data from the card at home is fine (although support for .ubx files on ka72.com would be nice). I have two PCB boards and a battery between the HC-6 antenna and the GPS; one of the PCB boards is covered with aluminum foil. That's apparently not enough.

I saw lots of references to RF interference on the drone forums; they sometimes use large (8 x 8 cm) ground plates to reduce it. RF interference also (partly) killed the plans to develop a Flysight for windsurfing. The Beitian GPS units are tightly packed, with two metal cages and just a very short cable visible between the antenna and the chip. I bet that's to minimize interference.

The stationary tests might even underestimate the effect of RF interference, since speed cannot go below 0. In driving tests, the ublox units had a strong tendency towards lower speed whenever there were artifacts; that was most pronounced when I did not let the HC-06 connect to the phone. On the other hand, all the surfaces in the van might make the problem worse, compared to having things on the helmet or upper arm while windsurfing. The windsurfing tests did look better than the driving tests. It will be interesting to see if I get even better results with Openlog-only units. Monday should be windy enough to test on the water .

Select to expand quote

boardsurfr said..
Mike, I discovered another reason why the HDoP you saw was higher. It's because the number you are looking at for the u-blox chip is probably not HDOP! In all likelihood, the number that GPSResults shows in the HDoP column is PDOP, not HDOP. PDOP includes both horizontal (HDOP) and vertical (VDOP) components. VDOP is generally much higher than HDOP, so PDOP is higher than HDOP.

Apparently, GPSResults silently used PDOP values in the HDOP column if HDOP values are not present. Hence the confusion.

I am saying "probably" because the logger program never does anything about the NAV-DOP messages, which are the only ublox messages that contain HDOP. It never enables or disables them, so if you enabled them manually, your files may contain them. You can check that by playing files using the "Player" menu in u-center.

My previous explanation that adding the GLONASS satellites to the GPS satellites might increase HDOP because of biased satellite orientation was most likely incorrect. When I look at the HDOP/VDOP/PDOP numbers in u-center, I get lower HDOP/PDOP numbers when I enable GLONASS than when only GPS satellites are enabled.

This entire discussion about HDOP values is somewhat pointless, since "GPS/GNSS users should have been ignoring them for awhile now" (cited from http://www.resourcesupplyllc.com/what-is-pdop-and-why-its-obsolete/).

Yep, was just in windows downloading the GW52 data, so remembered to play a module file, and you are correct, there's no HDOP only PDOP

Good luck with testing the logger on the water,

I just got the Drotek NEO-M8N module. It's nice that it has the USB port, makes it easier to see in u-center. During inside and balcony tests, the behavior is similar to the best other modules tested so far (first fix within minutes, 19 sats on the balcony in < 15 minutes). But the configuration behavior is weird and different. I can save and load settings to and from BBR and Flash. But when I unplug the module and plug it back in, it starts sending NMEA messages again, even if I turned them off individually and in the port settings. But the information is still in the BBR - when I reload the settings, NMEA messages are turned off.

It seems that at startup, the module uses a mix of default settings and settings from BBR and/or Flash.

I don't think this will be a problem when the module is used via USB, as I plan to do, since the logger program turns NMEA messages off explicitly. But it would be an issue with Openlog, since the log file would contain both UBX and NMEA messages; data overflow and loss/corruption could also be an issue due to the extra NMEA data. It might also be a problem with use through a serial connection if the baud rate resets to the default 9600 baud (but this is fixable with auto-bauding).

Select to expand quote

boardsurfr said..
I just got the Drotek NEO-M8N module. It's nice that it has the USB port, makes it easier to see in u-center. During inside and balcony tests, the behavior is similar to the best other modules tested so far (first fix within minutes, 19 sats on the balcony in < 15 minutes). But the configuration behavior is weird and different. I can save and load settings to and from BBR and Flash. But when I unplug the module and plug it back in, it starts sending NMEA messages again, even if I turned them off individually and in the port settings. But the information is still in the BBR - when I reload the settings, NMEA messages are turned off.

It seems that at startup, the module uses a mix of default settings and settings from BBR and/or Flash.

I don't think this will be a problem when the module is used via USB, as I plan to do, since the logger program turns NMEA messages off explicitly. But it would be an issue with Openlog, since the log file would contain both UBX and NMEA messages; data overflow and loss/corruption could also be an issue due to the extra NMEA data. It might also be a problem with use through a serial connection if the baud rate resets to the default 9600 baud (but this is fixable with auto-bauding).

This shouldn't be the case, as the M8N module is going to be the same, no matter who embeds it into their product. The rest of the support circuitry is the analog stuff, and shouldn't affect the way it stores or uses the config data.

Are you sure you are configuring it correct? Specifically do you remember that the GPS sentences can be configured differently based on the interface, i.e. you can send NMEA out one port and UBX out another, and a combination out a different one again?

Select to expand quote

boardsurfr said..

decrepit said..
GW52, 11 sats and HDop of 0.8. Ublox module 17 sats and HDop of 1.25. With the antennas about a centimeter apart.

Mike, I discovered another reason why the HDoP you saw was higher. It's because the number you are looking at for the u-blox chip is probably not HDOP! In all likelihood, the number that GPSResults shows in the HDoP column is PDOP, not HDOP. PDOP includes both horizontal (HDOP) and vertical (VDOP) components. VDOP is generally much higher than HDOP, so PDOP is higher than HDOP.

Apparently, GPSResults silently used PDOP values in the HDOP column if HDOP values are not present. Hence the confusion.

I am saying "probably" because the logger program never does anything about the NAV-DOP messages, which are the only ublox messages that contain HDOP. It never enables or disables them, so if you enabled them manually, your files may contain them. You can check that by playing files using the "Player" menu in u-center.

My previous explanation that adding the GLONASS satellites to the GPS satellites might increase HDOP because of biased satellite orientation was most likely incorrect. When I look at the HDOP/VDOP/PDOP numbers in u-center, I get lower HDOP/PDOP numbers when I enable GLONASS than when only GPS satellites are enabled.

This entire discussion about HDOP values is somewhat pointless, since "GPS/GNSS users should have been ignoring them for awhile now" (cited from http://www.resourcesupplyllc.com/what-is-pdop-and-why-its-obsolete/).

Finally got a chance to sit down and analyse some tracks for HDOP. Been busy all week at graduation ceremonies for my son, he did multiple degrees. Graduated as a mechanical engineer, and also honors, top of his class; perfect 4.0 GPA in every subject for 4 years of university. Thankfully he gets his intelligence from his mother as I'm an uneducated idiot with questionable politics according to our resident German expert boardsurfr!

GPS Results used the HDOP from my UBlox 8 just as Manfred designed it to do, certainly not PDOP or PaccH. I must have one of the hokey bluetooth U-Blox 8 GPS units, seems to do this every time...not sure what I'm doing wrong. Each time I ran the .ubx file through U-center I get the same pointless result.

Roo, my ubx file had no HDOP values in it only PDOP as Peter surmised. I'm sure if there is HDOP in the file that's what GPSResults uses. But try removing the HDOP and see what happens.