Open lff5 opened 2 weeks ago
My current workaround is to call Radio.Sleep()
and then SX126xAntSwOff()
after lorawan init (with NVM) in application layer.
Here is what the lorawan init looks like: https://github.com/zephyrproject-rtos/zephyr/blob/d45605e6a3dfe68e43207d15e3bfc003cbfaa72f/subsys/lorawan/lorawan.c#L682-L723
I was trying to work around this issue https://github.com/Lora-net/LoRaMac-node/issues/1594 by calling
Radio.Sleep()
after LoRaMAC init with NVM restore. My initial issue is this one https://github.com/zephyrproject-rtos/zephyr/issues/73417#issuecomment-2165139700.The problem I'm bringing up here following: calling Radio.Sleep() puts radio to sleep mode, but in some states turns on the Antenna Switch pin which means higher current consumption.
Its easy to see in the code. Here is the stack call walkthrough:
RadioSleep()
->SX126xSetSleep()
->SX126xWriteCommand()
->sx126x_spi_transceive()
->SX126xCheckDeviceReady()
->SX126xAntSwOn()
Here are the functions in calling order:
https://github.com/Lora-net/LoRaMac-node/blob/dcbcfb329b4a343ab007bc19ac43a8dc952b3354/src/radio/sx126x/sx126x.c#L254-L269
https://github.com/Lora-net/LoRaMac-node/blob/dcbcfb329b4a343ab007bc19ac43a8dc952b3354/src/radio/sx126x/sx126x.c#L134-L143
So
RadioSleep()
->SX126xSetSleep()
->SX126xWriteCommand()
->sx126x_spi_transceive()
->SX126xCheckDeviceReady()
->SX126xAntSwOn()
SX126xSetSleep()
first callsSX126xAntSwOff()
and then callsSX126xWriteCommand()
which internally may callSX126xAntSwOn()
and leave RF switch on. I think it would be safer to callSX126xAntSwOff()
in the end.I discovered this because of 'working around' or 'misusing' the internal api, but please do consider this tiny, it seems much safer! I haven't checked if the other radio implementations suffer from the same potential issue.