Replies: 6 comments
-
|
Hi Scott, Words and subframes are how the Galileo navigation message is organized. You can read up all the details in the ICD, especially in Section 4.3. A word is basically the smallest unit of information that is sent. Think a packet. One word is sent every 2 seconds. They have a numbers or types, which indicate what kind of data they contain. For instance, these two:
Now, to get all the information, you must collect one word of each type (just because each type holds a different piece of the complete data). So words are organized in a subframe of 15 words (which takes 30 seconds to transmit). These 15 words are essentially (this is not 100% accurate) one of each type, so by receiving the 15 words you get hold of the whole data. The subframe starts like this, and the same structure repeats every 30 seconds (you can just look at the E1B column and ignore the slightly confusing boxes with "Res", "Spare", "CRC", and so on).
For OSNMA, the receiver is supposed to collect some of the words from one subframe (not all the data is authenticated, so only some words play a role in OSNMA), and then check that data against the signature (tags) that is transmitted in the next subframe. The sentence
is actually quite interesting. There are two classes of data authenticated by OSNMA. One is the satellite ephemerides (its orbital parameters). This data is specific per satellite. The other one is the Galileo constellation timing information (the difference between Galileo time, GPS time and UTC, leap seconds, and that stuff). This data is "global" for all the satellites. So you should be able to put together the timing information that you receive from any of the satellites to get a complete copy. Keep in mind that the receiver might have to discard some words due to bad CRC if the signal is not good. So having multiple chances to get the same piece of data helps. Word 6 is one of these constellation timing information words. But what happens in practice is that not all the satellites are sending exactly the same information. They are sending close enough values, but not the same. Maybe some satellites got an updated copy of the data earlier than the others or whatever. Before OSNMA came, this used to be only slightly annoying. In the end it doesn't matter what of the two versions of the information you use, because the values are close enough. However, with OSNMA it does matter, because even if the data is close enough, the cryptographic signatures will be completely different. So what's happening is that galileo-osnma (the Rust library) is seeing this conflicting information and giving a warning. When it sees this, it keeps the first version of the data it received (in that particular subframe). But that version of the data may or may not match the signature (you may see some errors regarding tag authentication for timing parameters because of this). I am not quite sure how receivers are supposed to handle this, but it is quite inconvenient. Regarding env_logger, you're already using it. env_logger is a Rust library that generates the log that you're seeing as output. It lets you control what kind of data you want to see by setting the |
Beta Was this translation helpful? Give feedback.
-
|
Ah, very good. I thought the reference to that utility was beyond what was being displayed... i.e., a completely different tool. Thank you for the clarification! Because there are so many of those "received word ... doesn't match" messages, I have tried to filter them out but with no success. My normal " | grep -v {unwanted string] " syntax is not working, I assume because of how env_logger is outputting the messages that are equal to or above the level requested. By chance could I trouble you for any tips on how to parse this type of output to eliminate unwanted lines? I was not even able to redirect the output to a file ( " > {filename} ), so I am out of the techniques that I normally employ. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
The documentation for env_logger indicates that it outputs to stderr by default, NOT stdout. There may very well be a more simple way, but I accomplished my goal by redirecting the stderr out to a file with:
... and then in a separate window, monitoring that file with:
... which provides cleaner output without all those warnings about "doesn't match word stored for the same subframe" |
Beta Was this translation helpful? Give feedback.
-
|
Indeed the key is that the log output is going to stderr. You can also do it in one go with |
Beta Was this translation helpful? Give feedback.
-
|
I am not surprised that you have a cleaner way to parse the output - thank you! Hopefully these entry-level questions will be helpful to someone later who searches the ISSUE or DISCUSSION sections. I have a Galileo-capable GPS receiver coming, so once that arrives I'll try the next steps in your README. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
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 one can be moved to a discussion. |
Beta Was this translation helpful? Give feedback.
-
After registration & download of the Public Key, I have used the 'nc' method to see the processing myself.
I understand a portion of what is occurring, but could I ask for some clarification, please?
Could you please expand on what is meant by "word", as in "received word 6 from E14 doesn't match word stored for the same subframe"
Also, in this context, what exactly is a "subframe"?
Finally, would this output be more understandable if viewed using env_logger? (if so, command syntax appreciated)
Thank you!
-Scott, K4KDR
[local output used as the basis for my questions:]
Beta Was this translation helpful? Give feedback.
All reactions