Trigger on peak RSSI

[kestux75]

Trigger on peak RSSI #64

[voroshkov]

Unfortunately this approach won't improve anything as it's too straightforward. The RSSI values are read once per 0.1ms and can vary sensibly (around 2-3 for subsequent reads).
So you might get a value above the threshold and right after that - the value lower than the previously read one. So it will earn you just 0.1ms and won't find a peak at all. Try experimenting.

[kestux75]

Thank you for feedback. I tried to improve. Will test further

[kestux75]

I have made some changes to peak detection algorithm. Tested, and looks like it's works quite good. Andrey could you take a look at it?

[voroshkov]

Thanks for your effort. The code seems ok, but I'm not sure it's really needed. If it behaves the same both with this fix and without it, then I'd avoid unnecessary code complication.
Thank you anyway!

[StarrrLiteNL]

Triggering on peak RSSI should give much improved tracking accuracy,
Example: the first round you pass the gate at the far end away from the tracker, the next lap you fly very close tho the tracker. With threshold measuring, the first lap will be measured a little late, while the second will be measured early because the threshold will be passed earlier as the quad passes closer to the tracker.

When measuring via peak detection, both laps will be be counted equally , as the peak will be at the same moment, albeit a little higher or lower.
Measuring via peak detection will also make setting the exact correct threshold value easier as it needs to be a little less precise.

This might make 'only' 10-100ms difference, but in droneracing 100ms is a LOT.
There is a reason all the other trackers use measuring by peak instead of threshold ;)

[voroshkov]

@StarrrLiteNL I somewhat agree, but have you seen the RSSI signal in real time? Believe me, there's no clean peak or nice smooth transition from low to high when approaching the timer.

The suggested approach might improve things a bit, but also might make them a bit worse. But most likely it won't change anything significantly. So I'd avoid making changes to the detection algorithm until they are proved to benefit the accuracy.

As for other timers, don't they really use a threshold? Then how would they detect false peaks if a drone flies on some distance from the timer?

[kestux75]

I'm used modified chorus firmware with peak detection, for about half year. It works good, at lest not worse than standard :) I'm not sure if it makes big improvement comparing standard firmware. Still need to be tweaked. I'm not sure if ~3ms is enough to detect peak. Possible that SLOPE_DETECTION_ITERATIONS should be increased.
I will experiment more next year :)

[StarrrLiteNL]

@voroshkov , they threshold and peak. Once a channel passes the threshold, it will keep measuring untill it falls below it , and then takes the peak value for time measurement.
The RSSI values should resemble something of a curve, perhaps some smoothing/filtering of the raw RSSI values could help with that?

[voroshkov]

@StarrrLiteNL, exactly!

[voroshkov]

Don't get me wrong, I agree with the idea, but need good implementation for it, which will maintain balance between instant tracking and accuracy.
I value the speed of lap reporting and won't like to have a seconds delay between actual passing the finish gate and a "beep" indicating the event.