[Tinyos-devel] improving FTSP interface

[Omprakash Gnawali]

On Thu, Aug 7, 2008 at 10:09 AM, Andreas Köpke <koepke at tkn.tu-berlin.de> wrote:
> Am Donnerstag, den 07.08.2008, 09:29 -0700 schrieb 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
>
> Another solution would be to provide an overflow "interrupt" like the
> Counters.
>

Commenting on the interface - an interface such as this or the one
that Brano suggested should work.

It just does not make sense for an application to make indirect
inferences which can be error prone.

- om_p