MetaMotionR+: Maximal Recording Time coming up short
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?
Comments
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)
Logging
Streaming