brocaar
commented
1 year ago Please note that the default ADR algorithm works only with 125 kHz data-rates, the logic to which you are linking is iterating over the available data-rates in search for the max 125 kHz data-rate. There might be a higher LoRa data-rate and your custom ADR algorithm might be able to deal with that. Adding a MaxLoRaDR field does not solve this issue.
// The max DR might be configured to a non LoRa (125kHz) data-rate.
// As this algorithm works on LoRa (125kHz) data-rates only, we need to
// find the max LoRa (125 kHz) data-rate.
maxDR := req.MaxDR
maxLoRaDR := 0
enabledDRs := band.Band().GetEnabledUplinkDataRates()
for _, i := range enabledDRs {
dr, err := band.Band().GetDataRate(i)
if err != nil {
return resp, err
}
if dr.Modulation == loraband.LoRaModulation && dr.Bandwidth == 125 {
maxLoRaDR = i
}
}
wanssemd
Summary
When implementing an ADR-algorithm plugin similar to the default ADR algorithm, it is necessery to be able to access information about the maxLoRaDR. Currently this is computed inside the default ADR algorithm based on the band configuration. Since this configuration is only available internally, the ADR plugin is not able to compute the value the same way.
What is the use-case?
Implementing an ADR plugin similar to the default ADR algorithm which must be able to use the maxLoRaDR value.
Implementation description
The easiest solution would be to add a MaxLoRaDR field to the ADR HandleRequest struct. This field is then filled with the corresponding value, when the request is generated here. The value may either also be computed at this place or might be computed inside the internal/band.go file. There it may be computed as part of the setup function and stored as a variable which can be requested. It should be fine to do it once at this point instead of computing the value on every ADR Handle call since the band configuration is also only done once at this point.
Can you implement this by yourself and make a pull request?
Yes.