We have several outputs in the GPS message and in the Status word.
The GPS message that contains the GPSFixType, GPSFixStatusFlags, PositionAccuracyEst and PositionDOP is directly from the uBlox receiver (NAV-SOL: http://www.u-blox.com/images/downloads/Product_Docs/u-blox6_ReceiverDescriptionProtocolSpec_(GPS.G6-SW-10018).pdf#page=186).
- GPSFix can be 2D or 3D. In most cases, we see 3D.
- GPSFixStatusFlags provide information whether the time has been applied (e.g. time of week known; last bit is the GPS-fix indicator)
- PositionAccuracyEstimate is in cm (our exporter converts this to meters). This value will be somewhere between 2 and several hundreds of meter. We reject the GPS when the PositionAccuracyEstimate is higher than 25 meter.
- PositionDOP is the Dillution of Precision and is solely based on the GPS satellites in view. A ‘wide’ geometry, where satellites can be seen on the horizon and high in the sky gives the best value.
The StatusWord has two bits that apply to GPS:
- GPSFix is copied directly from bit 0 in the GPSFixStatusFlags in the uBlox NAV-SOL message.
- MTi-G Mode is the way the GPS data is used in the sensor fusion algorithm.
- A “3” means that the MTi-G is using the GPS data.
- A “1” means that the MTi-G was using GPS data and is now coasting/dead-reckoning the position based on the inertial sensors (the MTi-G is not using GPS data in this mode). This is done for 45 seconds, before the MTi-G Mode drops to “0”.
- A “0” means that the MTi-G doesn’t use GPS data and also that it doesn’t output position based on the inertial sensors.
- MTi-G Mode can discard GPS messages, even if the GPS Fix is valid. The MTi-G performs three checks on the GPS data to ensure robustness:
- Is there a GPS Fix, provided in the GPSFixStatusFlags?
- Is the PositionAccuracyEstimate better than a certain value (in most cases 25m)
- Is the latency less than 0.29s? This is difficult to notice, as the GPS data is still coming in, but the time stamp of the GPS messages is incorrect.