Reconstructing Timestamps and Counters

mgeorgi

Hi there,

I was just reading these threads about timestamps, as we also have some difficulties with reliably reconstructing timestamps for individual packets:

http://community.mbientlab.com/discussion/1934/metahub-timestamps/

http://community.mbientlab.com/discussion/1991/understanding-streaming-timestamps

I understand your suggestions to use the ODR and the sample count to reconstruct sampling timestamps and to use the expected elapsed time to detect package loss for selecting reference points. We more or less use such an approach and for the most part it works quite well.

What I wanted to ask is whether it would be viable for you to include a counter (maybe 8bit) in the sent data packages, so that it would be easier (and in my opinion more reliable) to detect losses of single packets. 

I understand, that this would change some parts of your current API (most prominently the available fields in the return types of your sensor streams like MblMwCartesianFloat), and maybe you already fully utilize the available space in the BLE packets, but maybe this would a alleviate some problems.

Eric

We have discussed the counter idea before but it is not something we are planning on adding as we have a packed mode for high frequency streaming.  Matt addresses briefly talks about adding a counter in this post (2nd to last paragraph).

http://community.mbientlab.com/discussion/comment/3210/#Comment_3210