RAIM: GPGBS msg.svid appears to be an array index, not the SV ID?

[S-u-m-u-n]

I am simulating some spoofing experiments where I spoof a single satellite. With more aggressive spoofing, at some point the spoofing is unsuccessful due to RAIM (Receiver Autonomous Integrity Monitoring), which is enabled by default on u-blox receivers and cannot be disabled. This is expected behavior.

I am trying to better understand what exactly RAIM is doing.

Setup:

1. Receiver: u-blox F9P
2. GNSS signals: GPS only
3. RAIM output enabled via CFG_MSGOUT_NMEA_ID_GBS_UART1

I receive GPGBS (NMEA GBS) messages that follow the format documented here.
Everything makes sense, except for the svid field, which is not at all the "ID of most likely failed satellite (1 to 138)", but seems to be an index instead.

Example:

• I am spoofing satellite 19
• RAIM is active, I receive a GPGBS message with the field msg.svid=2, which is not the actual satellite ID 19. The GPS satellite with ID 2 is not even visible, so it's unlikely that this is just an svid for a different satellite
• I also collect RAWX messages, that contain the satellites in this order:
  • 24 19 10 14 15 17 22 13 23 25 12 32 (i.e. svId_01=24, svId_02=19, svId_03=10, ...)
• and satellite 19 is at index 2 in the above array

That's why I think that the GPGBS msg.svid is a one-based index in some internally stored satellite array, not an actual satellite ID. However, if I repeat this experiment, I sometimes get a different index (e.g. 3), and satellite 19 is still filtered out/not used for a position fix. So it seems that it is not the satellite order from the RAWX messages but a different array that is being used.

Questions:

1. Is GPGBS msg.svid really just an array index, not an SV ID?
2. If so, which internal array does it reference?

Perhaps this is unrelated to pyubx2 and I should ask about this in the u-blox forums, but I wanted to hear your thoughts first.

[semuadmin]

Hi @S-u-m-u-n

(note that NMEA data is parsed via pynmeagps, which pyubx2 calls under the covers)

This is probably more a question for the u-blox forums (I had a quick look myself but couldn't see anything relevant to your particular query), but as far as I am aware, the GBS svid field does - as the documentation says - represent:

I simply parse it as a numeric field. I don't actually have any test data where this field is populated. Could you provide some of your NMEA data that I can look into?

[S-u-m-u-n]

Hey @semuadmin, thanks for the quick reply. I'm not exactly sure what format for the NMEA data you are expecting, but I've collected some example raw NMEA messages now. Let me know if a different format/data would be more useful.

Example

• I am aggressively spoofing satellite 19
• I am computing a position fix every 100ms
• According to the GPGGA messages, the first position fix occurs at 08:00:18.40
• According to the GPGBS (RAIM) messages, satellite 26 is the "most likely failed satellite"
• According to the GPGSA messages, satellite 19 is (except for the first few seconds) never used for a position fix, indicating that it was filtered out by RAIM
• According to the GPGSV messages, satellite 26 is not even visible
• If I repeat the exact same experiment without spoofing, RAIM is not active and satellite 19 is used for position fixes

(This example might be a bit of a bad example, because the number 26 from RAIM is a bit high for an index. But something is weird for sure, because there is no satellite 26.)

1. GPGBS

The number 26 stays constant during the entire experiment. In the beginning, RAIM is only sometimes active, but after the first few seconds it is always active:

$GPGBS,080018.31,,,,26,,125.7,8.6,1,1*67
$GPGBS,080018.50,49.9,42.4,67.3,26,,155.5,8.6,1,1*7F <-- RAIM is active at 08:00:18.50, RAIM is not active at 08:00:18.60
$GPGBS,080018.70,54.7,45.8,67.5,26,,155.5,8.6,1,1*72 <-- RAIM is active at 08:00:18.70, ....
$GPGBS,080018.90,54.1,45.3,66.8,26,,155.1,8.6,1,1*79
...
$GPGBS,080121.60,1.0,0.9,1.7,26,,164.8,44.9,1,1*75
$GPGBS,080121.70,1.0,0.9,1.7,26,,165.1,42.9,1,1*7A
$GPGBS,080121.80,1.0,0.9,1.7,26,,165.3,41.0,1,1*7D

2. GPGSA

In the beginning, there are a few messages that sometimes contain the satellite 19, this perfectly corresponds to what we see in GPGBS above. After the first few position fixes, satellite 19 is never used in the position fixes, indicating that is filtered out by RAIM:

$GPGSA,A,3,10,12,13,23,24,17,22,15,19,25,,,1.52,0.83,1.28,1*13 <-- satellite 19 is used
$GPGSA,A,3,12,13,23,24,17,22,15,25,,,,,1.69,1.02,1.34,1*17     <-- satellite 19 is not used - filtered out by RAIM?
$GPGSA,A,3,10,12,13,23,24,17,22,15,19,25,,,1.52,0.83,1.28,1*13 <-- satellite 19 is used
...
$GPGSA,A,3,10,12,13,23,24,17,22,15,25,,,,1.55,0.85,1.29,1*1B <-- satellite 19 is not used - filtered out by RAIM?
$GPGSA,A,3,10,12,13,23,24,17,22,15,25,,,,1.55,0.85,1.29,1*1B <-- satellite 19 is not used - filtered out by RAIM?
$GPGSA,A,3,10,12,13,23,24,17,22,15,25,,,,1.55,0.85,1.29,1*1B <-- satellite 19 is not used - filtered out by RAIM?

3. GPGSV

I think the only interesting thing to see here is that at no point during the experiment there is a satellite 26 visible. Sometimes satellite 16 (which shouldn't be visible) appears, but it seems that it's not used for anything:

$GPGSV,4,1,13,10,18,295,40,12,54,236,46,13,14,153,39,14,00,059,08,1*6D
$GPGSV,4,2,13,15,35,186,43,16,,,11,17,25,047,42,19,43,079,44,1*58
$GPGSV,4,3,13,22,19,057,40,23,13,253,40,24,86,352,48,25,16,241,40,1*6F
$GPGSV,4,4,13,32,09,322,38,1*56

[semuadmin]

Hi @S-u-m-u-n

Definitely one for the u-blox forum - I see you've raised a query already:

https://portal.u-blox.com/s/question/0D5Oj00000wjzjQKAQ/raim-gpgbs-svid-appears-to-be-an-array-index-not-the-sv-id

I'll be monitoring the response as I'm interested to know what's going on here. Sorry I couldn't be more helpful myself.

[S-u-m-u-n]

@semuadmin No worries, it most likely has nothing to do with pyubx2 / pynmeagps.

My plan was to post the forum link here once there is an answer, but now you have already found it.

One question came to my mind regarding the GSA, GSV, POLYS (PUBX,03?) messages being sorted by the svid:
Is this a standard required by NMEA? Because the example here is not sorted.
Is this sorting specific to how pynmeagps parses the messages? Or just something the u-blox receivers do internally?
The UBX equivalent of these messages, e.g. NAV-SAT, NAV-PVT also are sorted by the svid.

---

A completely different idea: maybe the following is a hint to what is going on under the hood. If I keep track of a global array ordered_sats myself, I get the correct svid the majority of the time (unfortunately not always) when indexing this array:

ordered_sats = []

# Main loop
raw, msg = ubr.read()
if msg:
  # UBX-NAV-SAT messages
  if msg.identity == 'NAV-SAT':
    for i in range(msg.numSvs):
      sv_id = getattr(msg, f"svId_{i+1:02d}")
      if sv_id not in ordered_sats:
        ordered_sats.append(sv_id)
  
  # RAIM messages
  if msg.identity == "GPGBS":
    svid = ordered_sats[msg.svid - 1] # Now svid is (more often than not...) the correct svid of the spoofed satellite

[semuadmin]

One question came to my mind regarding the GSA, GSV, POLYS (PUBX,03?) messages being sorted by the svid: Is this a standard required by NMEA? Because the example here is not sorted. Is this sorting specific to how pynmeagps parses the messages? Or just something the u-blox receivers do internally? The UBX equivalent of these messages, e.g. NAV-SAT, NAV-PVT also are sorted by the svid.

AFAIK there is no provision in the NMEA specification that svids be sorted, and - as you're presumably aware - svid numbering can depend on the specific receiver configuration (e.g. for u-blox 9th Gen receivers it can be configured via CFG-NMEA-SVNUMBERING). pynmeagps simply parses the sv data in the order it arrives - no sorting applied.

(Note that in the PyGPSClient GUI application, the SVIDs are sorted for ease of reference and consistency between constellations, but this happens externally to pynmeagps or pyubx2)