An Arduino library which allows you to communicate seamlessly with the full range of u-blox GNSS modules

Overview

SparkFun u-blox Arduino GNSS Library

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 GNSS 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 GNSS module. Stop polling messages and parsing NMEA data! Simply ask for the datums you need and receive an automatic callback when they arrive.

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

v2.0

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

  • Seamless support for "automatic" message delivery:
    • In v1.8, you could ask for the NAV PVT (Navigation Position Velocity Time) message to be delivered automatically, without polling. v2.0 adds automatic support for 23 messages, covering the full range of: standard and High Precision position, velocity and time information; relative positioning; event capture with nanosecond time resolution; raw GNSS signal data including carrier phase; Sensor Fusion; and High Navigation Rate data.
  • Dynamic memory allocation with clearly-defined data storage structs for each message:
    • There are no static 'global' variables to eat up your RAM. v2.0 automatically allocates memory for the automatic messages when they are enabled. You may find your total RAM use is lower with v2.0 than with v1.8.
    • Each "auto" message has a clearly-defined data storage struct which follows the u-blox protocol specification precisely.
  • Callbacks:
    • No more polling! Simply request the "auto" messages you need and receive an automatic callback when each message arrives.
    • Please see the callback examples for more details.
  • Built-in support for data logging:
    • Want to log RXM SFRBX and RAWX data for Post-Processed Kinematics or Precise Point Positioning? You can absolutely do that! v2.0 provides built-in support for data logging, allowing you to log any of the "auto" messages simply and easily.
    • Incoming "auto" data can be stored in a configurable ring buffer. You can then extract the data from the buffer and write it to (e.g.) SD card using your favorite SD library.
    • Data is logged in u-blox UBX format which is compact and efficient. You can replay the data using u-center.
    • Please see the data logging examples for more details.

Migrating to v2.0

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

  • The name of the library class has changed from SFE_UBLOX_GPS to SFE_UBLOX_GNSS to reflect that the library supports all of the Global Navigation Satellite Systems:
    • As a minimum, you need to change: SFE_UBLOX_GPS myGPS;
    • to: SFE_UBLOX_GNSS myGPS;
    • But we would encourage you to use SFE_UBLOX_GNSS myGNSS;. You will see that all of the library examples now use myGNSS instead of myGPS.
  • The name of the library header and C++ files have changed too:
    • Change: #include
    • to: #include

If you are using the Dead Reckoning Sensor Fusion or High Dynamic Rate messages, you will need to make more small changes to your code. Please see the dead reckoning examples for more details. There is more detail available in Theory.md if you need it.

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

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

Documentation

Theory

If you would like to learn more about how this library works, including the big changes we made in version 2.0, please see Theory.md for full details.

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-16344 - SparkFun GPS-RTK Dead Reckoning Breakout - ZED-F9R (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-17285 - SparkFun GPS Breakout - NEO-M9N, SMA (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.
Issues
  • Inconsistent data logging

    Inconsistent data logging

    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

    image

    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

    opened by adamgarbo 21
  • Best practices: Raw data logging rates

    Best practices: Raw data logging rates

    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.

    Screen Shot 2021-06-30 at 1 53 35 PM

    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. Screen Shot 2021-06-30 at 12 20 07 PM

    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

    opened by adamgarbo 20
  • Lib not working with ESP32 by using core 2.0.1

    Lib not working with ESP32 by using core 2.0.1

    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.
    
    opened by FStefanni 19
  • RAWX data gaps in RINEX file (logging issue)

    RAWX data gaps in RINEX file (logging issue)

    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. Screen Shot 2021-10-13 at 3 04 34 PM

    Serial monitor: Screen Shot 2021-10-13 at 2 59 47 PM

    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? Screen Shot 2021-10-14 at 8 59 42 AM

    And checksum failed (lower level debugging enabled): Screen Shot 2021-10-14 at 8 53 15 AM

    opened by derekpickell 15
  • Modify state management aberridg

    Modify state management aberridg

    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 :-)

    opened by aberridg 14
  • GNSS Logger Logging Failure

    GNSS Logger Logging Failure

    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!

    opened by derekpickell 13
  • GNSS Stack Overflow error on v2.2.9

    GNSS Stack Overflow error on v2.2.9

    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);
      }
    
    }
    
    
    opened by ricozinn 10
  • [Example15_NTRIPClient] NTRIP Trimble Ntrip Caster 4.3 needs additional headers

    [Example15_NTRIPClient] NTRIP Trimble Ntrip Caster 4.3 needs additional headers

    Subject of the issue

    The NTRIP Caster I like to use needs additional headers, otherwise it will not respond anything.

    This is the caster: http://www.ntrip.sachsen.de/

    SOURCETABLE 200 OK
    Server: NTRIP Trimble Ntrip Caster 4.3
    Content-Type: text/plain
    Content-Length: 2890
    Date: Wed, 01 Dec 2021 13:00:36 UTC
    
    STR;0157_MSM;0157_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble NetR9;none;B;Y;9600;;
    STR;0132_MSM;0132_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble NetR9;none;B;Y;9600;;
    STR;0133_MSM;0133_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble NetR9;none;B;Y;9600;;
    STR;0136_MSM;0136_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble NetR9;none;B;Y;9600;;
    STR;0139_MSM;0139_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble NetR9;none;B;Y;9600;;
    STR;0140_MSM;0140_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble NetR9;none;B;Y;9600;;
    STR;0142_MSM;0142_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble NetR9;none;B;Y;9600;;
    STR;0143_MSM;0143_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble NetR9;none;B;Y;9600;;
    STR;0148_MSM;0148_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble NetR9;none;B;Y;9600;;
    STR;0149_MSM;0149_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble NetR9;none;B;Y;9600;;
    STR;0151_MSM;0151_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble NetR9;none;B;Y;9600;;
    STR;0153_MSM;0153_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble NetR9;none;B;Y;9600;;
    STR;0154_MSM;0154_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble NetR9;none;B;Y;9600;;
    STR;0156_MSM;0156_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble NetR9;none;B;Y;9600;;
    STR;0144_MSM;0144_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble NetR9;none;B;Y;9600;;
    STR;0161_MSM;0161_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble Alloy;none;B;Y;9600;;
    STR;0162_MSM;0162_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble Alloy;none;B;Y;9600;;
    STR;0163_MSM;0163_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble Alloy;none;B;Y;9600;;
    STR;0164_MSM;0164_MSM;RTCM 3.2;1006 (10),1008 (10), 1013 (60), 1033 (10);;2;GPS+GLO+GAL+BDS;SAPOS;DEU;0;0;0;0;Trimble Alloy;none;B;Y;9600;;
    CAS;31.12.57.11;80;SAPOS-SN;SAPOS-SN;0;DEU;0;0;0.0.0.0;0;4;
    NET;SAPOS_SN;GEOSN;B;Y;http://www.landesvermessung.sachsen.de;http://www.landesvermessung.sachsen.de;mailto:[email protected];;
    ENDSOURCETABLE
    

    With those changes to the sample code / headers, it does repsond:

    snprintf(
        serverRequest, 
        SERVER_BUFFER_SIZE, 
        "GET /%s HTTP/1.0\r\nUser-Agent: NTRIP TestClient/1.0\r\nNtrip-Version: Ntrip/2.0\r\nNtrip-GGA: %s\r\n",
        mountpoint,
        "$GPGGA,082513.662,5029.847,N,01208.323,E,1,12,1.0,0.0,M,0.0,M,,*6D"
    );
    

    Also as far as I know, the User-Agent header must have a specific format regarding to the NTRIP definition.

    NTRIP

    I'm running it on a TTGO-T-Call board using the [email protected]^0.10.9 client. Project is set up and compiled in PlatformIO.

    /cc @nseidle

    opened by SunboX 10
  • Automatic NMEA - VTG, RMC, ZDA

    Automatic NMEA - VTG, RMC, ZDA

    Hello,

    Could you create the same function for VTG, RMC and ZDA data? My data logger require that data in NMEA structure. Data logger: RaceChrono.

    Thank you :) Regards Tomasz.

    enhancement 
    opened by TakiKroSmaN 9
  • Library for MKR GPS Shield

    Library for MKR GPS Shield

    Subject of the issue

    Hi, I'm trying to use your library to work with the MKR GPS Shield of Arduino. It seems that this library should work according to this page https://support.arduino.cc/hc/en-us/articles/360018628960-The-MKR-GPS-shield-does-not-fetch-any-data. Probably it could work because the shield use the SAM-M8Q which you are able to manage. I've seen that your library give an example of how to connect with UART and I2C, do you know how to connect "as shield". I can't connect it in other ways. I know that it's not your own product, but I'd appreciate if you let me know if you've already solved this problem or you have any advice. Thank you in advance!

    Your workbench

    • Arduino MKR WAN 1310 (powered via USB)
    • Arduino MKR GPS Shield (connected as shield)
    opened by gabrielesartor 7
  • ZED F9P - Unable to open the port

    ZED F9P - Unable to open the port

    Subject of the issue

    I am working on integrating ZED F9P with NVIDIA Jetson NX device via USB connection.

    First, I tried with python library using the below code: https://github.com/sparkfun/Qwiic_Ublox_Gps_Py/blob/master/examples/geo_coords_ex1.py

    Replaced port = serial.Serial('/dev/serial0', baudrate=38400, timeout=1) with port = serial.Serial('/dev/ttyACM0', baudrate=38400, timeout=1). It worked fine but the GPS was unable to lock signals at all times.

    Next step, was trying to use C libraries to verify the same issue : https://github.com/sugbuv/Ublox_Linux_Library/blob/master/linux_examples/ublox_f9p_test.cpp

    But I get an error stating "Ublox is not connected. Please connect ublox GNSS module and try again..."

    It worked with python libraries but not with C. It would be helpful to get inputs on this issue or any workarounds.

    Hardware: ZED F9P with GNSS Antenna NVIDIA Jetson NX USB Connection

    opened by niranjanravilevelup 7
  • Help Wanted: Dual SPI Bus Data Logging Example

    Help Wanted: Dual SPI Bus Data Logging Example

    It would be fantastic to have an example showing how to read (e.g.) RAWX data from a ZED-F9n and write it to microSD card with SdFat - using two separate SPI busses for maximum throughput.

    This GNSS library supports SPI and I think (e,g,) the SparkFun ESP32 Thing Plus C should be capable of doing it, but it's not something I have time to try right now.

    If you would like to take on the challenge, please do!

    Sincere thanks, Paul

    help wanted 
    opened by PaulZC 0
  • SD vs ExFat - Raw Logging Tests

    SD vs ExFat - Raw Logging Tests

    Hi @PaulZC,

    I thought I'd create an issue where I can share some of the results of my ongoing tests of the new u-blox library.

    My first goal was to determine what kind of performance gains can be achieved using the ExFat classes of v2.0 of the SdFat library. Having read that 7 Hz appeared to be the upper limit for the SD library, I thought I'd start at 10 Hz. While the results below were only for a short period of time, they were quite telling!

    Test Configuration:

    • All I2C pull-ups were disabled (ZED-F9P, MMDLCB, Artemis)
    • u-blox library example: DataLoggingExample5_Fast_RXM was used for both tests, with only the library, object instantiation and write command code being modified.
    • A micros() timer was added to the SD write commands to measure latency.

    Components

    • Sparkfun Artemis Processor Board
    • SparkFun MicroMod Data Logging Carrier Board (MMDLCB)
    • SparkFun GPS-RTK2 ZED-F9P SMA
    • u-blox ANN-MB antenna

    ZED-F9P Configuration:

    • Navigation rate: 10 Hz
    • Constellation: GPS only
    • Messages logged: RAWX/SFRBX

    SD Test Configuration:

    • Arduino SD library
    • microSD card: SanDisk Industrial XI 32 GB
      • Formatted using FAT32

    ExFat Test Configuration:

    • SdFat library (SdExFat/ExFile classes)
    • microSD card: SanDisk Extreme 64 GB
      • Formatted using ExFat

    Results:

    • Figure 1 illustrates just how quickly the file buffer fills up at 10 Hz when using the SD library. It's clear that the 12 ms SD write latency is creating a bottleneck that causes the buffer to overflow.
    • The second SD test filled the buffer quicker likely because the receiver had a better fix at this time.
    • After maxing out the file buffer, eventually the entire system became non-responsible and could not be halted via serial input.
    • By comparison, the ExFat write latency of ~400 μs appears to be sufficient to allow the data to be written to the card and prevent the overflow issue.
    • I also left the ExFat tests run for longer periods of time and never saw the buffer exceed 5000 bytes.

    max_buffer Figure 1. Max buffer size over time

    latency Figure 2. SD write latencies

    Conclusion & Next Steps:

    • The performance gains offered by the new SdFat library are significant!
    • The next step will be to see just how far I can push the library when using an ExFat formatted card.
    • I'll also start looking at data integrity after longer duration logging and see if I run into any of the same gremlins you and @nseidle had run into previously.

    Cheers, Adam

    opened by adamgarbo 9
Releases(v2.2.10)
  • v2.2.10(Apr 28, 2022)

    This release:

    • Fixes an error in processUBXpacket which was causing the navigation frequency (measRate) to be reported incorrectly
      • The error was the root cause of the occasional divide-by-zero seen in getNavigationFrequency
      • getNavigationFrequency, getMeasurementRate and getNavigationRate have been wrong since v2.2.1... Sorry!
    • Adds a new example showing how to access the callback data from the main loop
    Source code(tar.gz)
    Source code(zip)
  • v2.2.9(Apr 14, 2022)

    This release:

    • Adds a destructor to resolve the memory leak documented in #135 - thank you @ricozinn for reporting
      • Apologies! This bug has been around for a very long time...
    Source code(tar.gz)
    Source code(zip)
  • v2.2.8(Apr 4, 2022)

  • v2.2.7(Mar 18, 2022)

    This release:

    • Adds a new NEO-D9S + ZED-F9P example which shows how to retrieve (and print) the PointPerfect L-Band dynamic encryption keys using MQTT on ESP32 over WiFi
    • Updates the other MQTT examples so they are able to receive MQTT (SPARTN correction or MGA AssistNow) data longer than 2KBytes
    • Adds support for UBX-RXM-COR - which allows you to monitor if the differential correction data (SPARTN, PMP or RTCM3) is being decrypted correctly and/or used by the GNSS
    • Changes the default maxWait for the setVal and getVal functions from 250ms to the standard 1.1s
      • We were seeing timeouts when changing the setting of UBLOX_CFG_SPARTN_USE_SOURCE. This change corrects that
    Source code(tar.gz)
    Source code(zip)
  • v2.2.6(Mar 9, 2022)

  • v2.2.5(Mar 7, 2022)

  • v2.2.4(Mar 3, 2022)

  • v2.2.3(Mar 2, 2022)

    This release:

    • Adds full auto support for the RMC, VTG and ZDA NMEA messages - as requested in #120
    • Adds support for the UBX-MON-HW and UBX-MON-RF messages, plus UBX-CFG-ITFM, allowing the jamming / interference status to be monitored - as suggested in #121
      • Please see the new Example29 for more details
    • Please note: adding the above changes exceeded the program memory on the Arduino Uno (ATmega328) once again... To save memory and allow the library to compile, support for auto-NMEA is now automatically disabled on Uno platforms.
    Source code(tar.gz)
    Source code(zip)
  • v2.2.2(Feb 28, 2022)

    This release:

    • Allows the code to compile on AVR DA and DB (DxCore) hardware - based on #114 - thank you @nabelekt
    • Adds the message class and IDs for the PUBX u-blox proprietary NMEA-format messages - based on #116 - thank you @nabelekt
    • Adds support for survey-in durations longer than 65535 seconds
      • To maintain backward-compatibility and avoid ambiguity errors, the longer durations are accessed via new functions: setSurveyModeFull, enableSurveyModeFull and getSurveyInObservationTimeFull
      • Please see the updated Example3 for details
      • Based on #117 - thank you @russ396
      • Resolves this old issue :-)
    Source code(tar.gz)
    Source code(zip)
  • v2.2.1(Feb 20, 2022)

    This release:

    • Adds a new example showing how to request SPARTN correction data from u-blox's PointPerfect service using MQTT - thank you @mazgch
    • Adds preliminary support for the UBX-RXM-PMP data provided by the NEO-D9S correction data receiver
    • Adds preliminary support for UBX-RXM-SPARTNKEY, allowing the PMP SPARTN encryption keys to be passed to a ZED-F9x
    • Adds a new example showing how PMP data provided by the NEO-D9S can be pushed to a ZED-F9x using callbacks - thank you @mazgch
    • Corrects "auto" support for UBX-NAV-PVAT - see issue #97
    • Corrects an error in the private extract functions - resolving issue #109
    • Adds new setAuto...callbackPtr functions which allow the message callbacks to be passed a pointer to the UBX data, instead of a full copy of the data
      • This is much kinder on the stack and prevents some badness seen on Apollo3 / Artemis
      • Please see the modified callback examples for more details
    • Adds setOutputPort as a way of outputting all UBX and NMEA data to a Serial port - thank you @mazgch
    Source code(tar.gz)
    Source code(zip)
  • v2.2.0(Jan 14, 2022)

    This release:

    • Adds full "auto" support for UBX-NAV-PVAT plus an example - see issue #97
    • Adds a new how-to guide for adding support for new messages
    • Adds "auto" support for NMEA messages GPGGA and GNGGA
      • This makes it easy to push your location to an NTRIP Caster
    • Adds new functions:
      • setMainTalkerID - which changes GNGGA to GPGGA
      • setHighPrecisionMode - which adds extra decimal places to the GGA lat, lon and alt
      • setDGNSSConfiguration - which tells the module to use fixed or floating RTK (Differential) carrier solutions
    • Adds new examples for "auto" NMEA
    • Adds a new NTRIP Caster example showing how to use the GGA callback to full effect
    • Adds the two new dynamic models (mower and e-scooter) supported by HPS 1.21 (UDR / ADR modules only)
    Source code(tar.gz)
    Source code(zip)
  • v2.1.5(Jan 9, 2022)

    This release:

    • Corrects a gremlin in pushAssistNowDataInternal - it wasn't using numDataBytes correctly when pushing offset or a sub-set of data.
    Source code(tar.gz)
    Source code(zip)
  • v2.1.4(Dec 14, 2021)

    This release:

    • Cleans up ZED-F9P/Example14 and adds ZED-F9P/Example16 (NTRIP Client with GGA)
      • ZED-F9P/Example16 tests good with RTK2Go, Emlid, and the Sachsen corrections caster
    • Changes the way the .begin assumeSuccess parameter works
      • .begin will now return true if assumeSuccess is true and if _signsOfLife is also true
      • _signsOfLife is set true if any valid UBX packet or any valid NMEA header is received
      • This allows the user to be confident that the module is connected and communicating - even if the port is congested
      • (Port congestion on Serial is usually a sign that the baud rate is too low for the enabled messages and navigation rate)
    Source code(tar.gz)
    Source code(zip)
  • v2.1.3(Dec 9, 2021)

    This release:

    • Adds softwareResetGNSSOnly
    • Includes maxWait and assumeSuccess as parameters for the three .begin functions
      • If you are using Serial and the port is already outputting messages at high rate, .begin can often fail
      • You can now either set maxWait to a large value (5000ms seems to work well) and wait for success
      • Or set maxWait to a small value (e.g. 100ms) and/or set assumeSuccess to true
    Source code(tar.gz)
    Source code(zip)
  • v2.1.2(Dec 8, 2021)

  • v2.1.1(Dec 2, 2021)

    This release:

    • Corrects the definition of UBX_MGA_DBD_RINGBUFFER_LEN and adds a fix to let the code compile on the UNO
    • Corrects the definition and checking of UBX_NAV_SAT_MAX_BLOCKS
    • Removes some unnecessary "is size_t negative" checks (size_t is always unsigned)
    • Makes some changes to the .yml file so: changes are tested on the local branch instead of the main branch; the deltas report is enabled (showing any changes in memory use)
    Source code(tar.gz)
    Source code(zip)
  • v2.1.0(Dec 1, 2021)

  • v2.0.18(Nov 18, 2021)

    This release contains several significant changes:

    • v2.0.1 of the ESP32 core no longer supports multiple I2C restarts. We have restructured the library to work around this. It now uses contiguous equal-sized transmissions when sending bulk data to the module and will still use restarts where possible. But on ARDUINO_ARCH_ESP32 platforms it will always use a stop at the end of each transmission. On other platforms, you can opt to use stops too by calling setI2cStopRestart(true).
      • Note: at the time of release (Nov. 18th 2021) the library does not run correctly on older ESP32 hardware with v2.0.1 of the core. ESP32-S2 is OK, but the original ESP32 is glitchy. This is due to a change in the way the core handles clock-stretching. A fix is in progress. Please see issue #77 for more details. The solution - for now - is to keep using v2.0.0 of the core.
    • pushRawData has also been updated (for I2C). It too will still use restarts where possible, but on ARDUINO_ARCH_ESP32 platforms it will always use a stop at the end of each transmission. You no longer have to manually set the stop parameter to true on ESP32. The code now handles single byte writes correctly too. If the user attempts to push a single byte, it will be buffered until the next time pushRawData is called.
    • The I2C code no longer performs the unnecessary write to point to the 0xFF data stream register.
    • boolean (deprecated) has been changed to bool.
    • several annoying compiler warnings have been fixed - thank you @nabelekt #78
    • u-blox_structs.h has been tidied up - thank you @nabelekt #78
    • a YAML .yml file has been added to automate checking of new pull requests.
    • on UNO platforms, the minor debug messages are deleted by default to save program memory. You no longer have to manually edit the library header file.
    Source code(tar.gz)
    Source code(zip)
  • v2.0.17(Oct 20, 2021)

    This release:

    • increases UBX_RXM_RAWX_MAX_BLOCKS from 64 to 92
      • see issue #70 and PR #74 for more details
      • this will increase the RAM footprint by 896 bytes if setAutoRXMRAWX is used, and double that if setAutoRXMRAWXcallback is used
    Source code(tar.gz)
    Source code(zip)
  • v2.0.16(Oct 18, 2021)

    This release:

    • Adds a new 'repair file' option to the UBX Integrity Checker
    • Updates the data logging examples so they will run correctly on the MicroMod Artemis Processor using v2 of Apollo3
      • The microSD chip select pin and the I2C pull-ups have been corrected for v2
    Source code(tar.gz)
    Source code(zip)
  • v2.0.15(Aug 29, 2021)

  • v2.0.14(Aug 27, 2021)

  • v2.0.13(Aug 25, 2021)

    This release:

    • Adds getESFAutoAlignment and setESFAutoAlignment #58
    • Adds the extra configuration keys for the ZED-F9R and ZED-F9T #59
    • The complete list of configuration keys is included in the keys folder
      • The txt key lists are sorted in ascending order to make it easy to diff them
      • The key list in u-blox_config_keys.h follows the format of the u-blox interface definition as far as possible, but we have had to break out the CFG_MSGOUT for the F9R and F9T seperately
    Source code(tar.gz)
    Source code(zip)
  • v2.0.12(Aug 10, 2021)

  • v2.0.11(Aug 9, 2021)

  • v2.0.10(Aug 7, 2021)

  • v2.0.9(Jul 9, 2021)

    In version 2.0.8 we came very close to using all of the program memory on platforms like the ATmega328 (Arduino Uno).

    In v2.0.9, you can reduce the amount of memory used by the library by editing the header file (SparkFun_u-blox_GNSS_Arduino_Library.h) and uncommenting line 60:

    #define SFE_UBLOX_REDUCED_PROG_MEM // Uncommenting this line will delete the minor debug messages to save memory
    

    Doing this will save approximately 15% of program memory on the ATmega328.

    On Windows platforms, you will normally find SparkFun_u-blox_GNSS_Arduino_Library.h in:

    • Documents\Arduino\libraries\SparkFun_u-blox_GNSS_Arduino_Library\src
    Source code(tar.gz)
    Source code(zip)
  • v2.0.8(Jul 1, 2021)

    This release:

    • adds SPI support - thank you @aberridg #43
    • adds the getTimeFullyResolved helper function - thank you @UT2UH #41
    • change maxNMEAByteCount to 88 and adds set/getMaxNMEAByteCount - thank you @mstranne for the suggestion #38
    • replaces the two delayMicroseconds(500) with delay(1) - thank you @MedadRufus for the suggestion #11
    • removes the !!! from examples 18 and 19
      • !!! can cause avrdude to crash
    • ensures that NMEA messages are enabled in examples 1 and 2
    Source code(tar.gz)
    Source code(zip)
  • v2.0.7(May 8, 2021)

    This release:

    • Corrects an error on the UBX ESF RAW data parsing - thank you @nparker2020 #35 #32
    • Adds stop as an optional argument for pushRawData - resolves #30 - thank you @mstranne for the suggestion
    • Corrects some compiler warnings
    Source code(tar.gz)
    Source code(zip)
  • v2.0.6(Apr 26, 2021)

    This release:

    • Adds UBX-NAV-TIMELS leap second support - see Example28 - thank you @UT2UH #25
    • Adds support for selective NMEA logging - see DataLoggingExample6_NMEA
    • Allows selection of which NMEA messages are passed to processNMEA - see example2_NMEAParsing
    • Corrects an issue where stale CFG RATE data was being returned after calling setNavigationRate #24
    Source code(tar.gz)
    Source code(zip)
Owner
SparkFun Electronics
Building opensource widgets to make prototyping hardware easier since 2002.
SparkFun Electronics
A program that allows you to hide certain windows when sharing your full screen

Invisiwind Invisiwind (short for Invisible Window) is an application that allows you to hide certain windows when sharing your full screen.

Joshua T. 56 May 25, 2022
King Hamlet is a simple tool, which allows you to perform a Process Ghosting Attack

KingHamlet Process Ghosting Tool - 64 bits Only! King Hamlet is a simple tool, which allows you to perform a Process Ghosting Attack

null 136 Jun 19, 2022
Loads a signed kernel driver which allows you to map any driver to kernel mode without any traces of the signed / mapped driver.

CosMapper Loads a signed kernel driver (signed with leaked cert) which allows you to map any driver to kernel mode without any traces of the signed /

null 107 Jul 2, 2022
Playbit System interface defines an OS-like computing platform which can be implemented on a wide range of hosts

PlaySys The Playbit System interface PlaySys defines an OS-like computing platform which can be implemented on a wide range of hosts like Linux, BSD,

Playbit 227 Jun 22, 2022
Library for STM32 microcontrollers with HAL to communicate with absolute orientation sensor Bosh BNO055.

Bosh BNO055 sensor library fro STM32 with HAL Library for STM32 microcontrollers with HAL to communicate with absolute orientation sensor Bosh BNO055.

Eryk Możdżeń 1 Nov 20, 2021
Tightly coupled GNSS-Visual-Inertial system for locally smooth and globally consistent state estimation in complex environment.

GVINS GVINS: Tightly Coupled GNSS-Visual-Inertial Fusion for Smooth and Consistent State Estimation. paper link Authors: Shaozu CAO, Xiuyuan LU and Sh

HKUST Aerial Robotics Group 448 Jul 2, 2022
Basic definitions and utility functions for GNSS raw measurement processing

gnss_comm Authors/Maintainers: CAO Shaozu (shaozu.cao AT gmail.com) The gnss_comm package contains basic definitions and utility functions for GNSS ra

HKUST Aerial Robotics Group 54 May 24, 2022
A dataset containing synchronized visual, inertial and GNSS raw measurements.

GVINS-Dataset Author/Maintainer: CAO Shaozu (shaozu.cao AT gmail.com), LU Xiuyuan (xluaj AT connect.ust.hk) This repository hosts dataset collected du

HKUST Aerial Robotics Group 101 Jul 1, 2022
Multi-GNSS Precise Point Postioning with Ambiguity Resolution

This is demo for multi-GNSS precise point positioning with ambiguity resolution (PPP-AR), which is based on RTKLIB and RTKLIB_demo5. FEATURES ppp-ar w

Chen Chao 5 Jun 16, 2022
An open source GNSS receiver

greta-oto An open source GNSS receiver This project is an open source project of a consumer level GNSS receiver. It has the capability to receive L1 b

null 23 Jun 24, 2022
ROS GNSS/INS driver for Inertial Labs positioning systems for the CARMA Platform

CARMA Inertial Labs GNSS/INS Driver This is a fork of the Inertial Labs ROS package that is used for connecting to Inertial Labs GNSS/INS, IMU-P, AHRS

null 2 Dec 26, 2021
Optimization-Based GNSS/INS Integrated Navigation System

OB_GINS Optimization-Based GNSS/INS Integrated Navigation System We open-source OB_GINS, an optimization-based GNSS/INS integrated navigation system.

i2Nav-WHU 197 Jun 24, 2022
Off The Grid (OTG) Messenger is an easy way for people to communicate through text messages when in remote areas.

Off The Grid (OTG) Messenger is an easy way for people to communicate through text messages when in remote areas. With a theoretical transmission range of 10 miles (16kms), OTG messenger can be used by groups of people to stay connected when they are in areas not serviced by mobile connectivity.

Trevor Attema 488 Jun 19, 2022
This is some utility functions/classes for having a nice way to communicate with a pico board RP2040

PicoScreenTerminal This is some utility functions/classes for having a nice way to communicate with a pico board RP2040 How to build First follow the

GuillaumeG. 4 Nov 15, 2021
communicate between usermode and kernelmode through a swapped qword ptr argument

communicate between usermode and kernelmode through a swapped qword ptr argument

null 22 Jun 23, 2022
CQC (Charmed Quark Controller) a commercial grade, full featured, software based automation system. CQC is built on our CIDLib C++ development system, which is also available here on GitHub.

The CQC Automation System What It Is CQC is a commercial quality, software based automation system, suitable for residential or commercial application

Dean Roddey 57 Jun 24, 2022
Otto-SetupAssist provides an Arduino sketch which assist you to build Otto robots.

Otto-SetupAssist Otto-SetupAssist provides an Arduino sketch which assist you to build Otto robots. This sketch provides two features: Move servos to

ROBOT.ICHIBA 1 Oct 20, 2021
Had a tough time playing Microsoft Wordament ? Well WORDament_Solver has your back. It suggests you meaningful words you can use while playing the game and help you top the leaderboard.

WORDament_Solver Had a tough time playing Microsoft Wordament ? Well WORDament_Solver has your back. It suggests you meaningful words you can use whil

Tushar Agarwal 3 Aug 19, 2021
Range library for C++14/17/20, basis for C++20's std::ranges

range-v3 Range library for C++14/17/20. This code was the basis of a formal proposal to add range support to the C++ standard library. That proposal e

Eric Niebler 3.4k Jun 28, 2022