You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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()
SX126xSetSleep() first calls SX126xAntSwOff() and then calls SX126xWriteCommand() which internally may call SX126xAntSwOn() and leave RF switch on. I think it would be safer to call SX126xAntSwOff() 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.
The text was updated successfully, but these errors were encountered:
I was trying to work around this issue #1594 by calling
Radio.Sleep()
after LoRaMAC init with NVM restore. My initial issue is this one zephyrproject-rtos/zephyr#73417 (comment).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:
LoRaMac-node/src/radio/sx126x/sx126x.c
Lines 254 to 269 in dcbcfb3
LoRaMac-node/src/radio/sx126x/sx126x.c
Lines 134 to 143 in dcbcfb3
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.
The text was updated successfully, but these errors were encountered: