Indefinite Sleep mode or Force Standby State

Hi,

Is it possible to remotely execute a command that would force a BLE node into indefinite sleep or standby mode?

I am working to build out a BLE mesh network, where I will need to enable a feature that allows a user to "push a button" to force the entire mesh network into standby state or possibly sleep mode. The user then would also hit the same button to wake the mesh back up without a pre-defined time period to return to normal functionality.

BLE does have a standby state, but I am not having much luck in finding any resources that discuss putting the node into a standby state at the link layer. 

I've seen a ton of discussion on sleep/wake cycles, but I'm looking for hours or days of sleep cycles with the ability to interrupt that cycle back to "wake" at any given moment.

Thanks

Parents
  • Hi Terje,

    I'm not worried about the functionality of the mesh network with it turned off. It would kinda be the point. The use-case would require it to shut down, and then be turned back on remotely whenever the requirement to have it back on was met. 

    For the on/off model, are you meaning the deviceoff function message that turns the node off, and requires a physical interaction to turn back on?

    The two main objectives would be that I would verifiably be able to remotely shut down all BLE transmission (TX) of all nodes in the group, and then remotely turn them back on. In BLE standby mode, the radio isn't transmitting, but I don't know if I can force the radio to this mode, and then execute a remote command to push it back to normal operation.

  • Hi,

    I am struggling a bit to understand the full use case here. In this "sleep" mode, are we only talking about normal messages over the mesh network not being transferred, or are we talking about the devices themself entering a mode where the radio is disabled?

    Obviously in order to remotely control the devices there must be some RX going on. Either that they are in RX all the time (consuming the same amount of power as they would do when running the full mesh network,) or that they wake up periodically to check if they should wake up (which gives a latency to waking up equal to the wake up period.) What kind of power requirements (if any) do you have in sleep, and what maximum latency requirement do you have for wake up?

    It should be possible, yes, to disable and enable TX using some signal, and otherwise stay in RX all the time (or enter a low-power mode with periodic RX for listening for packets in order to wake up). It would however involve a separate protocol than Bluetooth mesh for when being in the sleep mode, as Bluetooth mesh by specification do require some TX which cannot be disabled in the stack. The mesh stack must therefore be disabled during sleeping.

    Regards,
    Terje

Reply
  • Hi,

    I am struggling a bit to understand the full use case here. In this "sleep" mode, are we only talking about normal messages over the mesh network not being transferred, or are we talking about the devices themself entering a mode where the radio is disabled?

    Obviously in order to remotely control the devices there must be some RX going on. Either that they are in RX all the time (consuming the same amount of power as they would do when running the full mesh network,) or that they wake up periodically to check if they should wake up (which gives a latency to waking up equal to the wake up period.) What kind of power requirements (if any) do you have in sleep, and what maximum latency requirement do you have for wake up?

    It should be possible, yes, to disable and enable TX using some signal, and otherwise stay in RX all the time (or enter a low-power mode with periodic RX for listening for packets in order to wake up). It would however involve a separate protocol than Bluetooth mesh for when being in the sleep mode, as Bluetooth mesh by specification do require some TX which cannot be disabled in the stack. The mesh stack must therefore be disabled during sleeping.

    Regards,
    Terje

Children
No Data
Related