Question about parsing the UBX sentence MSG_SOL and MSG_VELNED

[hmeijdam]

Two years ago I created an S-port GPS module from an Arduino with UBLOX-NEO6 module. I turned off all NMEA sentences set the GPS rate to 2,5HZ and airborne <4G and then just use the UBX message UBX_VELNED (VELocity North East Down) to measure speed in a pylonracer. So far so good, but as the pylonracer has high G turns, the GPS will have a bad fix frequently and show values like 900 km/h. I wish that was true
In slower planes the performance was acceptable.

When looking at the GPS sourcecode in OpenXsensor, I think this is done better as OpenXsensor uses the UBX_SOL message to check for a valid GPS fix.

Now my question: Is there an order relation between the UBX_SOL and the UBX_VELNED messages, leaving the GPS module? When I parse a UBX_SOL message that tells me I have no (or only a 2D) GPS fix, should I discard the next UBX_VELNED message that follows that UBX_SOL message or the previous UBX_VELNED message that came out of the module just before the UBX_SOL message? or both?

note; for Ublox M7N and higher I could use the UBX_PVT message that has speed and GPS fix information in one sentence, but would like to learn and improve on my old design.

-Hans

[mstrens]

Sorry but I do not know the answer.

[Kilrah]

Each sentence is "how it is now", not "the next frame is invalid". Whether the previous frame is also already bad enough to have to be considered invalid is kind of impossible to know...

But anyway you can't just look at the fix to know if the data is correct, in these high G scenarios the GPS will typically tell you it's got a perfectly good fix even when the data is completely off. Even HDOP may not start to rise until seconds later if at all.

[hmeijdam]

You may be right about the GPS responding too slow to flag bad values. If it is "how it is now" the UBX_PVT may be a better datasource. I have a NEO-7 now, so could test with that.
I forgot to mention that I created a second version, where I added a G-sensor and stopped the output to telemetry while G-forces > 4. that improved the data quality only to some extend.
I saw some Kalman filter code within the OpenXsensor source, however not sure if it is actively used. Maybe worth a try to see if a kalman filter can help filtering out the velocity spikes.

[mstrens]

The kalman filter is used to calculate a vertical speed using the pressure sensor (converted in altitude) as wel as the vertical acceleration.

It is not foreseen for the velocity spikes.