On Jan 3, 2007, at 4:41 PM, Michael Newman wrote:
For time counts driven by a crystal the types of errors you are
talking about should result in time variations of seconds per day.
What I am seeing is seconds per minute.
A repeating counter set to 1000 milliseconds should count seconds
with some jitter. I don't expect the events to be exactly on the
second, I do expect the number of events per hour to be correct.
Basically the timers are driven off of the watch crystal which
counts the ATmega128 counters. I expect to schedule an event every
time the ATmega128 counter passes the appropriate number of ticks.
I do not expect the events to get lost, nor do I expect extra
events. I expect the events to be near in time to the tick that
triggered them but not exact in time, because there may be other
tasks that compete for the exact time.
In any case counting fast indicates a flaw, competing for resources
and failing to get them would result in slow counts.
As Cory mentioned, please note that the timer interfaces talk in
terms of 2^10 ticks, not 10^3 ticks. So if you specify a time of
1000, even if you had a perfect crystal you would see the timer run
fast at a rate of 1024/1000 Hz, which is 58.5 seconds. So you would
see a 1-2 second difference. Can you quantify the results you've seen?
The reason for using 1024 rather than 1000 is one of accuracy. Since
the underlying hardware is in terms of 1024ths, then converting to
true milliseconds would introduce inaccuracies. In particular, it
would be possible to choose ms values which should be in phase but
would not be due to drift, unless you pay the overhead for partial
counts. E.g., a 111ms timer and a 999ms timer would slowly move out
of phase of one another.
Phil
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
