[Tinyos-devel] packet level time synchronization TEP

[Miklos Maroti]

Hi Geoffrey,

>> The wireTime would be the wire time of the sender, not the receiver,
>> so to make this
>> usable the protocol need to include the eventTime (also in the sender
>> time frame) as well.
>
> True, but my point was that you are already sort of doing this. FTSP, for
> example, includes an event time in the form of the FTSP global timestamp.
> Other protocols may include a different event time, but an offset alone
> isn't useful because it's just a measure of the time between when the packet
> hit the wire and ... when?

Sure, FTSP does something, but the point was that it could be
implemented with this new interface. We want to provide a primitive,
the least amount of functionality that is useful. For example, with a
timesync integrated converegecast (elapsed time on arrival article)
does not need another field. Your extra 4 bytes might help you
conceptually, but it would not be a) easier to implement, b) give more
functionality.

>> That would be all two, no? The receiver side does not know that this
>> is a time stamped message, so the receiveTime cannot be stored in the
>> message, only in the metadata. Anyways, that is 4 bytes for each and
>> again they might be in different time scales! You can think of an IRIS
>> mote using a 32KHz clock to mark an event (eventTime) then send that
>> to a Telos (wire time offset is in microseconds) to arrive to a
>> milisecond time stamp.
>
> Sorry, right: the receive time is in the metadata, where it should be (i.e.
> not taking up valuable packet space since it is never transmitted).
>
> As far as them being in different time scales, I'm not sure exactly why this
> is an issue. Can we just require that the event time and wire time be
> measured by the same clock? In order to make the offset meaningful you're

No, you do not want to assume to use the same clock source. Think of
FTSP running on a 1 KHz timer + some very time sensitive (1
microsecond) timesync integrated convergecast (e.g. the shooter
localization application), then you need 1 microsec precision packet
level time synchronization. Note, that you do not want to use
different resolution for the packet level time synchronization,
because that would require extra fields to describe the precision.

> going to have to convert it anyway, so alternatively, if you want to use
> different clocks you could just sent the wire time (or event time) converted
> into the time frame of the event time (or wire time).
>
> I'm also not sure I understand your example above. In terms of the three
> time stamps associated with the message, we have:
>
> event time: measured in the sender's frame of reference
> wire time: measured in the sender's f.o.r.
> receive time: measured in the receiver's f.o.r.
>
> To get event time in the receiver's f.o.r. I take receive time (which is
> supposed to line up with wire time, yes) - (wire time - event time).  So in
> your example, if the IRIS mote stamps the event with a 32khz timer it can
> either a) stamp the wire time with the same timer, b) stamp the wire time
> with a different time and then convert to a 32khz timestamp or c) stamp the
> wire time with a different time and then convert to a 32khz offset. But (c)
> implies (b), yes, which is my point: the two are essentially equivalent.

The message contains only the time offset, which is wire_time -
event_time both converted to 1 MHz ticks. Ok, (b) and (c) are
equivalent. What does it prove? Note, you HAVE to convert to convert
the offset to the time scales. A Mica2 might have 980 Khz timer which
approximates the 1Mhz CPU time, so if you really want to be precise
you have to convert (this is caused by 7.32 MHz and 8 MHz crystals
driving the mote).

>> The LPL layer would just query this new PacketInfo interface: uint16_t
>> PacketInfo.getLPLdutyCycle(message_t *msg)
>> whenever it needs that info. There is no need to maintain this in RAM,
>> it can always be called when needed.
>
> Ahh... OK, I get it. This is a neat idea!

Yeah, I think that is the future, but this is another discussion worth
asking the other developers for their opinion.

Miklos