The NMEA decoder silently drops satellites from its GSV-derived satellites events when the receiver uses NMEA 4.10/4.11 system-specific numbering. Observed on a Septentrio mosaic-G5 (firmware 1.1.0) in v4x mode: every BeiDou satellite with PRN >= 33 disappears from the decoded satellites event.
Concrete example. The receiver emits this GSV sentence:
$GBGSV,6,4,22,01,42,107,35,37,42,000,33,08,49,135,45,20,53,307,50,0*76
The GB talker identifies BeiDou, and under NMEA 4.11 the satellite numbers are BeiDou's own PRNs (1-63), so 37 here is BeiDou 37. The receiver reports it as tracked with SNR 33, and its SBF ChannelStatus for the same epoch lists it too. But the decoded satellites event contains only BeiDou C01-C32; C37, C40, C41 and C56 are gone:
SBF ChannelStatus: ... C32 C37 C40 C41 C56
NMEA GSV-derived: ... C32
The problem is that convertSVID (gps/internal/nmea/nmeasats.go) applies the unified numbering table (dfltSVNumbering) unconditionally. That table encodes the legacy NMEA 2.x/3.01 scheme in which all constellations share one number space and IDs 33-64 mean SBAS. For BeiDou PRN 37 it maps the SV to SBAS, then the talker-vs-mapped consistency check (gnssConsistent(BDS, SBAS)) fails and the satellite is discarded. This is the wrong model for a 4.1x receiver: under NMEA 4.10/4.11 each constellation has its own talker ID and its own PRN numbering, so no cross-constellation remap should be applied at all -- the talker already names the constellation and PRN 37 on GB is simply BeiDou 37.
The presence of the signal-ID field in the GSV sentence can indicate which numbering scheme is in use. NMEA 3.01 GSV has no signal-ID field; 4.10/4.11 GSV adds it (the trailing 0 in the example above). When the field is present the sentence uses system-specific numbering, so the unified table should not be applied and the talker's constellation should be trusted with the PRN as-is; when it is absent, the unified table is appropriate. Note that parseGSV currently collapses "field absent" and "field present with value 0" into the same sigID == 0, so the field's presence would need to be tracked separately to be usable as this discriminator.
This affects only the NMEA satellite path. The SBF path, which is authoritative for Septentrio, reports these satellites correctly.
The NMEA decoder silently drops satellites from its GSV-derived satellites events when the receiver uses NMEA 4.10/4.11 system-specific numbering. Observed on a Septentrio mosaic-G5 (firmware 1.1.0) in
v4xmode: every BeiDou satellite with PRN >= 33 disappears from the decoded satellites event.Concrete example. The receiver emits this GSV sentence:
The
GBtalker identifies BeiDou, and under NMEA 4.11 the satellite numbers are BeiDou's own PRNs (1-63), so37here is BeiDou 37. The receiver reports it as tracked with SNR 33, and its SBFChannelStatusfor the same epoch lists it too. But the decoded satellites event contains only BeiDou C01-C32; C37, C40, C41 and C56 are gone:The problem is that
convertSVID(gps/internal/nmea/nmeasats.go) applies the unified numbering table (dfltSVNumbering) unconditionally. That table encodes the legacy NMEA 2.x/3.01 scheme in which all constellations share one number space and IDs 33-64 mean SBAS. For BeiDou PRN 37 it maps the SV to SBAS, then the talker-vs-mapped consistency check (gnssConsistent(BDS, SBAS)) fails and the satellite is discarded. This is the wrong model for a 4.1x receiver: under NMEA 4.10/4.11 each constellation has its own talker ID and its own PRN numbering, so no cross-constellation remap should be applied at all -- the talker already names the constellation and PRN 37 onGBis simply BeiDou 37.The presence of the signal-ID field in the GSV sentence can indicate which numbering scheme is in use. NMEA 3.01 GSV has no signal-ID field; 4.10/4.11 GSV adds it (the trailing
0in the example above). When the field is present the sentence uses system-specific numbering, so the unified table should not be applied and the talker's constellation should be trusted with the PRN as-is; when it is absent, the unified table is appropriate. Note thatparseGSVcurrently collapses "field absent" and "field present with value 0" into the samesigID == 0, so the field's presence would need to be tracked separately to be usable as this discriminator.This affects only the NMEA satellite path. The SBF path, which is authoritative for Septentrio, reports these satellites correctly.