edgetx
edgetx copied to clipboard
EdgeTX
Logs: reset telemetry sensor data to inital state if telemetry is not streaming
After loosing telemetry all sensor values will be frozen at the last valid value. This is nice feature that can be used to retrieve the last known GPS position of a crashed model by e.g. looking at the model settings/telemetry screen. However logging frozen values doesn't make much sense as they give the impression of live recorded data.
This PR clears the sensor data written to the log file to their initial state in case telemetry is not streaming. That makes it easy to spot "no live telemetry" phases in the log file or log charts.
Probably the wrong way tof doing it, since it only addresses telemetry lost and not sensor lost, and many parsers don't like missing columns...
In addition, in case things go really bad, you might want to have a look at any piece of data you have, you might not have valid telemetry indication, but still get bits of data, you probably want those logged
Probably the wrong way tof doing it, since it only addresses telemetry lost and not sensor lost, and many parsers don't like missing columns...
Sensor lost: valid comment, a lost sensor should be cleared while telemetry is streaming
Missing columns: what makes you believe there would be missing columns? There are no missing columns, values just change, e.g. live RxBt 11.2V, after telemetry lost 0,0V, after telemetry recovered 11.2V
In addition, in case things go really bad, you might want to have a look at any piece of data you have, you might not have valid telemetry indication, but still get bits of data, you probably want those logged
The only thing I believe you are talking about might be calculated sensors. All calculated sensors have "live" sensors as input. Multiply or add or any other math on frozen values will only give you a meaningless new frozen value. If I am wrong please provide a plausible example of usable "bits of data" from a period where telemetry is not streaming.
added clearing of sensor data when sensor is lost while telemetry is streaming
A4: sensor lost while telemetry is streaming (A2 remains live), A4 resuming, followed by a telemetry loss (both A2 and A4 are no longer live)
MODEL02-2023-12-03-165134.csv: no empty columns if sensor lost or telemetry not streaming apart from GPS which is the standard unchanged behavior for initial GPS data (0.0, 0.0).
This reminds me that I never pushed changes where we update sensors even if telemetry is not streaming ( So no valid rssi or similar). This comes from a past where there was basically no crc on anything. Nowadays, there is no reason not to update a sensor when a valid packet is received, even if no rssi packet has been received recently for whatever reason
This reminds me that I never pushed changes where we update sensors even if telemetry is not streaming ( So no valid rssi or similar). This comes from a past where there was basically no crc on anything. Nowadays, there is no reason not to update a sensor when a valid packet is received, even if no rssi packet has been received recently for whatever reason
In general you need some sort of "receiver alive" status to determine stuff like receiver connected messages when trying to power down the radio. Currently TELEMETRY_STREAMING() delivers that status and it is entirely up to the protocol to set this to "yes, I think the receiver is alive" or "receiver not alive". Currently all (I think) of the protocols use a some sort of representation of link quality (RSSI, RQly, ...) to decide if they believe the receiver is up and running. Nothing is stopping the protocols to have a more complex logic to use data from arbitrary packets or even just packet counters.
Just an observation while reading the code: (Still have to test it)
if you clear the telemetryItem when loosing telemetry streaming, auto-offset sensors will be re-started. For example, absolute altitude will start computing from the altitude is restore telemetry, not from the ground as intended. Probably similar case with GPS distance from Home.
Just an observation while reading the code: (Still have to test it)
if you clear the telemetryItem when loosing telemetry streaming, auto-offset sensors will be re-started. For example, absolute altitude will start computing from the altitude is restore telemetry, not from the ground as intended. Probably similar case with GPS distance from Home.
Thanks for reanimating this discussion. The way this PR is intended to work is to write cleared data to log files in case of no dead telemetry or lost sensors. No general reset of any telemetry items. So auto offset should not be affected. Please test you use case an let me know.
if you clear the telemetryItem when loosing telemetry streaming, auto-offset sensors will be re-started. For example, absolute altitude will start computing from the altitude is restore telemetry, not from the ground as intended.
I built simu for this PR and tried your use case.
Alt is defined as auto offset sensor and telemetry started with an initial Alt value of 125m, resulting in an auto-offset of 125m and a sensor Alt value of 0m as expected.
Changing Alt to 127m results in an Alt sensor value of 2m as expected
Stopping the telemetry data stream results in a red Alt sensor and the well known "telemetry lost" message. The sensor value is frozen and remains at 2m as expected
Starting the telemetry data stream again (with just for fun assuming Alt has changed to 129m in the meantime) results in a live Alt sensor showing 4m as expected. The auto offset value is still at its initially calculated value of 125m
