Hi Michiel, On Thu, Aug 19, 2010 at 11:31 AM, Michiel Konstapel <[email protected]>wrote:
> 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. > That is all true. What I would need is a way for the radio stack to determine if a packet is a time sync packet (containes an embedded delay value). Currently we use a special AM type, but that does not work for Ieee 802-15.4 messages. And yes, I can live with that the sender and receiver has to agree on the time unit. 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? > No. What that person wanted is to get the local time of the sender node on the receiver side. He simply set the event time to 0. When the message was transmitted, then it contained the delay since the event time, which is exactly the local time. Then on the receiver side this delay was expressed in the local time of the receiver (this is the time on the receiver of the instant when the sender's clock was zero). He then just substracted this from PacketTimeStamp, which gives the local time of the sender when the message was sent on the receiver side. Now this works perfectly if you use TMicro timers. However, if yue use TMilli, then your top 10 bits is corrupted since the delay value embedded in the message is always expressed TMicro. > 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. > > All high precision time sync values were achieved with the MCU clocks and sleeping disabled. Janos did a hybrid timer, which gives you microsecond precision but works off the external 32khz crystal. Probably that is the future for this. > > 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 :) > The IRIS does not have spare bits (unless we want to use nonstandard 802.15.4 headers). I hate to add yet another byte header, but then you would not have this embedded AM type craziness for time sync messages. For 802.15.4 we could have - time sync disabled, so no time sync messages are supported (0 byte overhead) - time sync enabled, and if the message does not use it, then we have 1 byte overhead - time sync enabled, and if the message is a time sync message, then we have 5 bytes overhead. Currently we have (0, 0, 5 bytes overhead in the above cases). Miklos 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 > > > ------------------------------ > > *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
