This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Timestamping the data
#1
It would be nice if you could utilize the highly accurate clock inside the cell phone and timestamp each data point down to the millisecond or higher.

This would become extra useful when you want to align the data with events happening on a different clock than phyphox.

Otherwise you must rely upon several potentially unstable mechanisms for timestamping the data. 

Right now when I batch the data out, I am using the timestamp associated with the filename as the closest estimate to when the last datapoint was logged. This allows me to put the data on a real clock. This isnt a terrible solution as it mitigates the data traffic latency that would occur if you sample in real time, but the best solution would be to timestamp the data using the cell phones clock.
Reply
#2
The time logged by phyphox (which is the time in your exported data and the one in the buffers you can request via JSON) is based on the time of the sensor event as given by the system (for example on Android: https://developer.android.com/reference/...ensorEvent). This is (nominally) given in nanoseconds uptime (since the system started), so in principle it is quite precise.

Phyphox uses the first sensor event it receives to set the beginning of the measurement to "zero", which is not really consistent across multiple sensors due to our poor implementation of this. I plan to improve this eventually, but this will mostly be done by making the system time of the start available to the user. The problem is that uptime is a very precise and reliable measure while system time can be very tricky as it can be adjusted at any time. Uptime is used to avoid "jumps" when the system adjusts the clock and for the same reason we cannot simply output our data with absolute time stamps, but will need to add a point of reference instead.
Reply
#3
When you create a CSV file, you get a timestamp in the file name. I imagine this is the time in which the file was created. Is there any way to get this value from a json?

I am wondering... is generating a csv file the only way to get both the uptime and system clock sampled in a close proximity?
Reply
#4
Yes, it is the creation time, but since phyphox gives data relative to the start of the experiment, you don't get any info about the uptime. The best synchrization at the moment is probably starting with your script and storing the start time of your controlling machinę. Unless you measure over a very long duration you do not need to sync the clock of the phone (or the measurement timestamp) and the clock of your controller.
Reply
#5
(11-17-2018, 08:43 AM)Sebastian Staacks Wrote: Yes, it is the creation time, but since phyphox gives data relative to the start of the experiment, you don't get any info about the uptime. The best synchrization at the moment is probably starting with your script and storing the start time of your controlling machinę. Unless you measure over a very long duration you do not need to sync the clock of the phone (or the measurement timestamp) and the clock of your controller.

O Yeah, I am looking to record from like 100-10,000 devices at the same time for several days straight. I want to align them all the best I can down to hopefully millisecond range. I am working on some tricks for how to get a distributed sync pulse across geographic territories, but I haven't settled on anything yet.

I would like to run a physics experiment where I have people across the world put their cell phones on the ground and we poll the accelerometer data at maximal sampling rate. Then use this geographically distributed local sensor mesh of acceleration measurements to try to predict the data measured from government seismic activity monitoring systems
Reply


Forum Jump: