[Tinyos Core WG] arbiter issues

[Joe Polastre]

This then implies that all chips with radios must support 32kHz
precision to be TinyOS 2.x-compliant.  What is the width of the
timestamp?  32-bits?  16-bits is only a 2 second duration, so that
implies that the radio stack will not delay the timestamp by more than
2 seconds when dispatching to higher layers, something that may or may
not be possible based on platform, tasks, etc.

Timestamping on receive is only half the battle; it is the
reconciliation of transmit and receive stamps that reconcile timing
differences between nodes.  Are you suggesting that T2 not initially
support this in a single packet reception but rather require multiple
packet transmissions to establish a common time base?

-Joe

On 10/23/06, Philip Levis <pal at cs.stanford.edu> wrote:
> On Oct 23, 2006, at 9:45 AM, Joe Polastre wrote:
>
> >> 7) We need a radio timestamp abstraction. I am tempted to add it to
> >> Packet. Thoughts?
> >
> > This can be tricky, especially in a platform independent manner.  For
> > example, if atmega* doesn't support 32khz stamping, but msp430* does,
> > what does the Packet interface expose?  Can you insert timestamps into
> > a message, or is it only for SFD capture on receive?  Lots of
> > questions here...
>
> Both chips provide 32kHz timestamps.
>
> I think we went over the issues a few months ago: the timestamps are
> gathered locally at a point which the RX and TX nodes agree on. For
> the CC2420, the SFD interrupt is the common place to do this, but the
> CC1000 (or XE1205 or TDA5250) might pick a time besides the first
> data bit of the packet. It is up to the radio stack to decide when
> this point is, based on the radio's capabilities and the stack's
> software structure.
>
> The reason why I'd argue it belongs in Packet is because it is the
> generic interface that all packet-based protocols use. It doesn't
> make sense to turn L2 acks on/off on routing-layer packets, for
> example: that's up to the routing layer. However, as long as packets
> are moving through the data path, timestamps are important, and
> adding another interface seems unnecessary.
>
> Given that these timestamps will suffer from inaccuracies due to
> atomic sections, I think that a fixed precision but variable accuracy
> might be palatable.
>
> Phil
>