After spending many months tracking down all possible sources of error, I have come to the conclusion that the velocity and position reported by the UBlox LEA5H are not correct for the time reported by the module, but actually from many milliseconds in the past.

As part of a larger project, I am using the LEA5H reporting at 4Hz to observe and correct IMU data and biases. I have the time-pulse pin configured and triggering an external interrupt on my micro-controller to capture the exact time as dictated by the GPS's preceding UBX-TIM-TP message. This can then be correlated with the iTOW field in the NAV-VELNED & NAV-POSLLH messages to determine what local system time the velocity and position are supposed to correspond to. Keeping a history of what my IMU thought the velocity and speed was, I can compare the two at that moment and use the reported estimated accuracy to correct my internal estimates. Capturing all of this data in real-time at a rate of 200Hz, it is recorded to an on-board microSD card which can be analyzed post flight using parameter estimation software.

What I have found is that the speed and velocity indicated by the GPS are actually from an earlier time, and worse, they don't seem to be off by the same amount of time.

The position seems to lag by ~128ms and velocity by ~205ms. That is a lot of time for the accuracy that I am trying to achieve. These numbers pass visual inspection of the data as well as simulations and actual flight tests.

I'm wondering if anyone has any experience with this issue or can comment.

Views: 2652

Reply to This

Replies to This Discussion

Hi Bill,

The timepulse pin isn't primarily for time tagging the messages. They keep the jitter of the pulse (nominally 1 pulse per second) as low as possible so that you can sync / calibrate your hardware. This can be used to keep two different GPS receivers in sync or to get the typical microprocessor board low cost oscillator calibrated really well for example. It is also good for doing what you are doing, namely accounting for communciation and processing delays from the origination of the message in the U-blox to receipt by your microprocessor.

The latency that you are seeing is from the internal solution algorithm of the U-Blox, and will be found on all receivers to varying degrees. The receiver is mesauring the time of flight from the GPS satellites and forming the position and velocity solutions internally, but what you see It is the output from the internal velocity and position filters so there is a lag. It will vary with the type of filtering that you select in the unit as well (there are multiple settings, like "pedestrian" or "aircraft 4-G'). We've never been able to get a description of expected lag times from U-blox, but have measured about the same on velocity that you are showing...

We've been using U-Blox for about 8 years now, have it on most of our boards ( ). Your project sound like it is on the high end of precision timing, shoot us an email if you think we can help...
Thanks for the reply - I'm glad to see that this can be confirmed.

Yes, based of the GPS time-pulse precision, it was interesting to find that my micro-controller / crystal combination thinks there are 1003770us in a second :)

It sounds like the timestamp on the velocity and position messages is little more than a "stake in the sand." For my application (fairly aggressive, precise maneuvering in potentially challenging wind conditions) I need to know exactly what to expect of the GPS data - most importantly timing. I'm using the "portable" filter settings of the Ublox as my accelerations are normally under 1g and max velocities under 10m/s. Based on your experience, can you share any of your timing data for the various filter settings?

I very much like the Ublox units for their size, ease of use and especially their binary protocol, but can adapt to anything that may offer better or more predictable performance. Is there any other GPS module manufacturer that you can recommend looking at for this type of application?

Any tips would be appreciated.
Hi Bill,

The portable settings are for handheld type use and may have more filtering (pedestrians don't like seeing numbers jump around) but might have higher lag. Not sure, it has been awhile since we did our tests. We typically go with the 1g aircraft settings, for our applications it seems to balance solution noise with other criteria.

As for other modules, they all take range measurments to satellites and form the 3D velocity and position solutions, so for a PVT or velocity output you'll always have this kind of lag, though worse in some than others. Those filters have to handle adding or subtracting data from satellites that are newly visible or disappear from view among lots of other factors. We stopped looking awhile ago for anyone to describe their internal filter, and the U-Blox stuff seemed to have the smallest lag.

We like the size as well...we use the NEO-5Q series on our Monkey board...nice and tiny, so it lets us put some other active LNA/SAW circuitry for the on board antenna...

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service