[Tinyos-devel] Re: time synch reference implementation

[Branislav Kusy]

> I have updated a "reference implementation" of the time sync support
> (for the IRIS platform). Plase take a look at the important files are,
> as other platforms are expected to implement these components and
> interfaces:
cool miklos, i like us having a reference implementation of
timesync/timestamping interfaces.
to move on, i ported these interfaces to cc2420 based platforms
(though only tested it on micaz platform).
i have also rewritten FTSP using these interfaces and ran a small test
(1h test with 5 motes) to verify that it works (it does with ~1
jiffy(1/32khz) avg error). the code is here:

http://tinyos.cvs.sourceforge.net/tinyos/tinyos-2.x-contrib/stanford-lgl/tos/chips/cc2420/
http://tinyos.cvs.sourceforge.net/tinyos/tinyos-2.x-contrib/stanford-lgl/libs/FTSP/
http://tinyos.cvs.sourceforge.net/tinyos/tinyos-2.x-contrib/stanford-lgl/apps/TestFTSP/

ISSUES:

1) implemented 32khz based timestamping only
  - miklos suggested TMicro and TMilli timestamping
  - i used 32khz, because SFD interrupts are connected to Timer1
capture register on micaz, which is 32khz. i'm not sure if we can
change SFD capture to a different timer - if not, perhaps TMicro
timstamping is not possible (assuming timestamping utilizes capture
registers)
  - my code can be quite easily extended to downconvert to TMilli (the
same way Miklos did for TMicro and TMilli)

2) 'SFD - message_t' association bug in CC2420 radio stack
  - it sometimes happens that a message_t is dropped, but its SFD
timestamp stays in the m_timestamp_queue(CC2420ReceiveP)
  - this messes up timestamping of all consecutive messages for some time
  - until this bug is fixed, i defined a new CC2420Receive.sfd32()
command which only sets the timestamp field of the current rx message;
if anything goes wrong here - it will only affect a single message
which can be handled in the application layer

3) renamed TimeSyncPacket interface to TimeSyncEvent
   - we had 2 interfaces PacketTimeStamp and TimeSyncPacket which was
confusing;
   - also TimeSyncEvent.getTime() is not simply accessing a field in a
packet, it does some extra work (ie. calculating event time from
time_offset and rx timestamp)

4) which component should handle PacketLastTouch.touch() event?
  - PacketLastTouch is provided by CC2420TransmitP (replaces former
RadioTimeStamping interface)
  - is required for sender-receiver timesync protocols (allows us to
change contents of a msg after SFD interrupt was detected, ie. after
the message transmission started)
  - touch() event is currently handled by TimeSyncMessageP, which
makes it very much platform specific (e.g. it uses CC2420Ram.write()
to change the packet), i don't like it

5) CC2420Packet vs TSPacket?
  - currently CC2420Packet is extended with timestamp field in
metadata (former time field)
  - timestamp should be a more generic concept - should we go with TSPacket?

6) miklos has a bug in TimeSyncSend{Milli,Micro}.send commands, the
length of the original msg (len) has to be increased by the footer
size, or the last 4 bytes of msg will be overwritten:
         call SubSend.send[id](addr, msg, len+sizeof(timesync_footer_t));

7) currently, all received and transmitted messages are timestamped
which means extra cost (cpu) for non-timesync applications, however,
only msgs sent thorough TimeSyncMessageC have a timestamp actually
embedded in the payload; i assume this is fine

please, play around and let us know if you come across any problems or
have suggestions.

cheers,
brano