Maybe Google maps is out being 10 metres to far south and the GW is the more accurate?

Two days later, it's still only recording NAV-PVT sentences.
(I did a quick check, NAV-PVT data accumulates at 30kb/min, with the NMEA data in there it's 2.5mb/min)

So I've shaved some plastic off the side of the battery so it fits the enclosure, cut some rough holes for the on/off switch, battery charge usb and mini SD card.
It just fits in a paqua midi, I hadn't realised how thick it is.
It puts pressure on the paqua plastic, so I'll cover the holes and lid seal with tape just in case.



So it's ready to go windsurfing.

The paqua on my helmet is a bit squashed, so I'll have to leave the GW52 in there and wear the logger on my arm.

What looks like a red seal around the top, is only a spacer to stop the lid from pressing on the antenna, it doesn't quite fit otherwise.

The battery is over kill, it's 2,200 mah, so in theory good for over 40hrs. If I can find a thinner enclosure a smaller battery will be needed.

Had it's first very short blast today, conditions just got too wild for me to want to keep going, hopefully a longer test next time. I had the GW52 on my head, the logger on my upper right arm and the watch on my right wrist.

Here's GPSResults 2s view of watch, GW52 and U-blox/openlogger



So Mainly the logger numbers are in between the GWs, but the accuracy is mainly better.

Here's the max, 2s and 10s top 5 results.


I was a bit concerned about the smaller ground plane now it's in the enclosure, but the logger's accuracy is better than the other two most of the time.

Nice numbers, Mike. You threw me off a bit by posting the max speed. I went straight to the accuracy column and wondered why it was so bad, before realizing it was for single points. I usually ignore max speed, since it tends to have an "extra" error of 0.5-1 knots.

The error numbers for the ublox logger are much more consistent than for the Locosys units (even ignoring the low speed numbers). I have noticed the same thing often: the Locosys error estimates vary a lot more, both over medium and short time ranges, when the change in satellite reception should be minimal. They often have a "seesaw" pattern in the sub-second to second range that makes no sense. On the other hand, the ublox accuracy values sometimes seem to go up a bit slowly when the reception suddenly changes, for example under bridges in test drives.

Select to expand quote

boardsurfr said..
Nice numbers, Mike. You threw me off a bit by posting the max speed. I went straight to the accuracy column and wondered why it was so bad, before realizing it was for single points. I usually ignore max speed, since it tends to have an "extra" error of 0.5-1 knots.

The error numbers for the ublox logger are much more consistent than for the Locosys units (even ignoring the low speed numbers). I have noticed the same thing often: the Locosys error estimates vary a lot more, both over medium and short time ranges, when the change in satellite reception should be minimal. They often have a "seesaw" pattern in the sub-second to second range that makes no sense. On the other hand, the ublox accuracy values sometimes seem to go up a bit slowly when the reception suddenly changes, for example under bridges in test drives.

Yep, I do too, must be getting tired, don't know why I did that.

I haven't had an under bridge experience yet, make you wonder just how valid the accuracy figures are.

Still with results so close from 3 separate units, the accuracy can't be too bad.

Mike I don't know whether there is any relevance, but the Logger appears to be to have all it's peaks a good 18secs behind that of the Lyco's (Check Time column)

Select to expand quote

elmo said..
Mike I don't know whether there is any relevance, but the Logger appears to be to have all it's peaks a good 18secs behind that of the Lyco's (Check Time column)

Yep, that's correct Alby, it's got something to do with almanacs or leap seconds or something. I've noticed this on other comparisons between different GNNS systems. It may even have something to do with the logger using both the American and Russian systems, and the locosys units only using American.
I'm sure it's not a problem.

Some devices show the actual UTC time and some record the 'GPS' time which is 18 seconds offset now due to the accumulation of leap seconds since the GPS system was started up.

"GPS, Global Positioning System time, is the atomic time scale implemented by the atomic clocks in the GPS ground control stations and the GPS satellites themselves. GPS time was zero at 0h 6-Jan-1980 and since it is not perturbed by leap seconds GPS is now ahead of UTC by 18 seconds."

So leap seconds are to compensate for the inexact number of days in the Earth's yearly rotation around the sun, or is it the inexact number of hours in a day?
Whatever, the GPS system doesn't need to bother with that stuff.

Select to expand quote

elmo said..
Mike I don't know whether there is any relevance, but the Logger appears to be to have all it's peaks a good 18secs behind that of the Lyco's (Check Time column)

That's a bug in GPSResults. The u-blox NAV-PVT records give the correct time, but older units (10+ years ago) used different sentences, which may have recorded things differently.

Select to expand quote

decrepit said..
I haven't had an under bridge experience yet, make you wonder just how valid the accuracy figures are.

Accuracy estimates are always estimates, and never "accurate". But there are definitely good enough for our purpose.

In theory, the software filters could be improved by taken into account the specific characteristics, but there's no real need for that - it would not affect the vast majority of speedsurfing tracks at all.

Peter, I've been trying to summarise this thread, and got interested in your beitian 220/880 chip, it's a lot cheaper than the genuine neo8m that I bought. It looks to have a smaller antenna though, and it doesn't seem to have flash only a back up battery.
Would you recommend this for use in a logger?
It's also smaller, and would make fitting into a small enclosure easier.

I was pretty impressed with the results I got from the Beitian chips, even the 220. They have Flash, and I have never had any problem with the chips "forgetting" the settings. The 280 and 880 have larger antennas than the 220, but the antennas are a bit thinner than those of other modules. The 880 has a compass, which makes sense for drones, not for windsurfing, and is a bit more expensive. So I'd stick with the 280. IIRC, the larger antenna gets slightly better sAcc values than the smaller antenna in the 220. Size for the 880 is about 28x28x10 mm.

I think one reason the Beitian chips work so well is that the shielding and tight form factor. There are two metal boxes on the 880, one under the antenna and one around the GPS chip. The visible cable between the antenna and GPS is much shorter than in the "NEO-M8" modules I've seen, which can't hurt.

Thanks Peter, there seems to be a great variation in the 280 cost, from US$11 to US$25, but even the $25 is about half what I paid for the Neo.

I had another sail today, I managed to stay on the water a bit longer this time, so there's a few more comparisons.
Same set up, GW52 on head, logger on right arm.




so similar results, the logger has more even and mainly better accuracy.

And a closer look at the alphas. The divergence between trackpoints and doppler position at the end of the alpha is generally smaller in the logger results. Here's one of the worst examples.





The grid is 1meter, so the logger divergence is only a centimeter or so, and the GW52 is a bit over 2 meters.

The reason could be the straight green line at the bottom, this is the number of satellites being used. The GW52 is using 8, whereas the logger is using 20, so the doppler calculation of angle is probably more accurate.

I think I need to look at this a bit closer.

Select to expand quote

decrepit said....



The grid is 1meter, so the logger divergence is only a centimeter or so, and the GW52 is a bit over 2 meters.

The reason could be the straight green line at the bottom, this is the number of satellites being used. The GW52 is using 8, whereas the logger is using 20, so the doppler calculation of angle is probably more accurate.

Mike you really seem to be getting somewhere with this.
Cm accuracy on alphas ..really promising

The data look good, and the positional accuracy of the u-blox units seems to be better than for the Locosys units. But I doubt that the cm accuracy in Mike's example is typical. If you look at his driving example from July 19, the typical position error is still in the meter range. Nevertheless, any improvement in accuracy would be great, especially for alphas where some programs use the position data to determine the end distances.

Keep up the good work guys a lot of us technically inept persons are looking on in interest

Select to expand quote

boardsurfr said..
>>>> But I doubt that the cm accuracy in Mike's example is typical. If you look at his driving example from July 19, the typical position error is still in the meter range. Nevertheless, any improvement in accuracy would be great, especially for alphas where some programs use the position data to determine the end distances.

Correct, I just picked that one to show the difference between the two. There is one that has similar amount of divergence but in the opposite direction. However for all the rest I've checked, the logger is noticeably better than the GW52

In case anybody is interested we just launched the simpleRTK2B, the first low cost evaluation board for the ZED-F9P GNSS module, compatible with Arduino and Pixhawk autopilots.
If you want to see all the details you can go here: www.kickstarter.com/projects/simplertk2b/simplertk2b-the-first-multiband-rtk-shield-based-o

Select to expand quote

Ardusimple said..
In case anybody is interested we just launched the simpleRTK2B, the first low cost evaluation board for the ZED-F9P GNSS module, compatible with Arduino and Pixhawk autopilots.
If you want to see all the details you can go here: www.kickstarter.com/projects/simplertk2b/simplertk2b-the-first-multiband-rtk-shield-based-o

Here's how it looks like:

That is a very interesting product but unfortunately, I think it is still too expensive for our uses.

I do think that RTK could be part of our future for accurate speed measurement, but it will need to get to about 1/4 of the current cost. Hopefully, such capabilities will eventually be able to be integrated into smartphones and other compact consumer electronic devices.

Does this ublox high precision module give more accurate velocity (Doppler) measurement than the non high precision models?

The biggest difference between the ZED-F9P (in RTK mode) and regular GNSS solutions is in the position accuracy, from 2m to 1cm (1sigma).
The tests we performed don't show big changes in speed accuracy, the biggest difference is when the speed is close to 0.

Multiband GNSS improves significantly the quality of the signals in urban/dirty environment wrt regular GNSS, but I understand this is not the case in this forum :)

Another interesting application of RTK GNSS solutions is the moving base. For example, by placing two units in a board, you can get extremely accurate headings.

Select to expand quote

decrepit said..
I had another sail today, I managed to stay on the water a bit longer this time, so there's a few more comparisons.
Same set up, GW52 on head, logger on right arm.




so similar results, the logger has more even and mainly better accuracy.

And a closer look at the alphas. The divergence between trackpoints and doppler position at the end of the alpha is generally smaller in the logger results. Here's one of the worst examples.





The grid is 1meter, so the logger divergence is only a centimeter or so, and the GW52 is a bit over 2 meters.

The reason could be the straight green line at the bottom, this is the number of satellites being used. The GW52 is using 8, whereas the logger is using 20, so the doppler calculation of angle is probably more accurate.

I think I need to look at this a bit closer.

Re. Alphas:
This is interesting and indicates a much better position accuracy. If this is a general pattern, it could be be explained by the much larger number of satellites being used in the fix, as indicated in the bottom speed graph by the green lines (number of sats).
Are the HDOP numbers much bifferent between the two GPS at this moment?

If this is a pattern, it would be a big advance in Alpha accuracy.

No breakthrough.

After looking at the top 5 Alphas closely in that session, using the 1m Grid on GPS-Results, the difference netween the Doppler COG derived end point and the Positional point in each file is roughly the same. (around a meter, or slightly more). What looks like a better match on a couple of them is just that the lines follow the same path a bit closer and is therefore overlaid. But when I compare the end point of the Doppler and that of the Positional, they are separated by about the same actual distance. it's just more in line.

So my preliminary look does not support my theory that the position may be more accurate in the track using 20-24 satellites that that using 8-9 satellites.

It is something I will continue to monitor though. More samples may indeed show a difference.

Of course, the use of RTK, as in a few posts earlier, with cm level (or at least decimeter) positional accuracy would surely lead to far more accurate Alphas. Something for the future I hope.