Yesterday, 11:37 AM
The problem is that there is no guaranteed method to request a specific sampling rate from the operating system. Phyphox knows about three strategies to achieve a target sampling rate:
Copied and slightly modified from our Wiki:
request
The target rate is directly requested from the system and the provided sensor data will be provided as is. It depends on the system if the provided rate is close to the requested one and the system might not be able to provide sensor data at given rates or it might decide to provide a different rate if the sensor data is shared with other apps. This strategy is most likely to yield a rate that strongly differs from the expected one, but as it will not group or discard data points, it will not introduce additional sampling or aliasing effects.
generate
The target rate is generated internally by phyphox while requesting the highest possible rate from the system. It is guaranteed to give data points at the desired rate and can even exceed the sensor rate (be careful not to waste performance with this). While the resulting data points seem very easy to interpret afterwards and while it makes it easy to synchronize different sensors, this strategy can severely degrade the recorded sensor data as data points might be duplicated or discarded in unforeseen patterns. If the target rate is close to the actual internal sensor rate, this will very likely introduce additional sampling effects like aliasing between the sensors sample rate and this target rate. Therefore, this strategy is recommended for educational purposes to simplify data analysis, but if you know how to analyze data and want the best possible data quality, it is highly recommended to use the request strategy instead as you can emulate the generate strategy in your data analysis later, but you could not go back to the quality of "request" from "generate" data.
limit
The maximum sensor rate is requested by the system and the setting of rate is used as a limiter. More precisely, phyphox generates a new data point whenever the time interval from the last data point to the latest sensor event exceeds 1/rate. The resulting rate will always be close to but lower than the requested rate and the actual rate strongly depends on the actual sensor rate. This strategy is a compromise to get close to a target rate without the strong degradation introduced by the generate strategy as it usually leads to a similar number of sensor events per actually generated data points. The downside is that the data point rate may be quite different on different devices if the target rate is in the range of typical sensor rates.
Now, the default behavior in phyphox is "auto", which means that it starts with "request" and switches to "generate" if the system delivers a rate that is 10% faster than the target rate.
You can pick a specific strategy by setting an additional attribute like this:
<sensor type="accelerometer" rate="0" rateStrategy="limit">
However, as described above, if the system does not give a matching rate, I would advice against using "generate" to get the exact target rate, because this will artificially duplicate or drop and re-arrange datapoint, which can be quite degregading if you then feed it to a Fourier transform.
I am not sure why the 50 Hz case sometimes starts slower. It might be that iOS treats 50 Hz as a sign that it is a lower priority use case and allows that the sensor starts a bit later, so that the increasing rate is just a statistical effect because of the pause at the start?
Your 80 Hz example is not that surprising: The iPhone very likely does not offer a 80 Hz rate, but will still send data at 100 Hz. Phyphox recognizes that it is 20% too fast and switches to the limit strategy. In this case, every second data point is dropped because it arrives before 1/80Hz and you end up with every second data point, resulting in 50 Hz.
As long as the iPhone does not offer a native rate of 80 Hz, going with 50 Hz is you best option, because every other strategy will just artificially mess with the timing of the original data. You can also set the "stride" parameter to specifically only pick every n-th data point, but that might not be a good idea if you want to use this on different phones as well as some Android phone deliver up to 500 Hz and you end up with very different rates.
(See https://phyphox.org/wiki/index.php/Phyph...le:_sensor for the full documentation)
Copied and slightly modified from our Wiki:
request
The target rate is directly requested from the system and the provided sensor data will be provided as is. It depends on the system if the provided rate is close to the requested one and the system might not be able to provide sensor data at given rates or it might decide to provide a different rate if the sensor data is shared with other apps. This strategy is most likely to yield a rate that strongly differs from the expected one, but as it will not group or discard data points, it will not introduce additional sampling or aliasing effects.
generate
The target rate is generated internally by phyphox while requesting the highest possible rate from the system. It is guaranteed to give data points at the desired rate and can even exceed the sensor rate (be careful not to waste performance with this). While the resulting data points seem very easy to interpret afterwards and while it makes it easy to synchronize different sensors, this strategy can severely degrade the recorded sensor data as data points might be duplicated or discarded in unforeseen patterns. If the target rate is close to the actual internal sensor rate, this will very likely introduce additional sampling effects like aliasing between the sensors sample rate and this target rate. Therefore, this strategy is recommended for educational purposes to simplify data analysis, but if you know how to analyze data and want the best possible data quality, it is highly recommended to use the request strategy instead as you can emulate the generate strategy in your data analysis later, but you could not go back to the quality of "request" from "generate" data.
limit
The maximum sensor rate is requested by the system and the setting of rate is used as a limiter. More precisely, phyphox generates a new data point whenever the time interval from the last data point to the latest sensor event exceeds 1/rate. The resulting rate will always be close to but lower than the requested rate and the actual rate strongly depends on the actual sensor rate. This strategy is a compromise to get close to a target rate without the strong degradation introduced by the generate strategy as it usually leads to a similar number of sensor events per actually generated data points. The downside is that the data point rate may be quite different on different devices if the target rate is in the range of typical sensor rates.
Now, the default behavior in phyphox is "auto", which means that it starts with "request" and switches to "generate" if the system delivers a rate that is 10% faster than the target rate.
You can pick a specific strategy by setting an additional attribute like this:
<sensor type="accelerometer" rate="0" rateStrategy="limit">
However, as described above, if the system does not give a matching rate, I would advice against using "generate" to get the exact target rate, because this will artificially duplicate or drop and re-arrange datapoint, which can be quite degregading if you then feed it to a Fourier transform.
I am not sure why the 50 Hz case sometimes starts slower. It might be that iOS treats 50 Hz as a sign that it is a lower priority use case and allows that the sensor starts a bit later, so that the increasing rate is just a statistical effect because of the pause at the start?
Your 80 Hz example is not that surprising: The iPhone very likely does not offer a 80 Hz rate, but will still send data at 100 Hz. Phyphox recognizes that it is 20% too fast and switches to the limit strategy. In this case, every second data point is dropped because it arrives before 1/80Hz and you end up with every second data point, resulting in 50 Hz.
As long as the iPhone does not offer a native rate of 80 Hz, going with 50 Hz is you best option, because every other strategy will just artificially mess with the timing of the original data. You can also set the "stride" parameter to specifically only pick every n-th data point, but that might not be a good idea if you want to use this on different phones as well as some Android phone deliver up to 500 Hz and you end up with very different rates.
(See https://phyphox.org/wiki/index.php/Phyph...le:_sensor for the full documentation)