GPS number of sats

[f2knpw]

• radio : TX16s
• receiver FS-IA6B
• protocol IBUS

Just using a Ublox M8N GPS, when discovering the telemetry on my EdgeTx TX16S radio I do get abnormal number of sats

It seems that, when no fix, the number of sats is Ok (below 8 sats). Then they immediately climb above 100 and stay there and fix seems to be consistant (more or less) with this (when above 106 or 108 fix is got) 109, 110, ... etc

We discussed this on EdgeTX github :

But Mickael seems to say that it can't be the "fix": //(AC FRAME)[ID][inst][size][fix][sats][LAT]x4[LON]x4[ALT]x4 not according to this. fix is one byte and sats is one byte. fix is not transferred as telemetry sensor. fix usually has more values representing no fix, 2D fix, 3D fix, assisted fix.

can be seen everywhere (logs, screens, etc..)

It's of course not a critical bug !

[mstrens]

It is not a bug. Some people asked to add 100 to the number of sat when there is a 3D fix. It is a way of combining 2 data's into one field (some protocols are quite limited in the type/number of fields that can be transmitted)

[f2knpw]

Great !

So I was right to assume it was a fix flag !

Thanks

[mha1]

According to Betaflight (and EdgeTX) implementation there are two separate bytes transferred. One byte fix type, one byte number of satellites. Why don't you populate the fixType byte and mix it into number of satellites? I mean it works but you chose a proprietary and incompatible solution.

GPS frame definition:

IBus GPS frame definition:
typedef struct {
  uint8_t ID; 
  uint8_t size;
  uint8_t fixType;
  uint8_t sats;
  int32_t lat;
  int32_t lon;
  int32_t alt;
} IBus_GSP_frame_t;

Betaflight

            case IBUS_SENSOR_TYPE_GPS_STATUS:
                value->byte[0] = gpsFixType;
                value->byte[1] = sats;
                break;