-
-
Notifications
You must be signed in to change notification settings - Fork 339
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix the bug that some sensor values are displayed incorrectly #3386
Conversation
I think it is good to go, since Flysky knows best about how to decode their telemetry data. |
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),
|
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). |
@pfeerick I helped to do the following changes:
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. |
I checked PL18 and other references, I think RSNR should be db and not dbm |
@pfeerick Please test again. |
Argh! Just pulled this up to leave feedback and it's changed again! lol |
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? |
Fixes #3196
Summary of changes: