Taisync Logging to Drone

Info on what you can expect in vehicle logs for radio and how data is formatted

In the new IGC version, we make it so that IGC sends the RADIO_STATUS MAVLink message to the drone so that radio info propagates to logs.

Having the RADIO_STATUS coming from GCS to drone is not standard and not the best way to do it. It would have been better for this message to happen onboard the drone, like through the VOXL2. But the VOXL2 is not connected to the flight controller via UART on the IF800. Because of us sending it from the GCS rather than onboard, If the radio has connectivity issues, it's possible for the autopilot to not receive radio data and vehicle logs won't show either when the radio disconnects or when the connectivity is so bad that RADIO_STATUS fails to be received.

Currently, we hardcode RADIO_STATUS to be sent to drone at 2hz which should be fine for most cases. We can make this configurable in the future if needed.

RAD fields in ArduPilot logs:

1. RSSI

This is the RSSI of the GCS.

There's no way to provide this as a negative value, so it's the absolute value of the RSSI rather than the actual RSSI. e.g -40 RSSI would be 40 in this log. So, higher number = worse RSSI.

1. RemRSSI

This is the RSSI of the drone.

There's no way to provide this as a negative value, so it's the absolute value of the RSSI rather than the actual RSSI. e.g -40 RSSI would be 40 in this log. So, higher number = worse RSSI.

3. TxBuf

The Taisync does not provide TxBuf, so we instead send the groundLinkQuality percentage here

1. Noise

This is the GCS radio noise. It is calculated by

Noise = RSSI - gcs SNR

Noise should be negative, but there's no way to provide this as a negative value, so it's the absolute value of noise rather than actual noise. e.g -80 noise would be 80 in this log Higher number = lower noise

1. RemNoise

This is the drone radio noise. It is calculated by

Noise = RemRSSI - drone SNR 6. RxErrors

This is the number of error packets from ground GCS (groundLdpcFail)

This is a unsigned 16 bit integer value, so if it goes above 65,535, it will overflow back to 0. This shouldn't happen with RxErrors unless you have a REALLY crappy link, and you'll see it overflow in logs.

1. Fixed

This is the number of successful packets from ground GCS (groundLdpcPass)

This is sent through MAVLink as a unsigned 16 bit integer value, so if it goes above 65,535, it will overflow back to 0. In normal cases, you will see it overflow back to 0 continually. This is expected. This just has an affect on what the log looks like. Picture of what that looks like: