large skips in time stamps

[jeglin]

Hello I tried searching but didn't come up with much. Apologies if this is a well-known aspect of phyphox. 

I found this thread:
https://phyphox.org/forums/showthread.ph...large+data

But not sure if my issue is related. My issue: without thinking much about sample rate, I hopped on a roller coaster and started the accelerometer (iPhone 10,3). These rides are short, maybe 6-7 min at a time, but since I keep the phone secure in a pocket, I have to start the data-logging relatively far in advance before the ride starts (a minute?). At the end of the ride, the phone is inaccessible in my pocket until I can get out of the ride, but generally less than a minute, and still taking data. I export as csv and at first glance the data looks good, very fine grained of course, but in detail there are sudden gaps in the data. Example: 

Data file with 5741 data points. There is a sudden jump in the timestamps from 62.69 to 305.21, then one at 316.29 to 459.62, and a final jump from 468.50 to 632.18. The data ends at 632.27. The meta time file shows START at 0.00, PAUSE at 3.66, START at 3.66, and PAUSE at 632.29. Screenshot shows a basic plot of data highlighting the gaps (I got a warning about multiple screenshots but there should be only one).

I'm having a hard time figuring out what's going on. It's as if the sensors' algorithm decide to suppress data collection for periods of time. I realize that phyphox is limited by how and when the sensors choose to provide data. Am I trying to take too much data or for too long? Is this an issue on the data export end? If there an obvious piece of documentation I'm missing?

[Jens Noriʇzsɔɥ]

The amount of data should not be a problem on an iPhone with a rate of 100Hz and just about 10 minutes of data taking. I would have expected accidental* pausing of the recording, like it happened at 3.66. However, that should be visible in the time metadata.

Could you send us your export by email (contact…phyphox…org). Unfortunately, I am not that optimistic that we can read more from it.

*the upcoming version 1.1.11 has an option to blank and block the screen if the proximity sensor is triggered that could prevent it in future

[jeglin]

Thanks for the info, I've sent the original zipped data file as requested.

Not sure I follow the explanation. According to the metadata, if I understand correctly, there is an accidental PAUSE at 3.66. I assume you denote it such because there is an immediate START at the same time. But if I read it right, it should not have lost any acquired data all the way through to 632.29, where it PAUSEd again; however, there are significant gaps.

What do you recommend as a test to track this down? Before every one of the runs, I locked the phone, but I agree that even within my dark pocket, the proximity sensor could still be triggered (I in fact see this just while walking around). Or should I just wait for 1.1.11 and try again?

[Jens Noriʇzsɔɥ]

Thank you for the data.

It's as if the sensors' algorithm decide to suppress data collection for periods of time.

This also appears to be our best guess what happened: you have recorded “acceleration without g” and this is not a real rather a so-called fusion sensor. Data of the acceleroemeter, gyroscope, and magnetometer is combined in order to subtract earth's gravity acceleration.

If one of these sensors does not provide data, then there is also no fusion data and “acceleration with g” respectively. The magnetometer easily saturates, so if there was some magnetic lock, for instance, it could have stopped working.

My first assumption was that the experiment simply stopped and restarted. This appears quite unlikely now. A new feature in version 1.1.11 could prevent these accidental stops/starts with help of the proximity sensor. It has nothing to do with your observation. Sorry for the confusion.

Has something similar ever occurred to you or is it in some way reproducible? You could create a “simple experiment” via (+) and add the magnetometer: we would clearly see if there is a problem with it.

[jeglin]

Thanks for this info, very helpful. One issue is that I think I misinterpreted the docs. I had selected "without g" because for some reason I had it in my head that it was the non-fusion sensor. For data like this, I will proceed in the future "with g" so that I don't depend on the other sensors.

Looking forward to the next version. Yes I've noticed this same effect before albeit not in an extreme roller coaster environment. I always assumed it was user-error on my part or maybe too much data acquired for a buffer or something. I will do some controlled experiments and raise the issue again if I think it's warranted.

I'm curious about how the magnetometer enters in. The gyroscope makes sense for a correction, but I'm unclear about how/why the magnetometer enters in, esp in any experiment that is "local enough."

Thanks for the replies!

[Jens Noriʇzsɔɥ]

IIRC, https://www.youtube.com/watch?v=0rlvvYgmTvI has been quite instructive (the experiment on https://phyphox.org/wiki/index.php/Attitude_sensor fits quite well to the video). Earth's magnetic field provides a fixed axis and helps determining –and correcting– the smartphone's orientation in space.

[jeglin]

Fantastic resource, thanks!