[Tinyos-devel] packet level time synchronization TEP

[Geoffrey Werner-Allen]

Hey Miklos:

I think you and I are in agreement here :-). My point, which seems sort of
picayune at this point was that an offset is always relative to *sometime*,
but I guess that there are other ways (out of band) that the sender and
receiver could agree on what that sometime is.  And of course the event time
and the offset or wire time have to be in the same units, but that
conversion can happen at send time; they don't have to use the same clock
source, just the output has to agree. (I.E., if my event time is in 1MHz
clock time and I sample the delay in a 1kHz clock then I have to multiple by
1024 to get a 1MHz delay.)

I'm going to work on putting together a patch against T2.1 that does the
following:

a) Move as much of the FTSP logic as possible out of the radio stack
chips/cc2420 into lib/ftsp. I'll try and defend my changes against
non-CC2420 chipsets.
b) Correct FTSP to work properly over LPL, i.e. correct the per-packet delay
over multiple transmissions. Again, this is CC2420 only, but the fix should
be easy to apply to other radio stacks.

I've tested this setup on a small network using a modified version of
TestFtsp. (Obviously once you start using LPL you can't rely on a broadcast
message to produce a single arrival time across all nodes, so my version
uses a logic pulse on one of the interrupt-capable pins brought onto the
TMote Sky header driven by a dedicated mote to create the out-of-band
synchronous "moment" needed to test FTSP.)

This requires backing out some other changes that I made but I can submit
something in the next week or so.

Best,

-gwa-

geoffrey werner-allen :: 617.694.7261 :: www.eecs.harvard.edu/~werner


On Mon, Dec 8, 2008 at 2:32 PM, Miklos Maroti <mmaroti at math.u-szeged.hu>wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20081208/fe70f224/attachment.htm