plausibility check for telemetry values

[bigtwin]

Is there an existing issue for this feature request?

• [X] I have searched the existing issues

Is your feature request related to a problem?

I'm always frustrated when my post flight telemetry values (Min/Max, Logfile Value range) are messed up by some nonsense telemetry values.

Once in while it happens that the distance or heigh value from my GPS sensor (FrSky) is showing useless values. Instead of a distance, like e.g. 312m, suddenly I have like 12371m or 20629m displayed. Just some strange value which probably occured due to a transmission failure or may some FrSky firmware bug. Those nonsense value makes it into Maximum/Minimum scores and as well into the logs messing up the scale in any diagram. And all happens while the telemetry basically continue to work fine befor and after such a nonsense value. Including GPS distances.

Describe the solution you'd like

In reality it will never happen that a reasonable distance change is more than a couple of 10m among a measurement period. It is supposivly easy to catch those nonsense values based on the last value(s). A height cannot be 1200m while it was 150m before. Same with distance or GPS values. ETX may can check whether a telemetry value makes sense at all (20000m height???) and may even in comparison to the last value(s). If a value is not sensefull, it can simply be dropped and therefor does not pollute logs and statistics.

I am not talking about some sophisticated filtering which may costs plenty processing time. Just stuff like "kick the value if it is 100 times higher than the last one" or "there cannot be a temperature beneath -50°C". This feature can be added/processed prior the already existent "Filter" flag for the telemetry values.

Since someone may dont like that for any reason, it can be configurable. Just like the "Filter" Flag, there can be a check mark like "PlausCheck".

Describe alternatives you've considered

I dont see an alternative. Just live with it (the potential firmware bug). I dont know yet whether this is ACCST only or ACCESS as well.

Additional context

No response

[lshems]

Known issue, perhaps best to be solved with the new status field labelling it as 'unlikely' or something similar.

Personally I would still report the value, but not take it into account for max/min.

[bigtwin]

Ok, I guess this is not anymore of interest for anybody. Closeing.

[pfeerick]

I think it may be more an issue of if "implausible" values come in (and needing to be able to define that for all sensors as what is "implausible" varies from sensor to sensor, and possibly even application to application), that it is a somewhat significant indicator that there is something wrong with the telemetry link or sensor... as there are supposed to be checksums and the like to valid the values coming in already... i.e. EdgeTX is literally just relaying what the telemetry receiver says the value is supposed to be... so implementing this may in fact conceal a bigger problem.