Closed PaulZC closed 1 year ago
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.
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 UART1Other changes include:
snprintf
instead of sprintf
where possibleNice that you also found good use for the look/unlook hooks. Looking forward to the launch of the new hw version.
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 becometheGNSS
just to indicate that the GNSS could be connected via SPI, not only I2C.We've added a new File type
FileSdFatMMC
which supports bothSdFile
(forSdFat
) andFile
(forSD_MMC
) internally. Duplicate methods are provided internally so you can treatFileSdFatMMC
as if it wereSdFile
orFile
.The macro
USE_SPI_MICROSD
is used in many places to indicate ifSdFat sd
(SPI) orSD_MMC
(SDIO) should be used when accessing the microSD.USE_SPI_MICROSD
istrue
if theproductVariant
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 withnullptr
.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)
becomestheGNSS.addCfgValset(UBLOX_CFG_RATE_MEAS, 1000)
(note that the16
is no longer required)i2cGNSS.setPortInput(COM_PORT_UART2, COM_TYPE_UBX)
becomestheGNSS.setUART2Input(COM_TYPE_RTCM3)
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!