dorukeker
commented
5 years ago Hello, Thanks for reaching out.
I wrote this library for an installation 5 years ago. JS is not my day-to-day programming language. And I have not worked with JS for more than 2 years now. So in this context I don't have the time to keep the library up to date for every new device unfortunately. I will add this disclaimer to the README file as well.
Having said that (and without any test on device) below is my remarks for your questions.
The library is build up on the native API from JS. And devices tend to be inconsistent how they handle the values (hence the library). It might be newer devices have a different interval to return values.
There might be a change in the native API which I am not aware of.
I agree with the naming; it should have been "rate" or something like this.
Please have a look at the source and share your findings here for others as well. And also please feel free to check other libraries. I think with on 5 years some one out there created something better. (hopefully :-) )
Cheers, Doruk
Thanks for creating this lovely library. The frequency parameter is both not correct and also seems to have meaningful performance problems. The documentation says: frequency:50, // ( How often the object sends the values - milliseconds ) There are a number of challenges here. 1) The frequency sampling is badly variable/inconsistent and also it appears to be impossible to generate good performance. For example, on a recent device (Pixel 3) with little other JS processing going on, the time between samples with frequency:0 varies from about 30msec to about 70msec. This is more than a two-fold range! If a value is set, eg frequency=10, the same basic problem happens. Also, the sampling interval isn't stable. I graphed it over time, and (especially if there is meaningful JS processing going on) the time between intervals isn't stable over time... it creeps up, starting at about 51msec between samples, then 55msec, then 60msec, then 70msec... This means that quantitative use of the time series data is problematic to say the least. Not sure if the only option is to interpolate the data to estimate the 'correct' values at evenly-spaced times. Is there is some better way to handle this to achieve actual more even sampling, rather than trying to correct the error after the data have been collected? Is it possible for the library to sample from the accelerometer / gyro at even intervals and/or at shorter intervals/higher frequency? 2) Setting the value of frequency to 0 does not actually result in very fast sampling. It appears that there is a minimum. On the device I'm testing on (Pixel 3 using Android Chrome browser), this appears to be around 50msec per sample, 20Hz, but inconsisten. I'd really like to be able to sample faster than this. Is that possible? Is it limited by the device, or something somewhere in some settings? 3) The parameter is called "frequency", but it is actually not a frequency but something more like an interval, or a delay. A frequency is a rate (for example a frequency is 20 Hz = 20 times per second). The value presented is more like an interval or delay between samples in milliseconds (for example delay 50 milliseconds between samples). This means that users have to do their own experimenting, as I did, to understand what the result of this parameter actually is. Better documentation would be very helpful. At least, the parameter should be correctly named so its less confusing.
Thanks for your help, and thanks again for the library.