SUCCESS & a question ref. possible 4rth Test Scenario

[K4KDR]

I am beyond thrilled to report success with using live Galileo data (via locally connected USB dongle) as the source for evaluation by your app running on the local PC!

... and that prompted me to wonder if a 4rth testing scenario was possible. Your documentation and very welcome help on other ISSUES posted here allowed me to finally get the longan-nano to properly process INAV and OSNMA data via the serial port client.

I wondered if it might be possible to utilize live data from the USB device in place of the web stream to feed the longan-nano data.

I believe that I might have been successful (see images below) but I do not fully understand the result. In the second image below, the output deviates and I'm not sure if that is just a line-wrap error or if an OSNMA authentication has been achieved. Naturally the full PC app is more verbose. Would you be kind enough when time permits to explain in just a bit more detail what the longan-nano is telling us as it receives the live data stream? Many thanks in advance!

[daniestevez]

It's working.

The output you've marked in red means that it's managed to authenticate the ephemeris data for E08 and E13 at that point. Interestingly, it hasn't managed to authenticate the constellation timing parameters yet (that's what ADKD=4 stands for). Perhaps it will manage later on (you would see AUTH ADKD=4 TOW xxxx).

The reason why the AUTH ADKD=0 E08 TOW 7860 E13 TOW 7860 line disappears quickly, returning to AUTH ADKD=0 NONE is because the SRAM of the Longan nano is not particularly large, so it has barely enough storage space to process the authentication data. Once the next subframe starts (at TOW 7951), the old navigation data (which just has been authenticated) needs to be discarded to make room for the data in the new subframe.

That's why the authenticated data disappears so quickly. What the output is doing is, at each moment, printing what is the latest authenticated data it has (or NONE if there is NONE). Since the authenticated data is so short lived, we see NONE most of the time. It might be possible to play with the definition of the storage size to try to make the authenticated data live longer, but one needs to be careful, because if the program runs out of SRAM, it crashes.

If everything is going well, if you search through the output you would see successful authentication for ADKD=4 as well as for other satellites besides E08 and E13.

[K4KDR]

After upgrading to commit 599804e, I rebuilt all the applications including the firmware for the Longan-nano.

Using 'live' GNSS data via the serial client, I allowed the collection to run for a while. Unlike my initial report which only contained a single authenticated ephemeris data packet, you can see below that I happened to catch a string of multiple packets that were authenticated - both ephemeris data AND constellation timing parameters. So, I was very pleased with that result and wanted to share it for reference on this thread.

[daniestevez]

Nice! Now I see a bug that I've introduced in that commit. The AUTH ADKD=0 line says EE15 rather than E15. I will fix this.

[daniestevez]

I'm trying to clean up the issues by closing what is already solved and moving to a discussion what has background information that could be interesting to others. I think this is best transferred to a discussion, since it has some information about how to read the output from osnma-longan-nano that others may find useful.