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.
Comments
  • NEO-D9C with ZED F9P

    NEO-D9C with ZED F9P

    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

    opened by lurunawjan 29
  • 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
  • Neo M8U HNR-ATT data not changing when physicallly moving the device

    Neo M8U HNR-ATT data not changing when physicallly moving the device

    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.

    opened by N129BZ 14
  • 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
  • NEO-M8U IMU data (UBX_ESF_RAW_MAX_LEN not correct)

    NEO-M8U IMU data (UBX_ESF_RAW_MAX_LEN not correct)

    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.

    bug resolved 
    opened by adamoskaranikas 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
  • getRXMSFRBX and getRXMRAWX contain odd call to TIM related functionality

    getRXMSFRBX and getRXMRAWX contain odd call to TIM related functionality

    Subject of the issue

    I'm not sure if this is really an issue but it might be related to issues reported in conjunction with RAWX and SFRBX. I would appreciate if somebody could confirm that the current implementation is correct.

    In getRXMSFRBX and getRXMRAWX respectively, there is a call to checkUbloxInternal(&packetCfg, UBX_CLASS_TIM, UBX_TIM_TM2);. This seems odd as I would have expected a call similar to checkUbloxInternal(&packetCfg, UBX_CLASS_RXM, UBX_RXM_RAWX);. This is also the case in other functions.

    Can somebody confirm that the current implementation is correct?

    opened by FerdinandvHagen 0
Releases(v2.2.19)
  • v2.2.19(Nov 6, 2022)

    This release:

    • Adds autoSendCfgValsetAtSpaceRemaining
      • Calling (e.g.) myGNSS.autoSendCfgValsetAtSpaceRemaining(16); will cause the current cfgValset message to be sent automatically when there are 16 bytes or less remaining in packetCfg.payload
      • This allows you to simply keep adding keyIDs and values (using the addCfgValset methods) and not needing to worry about how much space is remaining in packetCfg
      • Please see the updated Example9_multiSetVal for more details
    Source code(tar.gz)
    Source code(zip)
  • v2.2.18(Oct 28, 2022)

    This release:

    • Adds new methods to make it easier to assemble and apply multiple-CFG-VALSET configuration changes
      • newCfgValset initializes a new, empty UBX-CFG-VALSET construct
      • sendCfgValset sends (applies) the construct
      • getCfgValsetLen returns the number of KeyID & Value pairs in the construct
      • getCfgValsetSpaceRemaining returns the number of free bytes remaining in the construct (packetCfgPayload)
      • Example9 has been updated to show how to use the new methods
    • Adds a new example which shows how to log high rate RAWX data using SPI and 4-bit SDIO (SD_MMC on ESP32)
      • We've tested this on a new board - the OpenLog ESP32. Coming Soon! It is able to log SFRBX, RAWX and NMEA at 20Hz, completely error-free
    Source code(tar.gz)
    Source code(zip)
  • v2.2.17(Oct 17, 2022)

    This release:

    • Corrects the RTCM examples - especially the examples for the NEO-M8P
      • Previously the RTCM3 protocol was being disabled on I2C, preventing the RTCM messages from being output
      • Resolves issue #160
    • Adds two new examples for the NEO-D9C QZSS-L6 correction data receiver
    Source code(tar.gz)
    Source code(zip)
  • v2.2.16(Sep 21, 2022)

  • v2.2.15(Sep 9, 2022)

    This release:

    • Corrects support for ESF MEAS sensor data on the NEO-M8U and ZED-F9R
      • The ESF MEAS message is output-only, it cannot be polled
      • This means that getEsfDataInfo and getESFMEAS were not correct - they have been deleted in this release
      • A new example shows how to access the ESF MEAS data from inside the loop
      • The example has been tested on both NEO-M8U and ZED-F9R. 400kHz I2C is required. The example uses 230400 baud to allow the Serial Monitor prints to keep up.
    Source code(tar.gz)
    Source code(zip)
  • v2.2.14(Sep 9, 2022)

    This release:

    • Adds helper functions for HPPOSECEF - plus a new example
    • Corrects support for ESF RAW IMU sensor data on the NEO-M8U and ZED-F9R
      • In #133 , we discovered that the NEO-M8U outputs the sensor data in 'sets' of 10 readings, whereas the ZED-F9R outputs them one at a time
      • The ESF RAW message is output-only, it cannot be polled
      • This means that getEsfRawDataInfo and getESFRAW were not correct - they have been deleted in this release
      • The UBX_ESF_RAW_data_t data type now contains an extra field numEsfRawBlocks which indicates how many sensor data blocks were received
      • On the ZED-F9R, numEsfRawBlocks will be 7: 3 * accelerometer, 3 * gyro, 1 * gyro temperature
      • On the NEO-M8U, numEsfRawBlocks will be 70. The data is all timestamped so it is possible to access all the sensor data and know when each sample was taken
      • Two new examples show how to access the ESF RAW data using a callback and from inside the loop
      • Both examples have been tested on both NEO-M8U and ZED-F9R. 400kHz I2C is required. The examples use 230400 baud to allow the Serial Monitor prints to keep up.
    Source code(tar.gz)
    Source code(zip)
  • v2.2.13(Aug 3, 2022)

  • v2.2.12(Jul 29, 2022)

    This release:

    • Adds preliminary support for the UBX-RXM-QZSSL6 correction message from the NEO-D9C - thank you @mazgch #145
    • Adds auto support for UBX-NAV-EOE and UBX-NAV-TIMEUTC - thank you @rislec #144
    • Corrects an error in the way fresh ESF data was requested - thank you @rislec #144
      • This may explain any stale or non-updating data returned by getSensorFusionMeasurement, getRawSensorMeasurement and getSensorFusionStatus
    • Corrects an error in Example20
    Source code(tar.gz)
    Source code(zip)
  • v2.2.11(Jun 29, 2022)

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

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. 74 Nov 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 144 Nov 9, 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 154 Nov 25, 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 236 Nov 12, 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 572 Nov 27, 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 66 Nov 21, 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 131 Nov 22, 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 9 Sep 30, 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 26 Nov 20, 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 281 Nov 24, 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 60 Oct 2, 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
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 491 Sep 15, 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 34 Nov 15, 2022
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.6k Nov 23, 2022