GPS-RTK2: outputting full 8-digit precision over I2C

GPS/GNSS Development Boards
1

Hi,

We are following the the tutorial GPS-RTK2 Hookup Guide using the recommended hardware SparkFun GPS-RTK2 Board, SparkFun BlackBoard, and SparkFun Bluetooth Mate Silver. It is mentioned there:

“If you want additional precision, you should consider using the UBX protocol which can output up to 8 digits of precision in dd.dddddddd format which will get you down to 1.11mm of precision! Be sure to checkout the examples in the SparkFun Ublox Arduino Library. We have various examples outputting the full 8 digits of precision over I2C without the burden of parsing NMEA sentences.”

However, none of the examples in the Ublox library (including the ones for high-precision data) output full 8-digit-precision latitude and longitude data for us with the BlackBoard on the Arduino serial monitor. It seems all of the latitude/longitude value we got have a 7-digit precision, instead, even though with U-Center, we were able to confirm that higher precision data are available.

Could you please give us some advice on how to get full 8 digits of precision over I2C?

Thanks,

Yaguang

2

Which example are you using?

3

Hi, Brandon! Thank you very much for your reply. We went through all the Ublox library examples applicable to the RTK-GPS 2 board (ZED-F9P) one by one. We were expecting those for fetching high-precision location information to generate the full 8-digit data, for example, Example8_GetHighPrecisionPositionAndAccuracy and Example9_GetHighPrecisionGeodeticPacket under examples/ZED-F9P, but the latitude and longitude values printed out on the serial monitor by these examples seem to have a precision of 7 digits instead of 8 as mentioned in the tutorial.

We have spent more time on this issue ourselves. The ZED-F9P Interface Description (available at https://www.u-blox.com/sites/default/fi … 854%29.pdf) mentions in Section 5.14.6.1 High Precision Geodetic Position Solution that Latitude and Longitude in the high-precision data message UBX-NAV-HPPOSLLH do have only 7 digits of precision (scaling = 1e-7). And 2 more digits lonHp (Byte Offset = 24) and latHp (Byte Offset = 25) can be obtained besides the normal 7-digit data, but they seem to be extracted out as part of the geoidSeparation value in the Ublox library src/SparkFun_Ublox_Arduino_Library.cpp (available at https://github.com/sparkfun/SparkFun_Ub … ibrary.cpp):

  • Line 755: geoidSeparation = extractLong(24);

    • Do you think this is a bug in the library?

    4

    Hello yaguang,

    That was really interesting. At first glance, my assumption was that the 8th (or 1st) digit was reserved for the coordinate sign (+/-). However, after speaking with our internal teams they’ll look further into it when they can. For now, it is officially posted as a [GitHub Issue.

    Thank you so much for your keen observation!](HPPOSLLH pulling wrong registers for lonHp/latHp · Issue #75 · sparkfun/SparkFun_Ublox_Arduino_Library · GitHub)

    5

    Thank you very much for your help! We will keep an eye on that GitHub Issue page.

    6

    Hi,

    We have added a fix for this to the library: Pull Request #90 https://github.com/sparkfun/SparkFun_Ub … ry/pull/90

    Can you please download and test the new code and check that it corrects the issues you were seeing?

    ZED-F9P\Example8_GetHighPrecisionPositionAndAccuracy shows how to use the new functions.

    Best wishes,

    Paul

    7

    Also note that you can use the ublox software to have it output 8 digits of precision in NMEA as well. It is technically against the NMEA standard (because it can exceed the maximum number of characters per message, but works great if your NMEA parser can handle more than 82 characters)

    Go to View → Generation 9 Configuration View → Advanced Configuratino → CFG-NMEA → CFG-NMEA-HIGHPREV and set the value to 1.