Putting a Metawear device into 'sleep' mode.

I read somewhere that when Mbient ships their hardware with a battery in place, that the device is put into a 'sleep' mode that it is awoken from by pressing the button which places it into idle mode awaiting connection. Is there a command in the API or other method by which I could return the device to this sleeping state where it does not sit listening for BTLE connections?

Comments

  • The Android SDK has the sleep mode function available in the Debug module. The iOS SDK exposes sleep mode in its internal modules which will require adding the SDK directly from GitHub.

    Basically, you just need to enable sleep mode then reset the board for it to boot into sleep mode.
  • By reseting I assume you mean, remove and insert the battery, or is there a command that can get the board to reboot?
  • Oh, and out of curiosity, what is the power consumption when in sleep mode?
  • The debug module has a reset command.  

    Sleep mode power consumption is lower than the min rating.  This is not specced as sleep mode is not a standard use case for the boards.
  • Eric. I've tried using the enablePowersave function from the Android API. It sends the byte sequence 0xFE 0x07 to the device. I've then followed that up with the 1) mbl_mw_debug_reset command, 2) the mbl_mw_debug_reset_after_gc and 3) removing / inserting the battery. Each method yields no change in the current profile of the device. It draws about 1.2 mA after being reset (regardless of the technique used) and then drops back down to the operating current with BTLE advertising bursts. Am I missing something?
  • edited October 2017
    If the board is advertising, then it is not in sleep mode.

    With the Android SDK, the below code snippet will boot the board in sleep mode:

    final Debug debug = metawear.getModule(Debug.class);
    debug.enablePowersave();
    debug.resetAsync();

    You can confirm if it works by checking the BLE scans before and after pressing the board's button.
  • Eric, When could you make a change on the IOS app to allow the user to put the Metamotion C to Sleep?

    Yes, I understand it would require a mechanical press of the button to wake it up.

    Thanks


  • Eric. This is one of the techniques I tried. I gave it another shot putting a 1 second delay between the commands. Out of 2 dozen attempts to put it to sleep, it succeeded once where the device reset and sat at about 14 uA consumption. Pushing the button woke it up as described previously, but I was never able to put it to sleep again.

    P.S. I thought perhaps that once it had been awoken from sleep it may not respond to the sleep command. So I removed and reinserted the battery, then tried to sleep it. Still nothing.
  • Your script is most likely terminating before the reset command has been sent to the board.  Monitor the BT adapter and see what values are transmitted from it.

    I've already addressed the SDK availability in your other thread.
  • Eric, the question was,
    When can you make a change to the Metawear IOS App to have a sleep function built into that for testing and also allow us to have a quick solution.

    Thanks
  • Eric. The device does reach reset. As I am monitoring the power consumption I can see the behavior of the device, and it is as it is when it resets. Is there any condition under which after sending the command to sleep, that the sleep mode would be aborted before the reset occurs?
  • @MichaelG
    Try writing an Android app with the code snippet in a previous post or use the nRF Connect app to manually send the commands.  Both methods reliably put the board in sleep mode on my Nexus 6.

    The iOS app will not be updated to use the sleep function.  You can modify the app yourself with the necessary changes or build your own sleep mode app using the starter template.
  • edited October 2017
    Eric. I've tried writing the app using the code snippet provided above and I am using another MetaMotionC device (in case there was some problem with the first). After executing the code Bluetooth reports that the device looses connection, so from that point of view the device is no longer visible and would appear to have gone to sleep; however, as I am monitoring the current draw, it fluctuates between 2.7 and 3.7 milliamps, averaging almost exactly 3 milliamps (not microamps, milliamps) which is definately more power than the idle mode which uses around 17uA and 120uA when advertising.

    How are you determining that the board has gone to sleep? How can anyone ever be sure that the Sleep mode has worked other than the fact that the connection with the device is lost?
  • edited October 2017
    If the board is still advertising, then it is not in sleep mode.
  • Eric, Why is the board consuming so much power in Sleep mode?

    MichaelG stated "After executing the code Bluetooth reports that the device looses connection"

    He is inferring the device is now in "Sleep" mode. Can you try to think of reasons why your device is using more power than you have quoted whilst in "Sleep" mode?

    Thanks


  • Just because the device looses connection does not mean it is in sleep mode.  I've stated how to tell if the board is in sleep mode so first lets determine if the boards are behaving as described in my previous post.  


  • Well, yes you lose connection AND the device no longer advertises.
  • Is the board in question running the v1.3.5 firmware?
  • @BenO

    If your board is consuming more power than idle mode, you are not in sleep mode.  Double check you firmware versions.  Verify with a second device.  Double check your measurement setup.

    Sleep mode is nearly equivalent in function to idle mode, except advertising is disabled and the SoC is put into essentially shutdown.  This will tend to produce a "sleep" current consumption of 1-3 uA less than the non-advertising current of idle mode.

    Entry into sleep mode typically takes less than 1 second after receiving the soft reset.  The only thing that will slow this process down, is if significant log entries remain in the device before entering sleep.

    When the device is power cycled -- for instance removing the battery -- it will not be in sleep mode when the battery is replaced.

    We have multiple devices here in the lab that show no issue entering sleep with firmware r1.3.4 or r1.3.5 and consume expected current.
  • It would be great if there were some way to trigger sleep mode without an explicit reset; for example, on disconnect.  We are looking into use cases where the sensor will be used occasionally (say, an hour a day) and we'd like to maximize battery life so our users don't have to recharge or replace the batteries often.

    Right now, if the device were to disconnect without being reset by my app (e.g. if the user turns off Bluetooth on their phone, or walks out of range with the device) then it will not enter sleep mode.

    Is there any other way to trigger the reset, other than from an explicit command from the app?
  • Actually, it looks like I can do this:

    [device.settings.disconnectEvent programCommandsToRunOnEventAsync:^() { [device.resetDevice]; }];

    which will trigger the reset when disconnected.

    Not to be greedy... but is there also a way to do the reset after a time elapses after the disconnection, rather than immediately?
  • Hmm, how do I do that with the disconnected event?  To use the MBLTimer, I need to provide a callback, and I can't put a callback inside programCommandsToRunOnEventAsync, can I?
  • Create the timed event and use the disconnect event to start the timer.
  • Great, that worked, thanks.

    Is there a way to persist a timer event using MBLRestorable?  When the device is woken from sleep, I'd like it to go back to sleep after a timeout if there's no connection.  (Otherwise, if the user presses the button to wake it up but never connects & disconnects with his phone, the battery will continue to drain.)

    I tried this:
    MetaWearConfig* config = [MetaWearConfig new];                                                       
    config.timerEvent = [mw.timer eventWithPeriod:1000.0f eventCount:5 autoStart:NO triggerOnStart:NO];  
                                                                                                         
    [[config.timerEvent programCommandsToRunOnEventAsync:
        ^()
        {
            [mw.led flashLEDColorAsync:[UIColor greenColor] withIntensity:1.0f numberOfFlashes:1];
        }] continueWithBlock:
        ^id(BFTask* task)
        {
            return [mw setConfigurationAsync:config];
        }]; 

    where MetaWearConfig is defined like this:

    @interface MetaWearConfig : NSObject<MBLRestorable>
    @property (nonatomic) MBLTimerEvent* timerEvent;

    @implementation MetaWearConfig
    - (void)runOnDeviceBoot:(MBLMetaWear*)mw
    {
        [self.timerEvent start];
    }

    I hoped that when the device boots the timer event would start and the  LED would flash green, but it doesn't happen.
  • The timer creation also needs to be contained in the runOnDeviceBoot block.
This discussion has been closed.