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.
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.
If you would like to contribute to this library: please do, we truly appreciate it, but please follow these guidelines. Thanks!
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:
autoHPPOSLLH
autoDOP
autoHNRAtt
autoHNRDyn
autoHNRPVT
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.
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.