In a previous post, I reported that the XIAO nRF54L15 does not significantly exceed the current consumption of the XIAO nRF52840 during BLE connections.
The main reason for this was the RF_SW implemented in the XIAO_nRF54L15. Since Zephyr does not support fine-grained control of the RF_SW, it had to be kept ON at all times.
Subsequently, thanks to @Loren_Bufanu ‘s development of the Arduino Core, it became possible to run the XIAO nRF54L15 in a lighter runtime environment. ’The XIAO nRF54L15 Works with Arduino’
Additionally, in the discussion below, there was a discussion about turning the RF_SW on as needed to reduce BLE current consumption.
Could you use CONFIG_BT_CTLR_GPIO_PA to allow this functionality in Zephyr? You would treat the RF_SW as the pin to enable an power amplifier, but instead it would enable the RF switch?
I believe it’s possible to turn RF_SW on and off using CONFIG_BT_CTLR_GPIO_PA and CONFIG_BT_CTLR_GPIO_LNA, but I haven’t tried it myself. According to the FM8625H datasheet, it takes 10 μs to come up from power-on, so the response speed might not be sufficient.
I was actually researching buying the nrf54l15 version for power saving on a BLE device when I noticed the power issues/stats you had posted.
It does seem like that config option I mentioner might be depreciated in Zephyr 3. New Solution seems to be to configure the FM8625H as an external FEM. Which you can configure the boot up time to be 11 microseconds…
I tried it, but I got a compilation error and it didn’t work.
According to information from Seeed, a new board called XIAO_nRF54LM20A will be released at the end of the month. This board does not include an RF_SW. If you’re not in a hurry, I recommend this one instead.
So check out the size dif, in the video… it’s tiny compared to the “FLAG” on the S3 , can see that one from mars..
Really though the RF switch is/was a PITA and a current suck. The improvements to the new XIAO are very, impresive.
on the S3 , can see that one from mars..
PJ 
