Fix different constellation timebase resolution by trying 12h prior, during, and after given basedate

[jonathanmuller]

pyspartn Pull Request Template

Description

Different constellations are using different time reference : GPS = GAL = QZSS = UTC -18s BEI = UTC -14 GLO = UTC + 3h (exactly 3h, 0 seconds)

Because of that, passing a basedate to convert a 16 bits timetag to 32 bits unambiguous can be either

• Correct
• Wrong because basedate is ahead of the constellation (GPS for example)
• Wrong because the basedate is behind the constellation (GLONASS for example)

In order to account for those time difference not being in sync, 3 unambitious solutions are calculated :

• At the time of basedate
• 12h after basedate
• 12h prior to basedate The closest in time is the one returned

By doing so, basedate can be up to 3h inaccurate (as GLONASS is +3h ahead) and still allow for a correct parsing

Fixes #17

Testing

Please test all changes, however trivial, against the supplied pytest suite tests/test_*.py. Please describe any test cases you have amended or added to this suite to maintain >= 85% code coverage.

• [x] Timetag unambiguity test (testtimetag) extended to test GLONASS ambiguity at the critical time where it would prior fail

Checklist:

• [x] I agree to abide by the code of conduct (see CODE_OF_CONDUCT.md).
• [x] My code follows the style guidelines of this project (see CONTRIBUTING.MD).
• [x] I have performed a self-review of my own code.
• [x] (if appropriate) I have cited my public domain SPARTN documentation source(s).
• [x] I have commented my code, particularly in hard-to-understand areas.
• [x] I have made corresponding changes to the documentation.
• [x] (if appropriate) I have added test cases to the tests/test_*.py pytest suite to maintain >= 85% code coverage.
• [x] I have tested my code against the full tests/test_*.py unittest suite.
• [x] My changes generate no new warnings.
• [x] Any dependent changes have been merged and published in downstream modules.
• [x] I have signed my commits.
• [x] I understand and acknowledge that the code will be published under a BSD 3-Clause license.

[semuadmin]

Thanks for this. I'm probably being a bit slow here but I'm not entirely clear what specific scenario this fixes (over and above the UTC/leap second adjustments already made in v0.3.2-beta via TIMETAGSHIFT)?

Can you give an explicit example of a datastream decryption that would fail with the current code but succeed with this PR? Ideally I'd like to see a further test in test_stream.py which exercises this specific scenario.

FYI the next release (RC 0.3.3-beta) will use datetime.now(UTC) rather than datetime.now() as the default, but that obviously only makes an hours difference.

[semuadmin]

@jonathanmuller @JonathanMullerGeosatis

I've added a couple of test cases to confirm that these changes do cater for "half-day rollover" scenarios. Your changes will go into https://github.com/semuconsulting/pyspartn/pull/22, hopefully in the next week or so. Thanks again for the contribution.

[jonathanmuller]

Sure, let me give you more details :

First, the intend of this PR has less to do with stream decryption than with single message decryption, which is the main feature I'm using, that's probably why it makes less (bit not none) sense in a stream context.

Currently, the following message fail to be parsed using the parse function :

>>> msg =bytes.fromhex("73000d6d1126705c17483be529d9707b585195e21e5e4bfc3aeeda1e56c11f3d196dcfeed54110")
>>> SPARTNReader.parse(msg, decode=True, key="930d847b779b126863c8b3b2766ae7cc", basedate=datetime.datetime(2024, 4, 25, 11, 37, 0))
...
pyspartn.exceptions.SPARTNMessageError: Attribute size 1 exceeds remaining payload length 0

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jonathan/Desktop/cloud_locate/custom/pyspartn/src/pyspartn/spartnreader.py", line 293, in parse
    return SPARTNMessage(
           ^^^^^^^^^^^^^^
  File "/home/jonathan/Desktop/cloud_locate/custom/pyspartn/src/pyspartn/spartnmessage.py", line 102, in __init__
    self._do_attributes()
  File "/home/jonathan/Desktop/cloud_locate/custom/pyspartn/src/pyspartn/spartnmessage.py", line 197, in _do_attributes
    raise SPARTNTypeError(
pyspartn.exceptions.SPARTNTypeError: Error processing attribute 'groupSat' in message type SPARTN-1X-OCB-GLO

However, the basedate it correct (and provided as UTC+0 timezone)

Nevertheless, in a stream context, here are a scenario that would fail without this PR :

• If the stream starts with ambiguous messages, and the provided basedate is around 12AM or 12 PM, GLO-OCB won't be parsed correctly
• If the stream contains message prior AND after the 12AM or 12PM time, the first messages of each type will be parsed incorrectly. For example : Unambiguous GPS at 11:59:59 -> basedate is set to 11:59:59 Ambiguous GPS at 12:00:01 -> basedate used is 11:59:59 -> rounded to 00:00 by the convert_timetag function -> won't parse

I could not record such a stream because it needs such a precise timming, but I'll see what I can do to have a tets case that covers it

EDIT : @semuadmin I was so slow to type this comment that you had time to comment in between, so I was obviously responding to your earlier comment