Timestamp variability

timw

I am reading the issues people have had with the uncertainties around timestamping of data in CSV files. I am seeing the same thing. I am not sure if I have read all the threads on this subject, but answers to the following would help summarize the current situation. It also highlights the need for better documentation.

The time interval between timestamps appearing in CSV files is variable. This would suggest that the timestamps are not generated as the data is sampled (which should be at fixed intervals), but instead when it is received by the app, correct ?

If so, there needs to be another, rocksolid way to determine real time stamps based on the time of sampling. I think it has been suggested that one could simply count the number of samples to determine relative time stamps. This would obviously require that data packets are never lost.* Is this actually the case ?

If not, there should be an option for transmission of real time stamps with the data (at the expense of data bandwidth). Perhaps an additional option to vary packet size could also allow more efficient transmission, as only one timestamp per packet would be necessary.

Data for many applications may be useless without the ability to see accurate timestamps.

*The situation is exacerbated somewhat by the long download times for logged data over BLE, which means that often only real-time streamed data is practical .... but where the potential for lost packets is presumably greater ?

Eric

Correct, the timestamp on streamed data is when the data was received by the device.

Reducing data bandwidth is not something we would like to do as one of the most requested features has been to stream at higher than 100Hz and from multiple boards / sensors.  As mentioned in this post from Matt, data transmission is reliable when the data throughput is at a reasonable rate (100Hz max).

timw

> Reducing data bandwidth is not something we would like to do as one of the most requested features has been to stream at higher than 100Hz and from multiple boards / sensors. 

But recording sample time stamps on the sensor side with the data and then making them available for transmission could be made an option could it not ? That would keep everyone happy. While there are those that need data as fast as possible, there are many applications that need rock solid time stamps at modest rates.

Eric

Yes, a reference point can be added onto the data.  However, as there is no such feature in the current firmware, you will need to reconstruct timestamps as outlined in Matt's post.