[Tinyos-devel] packet level time synchronization TEP

[Miklos Maroti]

Hi Geoffrey,

>> 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?

That is corect.

> 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?

Yes, that would work without a problem. However you will not get a
timestamp in those 4 bytes, only a time offset in microsecond, the
actual time stamp is the packet receive time + this time offset which
is usually in different units. So this would solve the +4 byte problem
but would not simplify the getting the time offset part.

> 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.

I think it would be best to somehow register a set of AM types with
the SendNotifier and ReveiceNotifier interfaces, and move all extra
parameters into these. This could remove most of the metadata too (e.g
LPL duty cycle, etc.).

Miklos