MetaMotionR+: Maximal Recording Time coming up short

edited September 2017 in General
p.p1 {margin: 0.0px 0.0px 12.0px 0.0px; line-height: 13.0px; font: 12.0px Garamond; color: #000000; -webkit-text-stroke: #000000} p.p2 {margin: 0.0px 0.0px 12.0px 0.0px; line-height: 15.0px; font: 12.0px 'Lucida Grande'; color: #000000; -webkit-text-stroke: #000000; min-height: 15.0px} p.p4 {margin: 0.0px 0.0px 12.0px 0.0px; line-height: 14.0px; font: 12.0px Times; color: #000000; -webkit-text-stroke: #000000; min-height: 14.0px} p.p5 {margin: 0.0px 0.0px 12.0px 96.0px; line-height: 13.0px; font: 12.0px Garamond; color: #000000; -webkit-text-stroke: #000000} li.li3 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 13.0px; font: 12.0px Garamond; color: #000000; -webkit-text-stroke: #000000} span.s1 {font-kerning: none} span.s2 {font-kerning: none; color: #747474; background-color: #ffffff; -webkit-text-stroke: 0px #747474} span.s3 {text-decoration: underline ; font-kerning: none; color: #0000ee; -webkit-text-stroke: 0px #0000ee} ul.ul1 {list-style-type: disc}

I’ve done a number of test recordings and come to some troubling results regarding the device’s maximal recording time. There were essentially two basic set-ups:

  • Acc & Gyroscope at 100Hz (+ possibly Magnetometer at 25Hz or Light at 1-5Hz – Given the low sampling rate, I didn’t imagine these should make much of a difference. There was one ‘accident’ where the acc was set at 50Hz)

  • Quaternions and/or Euler angles at 100Hz

Above is a record of the most detailed examples. Initialization and exporting was done with your mobile app, MetaBase, while the battery level was gauged using MetaWear. The “duration” is taken as the difference between the end and start time of the accelerometer reading or quaternion reading where relevant. Under all circumstances, the devices had >20% battery when reconnected, so from that I assume memory becomes an issue long before battery life. The data was downloaded from the sensors after waiting at least 2 hours from the start time. Here are a few things that I don’t understand: 

Logging: The datasheet for the MetaMotionR+ device says “8MB NOR FLASH – Off board/ Up to 500K sensor data entries.” When Logging, only 2/5 of the readings were close to the 500k sensor data entries. If it wasn’t battery life or the 500k readings, what caused recording to stop? The two which were performed worse were both sensor fusion related, although there was one, as noted above, which didn’t calculate quaternions but displayed other recording discrepancies (see note in picture)

Streaming: In streaming mode, I would imagine the recordings would no longer be limited by onboard memory constraints (only the memory constraints of the device they are streaming to, in this case a phone with >10GB of extra space). Looking at the “total rows” column, it seems here again there is some kind of invisible boundary around 685k rows. No recording exceeded 2 hours of recording and there was a very large variance among the recording lengths (b/w ~1 hr to 2 hours). The phones (signal receivers) were plugged in the entire time and located within 2m (well below the 10m Bluetooth range) for the duration of the recordings. The website for the MetaMotionR says “The 8MB of extra memory allows applications up to 24 hours of sensor data gathering at high sampling rates. Most applications are able to log sensor data up to 2 months of data in the field at slow or medium sampling rates”

o    Can someone clarify what the “extra” refers to here? Is this not the same 8MB onboard memory mentioned in the logging/memory section?

o    Further, if I take the upper bound sampling frequencies mentioned in the extended dataseheet here as a benchmark of what ‘high sampling rates’ means (1600Hz for acc, 3200Hz for Gyro, and 300 Hz for Mag), then all of my recordings should reach if not exceed the 24 hrs timeframe…

o   Why are the recordings are coming up much shorter and why there’s such variance among them?


  • Sensor fusion data consumes more log memory than the acc, gyro, and mag data per entry thus records less entries.  On the other hand, illuminance data uses less memory per entry so you can record more values.  Also, the ~500k is total number of entries that can be recorded so if you are recording multiple sensors, you will not be getting 500k entries per sensor.

    When you were streaming data, what did the in app counter display for # of samples received?  Was it greater than this 685k boundary mentioned in your post?  Perhaps your spreadsheet software has row limitations and cannot display more than 685k rows.

    The "extra" refers to the aforementioned flash memory chip.
  • edited September 2017
    Hi Eric, 

    Thank you for responding. 

    Sensor Fusion Logging
    - "Sensor fusion data consumes more log memory than the acc, gyro, and mag data per entry thus records less entries." I don't really understand how this is the case unless the log memory is holding something other than the csv files which are subsequently exported. The total maximum memory of any of the acc/gyro/mag/light recording maxes out around 45mb (roughly 20mb for each acc & gyro file, and maybe 5mb for the rest). On the other hand, the recording maxes for the quaternion/light combo comes out to only 20mb (~19mb for the quaternion file and maybe 1mb or less for the light file). The number of rows in an acc file is roughly comparable to the quaternion file, and it has 6 columns whereas the quaternions has 7 (also, almost comparable)

    For reference, I'm using Microsoft Excel Version 15.33 for Mac. Whenever I open the files and scan to the last row in the document, it gives rows until 1,048,576 ... so it's not a spreadsheet software problem.

    Streaming - I believe for all samples there came a point when it didn't actually provide a sample received count, though it still had a message saying that it was still recording flashing as thought said it was still recording. I still don't have any clue what should stop the streaming process.

  • edited September 2017


    • By "data" I am referring to the raw values reported by the sensors and sensor fusion algorithm, which is what MetaMotion boards record.  The boards themselves do not create nor log CSV files.

    • Again, the ~500k log entry count is total number of entries.  If you allocate those entries to both acc and gyro data, as mentioned in your previous post, they will have an equal number of entries compared to only recording quaternion data, which confirms my quoted statement.


    • The streaming portion of the app has a "Samples Received" text.  Does that value equal the total sum of the number of rows in the CSV files?

    • There is a red button at the bottom of the panel to stop the stream.  
This discussion has been closed.