I have started to see if it is possible to make a highly accurate GPS for the GPSTC using a "plug-and-play" strategy, using cables to put a few components together. It's currently centered around Sparkfun parts: u-blox chips with "Quiic" connectors, and the Openlog Artemis (OLA). Since at least one person who posts here on a regular basis has expressed interest, I've started to write about it on my blog. The first part at boardsurfr.blogspot.com/2021/03/the-olapap-gps.html mainly describes the parts used and a bit of initial conclusions, but I plan to add results and perhaps more detailed instructions over time.

Of course, the "OLA Plug&Play GPS" is not approved for GPSTC posting, and might never get approved for one reason or another, so this might be another dead end.

Couldn't get more simple than that!
All it needs now is a nice little enclosure

This is a fantastic bit of research and application Peter.

So there are four of us so far and I know of at least one other. It would be interesting to see how many people would be interested in making their own GPS unit.

Yep, interested, not skilled but interested.

A great initiative Peter, I think you're onto something.
im interested and skill limited too. No soldering definitely a plus

I've put a brief summary of the results I got with the M9 board with a chip antenna up at boardsurfr.blogspot.com/2021/03/olapap-why-we-need-ceramic-antennas.html As the post explains, the chip antenna appears to be not good enough for speedsurfing use.

Monopole antennas are only as good as their ground plane area.

M8 to M9 isn't the revolution previous upgrades were. M10 neither. I'm holding back for something else.

I've got a neo-m9n qwiic board coming but haven't found a quad band Ariel I want to use yet...
Currently playing with neo-m8n with wifi 2.4ghz hoping Andrew can later get the device to send its data to a Garmin watch....
Very interested in this

Select to expand quote

TRIMMER said.. I've got a neo-m9n qwiic board coming but haven't found a quad band Ariel I want to use yet...
Currently playing with neo-m8n with wifi 2.4ghz hoping Andrew can later get the device to send its data to a Garmin watch....
Very interested in this

Please let me know when you do, I have an artemis openlog on order, but antenna's for the M9 look tricky

Select to expand quote

decrepit said..

TRIMMER said.. I've got a neo-m9n qwiic board coming but haven't found a quad band Ariel I want to use yet...
Currently playing with neo-m8n with wifi 2.4ghz hoping Andrew can later get the device to send its data to a Garmin watch....
Very interested in this

Please let me know when you do, I have an artemis openlog on order, but antenna's for the M9 look tricky

will do

So after some advise from Decrepit and Boardsurf, I have decided to go ahead and build the cheapest logger option (BN880 + Sparkfun Openlog)
I have ordered the parts and will report back on my progress. I plan to keep a record of the number of hours it takes me to get from receiving the parts to being able to upload a track to KA72. I have no experience with GPS's or loggers but have assembled various electronic kits over the years.

You guys continually amaze me. I still have trouble trying to remember which button to press to turn my logger on and off with... and it only has ONE button.

Select to expand quote

TRIMMER said..
I've got a neo-m9n qwiic board coming but haven't found a quad band Ariel I want to use yet...

Why do you need a quad band?

Select to expand quote

boardsurfr said..

TRIMMER said..
I've got a neo-m9n qwiic board coming but haven't found a quad band Ariel I want to use yet...

Why do you need a quad band?

I don't, but chip is capable of over 100 channels and can use 4 simultaneous systems\bands to populate data.. why wouldn't you?

Select to expand quote

TRIMMER said..

boardsurfr said..

TRIMMER said..
I've got a neo-m9n qwiic board coming but haven't found a quad band Ariel I want to use yet...

Why do you need a quad band?

I don't, but chip is capable of over 100 channels and can use 4 simultaneous systems\bands to populate data.. why wouldn't you?

Because you do not need a "quad band antenna". Or alternative, because typical ceramic antennas work well enough as "quad band" with respect to receiving GPS, Glonass, Galileo, and BeiDou.

Primary (L1) band frequencies are 1575 MHz for GPS and Galileo, around 1600 for Glonass, and 1561 for BeiDou (from novatel.com/support/known-solutions/gnss-frequencies-and-signals). A typical ceramic antenna is centered around 1575, with a bandwidth of +/- 30 Mhz (from www.amazon.com/CIROCOMM-Antenna-Ceramic-25x25x2mm-Geekstory/dp/B078Y2WNY6/r). These have no problem picking up Glonass satellites. BeiDou is even closer to the center, so they should have no problem with that, either.

There are some GNSS antennas out there that also can receive L2 signals (around 1200 MHz). But the ones I have seen are way too big for speedsurfing, and it is questionable if the GPS chips could use the L2 signal, or benefit from them.

I have been looking at dropped points from the Sparkfun SAM-M8 GPS board, which are much more a problem than with the cheaper Beitian chips like the BN880. Eventually, I read this little footnote from the u-blox SAM-M8 datasheet (www.u-blox.com/sites/default/files/SAM-M8Q_DataSheet_%28UBX-16012619%29.pdf):
"Rates with SBAS and QZSS enabled for > 98% fix report rate under typical conditions"

That translates to almost 2% dropped points being "allowed" when logging GPS + Glonass at 10 Hz. The data sheet does not even give a rate for tracking 3 satellite systems (which definitely improves accuracy).

I have observed drop rates of about 1 in 300 in windsurfing tests when using 3 systems at 5 Hz. The rate of double dropouts (600 ms between points) is about 1 in 8000 points. The cause is that the GPS chip cannot compute a fix in the given time. It is definitely not a communication problem, like we have seen with the original Openlog at higher Hz rates. Two Beitian chips used in the same test did not drop a single point in more than 50,000 recorded points.

It is interesting to see that the much cheaper Chinese knockoffs perform better than the genuine u-blox chips.

Were you already aware of this thread on the Dutch forum?
forum.windsurfing.nl/viewtopic.php?f=62&t=13890429

Google translated
translate.google.com/?hl=nl&sl=nl&tl=en&text=https%3A%2F%2Fforum.windsurfing.nl%2Fviewtopic.php%3Ff%3D62%26t%3D13890429&op=translate

Select to expand quote

boardsurfr said..
Because you do not need a "quad band antenna". Or alternative, because typical ceramic antennas work well enough as "quad band" with respect to receiving GPS, Glonass, Galileo, and BeiDou.

Primary (L1) band frequencies are 1575 MHz for GPS and Galileo, around 1600 for Glonass, and 1561 for BeiDou (from novatel.com/support/known-solutions/gnss-frequencies-and-signals). A typical ceramic antenna is centered around 1575, with a bandwidth of +/- 30 Mhz (from www.amazon.com/CIROCOMM-Antenna-Ceramic-25x25x2mm-Geekstory/dp/B078Y2WNY6/r). These have no problem picking up Glonass satellites. BeiDou is even closer to the center, so they should have no problem with that, either.

There are some GNSS antennas out there that also can receive L2 signals (around 1200 MHz). But the ones I have seen are way too big for speedsurfing, and it is questionable if the GPS chips could use the L2 signal, or benefit from them.

That makes it easier to choose.
So the next M9 question for me is, how hard/practical is it to shorten and re-terminate the antenna lead? and which plug type.
So far I'm thinking life is much easier with the BN880

Select to expand quote

decrepit said..
So the next M9 question for me is, how hard/practical is it to shorten and re-terminate the antenna lead? and which plug type.
So far I'm thinking life is much easier with the BN880

There's plenty of Youtube videos about how to make SMA connectors/cables. This looks very similar to a coax cable for cable TV, and when I watched an installer, making these connections seemed pretty easy with the right tools.
The U.FL connector is smaller and might be a bit harder, but there are some U.FL type antennas available with short cables around here. But disconnecting a U.FL connection is a bit trickier; when I tried it with a GPS chip I have, I ended up removing the connector from the chip. That was before I looked at the tips for U.FL connectors on the Sparkfun web site (learn.sparkfun.com/tutorials/three-quick-tips-about-using-ufl/all).

Select to expand quote

decrepit said..
So far I'm thinking life is much easier with the BN880

Having a GPS chip with a decent antenna on it certainly simplifies things. There's a similar chip with a USB connector available for $14 on Amazon that looks quite good in initial tests. I'll play around with it next week. I need to figure out how to power it and the logger through USB, and change the firmware. Compared to the USB dongle I tested 3 years ago, this one has several improvements, like a bigger antenna and an M8-based chip. Almost makes me want to look at the Pi Zero again, since it has a separate USB power plug.

Whilst waiting for my parts to arrive, today I knocked up the power supply. I found an old charger and battery from an old SJCAM (Gopro copy). I soldered a lead on to the circuit board and out through the side of the case. It is a 900mAh battery.
So that is the battery and charging sorted. Time 30 mins. Cost $0

Select to expand quote

boardsurfr said..
I have been looking at dropped points from the Sparkfun SAM-M8 GPS board, which are much more a problem than with the cheaper Beitian chips like the BN880. Eventually, I read this little footnote from the u-blox SAM-M8 datasheet (www.u-blox.com/sites/default/files/SAM-M8Q_DataSheet_%28UBX-16012619%29.pdf):
"Rates with SBAS and QZSS enabled for > 98% fix report rate under typical conditions"

That translates to almost 2% dropped points being "allowed" when logging GPS + Glonass at 10 Hz. The data sheet does not even give a rate for tracking 3 satellite systems (which definitely improves accuracy).

I have observed drop rates of about 1 in 300 in windsurfing tests when using 3 systems at 5 Hz. The rate of double dropouts (600 ms between points) is about 1 in 8000 points. The cause is that the GPS chip cannot compute a fix in the given time. It is definitely not a communication problem, like we have seen with the original Openlog at higher Hz rates. Two Beitian chips used in the same test did not drop a single point in more than 50,000 recorded points.

It is interesting to see that the much cheaper Chinese knockoffs perform better than the genuine u-blox chips.

Dropped points has been an onging issue with Ublox M8 10Hz and faster update rates.

I also get some dropped points @ 10Hz with the BT M8 Bluetooth device Manfred Fuchs built for me to log with GPS-Logit. Dont seem to get any when logging @ 5Hz. The same happens with the BT M8 GPS that Mat built.

Julien seems to have completely solved that in the Mini Motions by limiting the number of satellites processed to the strongest 18 signals. Not sure if that is something one can program through U-centre though, I havn't looked at that.

Mini Motion can do 3 GNSS @10Hz with M8 Ulbox with no missed points in any of my last few sessions I just checked (apart from submergences) Of course, he also outputs a pared down Data file (oao - not ubx)

PS. One thing I have not really studied, is if the Ublox6 drops points @10Hz. I have a Wintec G-Rays BT GPS (discontunued unfortunatetly) with this chipset that works with GPS-Logit at up to 10Hz. It only uses the single GPS GNSS. I will check it out today.

Yes, I re-read the discussion about Mike's prototype where Julien said he did something like that (except up to 24 satellites). The closest thing I have found in the u-blox documentation is the CFG-NAVX5 command, which can set both minimum and maximum satellite numbers, and the "Minimum satellite signal level for navigation" (minCNO). Limiting just the satellites did not eliminate dropouts, but Julien had said that removing the lower quality satellites was what made the bigger difference. Trying that was on my to-do list, but will require access to my serial-to-USB cables to get an idea what CNO levels the various chips typically get. So next week, maybe.

Based on u-blox datasheets, different u-blox M8 chips have different specifications. The NEO-M8N list 5 Hz as the maximum navigation update rate, while the NEO-M8Q and the SAM-M8Q list 10 Hz. Only the data sheet for the SAM-M8Q specifies the ">98%" success rate. There's a few more variations out there. The M8 engine (M8030) is a chip that's available for less than $2 (compared to ~ $15 for the complete Neo-M8N module), so the Beitian chips may well we "genuine" u-blox chips. But perhaps Julien will share which exact chip he is using in the Motion, and which settings?

I did a test drive around town using the G-Rays M6 BT GPS with GPS-Logit.

It adds weight to the theory that a too large number of satellites being processed may bethe cause of lost points.

No lost points in this short test @10 Hz on just the GPS system alone where max sats was mostly below 7.

I had to convert the ubx to sbp in GPS-Results for Speedreader to process it (which is understandable, as M6 predates the development of GPS-Speedreader )




See how high the sAcc is, especially in the highlighted run. It was mostly over 0.6 for individual points, which is significantly higher than later model M7 and M8 running Multi GNSS.

I think we are certainly better off with the newer Multi GNSS M7 onwards chipsets if the problem of missed points can be solved.

As Peter says, I have no missed points at 10hz with the BN880 and over 20 sats

Select to expand quote

decrepit said..
As Peter says, I have no missed points at 10hz with the BN880 and over 20 sats

Another difference is that my Logit BT GPS's are writing all the satellite signal strength and positional data as well. That may be part of the issue with my devices using GPS-Logit when all the other GNSS system satellites are added. I think I remeber that when you added the Nav-Sat sentence, you also had missed point issues?

Sorry Andrew, I don't remember, but that could well be the case.

Hmmm, I've just had a look at an old file, from before we had speedreader, I don't think GPSResults shows up missing points as well, because that file had a few missing points.
File: Fangys 18 sept V3 10hz.ubx

Observed time distribution (in ms):
100 106646
200 6

Points with untypical dt (and speed > 5.0 knots):
1 200 ms at #27266 12:06:20.200 speed: 21.639 sAcc: 0.210
2 200 ms at #38015 12:24:15.200 speed: 18.793 sAcc: 0.192
3 200 ms at #46445 12:38:18.300 speed: 19.090 sAcc: 0.214
4 200 ms at #60703 13:02:04.200 speed: 22.486 sAcc: 0.212
5 200 ms at #63242 13:06:18.200 speed: 21.695 sAcc: 0.212
6 200 ms at #82701 13:38:44.200 speed: 18.748 sAcc: 0.169
6 time errors (6 above 5.0 knots), about 6 missing points
Added 6 missing points
21479 filtered points:
Low speed 21479 points; max speed: 0.6 kn
SDOP/sAcc 1 points; max speed: 0.0 kn

Filters were applied
Start: 18/09/2019 03:20:53.500 end: 18/09/2019 06:18:39.300
Assumed wind direction: 297 degrees

Files and colors:
Fangys 18 sept V# 10hz.ubx - blue
Writing results to temp file '/tmp/GPSReader17182350345997603835.html'
Writing KML file '/home/decrep/Desktop/mike/windsurfing/speedstuff/gpsdata/2021/March/2021-03-25.kmz'

Dropped points can be caused by at least three different issues:
1. The GPS chip not getting a fix in time.
2. Not enough data transfer speed between the GPS chip, the logger, and the SD card.
3. Corruption of data during transfer between GPS chip and logger.

Between Mike's and my tests, we have seen examples of all these issues. With the Sparkfun SAM-M8 chip, I get dropped points even if the chip uses only one GNSS system (GPS), and has fewer than 10 satellites (#1).
We've seen issue #2 when trying to log both NAV-PVT and the much larger NAV-SAT sentences using the original Openlog.
Issue #3 can be a problem when using serial communication and sub-optimal baud rates. Mike reported that a lower baud rate gave better results, IIRC.
Data corruption is also an issue with the Sparkfun I2C chips and the Openlog Artemis (OLA). With the Sparkfun GPS chips, is important that to scratch out the I2C jumpers. In the default configuration, there are many checksum errors, which also lead to dropped points. This can be seen by hooking up the OLA to a computer over USB, and enabling the debug messages. The cause is that the OLA expects a different signal rise timing than the u-blox chips, so it sometimes reads the first bit in a transmission wrong (maybe 1 out of 100 NAV-PVT sentences or so).

I plan to have a look at the effect of interpolating dropped points, which would be easy to do in firmware and in software. Different programs treat them differently, and may even treat them differently for different GPSTC disciplines. The approach we have agreed on for GPS Speedreader (allow single dropped points, but count their speed as zero) may need to be reconsidered. It is extremely conservative, especially when devices with just one GNSS and 1 Hz (the GT31) or with very weak antennas (the GW60) are still allowed in the GPSTC (and I do not say they should not be!).

The effect of dropped points, and different ways of treating them, is open to straightforward analysis. It just needs to be done. Note that two "approved" apps for submitting to GPSTC already seem to ignore missing points and calculate the speed for the larger interval between points. Mathematically (and practically), this is the same as interpolating missing points (well, one way of interpolating that uses just one of the two points around the dropout, if you want to be exact).

My experience with the Beitian BN220 is the same : no dropped points@10 Hz. I only log the NAVPVT sentence. But if I also want to log simultan a .csv file, then I start loosing points. I have a ESP32 with a SD-card to log. SW is specific for this purpose written in Arduino. The EPS32 is an excellent choice for these things, as they are cheap, and you can find them with display, SD-card en lipo charger integrated. Every one who can find the cold end of a solder iron, can solder the GPS to the ESP (4 wires).

Select to expand quote

rp6conrad said..
But if I also want to log simultan a .csv file, then I start loosing points.

I read several comments about similar problems with the OLA, which has plenty of CPU power & memory. Trying to write to two different files on the SD card while logging creates problems. Lots of debug output over USB while logging to just one file works fine. But SD cards are pretty much made to write continuous files, and can't deal with switching back & forth between files. One could try large buffers for each file (at least 4 kb) and write large chunks only, but I'm not sure how much that would help. Since Arduinos are single-threaded, having to wait for the SD card to switch files could lead to data loss even with larger buffers.

So I may try a few more 8hz tests, accuracy should only be reduced minimally but may just get rid of all dropped points