semuadmin
commented
7 months ago Hi again @jonathanmuller
So - yes - if the decryption is incorrect the entire payload will be junk - there's no middle ground there!
Are you able to ascertain if this issue only affects SPARTN-1X-OCB-GLO messages with 16-bit timetags (timeTagtype = 0), or does it also affect other GNSS types (e.g. OCB-GPS or OCB-GAL) with 16-bit timetags?
Are you able to confirm whether SPARTN-1X-OCB-GLO messages with timeTagtype = 1 (32-bit timetag) are being decrypted correctly?
This is puzzling because, based on the SPARTN sources I've been using (Thingstream PointPerfect MQTT and NTRIP services), all SPARTN-1X-GAD (global area definition) messages have 16-bit timetags (timeTagtype = 0) but these are definitely being decrypted correctly provided I use the correct key and basedate. I can verify this against exemplary output - see for example the gad_plot_map.png illustration. If I deliberately provide an invalid basedate, the GAD output is - as expected - gibberish.
The fact that GAD messags with timeTagtype = 0 are decrypted correctly suggests that the basic IV (Initialisation Vector) and decryption algorithms in pyspartn are working as expected as long as the key and basedate values are correct.
Unfortunately I don't have access to exemplary output for OCB or HPAC messages so it's much more difficult to ascertain whether they are in fact being decoded correctly. There's no explicit encryption validation CRC or hash, for example (understandably, as this is good cryptographic practice). One avenue I can use is to compare them with contemporary output from the Thingstream PointPerfect NTRIP service, which outputs unencrypted SPARTN messages (eaf=0).
Few suggestions just to discount any obvious hiccups (I'm sure you've checked these but just to confirm):
- I'm assuming the
keyyou're using is valid, but it might be worth double checking it hasn't expired. - What are using as the
basedate? If a datetime value, what value are you using and how have you obtained that? - Have you tried using a 32-bit timetag from the same datastream in place of a datetime value as the basedate (pyspartn will accept either) - i.e. the
gnssTimeTagvalue from a contemporaneous message withtimeTagtype= 1 (maybe an HPAC message)? - Have you tried using the spartn_mqtt_client.py or spartn_ntrip_client.py examples to obtain a 'real time' SPARTN data stream, by way of comparison?
In essence, can we discount the possibility that this is simply an issue of incorrect decryption parameters (key and basedate)?
jonathanmuller
Decryption of SPARTN-1X-OCB-GLO doesn't seem to be correct. The output result looks random (not a single field looks correct)
It looks to be related to the ambiguity resolution as SPARTN-1X-OCB-GLO are the only messages with 16 bits GNSS time tag defined in GLONASS epoch (rather than being 32 bits with no ambiguity or defined in GPS epoch)
Ideally a parameter of one of the function in the chain should specify if GPS time needs to be used or GLONASS I'm not sure how to solve it cleanly for now but I'll think about it and try to come with a proposal (or maybe @semuadmin has an idea on how to do that properly)
Code to reproduce :