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 ?
This discussion has been closed.