Timestamp error of metawear


I created an android app using metawear to track(logging) behaviours of patients, but looks like the timestamps have something wrong. It looks right on the first half of data, but another half was wrong (it was good but suddenly jumped to another day in the next second at some point), please see attached data files. (mmc.xlsx is the overall analysis, duration columns are how many minutes the patients were wearing the metawears).

Some of the logging data are like ( see the timestamp, it went to the future):

1.57435E+12 2019-11-21T09:25:09.208 0 -0.79268295 -0.79268295 -0.12195122
1.57435E+12 2019-11-21T09:25:09.229 0 0.5487805 -0.24390244 -0.18292683
1.57435E+12 2019-11-21T09:25:09.248 0 0.36585367 0.42682928 -0.36585367
1.57435E+12 2019-11-21T09:25:09.268 0 -0.24390244 1.1585366 -0.5487805
1.57435E+12 2019-11-21T09:25:09.287 0 -0.91463417 1.6463414 -0.6707317
1.57435E+12 2019-11-21T09:25:09.308 0 -0.6707317 1.7682927 -0.5487805
1.57435E+12 2019-11-21T09:25:09.327 0 -0.30487806 1.8902439 -0.18292683
1.57435E+12 2019-11-21T09:25:09.347 0 -0.30487806 1.8292683 0.12195122
1.58064E+12 2020-02-02T05:02:45.368 0 -1.0365853 1.7682927 0.24390244
1.58064E+12 2020-02-02T05:02:45.387 0 -1.7073171 2.2560976 0.6097561
1.58064E+12 2020-02-02T05:02:45.407 0 -1.6463414 2.9268293 0.79268295
1.58064E+12 2020-02-02T05:02:45.426 0 -1.2195122 3.1097562 0.4878049
1.58064E+12 2020-02-02T05:02:45.447 0 -0.9756098 2.6219513 0.18292683
1.58064E+12 2020-02-02T05:02:45.466 0 -1.097561 2.0731707 0
1.58064E+12 2020-02-02T05:02:45.486 0 -1.3414634 1.7682927 -0.06097561
1.58064E+12 2020-02-02T05:02:45.505 0 -1.5243902 1.7682927 -0.12195122
1.58064E+12 2020-02-02T05:02:45.526 0 -1.7073171 1.7682927 -0.06097561
1.58064E+12 2020-02-02T05:02:45.545 0 -1.8292683 1.5243902 0.06097561
1.58064E+12 2020-02-02T05:02:45.565 0 -1.4634147 0.9756098 0.06097561
1.58064E+12 2020-02-02T05:02:45.584 0 -0.85365856 0.30487806 0.06097561

Anything will help!



  • edited January 2020

    Are you able to replicate this and if so, how? Please send us the steps to replicate (code would be ideal) so we can solve this as a possible bug.

  • Sounds good to me, but the particular sensors are in the hand of another research group, it may take few days to get them from their hand. I'll try to replicate the situation and let you know. Thank you!

  • edited January 2020


    I tested two times, it happened again, I used 3 different boards to test, two of them had this issue in one of the tests, and these ones are not the previous boards (the previous boards which I thought were broken didn't have this problem again). So I guess it randomly happens, it's not a problem of particular boards.

    If you want to run this app, you need to follow these steps:
    1. open up the mobility app
    2. give all the permissions it requires (Bluetooth, Locations and read/write to external files)
    3. wait it to scan all the nearby sensors and update battery levels. (Note: I didn't setup "choose particular sensors" function, if there are a lot of sensors nearby, it will scan all of them and read all the battery information from them one by one, this step will be extremely slow. So please leave only 3 or 4 different sensors nearby to test)
    4. when every battery level is read, your can tap on the menu button on the top-right corner and choose "Start All Boards", all the scanned boards will light up one by one, it means they are recording right now.
    5. If you let them record for a short time, this problem usually doesn't happen, so I suggest that you can wait for about 50 minutes. (Also it may not happen in one test)
    6. When time's up, you can tap on "Sync All Boards" in the menu to download all the data from all the boards, you don't need to click " Stop All Boards" since the boards will be automatically stopped when start downloading. It's better to leave your mobile device alone while downloading, the screen will stay awake itself.
    7. It takes about 25 minutes to download 3 boards, the red progress bar under each board in the list will show the progress of downloading for current board (downloads one by one).
    8. You can find a folder in the root directory of file system named "mobilityData_CURRENT_DATE" ( for instance: mobilityData_2020_01_29) and all the data are saved in this folder.

    I included our app apk, some of the data sets and majority of my code files as attachment if you want to have a look and a test.

    Also, I found it's interesting that data of the first board we processed is usually correct, if you see the xlsx file I posted last time, you will know what I'm talking about.


  • @zhatiayua thank you for your comments and data. We are aware of this issue and testing for the root cause.

  • Thank you, if you figure out what happened, please let me know.

  • Hi @zhatiayua
    Can you let me know what is the firmware that each of the sensors are running.
    Are the ones that are failing running the latest firmware?

  • Hi Laura,
    I'm not sure about the firmware version, and I didn't find a way to retrieve firmware information in the documents, can you let me know how I can read that from metawear?

  • If you use the MetaBase App and you go to the diagnostic screen, you can read the firmware version.
    Please see www.mbientlab.com/tutorials -> metabase app or www.mbientlab.com/troubleshooting.

  • Hi, I used metabase app retrieved firmware info, please see attachment

  • You need to update to 1.5.0

  • @zhatiayua please update your firmware to latest and let us know if the issue persists.
    I would also make sure that your application is clearing the log before starting a new logging session. It may be that your devices contain data from older sessions that are interfering with the log readout cycle. Note that a firmware update alone will not clear old data from log memory.
    We have done a fair amount of testing on our end and have not seen a single sighting yet.
    It would also be a useful data point to know if this occurs when working with only a single sensor.

  • edited February 2020

    Ok, I will update it to 1.5.0 and see what will happen.

    Btw, can you let me know how the timestamp feature works? I guess metawear board doesn't have a clock right?

    *Edit: Looks like it cannot be updated by metabase app, if I try, the metabase app crashes. Is "downloadFirmwareUpdateFilesAsync" the only way to update firmware? (My device is Pixel 2, Android 10.)

  • MetaWear (Sensors) have an onboard clock. When you download the sensor data, the metawear clock and clock of the master device (smartphone, tablet, hub or whatever you are using) are synced.

    Please provide information regarding the metabase android app crash (photos, videos and so on).
    Try with an iOS device in the meantime.

  • Hi,

    Attached file is the screen record video, I currently don't have an iPhone, I will try that later.

  • @zhatiayua said:
    *Edit: Looks like it cannot be updated by metabase app, if I try, the metabase app crashes. Is "downloadFirmwareUpdateFilesAsync" the only way to update firmware? (My device is Pixel 2, Android 10.)

    I pushed out a MetaBase fix (version 3.4.15) to address a security issue with foreground services (https://github.com/NordicSemiconductor/Android-DFU-Library/issues/209).

  • Thanks, I'll take a look on that.

  • @Laura Thank you for reaching out to me, I'm currently working on cleaning the data we collected (it's kind of more urgent), I haven't started fully testing the metawear devices. I will test it out after I finish this part.

  • @zhatiayua Thanks for the update.

    Let me know as soon as you have news on this.

    We need to know if it's a bug or not so we can make the corresponding software/firmware update if needed. On our side, we have not seen this issue and we have not been able to reproduce so we are relying on you.

Sign In or Register to comment.