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:
Check every PROBE seconds, send every SEND seconds, but only if data is different then previous measurement
Details:
If the value is the same as the last one, then do not send
Compare current measurement to the confirmed measurement only (#22)
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?
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 aPROBEfrequency and send atSENDfrequency,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
PROBEandSENDmust be scaled in milliseconds, with the minimum value forSENDbeing 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 msis 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?