Sleep mode with LPN and no mesh

[Alex Ross]

Hello,

We have a product that will be frequently separated from the mesh and will rejoin. There's a goal of 250 devices that all need to get updates sent to them. Think something like syncing epoch time and having an easy to view status of all devices battery levels. I have this working well with the basic mesh (not LPN). However the current draw is around 5 mA which is way too high for the battery requirements. 

It seems like the LPN is the way to go, however, the devices will frequently leave the mesh and rejoin. It's my understanding that when the LPN doesn't have a friend anymore, it automatically starts searching for a new one. The goal is to keep the BLE in the uA range as much as possible so if it's searching I don't see how well that will work.

The devices will be headed to places where there's no BLE traffic so the initial thought was to have the radio wakeup the device to get it to start searching again but I'm now not so sure that this is possible.

The next solution would be to have it force the radio/mesh off and scan for a beacon message periodically. If the beacon message is there, start the mesh service. If not, disable the mesh service and continue to sleep.

Is this the right path? Is there anyway to just have a simple interrupt based off of the presence of radio traffic?

I'm currently working with the 833. The mesh server side can have a shorter battery life (Ideally still less than 10 mA) 

Thanks!

[tesc]

Hi,

Current draw of 5 mA for normal Bluetooth mesh nodes is as expected, as they have to be in RX when not in TX. RX draw current running on DC-DC for nRF52833 is typically 4.6 mA, ref. the nRF52833 Product Specification.

LPN will save power, but as you write, when losing connection to the friend node the default action is to start looking for a new one.

It is not possible to wake on radio traffic, no. From what I understand, in order to wake e.g. on RSSI, one would need to have the radio already running in RX mode. Having the radio switched on and waking the CPU on radio traffic would not do much, as the main power draw is from the radio peripheral itself in RX mode.

Switching mesh activity off/on, deciding when to search for friends and when not to, that could be the way to go, yes. Either through periodically waking, look for friends, then go back to a sleep mode if none found, or through some smart method for deciding when to look for friends (e.g. NFC tag (for which wake on field detect is supported), movement detected (e.g. by an accelerometer), button press, etc.)

Regards,
Terje

[Alex Ross]

Is it possible to get an internal count of nearby devices? I'm thinking something to the effect of:

-Wakeup every second and get a count of nearby devices (or attempt to find a friend) 
-If count is 0 then go back to sleep
-Else attempt to find a friend
-No friend go back to sleep

How long it would it take to determine if a friend is nearby?

Could you also clarify to me how in normal BLE mode devices wakeup? I'm thinking something like a tag. How does it wake itself up out of sleep mode when the phone wants to get an update? 

[tesc]

Hi,

I cannot think of any (at least not straight-forward) way to count the number of nearby devices. However it would probably be better on wakeup just to try to find a friend (for a brief period of time). It should be in the same ballpark energy consumption, if not even better.

With a normal BLE connection, the connection is timed. A timer is running on the device, which triggers the radio peripheral to go in RX mode, which when receiving a packet triggers the stack (waking the CPU for handling the packet.) This means, the device is in RX mode only at the proper times for the connection event, and is turned off otherwise.

In BLE, you also have settings such as "slave latency", which lets the peripheral device skip a configurable number of connection events, i.e. radio turned off for longer time period, when it does not have any data to send. It means however that the central device (usually the phone) cannot send data to the peripheral device until the peripheral device acutally listens for a connection event.

That is during an ongoing connection. For leaving the connection, then reconnecting when needed, you can do wake on NFC, wake on movement (e.g. by use of external accelerometer), wake on button press, or wake on button.

Also, for setting up a BLE connection, the peripheral device runs advertisements, for which the central device listens. Advertising interval and to some extent type and size of advertisement will affect power consumption. Examples typically starts with rapid advertiing, then go over to longer advertising interval, and then stop completely after a couple of minutes. Then restarts (from low advertising interval) if triggered.

Regards,
Terje