While implementing TEP132 <http://www.tinyos.net/tinyos-2.x/doc/html/tep132.html> and TEP133 <http://www.tinyos.net/tinyos-2.x/doc/html/tep133.html> for the gnode <http://www.sownet.nl/index.php/products/gnode> platform to support FTSP <http://docs.tinyos.net/index.php/FTSP> , I've run across some inconsistencies and I wondered what would be the best way to resolve them.
TEP133 specifies the following: The signature of the platform's ActiveMessageC [5] MUST include: provides interface TimeSyncAMSend<TMilli, uint32_t>; provides interface TimeSyncPacket<TMilli, uint32_t>; However, FTSP requires these interfaces to be present on a configuration called TimeSyncMessageC. In addition, it requires the names to have their precision appended: TimeSyncC.nc: components TimeSyncMessageC as ActiveMessageC; TimeSyncP.Send -> ActiveMessageC.TimeSyncAMSendMilli[TIMESYNC_AM_FTSP]; TimeSync32kC.nc components TimeSyncMessageC as ActiveMessageC; TimeSyncP.Send -> ActiveMessageC.TimeSyncAMSend32khz[TIMESYNC_AM_FTSP]; To both support FTSP and comply with the TEPs, I figured I'd do both: provide a TimeSyncMessageC with the appropriately named interfaces, and provide them on ActiveMessageC with the names TEP133 suggests. So far, so good. However, including them in ActiveMessageC causes another problem: I've followed the implementation for the RF230 and CC2420 platforms, which is to use an AMSenderC(AM_TIMESYNCMSG) to layer TimeSyncAMSend onto the normal ActiveMessage service. That also means wiring ActiveMessageC.Receive[AM_TIMESYNCMSG]. Unfortunately, that breaks apps/BaseStation: this wires all AM types, so AM_TIMESYNCMSG is doubly wired, which doesn't work for the buffer swapping Receive interface. My workaround so far is to provide only TEP132 (PacketTimeStamp) on ActiveMessageC, and include/wire the TimeSyncAMSend/Receive only in TimeSyncMessageC. That should work for FTSP and its test programs (they do expect PacketTimeStamp on ActiveMessageC), but it's not actually complying with TEP133. I guess the proper solution would be to make the time synchronization into a proper layer of the radio stack, so it doesn't need to claim an AM type? It might also be a good idea to update the documentation for FTSP to mention that it actually needs the TimeSyncMessageC configuration, although it's really quite obvious once you look at the source, and I suppose it's only relevant for platform developers. Kind regards, Michiel Michiel Konstapel Software Engineer SOWNet Technologies BV Delftechpark 26 2628 XH Delft The Netherlands T: +31 (0)15 26 00 44 6 F: +31 (0)15 26 00 40 5 W: www.sownet.nl <http://www.sownet.nl> ________________________________ This message is confidential and intended solely for the addressee. No rights may be derived from its contents.
<<image002.jpg>>
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
