sparkfun / sparkfun_ublox_arduino_library

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

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.

• 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.
• 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
• vid553 for the Zephyr port
• balamuruganky for the NAV-PVT velocity parameters, getSpeedAccEst, getHeadingAccEst, getInvalidLlh, getHeadVeh, getMagDec and getMagAcc
• nelarsen for the buffer overrun improvements
• mstranne and shaneperera for the pushRawData suggestion
• rubienr for spotting the logical AND issues

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

• /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.
• CONTRIBUTING.md - Guidelines on how to contribute to this library.
• Theory.md - provides detail on how data is processed by the library.

Documentation

• Installing an Arduino Library Guide - Basic information on how to install an Arduino library.

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:

• 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.

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.

sparkfun_ublox_arduino_library's Issues

I2C/RTCM issues

Subject of the issue

ESP32 - I2C Messages timeout and rtcmFrameCounter keeps incrementing until panic occurs.
SAMD21 - I2C will not work unless I change #define I2C_BUFFER_LENGTH 255 as 256 will not work.

Your workbench

ESP32 (Sparkfun ESP32 1 Channel Gateway)/SAMD21 (Adafruit M0) both using I2C and similar sketches. Adafruit is more stable.
ZED-F9P

Steps to reproduce

Update all libs to latest version.
Load "Example3_StartRTCMBase" with debugging enabled on either platform.
ESP32 partially works. M0 will not work without changing the ring buffer size.

Expected behavior

Packets should be processed appropriately, ACKs received and the frame counter reset.

Actual behavior

Timeouts should not take 35 seconds. Eventually memory leak will stop the RTCM output or panic occurs.

See below debug.

Sending: CLS:CFG ID:8A Len: 0xA Payload: 0 1 0 0 BD 2 91 20 4 0
sendCommand: Waiting for ACK response
checkUbloxI2C: Large packet of 24040 bytes received
Incoming: Size: 9 Received: CLS:CFG ID:8B Len: 0x9 Payload: 1 1 0 0 BD 2 91 20 4
packetCfg now valid
Incoming: Size: 2 Received: CLS:ACK ID:1 Len: 0x2 Payload: 6 8B
packetCfg now valid
packetAck now valid
UBX ACK: Command sent/ack'd successfully
Module not ready with data
Module not ready with data
Incoming: Size: 2 Received: CLS:ACK ID:1 Len: 0x2 Payload: 6 8A
packetCfg now valid
packetAck now valid
waitForACKResponse: ACK received after 40664 msec
waitForACKResponse: New data successfully sent

Sending: CLS:CFG ID:SAVE Len: 0xC Payload: 0 0 0 0 FF 0 0 0 0 0 0 0
sendCommand: Waiting for ACK response
checkUbloxI2C: Large packet of 21557 bytes received
Module not ready with data
Incoming: Size: 2 Received: CLS:ACK ID:1 Len: 0x2 Payload: 6 9
packetAck now valid
UBX ACK: Command sent/ack'd successfully
waitForACKResponse: ACK received after 36503 msec
waitForACKResponse: New data successfully sent
OK
CONFIG: CFG-MSGOUT-RTCM_3X_TYPE1077_I2C (0x209102cc)key: 0x209102CC

Sending: CLS:CFG ID:8B Len: 0x8 Payload: 0 1 0 0 CC 2 91 20
sendCommand: Waiting for ACK response
checkUbloxI2C: Large packet of 21197 bytes received
waitForACKResponse: timeout after 35795 msec. No ack packet received.

Sending: CLS:CFG ID:8A Len: 0xA Payload: 0 1 0 0 CC 2 91 20 4 0
sendCommand: Waiting for ACK response
checkUbloxI2C: Large packet of 22026 bytes received
Incoming: Size: 9 Received: CLS:CFG ID:8B Len: 0x9 Payload: 1 1 0 0 CC 2 91 20 4
packetCfg now valid
Incoming: Size: 2 Received: CLS:ACK ID:1 Len: 0x2 Payload: 6 8A
packetCfg now valid
packetAck now valid
waitForACKResponse: Config was valid but ACK not received
waitForACKResponse: timeout after 37168 msec. No ack packet received.

Sending: CLS:CFG ID:SAVE Len: 0xC Payload: 0 0 0 0 FF 0 0 0 0 0 0 0
sendCommand: Waiting for ACK response
checkUbloxI2C: Large packet of 22078 bytes received
Module not ready with data
Incoming: Size: 2 Received: CLS:ACK ID:1 Len: 0x2 Payload: 6 9
packetAck now valid
UBX ACK: Command sent/ack'd successfully
waitForACKResponse: ACK received after 36866 msec
waitForACKResponse: New data successfully sent
OK
CONFIG: CFG-MSGOUT-RTCM_3X_TYPE1087_I2C (0x209102d1)key: 0x209102D1

Sending: CLS:CFG ID:8B Len: 0x8 Payload: 0 1 0 0 D1 2 91 20
sendCommand: Waiting for ACK response
checkUbloxI2C: Large packet of 22820 bytes received
waitForACKResponse: timeout after 38205 msec. No ack packet received.

Sending: CLS:CFG ID:8A Len: 0xA Payload: 0 1 0 0 D1 2 91 20 4 0
sendCommand: Waiting for ACK response
checkUbloxI2C: Large packet of 22224 bytes received
Incoming: Size: 9 Received: CLS:CFG ID:8B Len: 0x9 Payload: 1 1 0 0 D1 2 91 20 4
packetCfg now valid
Module not ready with data
Incoming: Size: 2 Received: CLS:ACK ID:1 Len: 0x2 Payload: 6 8A
packetCfg now valid
packetAck now valid
waitForACKResponse: Config was valid but ACK not received
waitForACKResponse: timeout after 37917 msec. No ack packet received.

Sending: CLS:CFG ID:SAVE Len: 0xC Payload: 0 0 0 0 FF 0 0 0 0 0 0 0
sendCommand: Waiting for ACK response
checkUbloxI2C: Large packet of 21402 bytes received
Module not ready with data
Incoming: Size: 2 Received: CLS:ACK ID:1 Len: 0x2 Payload: 6 9
packetAck now valid
UBX ACK: Command sent/ack'd successfully
waitForACKResponse: ACK received after 36370 msec
waitForACKResponse: New data successfully sent
OK
CONFIG: CFG-MSGOUT-RTCM_3X_TYPE1097_I2C (0x20910318)key: 0x20910318

Sending: CLS:CFG ID:8B Len: 0x8 Payload: 0 1 0 0 18 3 91 20
sendCommand: Waiting for ACK response
checkUbloxI2C: Large packet of 21014 bytes received
waitForACKResponse: timeout after 35516 msec. No ack packet received.

Sending: CLS:CFG ID:8A Len: 0xA Payload: 0 1 0 0 18 3 91 20 4 0
sendCommand: Waiting for ACK response
checkUbloxI2C: Large packet of 22325 bytes received
Incoming: Size: 9 Received: CLS:CFG ID:8B Len: 0x9 Payload: 1 1 0 0 18 3 91 20 4
packetCfg now valid
Incoming: Size: 2 Received: CLS:ACK ID:1 Len: 0x2 Payload: 6 8B
packetCfg now valid
packetAck now valid
UBX ACK: Command sent/ack'd successfully
Incoming: Size: 2 Received: CLS:ACK ID:1 Len: 0x2 Payload: 6 8A
packetCfg now valid
packetAck now valid
waitForACKResponse: ACK received after 37699 msec
waitForACKResponse: New data successfully sent

Sending: CLS:CFG ID:SAVE Len: 0xC Payload: 0 0 0 0 FF 0 0 0 0 0 0 0
sendCommand: Waiting for ACK response
checkUbloxI2C: Large packet of 22506 bytes received
waitForACKResponse: timeout after 38125 msec. No ack packet received.
OK
CONFIG: CFG-MSGOUT-RTCM_3X_TYPE1127_I2C (0x209102d6)key: 0x209102D6

Sending: CLS:CFG ID:8B Len: 0x8 Payload: 0 1 0 0 D6 2 91 20
sendCommand: Waiting for ACK response
checkUbloxI2C: Large packet of 22447 bytes received
Incoming: Size: 2 Received: CLS:ACK ID:1 Len: 0x2 Payload: 6 9
packetAck now valid
waitForACKResponse: timeout after 38223 msec. No ack packet received.

Sending: CLS:CFG ID:8A Len: 0xA Payload: 0 1 0 0 D6 2 91 20 4 0
sendCommand: Waiting for ACK response
checkUbloxI2C: Large packet of 24452 bytes received
Incoming: Size: 9 Received: CLS:CFG ID:8B Len: 0x9 Payload: 1 1 0 0 D6 2 91 20 4
packetCfg now valid
Incoming: Size: 2 Received: CLS:ACK ID:1 Len: 0x2 Payload: 6 8B
packetCfg now valid
packetAck now valid
UBX ACK: Command sent/ack'd successfully
Module not ready with data
Incoming: Size: 2 Received: CLS:ACK ID:1 Len: 0x2 Payload: 6 8A
packetCfg now valid
packetAck now valid
waitForACKResponse: ACK received after 41442 msec
waitForACKResponse: New data successfully sent

https://github.com/PaulZC/SparkFun_Ublox_Arduino_Library/tree/PaulZC_testing_%2364

This build appears to have fixed some of the issues on ESP32. Much faster too. But still seeing the leak.

Sending: CLS:NAV ID:3B Len: 0x0 Payload:
sendCommand: Waiting for No ACK response
checkUbloxI2C: OK, zero bytes available
Incoming: Size: 40 Received: CLS:NAV ID:3B Len: 0x28 Payload: 0 0 0 0 32 81 8 12 50 0 0 0 22 D1 81 FB 60 AA 78 DF 83 21 18 13 14 15 4 0 2B C3 0 0 C7 0 0 0 1 0 0 0
packetCfg now valid
waitForNoACKResponse: CLS/ID match after 73 msec
Active: 0 Valid: 1 Timer: 80 Accuracy: 5.00
Base survey complete!
Active: 0 Valid: 1 Timer: 80 Accuracy: 5.00
RTCM now broadcasting.
CONFIG: CFG-I2COUTPROT-RTCM3X (0x10720004)key: 0x10720004

Sending: CLS:CFG ID:VALGET Len: 0x8 Payload: 0 1 0 0 4 0 72 10
sendCommand: Waiting for ACK response
checkUbloxI2C: OK, zero bytes available
Incoming: Size: 9 Received: CLS:CFG ID:VALGET Len: 0x9 Payload: 1 1 0 0 4 0 72 10 0
packetCfg now valid
Incoming: Size: 2 Received: CLS:ACK ID:1 Len: 0x2 Payload: 6 8B
packetCfg now valid
packetAck now valid
UBX ACK: Command sent/ack'd successfully
waitForACKResponse: ACK received after 81 msec
waitForACKResponse: CLS/ID match after 86 msec

Sending: CLS:CFG ID:VALSET Len: 0xA Payload: 0 1 0 0 4 0 72 10 1 0
sendCommand: Waiting for ACK response
Incoming: Size: 2 Received: CLS:ACK ID:1 Len: 0x2 Payload: 6 8A
packetAck now valid
UBX ACK: Command sent/ack'd successfully
waitForACKResponse: ACK received after 14 msec
waitForACKResponse: New data successfully sent

Sending: CLS:CFG ID:9 Len: 0xC Payload: 0 0 0 0 FF 0 0 0 0 0 0 0
sendCommand: Waiting for ACK response
checkUbloxI2C: OK, zero bytes available
Incoming: Size: 2 Received: CLS:ACK ID:1 Len: 0x2 Payload: 6 9
packetAck now valid
UBX ACK: Command sent/ack'd successfully
waitForACKResponse: ACK received after 67 msec
waitForACKResponse: New data successfully sent

Sending: CLS:CFG ID:9 Len: 0xC Payload: 0 0 0 0 FF 0 0 0 0 0 0 0
sendCommand: Waiting for ACK response
checkUbloxI2C: Large packet of 803 bytes received
waitForACKResponse: timeout after 921 msec. No ack packet received.

checkUbloxI2C: Large packet of 838 bytes received
Incoming: Size: 2 Received: CLS:ACK ID:1 Len: 0x2 Payload: 6 9
packetAck now valid
UBX ACK: Command sent/ack'd successfully
.checkUbloxI2C: Large packet of 867 bytes received
.checkUbloxI2C: Large packet of 1656 bytes received
.checkUbloxI2C: Large packet of 2484 bytes received
.checkUbloxI2C: Large packet of 3312 bytes received
.checkUbloxI2C: Large packet of 4982 bytes received
.checkUbloxI2C: Large packet of 6538 bytes received
.checkUbloxI2C: Large packet of 9425 bytes received
.checkUbloxI2C: Large packet of 12851 bytes received
checkUbloxI2C: Module not ready with data. Retrying.
checkUbloxI2C: Module not ready with data. Retrying.
.checkUbloxI2C: Large packet of 16510 bytes received
checkUbloxI2C: Module not ready with data. Retrying.
checkUbloxI2C: Module not ready with data. Retrying.
.checkUbloxI2C: Large packet of 21621 bytes received
checkUbloxI2C: Module not ready with data. Retrying.
.checkUbloxI2C: Large packet of 22358 bytes received
.checkUbloxI2C: Large packet of 20828 bytes received
.checkUbloxI2C: Large packet of 22355 bytes received
checkUbloxI2C: Module not ready with data. Retrying.
.checkUbloxI2C: Large packet of 22558 bytes received
checkUbloxI2C: Module not ready with data. Retrying.
.checkUbloxI2C: Large packet of 23265 bytes received
checkUbloxI2C: Module not ready with data. Retrying.
checkUbloxI2C: Module not ready with data. Retrying.
checkUbloxI2C: Module not ready with data. Retrying.
checkUbloxI2C: Module not ready with data. Retrying.
.checkUbloxI2C: Large packet of 22979 bytes received
checkUbloxI2C: Module not ready with data. Retrying.
checkUbloxI2C: Module not ready with data. Retrying.
.checkUbloxI2C: Large packet of 22157 bytes received
checkUbloxI2C: Module not ready with data. Retrying.
Guru Meditation Error: Core 1 panic'ed (IllegalInstruction). Exception was unhandled.
Core 1 register dump:
PC : 0x65000000 PS : 0x00060530 A0 : 0x800d1775 A1 : 0x3ffb1ed0
A2 : 0x3ffc0360 A3 : 0x3ffc015c A4 : 0x000000b0 A5 : 0x65000000
A6 : 0x00000000 A7 : 0x3ffb1f0c A8 : 0x800d35aa A9 : 0x3ffb1e90
A10 : 0x3ffc0360 A11 : 0x3ffb1f0c A12 : 0x00000002 A13 : 0x3ffbebf4
A14 : 0x00000010 A15 : 0x00000001 SAR : 0x00000013 EXCCAUSE: 0x00000000
EXCVADDR: 0x00000000 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0x00000000

Backtrace: 0x65000000:0x3ffb1ed0 0x400d1772:0x3ffb1ef0 0x400d1af3:0x3ffb1f10 0x400d2363:0x3ffb1f30 0x400d24ea:0x3ffb1f50 0x400d253e:0x3ffb1f70 0x400d15d2:0x3ffb1f90 0x400d5b91:0x3ffb1fb0 0x40088dbd:0x3ffb1fd0

Rebooting...

PC: 0x65000000
EXCVADDR: 0x00000000

Decoding stack results
0x400d1772: SFE_UBLOX_GPS::processRTCM(unsigned char) at ........\ADA_ESP32/ADA_ESP32.ino line 43
0x400d1af3: SFE_UBLOX_GPS::processRTCMframe(unsigned char) at ........\Arduino\libraries\SparkFun_Ublox_Arduino_Library-1.7.1\src\SparkFun_Ublox_Arduino_Library.cpp line 519
0x400d2363: SFE_UBLOX_GPS::process(unsigned char) at ........\Arduino\libraries\SparkFun_Ublox_Arduino_Library-1.7.1\src\SparkFun_Ublox_Arduino_Library.cpp line 470
0x400d24ea: SFE_UBLOX_GPS::checkUbloxI2C() at ........\Arduino\libraries\SparkFun_Ublox_Arduino_Library-1.7.1\src\SparkFun_Ublox_Arduino_Library.cpp line 374
0x400d253e: SFE_UBLOX_GPS::checkUblox() at ........\Arduino\libraries\SparkFun_Ublox_Arduino_Library-1.7.1\src\SparkFun_Ublox_Arduino_Library.cpp line 266
0x400d15d2: loop() at ........\ADA_ESP32/ADA_ESP32.ino line 23
0x400d5b91: loopTask(void*) at ........\Arduino15\packages\esp32\hardware\esp32\1.0.4\cores\esp32\main.cpp line 19
0x40088dbd: vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c line 143

Line 43 on the .ino: sendData(buffz, frame_length);

I do have a radio onboard that's attached to SPI and has interrupts which is , but not sure if that's involved somehow.

Fix licensing

Hello everybody,

the licensing of this library is not clear.
License.md says MIT, looking into the c-code and the c-header it says GPL.

Just an observation: sendCommand will always timeout with custom ubxPackets

Hi,
This is just an observation that will (hopefully) be trumped by multi-valset #20

If you define a custom ubxPacket which holds (e.g.) a UBX-CFG-VALSET message and then send it with sendCommand, it will always timeout as the commandAck checking in processUBXpacket (called from waitForResponse \ checkUblox \ checkUbloxI2C \ process \ processUBX) expects the packet class and ID to be defined in packetCfg, not the custom packet.

The offending line is:
if (msg->id == UBX_ACK_ACK && msg->payload[0] == packetCfg.cls && msg->payload[1] == packetCfg.id)

It would be possible to correct this by passing the requestedClass and requestedID from waitForResponse further down the food chain.

Cheers,
Paul

Feature request: multi-valset

From other issue:

Hi Nathan ( @nseidle ),
Sincere thanks for sharing this library! I'm using it to talk to the ZED-F9P.
Can I please raise a "feature request"?
setVal() is great - but can only set one value at a time. Could you add an elegant way to set multiple keys in a single packet?
My inelegant way is to define them as a ubxPacket and send them using .sendI2cCommand :

// setRAWXon: this is the message which enables all of the messages to be logged to SD card in one go
// It also sets the NMEA high precision mode for the GNGGA message
// It also sets the main talker ID to 'GN'
// UBX-CFG-VALSET message with key IDs of:
// 0x209102a5 (CFG-MSGOUT-UBX_RXM_RAWX_UART1)
// 0x20910232 (CFG-MSGOUT-UBX_RXM_SFRBX_UART1)
// 0x20910179 (CFG-MSGOUT-UBX_TIM_TM2_UART1)
// 0x2091002a (CFG-MSGOUT-UBX_NAV_POSLLH_UART1)
// 0x20910007 (CFG-MSGOUT-UBX_NAV_PVT_UART1)
// 0x2091001b (CFG-MSGOUT-UBX_NAV_STATUS_UART1)
// 0x10930006 (CFG-NMEA-HIGHPREC)
// 0x209100bb (CFG-MSGOUT-NMEA_ID_GGA_UART1)
// and values (rates) of 1
// 0x20930031 (CFG-NMEA-MAINTALKERID) has value 3 (GN)
static uint8_t setRAWXon_payload[] = {
0x00, 0x01, 0x00, 0x00,
0xa5, 0x02, 0x91, 0x20, 0x01,
0x32, 0x02, 0x91, 0x20, 0x01,
0x79, 0x01, 0x91, 0x20, 0x01,
0x2a, 0x00, 0x91, 0x20, 0x00, // Change the last byte from 0x01 to 0x00 to leave NAV_POSLLH disabled
0x07, 0x00, 0x91, 0x20, 0x01, // Change the last byte from 0x01 to 0x00 to leave NAV_PVT disabled
0x1b, 0x00, 0x91, 0x20, 0x01, // This line enables the NAV_STATUS message
0x31, 0x00, 0x93, 0x20, 0x03, // This line sets the main talker ID to GN
0x06, 0x00, 0x93, 0x10, 0x01, // This sets the NMEA high precision mode
0xbb, 0x00, 0x91, 0x20, 0x01 }; // This (re)enables the GGA mesage
ubxPacket setRAWXon = { 0x06, 0x8a, 49, 0, 0, setRAWXon_payload, 0, 0, false };

Sincere thanks,
Paul

getProtocolVersion overruns payloadCfg array

payloadCfg currently has a defined size of 256 (MAX_PAYLOAD_SIZE) bytes. Base on the comment "We need ~220 bytes for getProtocolVersion on most ublox modules" I believe the expectation is most modules will contain no more than 6 extensions (payload: 30 + 10 + 6*30 = 220 bytes). getProtocolVersion is currently configured to step through 10 extensions (340 bytes) which will overrun payloadCfg.

SFE_UBLOX_STATUS_CRC_FAIL errors with direct UART connection

Subject of the issue

SFE_UBLOX_STATUS_CRC_FAIL errors with direct UART connection from NEO-M8P-2 to Feather 32u4 basic TX/RX (null-modem).

Your workbench

Adafruit Feather 32u4 basic proto with TX/RX connected directly to NEO-M8P-2
https://learn.adafruit.com/adafruit-feather-32u4-basic-proto/pinouts

• Use https://www.sparkfun.com/products/15005 NEO-M8P-2 RTK GPS Module
• Use https://www.adafruit.com/product/2771 Atmega32u4 @8MHz
• Use https://www.adafruit.com/product/3463 NXP 9DOF
• RX/TX (Arduino Serial2) connected to TX/RX (null-modem) of NEO-M8P2 with 3" (8cm) wire
• Use 26AWG flexible silicon wire for attaching the digital signals and power (UART, I2C, 3V3) as below:
• Bring out 3V3/GND wires from Feather 32U4 to receive 3V power from the onboard Feather power adapter.
• Connect GPS 3V3 and GND to Feather 32U4 3V3/GND Pair 2
• Connect Feather 32U4 TX to GPS RX, 32U4 RX to GPS TX
• Power is provided by Feather onboard 500mA peak AP2112K-3.3.

Steps to reproduce

Easy sample here: https://github.com/jafrado/ubxgps, or using the latest master Sparkfun Ublox Arduino Library, and \examples\Example12_UseUart with the HW Serial Port on Atmega32u4 (Arduino Serial1, Pins 0=RX, 1=TX to NEO Pin RX/TX (Null-Modem). This means comment out the lines

#include <SoftwareSerial.h>
SoftwareSerial mySerial(10, 11); // RX, TX. Pin 10 on Uno goes to TX pin on GPS module.

now search and replace mySerial with Serial1.

At the bottom of setup() call myGPS.enableDebugging(Serial);

NOTE: Feather 32u4 uses USB console as Serial and the Pins 0/1 UART as Serial1

Upload to Feather and you will get the below with no debug output:

SparkFun Ublox Example
GPS: trying 38400 baud
GPS serial connected
Current update rate:1
Lat: 0 Long: 0 (degrees * 10^-7) Alt: 0 (mm) SIV: 0 Fix: No fix RTK: 0 Speed: 0 (mm/s) Heading: 0 (degrees * 10^-5) pDOP: 0.00
Lat: 0 Long: 0 (degrees * 10^-7) Alt: 0 (mm) SIV: 0 Fix: No fix RTK: 0 Speed: 0 (mm/s) Heading: 0 (degrees * 10^-5) pDOP: 0.00
Lat: 0 Long: 0 (degrees * 10^-7) Alt: 0 (mm) SIV: 0 Fix: No fix RTK: 0 Speed: 0 (mm/s) Heading: 0 (degrees * 10^-5) pDOP: 0.00
Lat: 0 Long: 0 (degrees * 10^-7) Alt: 0 (mm) SIV: 0 Fix: No fix RTK: 0 Speed: 0 (mm/s) Heading: 0 (degrees * 10^-5) pDOP: 0.00

With debug output, you see the CRC Fail message over and over.

SparkFun Ublox Example
GPS: trying 38400 baud
GPS serial connected
Current update rate:1
own Status

Sending: CLS:NAV ID:PVT Len: 0x0 Payload:

ut
getPVT retVal: CRC Fail
Lat: 0own Status

Sending: CLS:NAV ID:PVT Len: 0x0 Payload:

Incoming: Size: 92 Received: CLS:FF ID:FF Len: 0x5C Payload: 80 AA 70 14 E4 7 4 F 17 F A 37 2 0 0 0 4D FF FE FF 3 43 EA D A6 73 7D B7 6B D2 1C 16 9 50 1 0 73 C5 1 0 79 0 0 0 84 0 0 0 11 0 0 0 F6 FF FF FF A 0 0 0 13 0 0 0 37 65 2A 1 D 0 0 0 7D B6 25 0 A0 0 0 0 12 19 26 3B 0 0 0 0 0 0 0 0

ut
getPVT retVal: CRC Fail
 Long: 0 (degrees * 10^-7)own Status

Sending: CLS:NAV ID:PVT Len: 0x0 Payload:

 checksumA: 104 checksumB: 174 rollingChecksumA: 100 rollingChecksumB: 209
Failed  : Size: 0 Received: CLS:FF ID:FF Len: 0x0 Payload:
ut
getPVT retVal: CRC Fail
 Alt: 0 (mm)own Status

Sending: CLS:NAV ID:PVT Len: 0x0 Payload:

Incoming: Size: 92 Received: CLS:FF ID:FF Len: 0x5C Payload: 50 B2 70 14 E4 7 4 F 17 F C 37 2 0 0 0 17 FE FE FF 3 43 EA D A5 73 7D B7 6D D2 1C 16 E 50 1 0 78 C5 1 0 A6 0 0 0 8C 0 0 0 13 0 0 0 FA FF FF FF 2 0 0 0 14 0 0 0 37 65 2A 1 A 0 0 0 99 5 1A 0 A0 0 0 0 12 19 26 3B 0 0 0 0 0 0 0 0

ut
getPVT retVal: CRC Fail
 SIV: 0
own Status

Sample

Tell us how to reproduce this issue. Please post stripped down example code demonstrating your issue. Right here, with full output excerpts and other great snippets from examples provided with the library. Sample here: https://github.com/jafrado/ubxgps

Expected behavior

Tell us what should happen

g: Size: 92 Received: CLS:FF ID:FF Len: 0x5C Payload: 30 52 73 14 E4 7 4 F 17 12 4 37 2 0 0 0 5C 96 FE FF 3 43 EA D A1 73 7D B7 68 D2 1C 16 75 52 1 0 DF C7 1 0 5E 0 0 0 59 0 0 0 B 0 0 0 FD FF FF FF 21 0 0 0 B 0 0 0 37 65 2A 1 F 0 0 0 14 97 2D 0 9F 0 0 0 12 19 26 3B 0 0 0 0 0 0 0 0

SparkFun Ublox Example
GPS: trying 38400 baud
GPS serial connected
Current update rate:1
Lat: 370987622 Long: -1216515166 (degrees * 10^-7) Alt: 86681 (mm) SIV: 13
Lat: 370987623 Long: -1216515166 (degrees * 10^-7) Alt: 86709 (mm) SIV: 13
Lat: 370987623 Long: -1216515167 (degrees * 10^-7) Alt: 86700 (mm) SIV: 13
Lat: 370987622 Long: -1216515167 (degrees * 10^-7) Alt: 86704 (mm) SIV: 12
Lat: 370987622 Long: -1216515167 (degrees * 10^-7) Alt: 86717 (mm) SIV: 12
Lat: 370987623 Long: -1216515166 (degrees * 10^-7) Alt: 86734 (mm) SIV: 12
Lat: 370987622 Long: -1216515167 (degrees * 10^-7) Alt: 86737 (mm) SIV: 12
Lat: 370987624 Long: -1216515168 (degrees * 10^-7) Alt: 86734 (mm) SIV: 12
Lat: 370987624 Long: -1216515168 (degrees * 10^-7) Alt: 86756 (mm) SIV: 12
Lat: 370987624 Long: -1216515168 (degrees * 10^-7) Alt: 86758 (mm) SIV: 12
Lat: 370987625 Long: -1216515168 (degrees * 10^-7) Alt: 86766 (mm) SIV: 12

Actual behavior

It is always failing with the return code SFE_UBLOX_STATUS_CRC_FAIL in line 1160. If you comment out the line, the software works as expected. I understand the code is probably adapted primarily for I2C and the checksum may have some pecularities when used as such. Kindly request the UART and checksum work at the same level of functionality. Commenting out the checksum code seems to work fine after over 36hrs of use in a quite dynamic load testing environment.

I2C not detecting the Module

Subject of the issue

I2C is not detecting Module

Your workbench

I was building an application on platformIO using Esp32 and Zoe-M8Q. Everything was working fine. then I change the output mode from serial to uart. I run Factory Default via serial and then started working on the code. But I was unable to get any reading. Now I want to go back to use I2C but I can't. The module is not detected over the I2C bus. I have scanned all the possible addresses but this device is not detecting on I2C.
Can you please help me in this how can I get back to use I2C?

Ublox module not respecting I2C setup times

I think this may be the main culprit behind issues #37 and #38 but it's still a bit murky.

The ZED-F9P seems to be violating I2C setup times.

How to reproduce: Use a fast microcontroller such as the Artemis/Apollo3 and run Example99 on it. Using an analyzer we see the following:

The logic analyzer sees this byte as 0x21 but the Artemis sees it as 0xA1. This bit flip causes the CRC to fail and the frame to be tossed. Not terrible unless we are really trying to achieve fast update rates.

In the above image we zoom in on this 0x21 byte. The time between data going low and clock going high is 62.5ns. This is very short for I2C. 62.5ns is the shortest time slot my analyzer can capture so I need to get a better analyzer.

According to the I2C spec

"[3] A device must internally provide a hold time of at least 300ns for the SDA signal to bridge the undefined region of the falling edge of SCL." The ZED-F9P is not doing this so there are random 0-bits that are being mis-interpreted.

The ATmega328 does not experience this because it is too slow. Below is the "how many bytes available" read on the ATmega328:

4.875uS. It is interesting to note it looks like the ZED-F9P is clock stretching.

And below is the equivalent read on the Artemis:

If I had to guess, the I2C hardware on the ZED-F9P is malfunctioning. It is releasing the SCL line before it has properly set SDA. Almost all the I2C byte transactions look clean on the Artemis. But after the ZED-F9P has clock stretched, it gets really close to a bit error.

Here's an example. In the middle of a 100 byte read from ZED to Artemis, the ZED-F9P clock stretches to tell the Artemis to hold:

52us is the clock stretch. Once the ZED-F9P releases the clock the Artemis immediately resumes clocking out the data. But the ZED-F9P has not set SDA with the proper setup time of at least 300ns. In this example Artemis correctly read the first bit as 0 but because the timing is violating the I2C spec Artemis cannot be guaranteed to interpret that first bit correctly.

TODO:

• Test on Teensy. This will help determine if the problem is Artemis or ZED-F9P. Both platforms see similar timing violations of the I2C spec (62ns). Note: Teensy doesn't get CRC error where Artemis does intermittently.
• Test at 100kHz. All testing so far has been at 400kHz. Setup time should still be 300ns on SDA but it may be interesting. I2C timing violation appears at both 100kHz and 400kHz on both Teensy and Artemis.
• Test SAM-M8Q to see if similar timing errors exist. Timing violation is longer (187ns vs 62ns) but is still too short for the I2C spec (300ns).

Possibly wrong unit for high-precision accuracy values

Possibly wrong unit for high-precision accuracy values

It seems the unit for the high-precision accuracy values (outputs from methods getHorizontalAccuracy and getVerticalAccuracy defined in src/SparkFun_Ublox_Arduino_Library.cpp) should have a unit of 0.1 mm, instead of mm as indicated in the example examples/ZED-F9P/Example9_GetHighPrecisionGeodeticPacket. The ZED-F9P Interface Description mentions that there is a scaling of 0.1 for the high-precision accuracy values in Section 5.14.6.1 High Precision Geodetic Position Solution.

Workbench

We are following the the tutorial GPS-RTK2 Hookup Guide using the recommended hardware:

• SparkFun GPS-RTK2 Board
• SparkFun BlackBoard

Steps to reproduce

One can observe an inconsistency of the accuracy values, for instance, by running the examples ZED-F9P/Example8_GetHighPrecisionPositionAndAccuracy and ZED-F9P/Example1_GetPositionAccuracy, and comparing the output values from getHorizontalAccuracy (the 2D horizontal accuracy) and getPositionAccuracy (3D accuracy).

Expected behavior

One should expect the 2D horizontal accuracy to be smaller than the 3D one, because the latter considers the vertical error, too.

Actual behavior

However, if the high-precision accuracy values have a unit of mm as the 3D accuracy does, the 2D accuracy would be way bigger. For example, by outputting both accuracy values to the serial monitor, one can observe something like:

where the 2D accuracy (~290) is way bigger than the 3D one (~50).

What is the resolution of getHighResLongitude?

What is the resolution of "int32_t longitude = myGPS.getHighResLongitude()"?
A change to the least significant digit of the longitude/latitude, how many millimeters does that change represent? So that I could measure the real life distance traveled.

Is there any formulas och examples to illustrate this?

processUBXpacket() does not handle NACK

Subject of the issue

The processUBXpacket() method does not handle a NACK from the module. This is possible response from the module that needs to be handled otherwise it can result in unreliable processing of the module response.

The following was taken from the UBlox protocol specification:

32.5.1 Acknowledgement
When messages from the class CFG are sent to the receiver, the receiver will send an "acknowledge" (UBX-ACK-ACK) or a "not acknowledge" (UBX-ACK-NAK) message back to the sender, depending on whether or not the message was processed correctly.

I have corrected the issue and can submit a PR if you would like me to. The modified code is copied below. I am not sure how to highlight the changes inside a code block as bolding doesn't seem to work inside the code block.

The changes also address another issue with the indication of a valid packet. This is now more reliable as well.

SparkFun_Ublox_Arduino_Library.cpp

void SFE_UBLOX_GPS::processUBXpacket(ubxPacket *msg)
{
  switch (msg->cls)
  {
  case UBX_CLASS_ACK:
    //We don't want to store ACK packets, just set commandAck flag
    if (msg->id == UBX_ACK_ACK && msg->payload[0] == packetCfg.cls && msg->payload[1] == packetCfg.id)
    {
      //The ack we just received matched the CLS/ID of last packetCfg sent
      if (_printDebug == true)
      {
        _debugSerial->println("UBX ACK: Acknowledged");
      }
      commandAck = UBX_ACK_ACK;
    }
    else if (msg->id == UBX_ACK_NACK && msg->payload[0] == packetCfg.cls && msg->payload[1] == packetCfg.id)
    {
      //The ack we just received matched the CLS/ID of last packetCfg sent
      if (_printDebug == true)
      {
        _debugSerial->println("UBX ACK:  Not-Acknowledged");
      }
      commandAck = UBX_ACK_NACK;
    }

boolean SFE_UBLOX_GPS::waitForResponse(uint8_t requestedClass, uint8_t requestedID, uint16_t maxTime)
{
  commandAck = UBX_ACK_NONE;      //Reset flag
  packetCfg.valid = false; //This will go true when we receive a response to the packet we sent
  packetAck.valid = false;

  unsigned long startTime = millis();
  while (millis() - startTime < maxTime)
  {
    checkUblox(); //See if new data is available. Process bytes as they come in.

    if (packetAck.valid == true)
    {
      if (commandAck == UBX_ACK_ACK) {
        return (true);   //  Received an ACK
      }
      else if (commandAck == UBX_ACK_NACK) {
        return (false);  //  Received a NACK
      }

boolean SFE_UBLOX_GPS::getPVT(uint16_t maxWait)
{
  if (autoPVT)
  {
    //The GPS is automatically reporting, we just check whether we got unread data
    checkUblox();
    return moduleQueried.all;
  }
  else
  {
    //The GPS is not automatically reporting navigation position so we have to poll explicitly
    packetCfg.cls = UBX_CLASS_NAV;
    packetCfg.id = UBX_NAV_PVT;
    packetCfg.len = 0;
    //packetCfg.startingSpot = 20; //Begin listening at spot 20 so we can record up to 20+MAX_PAYLOAD_SIZE = 84 bytes Note:now hard-coded in processUBX
    packetCfg.valid = false;

SparkFun_Ublox_Arduino_Library.h

	const uint8_t I2C_POLLING_WAIT_MS = 25; //Limit checking of new characters to every X ms
	unsigned long lastCheck = 0;
	boolean autoPVT = false;	//Whether autoPVT is enabled or not
	uint8_t commandAck = UBX_ACK_NONE; //This goes true after we send a command and it's ack'd
	uint8_t ubxFrameCounter;

Setting rover

Subject of the issue

Hello, I try to setting the UART1 as a input port to receive the RTCM3 message on the rover station by the Arduino(UNO), and I found that the lib has a function "setPortInput(uint8_t portID, uint8_t inStreamSettings, uint16_t maxWait)" to set the port to input data. But, I don't know how to call it. Is there any examples or solutions?

Your workbench

• microcontroller: Arduino UNO
• lib version: 1.4.2

Expected behavior

Set up the rover as the C94-M8P - User Guide in the official website.

Many thanks.

ZED-F9P Example 4_BaseWithLCD does not output anything to Serial Port

I have set up the exact hardware for the Sparkfun ZED-F9P Base station receiver and loaded the sketch. The output initially included surveying in the base station and suceeded. Subsequent restarts show Base Station survey complete. After I receive the RTCM no broadcasting in the serial monitor and the LCD show "Transmitting RTCM" I am not receiving any output to the serial monitor or any changes to the LCD. I was expecting to see "pretty-print" Hex values in the serial monitor to confirm that the RTCM messages are being generated and sent. I have reset the Ublox with Example 12 and reloaded the above sketch with no change in output. I am trying to troubleshoot this before I begin sending the data to a NTRIP caster.

127 bytes available bug

Not sure if it's a bug, but wanted to document a weird ZED-F9P I2C comm issue:

Platform: Artemis

When requesting bytes available, we often see 0x007F or 127 bytes:

Unfortunately all these bytes are empty:

This happens multiple times per second (4 times in 1.15s):

I2C_BUFFER_LENGTH warning

Hi!

I get this warning when running the latest SparkFun Ublox Arduino Library in Platform.io on a ESP32:

In file included from src/gps.h:5:0, from src/gps.cpp:2: .piolibdeps/SparkFun Ublox Arduino Library_ID5746/src/SparkFun_Ublox_Arduino_Library.h:71:0: warning: "I2C_BUFFER_LENGTH" redefined #define I2C_BUFFER_LENGTH 32 ^ In file included from .piolibdeps/SparkFun Ublox Arduino Library_ID5746/src/SparkFun_Ublox_Arduino_Library.h:38:0, from src/gps.h:5, from src/gps.cpp:2: /home/trycoon/.platformio/packages/framework-arduinoespressif32/libraries/Wire/src/Wire.h:34:0: note: this is the location of the previous definition #define I2C_BUFFER_LENGTH 128

Would it be possible to set this value ONLY when it has not already been set?
I2C_BUFFER_LENGTH 32

Thanks!

Two suggestions: slight mods to the resetting of commandAck; and packet .counter and .valid

Hi Nathan (@nseidle),
While I was digging through the code to diagnose the maxWait timeout problem (#60), I thought about the following two suggestions (but wasn't brave enough to include them in PR #62):

• I think setting commandAck to UBX_ACK_NONE in sendCommand is possibly redundant? It gets reset in waitForResponse and I think that's the right place to do it. (I see @matthewgkerr made the same point in #35)

• the packet .counter and .valid parameters are reset together inside process. I wonder if they should be reset separately? Let's say we do a get of a value. We get both a packetCfg and packetAck in return. Let's say they are followed immediately by an AutoPVT packet, checkUbloxSerial (and possibly checkUbloxI2C) will keep processing bytes and process will reset .counter and .valid for both the Cfg and Ack packets. If you made the following change, it would allow the Ack.valid to remain true and so the sendCommand which started all this would return true instead of timing out?

I'm suggesting changing these lines from this:

    else if (ubxFrameCounter == 2)                     //Class
    {
      packetAck.counter = 0;
      packetAck.valid = false;
      packetCfg.counter = 0;
      packetCfg.valid = false;

      //We can now identify the type of response
      if (incoming == UBX_CLASS_ACK)
        ubxFrameClass = CLASS_ACK;
      else
        ubxFrameClass = CLASS_NOT_AN_ACK;
    }

to this:

    else if (ubxFrameCounter == 2)                     //Class
    {
      //We can now identify the type of response
      if (incoming == UBX_CLASS_ACK)
      {
        packetAck.counter = 0;
        packetAck.valid = false;
        ubxFrameClass = CLASS_ACK;
      }
      else
      {
        packetCfg.counter = 0;
        packetCfg.valid = false;
        ubxFrameClass = CLASS_NOT_AN_ACK;
      }
    }

Worth a thought?
Enjoy!
Paul

Add getPowerState method

We just added powerSaveMode(). Would be nice to have a getPowerState method to see what state the module is in.

Config file for fresh module

Hi , it is possible to provide the config file to use with u-center software ? I am using only SAM-M8Q IC on a custom board and trying to make the configuration compatible with this library , but it seems i cant manage to achive the same configuration of the module , and the serial demo code only outputs 0 on all fields without aquiring an gps fix. Thank you a lot.

Add support for the Neo 6M chip (can send PR if you want)

Subject of the issue

Are you interested in support for the older 6M ublox chip? If so, I can send in a PR. The existing code in this repo mostly works, but the 6M doesn't have the PVT nav commands. So I needed to generalize it to use PVT on the newer chips, but fall back to TIMEUTC or POSLLH on the 6M.

My (I would cleanup a bit if you want this PR) change is here:

meshtastic@512833e

ASCII serial forwarding not working?

Subject of the issue

I'm not seeing any ASCII data being forwarded from I2C connection to FP9. I have serial debugging enabled and see "Bytes available:" out the serial port, eventually stopping at 21300 at which point u-center starts reporting "$GPTXT,01,01,00,txbuff alloc*7F"

Your workbench

• What development board or microcontroller are you using? Arduino MKR WIFI 1010 SparkFun
• What version of hardware or breakout board are you using? SparkFun F9P board, and a HC06 bluetooth module
• How is the breakout board wired to your microcontroller? Arduino to F9P via I2C, and Arduino to HC06 module via pins 13/14 (communicating via Serial1)
• How is everything being powered? Both Arduino and F9P via USB to my laptop. HC06 powered from the 3.3V/GND connections on the F9P board
• Are there any additional details that may help us help you? I can get things working via BLE if I'm running everything via AutoPVT, but I need to forward the GGA/VTG messages out to the HC06 (separately, not at the same time). If I try setting the I2C output via "myGPS.setI2COutput(COM_TYPE_NMEA);", the Arduino stops responding with USB failure until I put it back in bootloader mode.

Steps to reproduce

Tell us how to reproduce this issue. Please post stripped down example code demonstrating your issue.
1)Connect to FP9 module via I2C
2)Configure nmea output port to a serial port (same behavior whether Serial to serial monitor or Serial1 to my HC06 module.
3)Optionally enable serial debugging

Expected behavior

I'm expecting to see the $GPGGA messages being forwarded out the serial connection

Actual behavior

"Bytes available: ##" messages are seen out the serial port with serial debugging enabled. Otherwise I see nothing out the serial port. uCenter connection to the FP9 starts showing "$GPTXT,01,01,00,txbuf alloc*7F" once the serial debugging indicates the bytes available caps out at 21300.
Example1_BasicNMEARead_Error.txt

HPPOSLLH pulling wrong registers for lonHp/latHp

High precision values are incorrectly being pulled. See line 755.

Bytes 24/25 are longHp/latHp.

We should also check the highRes examples to make sure this fixes this forum issue and the other possibly related unit issue.

Module not having bytes available

Platform: Artemis

Measurement period is extreme: 10Hz with nav rate of 5Hz (update rate of 2Hz). Problem also shows itself with Example6_OutputRate (nav freq set to 10Hz).

Module will say bytes are available but will present 0xFFs towards the end of the frame.

In this example, 0x64 bytes are 'available':

But part of the way through the byte harvesting, we start getting 0xFFs:

And then our CRC is corrupt. This error occurs ~3 times per 10 seconds.

Often the frame will include 0xFFs in between what looks to be valid data:

It seems as though the module is busy updating other ports (serial, SPI, etc) and is not serving up bytes to I2C buffer.

Unnecessary reset of commandAck

The first line of the function sendCommand sets the variable commandAck to false.
The end of the same function calls the function waitForResponse.
The first line of the function waitForResponse again sets the variable commandAck to false.
The variable commandAck will remain false until the function checkUblox is called, which is done in the function waitForResponse.
I think setting the variable commandAck in the function sendCommand can be removed.
I'm assuming the library is used in a single threaded application, and the serial Interrupt Service Routine is NOT calling checkUblox.
Am I correct in saying setting the variable commandAck in the function sendCommand is unnecessary, or am I missing something?

isConnected not handling waitForACKResponse correctly

isConnected is assuming sendCommand is returning zero for error, and non-zero for ok. However waitForACKResponse will return SFE_UBLOX_STATUS_DATA_SENT if the response was received, otherwise it could return some other zero or non-zero value. I think isConnected should be checking the return value of sendCommand for SFE_UBLOX_STATUS_DATA_SENT and return true, otherwise return false.

Error when used with Redboard Turbo - SAMD21 compatibility issue

Subject of the issue

The Ublox library generates an error when used with the Sparkfun Redboard Turbo as the target. The root cause is line 674 in SparkFun_Ublox_Arduino_Library.cpp. The code line reads as follows:

Serial.println(F("processUBX: counter hit MAX_PAYLOAD_SIZE"));

Since the SAMD processors use either SerialUSB or Serial1 as UART ports, any reference to 'Serial' will produce an error. Commenting out the line provides an immediate workaround to the issue.

I have found that if one must have Serial output specified, that the following code snippet placed at the start of the source file allows for this:

// Need the following define for SAMD processors
#if defined (ARDUINO_ARCH_SAMD)
#define Serial SerialUSB
#endif

Your workbench

Sparkfun Redboard Turbo
Ublox Library version 1.7.2
Arduino IDE 1.8.12

Steps to reproduce

I was able to reproduce this by using the Example1_BasicNMEARead.ino sketch and selecting the Sparkfun Redboard Turbo as the target processor. The error generated by the Arduino IDE is reported as follows:

Arduino: 1.8.12 (Windows 10), Board: "SparkFun RedBoard Turbo"

sketch\Example1_BasicNMEARead.ino.cpp.o: In function `setup':

C:\Users\xxxx\Documents\Arduino\libraries\SparkFun_Ublox_Arduino_Library\examples\Example1_BasicNMEARead/Example1_BasicNMEARead.ino:44: undefined reference to `Serial'

libraries\SparkFun_Ublox_Arduino_Library\SparkFun_Ublox_Arduino_Library.cpp.o: In function `SFE_UBLOX_GPS::processUBX(unsigned char, ubxPacket*)':

C:\Users\xxxx\Documents\Arduino\libraries\SparkFun_Ublox_Arduino_Library\src/SparkFun_Ublox_Arduino_Library.cpp:676: undefined reference to `Serial'

collect2.exe: error: ld returned 1 exit status

exit status 1
Error compiling for board SparkFun RedBoard Turbo.

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

Expected behavior

The library should compile without errors for any SAMD based board.

Actual behavior

See error message produced from Arduino IDE quoted above.

How to convert int32_t highResLatitude into float highResLatitude?

How to convert int32_t highResLatitude into float highResLatitude?
im using SparkFun GPS-RTK2 Board - ZED-F9P..

Support for getting date and time from UBX-NAV-PVT message

I added in this fork: https://github.com/loggerhead-instruments/SparkFun_Ublox_Arduino_Library

uBlox MAX-7Q returning zeros

Subject of the issue

Hi,
I have connected uBlox MAX-7Q to Arduino Nano. Using this library and example "Example11_UseUart" from this library I was able to connect uBlox to Arduino, but all I receive in return is zeros.
Do you have any ideas what I did wrong, did I forget to define/uncomment in .h file, is something wrong with my GPS module?...
Thanks for replies in advance.

CODE***************************************************************************************

/************************** Configuration ***********************************/

#include <TinyLoRa.h>
#include <SPI.h>

/*
Reading lat and long via UBX binary commands using UART @38400 baud - free from I2C
By: Nathan Seidle, Adapted from Example3_GetPosition by Thorsten von Eicken
SparkFun Electronics
Date: January 28rd, 2019
License: MIT. See license file for more information but you can
basically do whatever you want with this code.
This example shows how to configure the library and U-Blox for serial port use as well as
switching the module from the default 9600 baud to 38400.
Note: Long/lat are large numbers because they are * 10^7. To convert lat/long
to something google maps understands simply divide the numbers by 10,000,000. We
do this so that we don't have to use floating point numbers.
Leave NMEA parsing behind. Now you can simply ask the module for the datums you want!
Feel like supporting open source hardware?
Buy a board from SparkFun!
ZED-F9P RTK2: https://www.sparkfun.com/products/15136
NEO-M8P RTK: https://www.sparkfun.com/products/15005
SAM-M8Q: https://www.sparkfun.com/products/15106
Hardware Connections:
Connect the U-Blox serial TX pin to Uno pin 10
Connect the U-Blox serial RX pin to Uno pin 11
Open the serial monitor at 115200 baud to see the output
*/

#include "SparkFun_Ublox_Arduino_Library.h" //http://librarymanager/All#SparkFun_Ublox_GPS
SFE_UBLOX_GPS myGPS;

#include <SoftwareSerial.h>
SoftwareSerial mySerial(0, 1); // RX, TX. Pin 10 on Uno goes to TX pin on GPS module.
SoftwareSerial Serial_PC(4, 5); // RX, TX

long lastTime = 0; //Simple local timer. Limits amount of I2C traffic to Ublox module.

void setup()
{
Serial_PC.begin(115200);
//while (!Serial_PC); //Wait for user to open terminal
Serial_PC.println("SparkFun Ublox Example");

//Assume that the U-Blox GPS is running at 9600 baud (the default) or at 38400 baud.
//Loop until we're in sync and then ensure it's at 38400 baud.
do {
Serial_PC.println("GPS: trying 38400 baud");
mySerial.begin(38400);
if (myGPS.begin(mySerial) == true) break;

delay(100);
Serial_PC.println("GPS: trying 9600 baud");
mySerial.begin(9600);
if (myGPS.begin(mySerial) == true) {
    Serial_PC.println("GPS: connected at 9600 baud, switching to 38400");
    myGPS.setSerialRate(38400);
    delay(100);
} else {
    //myGPS.factoryReset();
    delay(2000); //Wait a bit before trying again to limit the Serial output
}

} while(1);
Serial_PC.println("GPS serial connected");

myGPS.setUART1Output(COM_TYPE_UBX); //Set the UART port to output UBX only
myGPS.setI2COutput(COM_TYPE_UBX); //Set the I2C port to output UBX only (turn off NMEA noise)
myGPS.saveConfiguration(); //Save the current settings to flash and BBR
}

void loop()
{
//Query module only every second. Doing it more often will just cause I2C traffic.
//The module only responds when a new position is available
if (millis() - lastTime > 3000)
{
lastTime = millis(); //Update the timer

long latitude = myGPS.getLatitude();
Serial_PC.print(F("Lat: "));
Serial_PC.print(latitude);

long longitude = myGPS.getLongitude();
Serial_PC.print(F(" Long: "));
Serial_PC.print(longitude);
Serial_PC.print(F(" (degrees * 10^-7)"));

long altitude = myGPS.getAltitude();
Serial_PC.print(F(" Alt: "));
Serial_PC.print(altitude);
Serial_PC.print(F(" (mm)"));

byte SIV = myGPS.getSIV();
Serial_PC.print(F(" SIV: "));
Serial_PC.print(SIV);

Serial_PC.println();

}
}

END OF CODE*************************************************************************************

I was expecting to get some values, but none...

Actual behavior

setRTCMOutputPort(Serial) not available

It seems that in the .cpp file the function setRTCMOutputPort(Serial) is not available.
So, example 3 "Example3_EnableRTCM" does not work.

If I change the name to "setNMEAOutputPort(Serial)", an existing function, the code runs, even saying in the Monitor: 'RTCM messages enabled'.

Regards,
Robin

no valset support

I have been trying to implement valset myself in this library, but have been unsuccessful so far.
Has there been any progress made so far on getting valset working?

setVal is 16 bit and needs 8 and 32 bit versions

Hi,
Looking at the code for setVal, although the comment in the code says that it sets an 8-bit value, value is actually taken to be 16 bits and is copied into payloadCfg[8] and payloadCfg[9].
8 and 32 bit versions are needed. Strictly, a 64-bit version is needed too for double precision values.
My approach would be to create setVal8, setVal16 and setVal32.
Let me know if you need a pull request.
Many thanks!
Paul

polling is slow

I'm not very happy with the performance of the library due to the polling mechanism being used. Specifically, when calling getPVT I'm seeing delays of 400ms and up before the GPS responds. It looks to me like it waits until the internal timer driven by NavFrequency fires and it produces a fresh fix. In my app, I can't handle delays that long, so I'm looking for alternatives.

As far as I can tell, the I2C interface is actually nice in that the GPS has a fairly large internal buffer, so if one turns periodic reporting on it can actually buffer things nicely until the arduino comes and polls. But this requires some changes in the library.

The way I would change things around is to allow enabling periodic reports and to store the last one so it can be queried without delay. For this to work I would move the parsing of UBX_NAV_PVT (and possibly other messages) into processUBXpacket and then:

• add setAutoPVT(bool PVT) which enables periodic UBX_NAV_PVT reporting in the GPS
• modify getPVT such that it doesn't send a poll request if periodic reports are enabled and instead returns false if no new report has come in.

The rest of the interface would remain the same. Thoughts?

Library currently fails when using SoftwareSerial

Subject of the issue

The recent changes made to the processing of ACKs and NACKs seems to have broken the library on SoftwareSerial.

Your workbench

ATmega328 RedBoard Qwiic (DEV-15123)
ZOE-M8Q Qwiic Breakout
I'm connecting via SoftwareSerial (RX on Pin 2, TX on Pin 3)

Steps to reproduce

Run the new updated Example 18

Expected behavior

I'd like things to go back to how they were...

Actual behavior

I'm seeing many failures. The UBX data just doesn't seem to be being parsed correctly at all.

Possible Root Cause

This is a hopefully logical train of thought that leads to the possible root cause:

• sendCommand sends a packet and then does a waitForResponse
• waitForResponse will return true if:
  • checkUblox returns true (and it always returns true for Serial)
  • AND packetAck.valid is true and commandAck is UBX_ACK_ACK
  • OR packetCfg.valid is true and packetCfg.cls and packetCfg.id match the requested class and ID
• packetCfg.valid and packetAck.valid are both cleared at the start of waitForResponse
• commandAck is reset to UBX_ACK_NONE at the start of waitForResponse and at the start of sendCommand (I think the one in sendCommand is redundant)
• packetCfg.valid and packetAck.valid are both cleared by process when ubxFrameCounter reaches 2
• .valid is set true by processUBX if the checksum matches
• commandAck is set by processUBXpacket immediately after .valid has been set by processUBX (so there is essentially zero gap in time between the two)
• checkUbloxSerial will keep calling process until serial.available returns false (I think the equivalent is true for checkUbloxI2C)
• SO, it is possible that in a single call to checkUblox, from inside waitForResponse, both packetCfg.valid and packetAck.valid could become true if the ACK arrived hot on the heels of the Cfg packet or vice versa
• BUT, because packetCfg.valid and packetAck.valid are both cleared by process when ubxFrameCounter reaches 2, only packetAck.valid or packetCfg.valid will be true at the end of the call to checkUblox
• previously waitForResponse didn't check that packetAck.valid was true when checking commandAck. It returned true if commandAck was true, and so it didn't matter if packetAck.valid had been cleared. Now it does!

I need to give up on this now and go wrap some presents. But I will dig into this again after the festivities. I just wanted to give you the heads-up that the new changes have caused problems.

I also need to check if the same thing happens when using hardware serial, or if this is limited to softwareserial.

Merry Christmas!
Paul

Zephyr driver

Subject of the issue

This should probably be someplace else but I am not sure where to ask it.

I've been doing some work with the Zephyr RTOS and wondering if Sparkfun is considering porting some of their drivers to Zephyr? If so, I could help out with some testing.

I think the current Arduino driver would port over reasonably well. Though this driver is written in C++ and Zephyr drivers need to be written in C, there isn't much dependency on C++ that I can see. The I2C and UART API's are a bit different but I think this would not be too much problem.

The bigger thing to consider is if you choose to do this you would be the first to develop a GPS driver for Zephyr. So, likely there would be a need to get consensus with the Zephyr guys on an GPS API. Some of that work is already done (data types for GPS "sensors" are defined). But a GPS sensor API does not exist to my knowledge.

IMHO, Zephyr has some pretty interesting potential. Still kinda rough around the edges but it is pretty slick.

meanAccuracy value

It appears there is a bug in the meanAccuracy value in SparkFun Ublox Arduino Library. Using the provided Example4 Base with LCD I am getting a value of 0.89 when the value in Ucenter Survey-In parameter for Mean 3D StdDev shows 7.4435. The value is correct once the ucenter survey-in value is below 6.5 …. Looks like perhaps an overflow issue in the calculation somewhere with the magic number being 6.5535

millis() does not work during sleep

Subject of the issue

checkUbloxI2C() uses millis() to check time and this time can be unreliable if the mcu goes to sleep since the SysTick on which millis() is based is stopped during sleep. Since checkUbloxI2C() uses a global "lastcheck" to track time elapsed between calls to checkUbloxI2C(), this causes an undesirable additional delay when checking the module after waking from sleep resulting in increased power consumption.

millis() is also used in waitForResponse() but since that function only uses millis() for relative time elapsed within the function itself, it is not a problem here except that generally, it would be preferable if waitForResponse() was not blocking.

My workaround for this problem was to use a tick from the real time clock instead of millis(). In the code snippet below, I have replaced the call to millis() with a global variable (volatile) that keeps track of the time from the rtc.

I suggest perhaps the "proper" solution might be abstract millis() using a virtual function and if the user needs to replace it with something else, it can be replaced by instantiating your own millis() function.

boolean SFE_UBLOX_GPS::checkUbloxI2C()
{
  if (rtcTickMS - lastCheck >= I2C_POLLING_WAIT_MS)
  {
    //Get the number of bytes available from the module
    uint16_t bytesAvailable = 0;
    _i2cPort->beginTransmission(_gpsI2Caddress);
    _i2cPort->write(0xFD);                     //0xFD (MSB) and 0xFE (LSB) are the registers that contain number of bytes available
    if (_i2cPort->endTransmission(false) != 0) //Send a restart command. Do not release bus.
      return (false);                          //Sensor did not ACK

    _i2cPort->requestFrom((uint8_t)_gpsI2Caddress, (uint8_t)2);
    if (_i2cPort->available())
    {
      uint8_t msb = _i2cPort->read();
      uint8_t lsb = _i2cPort->read();
      bytesAvailable = (uint16_t)msb << 8 | lsb;
    }

    if (bytesAvailable == 0)
    {
      if (_printDebug == true)
      {
        _debugSerial->println("No bytes available");
      }
      lastCheck = rtcTickMS; //Put off checking to avoid I2C bus traffic
      return true;
    }

I also noticed today commit e3e170e made in July to address an issue when the module is not ready. The commit adds a blocking delay in this event which causes additional power consumption. I would like to ask if there is something that can be done to eliminate the blocking delay.

F9P RELPOSNED bytes position bug found (and correction)

There is a bug in the library Ublox Arduino library concerning the RELPOSNED function (line 2603 of file SparkFun_Ublox_Arduino_Library.cpp) when using a UBLOX F9P receiver (module from Dec 2019).

The byte position for the parsing of the payloadCfg regarding the accuracy (accN, accE, accD...) and flags values are wrong (see source from Ublox here, page 159)

The code (line 2637) in SparkFun_Ublox_Arduino_Library.cpp:

  uint32_t tempAcc;

  tempAcc = extractLong(24);
  relPosInfo.accN = tempAcc / 10000.0; //Convert 0.1 mm to m

  tempAcc = extractLong(28);
  relPosInfo.accE = tempAcc / 10000.0; //Convert 0.1 mm to m

  tempAcc = extractLong(32);
  relPosInfo.accD = tempAcc / 10000.0; //Convert 0.1 mm to m

  uint8_t flags = payloadCfg[36];

should be changed to:

uint32_t tempAcc;

  tempAcc = extractLong(36);
  relPosInfo.accN = tempAcc / 10000.0; //Convert 0.1 mm to m
  tempAcc = extractLong(40);
  relPosInfo.accE = tempAcc / 10000.0; //Convert 0.1 mm to m
  tempAcc = extractLong(44);
  relPosInfo.accD = tempAcc / 10000.0; //Convert 0.1 mm to m

  uint8_t flags = payloadCfg[60];

In addition to this bug report
I would suggest :

to keep the values in mm or cm (and int or long instead of float) to avoid loss of details and extra space usage
Try to make the library lighter when using only a very small portion of it. Today it use of 16ko of ram without any extra sketch code, which is about 50% of the total available in an Arduino Uno.
Separating the configuration of the Ublox receiver from the reading and parsing part, should probably help with that and/or separating the parsing of NMEA; Ublox; RTCM into different .h file could also help.

F9P Ublox module from Dec 2019

• Arduino Uno + F9P Ublox
• I2C pooling via UART1

Calling function myGPS.relPosInfo.accN

When calling the function myGPS.relPosInfo.accN in I2C the current value of accuracy have no meaning, neither the flags (RTK Float or Fixed flag at least). Changing the byte assignment to the suggested permit to have to the correct values (checked with U-center software connected to the ublox module at the same time).

setNavigationFrequency not respected on custom packet branch

I was using example 16 to check the max output rate on the new custom packet branch and noticed the setNav freq was not sticking. Reverting, it works again. There's something weird on this branch that prevents the changing of the nav frequency that I haven't pinned down yet.

checkUbloxI2C() should return 0xFF

From the Ublox Manual:

If there is no data awaiting transmission from the receiver, then this register will deliver the value 0xFF.

line 205:

_i2cPort->requestFrom((uint8_t)_gpsI2Caddress, (uint8_t)2);
if (_i2cPort->available())
{
uint8_t msb = _i2cPort->read();
uint8_t lsb = _i2cPort->read();
bytesAvailable = (uint16_t)msb << 8 | lsb;
}

should we better check for 0xFF ??

if(lsb == 0xFF) return(false);

i think that removes the massive stocks of the lib..

RELPOSNED

Could you add ubx-relposned to libaray.

It´s very interesting to build a dual antenna system to provide accurate heading and roll.

best regards andreas

Examples 1 and 2 fail to compile due to checkUblox() function call

Subject of the issue

It appears some of the examples (at least Example1_BasicNMEARead and Example2_NMEAParsing) fail to compile (Arduino IDE version 1.8.12). The line in question is the myGPS.checkUblox() call. The checkUblox function appears to expect input parameters, but no parameters are passed in the example sketches. I don't have any hardware. I was simply trying to compile the code for an Arduino Uno. Library version 1.8.0 and MicroNMEA library version 2.0.1.

I haven't checked any of the other examples, but I imagine they would have the same problem.

Put module to Sleep

Is not really an issue, just asking the possibility for putting the module to sleep. I don't see any methods for doing so in the library, and as we know that we can send UBX command to make the module sleep. Is it possible to add the functionality?

Thanks.

feature request: GPS time (seconds since 6 Jan 1980)

Hi - This library looks really excellent. A useful variable would be the GPS time as seconds from GPS-zero (6 Jan 1980) which I guess comes from NAV-TIMEGPS. These values are increasingly used in astronomy (eg LIGO) as convenient data timestamps and are not present in the default NMEA strings (although depending on firmware the GPS time can be extracted from a $PUBX,04 query).

Serial Print at SparkFun_Ublox_Arduino_Library.cpp

You have a serial print at

Line 1516 + 1517 what not belongs there

Serial.print("refStationID: ");
Serial.println(refStationID);

HighResLongitude and HighResLatitude are mixed

Subject of the issue

getHighResLongitude returns latitude readings, and getHighResLatitude returns longitude.

I notice that the order in which they are decoded for UBX_NAV_HPPOSLLH messages is reverse of the order for UBX_NAV_PVT messages.

See:
https://github.com/sparkfun/SparkFun_Ublox_Arduino_Library/blob/master/src/SparkFun_Ublox_Arduino_Library.cpp#L634
https://github.com/sparkfun/SparkFun_Ublox_Arduino_Library/blob/master/src/SparkFun_Ublox_Arduino_Library.cpp#L601

Your workbench

• Feather Huzzah ESP32 powered by USB
• SparkFun Ublox Arduino Library by SparkFun Electronics Version 1.5.0 (more info)
• SparkFun GPS-RTK2 Board - ZED-F9P with firmware v1.12 wired to I2C and powered by 3.3v to/from the Feather
• Arduino IDE v1.8.9

Steps to reproduce

Same as Example8_GetHighPrecisionPositionAndAccuracy.ino

Expected behavior

lat is lat, lon is lon

Actual behavior

lon is lat, lat is lon

Definitions for VAL_LAYER need to be shifted

Hi,
The bit definitions for the setVal layer field need to be shifted.
The current default of BBR actually sets the value in RAM.
The definitions in .h should be:

const uint8_t VAL_LAYER_RAM = (1 << 0);
const uint8_t VAL_LAYER_BBR = (1 << 1);
const uint8_t VAL_LAYER_FLASH = (1 << 2);

Let me know if you need a pull request.
Thanks!
Paul

Unhandled Ack messages

When calling a command function (e.g setUART1Output) which results in the ublox module sending a response followed immediately by an ACK, I assume it is the intent of the library to process both the response and ACK before returning from the command function.
The function waitForResponse appears to exit as soon as either the expected ACK is received, or if the expected response is received.

I am seeing an issue where specific orders of commands is resulting in commands failing.
In my case, I'm calling setUART1Output then saveConfiguration. The second call is failing.

I'll do more testing tomorrow and add further details when I work out the cause of the issue.

SENDING RXM-PMREQ, timeout

Hello, I have tried to create the following function to send the zed f9p module to sleep, however I always receive a timeout, I have tried variations of the payload as well as disabled GLONASS and the result is the same TimeOut, unfortunately there is nothing on the web to know if it is a library or technical error

void SFE_UBLOX_GPS::setSLEEP(long slp, uint8_t uartPort, uint16_t maxWait)
{
//Get the current config values for the UART port
getPortSettings(uartPort, maxWait); //This will load the payloadCfg array with current port settings

packetCfg.cls = UBX_CLASS_RXM;
packetCfg.id = UBX_RXM_PMREQ;
packetCfg.len = 16;
//packetCfg.startingSpot = 0;

//payloadCfg is now loaded with current bytes. Change only the ones we need to

payloadCfg[0] = slp;
payloadCfg[1] = slp >> 8;
payloadCfg[2] = slp >> 16;
payloadCfg[3] = slp >> 24;
payloadCfg[4] = 0x00;
payloadCfg[5] = 0x00;
payloadCfg[6] = 0x00;
payloadCfg[7] = 0x00;

sfe_ublox_status_e retVal = sendCommand(packetCfg, 10000);

if (_printDebug == true)
{
_debugSerial->print("SLEEP OF:");
_debugSerial->println(((uint32_t)payloadCfg[3] << 24) | ((uint32_t)payloadCfg[2] << 16) | payloadCfg[1] << 8 | payloadCfg[0]);

_debugSerial->println(F("SLEEP: sendCommand returned: "));
_debugSerial->println(statusString(retVal));
}

}

can you help me?

Most of maxWait arguments are ignored

There are a lot of public getXXX(uint16_t maxWait = 250) methods with default maxWait set to 250. However specified maxWait argument is ignored in most cases since implementation relies on default maxWait

int32_t SFE_UBLOX_GPS::getLatitude(uint16_t maxWait)
{
if (moduleQueried.latitude == false)
getPVT(); <-- Here getPVT uses its default maxWait

IMHO caused by too many default arguments in helper methods like:
sendCommand, sendI2cCommand, waitForResponse, getPVT

how should getXXX handle stale/failed data?

ignoring the template because this is philisophical, YOLO.

The m.o. of this library is to try to return fresh data using moduleQueried. That's great, but it doesn't leave much room for failure. In other words, take getLatitude:

//Get the current latitude in degrees
//Returns a long representing the number of degrees *10^-7
int32_t SFE_UBLOX_GPS::getLatitude(uint16_t maxWait)
{
  if (moduleQueried.latitude == false)
    getPVT();
  moduleQueried.latitude = false; //Since we are about to give this to user, mark this data as stale

  return (latitude);
}

Now, what if a call to getPVT fails? moduleQueried.latitude will still be false, but we'll just steam right ahead and return.. something. It might be super-super-stale data or the init data, there's no way to know.

I'm using iTOW as a way to sniff "last updated time", but it's a bit of a hack.

Ideas:

• haveValidData()
• lastValidUpdateTime()
• timeSinceLastSuccessfulUpdate()