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.
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.
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.
blazczak and geeksville for adding support for the series 6 and 7 modules.
bjorn@unsurv for adding powerOff and powerOffWithInterrupt.
dotMorten for the MSGOUT keys, autoHPPOSLLH, autoDOP and upgrades to autoPVT.
markuckermann for spotting the config layer gremlins
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
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.
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.
请发表评论