Anyone obtaining reliable data when streaming from Metawear cPro? Crashes and Timestamp Synch

GregJenkins

I purchased several metawear cPro boards, hoping to use them to analyze the motions of walking.  Ideally, I would be able to stream accelerometer and gyro data from one board to laptop or phone with the MetaHub app.  There are several problems though *(skip to TLDR):

1. The MetaHub app is very buggy.

Metahub has a tendency (about 1 in 3) to close when you stop the data stream, and the option to 'share' data is lost.  This happens on three different Metawear cPro boards on two different laptops.  There must be a bug in the software for Metahub.  Additionally, 'sharing' the data is nice, but having the data download directly would be better.  Give the option to email afterwards.  Often, the email doesn't keep the attached data when sending.

The Metabase app also has crash problems (probably 1 in 2 uses).  Metatracker is useless.  Metawear app is also poor for multiple sensor data.

2. The data streamed via Metahub has inconsistent time stamps.

Say we set the accelerometer to 50Hz and stream for 1 minute.  When Metahub successfully streams and delivers data, we can download .csv files for each sensor used.  However, we encounter sporadic problems.

For a single .csv file, the time stamps (and epoch time stamps) come at irregular intervals.  Often there will be regular streaming rates based on the set Hz and then a sudden group of time stamps that occur much closer together or farther apart.  Sometimes we will even receive three time stamps that are the exact same in a row.  The chunking of several data into a group and putting two or three entries under the same time stamp happens very frequently, sometimes the data exclusively comes in chunks of three.  Maybe this is a laptop or phone bluetooth error, but after trying many tests with several bluetooth devices, it is more likely error on the software or board microprocessor.

The irregularity of one sensor data stream becomes a bigger problem when trying to compare the streams of data from two sensors on the same board.  Allowing the gyro and accelerometer to run at 50 Hz each should result in equal numbers of entries at consistent intervals, but the total difference in time stamps at the end of a one minute stream may be greater than .5 seconds.  And often, one csv has seven or so more entries than the other.  Sometimes the two .csv files come at the same time stamps, but then later on become different.  The amount of error may be negligible for some cases, but in my case it is not.  I need to know the gyro and accel at the approximate same time.  Of course they cannot be the true same time, but at least I need the data to come in a consistent fashion/rate so I can make the two data streams meaningful to each other.

Additionally, the 'elapsed time' column does not match the elapsed time based on the time stamps, almost ever, in the Metahub app generated .csv.

Additionally, the Metawear app does not give time stamps other than the elapsed time, therefore I don't trust the app.

TLDR question:

When I stream accel and gyro data from one cPro board to my laptop via MetaHub and select stop stream, I experience crashes.  Why?

The two .csv's generated by MetaHub for accel and gyro at 50Hz each from one cPro board have irregular time stamps (e.g. entries come evenly spaced and then suddenly several entries in .01 seconds or none for .075 seconds, or sometimes entries come in chunks of 3 at the same stamp.)  Why does this happen? And, can I trust the time stamps, epoch, or 'elapsed time' at all?

Does anyone have a recommendation to collect synchronized data from one board?

Thanks,

Greg

Eric

You will never have reliable timestamps when streaming data via Bluetooth LE due to the sensors pushing out data faster than the devices exchange data through the BTLE connection.  The 6-axis IMU on the CPro produces data at very consistent intervals so knowing the selected data rate is sufficient to reconstruct the actual timestamps.

I have the crashes in the app dashboard so I can take a look into getting to the root cause.  Also, the sav data locally to the users "Downloads" folder, inside a "MetaHub" and "MetaBase" folder.

GregJenkins

Eric,

If you set the time stamp on the hardware side (at the moment of data generation by the sensor), this can be achieved.  The microprocessor of the sensor would assign a time stamp to the packet of data and deliver this to the PC.  (i.e. all x y z accel and x y z gyro from within a certain window is grouped together to be at one specific time).  

It is hard to use this sensor as an out of the box tool for research if the data generated lacks synchronization and regularity.  Having multiple sensors is not useful when the sensors cannot be compared.  To create precise and meaningful data, the sensor microprocessor should be coded to group data at the sensor end.

Data would look like one file:

time ax ay az ga gy gz

Where 'time' is some integer defined by the sensor that cycles from - to + of whatever size memory allocation you set for it.  On the user side when its time to interpret data, they see all sensors output at the 'same' time stamps.  (Not random time stamps with variable Hz).

Eric

Please check out this post from one of the firmware devs about packing acc/gyro data together and time sync.

Again, knowing the sampling frequency and start time is sufficient enough to reconstruct the actual timestamps of the data and combine data from multiple sensors.  Yes it requires some post processing but it doesn't mean the data is unusable.

MichaelG

Eric - "You will never have reliable timestamps when streaming data via Bluetooth LE due to the sensors pushing out data faster than the devices exchange data through the BTLE connection."

If this is true, does the device continue to a point where it will inevitably fill it's buffer, and if so would the head of the buffer crashing into the tail of the buffer be the cause of the device stoping its stream requiring the battery to be removed to reset it? This would explain why for example the Accel/Gyro stops but the Mag and LED can still be operated.

Eric

The data is send in bursts rather than on creation resulting your receiving the data in bunches that have nearly identical timestamps rather than evenly spaced timestamps.  You can image the butter queues up 1 by 1 then is dequeued in chunks.

In the case of MetaHub, it uses an alternate TX method where it will pack 3 acc/gyro data into 1 ble packet rather than 3 separate ble packets.  This lets us increase the data throughput of acc and gyro data to 250Hz but you will get groups of 3 data samples with identical timestamps.