Regarding Galileo I/NAV Navigation Message data

[Kovács Levente]

Hello,

I'm using GPSTest to gather Galileo I/NAV navigation messages trying to assemble a Galileo sub-frame. I've read the GnssNavigationMessage documentation for GNSS Nav messages. According to the documentation of getData() on TYPE_GAL_I messages:

"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)"

So it says the data field should contain 29 bytes of data, but when I log out any I/NAV message the data field contains 32 bytes of data. I wonder where those 3 bytes are coming from and what are their purpose.

For example I have this nav message logged out, highlighting the extra bytes:

Nav,Svid,Type,Status,MessageId,Sub-messageId,Data(Bytes)

Nav,  25,1537,0,     24,       59,           -76,-98,-42,123,117,-88,-89,-11,14,-83,-89,-89,0,-128,47,4,-99,-37,-3,-52,113,-39,-120,-128,-111,-94,21,20,0,64,-125,20            (32 Bytes)

Can someone explain what these extra 3 bytes are? Is the difference in the documentation and the logs intentional? Or maybe I'm not reading the right docs? :)

Thanks,
Levente

[Sean Barbeau]

Levente,

That's the correct (and only, to my knowledge) documentation of the Navigation Message data.

What device is this? Have you tried reaching out to the manufacturer to get clarification?

Sean

[Kovács Levente]

Hello Sean,

I'm using a Samsung Galaxy A51. I've checked at this link, to see that this device support the Galileo GNSS.

I haven't reached out to the manufacturer yet, because I got the device as brand new and I've only used it for this purpose. I'm not entirely sure honestly where the problem originates from, I only experience that these navigation messages are not consistent with the documentation. I'll try to log some data with another device.

I posted this issue to the Android issue tracker as well with a more elaborate report.

You suspect that this is due to hardware malfunctioning?

Levente

[Kovács Levente]

Also I tried GNSSLogger as well and it produced the same data format (as far as I know both GPSTest and GNSSLogger uses the same GNSSNavigationMessage). So that's why I suspected that it's not a GPSTest specific issue. Maybe it's an API level bug.

Levente

[Sean Barbeau]

Thanks for the info, good to know (yes, GPSTest and GNSSLogger both get the same data from the underlying Android APIs). I'm guessing it's a software bug in the phone firmware.

Sean

--
You received this message because you are subscribed to the Google Groups "GPSTest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gpstest_andro...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gpstest_android/cce937fa-3914-4c94-8543-a5aad42de26bn%40googlegroups.com.

[Kovács Levente]

So I've tried logging out some data using another Samsung phone, Samsung Galaxy A50 (unfortunately I don't have another model available). The data format is the same, but this doesn't rule out the firmware problem, A50 and A51 may have the same firmware for this. I'm going to contact Samsung as well with this problem.

Someone else has this problem? If you can log Galileo, is your data field containing 29 or 32 bytes?

Levente

[ndo...@gmail.com]

Did you compare the Android Docs to the actual Galileo ICD?  That might help you figure something out?  https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo-OS-SIS-ICD.pdf

Also, separate from your issue, and maybe it doesn't affect what you're trying to do...but are you attempting to use open service E1b/E5a ?  If so, you'll want FNAV for that.  They fold the inter-signal corrections (aka satellite HW group delay) for that signal pairing into the clock correction contained in the FNAV message (Different approach from GPS).  If you read the Galileo docs carefully, they state it there, albeit not as clearly as they likely should have.  They indicate the INAV is also applicable for open service as well, however it's clock corrections contain an ISC for a different signal pairing.

[Lodro Gyamtso]

Into android devices we can found usually, one of the well known SoC from qualcomm, mediatek, hisilicon, exynos. After some search, i haven't found any info that the internal gnss receiver has " navigation messages" ability. Only external chips like broadcom can support this feature. Huawei and Samsung is using broadcom. Not always, but a lot. Has anyone found a list with android model devices of the last 3-5 years support ?

[Kovács Levente]

" Did you compare the Android Docs to the actual Galileo ICD?  That might help you figure something out?"

I did compare the Android docs to the ICD. The data specified in the android docs sort of aligns with the ICD, even though the assembling of sub-frames isn't quite clear for me at this point. The problem is that the data in the logs certainly doesn't match the ICD, neither the API. However, the API docs make sense if we ignore the faulty data.

It provides 2 pages in one I/NAV message and there are 114 bits per page. The full I/NAV page would be 250 bits, 120 (even page)+120 (odd page)+10 (sync bits), the docs state it ignores the sync bit and tail bits (tail bits are six 0 bits at the end of each page). So in full it returns 228 bits of data which makes sense, but I have never received 29 bytes of data and the messageIDs are out of range. Please read the bug report I've made on the API issue tracker for more details.

I'm still interested in whether someone else could verify if the 1537 type message's format is different on other devices (I still could only try logging with the two Samsung Galaxy devices).

" Also, separate from your issue, and maybe it doesn't affect what you're trying to do...but are you attempting to use open service E1b/E5a ? "

No, I'm specifically interested in the I/NAV E5b-I/E1b signal to analyze the OSNMA (Reserved 1 in ICD) in the E1b part of the signal. I'm not sure I understand this folding part, but you mentioned E5a signal which is not familiar to me :)

[Sean Barbeau]

(cross-posting this to this thread too)

I started keeping a manual log of which devices supported various features here:

https://github.com/barbeau/gpstest/blob/master/FAQ.md#what-devices-support-the-various-functionality-shown-in-gpstest

...but it was too manually-intensive to keep up.

Coincidentally I just started working on a new feature that would allow users to upload their device capabilities to the GPSTest Device Database (i.e., a Google Sheet):

https://github.com/barbeau/gpstest/pull/448

Hopefully this will be a more sustainable way to have an open directory of this info.

I plan a device capabilities screen in GPSTest similar to whats in the GNSS Check app as well, hopefully in the near future:

https://github.com/barbeau/gpstest/issues/313

Sean

[ndo...@gmail.com]

Compatibility and interoperability of Galileo and GPS were ensured through cooperation between Europe and the United States on the definition of the Galileo E1 OS and the GPS L1C modulation parameters as well as power levels. The result was the EU-US agreement in 2004 on Galileo E1 and E5 and GPS L1C and L5 signals, respectively. Since then, similar spectrum coordination agreements have taken place with other SATNAV systems. 

The Galileo satellites broadcast coherent navigation signals on three frequencies in L-band: E1, E5, and E6. Galileo provides, in the E1 frequency band centered at 1,575.42 MHz, three signal components, referred to as E1-A, E1-B, and E1-C. The E1-A signal component carries the Galileo PRS. The E1-B and E1-C components form the data and the pilot components, respectively, of the Galileo E1 OS. At a carrier frequency of 1,278.75 MHz, Galileo is emitting its E6 signals that include the signal components E6-A, E6-B, and E6-C. Similar to the E1 frequency band, in E6 the E6-A component refers to the Galileo PRS service. The components E6-B and E6-C are the data and the pilot components, respectively, of the Galileo CS. The Galileo E5 signal centered at 1,191.795 MHz consists of 2 individual signals, the Galileo E5a and the Galileo E5b signal. The E5a data and pilot components are centred at 15.345 MHz below the E5 carrier frequency (1,176.45 MHz - same as GPS L5) and the E5b data and pilot component are centered at 15.345 MHz above the E5 carrier (1,207.14 MHz). Both E5a and E5b can be tracked individually as if they were modulated on separate carrier frequencies in the E5 band. The E5 signal (E5a and E5b) can also be tracked as one signal with a very large receiver bandwidth.  

Note the bold text.  This is the same frequency as GPS L5, and it's highly likely that most/all mobile devices would utilize this frequency, and not E5b, in order to save on receiver RF front end design costs.  If you want to utilize E5a for a dual frequency solution, you must utilize FNAV for the solution.  It's clock corrections have the broadcast group delays integrated into the values, as opposed to GPS where they send the satellite group delays (aka Inter-signal corrections or ISC) separately from the clock correction components.

It sounds like you're doing something else, but you mentioned not knowing what E5a is, so here you go.