Use 'nodeRssiPeak' in delta5Node.ino #73
Conversation
There was a problem hiding this comment.
The goal auto calibration is two fold.
- Account for different sensitivities across different VRXs
- Account for different signal strength across different VTXs.
An added bonus is that the current implementation is unaffected by the RSSI values drifting over time as the VRXs heat up and stabilize.
This change seems to remove #2, by always setting the trigger value based on the peak RSSI since powerup or freq change.
Am I understanding this correctly?
I could see an improvement where the trigger value is updated in a particular run based on the run's peak (still reset when auto calibration is set) and pulled up even after the first pass. This would allow recovery from the situation where you get an artificially low trigger on the first pass (the pilot misses the start gate but still sets the trigger).
I don't think I agree with the change as written. It's possible I'm misunderstanding the intent.
|
|
||
| // If in calibration mode, keep raising the trigger value | ||
| if (state.calibrationMode) { | ||
| state.rssiTrigger = max(state.rssiTrigger, state.rssi - settings.calibrationOffset); |
There was a problem hiding this comment.
The intent of auto calibration is to calculate a new trigger value for each new run. Each run may have a different pilot with different vtx output strength.
| @@ -428,7 +435,7 @@ byte i2cHandleRx(byte command) { // The first byte sent by the I2C master is the | |||
| case WRITE_CALIBRATION_MODE: | |||
| if (readAndValidateIoBuffer(WRITE_CALIBRATION_MODE, 1)) { | |||
| state.calibrationMode = ioBufferRead8(); | |||
| state.rssiTrigger = state.rssi - settings.calibrationOffset; | |||
| state.rssiTrigger = state.nodeRssiPeak - settings.calibrationOffset; | |||
There was a problem hiding this comment.
This looks like it assumes that you always want to set the trigger value based on peak RSSI, not the peak of the current quad in the heat.
|
@punkkills My experience with the modules has been that they have a very consistent peak-RSSI level, typically in the 205-215 range. The peak can rise a bit (maybe 5-10) as the box warms up, but the peak-RSSI tracking I've implemented will track that as well. Whenever a quad/VTX (of any power level) is "in the gate" and right next to the timer, the RSSI gets saturated and the module outputs its peak RSSI value. For a given module the saturated peak-RSSI value is the same regardless of VTX power or frequency. The RSSI-trigger value is an offset of the peak, and the more accurately the peak is detected the better. Having a detected RSSI peak be lower that the "real" peak can lead to false gate-pass (trigger) events. I think the key point is that whenever a quad/VTX of any power level is within a foot or two of the timer, the detected RSSI is at that peak value. There are not different peaks for different quad/VTX units being read by the same RX5808 module. --ET |
|
@ethomas997, Interesting that you found that the peak RSSI is always saturated during a pass, no matter the vtx output power. I have not noticed this in my experience, though it is not something I've been looking for specifically. If that's true, I think the pass/calibration loop could be further simplified. I just gave the timer to one of our race directors so I don't have it in hand now. I'll check this out once I get it back. Mind if we keep this one on ice until i can take a look? ed |
|
@punkkills Sure, no problem. I'd say it's not that the peak RSSI is always saturated during a pass (though it often is), but it can be saturated on any given pass. If it can reach that absolute peak saturation value then basing the RSSI-trigger on a lower value will only degrade the accuracy of detection in general. |
ethomas997
force-pushed
the
etAddNodeRssiPeak
branch
from
c39985f to
1506ae4
Compare
|
Rebased to master-20181112 |
Adds a 'nodeRssiPeak' state variable to track the peak smoothed RSSI value seen since the node was powered on or the frequency set, and makes it so the 'rssiTrigger' etc variables are based on this 'nodeRssiPeak'.
This makes is so the "peak" RSSI value can be captured anytime the node is powered on (instead of only after a race is started). If the racers are lined up before the start, the initial-calibration-pass functionality still operates the same way.
I think it's best to use all possible samples to capture the "peak" RSSI value as soon as possible. The more it changes during a race the less reliable the triggers will be.
--ET