Grace period before setting sensor auto offset #3918
Conversation
…etry streaming which gives a grace period of 1s to allow the sensor to settle rather than using the first incoming data which might be 0.
|
@3djc please review |
|
Hmmm did you test it actually working ? I have a feeling it does not change anything, since TELEMETRY_STREAMING will be true when first telem packet is received, hence I think there is actually no grace period here. (And I know I suggested using it, apologies for that). I know of pilots who share sensors between planes, so they might connect sensors even after telem is up, so ideally, who should be counting how long this sensor has been up, ideally without consuming more RAM. Probably can be achieved within the union size |
|
I did, check this out: https://discord.com/channels/839849772864503828/909552654328406056/1138832665164918896 |
|
Very strange, it would mean that the module send rssi only after some time ? What module/protocol did you test with ? |
|
MPM/Graupner HoTT |
|
That must be a very edge case then, combination of MPM and Hott, here is the result of:
on a simple ELRS module
When you get there first, TELEMETRY_STREAMING() is already true (which makes sense because data should not be processed if it isn't) |
|
I wonder because it's exactly 1s |
|
Please try the following with your trace enabled:
what's your trace looking like now? |
|
Exactly what I did (except I waited 22.5s instead of 30s as can been seen in the logs |
|
do you have equipment to try MPM/FrSky X2? |
|
This is ghost in similar conditions
|
|
MPM with FRSKY
|
|
Thx for looking at this. I have to think about it ... |
|
@3djc You were right, ELRS and FrSky are working as expected. My observation is not tied to the MPM in general but is indeed a quirk of the way HoTT telemetry works. The 1s delay until RSSI can be explained. HoTT sends RSSI and LQI. LQI > 0 is used to reset the telemetry streaming timer. The rx calculates LQI as number of decodable packets received over a period of 1s. So for the first second LQI is zero because only after the first second a sampled value is available. The fact that the first two packets contain zero data for RxBt might be also related to some internal filtering. Anyhow, this behavior makes auto offset to use zero values because the real values are two packets too late. The remedy for both quirks is easy. The Graupner HoTT protocol decoder just needs to ignore the first batch of incoming packets, basically to allow LQI and real values to be available for sure. I'm not sure yet if I put in a PR for this (hott.cpp) because no one (besides myself) ever complained about auto offset not working for Graupner HoTT. On the other hand there is no harm in ignoring the x telemetry packets either. |
|
Ignored issues always come back bitting you, usually with a vengeance. Raise a PR to fix it and be done with it :) |
Harmonized setting sensor auto offset with TELEMETRY_STREAMING() which returns true after one second of stable telemetry data. Auto offset will be written for the specific sensor if it is enabled and telemetry streaming is stable and