Michael Collett wrote:
> Hi,
>
> I'm planning on setting up an investigation into clock drift as follows:
>
> *Connect two MicaZ nodes via MIB510s to a laptop's serial ports (am
getting a twin serial port adapter)
> *Node A transmits its clock value to node B. Node B then logs it's
clock value when the message arrived
> *Node B then sends the value of the two clocks (A,B) over the serial
port to the laptop
it's a little tricky to log the time of arrival of a message. if you
simply read your clock in the receive() event, you'll get relatively
large non-deterministic errors (receive event is signaled from a task).
what you want to do is to read the clock at the moment when the message
was received. a capture register on CC2420's SFD interrupt does this for
you and it can be accessed through the metadata of tos messages ( call
CC2420PacketBody.getMetadata( p_msg )->time ).
logging the transmission time requires similar trick (due to the MAC
backoff, you'd see much larger errors here than in the receive case). i
just looked at the CC2420TransmitP.nc file and you should be able to
wire your application to the CC2420TransmitC.RadioTimeStamping interface
to get transmittedSFD(time, p_msg) events.
> *They swap roles and repeat.
> *The incoming data will be timestamped by the laptop and used to look
at potential synchronisation techniques/evaluation.
i wouldn't worry about timestamping by the laptop - you'd just introduce
an additional source of error in your timestamping sequence (besides,
it's much harder to get close to the hardware layer on the PCs than on
the motes, so your timestamping error would be large). and you don't
need this at all: say you have a node periodically transmitting messages
and one receiver. both of the motes record and report timestamps (t_i
and r_i for the i-th message):
msg1: t1,r1
msg2: t2,r2
msg2: t3,r3
...
then you can look at (r2-r1)/(t2-t1),(r3-r2)/(t3-t2), ... or
something similar.
one problem that you'll have to resolve is that the timestamp is
currently 16 bits, which overflows in about 2 seconds.
alternatively, you can use 1 transmitter and 2 receivers (p,q), and look
only at the receive timestamps:
msg1: p1,q1
msg2: q2,p2
...
this would remove any errors involved in timestamping on the sender side.
also, in any of these experiments you don't need to use multiple serial
cables - just use TOSBase.
>
> I'm not sure about the issue of timestamping and what variable
latency will be introduced by the radio. Can people give me some hints
and recommendations for this, as well as any suggestions to improve my plan?
SFD interrupt is very accurate (sub-microsecond) which is far better
than the resolution of the clock (i believe the capture register uses
32kHz clock).
> Does anyone know of applications already available that I can draw from?
this should be actually simple to implement. use tinyos2 because tinyos1
implementation of timestamping had a bug (it could timestamp wrong
messages).
brano
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
