Fix the bug that some sensor values are displayed incorrectly

[Xy2019]

Fixes #3196

Summary of changes:

[richardclli]

I think it is good to go, since Flysky knows best about how to decode their telemetry data.

Changes were made

[pfeerick]

I think this is mostly good to go, but can you just check a couple of final details first though. For each radio and when changing firmware I did sensor rediscovery so not have issue with changes to sensor IDs or handling, etc. I'm not so concerned with the MPM changes as that is suggestive there is probably something wrong in that handling, but at the same time this PR is breaking stuff there.

For AFHDS3 (with a FTr12B, FS-CAT01 and FS-CVT01), on the EL18 (ignore the names being repeated on the right side, that is a bug has been fixed), I get the following, where Tmp1 is an invalid value.

Regarding table of telemetry issues in #3196, should RNse unit be dBm or dB?

For my own reference, is % a valid unit for RQly?

For AFHDS2A (with a FS-iA6B, FS-CAT01 and FS-CVT01),

• on the NV14, I get the following, with A1 present and correct unit, Alt is completely wrong, and Pres seems to be the correct value
  

• and finally, on the TX16S and MPM, I get the following (ignore the highlighting of TRSS) - A1 is missing and there is a now 0100 sensor , perhaps with wrong unit since it was 5.20V when A1 was present? Tmp2 is completely wrong (is that even supposed to be here - it was there before this PR and seemed to be a valid value for ambient temperature), Pres is completely wrong, Alt is negative.
  
  

[Xy2019]

1.The temperature error of the FS-CAT01 sensor is too large (or completely wrong), and the data analysis of TX is no problem (if possible, we will not let the temperature value be displayed).
2.The unit of RNse (Noise) is dBm, the same as RSSI.This is my mistake:worried:.
3.The signal quality range of RQly is 0-100, which is a value converted by RSSI. We hope that the unit of RQly is UNIT_RAW.

[richardclli]

@pfeerick I helped to do the following changes:

1. RQly use %
2. RNSe use dbm
3. 0100 problem solved

Alt problem seems scaling problem, maybe the sensors used in AFHDS3 and AFHDS2 receivers should use different scaling, however, not sure if this can be done with a common telemetry coding. I asked Flysky to check again.

Please see if there are anything else.

[richardclli]

I checked PL18 and other references, I think RSNR should be db and not dbm

[richardclli]

@pfeerick Please test again.

[pfeerick]

Argh! Just pulled this up to leave feedback and it's changed again! lol

[pfeerick]

Ok, with latest state of this PR:

On the NV14, RQly seems to be following RSNR value, and so is wrong.

On the EL18, Tmp1 was around -15.0C, when the actual ambient temperature is around 24C, so I don't think the 40C temperature offset applies to AFHDS3. Can you validate and commit this if it works fine for you? It has put my temperature reading back into acceptable range (i.e. one thermometer says it's 24.3C and the transmitter is saying 26.3C now).

diff --git a/radio/src/telemetry/flysky_ibus.cpp b/radio/src/telemetry/flysky_ibus.cpp
index 3b8c7e199..8176f3406 100644
--- a/radio/src/telemetry/flysky_ibus.cpp
+++ b/radio/src/telemetry/flysky_ibus.cpp
@@ -280,8 +280,7 @@ void processFlySkyAFHDS3Sensor(const uint8_t * packet, uint8_t len )
   {
     if (sensor->type != type) continue;
 
-    if (sensor->unit == UNIT_CELSIUS) value -= 400; // Temperature sensors have 40 degree offset
-    else if (sensor->unit == UNIT_VOLTS) value = (int16_t) value; // Voltage types are unsigned 16bit integers
+    if (sensor->unit == UNIT_VOLTS) value = (int16_t) value; // Voltage types are unsigned 16bit integers
 
     setFlyskyTelemetryValue(type, id, value, sensor->unit, sensor->precision);
     return;

On the TX16S /w MPM, Pres is wrong, Alt is wrong, Tmp1 is reported as Tmp2 and is wrong. Other telemetry seems fine though. I'm on the fence as to how important this is atm, as it can be flagged as a known issue and work in progress with flysky - i.e. stick with an earlier 2.8.x build if using MPM with AFHDS2A.

I am curious about Alt(itude) generally though. I'm pretty sure the previous behaviour was coded so that it would be relative to takeoff, i.e. 0 and then go up or down. whereas now for me it starts off at about 48m and goes up in 0.5m increments. Is it supposed to be an approximation relative to sea level or something?