1) might not be necessary, if the radio stack always uses the same internal representation. In our case, the "native" clock for timestamping is the 32 kHz timer, and conversion to millis is done on demand. However, if you want to be able to exchange timestamped messages between nodes using different units, then yes, you'll have to encode the unit into the packet somehow. On the other hand, since the nodes have to agree on modulation, bit rate, packet layout, etc. anyway, having them agree on the unit of time might not be too much to ask.
2) Of course overflow is an issue with any time value, it's just harder to ignore with TMicro timers :) > I have seen people trying to use 0 as the event time since they only wanted to know when the message was transmitted Shouldn't/couldn't you just use PacketTimeStamp for that, and ignore TimeSyncAMSend altogether? 3) That's if you're using a microsecond timer, you mean? I figured that wasn't very useful, since either you lose all synchronization as soon as you sleep, or you're forced to keep the clock running. Of course, some applications might not care about the extra power that requires, if they need the extra accuracy. > 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. Sounds good - I've got some spare bits in the header, so I might do that anyway to decouple it from the AMSenderC. Not right now, though :) Michiel From: [email protected] [mailto:[email protected]] On Behalf Of Miklos Maroti Sent: woensdag 18 augustus 2010 21:15 To: Janos Sallai Cc: Michiel Konstapel; TinyOS Development; [email protected] Subject: Re: [Tinyos-devel] [Tinyos-help] FTSP, TEP132, TEP133 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 Error! Filename not specified. 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. _______________________________________________ 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-deve l
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
