[Tinyos-devel] improving FTSP interface

[Branislav Kusy]

>>> 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.
so to make it easier for app developers, FTSP can provide 
isRollover(uint32_t current_time) command that implements this, right?

one scenario, where rollover would be useful is when your application 
runs for a long time and doesn't query ftsp's global time very often. 
33rd bit could flip twice without the app realizing it, while rollover 
bit would stay set. for 32khz clock (hopefully provided soon), this 
would mean 4.5 hours which is not totally unreasonable. ftsp could 
realize the rollover because it receives periodic timesync messages.

brano