Review new Galileo OSNMA ICD

[daniestevez]

A new ICD for Galileo OSNMA has been published recently. This is the Galileo OSNMA SIS ICD for the service phase v1.0. We need to see what are the changes with the previous ICD (which was the one for the test phase) and determine how the changes affect this project.

[N6RFM]

Thanks for the heads up Dani! Will stay tuned for any modifications. Happy New Year! Bob N6RFM

[daniestevez]

I haven't taken a look at the ICD yet, but I've given a try to the quickstart and the same OSNMA_PublicKey_20210920133026.pem key used for the test phase.

galmon-osnma is working correclty with the current signal-in-space and that key. There are the typical conflicts in word 6 from multiple satellites, which sometimes cause MACK validation failures, but other than that, everything seems to be working.

So it seems that there aren't any major changes being applied already to the signal-in-space.

[N6RFM]

Thanks update Dani!

[coelner]

there was an update on 2023-08-03T10:59:52Z and there is a new certificate. to convert this: openssl x509 -in ../OSNMA_PublicKey_20230803105952_newPKID_1.crt -noout -pubkey > /public.key

[daniestevez]

Thanks @coelner. I was taking a quick look at the new pubkey the other day and wonder how to convert it, so you comment saved me some work.

I have now updated the README to include this information and links to the new ICDs.

I still haven't reviewed the ICD v1.0 carefully to see if there are changes with respect to the test phase. They don't make things easy by giving a list of changes, and I have mostly forgotten about all the small details from when I implemented this. At least, taking a glance at the new ICD I've seen a Data Cut-Off Point (COP) field in the MACK header, which I think wasn't there before.

[daniestevez]

They don't make things easy by giving a list of changes

I stand corrected: Annex D in the new ICD has a detailed list of the changes.

[daniestevez]

I have just pushed to the new-icd some work I've been doing this week. This includes a substantial rewrite of the navmessage module to account for the fact that ADKD=4 is now per-satellite instead of for the whole constellation and that now we can use the COP to determine if the data is recent enough to authenticate, instead of having to resort to heuristics involving the IODnav.

This is working quite well in my tests today, and is probably close to a release version. The only problem that I'm finding is when running with the Galmon server data. For a few satellites the INAV word numbers look bogus. I think this is a problem with the Galmon data, because running ubxtool at the same time and on some of the problematic satellites with my own receiver I don't see this problem.

I still need to see what happens with the longan-nano demo, because the fact that ADKD=4 now is per-satellite requires more navigation message storage, so the demo might not have enough SRAM to run.

[daniestevez]

Rergarding the longan-nano demo, it builds and seems to run fine (no crashes), but it often doesn't manage to authenticate any data (but I've seen it authenticate a few satellites sometimes). It is working much worse than the galmon-osnma application with SmallStorage getting the same input data from a single ublox receiver, so some debugging to see what's going wrong will be needed.

[daniestevez]

I have now done some more work, including implementing FLX MACLT slots, which was required for the current MACLT used by the signal-in-space. I've published a new version v0.6.0. Everything seems to be working well now with the current signal-in-space, including the longan-nano demo, so I'm going to close this issue.