Real time clock in csv & option to run while phone is sleeping & sample rate

[Sebastian Staacks]

Some apps can export csv with real time clock timestamp like physics toolbox, but phyphox can't. Would be nice if this was added, it's such a simple feature I was surprised that this app didn't had many options.

Phyphox does not only export time series data. Every entry you see in the main menu is not hardcoded but defined in our own file format, which tells phyphox which sensor should be recorded, which mathematical operations should be applied and how the results should be presented. This means that most of these entries have much more than just the sensor data, like results of some analysis but also temporary results. Therefore, our file format also defines which data should be exported, which can be simple sensor data vs. time, but also none time-series data like an audio spectrum or acceleration vs. angular velocity. That is why there is no general way phyphox does this, but for most experiments phyphox gives time relative to the start of the experiment.

Now, this could of course have a different point of reference. So, what do you mean by "real time clock"? Are you looking for a human readable timestamp like "2020-01-09 08:00:00.000" or for a numerical one that gives an absolute time like a unix timestamp "1578556800", which is seconds since 1st January 1970. All of these have advantage and disadvantages, depending on what you want to accomplish and where you are coming from. If your a coming from an IT background, you will prefer the unix timestamp as this can easily be interpreted in most programming languages. If you want to place phyphox on a floor and just want to read from the raw data, at which time someone passed by, you probably prefer the human-readable format.

However, phyphox is designed for physics education from school to university level. And for this, we decided on a format that can easily be understood (hence no unix timestamp) and still easily be processed for plotting (hence no human-readable format). Besides, phyphox is designed to be used for experiments in class. This does not mean that there may not be longer measurements, but first of all, it is designed for experiments that do not last longer than a few minutes...

If you are not wondering about the format, but if you in fact mean "real time clock" in the sense of the clock in the device, the situation is much more complicated. Sensor events from the system are given in nano seconds since the device booted (uptime). This is done because the real time clock might jump at any moment when the system syncs the clock, which would make any process depending on sensor data jump - imagine that every game controlled by tilting the phone would jerk when the phone updates the system time because the sensor data would have a slightly different time base. Also, the real time clock only gives us a resolution of milliseconds, which is not enough when considering a 500Hz accelerometer featured on many devices. (see here about the different clocks on Android: https://developer.android.com/reference/...ystemClock)

So, the most accurate time we can give you is uptime. But "time since start of the device" does not have much more meaning to the user than "time since start of the experiment". For most users, it actually means less. If we were to calculate an absolute time from this, we could try to regularly compare it to the system time, introducing jitter due to its lower resolution and jumps due to clock synchronization. Alternatively (and I would think that this is what the other apps do), we can note the start of the experiment as a real time event and simply add the differences in uptime from the beginning.

The latter should be fine for almost all use cases, but as mentioned above for our use case, a simple time since experiment start is preferable. However, we should note the actual start time somewhere, so I will introduce some experiment metadata with one of the next updates. So, you will get the info at which time the experiment started and calculate absolute time from the relative timestamp given within the table.

2nd thing useful would be sample rate setting. Instead of max 200 Hz or something I would like to use 10 Hz

From the main screen, you can hit the "plus" button to create a simple experiment configuration reading selected sensors at a given rate. For more detailed options, you can use our editor (https://phyphox.org/editor) or directly our XML format (https://phyphox.org/wiki/index.php/Phyphox_file_format) to set up more complex configuration and for example set up your own averaging.

One warning though: You will most likely not exactly get the rate you request. We can not directly poll the sensor and we cannot set a sensor rate. On both, Android and iOS, apps can only subscribe to sensor updates and set a desired rate in terms of pre-defined use cases. So, we can request updates with rates suitable for UI (typically a few Hz), suitable for gaming (25-50 Hz) or as fast as possible (typically 100Hz-500Hz). What we actually get depends on the device and while it typically is given at a more or less constant rate, it is not guaranteed to to come in at fixed intervals. Therefore, phyphox always requests the maximum rate from the system and uses the user-defined rate as a limiter for internal averaging. If you request 10 Hz on a device that samples at 500 Hz, the result should be close to 10 Hz, but if you request 10 Hz on a device that samples at 99 Hz, you will get something slightly different at a non equidistant rate.

3rd thing is - this app doesn't work while phone is sleeping. I tried 8+ sensor recording apps, this one seemed to have the most potential, which is why i'm writing here. I also liked physics toolbox, but it doesn't work wheen sleeping, it just leaves out the time when phone was sleeping in its reports.

Other apps just froze data when recording after phone entered doze mode or something. Some apps just stopped recording, including this one.
I want to record data for more than just a few seconds.


Question is does this app have wakelock support to access phone sensors while in sleep?  Because I had disabled battery optimization for this and other apps, didn't help. I disabled aggressive doze in greenify - didn't help.

That is because it is not as simple as just keeping the device awake. The part of the app that fills the screen is called an "activity" (that is the Android term, but iOS behavior is similar) and any activity is stopped as soon as it is not displayed any more. This is not just a case of the phone sleeping, but this happens when switching to different activities (other apps), turning off the screen or on iOS even when pulling down the notification bar. To avoid this, we need to split the recording part from the activity into a so-called service (the ones with a notification icon in the notification bar). I wish, we had designed phyphox that way right from the beginning, but now this means some heavy restructuring. It is on the todo list, but the benefits are not big enough to have reached the top of that list yet.

In fact, I am not entirely sure about the benefits. For our typical user this will hopefully mean that they can record with the phone in their pocket. But I am not yet sure if all recording capabilities are available in this state - even with a wakelock. On top, phyphox requires some improvements to gracefully handle long recordings when the user begins to run out of memory to reasonably offer this feature (at the moment there is no warning and the export is the first thing that stops working).

Also, I do not expect that you can save much battery if you were able to turn off the screen (I assume that the Play Store review with the same demands is by you). Of course, the screen consumes some energy, but the most important aspect to save battery is allowing the CPU to enter deep sleep states, which is why Android and iOS so aggressively prevent any app from keeping the phone awake. Obviously I have not tried it, but I would think that the battery drain of an active phone with deactivated screen will be very similar to an active phone with a dimmed screen - even more so when using an OLED screen.