[Tinyos-devel] timestamps in seriallisten/sflisten etc.

[Vlado Handziski]

On Thu, Jun 26, 2008 at 22:36, David Gay <dgay42 at gmail.com> wrote:

> On Thu, Jun 26, 2008 at 1:27 PM, Philip Levis <pal at cs.stanford.edu> wrote:
> >
> > On Jun 26, 2008, at 12:59 PM, Razvan Musaloiu-E. wrote:
> >
> >>>
> >>
> >> I'm a little confused. What is a "packet source"? In the way I'm
> thinking,
> >> the code that handles the direct serial communication to the mote is the
> >> only one that is required to read the clock and put a timestamp.
> >
> > The point is that serial@ is a protocol; it doesn't define an endpoint.
> It's
> > possible to connect two PCs via serial cable and have them talk the
> serial
> > protocol. As I said before, while this might seem a bit unlikely, there
> are
> > other protocols that can connect directly to motes, such as network@,
> which
> > is essentially the serial protocol over a TCP socket.
> >
> > It would be a very bad idea to bind protocols to particular kinds of
> > endpoints. I.e., we could say that network@ and serial@ do not have
> > timestamps, while sf@ does. But this could get a little weird; it would
> mean
> > that the serial and network packet sources would need to insert NULL
> > timestamps,
>
> Well no, the network@ and serial@ packet sources would be the ones
> inserting the current time as the timestamp.
>

Can't we make this a bit more flexible using a different serial protocol ID
to indicate if a frame needs to be  stamped by the source or not? If a
normal serial AM frame arrives then there is no action, if "timestamp" frame
arrives, then the source can add/modify the stamp. This way we can support
both host stamps (the mote sends empty timestamp) or mote stamps (the PC
side only modifies the mote stamp to translate it into local time, in case
the delay over the serial line needs to be acounted for). SF side remains as
is.

Vlado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080626/7089f202/attachment.htm