Hello,

I wanted to ask, I have NEO-D9C and ZED-F9P devices, how can I use the library for QZSS-L6 library?

Is there anyone know how to use it?

Thank you

Hi @PaulZC,

Here's a Monday head-scratcher for you.

I've been testing the most recent release of the u-blox library. The tests were configured with rolling alarms that would log RAWX/SFRBX for 2 hours and sleep for 1 hour. After letting it run overnight, I discovered some very strange behaviour.

In the initial test, the first 2-hour logging period at 22:00 executes as normal. However, at 1:00, data stopped being received 45 minutes into the 2-hour period. The sleep/wake cycles continued as normal, but no data was received over the next 12 hours. Upon each wake cycle, the RTC synchronization function would also fail to obtain a GNSS fix, timing out after 5 minutes, and only 165 KB would be written to the SD card. However, magically at 16:00, data began being received again.

I use a flag to record initialization success/failure and the u-blox showed as successfully initializing at each power cycle. I thought perhaps the issue was due to low battery voltage, so I replaced the battery and repeated the test with the same firmware. As you can see in the results of Test 2, the same behaviour was observed.

I should note that I am using the gnss.end() function before powering down the u-blox. Could this in any way explain the issues described here? I am also wondering if this could also be somehow related to the file buffer or how data is being processed.

Test 1 Datetime | u-blox Init. (ms) | RTC Sync (ms) | GNSS Logging (ms) | Bytes Written | Max Buffer -- | :--: | :--: | :--: | :--: | :--: 2021-04-03 22:00:00 | 1273 | 26666 | 7200917 | 8418448 | 3016 2021-04-04 1:00:00 | 1023 | 26540 | 7235913 | 3252824 | 2680 2021-04-04 4:00:00 | 1269 | 300000 | 6974230 | 165504 | 528 2021-04-04 7:00:00 | 1270 | 300000 | 6977998 | 165576 | 528 2021-04-04 10:00:00 | 1025 | 300000 | 6987520 | 165528 | 528 2021-04-04 13:00:00 | 1024 | 300000 | 6985682 | 165552 | 528 2021-04-04 16:00:00 | 1270 | 300000 | 6924799 | 7558288 | 2624

Test 2 Datetime | u-blox Init. (ms) | RTC Sync (ms) | GNSS Logging (ms) | Bytes Written | Max Buffer -- | :--: | :--: | :--: | :--: | :--: 2021-04-04 23:00:00 | 1018 | 26240 | 7193951 | 8029560 | 2696 2021-04-05 2:00:00 | 1270 | 26213 | 7216366 | 7762696 | 2600 2021-04-05 5:00:00 | 1270 | 300000 | 6965067 | 165576 | 528 2021-04-05 8:00:00 | 1270 | 300000 | 6978940 | 165552 | 528 2021-04-05 11:00:00 | 1269 | 300000 | 6986883 | 165456 | 528 2021-04-05 14:00:00 | 1271 | 300000 | 6970831 | 3637352 | 2608

Cheers, Adam

Hi Paul,

Following-up on our conversation regarding best practices for changing the raw data logging rates, I wanted to share a couple of quick results from a logging test today.

Test setup:

• MicroMod Data Logging Carrier Board
• MicroMod Artemis Processor
• SparkFun GPS-RTK-SMA Breakout - ZED-F9P
• 6600 mAh LiPo
• GNSS Multi-Band L1/L2 Surveying Antenna (TNC) - TOP106

Configuration:

• Both systems are identically configured except for how the logging rates are set.
• The code is custom but has the DataLoggingExample4 from the u-blox library at its core.
• Both tests were conducted at the exact same time and were run for 1 hour.
• Results screenshots below are taken from Emlid's new and very handy tool "Emlid Studio" for processing .ubx data, which runs RTKLIB under the hood.

Test 1:

• Measurement and navigations rates set to one second

Code:

gnss.setNavigationFrequency(1);

Results:

• Very typical output for my location.
• Several uninterrupted connections to GPS and GLONASS satellites.
• Many L2 only signals.

Test 2:

• Measurement rate set to 1000 ms and navigation rate (ratio) set to 15.

Code:

gnss.setMeasurementRate(1000);  // Set the measurement rate to 1 second (1000 milliseconds)
gnss.setNavigationRate(15); // Set the navigation rate (ratio) to 15 to produce a solution every 15 s

Results:

• It's immediately clear that something is up.
• It appears that in many cases it was not possible for the receiver to achieve an L2 lock.
• Many of the L2 only signals are also missing.

Discussion

• It's appears that L2 performance is severely degraded when increasing the navigation rate to 15.
• I have tried difference combinations of receivers, processors and antennas to ensure that this isn't a hardware issue.
• I'm currently waiting on the NRCan PPP outputs from the above two RINEX files. I'm very curious to see what the results will be.

I'll update this issue later on!

Cheers, Adam

Subject of the issue

Hi,

by using the same code, the same lib version, the same hw, etc, but upgrading the ESP32 Arduino core library, from version 2.0.0 to version 2.0.1, it stops to work.

Initially I supposed it was a bug of the ESP32 core, but the core maintainers say it is an issue related on how many libs are using the I2C. So it seems to be an issue of this GNSS library.

The full report I have done and the discussion ongoing is reported here: https://github.com/espressif/arduino-esp32/issues/5875

Please give it a check.

Thank you, regards.

Your workbench

• What development board or microcontroller are you using? ESP32 Dev Module, ESP32 Wrover
• What version of hardware or breakout board are you using?
• How is the breakout board wired to your microcontroller? I2C
• How is everything being powered? Tested with just USB/Serial, and also with cpower supply
• Are there any additional details that may help us help you?

Steps to reproduce

Just use the Example3_GetPosition sketch.

Expected behavior

Should work.

Actual behavior

Prints the following:

u-blox GNSS not detected at default I2C address. Please check wiring. Freezing.

Subject of the issue

Using the example data logging RAWX/SFRBX (both versions w/ and w/out callbacks), and without changing the Navigational Frequency (1Hz), the processed RINEX file contains data gaps of random intervals (sometimes 3+ seconds). This is also reflected in the serial monitor when the numRAWX counter occasionally hangs up on a single count for several iterations.

I cut the I2C bridges on both MicroMod and peripheral without any change in performance. There doesn't seem to be any issues with the buffers overflowing, and also no improvement in output consistency when I disable SFRBX messages to try to decrease the message load.

Setup

MicroMod Data Logging Carrier Board MicroMod Artemis Processor SparkFun GPS-RTK-SMA Breakout - ZED-F9P UBLOX L1/L2 Antenna Formatted SanDisk 4GB microsd

Configuration

Attempted using DataLoggingExample3_RXM_SFRBX_and_RAWX and version without callbacks. (Only change was CS needed to be changed to pin 41). Hooked up exactly per instructions with Qwiic connector.

Processed raw .ubx data using RTKLIB and UNAVCO teqc, both outputting RINEX files that come with GNSS data gaps.

As a sanity check, I used Ucenter to log Raw .ubx data, and the sampling interval is consistent. Could this be an issue with the SD card? I see no indication from the buffers that it is getting hung up enough to drop data. Also tried slowing setMeasurementRate() to 10 second intervals, which still have data gaps. Unsure what other root cause it could be at this point... Appreciate the help! First time posting something here.

Snippet from RINEX file: Note in red how the subsequent GNSS data timestamp indicates it arrived 2 seconds after the first.

Serial monitor:

EDIT:

After enabling debug messages, following message occurs during hiccups: "insufficient space available! Data will be lost!". This is surprising to me because the fileBufferSize doesn't approach full. Could the write to SD be hanging up the rest of the program?

And checksum failed (lower level debugging enabled):

In the M8U Dead Reckoning Example 5 for auto HNR-ATT, the roll/pitch/heading data does not change when physically moving the device around.

Workbench

• Using SparkFun RedBoard, SparkFun Neo M8U breakout device, quik cables
• Hookup: RedBoard connected to PC with USB cable, Neo M8U connected to RedBoard with Qwik cable
• Powered thru USB port to RedBoard, Qwik cable to M8U

Steps to reproduce

When powering the M8U directly via USB and sending the appropriate UBX-CFG-HNR and UBX-CFG-MSG messages to enable a nav rate of 20hz and receive UBX-HNR-ATT messages, I get good data, i.e., moving the device around the 3 axes produces visible data change in roll, pitch, and heading. (using the U-Center application to communicate with U-BLOX devices)

When using Dead Reckoning Example5_getHNRData example in the Arduino IDE, I commented out the myGNSS.getHNRDyn and myGNSS.getHNRPVT blocks so as to isolate the data to only output from myGNSS.getHNRATT block. I get data output to the serial monitor, but moving the device around does not change the data - it always churns out the exact same numbers for roll. pitch, and heading.

Expected behavior

The roll, pitch, and heading numbers should reflect what is physically happening to the device when it is moved around the 3 axes.

Actual behavior

The roll, pitch, and heading numbers never changed when the device is moved around 3 axes.

As previously discussed - a rework of the state management code. Fewer flags, state checking moved to ubxPacket and removed from processUBX. Improved performance and reliability and maintainability. May still be scope to reduce the number of incoming UBX packet buffers. Contains all changes in add-spi-aberridg branch too :-)

Hi all. I've encountered an issue where my Artemis - ZED-F9P system will unexpectedly and permanently freeze/fail while logging RAWX/SFRBX messages. It has been incredibly hard to reproduce this failure (occurred 16 hours into a logging session, and after 12 hours a second time), and I'm having a hard time narrowing down where the root cause may be coming from, so I figured I'd ask some of the experts here.

• Software versions: Recently upgraded to GNSS Library v2.2.8 from v2.0.15. Apollo/Artemis Core v1.2.3. I'm using the RAWX Logging without Callbacks example modified with SdFat and a WDT.

• How is the breakout board wired to your microcontroller? I2C @ 400kHz with all pull-up jumpers disabled.

• How is everything being powered? Issue encountered while powered with battery. Currently seeing if I can replicate the issue over USB with serial debug messages.

Steps to reproduce

Unfortunately the first time this issue appeared I was not outputting any debug to serial. However, the behavior is qualitatively similar to this issue https://github.com/sparkfun/OpenLog_Artemis_GNSS_Logger/issues/8 in that the STAT Led was no longer flashing but the power LED was on. I also had all constellations enabled and NavigationFrequency = 1, whereas in the past I only ever used GPS L1/L2. The second time around I output "important GNSS messages", which read "checkUbloxI2C: I2C error: endTransmission returned 4" ad infinitum.

Like I mentioned, it's been hard to debug because of the difficultly in reproducing the issue. There are quite a few variables I'd like to test (number of constellations, I2C clock speed, revert to GNSS library version 2.0.15, eliminating load on Artemis by disabling SPI/Serial streams)...

Thanks!

Subject of the issue

This is more of a question than an issue. I'm using a NEO-M8U at high nav rate (~30Hz) and its been really good. After diving in to it a bit more, I've began wondering if it's possible to extract its IMU data at rates higher than 30Hz. If this is possible, it'll allow me to remove an external IMU from my setup which would save quite a bit of cost.

Your workbench

The module is connected to a ESP32 WROOM32D via qwic i2C. It's normally powered by USB, but eventually I'll be powering everything out of a motorcycle can bus.

I was wondering if you guys have any experience with getting the IMU data out separately from the UBX message at different rates. Any help is greatly appreciated!

PS I know that I should probably be asking this on the UBLOX forum, but the response times there are atrocious and this is slightly time sensitive so I'm hoping I could pick your guys' brains about this idea.

I'm having an issue interfacing the library with anything with a RP2040 processor (I've tried the code on a ThingPlus, Feather and Trinkey). It may be someone has messed around with the Arduino core. Put very simply, 99% of the time a call to begin() throws up a 'unable to connect' error. I know the board is there because:

`#include <Wire.h> //Needed for I2C to GNSS #include <SparkFun_u-blox_GNSS_Arduino_Library.h> //http://librarymanager/All#SparkFun_u-blox_GNSS

SFE_UBLOX_GNSS GNSS;

boolean UDR = false; char Model[30];

void setup() { Serial.begin(115200); // You may need to increase this for high navigation rates! while (!Serial) ; //Wait for user to open terminal Serial.println("Configuration check"); Wire1.begin(); Wire1.beginTransmission(0x42); if((Wire1.endTransmission() == 0)){ Serial.println("YES - I am definitely here"); } else{ Serial.println("NO - I am not here"); } GNSS.begin(Wire1); if (GNSS.begin(Wire1) == false) //Connect to the u-blox module using Wire port { Serial.println(F("u-blox GNSS not detected. Please check wiring. Freezing.")); while (1) ; } GNSS.setI2COutput(COM_TYPE_UBX); //Set the I2C port to output UBX only (turn off NMEA noise) }

void loop() { }`

Confirms that the board is there but throws up the error when I go to start the library. A quick zoom through the source code suggests that you're using the same code in 'isConnected'. (Sorry, I'm of an age where Pascal/Fortran was king of languages for University). Am I missing something? The library starts correctly on every other processor I've tried (SAMD M0 & M4 and STM32) and used to work fine on RP2040 architecture.

I'm trying to interface a M8U (and I spotted in the source that they occasionally throw up issues), but a M9N shows the same behaviour.

Subject of the issue

If I run the GNSS library version 2.2.9 I get a stack overflow with the code below that I never get using version 2.0.15.

Here's the MbedOS error: 11:22:24.344 -> 11:22:24.344 -> 11:22:24.344 -> ++ MbedOS Error Info ++ 11:22:24.344 -> Error Status: 0x80020125 Code: 293 Module: 2 11:22:24.344 -> Error Message: CMSIS-RTOS error: Stack overflow 11:22:24.344 -> Location: 0x2E1E3 11:22:24.344 -> Error Value: 0x1 11:22:24.344 -> Current Thread: main Id: 0x10004F40 Entry: 0x2E07D StackSize: 0x1000 StackMem: 0x10006BB0 SP: 0x1005FEEC 11:22:24.344 -> For more info, visit: https://mbed.com/s/error?error=0x80020125&tgt=SFE_ARTEMIS_ATP 11:22:24.344 -> -- MbedOS Error Info --

Your workbench

HARDWARE/LIBRARY SETUP... use the artemis red board hardware and the following libraries. I only connect the GNSS module using the qwiic wire and nothing else. The code and setup is as minimal as I could get it and still cause the stack overflow to occur quickly.

//https://github.com/sparkfun/Arduino_Apollo3/releases/tag/v2.2.1//https://github.com/sparkfun/Arduino_Apollo3/releases/tag/v2.2.1 use v2.2.1 of the Apollo3 board

https://github.com/sparkfun/SparkFun_u-blox_GNSS_Arduino_Library/releases use version 2.2.9 of the GNSS library

https://github.com/arduino-libraries/ArduinoBLE/releases use version 1.2.2 of the ArduinoBLE library

Steps to reproduce

To test, run the sketch, and use a mobile app like "Light Blue" (free in the app store), connect to the peripheral, and turn on notifications of the custom "testChar" BLE characteristic (the one with the long UUID)

Expected behavior

You should see the stack overflow somewhere in the first 5 to 300 seconds. If using the same code I go back to version 2.0.15 of the GNSS library you will never see it even after running for hours.

/*
 * HARDWARE/LIBRARY SETUP...
 * use the artemis red board hardware and the following libraries.  I only connect the GNSS module using the qwiic wire and nothing else.  The code and setup is as minimal as I could get it and still cause the stack overflow to occur quickly. 
 * 
 * //https://github.com/sparkfun/Arduino_Apollo3/releases/tag/v2.2.1//https://github.com/sparkfun/Arduino_Apollo3/releases/tag/v2.2.1
 * use v2.2.1 of the Apollo3 board
 * 
 * https://github.com/sparkfun/SparkFun_u-blox_GNSS_Arduino_Library/releases
 * use version 2.2.9 of the GNSS library
 * 
 * https://github.com/arduino-libraries/ArduinoBLE/releases
 * use version 1.2.2 of the ArduinoBLE library
 * 
 * TO TEST...
 * To test, run the sketch, and use a mobile app like "Light Blue" (free in the app store), connect to the peripheral, 
 * and turn on notifications of the custom "testChar" BLE characteristic (the one with the long UUID)
 * 
 * You should see the stack overflow somewhere in the first 5 to 200 seconds.  If using the same code I go back to version 2.0.15 
 * of the GNSS library you will never see it even after running for hours.
 * 
 */

#include <ArduinoBLE.h>

const byte PIN_QWIIC_POWER = 18;
const byte PIN_QWIIC_SCL = 8;
const byte PIN_QWIIC_SDA = 9;


#include <Wire.h> //Needed for I2C to GPS
TwoWire qwiic(PIN_QWIIC_SDA, PIN_QWIIC_SCL); //Will use pads 8/9

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

rtos::Thread thread;  // https://os.mbed.com/docs/mbed-os/v6.2/apis/thread.html
uint32_t counter = 0;
BLEService                  testService("f5b64b90-14ed-0000-82a8-0242ac130093");
BLECharacteristic             testChar ("f5b64b90-14ed-11ec-0000-0242ac130000", BLENotify, 255);
BLEService batteryService("180F");
BLEUnsignedCharCharacteristic batteryLevelChar("2A19", BLERead | BLENotify); // remote clients will be able to get notifications if this characteristic changes

// Callback: printPVTdata will be called when new NAV PVT data arrives
// See u-blox_structs.h for the full definition of UBX_NAV_PVT_data_t
//         _____  You can use any name you like for the callback. Use the same name when you call setAutoPVTcallback
//        /                  _____  This _must_ be UBX_NAV_PVT_data_t
//        |                 /               _____ You can use any name you like for the struct
//        |                 |              /
//        |                 |              |
void printPVTdata(UBX_NAV_PVT_data_t *ubxDataStruct)
{
    Serial.println();

    uint8_t valid = ubxDataStruct->valid.all;
    Serial.print(F("TEST 2... Time: ")); // Print the time
    uint8_t hms = ubxDataStruct->hour; // Print the hours
    if (hms < 10) Serial.print(F("0")); // Print a leading zero if required
    Serial.print(hms);
    Serial.print(F(":"));
    hms = ubxDataStruct->min; // Print the minutes
    if (hms < 10) Serial.print(F("0")); // Print a leading zero if required
    Serial.print(hms);
    Serial.print(F(":"));
    hms = ubxDataStruct->sec; // Print the seconds
    if (hms < 10) Serial.print(F("0")); // Print a leading zero if required
    Serial.print(hms);
    Serial.print(F("."));
    unsigned long millisecs = ubxDataStruct->iTOW % 1000; // Print the milliseconds
    if (millisecs < 100) Serial.print(F("0")); // Print the trailing zeros correctly
    if (millisecs < 10) Serial.print(F("0"));
    Serial.print(millisecs);

    long latitude = ubxDataStruct->lat; // Print the latitude
    Serial.print(F(" Lat: "));
    Serial.print(latitude);

    long longitude = ubxDataStruct->lon; // Print the longitude
    Serial.print(F(" Long: "));
    Serial.print(longitude);
    Serial.print(F(" (degrees * 10^-7)"));

    long altitude = ubxDataStruct->hMSL; // Print the height above mean sea level
    Serial.print(F(" Height above MSL: "));
    Serial.print(altitude);
    Serial.println(F(" (mm)"));

    if(BLE.connected() && testChar.subscribed()){
      testChar.writeValue("reallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreallyreally long",239, false );
    }
}

void setup()
{
  pinMode(PIN_QWIIC_POWER, OUTPUT);
  pin_config(PinName(PIN_QWIIC_POWER), g_AM_HAL_GPIO_OUTPUT); // Make sure the pin does actually get re-configured
  digitalWrite(PIN_QWIIC_POWER, HIGH);

  delay(10);
  qwiic.begin();
  qwiic.setClock(AM_HAL_IOM_400KHZ);

  delay(1000);
  am_hal_gpio_pincfg_t sclPinCfg = g_AM_BSP_GPIO_IOM1_SCL;
  am_hal_gpio_pincfg_t sdaPinCfg = g_AM_BSP_GPIO_IOM1_SDA;
  sclPinCfg.ePullup = AM_HAL_GPIO_PIN_PULLUP_NONE; // No pull-ups
  sdaPinCfg.ePullup = AM_HAL_GPIO_PIN_PULLUP_NONE;
  pin_config(PinName(PIN_QWIIC_SCL), sclPinCfg);
  pin_config(PinName(PIN_QWIIC_SDA), sdaPinCfg);
  
  //myGNSS.enableDebugging(); // Uncomment this line to enable helpful debug messages on Serial

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

  if (myGNSS.begin(qwiic, 0x42) == 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.setUART1Output(0);
  myGNSS.setUART2Output(0);
  myGNSS.setUSBOutput(0);
  myGNSS.setSPIOutput(0);
  //myGNSS.enableDebugging();
  myGNSS.setI2COutput(COM_TYPE_UBX); //Set the I2C port to output UBX only (turn off NMEA noise)
  myGNSS.setAutoPVT(true);//, false);//nodeSetting->useAutoPVT); // Use autoPVT as required
  myGNSS.saveConfigSelective(VAL_CFG_SUBSEC_IOPORT); //Save (only) the communications port settings to flash and BBR
  myGNSS.setNavigationFrequency(2); //Produce two solutions per second
  myGNSS.setAutoPVTcallbackPtr(&printPVTdata); // Enable automatic NAV PVT messages with callback to printPVTdata

  if (!BLE.begin()) {
    Serial.println("starting BLE failed!");
    while (1);
  }
  BLE.setLocalName("LP Test");
  BLE.setDeviceName("LP Test");
  BLE.setConnectionInterval(6, 12); // 7.5 ms minimum, 4 s maximum... increments of 1.25ms (6=7.5ms and 12=15ms)

  batteryService.addCharacteristic(batteryLevelChar);
  BLE.addService(batteryService); // Add the battery service  
  testService.addCharacteristic(testChar);
  BLE.addService(testService);
  BLE.setAdvertisedService(testService);
  BLE.setEventHandler(BLEDisconnected, blePeripheralDisconnectHandler);
  BLE.advertise();

  thread.start(thread_fn);          // assign thread_fn to the object thread and begin execution
}

void blePeripheralDisconnectHandler(BLEDevice device) {
  Serial.print("Disconnected event, device: ");
  Serial.println(device.address());
  BLE.advertise();
}

void thread_fn( void ){             // create a function to run as a thread


  while(1){
    rtos::ThisThread::sleep_for(10);    // equivalent to calling "delay()"
    counter++;
  }


}

void loop()
{
  myGNSS.checkUblox(); // Check for the arrival of new data and process it.
  myGNSS.checkCallbacks(); // Check if any callbacks are waiting to be processed.
  
  if(BLE.connected() && batteryLevelChar.subscribed() && counter % 100 == 0){
    batteryLevelChar.writeValue(100);
  }

}