If TCXO pin has been configured, TCXO is disabled when the radio goes
to sleep.
Set the TcxoInputOn bit properly and provide an interface to set the
correct value for the particular board/SoC.
TCXO control is required for low-power applications; keeping it always enabled consumes ~1.2 mA which is unacceptable for most battery powered devices.
This might not be directly mergeable as such, but more like starting point... the main question is how the added member function set_board_tcxo_params() should be handled. Currently it's just a new non-virtual member function for this radio only. Options could be adding the parameter(s) to the constructor of SX1276_LoRaRadio or making the interface available in the virtual base class (LoRaRadio).
Also, I'm wondering if an explicit parameter for tcxo_input_on is really needed or should TcxoInputOn bit just become enabled always when a tcxo pin other than NC is given.
The logic for enabling/disabling the TCXO is modeled after LoRaMac-node where the dynamic TCXO enabling has been implemented.
Two issues with TCXO on SX1276 resolved:
TCXO control is required for low-power applications; keeping it always enabled consumes ~1.2 mA which is unacceptable for most battery powered devices.
This might not be directly mergeable as such, but more like starting point... the main question is how the added member function set_board_tcxo_params() should be handled. Currently it's just a new non-virtual member function for this radio only. Options could be adding the parameter(s) to the constructor of SX1276_LoRaRadio or making the interface available in the virtual base class (LoRaRadio).
Also, I'm wondering if an explicit parameter for tcxo_input_on is really needed or should TcxoInputOn bit just become enabled always when a tcxo pin other than NC is given.
The logic for enabling/disabling the TCXO is modeled after LoRaMac-node where the dynamic TCXO enabling has been implemented.