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

[user123]

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.

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

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.

[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.

[user123]

Thanks for your answer. So any app that needs to record while phone is in sleep needs have a service capability. I guess none of the similar apps have this then. Except 'Sensor Charts' which doesn't have so many options to get raw data.

But there are many apps that have these sensor monitoring features, like fitness tracking, step tracking, they somehow doesn't use battery as much and can run along with everything else without much drain, on some Huawei phones for example (Huawei health app).

I would guess sensor on average would drain like 4-5% per hour with screen off which is not that much, with screen on it would be 15-20%. For example linear acceleration on my phone consumes 0.900 mA - 0.9‬ mAh. If average battery is 3.8-4 V and 4000 mAh, the particular sensor could work for 4444 hours if there wouldn't be any other power consumers. Screen on consumes around ~300+mAh.

[Sebastian Staacks]

But there are many apps that have these sensor monitoring features, like fitness tracking, step tracking, they somehow doesn't use battery as much and can run along with everything else without much drain, on some Huawei phones for example (Huawei health app).

Good observation. But the step counter capability is actually proided by Android as a separate sensor. This means that the app does not have to monitor and analyze the accelerometer itself, but instead it only needs to wake once in a while (or maybe not at all until the user turns on the screen again) and just receive the latest count from the system. (See https://developer.android.com/guide/topi...tepcounter). The counting itself is done by Android and on most modern phones it uses a special coprocessor for this (this was one of the novelties of the iPhone 5s if I remember correctly...).

I would guess sensor on average would drain like 4-5% per hour with screen off which is not that much, with screen on it would be 15-20%. For example linear acceleration on my phone consumes 0.900 mA - 0.9‬ mAh. If average battery is 3.8-4 V and 4000 mAh, the particular sensor could work for 4444 hours if there wouldn't be any other power consumers. Screen on consumes around ~300+mAh.

I am not worried about the drain from the sensor it self but from the CPU not entering deep sleep states. The power consumption of the CPU will exceed that from the sensor by far and entering deep sleep states is essential for battery life.

[joe]

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.

Hey, I was just wondering the same as user123 if there would be an option to get a timestamp at the beginning of the recording and stumbled across this post.

Did you already try to implement this feature? This feature would really help us because we want to compare the measurements of phyphox to another sensor (connected to a PC) which has timestamps in UNIX/POSIX time format.

[Sebastian Staacks]

No, sorry, it is not implemented yet. I will try to put it in the next update.

[joe]

Thank you, that would be great! (Although the app is already great)