We are having an issue with logging Galileo navigation data on Samsung Galaxy devices. We are logging byte-level data of Galileo I/NAV E1b messages and the returned data doesn’t allign with the Android API documentation.
I’m mainly using a Samsung Galaxy A51 model, but I’ve also tried to use Samsung Galaxy A50 and both produced the same result, which I’ll describe in detail.
We are specifically interested in TYPE_GAL_I GnssNavigationMessages, these are the I/NAV messages of Galileo. The data returned is inconsistent in multiple ways:
1. getData() is returning more bytes than stated
I found is that the getData() field supposedly returns the following:
“For Galileo I/NAV, each page contains 2 page parts, even and odd, with a total of 2x114 = 228 bits, (sync & tail excluded) that should be fit into 29 bytes, with MSB first (skip B229-B232).”
From my understanding this means that the data returned by this function is exactly 29 bytes in length, however for every I/NAV message the data field is 32 bytes. I don’t understand where those extra 3 bytes are coming from.
For example, here’s a message I logged out:
The data field contains 32 bytes instead of the 29 bytes mentioned in the API documentation.
This is a problem is because I’m logging these pages to assemble an E1b sub-frame from these pages. I understand the first 29 bytes but the rest is not mentioned anywhere. All of the messages are like this, I’ll include a log which contains a small set of these messages.
The purpose of these extra bytes are not clear.
2. messageId is out of the specified range
For messageId it says this field should help with assembling the navigation message:
“For Galileo I/NAV nominal frame structure, this refers to the subframe number in the range of 1-24.”
From this quote it seems like the messageId refers to a subframe id in the full frame transmitted on the E1B signal. The full galileo E1B frame consists of 24 subframes and each subframe consists of 15 pages (see page 32: https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo-OS-SIS-ICD.pdf). From my experience this messageId seems to be in the range of 1-30 and after 30 it resets. I’m not sure why this is the case…
An example I logged:
As you can see, the messageId is 30 in this case. I’ve never seen it go above 30 though. Not sure what this means. In a Galileo subframe there are 30 pages (counting even+odd pages separately), but 2 pages are sent with each message. The ID is clearly not in the range though.
3. SubmessageId is inconsistent with given range
For the submessage-ID the documentation states the following:
“For Galileo I/NAV, this refers to the word type in the range 1-10+ For Galileo in particular, the type information embedded within the data bits may be even more useful in interpretation, than the nominal page and word types provided in this field.”
So the Galileo ICD says there are 12 types of words in total in the range of 0-10 and 63 type of page as dummy data. See https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo-OS-SIS-ICD.pdf, section 4.3.5. However, as you have seen in the previous data the submessage-id was 59, the other is 19. The purpose of this ID is not understandable at all because of this… I think it’s a 6-bit value, as the word-type should be, but I don’t understand what all the different submessageIds mean.
I’ve reported this bug to the developer of GPSTest here and I’ve supplied a report to the Android API developers here. Because two different applications and devices produced the same result we suspect it’s not an application level bug, but rather an API or firmware issue.
I hope someone can shed some light on this
Here’s a log I made using GPSTest with these weird Galileo I/NAV messages:
gnss_log_2020_10_12_22_32_53_1537.txt (28.1 KB)