Over the past week, I've analysed all 12 years worth of GT-31 and Motion logs from Weymouth Speed Week, looking for oddities from the GT-31 (SiRF) and Motion (u-blox).

I'd never really payed much attention to the phantom speeds that u-blox chipsets often report after a crash. These are clearly due to the functionality that u-blox calls "Dead Reckoning, Extrapolating Positioning".

I've finally taken a closer look and briefly documented the behavior (including the u-blox description) at logiqx.github.io/gps-details/devices/motion/fix/

You may recall the "ON-FIX" logging of the GT-31. My thinking is that "on fix" logging should probably be implemented in the Motion and ESP-GPS as well, plus any other u-blox loggers for our sport.

The "on fix" filter should be an easy thing to implement as we already have log filtering in the custom Motion firmware for Weymouth Speed Week - min speed = 5 knots.

Please have a read of my document and let me know your thoughts!

The u-blox chips output an HDOP of 99.99 when this occurs and sats of 0. Thus in GPSResults / Gpsar / GPS Speedreader, no additional filtering is required to prevent these from affecting session results because of the existing sats / HDOP filters.

The main issue is that these nav-pvt frames are completely fabricated and don't impart any useful information. About the only genuine data they contain is the timestamp when the u-blox chip was unable to produce a proper nav solution.

An issue with these frames is that they can make it look like the Motion + ESP sometimes do weird things when in fact they produce great results. The "no fix" points affect speed + sAcc graphs and plot positions that never occurred in reality. This potentially has more consequences when a GPX file ends up in other ecosystems.

I mentioned that Locosys devices drop "no fix" points because they are not deemed useful. They only really indicate that the receiver was unable to track the satellites and could not produce a nav solution. I don't really see an upside to saving confusing points, when their absence indicates the same thing (no signal) but less ambiguously.

I agree that raw data should not be tampered with. There is an option to change the DR behavior via UBX-CFG-NAV5. It is not specified whether drLimit = 0 means "never", or "indefinitely". The DR behavior is essentially for cars / pedestrians in tunnels where it is reasonable to assume the speed is constant, whereas for us it is 100% due to submersion (or being inside a thick building).

I think perhaps it would be worth testing the effects of drLimit = 1 in UBX-CFG-NAV5 and once it is confirmed that it stops the DR behavior exceeding 1 second, try drLimit = 0 to see if it disables DR entirely. Changing a setting obviously isn't tampering with data, simply choosing behaviour best suited to the use case.

I feel like >99% of users will benefit from DR being disabled (whether via drLimit or filtering), but ESP developers / testers may wish to enable it on occasion (although I'm struggling to think how DR would be useful during a crash).

I managed to produce a very large number of u-blox artifacts (while trying to learn winging). After looking at a lot of them, I do not quite trust the u-blox fix flag. Sure, when it's set to "no fix", there is no fix, but quite often, the chips seems rather hesitant to go to the no-fix stage. My suspicion is that there often is a delay of a few seconds before the u-blox gives up, and says so in it's flags. I often go and remove top speeds from wing sessions if the 2 second peak is immediately followed by a filtered records (usually due to high sAcc values, sometimes also due to 0 sats).

I don't have a problem with disabling dead reckoning, or limiting it to 1 second. However, I do think that even the nonsense data do give us useful information - if nothing else, about the behavior of the chip. I could try the effect of setting DR to 0 easily with my OpenLog based loggers, except that I did not bring the required cable for our winter trip.

Am I missing something?

Those crazy artefacts you see when the units are brought into the building at the end?

It doesn't really happen in 99.9% of cases because we turn the GPS off at the waters edge after our session - except of course for the dummies (myself included. ) who forget to and drive home with them going. But in that case it is pretty obvious to anyone who is paying attention and the file is trimmed. problem solved, easy peasy.

Same thing with the building stuff? Just trim file? Ahh... but i see this could be a problem if you are trying to process scores of files for and event quickly.

So can you configure a software processing filter to pick up the no fix situation for that specific situation?

And, of course it would be great if a filter could be configured in the processing software to catch the crash produced spike situation as well.

Just to clarify. The building induced spikes are not caused by the DR behaviour. I only mentioned building induced spikes as they relate to Peter's observations that bad data can be logged prior to a u-blox receiver losing its lock on the satellites, or shortly after re-acquisition (whilst claiming to have a 3D fix).

FWIW, we keep the WSW unit switched on so that we can pull the data quickly and easily... 3 button presses and the data appears on our laptop. When you've got 100 units to do, knowing the state (on / off) and not having to check them or power them up is very helpful. People also go in and out of the building throughout the day, so building induced spikes happen at all sorts of times (and very occasionally the same artifacts can be seen during a crash).

Inhibiting DR (either via config or filters) has the potential to be a quick win for everyone. The large spikes (building or crash induced) are a little more involved, but I'm in the process of documenting some possible options (via config or filters) and the analysis that justifies their worth.

Back to the DR topic. Is anyone in a position to experiment with the drLimit parameter in the ESP?

rp6conrad said..
In the ublox M6 datasheet, the default value for DR is 0 seconds.
In the ublox M8 datasheet, the DR value is "reserved" (means : do not change it ?)

13 U1 - drLimit s Reserved
I can try to read it out with a M8, but if it is already zero, it does not make sense to give it a higher value...

Zero must be indefinite then. Would be interesting to see the effect of 1.

JulienLe said..
If I recall correctly (2018 stuff), invalid frames on Motions had every field changed to 0 except UTC and checksum but I was asked to remove this feature and produce the full raw output of the receiver at all time.

I'm also not sure this has anything to do with dead reckoning, the receiver just carries on outputting whatever trash the velpos computation arrays currently contain. It's up to the competition/software/user to check the validity flags of each frame first. I check for time valid, FIX 3D and output filter valid.

This can change. I'd like it better if invalid frames weren't logged at all. Yall discuss it together and let me know. :)

Why cant this be user configureable?

Issue solved.