Select to expand quote

boardsurfr said..

mathew said..

Your blog doesn't indicate which version of Bluetooth you are using - BT version 4 uses spreadspectrum so shouldn't really interfere. Was the test using BT v1 or v2 ?

...
You could make the theoretical argument that Bluetooth should not interfere with GNSS since the frequencies are quite different - around 2.4 GHz vs. 1.6 GHz). Actual observation shows that you're about 99.999999999999% correct. Unfortunately, since the GPS signal is about 1000000000000000 times weaker than the signal emitted by BT transceivers, that's not good enough to eliminate all interference.

Maybe a BT 4 transceiver could have less RF interference simply because you can reduce the power output of the signal easily. Maybe you'd also get good enough communication between the module and the phone to record sessions reliably even at low-power modes. But you'd always need to use two separate devices, the phone and the GPS. Your recording will fail when one of the two devices has a problem - for example, when the phone battery dies.
...

BT 4 uses direct-sequence spread spectrum (vs frequency hopping) and transmission occurs over a wider band than previous versions, and with lower power by 3 orders of magnitude.

So unless there is high-correlation between the PN-sequence used for GPS, and the PN-sequence for BT4 -. then there should be minimal-to-no interference.

aka it makes a huge difference.

Select to expand quote

mathew said..
BT 4 uses ... lower power by 3 orders of magnitude.

Please stop posting completely misleading figures like "3 orders of magnitude". That is a ridiculous over-estimate for the use we discussed, transmitting GPS data while windsurfing. BT 4 LE uses significantly less power when the device does not transmit data ("A Bluetooth low energy device achieves low power consumption by keeping radio activity short and allowing the device to reside in standby or power down mode most of the operating time.", from http://www.ti.com/lit/an/swra478c/swra478c.pdf).

RF interference happens when the BT devices is actually sending data, which would happen at least 5 times per second. When transmitting, the power output from BT LE devices is in the same range (up to +5 dBm) as for the HC-06 (-4 to +6 dBm). Current when transmitting is also similar (8 mA for HC-06, 6 to 27 mA for TI BT LE units according to the link above).

The changes in frequency hopping in newer BT versions certainly are effective to reduce interference from devices that transmit in the same frequency range, like other Bluetooth devices. That they also have an effect on RF interference in the GPS frequency range is entirely hypothetical (and unlikely).

Been logging data via bluetooth for over 10 years now. If anything the accuracy has gotten better as the gps units have been upgraded and the error estimates have reduced. Can't see any evidence of RF interference causing problems...probably fake news as usual!

Here's the first doppler track I ever recorded via bluetooth with the UBlox 4 at 5 hz back on October 28th 2007. Even with 6 sats the +/- was 0.296 knots for the best 10 second run, It was mounted on the dashboard of the car.

Select to expand quote

boardsurfr said..

mathew said..
BT 4 uses ... lower power by 3 orders of magnitude.

Please stop posting completely misleading figures like "3 orders of magnitude". That is a ridiculous over-estimate for the use we discussed, transmitting GPS data while windsurfing. BT 4 LE uses significantly less power when the device does not transmit data ("A Bluetooth low energy device achieves low power consumption by keeping radio activity short and allowing the device to reside in standby or power down mode most of the operating time.", from http://www.ti.com/lit/an/swra478c/swra478c.pdf).

RF interference happens when the BT devices is actually sending data, which would happen at least 5 times per second. When transmitting, the power output from BT LE devices is in the same range (up to +5 dBm) as for the HC-06 (-4 to +6 dBm). Current when transmitting is also similar (8 mA for HC-06, 6 to 27 mA for TI BT LE units according to the link above).

The changes in frequency hopping in newer BT versions certainly are effective to reduce interference from devices that transmit in the same frequency range, like other Bluetooth devices. That they also have an effect on RF interference in the GPS frequency range is entirely hypothetical (and unlikely).

BT1-3 -> max-transmit power 100mW
BT4 -> max-transmit power 10mW
... so there is one order.

BT4 uses double the bandwidth for the same data-rate - so that is about x2 reduction.
BT4 is also designed to transmit much less power, for the same transmission-distance - basically an optimisation of hardware versioning. In practise, this is 20%-x5 lower transmit power.
... there is about another order.

Any practical implementation of direct-sequence spread spectrum coding, results ina significant reduction of required transmit power because you dont need to generate a high-power centre/carriar signal. In practise, that is about an order of magnitude reduction.

But most of that is irrelevant -> thekey factoris direct-sequencePN-coding. This type oftransmitter will send out the data with the spectral-density (aka bandwidth-power) *below the noise floor* for the bandwidth....only receivers keyed in to the same PN-coding, are able to re-assemble thesignal. Granted the noise floor is raised just a little,but we aretalking near-non-measurable difference ( I only managed to do it in a lab ) -juststanding outside in the sunlight is worse.And to make DSSS even better, you dont get anywhere near the number of high-power harmonics.

Frequency hopping is still used in BT4, but that is only to avoid transmitting at frequencies which are already congested.

I will add for clarity -the"orders of magnitude" thing is just a rule of thumb for engineering - it could be out of margin by x5... but that is still suitable for Fermi estimations... ref: what-if.xkcd.com/84/

Select to expand quote

Roo said..
Can't see any evidence of RF interference causing problems.

You'd actually have to look for it. We know how "careful" you are there. The data that you have actually posted onwww.seabreeze.com.au/forums/Windsurfing/Gps/GPS-Logit-with-10hz-external-BT-receiver?page=1 actually showedhighererrors for your ublox data than for the GT-31 over 2 secs and 10 secs.:
2 seconds U-Blox 10hz 35.524 +/- 0.987 GT-31 35.913 +/- 0.311
10 seconds U-Blox 10hz 34.378 +/- 0.412 GT-31 34.479 +/- 0.278

That would be one indication; ublox data usually have much lower error rates.

In another example you posted on www.seabreeze.com.au/forums/Windsurfing/Gps/18hz-GPS-units?page=1, the calculated ranges for your 10 second data did not overlap, indicating problems with your units.

Select to expand quote

mathew said..
BT1-3 -> max-transmit power 100mW
BT4 -> max-transmit power 10mW
... so there is one order.

Once again, your arguments are entirely theoretical, and you're ignoring facts just so you can "prove" your point. I have given you both the name of the BT module I used, and the power specs. The maximum transmit power of the HC-06 is 6 dBm, 4 mW. Compared to the theoretical max transit power of a 10 mW you give for BT4, BT 4 would actually be 2.5 x higher power.

The other arguments you give are also entirely based on theory. In practice, when talking about building a Bluetooth GPS, you're putting an RF emitter that puts out somewhere around 0 dBm (1 mW) next to an system that analyzes signals around -150 bBm (0.000000000000001 mW). You can rely on your theory, and hope for the best. Or you can actually build the system, and measure what you actually get. You'll need to build something where you can also measure with the RF emitter off, though, which Roo does not seem to understand.

It is quite possible that you get less RF interference with Bluetooth 4, but it is by no means certain. Reality might show that the opposite is true. The RF interference from the Raspberry Pi was quite noticeable, even with WiFi and BT off; RF interference killed further development of the Flysight for windsurfing.

But as I explained before, building a Bluetooth GPS to be used with a phone, rather than using an Openlog GPS and an optional phone, is rather pointless, even if RF interference would not be an issue.

I've just got version 2 working, sort of I think.

dispensed with the 2,200mAh powerbank, and replaced with an 800mAh lithium battery, and a couple of battery management modules.
This created enough spare space to also include the serial to USB converter. I've also added a couple of switches to change output of the Neo from the logger to the converter.

The charger works well, cutting out exactly at 4.2 volts, but the over discharge module, seems to need to be wakened by the charger before it connects the battery. This would be a bit of a pain if you didn't have a charger with you.
The instructions do mention this but it's ambiguous, it reads like this happens with first use, and it seemed that way yesterday, when it turned on after being off for an hour or so. But this morning, nothing until I plugged the charger in.

The converter is working OK, so I've changed from 5hz to 10hz for a discharge test, to see how much I get out of the 800mAh battery.
At 45mA drain it should last 17hrs, only 2hrs less than the 2,200. I'll find out tomorrow, and also see if the over discharge protection works.

The 10hz trial is in a fail state, I'm getting missed data points as Raymond warned would happen. I had hopped that the open logger would be able to cope with the SD card write problem, but it seems not.

When I'm happy with it, I'll start a new thread about V2

Select to expand quote

decrepit said..
I've just got version 2 working, sort of I think.

dispensed with the 2,200mAh powerbank, and replaced with an 800mAh lithium battery, and a couple of battery management modules.
This created enough spare space to also include the serial to USB converter. I've also added a couple of switches to change output of the Neo from the logger to the converter.

The charger works well, cutting out exactly at 4.2 volts, but the over discharge module, seems to need to be wakened by the charger before it connects the battery. This would be a bit of a pain if you didn't have a charger with you.
The instructions do mention this but it's ambiguous, it reads like this happens with first use, and it seemed that way yesterday, when it turned on after being off for an hour or so. But this morning, nothing until I plugged the charger in.

The converter is working OK, so I've changed from 5hz to 10hz for a discharge test, to see how much I get out of the 800mAh battery.
At 45mA drain it should last 17hrs, only 2hrs less than the 2,200. I'll find out tomorrow, and also see if the over discharge protection works.

The 10hz trial is in a fail state, I'm getting missed data points as Raymond warned would happen. I had hopped that the open logger would be able to cope with the SD card write problem, but it seems not.

When I'm happy with it, I'll start a new thread about V2

I tested the overdischarge modules by using a variable power supply and just wound it down until the voltage hit about 2.5v, before it cut out. What I saw in practice was that the module would cut the power it supplied, but the terminal voltage would creep up a bit, and then it would turn the power on again.

What module are you using for discharge protection? I don't think mine needed any special attention.

As for not being able to keep up with 10hz updates, I am not surprised. The problem is always going to be that the SD card sometimes needs time to reallocate file blocks and the low end Arduinos don't have enough buffering capacity to outlast the SD card wait time. In theory this should be better if the card is reformatted each time (I think), but the approach others have used is to create a blank file so that the SD card doesn't need to allocate new block as it already has them.

Select to expand quote

FormulaNova said..
>>>>>, but the approach others have used is to create a blank file so that the SD card doesn't need to allocate new block as it already has them.

Thanks Formula, but you've lost me there, a blank file where? And do you name it?
And I suppose you have to do this before every use?

I've bought these two modules.
Charger,
6W 5V UPS mobile power Diy Board Charger & Step-up DC DC Converter Module for 3.7V 18650 lithium battery
Model Number: DD05CVSB_5V

Over discharge protection.
3.7V 4.2V 3A Li-ion Lithium Battery Charger Over Charge Discharge Overcurrent Protection Board for 18650 TP4056 DD05CVSA
Model Number: DD04CPMA

And this is the ambiguous note.

Note: Please charge the first time, activate the protection board. Otherwise there is no voltage output

G'day Mike,

How far away are we with these beasties?

My GT11 (yes Old school) is showing worry symptoms of an imminent demise (randomly records) and I don't want to waste my money on a watch which I can't read and is liable to fall apart inside of a couple of years.

Select to expand quote

Note: Please charge the first time, activate the protection board. Otherwise there is no voltage output

My Guess:
The TP4056 has an internal P-FET which isolates the TP4056 from its Battery in under voltage shutdown mode (and also first time use).
Plugging TP4056 into a 5V usb cable (charge mode) will be needed to turn the P-FET on and allow the battery to power the TP4056 again. If the battery has charge in it, then plugging the 5V USB in for a few seconds is all the is needed to get things up and running.

Alby, how long is a piece of string??????
Mine is going, it's approved and I've posted with it the last few sessions.
But I'm still playing with improving it one way or another.

If you use a genuine Neo 8m module with an open logger, it shouldn't be a problem to approve it.
Depends on how much work you want to put in yourself, and how "elegant" you want the finished product.

My problem it seems is my trial and error approach to things, I'm not much good at planning out the whole job before I start, I have little design skills. So I start off with a rough idea of what I want, then try and solve problems as I go.

This latest version was going fine, up to the stage I had the two boards loosely coupled for testing. My idea was to join the two boards together with spacers and screws, but discovered that although there are spacers on both boards to do this, none line up! So it's back to sticky tape.

Looks like a good guess Steve, but it's weird after being off for 10hrs last night it switched on without a charge, But yesterday after being off for a day or so, while I worked on it, a charge was necessary. I'm sure the charger didn't get disconnected from the battery while I was doing it.

Discharge test gave me 10hrs 45mins, but looks like the under voltage protection cut out a bit early.
At 0830 the battery was at 3.07v, at 0840 it had turned off and the battery was at 3.0v and wouldn't turn back on. I'm not too concerned by this I'd rather have it turn off early than late!
And the load voltage was probably lower than the open cct voltage.
I'll see if I can find a discharge curve, to see how much I'm missing.

Well not much looking at this!!!!!!!!!!!!!!!!!!!

I just checked the discharge file. Starts off at 10hz (0.1s intervals) with a few missed points, (0.2s between points), to slowly change to 5hz (0.2s intervals) with the occasional 0.1s thrown in. then the occasional 0.1s disappear to be replaced by 0.3s further down the track.

I had deleted all files (except the config.txt) from the card, and emptied the rubbish, but the new file was still the next number in the old sequence. Checking the 5hz 19hr discharge file using the powerbank, it had 0.2s intervals all the way through.

Maybe the card does need reformatting fairly often, or I need to find out about making this "blank file"?

Found an article on the arduino forums, saying older sd cards may work better than new ones. So I've exchanged a class 4 out of the wife's tablet with the class 10 I was using. Out for a test now, this SD card has been half full of pics and music. I only erased it all, so if results are poor I'll try reformatting it.

Didn't help, worse after formatting in my linux box, maybe I'll try formatting with windows. But running out of time now, will have to wait till later.

SD cards are delicate devices, I discovered myself.
I've been using Micro-SD cards with SLC memory and dualcore cpu's
No I didn't make a typo...

At 1hz a lot of cards are fine, around 5hz it starts to get special.
!0hz is already an issue and at 18hz you start to pull your hairs...

My advice : Samsung
5hz : EVO/EVO+
10Hz : PRO/Pro+

Tonight I ordered the PCB for7th revision Gyro GPS...
forum.windsurfing.nl/viewtopic.php?f=62&t=13890429&start=690

Select to expand quote

raymondw said..
SD cards are delicate devices, I discovered myself.
I've been using Micro-SD cards with SLC memory and dualcore cpu's
No I didn't make a typo...

At 1hz a lot of cards are fine, around 5hz it starts to get special.
!0hz is already an issue and at 18hz you start to pull your hairs...

My advice : Samsung
5hz : EVO/EVO+
10Hz : PRO/Pro+

Tonight I ordered the PCB for7th revision Gyro GPS...
forum.windsurfing.nl/viewtopic.php?f=62&t=13890429&start=690

By 'delicate', do you mean that they can't handle high frequency updates? Are you buffering the data or writing it at 18 times a second?

Select to expand quote

FormulaNova said..
By 'delicate', do you mean that they can't handle high frequency updates? Are you buffering the data or writing it at 18 times a second?

SD cards can't handle 18Hz updates if you write it directly with all the info you need, not even the Samsung cards.
When a SD card needs to allocate an empty block it can take between 400 and 800ms.
During this allocation you will loose data as (most) loggers can't buffer the data.

Fairly soon after I tested multiple SD cards I created a big buffer and instead of writing per update I started writing per block.
As I write per block I created multiple buffers that can handle SD block allocation.
Last trick I use is a continuous allocated file, this also handles block allocation OR slow SD cards.

BUT... the Ublox 8 chip only supports 18Hz on 1 GNSS
If you step back to 10Hz, you can use 2 GNSS networks, at 3Hz you can use 3.
At the moment I log data at 10Hz with GPS and Glonass, but as soon as it is more stable I will add Galileo and log at 3Hz
1 GNSS gives a deviation around 0.1/0.3km/h (0.05/0.16kts)
2 GNSS networks give a deviation around 0.03/0.08km/h (0.016/0.04kts)
3 networks is not really clear yet, I think the deviation will be around 0.005km/h (0.002kts)
(Yes, the Gyro supports Galileo already, every GNSS chip is updated to the latest Ublox firmware and the antenna is prepared)

Although you get more data per GNSS update, lower Hz rates is a bit less data.

I received an old Skytrack Venus816, it updates at 40hz and my unit can handle the data without missing a GNSS point.

Select to expand quote

raymondw said..
If you step back to 10Hz, you can use 2 GNSS networks, at 3Hz you can use 3.
At the moment I log data at 10Hz with GPS and Glonass, but as soon as it is more stable I will add Galileo and log at 3Hz
1 GNSS gives a deviation around 0.1/0.3km/h (0.05/0.16kts)
2 GNSS networks give a deviation around 0.03/0.08km/h (0.016/0.04kts)
3 networks is not really clear yet, I think the deviation will be around 0.005km/h (0.002kts)

I have no problem getting GPS, Glonass, and Galileo at 5 Hz. In a sample that I looked at in u-center, there were about 4 Galileo satellites tracked, and 9-10 each GPS and Glonass. Typical total sat numbers are around 20-24 for three systems, and ~16-18 for GPS and Glonass only.

Adding Glonass to GPS roughly doubles the number of satellites tracked, so the improvement in accuracy is quite noticeable. Also adding Galileo has a smaller, but still noticeable, effect. It's not nearly as large as the numbers you gave, nor would I expect it to be.

Select to expand quote

boardsurfr said..

I have no problem getting GPS, Glonass, and Galileo at 5 Hz. In a sample that I looked at in u-center, there were about 4 Galileo satellites tracked, and 9-10 each GPS and Glonass. Typical total sat numbers are around 20-24 for three systems, and ~16-18 for GPS and Glonass only.

Adding Glonass to GPS roughly doubles the number of satellites tracked, so the improvement in accuracy is quite noticeable. Also adding Galileo has a smaller, but still noticeable, effect. It's not nearly as large as the numbers you gave, nor would I expect it to be.

Keep in mind I spend a fair amount of time researching different chips and antennas.

This is the datasheet from the
NEO-M8 series : www.u-blox.com/sites/default/files/NEO-M8-FW3_DataSheet_%28UBX-15031086%29.pdf
MAX-M8 series : www.u-blox.com/sites/default/files/MAX-M8-FW3_DataSheet_%28UBX-15031506%29.pdf
FW for NEO v3 info : https://www.u-blox.com/sites/default/files/GNSS-FW3.01_ReleaseNotes_(UBX-16000319)_Public.pdf
Depending on the used chip there is a certain Hz rate possible, for my units I wanted integrated LNA, flash based FW (upgrades!), etc etc
The whole MAX series wasn't an option and even in the NEO series there is only 1 chip available.


Quote from FW pdf : "4.12 Navigation rate
The recommended maximum navigation rate supported is 5Hz for standard multi-GNSS operation (GPS + SBAS+ GLONASS + QZSS) and 10Hz for single GNSS operation. When Galileo is enabled,then the maximum navigation rate when executed from flash is 3 Hz."

If you go above the advised values the Ublox WILL send out malformed GNSS packets, but it is almost impossible to know when.
When looking at your tracks you sometimes miss runs due to the malformed packets.
I've been researching this malformed packet behavior for several weeks and changed a lot of SD code as I suspected a faulty SD card.
Manfred even provided a software program to quickly detect the health of the logged UBX data.
In the end it was the Ublox chip dropping packets...

Select to expand quote

raymondw said..
If you go above the advised values the Ublox WILL send out malformed GNSS packets, but it is almost impossible to know when.

I assume that with GNSS packets you mean records in the .ubx file, right? What problems did you observe exactly? Some possible scenarios would be:
- completely dropped records
- incomplete records (missing bytes)
- complete records but checksum errors
- records complete and checksum ok, but otherwise unusable (e.g. flags set as invalid, numbers clearly out of range, etc.)

Some of these (likely missing and partial records) would be quite obvious when I look at data in my parser, but others might theoretically slip through, so any additional info you may have would be appreciated.

Select to expand quote

raymondw said..
The recommended maximum navigation rate supported is 5Hz for standard multi-GNSS operation (GPS + SBAS+ GLONASS + QZSS) and 10Hz for single GNSS operation. When Galileo is enabled,then the maximum navigation rate when executed from flash is 3 Hz."

That actually sounds like an argument against recording at 10 Hz for GPS+GLONASS.

Select to expand quote

raymondw said..

When Galileo is enabled,then the maximum navigation rate when executed from flash is 3 Hz."

The "when executed from Flash" apparently is quite important. When the version 3 firmware was released, the only option was to run from Flash, which is slower than ROM. The comments to one post on the u-blox forum (portal.u-blox.com/s/) states:
" u-Blox is updating the silicon with a new ROM (3.01) which allows it to run faster and support higher navigation rates."

This post is from 2016, and the guy who posted the comment appears to know what he is doing ("Senior Principal Expert", ranked #1 on the u-blox forum).

It seems quite likely that the 3 Hz limitation applies to older chips that required firmware update, but that newer chips have the newer firmware in ROM and can therefore support higher rates.

I think the bigger issue is that GPSResults still discards tracks when a single point is missing or invalid. That was appropriate in with 1-Hz data from GT-31s, but makes no sense with 5 Hz or 10 Hz data. Even with single missing points every now and then, 5 Hz data still have significantly more information than 1 Hz or 3 Hz data. In contrast to GT-31 data, single missing points do not indicate a major problem in higher frequency data. Missing points are actually quite common - but as you say, you have to look for them, otherwise you may never notice. IIRC, ka72.com actually allows single missing point for categories other than 2 and 10 seconds.

Select to expand quote

boardsurfr said..
I assume that with GNSS packets you mean records in the .ubx file, right? What problems did you observe exactly? Some possible scenarios would be:
- completely dropped records
- incomplete records (missing bytes)
- complete records but checksum errors
- records complete and checksum ok, but otherwise unusable (e.g. flags set as invalid, numbers clearly out of range, etc.)

Some of these (likely missing and partial records) would be quite obvious when I look at data in my parser, but others might theoretically slip through, so any additional info you may have would be appreciated.

That actually sounds like an argument against recording at 10 Hz for GPS+GLONASS.

Problems I found where incomplete packets.
Most problematic areas where around packets where with large transfers.
UBX-NAV-SAT is needed to track satellites, but even at 1Hz it generates a lot of load within the Ublox 8 chip.
This is a requirement for the (at this time not active used) Record ranking.

Select to expand quote

boardsurfr said..
The "when executed from Flash" apparently is quite important. When the version 3 firmware was released, the only option was to run from Flash, which is slower than ROM. The comments to one post on the u-blox forum (portal.u-blox.com/s/) states:
" u-Blox is updating the silicon with a new ROM (3.01) which allows it to run faster and support higher navigation rates."

This post is from 2016, and the guy who posted the comment appears to know what he is doing ("Senior Principal Expert", ranked #1 on the u-blox forum).

It seems quite likely that the 3 Hz limitation applies to older chips that required firmware update, but that newer chips have the newer firmware in ROM and can therefore support higher rates.

I think the bigger issue is that GPSResults still discards tracks when a single point is missing or invalid. That was appropriate in with 1-Hz data from GT-31s, but makes no sense with 5 Hz or 10 Hz data. Even with single missing points every now and then, 5 Hz data still have significantly more information than 1 Hz or 3 Hz data. In contrast to GT-31 data, single missing points do not indicate a major problem in higher frequency data. Missing points are actually quite common - but as you say, you have to look for them, otherwise you may never notice. IIRC, ka72.com actually allows single missing point for categories other than 2 and 10 seconds.

You have to consult the company which delivers your Ublox units.
My source has 2 part numbers, when you bom for details the difference is FW, v2 or v3.

When you log data from the Ublox chip you should not see missing points.
You can see invalid points, but if something is missing there is something else happening.
Since August 2017 I check almost every session on missing data points with the Ublox parser, so far only a false positive at the start or end of a file.

But I agree on the point that a single invalid or missing datapoint should be fine IF the track is at high Hz rates.
Maybe =>3Hz for 3 networks and =>5Hz for 2 networks, this is the current state of the available technology.

What is better, 3 GNSS networks at 3Hz (maybe 5hz) or 2 GNSS networks at 5 or 10Hz.
That is something I would like to test when there is enough coverage from Galileo.
(Maybe I'll start with that today if I have some spare time)

Select to expand quote

raymondw said..
UBX-NAV-SAT is needed to track satellites, but even at 1Hz it generates a lot of load within the Ublox 8 chip.
This is a requirement for the (at this time not active used) Record ranking.

At least 99.99% of all GPS speedsurfing sessions are not for record rankings, and normal track analysis does not use NAV-SAT info. That includes all GPSTC sessions. So recording it all the time makes no sense to me. It could be a setting that users can activate if they go for official records.

Logging NAV-SAT at the same frequency as speed data increases data load and file size by a factor of 5 when using three GNSS systems. That can easily overwhelm data pipelines, I have seen that happen. Even when logging NAV-SAT just once per second, and NAV-PVT at 3 Hz, adding NAV-SAT more than doubles the data load. Worse, since NAV-SAT sentences can be almost 400 bytes long, compared to 92 bytes for NAV-PVT, chances of buffer overflow increase dramatically. That's easy to see with Openlog recorders, where the buffer size is only about 500 bytes, but other setups will also have some limitations in the data pipeline.

To me, it makes more sense to only records the data that's actually needed and used (NAV-PVT). It includes the number of satellites tracked, which is the only satellite number actually used by filters. Everything else may be useful for initial development and perhaps for official record attempts, but completely useless for general session tracking or GPSTC.

Select to expand quote

boardsurfr said..
At least 99.99% of all GPS speedsurfing sessions are not for record rankings, and normal track analysis does not use NAV-SAT info. That includes all GPSTC sessions. So recording it all the time makes no sense to me. It could be a setting that users can activate if they go for official records.

Logging NAV-SAT at the same frequency as speed data increases data load and file size by a factor of 5 when using three GNSS systems. That can easily overwhelm data pipelines, I have seen that happen. Even when logging NAV-SAT just once per second, and NAV-PVT at 3 Hz, adding NAV-SAT more than doubles the data load. Worse, since NAV-SAT sentences can be almost 400 bytes long, compared to 92 bytes for NAV-PVT, chances of buffer overflow increase dramatically. That's easy to see with Openlog recorders, where the buffer size is only about 500 bytes, but other setups will also have some limitations in the data pipeline.

To me, it makes more sense to only records the data that's actually needed and used (NAV-PVT). It includes the number of satellites tracked, which is the only satellite number actually used by filters. Everything else may be useful for initial development and perhaps for official record attempts, but completely useless for general session tracking or GPSTC.

I have NAV-SAT at 1Hz per request of Manfred(/GP3S) as an option available.
My logger has more than enough buffers to catch 400bytes, it is an issue happening within the Ublox chip.
Even on lower Hz settings (less data) the cut off strings will appear.

I record the sentences below, and agree that it is enough for normal postings.
NAV-PVT
NAV-DOP
Everything else is turned off.
I've tested different power settings, air modes etc etc etc and found a decent mix that works fine.

Select to expand quote

raymondw said..

boardsurfr said..
At least 99.99% of all GPS speedsurfing sessions are not for record rankings, and normal track analysis does not use NAV-SAT info. That includes all GPSTC sessions. So recording it all the time makes no sense to me. It could be a setting that users can activate if they go for official records.

Logging NAV-SAT at the same frequency as speed data increases data load and file size by a factor of 5 when using three GNSS systems. That can easily overwhelm data pipelines, I have seen that happen. Even when logging NAV-SAT just once per second, and NAV-PVT at 3 Hz, adding NAV-SAT more than doubles the data load. Worse, since NAV-SAT sentences can be almost 400 bytes long, compared to 92 bytes for NAV-PVT, chances of buffer overflow increase dramatically. That's easy to see with Openlog recorders, where the buffer size is only about 500 bytes, but other setups will also have some limitations in the data pipeline.

To me, it makes more sense to only records the data that's actually needed and used (NAV-PVT). It includes the number of satellites tracked, which is the only satellite number actually used by filters. Everything else may be useful for initial development and perhaps for official record attempts, but completely useless for general session tracking or GPSTC.

I have NAV-SAT at 1Hz per request of Manfred(/GP3S) as an option available.
My logger has more than enough buffers to catch 400bytes, it is an issue happening within the Ublox chip.
Even on lower Hz settings (less data) the cut off strings will appear.

I record the sentences below, and agree that it is enough for normal postings.
NAV-PVT
NAV-DOP
Everything else is turned off.
I've tested different power settings, air modes etc etc etc and found a decent mix that works fine.

I agree that NAV-PVT and NAV-DOP are all that is required for normal postings.

I suspect that it is also all that is required for any records as well, but I would have to look into it a bit more to be sure.

I record NAV-PVT and NAV-DOP @ 10Hz and NAV-SAT @ 1Hz with BT GPS Logit as that is the way Manfred has set it up. I have NO problem with missed points in this case with the two BT GPS I have.

I suspect we included the requirement for NAV-SAT when older UBLOX chips did not produce the NAV-PVT sentence. (M6-Wintek G-Rays)

I've just been using NAV PVT, that seems to give everything needed.

OK I'm back from relaxing in Bali, so I've been playing with SD cards and their 10hz results.
Although I read somewhere that the open logger didn't benefit from newer faster cards speed, I had to try it.
So I pinched the cards from a couple of phones, an ultra HC1 and an older class 4.
First I bench marked them with results as expected.

Ubuntu 14 "disks" benchmarks
old class 4
Average read speed 18.1 MB/s, Average write speed 3.2 MB/s, access timr 1.89msec

ultra HC1
Average write speed 35.1 MB/s, Average write speed 7.6 MB/s, access time 1.07msec

Device set to 10hz, left outside for about half hour, and various minutes worth of data checked for missing points, (0.2sec instead of 0.1secs intervals)

class 4 about 6 to 10 misses per minute
ultra HC1 about 25 to 30 misses per minute

The original card I had in this was a class 10, that is confusing, part of it has only 3 or 4 missing points per minute, but others have closer to 50 missing points per minute.

I've ordered another logger, based on the open logger, but with a bigger buffer, a full size HC SD card support, higher baud rate and usb download.
Fingers crossed, it will do 10hz.

More later.

As raymondw has pointed out, the bottleneck may not be in the logger or the SD card at all. If you have a u-blox 8 chip where the firmware needed to be upgraded and now is run from Flash, the chip will definitely be the problem, so not logger (Openlog, Pi, or whatever) will record at 10 Hz.

Even if you had a chip that can record at 10 Hz when using 3 GPS systems, the accuracy gain from going to 10 Hz from 5 Hz will be marginal at best. If you use 3 systems at 5 Hz, but just 2 at 10 Hz, the accuracy at 5 Hz is likely to be better.