Select to expand quote

boardsurfr said.. >>>>The standard firmware seems to log data coming in over the serial port, just like the original Openlog. So switching loggers, like you had planned, might be a simple exercise after all.

Also, it seems using the USB port in the OLA to log data from a GPS connected through USB does not work. The problem is that USB always requires a controller and one or more devices. When hooking up to U-center or the Arduino IDE, the computer is the controller. That means the OLA and the GPS units are both devices, and devices only can talk to a controller, not to another device. So logging with a USB GPS would only work with something like the Pi Zero or a phone with OTG support. I just ordered the Sparkfun M9 chip with the U.FL connector. Should arrive in a couple of days. Now if only the warmer weather would arrive for some on-the-water testing! I'm just not ready to jump into 5 C water yet.

That's how I read the manual, we'll know fairly soon, (I hope)

Select to expand quote

tbwonder said..
Motion file 2.2MB
BN880 file 4.4MB
Both for 46,000 points, so more than 1 hour

My test:

Motion (mini) 2.0MB
GPS-Logit (M8N) 4.3MB

37,500 points. Pretty close to I hr.

Interesting was that the Motion had 18 sats most of the time.
The Logit BT device was from 7 to 12. I seem to remember that the M8 is set to only use 2 GNSS where the Motion is using 3. The Doppler error was significantly lower with the Motion: around 0.25-0.30 for each data point. compared with around 0.38-0.48 with the Logit M8.

1 missed point with Logit (right in the middle of the hr). None with the Motion.

Despite the UBX file being double the size, the processing and rendering time on GPS-Logit on my MacBook Pro is insignificantly different. Somewhere around 2-3 seconds.

Yep, works great, connected it up and away it went.
Looks like it will even label the files with the correct time.
But it will need an on/off switch, and a remote reset button. Once power is disconnected, it doesn't start back up until reset.
We're going out now, so I'll play a bit more tomorrow .

And while playing, I found, much to my surprise, I have a BN280, not a BN880 like my wiring diagram says.
I think this has the same size antenna as the 880 but it's passive not active. Works perfectly fine, but when I've sailed with it it's been on my head. I haven't used it much because the old logomatic drew a lot of current so battery ran out a bit too quick. I'm hoping that the new artemis openlog will draw less current. I'll find that out fairly soon.

Select to expand quote

decrepit said..
And while playing, I found, much to my surprise, I have a BN280, not a BN880 like my wiring diagram says.
I think this has the same size antenna as the 880 but it's passive not active. Works perfectly fine, but when I've sailed with it it's been on my head. I haven't used it much because the old logomatic drew a lot of current so battery ran out a bit too quick. I'm hoping that the new artemis openlog will draw less current. I'll find that out fairly soon.

I've used the BN280 in an armband, and the 880 on the head, in recent tests. The number of satellites is pretty similar, perhaps 1-3 satellites lower for the BN280, but also often the same. The error estimates are higher for the BN280, but that may well be due to the different position, with partial signal blockage by the body. Here's an image from a recent foiling session:
The big differences are in a crash, when the unit on the arm was in the water, but the one on the head was not.

On the BNs I have, the 280 has a 4 mm thick antenna, while the 880 has only a 2 mm thick antenna. The thicker antenna should improve reception from satellites that are off to the side of the antenna.

Select to expand quote

sailquik said..
Despite the UBX file being double the size, the processing and rendering time on GPS-Logit on my MacBook Pro is insignificantly different. Somewhere around 2-3 seconds.

And when you want to see alpha results after just opening a file? Especially if the file has longer times of near-zero speeds?

Bugger, Looks like I was fooled by old files. I checked the GPS date on them and they're from last year. So looks like I've yet to record GPS data, but it does record a data file from the onboard sensors. Looks like I will have to be patient and wait for the USBc cable

Bugger again, may have stuffed the board, the BN280 uses TTL logic levels, (5v high). Max input voltage of the Artemis is 3.6.
I'll try a voltage divider and see if that gets it working

Select to expand quote

boardsurfr said..

sailquik said..
Despite the UBX file being double the size, the processing and rendering time on GPS-Logit on my MacBook Pro is insignificantly different. Somewhere around 2-3 seconds.

And when you want to see alpha results after just opening a file? Especially if the file has longer times of near-zero speeds?

What are you trying to point out Do Files with Alphas take longer with UBX V's OAO?

Select to expand quote

sailquik said..
What are you trying to point out Do Files with Alphas take longer with UBX V's OAO?

Calculating alphas take longer at higher herz rates. The algorithm usually has an N-squared component, so doubling the data amount increases the time to calculate alphas 4-fold. This is very easy to see in GPS Action Replay, where the alpha calculation can take a lot more time than the other speeds. In GPS Results, some of the other calculations for the "longer" categories (like nauti) can also be slow.

Both GPSAR and GPSResults open a file and calculate speeds later. With high-rate files and longer sessions, seeing the results can be a test of patience. If you have a file for a multi-hour session with some break periods, you may have enough time to not just get coffee, but also to brew it .

GPS Speedreader is different - it calculates all speeds when opening a file. The algorithms have been optimized to be quite fast. From what I've seen, ka72 is similar. But the total time needed will always scale with the number of data points, so higher rates and longer sessions will always require more time.

Select to expand quote

decrepit said..
Bugger again, may have stuffed the board, the BN280 uses TTL logic levels, (5v high). Max input voltage of the Artemis is 3.6.
I'll try a voltage divider and see if that gets it working

Would be a real bummer if you killed the board (or even just the serial circuits on the board). One of the things about serial communications that can get you - different voltage levels.

I assume that you edited the config file to match the baud rate the BN uses?

I did today a test with the BN220 / BN280. Both were on the dashboard of my car, distance 60 km, rate 10 Hz. The BN280 has a faster fix, but overal the nr. of sats were comparable (11 - 16). At the end, I didn't see much difference in the results :

I got the Sparkfun Neo-M9N GPS with the U.FL connector today. The good news is that the $14 antenna works great, the CNO levels are at least as good as with the best other chip I have, and much better than with the chip antenna. The bad news is that the GPS limits the number of satellites used to 16 as soon as you go to 10 Hz or higher. Here's a short video that shows this in U-center:

Every time I set the rate to 10 Hz, the number of satellites used drops to 16. That happens with 4 GNSS systems, but also with just 3 (with or without Beidou). On the bright side, at least the chip picks the sats with the best CNO to use (that did not seem to be the case on the M8 when limiting the number of sats in the GNSS config settings), and can go to 18 Hz with 4 systems.

I'm running some stationary "at the glass door" tests to compare 5 Hz (with 20-22 sats) with 18 Hz (16 sats). If taking the best 16 satellites is as good as taking 20+, and if the error is mostly random, then the 5 Hz data should have about 70% higher errors.

Select to expand quote

boardsurfr said..
Calculating alphas take longer at higher herz rates. The algorithm usually has an N-squared component, so doubling the data amount increases the time to calculate alphas 4-fold. This is very easy to see in GPS Action Replay, where the alpha calculation can take a lot more time than the other speeds. In GPS Results, some of the other calculations for the "longer" categories (like nauti) can also be slow.

Both GPSAR and GPSResults open a file and calculate speeds later. With high-rate files and longer sessions, seeing the results can be a test of patience. If you have a file for a multi-hour session with some break periods, you may have enough time to not just get coffee, but also to brew it .

GPS Speedreader is different - it calculates all speeds when opening a file. The algorithms have been optimized to be quite fast. From what I've seen, ka72 is similar. But the total time needed will always scale with the number of data points, so higher rates and longer sessions will always require more time.

That make sense.

And yes, I have had plenty of time to brew a Coffee when opening big, high Hz files in other programs, probably exacerbated by running them in Windows Emulation on a Mac.

That fed my concern that we might run into time problems trying to process 25Hz UBX files, but with the speed at which GPS-Speedreader does it, I am not so concerned now.

Select to expand quote

boardsurfr said..
I got the Sparkfun Neo-M9N GPS with the U.FL connector today. The good news is that the $14 antenna works great, the CNO levels are at least as good as with the best other chip I have, and much better than with the chip antenna. The bad news is that the GPS limits the number of satellites used to 16 as soon as you go to 10 Hz or higher.

That is very interesting indeed. So it appears that the chip itself in programmed to do this automatically?

That makes sense to the extent that Julien has also implemented a limit (18 sats) in his 10Hz devices. is this a disadvantage, or is it an advantage because it might prevent lost data points? The Motions report very low error values. Would they gain anything significant using more satellites? It appears from your excellent video. that the PDoP decreases slightly. Can you tell if the Velocity error changes?

I'm running more tests now. I could come up with lots of theories, but the only thing that matters is what the data say.

There's quite a bit of variation between tests, and even within tests. It will be important to do a few longer test runs at different settings, and different times of the day to get different satellite constellations. U-center fooled me for a while into thinking I could not change the rate to 25 Hz by coloring the background in the "Rate" cell red. But it seems 25 Hz works ok even with 4 GNSS systems. Whether it's really better remains to be seen. I'll set up a really long test at 8 Hz overnight, and get some 25 Hz data tomorrow.

Select to expand quote

boardsurfr said..>>> I assume that you edited the config file to match the baud rate the BN uses?

Yep, but I'm not convinced it's having an effect. I also turned off the internal sensors, except temperature, and enabled debugging. But I still get all the sensor data and no debugging.
Also I may be OK with the voltage levels, because the 280 is fed from the 3.3v artemis serial pins. Unless the 280 steps that up to 5v it should be OK, and just be a baud mismatch.
So I could just wait to Tuesday for a USBc cable, or I could change the 280 back to 9600 to test.

I also discovered (more manual reading) how it's meant to save the RTC. you don't switch the battery directly, you hold the 3.3v rail low, (a couple of dedicated pins) that sends the artemis into deep sleep. That's the 18?a battery draw, keeping the clock ticking.
It also recommends sending a "stop logging" signal via pin 32. The you need a momentary switch on across the "reset" pins.

So using the device is a bit messy. You need access to both sides and ends. USBc is at one end card holder at the other end and other side.
But it does say that the card can be read from USB. This may be the best way to access data, as the USB socket is under the blue tooth antenna, so pushing the card in and out requires good access if it's in an enclosure.
Then to turn off you need to press the stop logging button and switch the 3.3v rail low. To turn back on, you have to release the 3.3v rail and press the reset button. So two buttons and a switch need to turn on and off.

With my lack of design skills, this could cause me a headache, trying to get this into a small neat enclosure.

I don't worry about enclosures. Either a GoPro case or a double bagging with a waterproof armband and a plastic bag works perfectly fine, and access to everything is easy. But I see that neither is compatible with your goal of maximizing the number of GPS units on top of your helmet.

If you figure out an easy way to access the SD card via USB, let me know. It certainly possibly to write firmware that accesses the card and communicates through USB, but that's not easy.

I don't quite follow you about the stop logging, since there is no "stop logging" button. You'd have to add one by connecting to pin 32. IIRC correctly, you have to temporarily pull that to ground. The firmware checks the pin (if the settings file has been modified to enable pin 32), and then puts the device into deep sleep. Doable, but I think it is easier to have the firmware watch for satellite loss or long stationary periods and then induce sleep. I've implemented the first part, but only for logging over I2C (since I started with the GNSS firmware).

yes the stop logging button will be connected to pin 32. But that's all future experiment, whether it works or not we'll see.
First I have to get it logging!
Peter, you're a natural programmer, I'm a natural wire solderer.

I've got a bunch of results from stationary testing at 5 to 25 Hz. Here's one example from a stationary test at 25 Hz where the GPS was never moved:


Note that there are several 10 second speeds of 0.2 knots where the accuracy estimates are 0.05 knots or less. These are two standard deviation numbers, so the speed is at 8 to 13 standard deviations above 0. That should basically never happen (remember that six sigma is 4 errors per million, and we are talking 8-13 sigma!).

Two possible reasons for the observations are:
1. The point error estimates (sAcc numbers) are too optimistic.
2. The error is not randomly distributed.

Option 1 can be excluded quickly by comparing speed and error estimates. The average point error estimate is typically about 4-5 times the average speed (speed 0.06 knots, +/- 0.3 knots).

That means the error is not randomly distributed. This is indicated by the both the waves in the error estimates (lower graph), and the clustering of higher speeds in the speed graph.

The result is actually not surprising. For example, atmospheric disturbances are a major source of noise that leads to position errors. These are on a relatively large scale, otherwise RTK corrections with a base station that can be kilometers away would not work.

Bottom line is that measuring at 25 Hz only looks more accurate, since the error numbers reported by GPS Results or GPS Speedreader are lower. Correct error estimates for the results above should be several-fold higher (roughly similar to the reported speeds).

Some random thoughts:
- M9/10 were stop-gaps. M9 to not miss the RTK/multiband hype-train of Broadcom and ST. Which, two or three years in, still have no real following. M10 to not miss huge but cheap contracts. M8 was also released too early with an important bug in raw Glonass data. I'm fairly certain that some decisions made a few years ago threw some big-paying customers off and/or made working with them harder.

- Replicating chips is easy and popular "modules", not talking about only GPS here, use these. If your chip is nothing more than an ARM Cortex-M plus a few other building blocks like a regulator, supervisor and ADC, they just need to re-assemble four similar design blocks to copy it. It's even easier for them if you release your firmwares without any encryption.. There's a company touring the world's tech fairs and boasting billions in sales (doubt) that has, in its catalog, not hidden at all, chips with the same nomenclature as ?Blox or ST chips.

- Stationary is an human construct. It's easy for us to notice but hard for a receiver to compute.

Select to expand quote

JulienLe said..
- Stationary is an human construct. It's easy for us to notice but hard for a receiver to compute.

Not really. As Tom Chalko pointed out, the GPS satellites are moving at such a large speed relative to earth that the relative difference between 0 and 40 knots is extremely small. But stationary is the only test that is very easily accessible.

The one issue one has to be aware off in stationary tests is the bias introduced by speed over ground being non-directional. When windsurfing and the GPS has an error of +1 knot in one point, and -1 knot in the next, that evens out (unless at the edge of a measurement). If the error is perpendicular to the direction of travel, it's contribution to speed over ground will be very small at typical speed (e.g. < 0.02 knots at 30 knot speed (Pythagorean theorem). But measured stationary (true speed = 0), the error will always show up at 1 knot. But in u-blox data, this can be examined, for example by looking at the directional speeds (velN and velE), which are available in the NAV-PVT records typically recorded.

Select to expand quote

sailquik said..
Would they gain anything significant using more satellites?
Can you tell if the Velocity error changes?

Two good questions. First one is hard to answer and will need more tests. Second one requires not just to look at the speed error numbers, but also at their validity. Here's an image from an "ideal setup" stationary test (GPS on top of my high-roof van with a clear view of the perfectly sunny sky):


The 25 Hz data have higher average speeds (top panel), but lower error estimates (bottom panel), than the 5 Hz data. The # of satellites was 15-16 for 25 Hz, and 24-29 for 5 Hz. Here's a closer look at the error estimates for the entire test sessions:


So estimated error is definitely higher for 5 Hz. But the observed speeds (which are actual errors) are lower for 5 Hz:

So actual errors are higher at 25 Hz, but error estimates are lower!

My guess is that this is because the 5 Hz solution includes satellites with lower signal-to-noise ratios, which results in higher residuals (or similar) that is used to estimate the accuracy (probably together with other estimates). But the actual algorithm is decent enough that the additional satellites improve the accuracy, even if some of them have higher noise levels. I'll run some tests specifying minimum CNO levels to see if I can confirm this guess.

Select to expand quote

boardsurfr said..
My guess is that this is because the 5 Hz solution includes satellites with lower signal-to-noise ratios, which results in higher residuals (or similar) that is used to estimate the accuracy (probably together with other estimates). But the actual algorithm is decent enough that the additional satellites improve the accuracy, even if some of them have higher noise levels. I'll run some tests specifying minimum CNO levels to see if I can confirm this guess.

That seems to not be the case. I ran one test with minimum CNO of 28, which dropped satellites from ~29 to ~24, but had no apparent effect on sAcc (average 0.26) or stationary speed (average ~ 0.03 kn). Then I increased minCNO to 30, and limited satellites to 16, and the sAcc average went up slightly to around 0.3. Since that's just a single test, it is always possible that changes in the satellites contributed to the observed differences, but it's unlikely that my guess was right.

So it remains that the Neo-M9N seems to give lower error estimates at higher data rates, but higher actual errors. That's something that needs to be repeated, though, ideally at a different location.

Great stuff Peter, finding out what actually goes on the accuracy and error numbers

I put a description of the results of some tests at boardsurfr.blogspot.com/2021/04/gps-noise-and-data-rates.html
There's a little puzzle at the end. I'm curious if anyone figures out what I did to generate the last graph in the post.

You're fighting two battles. One at the very beginning of the computation, look into PLL and jitter, another at the very end of the computation, look into dynamic filters.

Select to expand quote

decrepit said..
Very interesting that higher hz has reported better accuracy but in fact has less. How does the HDoP data compare? Does that give just as bad an indication or is it better?
We've thought it irrelevant, now we have sdop but????????????

Mike asked that in an email, but it is a very good question, so I post it here. Below is a graph of the HDoP values for 5 Hz and 25 Hz:
The HDoP value at 25 Hz is more variable, and always about 2x higher. This means that at 25 Hz, the GPS picks satellites that are closer together in space. At 5 Hz, is used all 25-29 satellites, but at 25 Hz, it used only the "best" 16. From looking at the detailed satellite info in u-center, the GPS seems to pick the satellites it uses based on the signal-to-noise level (CNO).

In general, satellites closer to the horizon will have more noise, and therefore a lower CNO, since the signal has to travel through a longer section of the atmosphere. So the selection of just 16 satellites at 10 Hz or higher that the M9 chips do will "throw out" most satellites closer to the horizon. That leads to higher HDoP values, which is what we are seeing.

The GPS units are made for car navigation, where picking the satellites high in the sky makes sense, anyway: they are least likely to be blocked by houses or trees next to the road, and will give the most accurate position. But for speedsurfing, position accuracy matters little - we are mostly interested in speed determine by Doppler. The Doppler effect is largest when you move directly towards something, or directly away from it. With something that is at a right angle to the direction of travel, and very far away, like satellites right above you, the doppler effect will be much smaller. So the selection of a subset of satellites at higher rates actually can reduce the Doppler speed accuracy. Which is what the stationary test results have shown.

You were closer to the solution in your previous experiment. It's a well-researched phenomenon.


But it makes a good example how this is all marketing in the end. You're sold a 25Hz receiver but you'd need a 500+usd oscillator for it to be useful. You're sold a multi-band receiver but you'd need double the antennas, double the filters, double the amplifiers, double the paths, double the converters for it to make an actual improvement.

It's all marketing so the end-product marketing can boast these too. No-one space constrained or BOM constrained, like smartphones or satnav designers, will bother implementing these properly. It's not their goal, it's not worth it, it's not useful to anyone. As exhibited by the complete lack of third-party parts availability this would require. But damn does it look good on the marketing sheet.

I did another 5 to 25 Hz comparison today, but this time with satellites reporting (NAV-SAT) turned on. Here's a sky view of which sats were used at 5 Hz:

And at 25 Hz:




All the satellites shown in blue in the lower image would have been available for navigation, but were not used due to the 16 satellite limit the M9 enforces at rate from 10 Hz on. It used all satellites near the center, while unused but usable satellites are closer to the horizon. As a result, the PDoP was about 50% higher. However, it gives better (lower numbers for the other "accuracy" estimates.

That also visible when comparing the tracks in Speedreader:




The error estimates (lower panel) are lower for the 25 Hz data, but the actual errors are higher. The given error estimates have a "more Hz is better" bias that is exactly the opposite of what the observed accuracy is.

If we look at the top 10 second speeds in these tracks, it also becomes clear that there is an issue with the 25 Hz data:


Most or all of the 10 second speeds should be less than the +/- estimates (which are 2 sigma). That is true for the 5 Hz data on the right, but not for the 25 Hz data on the left. In the 25 Hz data, the top speeds are about 2x the +/- estimates, which should be a very rare event.