[Tinyos-devel] improving FTSP interface

[Miklos Maroti]

>> But realize, the 33rd bit (which is what you are asking for) might
>> change for other reasons as well. How can FTSP detect a rollover
>> internally? If your timesync is so much messed up that it cannot
>> distinguish a rollover from a simple 2^31 unit time offset change,
>> then you should not rely on it in the first place. Trust me, just
>> watch the 32nd bit, and tell me a concrete scenario when that is not
>> working.
>
> It is much easier for FTSP to realize if it is a rollover or other
> reasons than an application. I think this is different from 33rd bit.
>
> Yes, we run FTSP in scenarios where something more than the 32nd or
> 33rd bit would be useful and seems necessary - a bit that takes into
> account the FTSP state machine as well as the counter value.

FTSP does not have a state machine, it always updates its internal
global clock pretty much in the same way (except when it is the root
node). It calculates a reference point (local, global time pair) and a
skew from an internal list of data points. Yes, global time can jump
if the node looses connection, but you can detect that one as well
(via the TimeSyncInfo.getNumEntries method). It is not clear if your
overflow (33rd bit) should be set or cleared when a jump occurs. The
only reasonable solution would be the following:

1) maintain the last obtained global time value
2) periodically read the current global them when needed
3) if the current global time is less than 0x3FFFFFFF and the last
global time is greater than 0xBFFFFFFF, then you have a rollover.
4) replace the last global time with the current global time and go to step 2.

Actually, step 3) could be more precise as follows:

(int32_t)(current_global_time - last_global_time) > 0
&& (int32_t)(current_global_time) >= 0
&& (int32_t)(last_global_time) < 0

The first condition says that the clock went forward (with or without
overflow, think about it)
The second condition says that the highest bit in the current global time is 0
The third condition says that the highest bit in the last global time is 1.

This should work. Always.

Miklos