LoRaWAN: calibrates before every transmission

[tve]

When using an sx1262 every transmission and reception using LoRaWAN performs a radio calibration, which takes 3.5ms and uses quite some power. Is this intentional and desired? The reason this happens is that setFrequency is called and in the sx1262 driver that defaults the calibrate parameter to true https://github.com/jgromes/RadioLib/blob/master/src/modules/SX126x/SX1262.cpp#L69 (The PhysicalLayer doesn't provide access to a setFrequency method with an explicit calibrate param.)

[StevenCellist]

RadioLib isn't specifically designed for low-power applications.. while we may be able to do something about this, it's never going to be the best one out there - that's LBM or Modem-E. RadioLib is and will be a universal platform. So that's a general warning for you as your adventures do seem quite extensive.

@jgromes how do you feel on support for turning off subsequent calibrations? I'm not sure myself yet.

[jgromes]

The SX126x datasheet does not specify whether it is needed to repeat calibrations after some time or changes to frequency. Though doing it on every frequency setting is definitely excessive. The simplest solution I can think of is to:

1. Make the calibration flag accessible via PhysicalLayer
2. In LoRaWAN, keep track of the number of frequency updates, and only recalibrate e.g. every 10th update.

The only risk I see in this solution is if the node needs to switch to a different band. The calibration would then become invalid and a new calibration would be needed. @StevenCellist is this something that can happen in the LoRaWAN world?

[StevenCellist]

The reason for my hesitation is this: "Want to add a Bluetooth interface to your LoRa network? Sure thing! Do you just want to go really old-school and play around with radio teletype, slow-scan TV, or even Hellschreiber using nothing but a cheap radio module? Why not!"

We must assume that the user reconfigures the radio in between LoRaWAN actions. They're free to do 433MHz P2P LoRa transmissions interlaced with the LoRaWAN uplinks. Or, as mentioned by Jan, the user could in theory run two different LW stacks simultaneously if a node would be right at the border of two regions.

An idea may be to read the the current frequency in setFrequency and determine the distance between the two frequencies - if it is more than X, do a calibration, otherwise leave it. I have zero clue if repeated calibrations are a thing though.

[jgromes]

That's a fair point, there's no guarantee the user isn't doing "something weird" in between uplinks. Checking the frequency in the radio driver itself would resolve that (precedent for this actually exists, RadioLib tone emulation for ESP32 only sets a new frequency when a change is detected, otherwise the ESP32 PWM breaks).

We also need to provide a way to force the calibration, either with yet another flag for setFrequency, or better by having a dedicated public calibration method (like LR11x0::calibImage). Finally, the calibrate argument might need to be changed to something like preventCalibration, since the automated calibration is now controlled by the frequency difference. It's not a complex change, I can have a go at it.

[jgromes]

As discussed, this was implemented in b8b1afd. Quick check using LoRaWAN uplinks shows that:

1. Things work as they did before
2. Only two calibrations are performed now: one during initialization, second one when starting LoRaWAN since the frequency changes from the default 434 MHz to EU868 band.

I also updated LR11x0 driver to have the same logic, since it also has a similar image calibration.

[StevenCellist]

@tve the new logic is an even better reduction than the mentioned 3.5ms.
Using LoRaWAN::setPhyProperties() as benchmark, on 7.0.2:

08:56:09.266 > RLB_DBG: PHY:  Frequency UL = 868.500 MHz
08:56:09.278 > RLB_DBG: LoRa: SF = 7, TX = 16 dBm, BW = 125.0 kHz, CR = 4/5

.. vs upstream ..

10:13:53.636 > RLB_DBG: PHY:  Frequency = 867.300 MHz, TX = 16 dBm
10:13:53.642 > RLB_DBG: LoRa: SF = 7, BW = 125.0 kHz, CR = 4/5, IQ: U

The timings are consistent across all occurrences I checked: from 12ms down to 6ms :)
@jgromes thanks!!