RAK4600 disable BLE

LPWAN Modules / EVBs RAK4600
#1

Hello everyone,

I’m looking for reducing power consumption as much as possible, so I would like to turn Bluetooth RF off by default, is there a way of doing this?
I’ve searched in the AT commands manual but there’s only one command for setting the BLE work mode but none of the options disable RF.
On the other hand, RUI doesn’t seem to expose a way of turning BLE off.

It would be desirable to keep all the AT commands that the latest official firmware offers.

P.D. BLE functionality isn’t required right now, maybe in the future I’ll be using it and that’s why I selected RAK4600, but in the current application in order to reduce consumption I’ll be disconnecting the power of the RAK4600 when it isn’t used, then when I want to transmit data I reconnect power and send the data via LoRa.

Any help will be appreciated.

#2

Hi @nicolasech,

RAK4600 consumes around 11-12uA at sleep mode at+set_config=device:sleep:1.

If your application needs lower than that, cutting the power source is the only choice. No need to turn of BT RF since it is already off.

#3

Thanks for your answer @carlrowan.
My concern is in transmit periods, if I use LoRaWAN message confirmation then I’ll need to wait some seconds depending on the number of retries I’ve set. So, in those seconds I’ll be wasting power on BLE RF. Do you know if there’s a way of turning BLE off?

#4

At my measurements, if you are not using the BLE and no LoRa transmissions (class A), the current should not be too high. What current do you measure on idle state and while waiting for confirmation?

I am not sure on your transmissions intervals, but I believe the sleep currents will most likely determine your battery capacity unless the transmit interval is quick (like faster than 1 minute).

#5

Using confirmed uplink is probably inadvisable anyway (if you are using Chirpstack as your server, it’s basically broken at the server end).

But if you are going to do it, you still need to respect uplink duty cycle limits which means waiting before re-transmitting, and you should be in lower power sleep during that waiting, because you don’t want to burn power with the processor core waiting out the delay awake.

Really if you want confirmation its better to do it your own scheme at application level, that also lets you know that the data actually got through to your consuming infrastructure, and not merely the LoRaWan server.

What evidence do you have that BLE is actually active? Is the device beaconing? Given that BLE devices are usually battery powered, the underlying BLE stack is only going to power up the RF when it actually needs to use it to transmit or receive. If it’s not transmitting, and it’s not scanning or paired, it shouldn’t be doing anything.

#6

@cstratton thank you for your answer.

What evidence do you have that BLE is actually active? Is the device beaconing? Given that BLE devices are usually battery powered, the underlying BLE stack is only going to power up the RF when it actually needs to use it to transmit or receive. If it’s not transmitting, and it’s not scanning or paired, it shouldn’t be doing anything.

Right now I don’t evidence that BLE is active, it’s just a guess because I didn’t find any documentation on how to disable it and I don’t a tool that helps me to measure the actual current consumption of the device. Soon I’ll be getting a tool for this purpose and I’ll be reporting any news I find.

#7

I also have a requirement for this in my latest application, and I have evidence from using nRF Connect on my phone that the device is beaconing all the time.

Are there really no API commands for at least stopping advertisements?