›

MetaMotion C kinetic awakening after sleep

MichaelGMichaelG
in Firmware
I have access to a lot of MetaMotion C boards. (A LOT). Using the sleep command from the Android API and the newly added option on the Metawear App, I am able to put them to sleep (successfully; I should add, as they do not advertise for an extended period). Howerver, I have discovered that about a quarter of the devices will wake from sleep mode after being moved. Simply rotating the unit seems to awaken it. They are all the same hardware revision (r0.1) and I tried reflashing firmware 1.3.6; sleeping again, and still having it wake up due to movement. So it would appear to be consistently the same devices.

I assume that the sleep mode is simply an interruption to the usual boot process that waits on the button press to continue the boot to the advertising mode. Is it possible that the one or more of the sensors (accelerometer, gyro or magnetometer) are not being initialised and are in a non-dormant state after the reset and before the sleep-pause, resulting in this behavior?

Comments

  • EricEric
    edited December 2017
    • How many units are exhibiting this behavior?  
    • When were these units purchased?

    Please send MbientLab a few of these boards exhibiting this behavior.  
  • MichaelGMichaelG
    35 of 130 units tested. There are an additional 80 which remain untested. They've been purchased in batches over the last three to four months.
  • MichaelGMichaelG
    edited December 2017
    Eric, I thought I might add that after retesting some of the units that hadn't awoken from movement, some that previously hadn't now do. I would also add, that these units were programed with a Macro that changed the name they advertised. This had reverted back to METAWEAR after being tested prior to sleep as working with the Macro. So it would appear that not only are they waking up, they aren't executing the OnBoot macro.
  • EricEric
    Please post a video that shows the devices being put to sleep, confirm they are in sleep mode, then being woken up via motion as described by your OP.  It also sounds like the boards have other code running on them before the sleep mode command.  Post the code that is run on the board leading up to sleep mode.

    Again, please RMA a few of these boards. 
  • MichaelGMichaelG
    Eric. I'll see what I can do about a video. The test procedure per device takes several minutes to turn around so it's a time consuming process to demonstrate waiting for a unit to awaken, but in a nutshell, the test procedure is as follows:

    Flash the latest firmware (1.3.6)
    Connect to the device.
    Write the macro to change the name.
    Sleep the device.
    Wake the device (with the button) to ensure the name change has taken.
    Connect to the device.
    Put the deivce back to sleep.
    Sleep is confirmed with a third party app to ensure the device is no longer advertising.

    Further testing seems to be waking more devices (a total of 77 so far), so it's quite possible they are all afflicted with the same problem it just requires sufficient movement (or perhaps the right kind of movement) to awaken them. A number of devices (18) have also drained their batteries whilst in sleep mode (see my other post regarding power consumpiton; a device I was testing drew a continual 3000uA or current but I was unable to reproduce this). Part of the test procedure is to check the button on the device to ensure it has a good mechanical 'click'. And while moving the unit, care is being taken not to press the button.

    This puts us (at time of post) with 95/130 units (73%) that exhibit anomalous behavior. I cannot fathom how this problem could be occuring other that to reiterate that if the 'sleep' is an interruption to the usual startup that prevents the device advertising, that it may be occuring before the onboard processor and hardware have been initialized to a stable state. It would save considerable time on our part if you could grab a number of your in-stock units and attempt to conduct a similar test procedure to the one I have described above to see if you experience similar results. Given the number of units now exhibiting problems, I cannot see that it would require too many test units on your end to reproduce.
  • EricEric
    Post the code are you using to configure the board as described in your previous post.  This is the first time these additional commands were mentioned so we need to be on the same page if we are to replicate your results.  

    Also, when testing the boards, are you testing with the boards bare or are they placed in a case?
  • MichaelGMichaelG
    // record name change macro active at boot
    mbl_mw_macro_erase_all(board);
    mbl_mw_macro_record(board, 1);
    mbl_mw_settings_set_device_name(board, deviceName, 8);
    mbl_mw_macro_end_record(board, macroWritten);

    // sleeping the device
    mbl_mw_debug_enablePowersave(board); // adapted from android. Sends 0xfe 0x07
    mbl_mw_debug_reset(board);

    The board is inside a plastic case.
  • MichaelGMichaelG
    As you can see, the commands being used are very straight forward. The Macro for changing the name works as was mentioned in my previous thread and the sleep process is a two step command so isn't that complicated. Can you please let me know what results Mbient is encountering from your testing? We are overdue delivering these units to a customer and cannot if there is doubt over their shelf-life.
  • EricEric
    A few questions regarding the code in relation to the macro -> sleep step in your test process (steps #3 and #4)
    • What is being run in the macroWritten callback function?
    • When is the sleep code being executed in relation to the macroWritten callback function?
      • Is it run after macroWritten has been called?
      • Or is it being executed regardless of whether macroWritten has been called or not?
  • EricEric
    Also add this code at the beginning of the function that write_gatt_char points to:

        cout << "{type: " << writeType << ", value: [" << hex << setw(2) << setfill('0') << "0x" << (int)value[0];
        for (uint8_t i = 1; i < length; i++) {
            cout << ", 0x" << (int)value[i];
        }
        cout << "]}" << dec << endl;
  • MichaelGMichaelG
    edited December 2017
    In answer to your question; macroWritten simply sends a command to turn on the LED as a visual indication that the operation is complete. The 'sleep' code is triggered by a separate ui-button in the program. Don't confuse the stated problem with the code not working. The Macro code works and the Sleep code works. I can program the macro, sleep the device and then wake the device with the button and confirm the advertisment name changes to what was programmed in the macro and sleep the device again. This all works perfectly. There is no problem writing the macro or putting the device to sleep, the problem is it wakes up when you move it.
  • EricEric
    As stated previously, we have to be on the same page i.e. I need to be executing the functions in the same manner you are therefore I need as much context as possible.  Simply providing me two code snippets with no indication of how they are used does not give me much to work with, especially since the macro is callback driven.

    You can instead modify your code in my previous post and send me the byte arrays that are printed when going through your test flow.
  • MichaelGMichaelG
    Alright, lets read from the same book and the same page. I reflashed 44 of the Metawear devices (firmware 1.3.6, they already had it but just to be sure). I then used the sleep function in the Metabase software (your software [Apple IOS]) to put them to sleep (verified by no devices found while scanning in your app). I then moved them all. 18 devices re-appeared (ie were advertising) when scanning for devices in your application. It's not a problem with the software. You have your software and a stock of Metawear devices; go ahead and test 50 of them to confirm my findings. If you still think it's a software problem, then both apps are afflicted.
  • EricEric
    What do you mean by "moved them all"?  Are you spinning them, dropping them, sliding them on the table, or something else?

    How long does it take for the 18 devices to start advertising?

    Since you have 18 devices that aren't working, post a video that shows one of these devices being put to sleep, confirmed it is in sleep mode, then being woken up via motion.
  • MichaelGMichaelG
    Give them a shake, turn the over and over a few times, pick them up, put them down, take your pick. I moved 44, one at a time and then rescan for any that have awakened since the number that do is inconsistent, so it takes that amount of time for 18 out of 44 moved to advertise. I'm cannot monitor the exact amount of time for every device to advertise after being moved as I do not know which devices will awaken. I haven't been inclined to make a video as it takes considerable time to turn around this many devices using the test procedure described above and any video is only going to be a 2-3 hour visual extravaganza of what I have already described in these lengthy posts. Do you want a video because you were unable to reproduce my result or do you think I've been trolling you this entire time? Do you think there is a flaw in my test procedure that you haven't mentioned for the last few weeks and want to confirm visually? What was the outcome of your testing?
  • EricEric
    I do not need a video of all 18 boards; pick one and record the test procedure that shows it being woken up from movement.

    I have yet to find a board that exhibits this behavior have no idea if any of the boards we have in inventory will exhibit this behavior.  You have boards that are exhibiting this issue so I am going to ask again that you RMA some of them so we get our hands on confirmed boards.  Help us to help you.
  • MichaelGMichaelG
    Here are the links to some videos (hopefully in the correct order). It's riveting stuff.

    Video 1
    Video 2
    Video 3
    Video 4
    Video 5
    Video 6
    Video 7

  • EricEric
    Ok, I suppose i'm not subjecting the boards to the same amount of shock as you are in the video.  I can try again with a box to jostle the board around.
  • MichaelGMichaelG
    Tried some of the older C-Pro devices that we're just sitting idle and as shipped (since they didn't support the newer Sensor Fusion being used in the Metamotion). Was able to reliably wake one of these up. Was going to send this and some of the Metamotions back to you. Put through the return authority, but am yet to hear anything back through email, including responses to some questions. Any update?
  • EricEric
    From what I understand, the images provided are images of CPros not having sensor fusion thus have nothing to do with the sleep issue.  

    We will have time to look into the issue more next week.
This discussion has been closed.