That's what I haven't tried yet, a logger and a GW52 fit in the same bag on my head, but I don't think two loggers will. Must go and check now.

So there's no room in my new pouch for both loggers, but the carrier I'm making to fit on my helmet fits both loggers and the GW52. I just need a bigger pouch.



The mark 3 BN880 will go in the middle one once the new battery arrives.

don't fall at speed !!! that thing will snap your neck!!!!

That's always a worry with any helmet, maybe I'll fix it so it comes off easy and floats.

Just tried NAV-PVT and NAV-SAT, both at 10hz,
didn't work.

40190 points read: checksum: 927, corrupted: 636, missing: 692.
So I won't bother with 18hz.
Next is NAV-SAT at 1 hz

Well that's odd, some of those points are inside the area that's reached a fix, but I can't see them in GPSResults
Instead there's points with missing acceleration data.



So is this due to missing data? or some other cause? I thought that GPSResults calculated acceleration from changes in speed?

So pushing to the limit now, 18hz both PVT and SAT, what's the bets? more missing acceleration points?

Don't think I'll be doing this whatever the outcome, 18hz with pvt and sat is a huge file, 25mb for an hour.
here's what the parser says.
12286 points read: checksum: 42, corrupted: 12, missing: 195.

I'll go and see what it looks like in GPSResults.
That's another thing, 18hz is 55.555555555555 ms in both u-center and the parser I don't get a decimal point choice.
the above is with the parser set to a period of 56, the below is a period of 55
12286 points read: checksum: 42, corrupted: 12, missing: 12145

And this is with the parser on 57

12286 points read: checksum: 42, corrupted: 12, missing: 195
very interesting, why pick 18hz if that can't be set in U-center?

the 195 missing would be right, not sure if I want to see what happens with NAV-SAT removed? I think 10hz with NAV-Sat at 1 sec, and go for a longer time.

So changed my mind and did an 18hz NAV-PVT only, not a very long test, but just wanted to see what happened.
this is the result from the parser.
000001: 0019 07 092
000002: 0059 07 092
010012.264 059ms
010030.184 112ms

The first three are before fix, the last one is immediately after, it jumps from 4 to 11 sats.

Peter is also having acceleration induced dropouts at 10hz, in his case due to GPSResults filters. I'll see what happens to mine if I turn filters off.
Back later.

So checked the 10hz PVT and 10hz SAT file with filters off, and it made no difference, there's still points with missing acceleration data. However Daffy has observed that the file is only an hour long and GPSResults gives an hour result with filters on. So I'm not sure what is going on with that file.

Earlier I set V3 back to 10hz with NAV-Sat at 1 second, then took it, along with the GW52 and v2 for a bike ride, but due to a seniors moment v3 had no card in it!
So it's on the balcony again seeing how that setting works. If it looks good I'll try another bike ride later.
Well the file looks good, BUTTTTTTTTTTTT it's only 14minutes long, the %%$# battery went flat. I don't want to fully charge it, because then it won't stay on, just long enough to give me an hour's bike ride would be good, but how long is that?

Select to expand quote

decrepit said..
So checked the 10hz PVT and 10hz SAT file with filters off, and it made no difference, there's still points with missing acceleration data. However Daffy has observed that the file is only an hour long and GPSResults gives an hour result with filters on. So I'm not sure what is going on with that file.

It looks like GPS-Results does not mind if part of the sentence is missing that has the Acc data in it as far as a valid run goes. It seems to accept it if the main speed data is there and the point is not actually missed.
I'd say thats a trucated sentence.

Select to expand quote

sailquik said.. >>>>>> I'd say thats a trucated sentence.

That's my best guess as well.

Yes, this is a corrupted/truncated sentence. GPSResults will definitely not include this region in 2 sec, 10 sec, and nautical miles. One missing point in a nautical mile, and it will be discarded. However, it seems GPSResults tolerates missing points in 1 hour runs. It has to, since crashes often lead to missing points, and most hours be mere mortals contain crashes (or points that are filtered for other reasons).

The programs differ in how they treat missing or filtered points. GPSAction Replay Pro does not care about missing points at all, it always calculates results. IIRC, ka72.com will not calculate 2 sec and 10 sec results if a point is missing/filtered, but will calculate longer runs like nautical miles. I'm not sure were exactly the switchover is for ka72.com.

I've just found one of the downsides with the logomatic. It draws heaps of current, it may be possible to reduce this by playing with the firmware, but I'm not up to that yet.

So at 10hz with 1s NAV-SAT info it draws around 160ma that's only 6:15hrs with the intended 1000ma/hr battery.
If I drop the NAV-Sat info the current drops to about 135ma, that should give another hour. Strangely, changing to 5hz doesn't make much difference, about 133ma.

Select to expand quote

decrepit said..
I've just found one of the downsides with the logomatic. It draws heaps of current, it may be possible to reduce this by playing with the firmware, but I'm not up to that yet.

So at 10hz with 1s NAV-SAT info it draws around 160ma that's only 6:15hrs with the intended 1000ma/hr battery.
If I drop the NAV-Sat info the current drops to about 135ma, that should give another hour. Strangely, changing to 5hz doesn't make much difference, about 133ma.

That's a lot of current! I found one customer review on the Sparkfun site that confirm high current use. They say at low logging rates, a 2000 mA battery lasts 1.5 days - so that's about 55 mA. Compared to 6 mA for the Openlog, that's still a lot.
For the Adafruit Feather loggers, I've seen numbers of 10 and 20 mA. Have not tested it yet, but this would be ok, since the GPS module also needs something around 50 mA.

Finally got V3 in an enclosure with it's new battery, I'm sure I ordered 1000ma/hr but the one that arrived is 1100ma/hr. I'm not complaining, it fits in nicely.
So I'm doing a discharge test to see how long it holds up with NAV-PVT @ 10hz and NAV-SAT at 1second.
I couldn't resist a quick peek at the data, so after 4hrs I get these errors.

84105 points read: checksum: 21, corrupted: 17, missing: 23

000001: 0009 07 092
012204.112 112ms
000002: 003a 07 092
025418.700 200ms
000003: 0065 07 092
030240.700 200ms
000004: 005d 07 092
030243.700 200ms
000005: 005d 07 092
031150.700 200ms
2008300.600 713400100ms
000006: 0065 07 092
031410.700 200ms
000007: 0065 07 092
031645.700 200ms
000008: 0065 07 092
031841.700 200ms
000009: 0065 07 092
032031.700 200ms
000010: 0065 07 092
032319.700 200ms
032509.700 700ms
1300404.600 460680100ms
000011: 0065 07 092
032751.700 200ms
000012: 0065 07 092
033109.700 200ms
000013: 005d 07 092
033246.700 200ms
000014: 0065 07 092
033402.600 200ms
033411.700 200ms
033557.700 200ms
000015: 0065 07 092
033731.600 200ms
000016: 0065 07 092
033746.700 200ms
033923.600 600ms
000017: 0065 07 092
033929.700 200ms

All the "0000" times are before it's got a fix, but the cluster in the 033s are real.
So unless I can get into the firmware and improve things, looks like I'll have to drop NAV-SAT.

I have to buy another card to replace the one I pinched from my music player phone, so I'll see if I can try a faster one.

OK just ordered this.
SanDisk Extreme 16GB SD SDHC Memory Card U3 UHS-I 90MB/s Ultra HD VIDEO 4K 16G
I think that's twice the speed of the one in there at the moment, so we'll see if it makes any difference.

That's thrown a spanner in the works, 2nd session didn't record, a bad connection in the 3.3v rail to the GPS. So now I don't know how long it's been on, and if said bad connection is responsible for the missing and corrupted data. So back to square 1 with the tests.
I can't find the actual bad joint, all connections look fine through my X3 specs, so I've just bypassed the section.

Could be the bad connection, but the misses I've seen in other 10 Hz data look very similar - mostly single point misses.

It is possible that the limitation is on the GPS chip, not the SD card or logger. I read somewhere that the chip would be able to take 40-50 measurements per second, but it's spec'd only to 10-18 Hz. As Raymond has pointed out, it does not even reach this speed when running from Flash.

When running at the maximum specified speed, I'm sure there are some limits on what data can be sent. I can't imagine that the chip would be able to send all UBX and/or NMEA sentences. The question is where exactly the limit is. Perhaps using Bluetooth and GPSLogit BT that's now available on a decent phone might provide some insights ... although the only definitive answer would be if things work. If there's still data loss, it might be due to the Bluetooth connection or the phone. The same thing is true for using another logger like the Pi or the Adafruit Feather Logger M0. Maybe I''l take some toys with me on vacation, just in case the weather is bad.

But it looks OK in U-center, all though I haven't saved a file there to have a close look.
It does look like18hz NAV-PVT and NAV-SAT is coming in.

U-center is definitely a useful tool that might help here. It is difficult to see missing points in u-center when it's just one point missing every few thousand points. Recording from u-center to a file may work, although this adds a couple of new possible bottlenecks: u-center's file recording, and the connection between the GPS module and u-center (in particular any USB-to-serial cables).

You've made me curious now. I just put my Surface connected to the Drotek NEO-M8 outside (since that can be connected directly via USB), recording NAV-PVT and SAT at 10 Hz. Will let it run for a couple of hours (if Windooze lets me) and see if something's amiss.

So I ran the test for a few hours. Logging both NAV-PVT and NAV-SAT worked ok for about 1 minute, then the first points were missed. This got worse over time. After an hour, most points were 200 ms apart, with just occasional short 100 ms periods. After a few hours, it converted to 5 Hz almost completely - I found one period were all points were recorded at 5 Hz for about 5 minutes, without a single point at 100 ms. It would appear that this is a limitation of the GPS chip. Not that the logger can't also loose points .. probably does it just to make things confusing .

Confusing seems to be the operative word!!!!!
I've done something to my unit now, seems in the process of fixing the 3.3v rail I've stuffed the RX and TX connection to the BN880. Off to have another play now.

Problem was in the BN880 between the breakout holes and the socket. Seems mounting it by the pegs isn't a good idea, I think mechanical strain has cracked the RX track. It's working OK now using the plug and ribbon cable. I've just got to put it back together, without doing more damage!
I'll get ride of SAT-NAV, and see if I can do a long session with only 10hz NAV-PVT

Select to expand quote

decrepit said..
Problem was in the BN880 between the breakout holes and the socket. Seems mounting it by the pegs isn't a good idea, I think mechanical strain has cracked the RX track. It's working OK now using the plug and ribbon cable. I've just got to put it back together, without doing more damage!
I'll get ride of SAT-NAV, and see if I can do a long session with only 10hz NAV-PVT

I always use the cable. Makes it easy to switch GPS modules, hook them up to u-center, etc.

It will be interesting to see if you can get several hours of 10 Hz NAV-PVT without any lost points.

Finally got it back together, completely reconfigured. I'm much happier with this layout.
Managed 1/2 hr at 10hz PVT before the battery went flat. just had 1 corrupted and 1 missing at the start, before fix.
I'm charging it now. and there's wind forecast for tomorrow, so I may get to test it live.

Select to expand quote

decrepit said..
Finally got it back together, completely reconfigured. I'm much happier with this layout.
Managed 1/2 hr at 10hz PVT before the battery went flat. just had 1 corrupted and 1 missing at the start, before fix.
I'm charging it now. and there's wind forecast for tomorrow, so I may get to test it live.

I recorded my car trip Sale to Sandy Point today. Roughly 2 hrs at speeds up to 50 knots.
10Hz, GPS-Logit. Manfreds BT GPS receiver. PVT and DOP @10Hz /SAT @1Hz

31 points missed in a tight cluster within about 5 seconds in the middle of the trip. No others. I cant see any reason why they dropped except the sudden appearance, and then disappearance, of a single Beidou satellite in the list on U-Centre which coincided with a jump from 11 to 12 sats used. Otherwise just the usual GPS and QZSS sats.

Hmmm. ??

I also did a stationary test with GPS-Logit set to 18Hz (GPS only) and had only two missing points in over 1 hour (and I think right at the very start). That is much better than I had experienced before and indicates that using only 1 GNSS may be an advantage. I will do some moving tests @18Hz tomorrow. Unfortunately, I can't configure Logit to do only one GNSS @5hz or 10Hz to test that.

Maybe the theory about updating the chip with sat data has something going for it.

Select to expand quote

decrepit said..
Maybe the theory about updating the chip with sat data has something going for it.

Maybe, but I had the GPS going in the backyard doing stationary tests for a few hours before the trip. It should have been well and truly 'updated'.

I am now suspectig it may be just too many sats that is the issue??

I have come to the conclusion that the Openlog ismost likely fast enough to record 10 Hz NAV-SAT data, and that missing data points are probably often caused by the u-blox chip. I would say that chances that the chip is at fault are very high in cases where there are many dropped points close to each other.

For the first speed, the chip was setup to send a lot of different UBX records that have a fixed size (unlike e.g. NAV-SAT, where the size depends on the number of satellites visible or tracked). The chip put out ~ 538 bytes of data 10x per second, and did not track any satellites. The amount of data is comparable to sending NAV-PVT and NAV-SAT at 10 Hz, but since the chip had no reception, there was no concern about computing speed. The results was 24 corrupt records in a 42 MB file. So the Openlog almost was able to keep up, but not quite. I also checked the TX buffers and IO status in u-center when sending data at this rate, and saw no signs of problems. The TX buffer usage always stayed below 25%, so it's not a buffer problem on the GPS module site.

I then ran a 10 1/2 h test with just NAV-PVT at 10 Hz. That file was "only" 38 MB. Unfortunately, the chip started tracking satellites after a few minutes. There are two incidences of missing points:4 points in a row missing after ~ 4 hours,and 3 points after ~8 hours. There were no corrupt sentences, so the misses definitely appear to be caused by the GPS module.

Based mostly on Julien's explanations and Raymond's and our observations, here's what I think is going on:
-when recording at 10 Hz from 2 or 3 GNSS networks, the u-blox 8 is running "all out". It comes to a valid solutionalmostall the time, but about once every 1000 to 100,000 calculations, something goes wrong, and no valid solution is achieved within the ~100 ms the chip has. This leads to missing points - sometimes one point, sometimes a few points. This seems to happen more when about 15-20 satellites areused for the solution, but can also happen with fewer satellites, even without Galileo and Beidou.

In 5 Hz data, such problems are either absent, or much less frequent. We have seen several examples from different units and locations where the chip reverted to 5 Hz rates for a period of time when 10 Hz calculations failed. Possible reasons are that the calculations take just a bit longer than 100 ms, or that the chip can "start over" after the first calculation failed (but does not quite have to start from scratch, letting it finish the second time around).

Note that this "missing points" behavior is not limited to u-blox 8 chips. I have seen instances in 5 Hz Locosys data where points were missing in the middle of a run. However, these seem to be rare, and they are easily missed unless you specifically look for them. Canmores can miss points on a more regular basis.

Select to expand quote

boardsurfr said.. >>>>> Canmores can miss points on a more regular basis.

All that makes good sense Peter, but for this last sentence, I'd use "do" rather than "can"

I have just installed a more up to date version of U-Centre (Ublox GPS analysis tool) and cleared a few things up for myself.

First, GPS-Logit BT is not using GLONASS when set at 5Hz and 10 Hz. It is using GPS and QZSS/MSAS(Japanese). It sometimes 'sees' a Beidou satellite but does not show it gets a signal or uses it. This is not what I had assumed. I had assumed it was using GPS/GLONASS.

Second, It is only using GPS when set to 18Hz. This is what I had assumed. Strangely, I am seeing almost no missed points when running at 18Hz in a couple of tests done in the last few days and in loder skiing tests. In early windsurfing and stationary tests a few years ago I was seeing very regular missed points. Something has changed for the better.

Thirdly, I have gone through a lot of old sailing and skiing files and have seen very few missed points in the 10Hz data. There is an occasional one, but I have very rarely missed a run that 'counts' due to a missed point.(I had a couple of whole days of skiing @18Hz without any missed points. It's amazing to see the shape of your turns so clearly at 18Hz!)

I went back to the 10Hz M6 UBX files from Manfreds twin GPS logger I carried at Luderitz. There are just one or two missed points in those files, right at the start when the GPS is getting a fix. None appear in any of the runs in either set of side by side data. Notes on this data: The error rates are slightly higher for all the divisions compared with what I see from the current M8 based receiver, but as I have said before, this is good because even with the slightly higher error, Manfred found excellent correlation between the GPS's and the fixed timing gates. It can only be better with the M8 chip.

Test files from Mikes GPS at 10Hz did include the GLONASS satellites (as well as GPS and QZSS/MSAS) and had a significantly higher total in view than mine as a result. It will be interesting to see if further tests show this to be an advantage re. error values or a problem with missed points.

I will continue to test the BT receiver at 10Hz to get a better picture of how any missed points, that may appear, actually affect the results.
I now have a couple of better tools.

After poring over a heap of old and new GPS files in the last few days, I am now even more of the opinion that the recording of satellite position, signal level data and fix data is extremely useful and should be a feature of new GPS's. This data is not used in the active filters in the analysis programs, but it is invaluable for development, troubleshooting and trying to explain why things go wrong.

I don't think an individual point missed at 10Hz or 18Hz, in 2 or 10 sec runs is going to adversely affect the result or it's validity. I am highly confident that it is not a problem at all in NM or the 1Hr.

I have asked Manfred if he concurs, and if he can modify GPS Results to allow missed points in 10Hz and higher results. GPSAR-Pro, KA72 and Realspeed already allow this in certain circumstances.

In the meantime, we have now seen GPS-TC approval of a couple of homebuilt ublox based M8n loggers for use at 5Hz.

We are awaiting the Motion GPS from Belgium for testing and hopefully, approval. There has been a flurry of testing by the designer in the past week or so to resolve how fast it can log without missing points, so it's delivery has been delayed slightly. That is fine with us as hopefully it can be approved at up to 10Hz or more.

Tested the helmet mod to take two GPSs along with the V3 logomatic, BN880 logger @ 10hz.
There's still work to be done on the helmet mod, I've held the waterproof pouch in place with the front of an old paqua-midi. Water gets between the two plastic sheets, and probably reduces the satellite signals, although that's hard to pick up in the data.

I had the GW52 and V3 in the helmet, and V2 on my upper right arm.
The three are very close, and these are the ubx missing points

V3
176045 points read: checksum: 0, corrupted: 1, missing: 1
000002: 0019 07 092 This is before any sats have been fixed
004801.102 102ms this is when it goes from 0 sats to 7 sats

V2
86363 points read: checksum: 0, corrupted: 0, missing: 3
005108.400 217ms, this occurs as sats go from 0 to 6
010255.400 201ms, 0.6secs before this is a 0.199
031831.400 201ms, "" "" " " " "

A bit more of a play today, as V2 doesn't like 10hz I tried it with 8hz. Nobody talks about 8hz, so I wasn't sure if it would even do it. But at 125ms periods it worked fine for almost 2 hours.



So now I'll do some longer tests and see how the accuracy and reliability compare.

I'll also try V3 @ 8hz with NAV-Sat enabled at 1s intervals.

I was hoping to try a sandisc ultra extreme card but I ordered an ordinary sd card not a micro. For some reason I assumed that googling micro SD cards, would give me micro sd cards, I didn't bother checking.