sparkfun / SparkFun_Ublox_Arduino_Library

Library to control UBX binary protocol and NMEA over I2C on Ublox GPS modules
Other
141 stars 85 forks source link
arduino-library gps sparkfun ublox

SparkFun u-blox Arduino Library

Please note: this library is now deprecated. Please migrate to the new SparkFun u-blox GNSS Arduino Library.

You can find details on how to migrate to v2.0 here.

You can install v2.0 via the Arduino Library Manager. Search for SparkFun u-blox GNSS.

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)

U-blox 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 u-blox devices over I2C (called DDC by u-blox) 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 u-blox GNSS.

Although not an integrated part of the library, you will find an example of how to communicate with the older series 6 and 7 modules in the examples folder.

Max (400kHz) I2C Support

To achieve 400kHz I2C speed please be sure to remove all pull-ups on the I2C bus. Most, if not all, u-blox modules include pull ups on the I2C lines (sometimes called DDC in their manuals). Cut all I2C pull up jumpers and/or remove them from peripheral boards. Otherwise, various data glitches can occur. See issues 38 and 40 for more information. If possible, run the I2C bus at 100kHz.


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

Thanks to:

Need a Python version for Raspberry Pi? Checkout the Qwiic Ublox GPS Py module.

Need a library for the u-blox and Particle? Checkout the Particle library fork.

Need a C++ version which runs on Linux? Checkout the Ublox_Linux_Library.

Contributing

If you would like to contribute to this library: please do, we truly appreciate it, but please follow these guidelines. Thanks!

Repository Contents

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.

The library also supports:

Memory Usage

Version 1.8.9 introduced support for autoHNR on the NEO-M8U, and that tipped the balance in terms of RAM use on the ATmega328. The library does still run on the ATmega328 but you will see Low memory available, stability problems may occur warnings as the global variables now occupy 1540 bytes of RAM. If you do want to run this library on the ATmega328, you may need to regress to Version 1.8.8 via the Library Manager.

Products That Use This Library

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.