You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If current value is different than the last confirmed value, send it
If you receive confirmation from the server for current value, use it as compare base for the next measurements
We do not send unconfirmed values again in this (main) loop, because we have a separate one loop (garbage collector) to perform this task (#22).
By "sent" we understand "sent to the sending queue". The first loop (data read interval) is not sending anything. This is a job of the second loop (data send interval).
If:
both values are equal (PROBE == SEND), then you have "live" mode, i.e. you measure and send on an ongoing basis,
if PROBE < SEND, you sample at a PROBE frequency and send at SEND frequency,
Again, in both scenarios you are not sending anything directly to server, but put data to the sending queue. This is required for the garbage collector to operate correctly on unconfirmed (failed to sent) measurements (#22).
Both PROBE and SEND must be scaled in milliseconds, with the minimum value for SEND being 1000 (we do not send data directly to server more often than once per second), and for PROBE -- 100 ms (I doubt that cheap hardware sensors onboard mobile devices are able to provide unique results more often).
To be more precise, PROBE == 100 ms is a special mode for experiments in which we want to check how often the electronics returns changed values. Is it possible, for example, to measure changing accelerometer values, e.g. 10 times per second? Will you be able to throw your phone and trace the curve of its flight?
The text was updated successfully, but these errors were encountered:
We need a two separate sliders or dropdown that will control:
PROBE
: data read interval,SEND
: data send interval,independently.
Rule of the thumb is:
Details:
We do not send unconfirmed values again in this (main) loop, because we have a separate one loop (garbage collector) to perform this task (#22).
By "sent" we understand "sent to the sending queue". The first loop (data read interval) is not sending anything. This is a job of the second loop (data send interval).
If:
PROBE == SEND
), then you have "live" mode, i.e. you measure and send on an ongoing basis,PROBE < SEND
, you sample at aPROBE
frequency and send atSEND
frequency,Again, in both scenarios you are not sending anything directly to server, but put data to the sending queue. This is required for the garbage collector to operate correctly on unconfirmed (failed to sent) measurements (#22).
Both
PROBE
andSEND
must be scaled in milliseconds, with the minimum value forSEND
being 1000 (we do not send data directly to server more often than once per second), and forPROBE
-- 100 ms (I doubt that cheap hardware sensors onboard mobile devices are able to provide unique results more often).To be more precise,
PROBE == 100 ms
is a special mode for experiments in which we want to check how often the electronics returns changed values. Is it possible, for example, to measure changing accelerometer values, e.g. 10 times per second? Will you be able to throw your phone and trace the curve of its flight?The text was updated successfully, but these errors were encountered: