[Tinyos-devel] packet level time synchronization TEP

[Geoffrey Werner-Allen]

Hi Miklos:

Replies below:

On Thu, Nov 20, 2008 at 11:12 AM, Miklos Maroti <mmaroti at math.u-szeged.hu>wrote:

> Hi Geoffrey.
>
> > a) moving metadata initailization higher so that SendNotifier can mark
> the
> > message for timestamping (and change the size)
>
> On the receiver side you cannot decide if you need to substract the
> length (that is you have an embedded timestamp) or not. What do you do
> with that?
>

OK, so I think that the argument you are making is that the current setup is

Sending application sends packet of length X
Stack adds timestamp, length becomes X + 4
Receiver receives packet of length X + 4
Receiver corrects length to be X
Receiving application expects length X, receives length X

And without a dedicated CC2420ActiveMessageP.nc pass-through you can't
correct the length?

This is a good point, but is it really necessary to change the length of
packets at all?  What is currently done is to add bytes to the end, but why
not just have the protocol stipulate that the last 4 bytes of the packet
data are overwritten? This doesn't require any length munging on the sender
and receiver and allows simpler access to the timestamp on the receiver side
(since I just declare a field for it in my message struct). It also means
that you don't have to handle the corner case where X + 4 > maximum packet
size.  Would that work?

The other solution which is more intrusive is to have an equivalent to the
SendNotifier interface on the receive side. Essentially something that sat
on the top of the receive stack and was able to munge packets before
Receive.receive() was called.  This would allow you to correct the length
without having to implement another AM pass-through.  It could also be
useful in other contexts, although I can't come up with any off of the top
of my head.

> b) providing a aboutToTransmit() interface which provides an event in the
> > SFD.captured() handler. This isn't all that beautiful though and I think
> > that *that* portion of the functionality might be best left inside the
> > stack.
>
> Yes, and that portion is very platform specific. I think it is better
> left inside the stack. With the callback approach you are going to
> have people who abuse that interface and do more lengthy calculation
> that might prevent the stack to update the message in time. In that
> case you will get corrupted timestamps without notification.


I suppose that is true, but I'm sure it's not the only interface to the
radio stack subject to abuse ;-).

Best,

-gwa-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20081206/4f3937bd/attachment.htm