sparkfun / sparkfun_u-blox_gnss_v3

An Arduino library which allows you to communicate seamlessly with u-blox GNSS modules using the Configuration Interface

SparkFun u-blox GNSS Arduino Library - v3

SparkFun GPS-RTK2 - ZED-F9P (GPS-15136)	SparkFun GPS-RTK-SMA - ZED-F9P (GPS-16481)	SparkFun MAX-M10S Breakout (GPS-18037)	SparkFun ZED-F9K Breakout (GPS-18719)	SparkFun ZED-F9R Breakout (GPS-16344)

u-blox makes some incredible GNSS receivers covering everything from low-cost, highly configurable modules such as the MAX-M10S all the way up to the surveyor grade ZED-F9P with precision of the diameter of a dime. This library supports configuration and control of u-blox devices over I²C (called DDC by u-blox), Serial and SPI. This version uses the u-blox Configuration Interface to: detect the module; configure message intervals; set the base location; etc.. We wrote it for the most recent u-blox modules which no longer support messages like UBX-CFG-PRT or UBX-CFG-MSG.

If you are using an older module, like the M8, you will need to use version 2 of this library.

This library can be installed via the Arduino Library manager. Search for SparkFun u-blox GNSS v3.

v3 vs. v2

This library is the new and improved version of the very popular SparkFun u-blox GNSS Arduino Library. v3 contains some big changes and improvements:

• Module detection and configuration is done exclusively using the u-blox Configuration Interface (UBX-CFG-VALSET and UBX-CFG-VALGET)
  • The library no longer uses UBX-CFG-PRT to detect the module and configure the port settings
  • UBX-CFG-MSG is no longer used to configure message intervals
  • This allows the library to work with the latest module firmware where those messages have now been deleted
• SPI support has been enhanced:
  • pushRawData is fully supported on SPI - in addition to I²C and Serial (UART)
  • pushAssistNowData is also fully supported on SPI
• The hardware interface has been abstracted:
  • All hardware communication is performed through class GNSSDeviceBus
  • This makes it much easier to re-use this library on other hardware platforms. Only sfe_bus.h and sfe_bus.cpp need to be updated
• Template methods simplify multiple-VALGET and multiple-VALSET configuration

Migrating to v3

Migrating to v3 is easy. There are two small changes all users will need to make:

• The name of the library header file has changed:
  • Change: #include <SparkFun_u-blox_GNSS_Arduino_Library.h>
  • to: #include <SparkFun_u-blox_GNSS_v3.h>
• The library now uses three separate hardware classes: SFE_UBLOX_GNSS , SFE_UBLOX_GNSS_SERIAL and SFE_UBLOX_GNSS_SPI
  • SFE_UBLOX_GNSS provides support for I²C (Qwiic / Wire) only
  • SFE_UBLOX_GNSS_SERIAL provides support for Serial (UART) only
  • SFE_UBLOX_GNSS_SPI provides support for SPI only
  • If you are using Serial or SPI, you will need to change your code to: SFE_UBLOX_GNSS_SERIAL myGNSS; or SFE_UBLOX_GNSS_SPI myGNSS;

v3 is mostly backward-compatible with v2, but there have been some important changes. If in doubt, please look at the updated examples. They have all been updated and tested with v3.

VAL_LAYER

Because all module configuration is performed using the Configuration Interface, you will find that the VAL_LAYER has been added as a parameter in many methods. The set methods default to using VAL_LAYER_RAM_BBR - i.e. the configuration will be changed and stored in both RAM and Battery-Backed RAM but not flash. Options are: VAL_LAYER_RAM, VAL_LAYER_BBR, VAL_LAYER_FLASH (if your module has flash memory attached), VAL_LAYER_RAM_BBR and VAL_LAYER_ALL (all three).

Please check your code. If you are using maxWait, you will need to specify the LAYER too. E.g.:

• v2:

  bool setAutoPVT(bool enabled, bool implicitUpdate, uint16_t maxWait = defaultMaxWait);
  bool setAutoPVTrate(uint8_t rate, bool implicitUpdate = true, uint16_t maxWait = defaultMaxWait);
  bool setAutoPVTcallback(void (*callbackPointer)(UBX_NAV_PVT_data_t), uint16_t maxWait = defaultMaxWait);

  bool setSurveyMode(uint8_t mode, uint16_t observationTime, float requiredAccuracy, uint16_t maxWait = defaultMaxWait);
  bool addGeofence(int32_t latitude, int32_t longitude, uint32_t radius, byte confidence = 0, byte pinPolarity = 0, byte pin = 0, uint16_t maxWait = defaultMaxWait);

• v3

  bool setAutoPVT(bool enabled, bool implicitUpdate, uint8_t layer = VAL_LAYER_RAM_BBR, uint16_t maxWait = kUBLOXGNSSDefaultMaxWait);
  bool setAutoPVTrate(uint8_t rate, bool implicitUpdate = true, uint8_t layer = VAL_LAYER_RAM_BBR, uint16_t maxWait = kUBLOXGNSSDefaultMaxWait);
  bool setAutoPVTcallbackPtr(void (*callbackPointerPtr)(UBX_NAV_PVT_data_t *), uint8_t layer = VAL_LAYER_RAM_BBR, uint16_t maxWait = kUBLOXGNSSDefaultMaxWait);

  bool setSurveyMode(uint8_t mode, uint16_t observationTime, float requiredAccuracy, uint8_t layer = VAL_LAYER_RAM_BBR, uint16_t maxWait = kUBLOXGNSSDefaultMaxWait);
  bool addGeofence(int32_t latitude, int32_t longitude, uint32_t radius, uint8_t confidence = 0, bool pinPolarity = 0, uint8_t pin = 0, uint8_t layer = VAL_LAYER_RAM_BBR, uint16_t maxWait = kUBLOXGNSSDefaultMaxWait);

Likewise, when reading (getting) the configuration, you can specify VAL_LAYER_RAM or VAL_LAYER_DEFAULT. The methods default to VAL_LAYER_RAM. (VAL_LAYER_BBR and VAL_LAYER_FLASH are also supported - but earlier ZED-F9P's NACK'd reading those layers.)

VALSET and VALGET

v3 provides a new way of reading (getting) values from the Configuration Interface: newCfgValget, addCfgValget and sendCfgValget. Please see the VALSET and VALGET examples for more details.

setPortOutput, setPortInput and getPortSettings have been deleted. To get (read) the port configuration, please use getVal with keys like UBLOX_CFG_I2CINPROT_UBX and UBLOX_CFG_UART1OUTPROT_NMEA. To configure the ports, please use the methods:

  bool setI2COutput(uint8_t comSettings, uint8_t layer = VAL_LAYER_RAM_BBR, uint16_t maxWait = kUBLOXGNSSDefaultMaxWait);
  bool setUART1Output(uint8_t comSettings, uint8_t layer = VAL_LAYER_RAM_BBR, uint16_t maxWait = kUBLOXGNSSDefaultMaxWait);
  bool setUART2Output(uint8_t comSettings, uint8_t layer = VAL_LAYER_RAM_BBR, uint16_t maxWait = kUBLOXGNSSDefaultMaxWait);
  bool setUSBOutput(uint8_t comSettings, uint8_t layer = VAL_LAYER_RAM_BBR, uint16_t maxWait = kUBLOXGNSSDefaultMaxWait);
  bool setSPIOutput(uint8_t comSettings, uint8_t layer = VAL_LAYER_RAM_BBR, uint16_t maxWait = kUBLOXGNSSDefaultMaxWait);

  bool setI2CInput(uint8_t comSettings, uint8_t layer = VAL_LAYER_RAM_BBR, uint16_t maxWait = kUBLOXGNSSDefaultMaxWait);
  bool setUART1Input(uint8_t comSettings, uint8_t layer = VAL_LAYER_RAM_BBR, uint16_t maxWait = kUBLOXGNSSDefaultMaxWait);
  bool setUART2Input(uint8_t comSettings, uint8_t layer = VAL_LAYER_RAM_BBR, uint16_t maxWait = kUBLOXGNSSDefaultMaxWait);
  bool setUSBInput(uint8_t comSettings, uint8_t layer = VAL_LAYER_RAM_BBR, uint16_t maxWait = kUBLOXGNSSDefaultMaxWait);
  bool setSPIInput(uint8_t comSettings, uint8_t layer = VAL_LAYER_RAM_BBR, uint16_t maxWait = kUBLOXGNSSDefaultMaxWait);

Template VALSET and VALGET

Please also note that as of Jan 10th 2023 the u-blox Config Keys defined in u-blox_config_keys.h now have their size encoded into them. We OR extra data into the unused bits in each key to define the size. This allows set and get template methods to cope with the different sizes. E.g.:

// CFG-ANA: AssistNow Autonomous and Offline configuration
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
const uint32_t UBLOX_CFG_ANA_USE_ANA = UBX_CFG_L | 0x10230001;    // Use AssistNow Autonomous
const uint32_t UBLOX_CFG_ANA_ORBMAXERR = UBX_CFG_U2 | 0x30230002; // Maximum acceptable (modeled) orbit error in m. Range is from 5 to 1000.

UBX_CFG_L is a logical boolean single bit, stored as 8-bit U1 (uint8_t). UBX_CFG_U2 is 2-byte (16-bit) unsigned (uint16_t). Etc..

If you are using the keys in your own code, you can restore the original key value by ANDing with the inverse of UBX_CFG_SIZE_MASK :

key &= ~UBX_CFG_SIZE_MASK; // Mask off the size identifer bits

The get and set template methods are based on an idea by Michael Ammann. Thank you @mazgch

Multiple-VALGET

Start by creating a custom ubxPacket :

  const uint16_t maxPayloadSize = 100; // Make this large enough to hold all keys and values
  uint8_t customPayload[maxPayloadSize]; // This array holds the payload data bytes
  ubxPacket customCfg = {0, 0, 0, 0, 0, customPayload, 0, 0, SFE_UBLOX_PACKET_VALIDITY_NOT_DEFINED, SFE_UBLOX_PACKET_VALIDITY_NOT_DEFINED}; // Create and initialise the custom packet
  myGNSS.newCfgValget(&customCfg, maxPayloadSize, VAL_LAYER_RAM); // Create a new VALGET construct inside the custom packet

Add the Keys you want to get using addCfgValget :

  myGNSS.addCfgValget(&customCfg, UBLOX_CFG_I2C_ADDRESS); // Get the I2C address (see u-blox_config_keys.h for details)
  myGNSS.addCfgValget(&customCfg, UBLOX_CFG_I2COUTPROT_NMEA); // Get the flag indicating is NMEA should be output on I2C
  myGNSS.addCfgValget(&customCfg, UBLOX_CFG_UART1_BAUDRATE); // Get the UART1 baud rate

Perform the VALGET by calling sendCfgValget(&customCfg);. The method returns true if the VALGET was successful.

Extract the Key Values using the template method extractConfigValueByKey.

Note: you do still need to know the data type to extract the data correctly.

Consult the u-blox Interface Description or u-blox_config_keys.h to see the data type (size) for each Key ID.

Size	Type
L	bool
U1/E1/X1	uint8_t
I1	int8_t
U2/E2/X2	uint16_t
I2	int16_t
U4/E4/X4	uint32_t
I4	int32_t
U8/X8	uint64_t
I8	int64_t
R4	float (32-bit)
R8	double (64-bit)

Pass a pointer to, or the address of, your variable plus its size (in bytes) to extractConfigValueByKey to extract the value. The method returns true if the extraction was successful.

  uint32_t baud; // U4
  myGNSS.extractConfigValueByKey(&customCfg, UBLOX_CFG_UART1_BAUDRATE, &baud, sizeof(baud)); // Get the baud rate - using the key and the address of and sizeof baud

Please see VALGET_and_VALSET/Example6 for more details.

Multiple-VALSET

In v2 of the library, you had to specify the key value size when calling addCfgValset. v3 uses a template method to deduce the size automatically using the size encoded into the key itself.

Start by creating a new VALSET:

  myGNSS.newCfgValset(VAL_LAYER_RAM); // Create a new VALSET construct (internally in packetCfg)

Add each key and value that you wish to set. The type / size is deduced automatically if required. The method returns true if the add is successful.

  myGNSS.addCfgValset(UBLOX_CFG_UART1_BAUDRATE, 38400); // U4 - deduced automatically
  myGNSS.addCfgValset(UBLOX_CFG_TP_DUTY_LOCK_TP1, 50.0); // R8 - deduced automatically
  uint32_t freq = 1000; // U4
  myGNSS.addCfgValset(UBLOX_CFG_TP_FREQ_LOCK_TP1, freq);

Finally, send the VALSET by calling sendCfgValset();. The method returns true if the VALSET was successful.

Please see VALGET_and_VALSET/Example6 for more details.

If you are setting many configuration items, such that the number of keys and values could overflow packetCfg, you can use the method autoSendCfgValsetAtSpaceRemaining to send a VALSET automatically when packetCfg is almost full. E.g.:

  myGNSS.autoSendCfgValsetAtSpaceRemaining(16); // Trigger an auto-send when packetCfg has less than 16 bytes are remaining

Please see VALGET_and_VALSET/Example4 for more details.

Compatibility

v3 of the library provides support for generation F9 and M10 u-blox GNSS modules.

For most generation 8 modules, please use version 2 of this library.

For generation 6 and 7, please see this example (depricated).

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.
• /Utils - contains a Python utility which can check the contents of UBX log files.

Documentation

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

Products That Use This Library

• GPS-15136 - SparkFun GPS-RTK2 Board - ZED-F9P (Qwiic)
• GPS-16481 - SparkFun GPS-RTK-SMA Breakout - ZED-F9P (Qwiic)
• GPS-16344 - SparkFun GPS-RTK Dead Reckoning Breakout - ZED-F9R (Qwiic)
• GPS-18037 - SparkFun GNSS Receiver Breakout - MAX-M10S (Qwiic)
• GPS-18719 - SparkFun GNSS-RTK Dead Reckoning Breakout - ZED-F9K (Qwiic)
• GPS-18774 - SparkFun GNSS Timing Breakout - ZED-F9T (Qwiic)
• GPS-19663 - SparkFun MicroMod GNSS Function Board - ZED-F9P
• GPS-17722 - SparkFun MicroMod GNSS Carrier Board (ZED-F9P)

License Information

This library is open source!

Please see LICENSE.md for full details.

• Your friends at SparkFun.

sparkfun_u-blox_gnss_v3's Issues

Data is not stored in BBR after myGNSS.powerOff() (software backup mode is not working)

Hello, all!
I am experiencing a weird issue after putting my u-blox MAX M10S GPS module into software backup mode using the function powerOff(). It is not storing time or location data from the previous period of being on. It is almost like it is reseting every time I put it into backup mode. This screenshot from the integration manual says that it stores the relevant data:

And this screenshot says that it retains BBR:

But, this screenshot seems contradicting, saying that the RAM is erased:

Reading futher in the inerface manual, I noticed this. Is the Sparkfun library sensing a reset message every time it "wakes up" from software backup mode?

I am using a homemade SAMD21G18A microcontroller to interface with the GPS module. The GPS module has power supplied to the V_IO and VCC pins, with nothing supplied to the V_BCKP pin, as specified. The u-blox integration manual can be found using this link (section 3.6.3/3.6.3.2).

If you're wondering what code (modified example 22) I'm using to get these results, here it is:

/*
  Powering off a ublox GNSS module
  By: bjorn
  unsurv.org
  Date: July 20th, 2020
  License: MIT. See license file for more information.

  This example shows you how to turn off the ublox module to lower the power consumption.
  There are two functions: one just specifies a duration in milliseconds the other also specifies a pin on the GNSS device to wake it up with.
  By driving a voltage from LOW to HIGH or HIGH to LOW on the chosen module pin you wake the device back up.
  Note: Doing so on the INT0 pin when using the regular powerOff(durationInMs) function will wake the device anyway. (tested on SAM-M8Q)
  Note: While powered off, you should not query the device for data or it might wake up. This can be used to wake the device but is not recommended.
        Works best when also putting your microcontroller to sleep.

  Feel like supporting open source hardware?
  Buy a board from SparkFun!
  SparkFun myGNSS-RTK2 - ZED-F9P (myGNSS-15136)    https://www.sparkfun.com/products/15136
  SparkFun myGNSS-RTK-SMA - ZED-F9P (myGNSS-16481) https://www.sparkfun.com/products/16481
  SparkFun ZED-F9K Breakout (myGNSS-18719)      https://www.sparkfun.com/products/18719
  SparkFun ZED-F9R Breakout (myGNSS-16344)      https://www.sparkfun.com/products/16344

  Hardware Connections:
  Plug a Qwiic cable into the GNSS and a BlackBoard.
  To force the device to wake up you need to connect to a pin (for example INT0) seperately on the module.
  If you don't have a platform with a Qwiic connection use the SparkFun Qwiic Breadboard Jumper (https://www.sparkfun.com/products/14425)
  Open the serial monitor at 115200 baud to see the output
*/

#define Serial SerialUSB
#include <SparkFun_u-blox_GNSS_v3.h> //http://librarymanager/All#SparkFun_u-blox_GNSS_v3
SFE_UBLOX_GNSS myGNSS;

// define a digital pin capable of driving HIGH and LOW
#define WAKEUP_PIN 11

// Possible GNSS interrupt pins for powerOffWithInterrupt are:
// VAL_RXM_PMREQ_WAKEUPSOURCE_UARTRX  = uartrx
// VAL_RXM_PMREQ_WAKEUPSOURCE_EXTINT0 = extint0 (default)
// VAL_RXM_PMREQ_WAKEUPSOURCE_EXTINT1 = extint1
// VAL_RXM_PMREQ_WAKEUPSOURCE_SPICS   = spics
// These values can be or'd (|) together to enable interrupts on multiple pins

void wakeUp() {
  Serial.print("-- waking up module via pin " + String(WAKEUP_PIN));
  Serial.println(" on your microcontroller --");

  digitalWrite(WAKEUP_PIN, LOW);
  delay(1000);
  digitalWrite(WAKEUP_PIN, HIGH);
  delay(1000);
  digitalWrite(WAKEUP_PIN, LOW);
}

void setup() {
  pinMode(WAKEUP_PIN, OUTPUT);
  digitalWrite(WAKEUP_PIN, LOW);

  Serial.begin(115200);
  while (!Serial); //Wait for user to open terminal
  Serial.println("SparkFun u-blox Example");

  Wire.begin();

  myGNSS.enableDebugging(); // Enable debug messages

  if (myGNSS.begin() == false) //Connect to the u-blox module using Wire port
  {
    Serial.println(F("u-blox GNSS not detected at default I2C address. Please check wiring. Freezing."));
    while (1);
  }
}

void loop() {
  Serial.print("Date/Time: ");
  Serial.print(myGNSS.getYear());
  Serial.print("-");
  Serial.print(myGNSS.getMonth());
  Serial.print("-");
  Serial.print(myGNSS.getDay());
  Serial.print(" ");
  Serial.print(myGNSS.getHour());
  Serial.print(":");
  Serial.print(myGNSS.getMinute());
  Serial.print(":");
  Serial.println(myGNSS.getSecond());
   
  // Powering off for 20s, you should see the power consumption drop.
  Serial.println("-- Powering off module for 20s --");

  myGNSS.powerOff(20000);
  //myGNSS.powerOffWithInterrupt(20000, VAL_RXM_PMREQ_WAKEUPSOURCE_EXTINT0);

  delay(10000);

  // After 10 seconds wake the device via the specified pin on your microcontroller and module.
  wakeUp();
}

Any help with this would be appreciated!

[Enhancement] Add support for the LNA mode configuration on the NEO-F10N

From the NEO-F10N Integration Manual:

Internal LNA mode configuration

u-blox 10 receivers support three modes for the internal low-noise amplifier (LNA): normal gain, low gain, and bypass mode. The NEO F10N default is the normal mode. With a high-gain external active antenna, the low gain or the bypass mode shall be used to save power.

Notes:

Configuration Interface key is 0x20A30057 and is documented in the Interface Description:

RTK Corrections unavailable when using RTK Express

Subject of the issue

Describe your issue here. If you reference a datasheet please specify which one and in which section (ie, the protocol manual, section 5.1.2). Additionally, screenshots are easy to paste into github.

Your workbench

• What development board or microcontroller are you using? ESP32
• What version of hardware or breakout board are you using? ESP32
• How is the breakout board wired to your microcontroller? I2C
• How is everything being powered? MicroUSB
• Are there any additional details that may help us help you?

Steps to reproduce

Tell us how to reproduce this issue. Please post stripped down example code demonstrating your issue.

#include <SparkFun_u-blox_GNSS_v3.h> 
UBX_NAV_STATUS_data_t checkRTKstatus;
Serial.println(checkRTKstatus.fixStat.bits.diffCorr);

Expected behavior

Tell us what should happen
Since I have connected the RTK Express to the GPS and powered it on, I should be receiving the RTK Corrections. But when I check the value of diffCorr variable (https://github.com/sparkfun/SparkFun_u-blox_GNSS_v3/blob/05eea9878f1e91575781d86b82642847fccce2cf/src/u-blox_structs.h#L189C9-L189C9), I always get 0.

Actual behavior

Tell us what happens instead
The value of diffCorr should be 1 when RTK Corrections are available.

Clarify ESF_ALG and Example4_vehicleDynamics

Ditto sparkfun/SparkFun_u-blox_GNSS_Arduino_Library#197

getMeasurementRate() returns inconsistent values

Hello,

I have been trying to use getMeasurementRate() verify the configuration of a SAM-M10Q module on a custom board. However, it returns "16329" value repeatedly when it pushes the data rate command. The command is pushed right after the module is powered on. I have no valid position due to no satellite coverage. I think that explains the initial "0" value.

After 50+ tries it actually returns expected value. (Still no valid position) Not sure what it could be related to.

Here is the part I request the data rate:

 // Data rate check
  measRate = myGNSS.getMeasurementRate();  // Get the measurement rate of the module
  Serial.print("Ublox Rate in Hz: ");
  Serial.println(measRate);
  while (measRate != 50) {
    Serial.print("Trying again..");
    push_ublox_command(20Hz, sizeof(20Hz));
    delay(1000);
    measRate = myGNSS.getMeasurementRate();  // Get the measurement rate of the module
    Serial.println(measRate);
  }

Your workbench

It is wired to ESP32 via UART.

Steps to reproduce

Immediately after connecting SAM-M10Q via UART serial, request the measurement rate with getMeasurementRate() .

ZED-F9K / ZED-F9R Priority Navigation Mode

Hello,

we would like to receive PVT, ATT and INS solutions at 30Hz from the ZED-F9K.

As a base example, we have modified line 58 myGNSS.setNavigationFrequency(30) in Example7_OutputRate. When indoors (in a GPS denied area), this works well and we can poll the model at 30Hz without any problems. However, when going outdoors and having Fix Type 3 or 4, the rate drops down to 5-8Hz. We are using an ESP32 and connect the ZED-F9K via I2C at 400kHz.
We have also tried the same module with a direct USB-C connection and using the ublox-ros node and are able to obtain data at 30Hz even in Fix Type 3 and 4 scenarios.
Does anyone know why this may be happening and potential solutions?

Thanks

Suggestion: Clear survey-in observation time with disableSurveyMode()

Hi @PaulZC,

I've done some testing with starting and stopping the survey-in procedure and noticed that the observation time does not get reset when .disableSurveyMode() is called. A minor suggestion that the function clears the value of dur in UBX-NAV-SVIN when called.

Cheers,
Adam

Control the rate of data from NTRIP Caster

#Subject of the issue
Using the SparkFun "NTRIPClient_With_CGA_Callback_Serial" example code I can successfully open a connection to the rtk2go base station, but my processor gets flooded with data, no matter how big I make the rtcmData buffer, it always overflows and hits the "break" statement. How can I control the rate at which data arrives from the caster (Assuming I have it correct and that's where the data is coming from?).
I have increased the serial BAUD rate to the Z9P to 203400, but things still fall over eventually.

What development board or microcontroller are you using? "DOIT ESP32 DEVKIT V1"
What version of hardware or breakout board are you using? "No breakout - Serial connection (Serial2) to u-Blox ZED-F9P GNSS receiver board"
How is the breakout board wired to your microcontroller?
How is everything being powered? "PC USB, My NTRIP server based on your example (same hardware) works a treat and has been running for many days."
Are there any additional details that may help us help you? "I am using SparkFun u-blox GNSS v3 (3.1.00)"

#Steps to reproduce
I just substituted my parameters into your example code, the only change I made was some debug to determine if "keypressed()" or "processConnection()" was causing the connection to be 'closed' - it is processConnection()

#Expected behavior
Code should not drop the connection to the rtk2go NTRIP server

#Actual behavior
The connection is "dropped"

Compatibility with MIA-M10

Has anyone tried this library with the new MIA-M10 chip? https://www.u-blox.com/en/product/mia-m10-series

Powering off using EXTINT

Hi, I am trying to turn of the MAX-M10S using the suggestions here: sparkfun/SparkFun_u-blox_GNSS_Arduino_Library#228

I have enabled both EXTINTBACKUP and EXTINTWAKE, so that the device should be completely in the control of the EXTINT pin and not wake up on any other sources. It does not seem to work yet. Can you spot anything wrong? Maybe I need to configure PSMOO as well?

https://github.com/gauteh/omb-2024-nano/blob/main/src/gnss_manager.cpp#L7:

  wdt.restart();
  Serial.println(F("Attempting to configure GPS enable pin.."));

  GnssWire.begin();

  /* turn_gnss_on(); */
  delay(1000); // Give it time to power up
  wdt.restart();

  Serial.println(F("gnss wire started"));
  Serial.flush();

  if (!gnss.begin(GnssWire, 0x42)){
    Serial.println(F("problem starting GNSS"));
    return false;

    // power things down
    delay(500);
  } else{
    Serial.println(F("success starting GNSS"));
  }

  // now we know that we can talk to the gnss
  gnss.setI2COutput(COM_TYPE_UBX); // Limit I2C output to UBX (disable the NMEA noise)
  delay(100);

  // If we are going to change the dynamic platform model, let's do it here.
  // Possible values are:
  // PORTABLE,STATIONARY,PEDESTRIAN,AUTOMOTIVE,SEA,AIRBORNE1g,AIRBORNE2g,AIRBORNE4g,WRIST,BIKE
  if (!gnss.setDynamicModel(DYN_MODEL_STATIONARY)){
    Serial.println(F("GNSS could not set dynamic model"));
  }


  Serial.println(F("configuring..."));
  gnss.newCfgValset(); // Defaults to configuring the setting in RAM and BBR
  gnss.addCfgValset(UBLOX_CFG_PM_EXTINTBACKUP, 1);
  gnss.addCfgValset(UBLOX_CFG_PM_EXTINTWAKE, 1);
  gnss.sendCfgValset(); // Send the packet using sendCfgValset
  Serial.println(F("done."));

  wdt.restart();
  GnssWire.end();

  return true;
}

Missing return in extractConfigValueByKey

As observed by @adamgarbo - thanks!

There is a missing return (true); right here:

SparkFun_u-blox_GNSS_v3/src/u-blox_GNSS.h

Lines 502 to 503 in f95988e

	*value = (int8_t)extractSignedChar(pkt, ptr);
	break;

CAM-M8C not detected (regression issue from version 2)

Subject of the issue

Your lib v3 cannot detect an I2C CAM-M8C-0-10 while lib v2 detects successfully.

Your workbench

• What development board or microcontroller are you using? - ESP32 Frogboard
• What version of hardware or breakout board are you using? - CAM-M8C
• How is the breakout board wired to your microcontroller? - Default GPIO SDA/SCL pins
• How is everything being powered? - USB

Steps to reproduce

I used Example 29 Jamming info in both lib versions.

Expected behavior

The module is detected.

Below are the logs from v2.

SparkFun u-blox GNSS Example
createFileBuffer: Warning. fileBufferSize is zero. Data logging is not possible.

Sending: CLS:CFG ID:0x0 Len: 0x1 Payload: 0
sendCommand: Waiting for ACK response
checkUbloxI2C: Reading 38 bytes
Incoming: Size: 20 Received: CLS:CFG ID:0x0 Len: 0x14 Payload: 0 0 0 0 84 0 0 0 0 0 0 0 7 0 3 0 0 0 0 0
packetCfg now valid
packetCfg classAndIDmatch
Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 0
packetCfg now valid
packetAck now valid
packetCfg classAndIDmatch
packetAck classAndIDmatch
waitForACKResponse: valid data and valid ACK received after 37 msec

Sending: CLS:CFG ID:0x39 Len: 0x0 Payload:
sendCommand: Waiting for ACK response
checkUbloxI2C: Reading 26 bytes
Incoming: Size: 8 Received: CLS:CFG ID:0x39 Len: 0x8 Payload: F3 AC 62 AD 1E 3 0 0
packetCfg now valid
packetCfg classAndIDmatch
Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 39
packetCfg now valid
packetAck now valid
packetCfg classAndIDmatch
packetAck classAndIDmatch
waitForACKResponse: valid data and valid ACK received after 36 msec
The jamming / interference monitor is enabled

Actual behavior

The module isn't detected.

Below are the logs from v3.

SparkFun u-blox GNSS Example
createFileBuffer: Warning. fileBufferSize is zero. Data logging is not possible.
getVal key: 0x10710001

Sending: CLS:CFG ID:0x8B Len: 0x8 Payload: 0 0 0 0 1 0 71 10
sendCommand: Waiting for ACK response
checkUbloxI2C: 10 bytes available
processUBX: NACK received: Requested Class: 0x6 Requested ID: 0x8B
Incoming: Size: 2 Received: CLS:ACK ID:0x0 Len: 0x2 Payload: 6 8B
packetCfg now valid
packetAck now valid
waitForACKResponse: data was NOTACKNOWLEDGED (NACK) after 23 msec
getVal: sendCommand returned: Command not acknowledged (NACK)
begin: isConnected - second attempt
getVal key: 0x10710001

Sending: CLS:CFG ID:0x8B Len: 0x8 Payload: 0 0 0 0 1 0 71 10
sendCommand: Waiting for ACK response
checkUbloxI2C: 235 bytes available
processUBX: NACK received: Requested Class: 0x6 Requested ID: 0x8B
Incoming: Size: 2 Received: CLS:ACK ID:0x0 Len: 0x2 Payload: 6 8B
packetCfg now valid
packetAck now valid
waitForACKResponse: data was NOTACKNOWLEDGED (NACK) after 37 msec
getVal: sendCommand returned: Command not acknowledged (NACK)
begin: isConnected - third attempt
getVal key: 0x10710001

Sending: CLS:CFG ID:0x8B Len: 0x8 Payload: 0 0 0 0 1 0 71 10
sendCommand: Waiting for ACK response
checkUbloxI2C: 10 bytes available
processUBX: NACK received: Requested Class: 0x6 Requested ID: 0x8B
Incoming: Size: 2 Received: CLS:ACK ID:0x0 Len: 0x2 Payload: 6 8B
packetCfg now valid
packetAck now valid
waitForACKResponse: data was NOTACKNOWLEDGED (NACK) after 23 msec
getVal: sendCommand returned: Command not acknowledged (NACK)
u-blox GNSS not detected at default I2C address. Please check wiring. Freezing.

[Feature Request] Add helper methods for the antenna settings

Hello,

at the moment there are no functions and to change the antenna settings. Commands like this must therefore be used:

gnss_i2c.setVal8(0x10a3002f, 1); //Enable short antenna detection flag gnss_i2c.setVal8(0x10a30031, 1); //Enable open antenna detection flag gnss_i2c.setVal8(0x10a3002e, 1); //Enable active antenna voltage control flag

It would be good to implement these functions.

Thank you!

Best regards,
Michael

[Enhancement] Add support for L5 signal health configuration on the NEO-F10N

From the NEO-F10N Integration Manual:

GPS L5 signal health status configuration

To evaluate GPS L5 signals before they become fully operational, the receiver can be configured to ignore the GPS L5 health status by overriding it with the respective GPS L1 C/A signal status.

To ignore the GPS L5 signal health status and override it with the respective GPS L1 signal health status, send the configuration string given in Table 4.

Notes:

Configuration Interface key is 0x10320001 - which is not documented in the Interface Description. But is one bit (bool).

NTRIP Connection dropped

Subject of the issue

Using the SparkFun "NTRIPClient_With_CGA_Callback_Serial" example code I can successfully open a connection to the rtk2go base station, but after about ~4 times round the main loop(), the connection is dropped - how can I determine why it was dropped and how do I stop it being dropped?

Your workbench

• What development board or microcontroller are you using? "DOIT ESP32 DEVKIT V1"
• What version of hardware or breakout board are you using? "No breakout - Serial connection (Serial1) to u-Blox ZED-F9P GNSS receiver board"
• How is the breakout board wired to your microcontroller?
• How is everything being powered? "PC USB, My NTRIP server based on your example (same hardware) works a treat and has been running for many days."
• Are there any additional details that may help us help you? "I am using SparkFun u-blox GNSS v3 (3.0.16)"

Steps to reproduce

I just substituted my parameters into your example code, the only change I made was some debug to determine if "keypressed()" or "processConnection()" was causing the connection to be 'closed' - it is processConnection()

Expected behavior

Code should not drop the connection to the rtk2go NTRIP server

Actual behavior

The connection is "dropped"

lastCorrectionAge in UBX-NAV-PVT is missing

Hello,

the bits from lastCorrectionAge in the flags3 from the UBX-NAV-PVT is missing.

At the moment the union is this:

union { uint8_t all; struct { uint8_t invalidLlh : 1; // 1 = Invalid lon, lat, height and hMSL } bits; } flags3;

Please change it to:

union { uint8_t all; struct { uinit8_t invalidLlh : 1; // 1 = Invalid lon, lat, height and hMSL uinit8_t lastCorrectionAge : 4 } bits; } flags3;
Thank you!

Best regards,
Michael

SV data updates very slow, over 10 seconds between valid data.

Subject of the issue

NAV_SAT data is severely delayed / slow, with a refresh every almost 15seconds between valid data.
Get the following error over I2C with an ESP32S3 running I2C at both 100khz and 400khz.

• Running Example 33 for NAV_SAT.
• Running on ESP32S3 dev kit.
• GPS: UBlox NEO-M9N over I2C

Here's a snippet of the debug output:

13:30:08.160 -> Sending: CLS:NAV ID:0x35 Len: 0x0 Payload:
13:30:08.160 -> sendCommand: Waiting for No ACK response
13:30:08.160 -> checkUbloxI2C: 70 bytes available
13:30:08.160 -> checkUbloxI2C: 5 bytes available
13:30:08.299 -> checkUbloxI2C: 32767 bytes available
13:30:09.125 -> Checksum failed: checksumA: 0 checksumB: 6 rollingChecksumA: 93 rollingChecksumB: 92
13:30:10.107 -> Checksum failed: checksumA: 0 checksumB: 0 rollingChecksumA: 26 rollingChecksumB: 34
13:30:11.342 -> processUBX: buffer overrun detected! activePacketBuffer: 0 maximum_payload_size: 3068
13:30:11.342 -> waitForNoACKResponse: CLS/ID match but failed CRC after 3198 msec
13:30:11.389 -> 
13:30:11.389 -> Sending: CLS:NAV ID:0x35 Len: 0x0 Payload:
13:30:11.389 -> sendCommand: Waiting for No ACK response
13:30:11.669 -> checkUbloxI2C: 32767 bytes available
13:30:12.122 -> Checksum failed: checksumA: 89 checksumB: 0 rollingChecksumA: 229 rollingChecksumB: 60
13:30:13.121 -> Checksum failed: checksumA: 25 checksumB: 27 rollingChecksumA: 27 rollingChecksumB: 54
13:30:14.118 -> Checksum failed: checksumA: 29 checksumB: 83 rollingChecksumA: 185 rollingChecksumB: 194
13:30:14.759 -> waitForNoACKResponse: CLS/ID match but failed CRC after 3376 msec

[Feature Request] Add support for UBX ESF-RESETALG

Based on:

sparkfun/SparkFun_u-blox_GNSS_Arduino_Library#203 (comment)

Tagging @cturvey , @Eric-FR

setStaticPosition does not set Fixed mode

As observed by @adamgarbo - thanks!

In v2 of the library, setStaticPosition sets the mode to fixed:

https://github.com/sparkfun/SparkFun_u-blox_GNSS_Arduino_Library/blob/3416a3140fb74c3b80fc680140d029182fcd03ad/src/SparkFun_u-blox_GNSS_Arduino_Library.cpp#L7597

In v3, we've missed that step. In should happen here:

SparkFun_u-blox_GNSS_v3/src/u-blox_GNSS.cpp

Lines 7288 to 7289 in 3444ad3

	bool result = newCfgValset(layer);
	result &= addCfgValset8(UBLOX_CFG_TMODE_POS_TYPE, (uint8_t)latLong);

Missing callbacks for NMEA messages

Subject of the issue

Callbacks (which can be set for e.g. NMEA GGA messages) are called only once, even that buffer on serial line contained more messages.

Your workbench

Wemos D1 mini ESP32 (ESP-WROOM-32)
GPS Beitian BK-280 (Ublox M9)
Connected using ESP Serial2 port. Now powered by USB.

Steps to reproduce

uint32_t tstcounter = 0;

void callbackGPGGA(NMEA_GGA_data_t *nmeaData)
{
    tstcounter++;
}

void setup()
{
    Serial.begin(115200);
    delay(1000);

    Serial2.setRxBufferSize(4096);
    Serial2.begin(115200); // GPIO Rx 16, Tx 17

    while (myGNSS.begin(Serial2) == false) // Connect to the u-blox module
    {
        Serial.println(F("u-blox GNSS not detected"));

        Serial.println(F("Retrying..."));
        delay(1000);
    }

    myGNSS.setNMEAGPGGAcallbackPtr(&callbackGPGGA); // register callback for GGA NMEA message
}

void loop()
{
    if (Serial2.available() > 2000) 
    {
        tstcounter = 0;
        myGNSS.checkUblox();
        myGNSS.checkCallbacks();
        Serial.printf("Callback was called: %d times\n", tstcounter);
    }
}

Expected behavior

Callback should be called for each received NMEA message. Also I would expect that check for callback is made inside the library (when doing reading and parsing during e.g. checkUblox or getPVT)

Actual behavior

The code above will always report 1 time of callback call, even that Serial buffer contain around 20 GGA messages.

getModuleInfo() fails for UBX-M10050-KB

Subject of the issue

I found that getModuleInfo() returns false for my UBX-M10050-KB device. I have also found out that it happened because the payload did't contain 'MOD=' substring.

Here's the debug output I get, showing that there's no such substring, while FWVER and PROTVER are present:

Sending: CLS:MON ID:0x4 Len: 0x0 Payload:
sendCommand: Waiting for No ACK response
Incoming: Size: 160 Received: CLS:MON ID:0x4 Len: 0xA0 Payload: 46 57 56 45 52 3D 53 50 47 20 35 2E 31 30 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 50 52 4F 54 56 45 52 3D 33 34 2E 31 30 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 47 50 53 3B 47 4C 4F 3B 47 41 4C 3B 42 44 53 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 53 42 41 53 3B 51 5A 53 53 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
packetCfg now valid
packetCfg classAndIDmatch
waitForNoACKResponse: valid data with CLS/ID match after 233 msec

I decoded it using the following Python one-liner:

>>> s = "46 57 56 45 52 3D 53 50 47 20 35 2E 31 30 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 50 52 4F 54 56 45 52 3D 33 34 2E 31 30 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 47 50 53 3B 47 4C 4F 3B 47 41 4C 3B 42 44 53 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 53 42 41 53 3B 51 5A 53 53 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0"
>>> "".join([chr(int(x, 16)) for x in s.split(' ')])
'FWVER=SPG 5.10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00PROTVER=34.10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00GPS;GLO;GAL;BDS\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00SBAS;QZSS\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
>>>

Expected result

Probably, DevUBLOXGNSS::getModuleInfo() could be fixed by not expecting all three items to be present.

UBX-NAV-SAT access

Hello,

I can get the data from UBX-NAV-SAT via getNAVSAT(), but access to the data is not possible. Either I cannot find the function or it does not exist. I ask for explanation or implementation.

Thanks you!

Best regards,
Michael

Relative Position NED not returning proper data over I2C.

Subject of the issue

I am able to view Relative Position NED data from the U-Blox U-Center application via USB. I have the Relative Position NED automatically sending packets over the UBX protocol, and can view those packets being sent. When connected over I2C, I am able to receive positional data from the simple GetPosition Arduino example, however, when I test the RelativePositionInformation example, the packet returns zero for all data points.

Your workbench

• What development board or microcontroller are you using? Arduino Mega 2560
• What version of hardware or breakout board are you using? SparkFun RTK-2 Zed-F9P breakout.
• How is the breakout board wired to your microcontroller? Wired over I2C using Qwiic connectors, then to Dupont wires into the Arduino.
• How is everything being powered? GPS modules are powered over the I2C Qwiic connector to Arduino. Arduino powered via USB.
• Note: Something that is missing from the image given is that I have a single wire for serial TX to RX (moving base GPS, to moving rover GPS) connected to to the header pins I added to the breakout boards. This is used for the movement of RTCM3 correction data.
• Another note: GPS antennas were also connected during testing, which are not included in the image.

Steps to reproduce

1. Connect rover GPS that produces RelPosNED solutions via USB to computer with U-Blox U-center application.
2. Double check that Relative Position NED is working within u-center. (Gives valid solution) and receives heading information.
3. Disconnect USB cable.
4. Run Arduino code and see that zeros are output from every data point. The only data that is set correctly is gnssFixOK. After a good while, diffSoln will also set itself to true.

Stripped down code from the Zed-F9P > Example5_RelativePositioningInformation.ino example:

#include <Wire.h> //Needed for I2C to GNSS

#include <SparkFun_u-blox_GNSS_v3.h> //http://librarymanager/All#SparkFun_u-blox_GNSS_v3
SFE_UBLOX_GNSS myGNSS;

// Callback
void printRELPOSNEDdata(UBX_NAV_RELPOSNED_data_t *ubxDataStruct)
{
  Serial.println();
  Serial.println("New RELPOSNED data received:");

  Serial.print("relPosLength (m): ");
  Serial.println(((double)ubxDataStruct->relPosLength / 100) + ((double)ubxDataStruct->relPosHPLength / 10000), 4); // Convert cm to m
  Serial.print("relPosHeading (Deg): ");
  Serial.println((double)ubxDataStruct->relPosHeading / 100000); // Convert deg * 1e-5 to degrees

  Serial.print("gnssFixOk: ");
  if (ubxDataStruct->flags.bits.gnssFixOK == true)
    Serial.println("x");
  else
    Serial.println("");

  Serial.print("diffSolution: ");
  if (ubxDataStruct->flags.bits.diffSoln == true)
    Serial.println("x");
  else
    Serial.println("");

  Serial.print("relPosValid: ");
  if (ubxDataStruct->flags.bits.relPosValid == true)
    Serial.println("x");
  else
    Serial.println("");

  Serial.print("carrier Solution Type: ");
  if (ubxDataStruct->flags.bits.carrSoln == 0)
    Serial.println("None");
  else if (ubxDataStruct->flags.bits.carrSoln == 1)
    Serial.println("Float");
  else if (ubxDataStruct->flags.bits.carrSoln == 2)
    Serial.println("Fixed");

  Serial.print("isMoving: ");
  if (ubxDataStruct->flags.bits.isMoving == true)
    Serial.println("x");
  else
    Serial.println("");
}

void setup()
{
  delay(1000);
  
  Serial.begin(115200);
  Serial.println("u-blox Base station example");

  Wire.begin();
  Wire.setClock(400000); //Increase I2C clock speed to 400kHz

  while (myGNSS.begin(Wire, 0x43) == false) //Connect to the u-blox module using Wire port
  { 
    Serial.println(F("u-blox GNSS not detected at default I2C address. Please check wiring. Retrying..."));
  }

  myGNSS.setAutoRELPOSNEDcallbackPtr(&printRELPOSNEDdata); // Enable automatic NAV RELPOSNED messages with callback to printRELPOSNEDdata
}

void loop()
{
  myGNSS.checkUblox(); // Check for new RELPOSNED data
  myGNSS.checkCallbacks();
}

Expected behavior

Return proper data from RelPosNED.

Actual behavior

All data points return zero from RelPosNED.

Error in connecting in serial mode

i am getting this

when i am try to connect to gps02-ubx using esp32c3

`#include "HardwareSerial.h"
#include <SparkFun_u-blox_GNSS_v3.h> //http://librarymanager/All#SparkFun_u-blox_GNSS_v3
SFE_UBLOX_GNSS myGNSS;

HardwareSerial mySerial(1);

long lastTime = 0; //Simple local timer. Limits amount if I2C traffic to u-blox module.

struct gps_readings {
long lat, lon, alt;
};

void gps_init() {
Serial.println("GPS initializing....");

do {
Serial.println("GNSS: trying 38400 baud");

mySerial.begin(38400, SERIAL_8N1, RX1_PIN, TX1_PIN);

myGNSS.enableDebugging();  // Uncomment this line to enable helpful debug messages on Serial
myGNSS.connectedToUART2();  // This tells the library we are connecting to UART2 so it uses the correct configuration keys

if (myGNSS.begin(mySerial) == true) break;

delay(100);
Serial.println("GNSS: trying 9600 baud");
mySerial.begin(9600, SERIAL_8N1, RX1_PIN, TX1_PIN);
if (myGNSS.begin(mySerial) == true) {
  Serial.println("GNSS: connected at 9600 baud, switching to 38400");
  myGNSS.setSerialRate(38400);
  delay(100);
} else {
  //myGNSS.factoryDefault();
  delay(2000);  //Wait a bit before trying again to limit the Serial output
}

} while (1);
// Serial.println("GNSS serial connected");
Serial.println("The GPS is successfully initialized.");
Serial.println("================================================");

myGNSS.setUART1Output(COM_TYPE_UBX); //Set the UART port to output UBX only
myGNSS.saveConfiguration(); //Save the current settings to flash and BBR
}
`

SPI connection F9R ESP

Hello,

We are trying to get the GPS Dead Reckoning ZED-F9R breakout board to connect via SPI with an ESP32 Wrover module but are not having any success, we receive the error that the GNSS module cannot be detected. It works well using I2C.
We have shorted the SPI connector pads on the back of the module and have ensured that everything is hooked up correctly. We have also switched to SFE_UBLOX_GNSS_SPI.

We have tried the standard example and have also tried modifying the code like this:

SPI.begin(SCK, MISO, MOSI, SS);
SPI.setFrequency(myClockSpeed);
ESP_LOGI("SPI", "Trying SPI");
while (moto_gps.begin(SPI, SS, 4000000) == false) {
    ESP_LOGI("SPI", "u-blox GNSS not detected. Retrying...");
    delay(1000);
}

Has anyone had any success running the SPI example with an esp32 and the zed-f9r?
Any help would be greatly appreciated.

Thanks!
Nico

Receive GSA and GSV

Hello,

with the function getLatestNMEAGNGGA it is possible to get the GGA sentence. I cannot find a function for GSA and GSV. Is it possible to implement that two sentences.

Thank you!

Best regards,
Michael

I2C held up for over 1sec

Hi There,
I have a SparkFun MAX-M10S wired via i2c to a Pi Pico running earlephilhower core 3.9.4. I am using different I2C lines but confirm this works with all other devices on the circuit.

However when I run my code to get data, the first function (normally myGNSS.getPVT(), but seems to be any function) will take over 1 second to return anything. After which all remaining commands will take 0ms.

It is preventing access to the I2C lines and stalling the processor for too long, preventing button recognition and screen refresh. Making device very laggy.

I have simplified my code as show below, my serial output come back as:
1010 0
1006 0
1005 0
1006 0
1004 0
Got Fix 904 0
Got Fix 906 0
Got Fix 1010 0

Showing that both with and without satellite fix the first poll of the Max10S takes ~1000ms and rest of functions take 0ms

#include <Wire.h>  //Needed for I2C to GNSS

#include <SparkFun_u-blox_GNSS_v3.h>  //http://librarymanager/All#SparkFun_u-blox_GNSS_v3
SFE_UBLOX_GNSS myGNSS;

long lastTime1 = 0;  //Simple local timer. Limits amount if I2C traffic to u-blox module.
long lastTime2 = 0;
long now = 0;
int32_t latitudeTX;
int32_t longitudeTX;
int min_check;
int Broadcast_Int = 2;  //has to be greater than number oof nodes
int t_sec;
int t_min;
int t_hour;
int fixType;

void setup() {
  Serial.begin(115200);
  Serial.println("SparkFun u-blox Example");
  delay(2);
  Wire.setClock(400000);
  Wire.begin();

  if (myGNSS.begin() == false)  //Connect to the u-blox module using Wire port
  {
    Serial.println(F("u-blox GNSS not detected at default I2C address. Please check wiring. Freezing."));
    while (1)
      ;
  }

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

void loop() {

  lastTime1 = millis();
  if (myGNSS.getPVT() == true) {
    lastTime2 = millis();
    if (myGNSS.getTimeValid()) {
      t_hour = myGNSS.getHour();
      t_min = myGNSS.getMinute();
      fixType = myGNSS.getFixType();
      if (fixType == 5) {
        fixType = 0;
      }
      if (fixType >= 2) {
        latitudeTX = myGNSS.getLatitude();
        longitudeTX = myGNSS.getLongitude();
      }
    }
  }
  now = millis();
  if (fixType >= 2) {
    Serial.print("Got Fix "); //print if we get a sat fix
  }
  long change = now - lastTime1;
  Serial.print(change); //Time in millis of every GPS command
  Serial.print("  ");
  change = now - lastTime2;
  Serial.println(change);//Time in millis of every GPS command besides first one
  delay(3000);
}

RTCM over UART

Hello,

I am trying to send over UART RTCM data. Unfortunately, only defective packages arrive at the ZED-F9P. I checked this with the u-center. Here is the command: gnss_serial.pushRawData(data, counter, false);

When I send the same data over I2C, the transfer works fine. gnss_i2c.pushRawData(data, counter, false);

The UART is set correctly because other commands work fine. I suspect that the pushRawData function for UART is not working properly. Please check this...

Thanks very much!

Best regards
Michael

ZED-F9R: UART1 Dying After around 10mins of usage

Im using the ZED-F9R breakout board(HPS Version 1.3), with a Teensy 32 connected to the UART1 pins of the ZED-F9R, with a baud rate of 115200. When I set a solution rate* higher than the default rate of 1Hz, (myGNSS.getHPPOSLLH()) || (myGNSS.getPVT()) will continuously return false after around 700s of usage.

When restarting the device(power cycle), I notice that a baud rate of 38400 is connected to first, despite 115200 being what was written to configuration. This makes me think that the reason for this issue is that the UART1 port is dying as there are too many UBX messages sent.

The issue is solved by switching back to the default measurement rate of 1Hz, but I would like a solution rate of around 10Hz.

Would it be possible to still do this using UART1 or is switching to SPI/I2C necessary? Can I (or rather should I) enable only relevant messages for GPS coordinate finding and ESF status? Off the top of my head Im thinking UBX-NAV-PVT, UBX-NAV-HPPOSLLH and UBX-ESF-STATUS, but I'm not too sure if this is advisable.

Something interesting I have observed is that I could only reproduce the issue while moving. When leaving the unit there over time, there are no issues. Once I am out with a bike the UART1 port fails.

*My definition of solution rate is $MeasurementRate \times NavigationRate$. By default this is $1000\times1$ so a new solution is produced every 1s.

For example, this fails, but doesnt fail when a ZED-F9P is used.

//Solution rate of 0.1s
GNSS.setMeasurementRate(50);
GNSS.setNavigationRate(2);

Implementation Details

• Dynamic Model: Escooter
• IMU Alignment Angles set manually
• AutoPVT and AutoHPPOSLLH set to true.