[Tinyos-devel] timesync

[Andreas Koepke]

> Hi Philip,
>
> Ok, then TimeSyncSend interface should have a precision_tag parameter.
> Do we want to make the over-the-air format generic as well? I think we
> could stick with microsecond precision there, and it should be
> possible to convert that to T32k on the fly. What do you think?

That depends whether T32kHz and TMicro use the same counter or not. The 
eyesIFX platform could use a real 1MHz oscillator for TMicro and the 32768 Hz 
watch crystal for T32kHz. If I remember correctly the micaz could do 
something equally weird. A conversion between these two counters is not 
possible without loss of precision. For eyesIFX I think it is best to 
implement the T32kHz, uint32_t variant.

> Miklos
>
> On Mon, Feb 25, 2008 at 10:09 PM, Philip Levis <pal at cs.stanford.edu> wrote:
> > On Feb 25, 2008, at 11:24 AM, Miklos Maroti wrote:
> > > Hi Ben,
> > >
> > >> Is there potential for offering more than one precision interface
> > >> such as
> > >> with Timers? <TMicro> <T32kHz>, or even <TMilli> for those not
> > >> requiring
> > >> high precision but still wanting a reasonable approximation within
> > >> their
> > >> network? I suggest options as I think some platforms only offer
> > >> their lower
> > >> power states with certain timers still running (e.g. I think I am
> > >> correct in
> > >> saying that the micaz can only offer at best 32kHz precision in
> > >> its lower
> > >> sleep states?)
> > >
> > > Yes, that is possible, with some extra work. The real problem would be
> > > 1) you have to use typed TimeSyncSend interfaces, 2) you have to be
> > > able to convert between the different time representations.
> > >
> > > Regarding 1) I am happy to have a parametralized TimeSyncSend
> > > interface. Please others comment on this.
> > >
> > > Regarding 2) there is no real framework that could convert between the
> > > available clock sources on the same mote! Ideally, there would be only
> > > one imeginary local time, and LocalTime<T32k, uint16_t>,
> > > LocalTime<TMicro, uint32_t>, LocalTime<TMilli,uint32_t> would just
> > > return a sequence of N bits of this imaginery local time value. Then
> > > we would need some global functions to convert between these
> > > representations, which would be not too difficult to do. However, I do
> > > not want to introduce something complicated (controversal) into the
> > > tree, but us the KISS (Keep It Simple, Stupid) and get the minimal
> > > infrastructure so a) it is easy to implement on each platform, b)
> > > powerful enough so everything can be implemented on thop of it.
> > >
> > >> One other potentially very useful interface that could be included
> > >> within
> > >> the timesync functionality (though this is possibly something for
> > >> a separate
> > >> Component such as "GlobalTime") would be a GlobalTimer interface that
> > >> accepts global time t0 values within timer.startxxxAt(t0,dt) type
> > >> functions?
> > >
> > > Yes, that would be very nice too, but again, that is left to others
> > > to do.
> > >
> > >> p.s. Another solution to the precision question would be to allow the
> > >> optional use (in low power modes or hardware offering rougher
> > >> timers) of a
> > >> lower-precision timer feeding updates to a <tmicro> counter value
> > >> in bigger
> > >> steps. i.e. It'd be a timestamp value in microseconds but with
> > >> less-than-microsecond precision (e.g. a <32kHz> counter could
> > >> update the
> > >> timestamp clock in 31.25 microsecond increments). This would allow
> > >> compatability in the interface but also allow lower-precision
> > >> clocks to be
> > >> used as the app developer requires?
> > >
> > > This is even more complicated than the one I wrote above, but
> > > certainly it would be nice.
> >
> > The general philosophy in TinyOS is that if you can check it at
> > compile time, you should.
> >
> > The reason why there are different timer granularities is it allows
> > an implementation to state its precision in a way that can be checked
> > at compile time. Making it a run-time call would mean that code which
> > expects and requires a 32kHz timer but happens to be wired to timer
> > whose actual precision is 1kHz cannot detect this until the system
> > boots. This bloats code -- you have to do the checks -- and is error
> > prone.
> >
> > So fundamentally, the idea of having a Timer<TMicro> goes against
> > this. It's either a TMicro or it's not; you shouldn't pretend.
> > Otherwise, imagine trying to debug why your system doesn't work
> > because you happen to have made the TMicro that a fine-grained TDMA
> > protocol uses actually be a TMilli and fake the precision.
> >
> > Phil
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel