Hi Guys! Janos is correct. This bridging of TimeSync messages to a single AM type was a bad idea. It was not obvious at that time, but now I see several issues with this:
1) The radio stack (TimeSyncMessageC) does not know on the receiver side how to decode the received message. The message only contains an int32_t delay value (the time difference between an event time and transmission time) expressed in microseconds. However, it does not know what units the receiver wants to use. Currently, this final transformation of the delay value into a TMilli or T32khz timestamp is performed when the user calls TimeSyncPacket<precision>.eventTime. The solution would be to have several time resolutions: e.g. TMilli, T32khz and TMicro and this info is also embedded into the timesync message (as an extra byte). 2) The original code always used TMicro for the delay, which resulted in strange overflows if the user was not careful and does not understand how the code works. For example, I have seen people trying to use 0 as the event time since they only wanted to know when the message was transmitted. However, this will work only for TMicro timesync messages, and not for TMilli, because the offset is always expressed in TMicro. With this embedded type this problem would also be fixed. 3) If the receiver does not immediately calls the TimeSyncPacket.eventTime command (e.g. it sleeps with a timer), then the calculated event time is going to be incorrect. Even if the user does not sleeps, but waits a little longer, then the precision of the event time is going to go down. 4) As Michiel pointed out (and Janos had run into this previously) the Basestation code cannot work with time sync messages since that AM type is double wired, and the stack does not know how to decode the message. Ideally, I could use a stock BaseStation and all time sync messages would be automatically decoded and the timestamp field would contain the event time (and not the delay). 5) TimeSync cannot be used with Ieee154MessageC, since it relies on a specific AM id. I think we have to have a compile time define to turn on timesync (just like we turn on low power listening) and this would always add an extra byte (only 2 bits are needed) which would support 00=no, 01=TMilli, 10=T32khz and 11=TMicro timesync messages. End we can have the extra 4-byte embedded delay when we need it. Miklos On Wed, Aug 18, 2010 at 7:45 PM, Janos Sallai <[email protected]>wrote: > Michiel, > > Your observations are correct. The AM over AM implementation of > TimeSyncMessageC essentially breaks bridging, because AM_TIMESYNCMSG would > be doubly wired: ActiveMessageC.Snoop is also signaling the receive event > for messages with AM type AM_TIMESYNCMSG. > > There are two solutions that I know would work (without breaking FTSP or > CTP/AMSender): > - ActiveMessageC over TimeSyncMessageC: All messages are timestamped. Of > course, this trims the payload by 4 bytes, because timestamps will be there > even if they are not needed. > - A flag in the message header to allow for the radio stack to decide if > the message needs timestamping. This requires changes to the current > message_t. > > I am cc-ing tinyos-devel, since there is an ongoing discussion there about > revamping message_t. > > Janos > > > On Wed, Aug 18, 2010 at 4:21 AM, Michiel Konstapel > <[email protected]>wrote: > >> 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 >> >> >> >> >> >> [image: SOWNet logo 200x54.jpg] >> >> * * >> >> *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 >> >> >> ------------------------------ >> >> *This message is confidential and intended solely for the addressee.* *No >> rights may be derived from its contents.* >> >> >> >> _______________________________________________ >> Tinyos-help mailing list >> [email protected] >> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >> > > > _______________________________________________ > Tinyos-devel mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel > >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
