Hi All, Thanks to all who replied.
I haven't found the error yet, but I do have some insights that might help. 1. I'm pretty sure that there are no issues with the code from ActiveMessage below. 2. When comes to FTSP, there is this part of the code in TinySyncP which probably introduces some errors. a) addNewEntry() the main problem here is that we mix multiple types which of course might introduce some errors. Multiple variable types also make the code harder to debug 3. My big concern is related to int TimeError variable. Should this really be int, instead of int32_t ? Note that when you do sizeof(int) you get 2, whereas sizeof(int32t) is 4. Given the multiplication / addition done in GlobalTime.local2Global we should use int32_t, in fact it expects to get int32_t but we pass a pointer to int (the timeError)? Thanks, Marcin Btw, I've noticed that one of my emails went to private email reply instead of reply-to-all (including the list) so below I paste the comment regarding the possibility of the problem at SFD capture event. The timestamp field from the timesync_footer_t does not store the global time, but only the time delay it took that packet to go through CSMA/CA + time it takes to load the packet into radio's buffer. Note that since from this time (happen at moment t1) we subtract time t2 (from future) occurring when SFD is captured, this time difference is a negative value. On the receiver side, the msg->localTime is actually the timesync_footer->timestamp - the (negative) time it takes sender to get through all the MAC's layers + the time when the packet was received (using local time with respect to receiver). So ignoring the packet propagation delay, at the receiver the msg->localTime is the time when the packet was send by the sender's FTSP according to the receiver's local time. At this moment we have two time values time_at_sender_when_sender_sent (msg->globalTime) and time_at_receiver_when_sender_sent (msg->localTime). Think of this as both of the fields store occurrence of the same event: one following local clock and the other following the global clock. Now, if we convert the local timestamp to the global time, we can observe how bad is the receiver's local2Global time conversion by comparing to msg->globalTime. This conversion seems to be problematic. Regarding the SFD time-stamping, I think that the time conversion to 32bit is done correctly, although this computation might be actually redundant, because when uint16_t time is converted to uint32_t time32, the time32 is always (at least in all my experiments) equivalent to LocalTime.get() - 1 Concluding, there are no issues with the flow of the algorithm and as far as I have tested the code, there are no implementation issues across the layers of AM (including CC2420TransmitP). On Tue, Sep 25, 2012 at 4:28 AM, LoveYou <[email protected]> wrote: > Dear Marcin, > > Your explanation help me understood more how FTSP implementation works. > Thank your about this. As your explanation, at the receiver, we get two > time values: > msg->globalTime = time_at_sender_when_sender_sent (Call > TimeSyncAMSend.send) > msg->localTime = time_at_receiver_when_sender_sent (by calling > TimeSyncPacket.eventTime(msg)) > so we get timeOffset = msg->globalTime - msg->localTime; > And we expect that timeOffset does not vary much for each packet. However, > I observed that the timeOffset value is very abnormal, it changes time to > time. Moreover, value of msg->localTime does not correspond to the time of > the event in receiver's local clock (I get receiver's local clock by > calling GlobalTime.getLocalTime() to compare with). That is the reason why > we get the large timeError value in addNewEntry function > > timeError = msg->localTime; > call GlobalTime.local2Global((uint32_t*)(&timeError)); > timeError -= msg->globalTime; > > I'm trying to test many time but FTSP can't work. How about your result? > Could you print out the log file including the msg->localTime, > msg->globalTime, timeError, etc for comparasion? > Thank you very much! > > Best regards, > Han Bin > > >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
