Improved vario refresh rate

[olivierrieux]

Hello,

Thanks again for this nice firmware.

I understand that vario sound is computed and generated in "CheckCustomAlarms()", with a rather low periodicity (approximately every second), while the altitude screen display is updated with a significantly higher refresh rate in "acData()", (equal to the Rx refresh rate?) (both functions are in source/source/alt.c). In other words, I have the impression that the vario function only uses 1 altitude samples out of n (I was not able to see upon which event those functions or called, to confirm the theory).

I have the feeling that the vario could be improved by using all altitude samples from the Rx, without decimation. One obvious benefit could be a reduced latency. Also, some filtering could be added in order to improve accuracy (filtering definition is a trade off between accuracy and bandwidth/latency). The sound refresh rate does not necessarily have to match the altitude samples rate although it would simplify implementation.

Do you think it's possible?
What would be the best way to implement this?

Thanks a lot.
Best regards.

[Yenya]

@olivierrieux - I can definitely try to increase the refresh rate. As for averaging the measurements received between the beeps - no, I don't think it would lower the latency. Pressure sensors/varios usually average many thousands of samples for every measurement sent, and I am pretty sure the latest measurement is what you want the next beep to be based on. After all, the beep of the receiver reflects the difference since the last beep, so in my humble opinion you need the difference between the previous beep and the very last sample you can get, not the average through that time.

Another problem with averaging inside the Rx would be that we have virtually no program space left for adding more complicated code. But I still believe that averaging since the last beep is fundamentally not what you want.

After all, further filtering can be done in the vario itself. At least if you have a programmable one such as my own based on BMP-280 and Arduino. https://github.com/Yenya/ibus-altitude-sensor

I might be completely wrong here, but I tried both weighted average and "just use the last sample" approach, and settled for the later one.

[olivierrieux]

Hello
Thanks for your so quick answer. I can see you already thought intensively about the topic

I can definitely try to increase the refresh rate.

I would like it :-)

As for averaging the measurements received between the beeps - no, I don't think it would lower the latency

I agree, filtering would increase the latency.

Pressure sensors/varios usually average many thousands of samples for every measurement sent, and I am pretty sure the latest measurement is what you want the next beep to be based on.

I use the fs-cat01 (associated with an fs-ia6b Rx that transmits the data to my tgy-i6), I have no clue what it actually does but I assume it is quite simple in terms of signal processing.
Since the altitude information the tgy-i6 displays has quite some noise, I assume that some filtering would improve the accuracy. And provided that the filtering horizon is in the same order of magnitude as the time between consecutive beeps (as you consider), the total latency from the telemetry data to my ears would not increase to much.

[olivierrieux]

As for filtering, I was thinking of a recursive filter like:
y[n]=.2x[n]+.8y[n-1]
Where x is the raw telemetry data, y the filtered data, n the present, and n-1 the previous sample time

[olivierrieux]

The coefficient 0.2 (0.8 is just 1-0.2) is only an example and has to be chosen according to the sampling period and the acceptable latency. If i am not mistaken, this is a first order lowpass filter with a time constant of 5 sampling periods.

[olivierrieux]

I might be completely wrong here, but I tried both weighted average and "just use the last sample" approach, and settled for the later one.

Have you implemented the average in your Arduino or in the fs-i6 flyplus? If in flyplus, i would be happy to test it in my fs-cat01-based configuration (assuming that you still have the uploadable image or the source ready to compile).
In any case, thank you for all your work and for taking the time for this discussion.

[Yenya]

Looking at the code:

https://github.com/Yenya/ibus-altitude-sensor/blob/master/ibus-sensor.c#L370

Some sensors, such as BMP280, can do hundreds or thousands of measurements in a few miliseconds, and then return the average. In order to provide the best possible latency (even though it is traded off for slightly higher noise), I return only the latest value for such sensors. For BMP085, though, I use a similar low-pass filter as you propose, just without the floating-point arithmetics:

value -= value >> 5;
value += measurement;

https://github.com/Yenya/ibus-altitude-sensor/blob/master/ibus-sensor.c#L433

It is essentially similar to your

value = 0.2*measurement + 0.8*value;

Another problem is that the sensor never knows when exactly the Rx (ibus master) asks for a measurement, so it has to measure all the time (I sleep for 50 ms after each measurement loop; my hardware can serve also as a battery voltage sensor).