Timestamping the data

[jbshute]

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.

[Sebastian Staacks]

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.

[jbshute]

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?

[Sebastian Staacks]

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.

[jbshute]

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

[YvesD]

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

Any update on this thread? I need synchronization between more than one device in frequency.

[sprigga]

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.

Is the feature any update? thanks.

[Jens Noriʇzsɔɥ]

System time is now stored as meta data in the export files, see https://phyphox.org/wiki/index.php/Versi...tory#1.1.8

Please note that that the accuracy of the (absolute) system clock is not necessarily great on smart devices.

[praveen2600]

Thank you for updating this feature. There is a slight difference between the START and PAUSE time in the RAW DATA sheet and the METADATA TIME sheet when I exported the data. For example, in the magnetometer expt:

Raw data Start time : 0.036072143, Pause : 6.796072143
Metadata Time Start time : 0, Pause : 6.804982289

I believe both the timestamps should be the same. You have already provided an option of "Convert to system time" when I zoom in on the data. This replaces the timestamp in the time axis with the local time in the GUI mode. Why not "export also" every timestamp by the local timestamp instead of the only exporting start and pause time?

[Jens Noriʇzsɔɥ]

The “Metadata Time” reflects the user actions play and pause. The raw data shows the time that the smartphone OS provides us with a sensor's data and it is highly unlikely that it is just on tap.

For some sensors it takes a bit until phyphox gets their first values and smartphone clocks are not that well synchronised. So, the moment of tapping play could be meaningful information that should be kept.

The current time column is what most users need and additional columns –easily obtained by other means– would add to confusion. So we would like to keep it the way it is, of course unless there is a good reason we have overlooked. Please keep in mind that there is some added complexity with leap seconds in human readable formats…