Incorporate GNSS receiver with PPK/PPP capabilities

[brian-r-calder]

Although the original intent for WIBL loggers was to provide the lowest cost, minimal functionality logger for volunteer bathymetric data that we could find, we've ... umm ... gone a little further than that now.

This proposal is to allow the WIBL logger to be used in two modes: as a minimal functionality logger built at lowest possible cost; and as a GNSS-enabled logger that can provide reasonable positioning in real time, and save enough raw information to allow for post-processed positioning sufficient to provide centimetric uncertainty. The goal is to have a uniform hardware platform that supports both options, and to set up either functionality through a combination of BOM manipulation (for the hardware) and firmware management. Post-processed centimetric positioning allows for Trusted Community Bathymetry (Calder et al., 2020) processing, auto-calibration, empirical uncertainty estimation, and other downstream behaviours (e.g., cross-calibrating "standard" WIBL loggers for vertical corrections).

The requirements for this include (among others, probably):

• Modifications to the schematic and PCB to allow for optional addition of a U-Blox ZED-F9P (or other) GNSS module.
• Interface of the GNSS module to the ESP32 using the I2C interfaces (best mix of speed and available interfaces). This should include a line from the time signal output to an unused pin on the ESP32 to allow for 1PPS interrupts.
• Two BOMs to allow for the different modes.
• A firmware logger element to talk to the GNSS module (using the SparkFun interface library.
• Modification of the logger's serialiser module to provide a message to encapsulate GNSS raw observations for post-processing.
• Addition of a time synchronisation module to the firmware based on the 1PPS configured from the GNSS receiver.
• Modification of WIBL processing code to allow a binary file of the raw GNSS observations to be reassembled on read for post-processing (e.g., though RTKLib).
• Modification of the WIBL python code to support the raw GNSS observations records.
• Modification of the WIBL processing code to use GNSS time and position information from the post-processed observations if available.
• Modification of the WIBL processing code to use real-time GNSS time and position for processing if available (they're likely better than anything else we're going to get!)

This would form at least a minor version step for both hardware and firmware.