Posted by Bill Nesbitt on November 5, 2010 at 1:55pm
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.
You need to be a member of diydrones to add comments!
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 ( www.ryanmechatronics.com ). Your project sound like it is on the high end of precision timing, shoot us an email if you think we can help...
Replies
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 ( www.ryanmechatronics.com ). Your project sound like it is on the high end of precision timing, shoot us an email if you think we can help...