Support Ublox NTRIP Client (No MQTT) SPARTN format

[jptalledo10]

PyGPSClient Feature Request Template

Ublox/Thingstream released a new service based on NTRIP/IP and providing SPARTN format corrections without any MQTT dependencies.

Wondering if this application can add this feature and provide a server for it to connect and retrieve those corrections

[semuadmin]

Hi @jptalledo10 ,

PyGPSClient can already parse (but not yet fully decode) SPARTN data from MQTT and L-Band sources, so in theory there should be no major difficulty in parsing SPARTN data from an NTRIP (i.e. HTTP) source.

The main issue is that, while the SPARTN protocol is ostensibly in the public domain, the documentation is (in my experience) relatively poor and u-blox's SPARTN services all require a paid subscription in order to decrypt the raw data, making it extremely difficult for an unpaid and unsponsored volunteer project like PyGPSClient to develop, test and implement it successfully. SPARTN is basically a money-spinner for u-blox.

The NTRIP RTCM3 protocol, on the other hand, is well documented, unencrypted and a great many NTRIP sources are available free of charge from public domain service providers like rtk2go.com and euref-ip.com.

u-blox have shown little interest in supporting open source projects like PyGPSClient and certainly no interest in assisting with subscription fees or testing, so at this point I don't feel greatly motivated to implement new SPARTN functionality in support of u-blox's revenue stream.

As things stand, the pyspartn library (which PyGPSClient uses to parse, decrypt and decode SPARTN data) is currently still in Alpha and cannot yet fully decode all SPARTN payloads. I suspect the outstanding issues are probably easily resolved (they're almost certainly a document interpretation problem rather than a decryption problem), but I've simply not had the time or frankly the incentive to look into them in any depth.

Having said this, contributions of all kinds are always welcome so if anyone out there is in a position to assist with the implementation of such functionality, I'd be more than happy to incorporate it.

[jptalledo10]

The good news is that Ntrip Spartn is not encrypted and I can share a developer account for debugging/testing if needed. Happy to discuss further.

[semuadmin]

The good news is that Ntrip Spartn is not encrypted and I can share a developer account for debugging/testing if needed. Happy to discuss further.

That would certainly be helpful - appreciate the offer. In point of fact, you don't actually need to decrypt SPARTN data in order to send it to an RTK-compatible GNSS receiver like the ZED-F9P - you can simply send the raw binary datastream along with the relevant decription keys and the receiver will happily decrypt it itself. Native SPARTN decryption in pyspartn is provided more as a diagnostic and academic service to end users.

I've been reviewing the PointPerfect service description at https://developer.thingstream.io/guides/location-services/pointperfect-ntrip-distribution and it all looks relatively straightforward, particularly as it appears to support the standard NTRIP HTTP port 2101 in addition to an encrypted HTTPS (TLS) service on port 443.

Supporting the service would require the following changes:

1. (necessary) Enhancements to the pygnssutils library - specifically the gnssntripclient class. It should be a simple matter to add a flag to signify either RTCM3 or SPARTN protocol, and then assign either pyrtcm.RTCMReader or pyspartn.SPARTNReader to parse the data into individual RTCMMessage or SPARTNMessage objects and forward the serialised objects to the receiver.
2. (optional) For HTTPS support, I may also need to add a parameter which points to the location of the necessary PointPerfect TLS certificates, assuming these are not already supported natively by the Python certifi library via its default cacerts.pem TLS certificate registry.
3. (optional) enhancements to the pyspartn library to fix the remaining SPARTN decode issues - something that's been on my backlog for a while anyway. Having access to a developer account would certainly facilitate this.

I'm moving this issue to the PyGPSClient Ideas and Feature Requests Discussion Forum where we can continue the discussion, if that's OK with you.

Thanks again for the suggestion and any assistance you can offer.