Skip to content

Library to control UBX binary protocol and NMEA over I2C on Ublox GPS modules

License

Notifications You must be signed in to change notification settings

mayopan/SparkFun_Ublox_Arduino_Library

 
 

Repository files navigation

SparkFun Ublox Arduino Library

SparkFun GPS-RTK2 - ZED-F9P (GPS-15136) SparkFun GPS-RTK - NEO-M8P-2 (GPS-15005) SparkFun ZOE-M8Q Breakout (GPS-15193) SparkFun SAM-M8Q Breakout (GPS-15210) SparkFun NEO-M9N Breakout (GPS-15733)

Ublox makes some incredible GPS receivers covering everything from low-cost, highly configurable modules such as the SAM-M8Q all the way up to the surveyor grade ZED-F9P with precision of the diameter of a dime. This library focuses on configuration and control of Ublox devices over I2C (called DDC by Ublox) and Serial. The UBX protocol is supported over both I2C and serial, and is a much easier and lighterweight interface to a GPS module. Stop parsing NMEA data! And simply ask for the datums you need.

This library can be installed via the Arduino Library manager. Search for SparkFun Ublox.

Want to help? Please do! We are always looking for ways to improve and build out features of this library.

  • We are always interested in adding SPI support with a checkUbloxSPI() function

Thanks to:

  • trycoon for fixing the lack of I2C buffer length defines
  • tve for building out serial additions and examples
  • Redstoned and davidallenmann for adding PVT date and time
  • wittend for pointing out the RTCM print bug
  • Big thanks to PaulZC for implementing the combined key ValSet method, geofence functions, better saveConfig handling, as well as a bunch of small fixes.
  • RollieRowland for adding HPPOSLLH (High Precision Geodetic Position)
  • tedder for moving iTOW to PVT instead of HPPOS and comment cleanup
  • grexjmo for pushing for a better NMEA sentence configuration method
  • averywallis for adding good comments to the various constants.

Need a library for the Ublox and Particle? Checkout the Particle library fork.

Repository Contents

  • /examples - Example sketches for the library (.ino). Run these from the Arduino IDE.
  • /src - Source files for the library (.cpp, .h).
  • keywords.txt - Keywords from this library that will be highlighted in the Arduino IDE.
  • library.properties - General library properties for the Arduino package manager.

Documentation

Polling vs. Auto-Reporting

This library supports two modes of operation for getting navigation information with the getPVT function (based on the UBX_NAV_PVT protocol packet): polling and auto-reporting.

The standard method is for the sketch to call getPVT (or one of the getLatitude, getLongitude, etc. methods) when it needs a fresh navigation solution. At that point the library sends a request to the GPS to produce a fresh solution. The GPS then waits until the next measurement occurs (e.g. once per second or as set using setNavigationFrequency) and then sends the fresh data. The advantage of this method is that the data received is always fresh, the downside is that getPVT can block until the next measurement is made by the GPS, e.g. up to 1 second if the nav frequency is set to one second.

An alternate method can be chosen using setAutoPVT(true) which instructs the GPS to send the navigation information (UBX_NAV_PVT packet) as soon as it is produced. This is the way the older NMEA navigation data has been used for years. The sketch continues to call getPVT as before but under the hood the library returns the data of the last solution received from the GPS, which may be a bit out of date (how much depends on the setNavigationFrequency value).

The advantage of this method is that getPVT does not block: it returns true if new data is available and false otherwise. The disadvantages are that the data may be a bit old and that buffering for these spontaneus UBX_NAV_PVT packets is required (100 bytes each). When using Serial the buffering is an issue because the std serial buffer is 32 or 64 bytes long depending on Arduino version. When using I2C the buffering is not an issue because the GPS device has at least 1KB of internal buffering (possibly as large as 4KB).

As an example, assume that the GPS is set to produce 5 navigation solutions per second and that the sketch only calls getPVT once a second, then the GPS will queue 5 packets in its internal buffer (about 500 bytes) and the library will read those when getPVT is called, update its internal copy of the nav data 5 times, and return true to the sketch. The sketch calls getLatitude, etc. and retrieve the data of the most recent of those 5 packets.

Products That Use This Library

  • GPS-16481 - SparkFun GPS-RTK-SMA Breakout - ZED-F9P (Qwiic)
  • GPS-15136 - SparkFun GPS-RTK2 Board - ZED-F9P (Qwiic)
  • GPS-15005 - SparkFun GPS-RTK Board - NEO-M8P-2 (Qwiic)
  • GPS-15210 - SparkFun GPS Breakout - Chip Antenna, SAM-M8Q (Qwiic)
  • GPS-15193 - SparkFun GPS Breakout - Chip Antenna, ZOE-M8Q (Qwiic)
  • GPS-15733 - SparkFun GPS Breakout - NEO-M9N, Chip Antenna (Qwiic)
  • GPS-15712 - SparkFun GPS Breakout - NEO-M9N, U.FL (Qwiic)
  • GPS-16329 - SparkFun GPS Dead Reckoning Breakout - NEO-M8U (Qwiic)
  • SPX-14980 - SparkX GPS-RTK Black
  • SPX-15106 - SparkX SAM-M8Q

License Information

This product is open source!

Various bits of the code have different licenses applied. Anything SparkFun wrote is beerware; if you see me (or any other SparkFun employee) at the local, and you've found our code helpful, please buy us a round!

Please use, reuse, and modify these files as you see fit. Please maintain attribution to SparkFun Electronics and release anything derivative under the same license.

Distributed as-is; no warranty is given.

  • Your friends at SparkFun.

About

Library to control UBX binary protocol and NMEA over I2C on Ublox GPS modules

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages

  • C++ 100.0%