[Announcement] Changes in v3.2

[PaulZC]

February 23rd 2023:

The release_candidate branch includes some major changes which will be released in v3.2. We've been adding support for a new RTK product where: the ZED-F9P is connected via SPI instead of I2C; and the microSD card is connected via 4-bit SDIO instead of SPI. This speeds up reading the GNSS data and writing it to microSD by an order of magnitude.

i2cGNSS has become theGNSS just to indicate that the GNSS could be connected via SPI, not only I2C.

We've added a new File type FileSdFatMMC which supports both SdFile (for SdFat) and File (for SD_MMC) internally. Duplicate methods are provided internally so you can treat FileSdFatMMC as if it were SdFile or File.

The macro USE_SPI_MICROSD is used in many places to indicate if SdFat sd (SPI) or SD_MMC (SDIO) should be used when accessing the microSD. USE_SPI_MICROSD is true if the productVariant defines that SdFat / SPI should be used. false for SD_MMC / SDIO.

There is an equivalent macro for I2C vs SPI GNSS ( USE_I2C_GNSS ) but this is only used rarely as the library handles both more or less seamlessly.

NULL (deprecated) has been replaced with nullptr.

We've migrated to version 3 of the GNSS Library. version 3 configures the module using the configuration interface (VALSET and VALGET), instead of the deprecated UBX-CFG-PRT, UBX-CFG-MSG messages. The RTK firmware already uses the configuration interface almost exclusively, so the code changes are not huge but you will notice that:

• addCfgValset is now a template method which auto-determines the data type:
  • i2cGNSS.addCfgValset16(UBLOX_CFG_RATE_MEAS, 1000) becomes
  • theGNSS.addCfgValset(UBLOX_CFG_RATE_MEAS, 1000) (note that the 16 is no longer required)
• The port input/output configuration methods are different:
  • i2cGNSS.setPortInput(COM_PORT_UART2, COM_TYPE_UBX) becomes
  • theGNSS.setUART2Input(COM_TYPE_RTCM3)
• The library now has built-in methods to read and return the module and firmware info. We no longer need to do that through a derived class.
  • getFirmwareType
  • getFirmwareVersionHigh
  • getFirmwareVersionLow
  • getModuleName

@PaulZC thinks everything is backward-compatible and that he hasn't broken anything, but please comment on this issue if you notice anything strange or broken. Thanks!

[PaulZC]

With standard RTK products, we use the GNSS UART1 port to output messages for parsing and logging etc.. We use the GNSS I2C port for configuration only.

For the new product, the GNSS is connected via SPI, meaning it does not have access to UART1 (or I2C). The messages for parsing / logging will instead be buffered in the GNSS Library's built-in logging buffer.

Over the next few days, you will see new code being added to allow the messages to be read and parsed from the logging buffer as well as UART1. As always, it should all be seamless, backward-compatible and error-free. But please do comment here if you notice anything strange or broken.

[PaulZC]

March 3rd 2023

Pull Request #416 contains the bulk of the changes to support the new Reference Station RTK product. The following is background information to explain some of the changes:

As outlined above, standard RTK products use I2C for module configuration and periodic reading of (e.g.) NAV-PVT and NAV-HPPOSLLH. For any UBX/NMEA/RTCM messages which need to be logged or streamed to Bluetooth, these are output on the u-blox module's UART1 serial port and received by the firmware using the ESP32 UART2 (serialGNSS).

For the Reference Station product, the GNSS is interfaced via SPI. This provides an order of magnitude improvement in the bus speed (4MHz for SPI vs. 400kHz for I2C), but means that I2C and UART1 are not available...

To emulate UART1, we use the logging buffer which is built in to the SparkFun u-blox GNSS v3 library: v3.0.3 (released today). This allows any UBX, NMEA or RTCM message to be stored (logged) in the library's internal buffer. These messages can then be read from the buffer as if they were being read from UART1.

This required some updates to the GNSS library. v3.0.3 offers: RTCM logging (new in this version), better NMEA logging (the data is now checksum-checked before being added to the logging buffer); and more flexible UBX logging (any UBX message can be logged, even those without "Auto" support).

We also use the lock and unlock methods - which were introduced in v3.0.2 of the GNSS library (thank you @mazgch). These prevent the serialGNSS thread from accessing the SPI (or I2C) bus at the same time as (e.g.) setMessages.

As far as the Reference Station RTK firmware is concerned, this means:

• setMessages enables/disables the 73 supported messages on SPI instead of UART1
• For messages like NAV-PVT and NAV-HPPOSLLH (also ESF-STATUS), these will always be enabled on SPI but will only be added to the logging buffer if they are being actively logged.
  • Think of it this way: for standard RTK products, NAV-PVT is output periodically on I2C, and is also output on UART1 if it is selected for logging. For the Reference Station, NAV-PVT is always output periodically on SPI, but is also tagged for logging to the library buffer if the message settings say the message should be logged.

Other changes include:

• @PaulZC has tried to make the code more memory-safe by using snprintf instead of sprintf where possible

[mazgch]

Nice that you also found good use for the look/unlook hooks. Looking forward to the launch of the new hw version.

[nseidle]

v3.2 is released.