Pretty interesting. Miklos: Do I understand the rf230 datasheet correct in that on the TX side, you get the IRQ once the message is sent out, but on the RX side it is when the SFD is received?
Thomas On Fri, Feb 12, 2010 at 4:59 AM, HL truong <[email protected]> wrote: > Hi Miklos, > > Thanks for your prompt reaction. We built the following setup to perform the > measurements you asked for: > > We had 9 Iris motes, each attached to an MIB520 with the pin F6 connected to > a dedicated channel on the HP 16702A logic analyzer. If I understoods the > specifications correctly, the HP 16702A has a maximum time error of 8ns. As > it can store only 512k samples, we set the sampling interval to 1us (as per > your request) and thus could measure 5 transitions in one data acquisition > step. In order to use our measurement setup we had to slightly modify your > code to toggle Pin F6 (available on the JTAG head on the MIB520) and to > synchronize the states across all nodes (makes it easier to read the > output). The modified code is attached. Node 0 was the sender, and nodes 1 - > 8 were the receivers. > > Measurement results: summary > There was almost no synchronization error for the purely software > acknowledgment case (would need more data to give a statistically meaningful > answer). If the sender was using hw and the receivers sw acks, there was a > small error (~10us) that seems to be independent on the message size. In the > remaining cases we had a significant offset: ~7.5ms for 30 bytes, and ~5.2ms > for 100 bytes. So the problem seems to be located at the receiver and the > time offset dependent on the message size. > > Measurement results: data > Each line corresponds to a transition. The eight columns correspond to the > eight receiving nodes. The values are the time offset of the transition with > respect to the sender. The values in parentheses are the minimum, maximum > offsets, and the maximum difference among all the receiving nodes for this > transition. > > ** sw -> sw, 30 bytes > -1 -1 -2 -2 -3 -2 -1 -2 (-3, -1, 2) > 0 -1 0 0 -1 -1 -1 0 (-1, 0, 1) > 1 0 0 0 1 -1 0 -1 (-1, 1, 2) > 1 0 0 0 1 0 1 1 (0, 1, 1) > 0 -1 0 0 0 0 0 0 (-1, 0, 1) > > ** sw -> sw, 100 bytes > 1 0 1 0 0 0 0 0 ( 0, 1, 1) > -1 -1 0 0 -1 0 0 -1 ( -1, 0, 1) > -1 -1 -1 -3 -3 -2 -1 -1 ( -3, -1, 2) > -2 -2 -2 -2 -1 -2 -2 -2 ( -2, -1, 1) > 0 0 1 -1 -1 0 -1 1 ( -1, 1, 2) > > ** hw -> hw, 30 bytes > -7470 -7470 -7471 -7470 -7471 -7469 -7469 -7470 (-7471, -7469, 2) > -7469 -7470 -7469 -7470 -7469 -7470 -7470 -7469 (-7470, -7469, 1) > -7469 -7469 -7469 -7469 -7469 -7468 -7468 -7469 (-7469, -7468, 1) > -7469 -7468 -7469 -7469 -7469 -7469 -7469 -7468 (-7469, -7468, 1) > -7470 -7470 -7470 -7469 -7469 -7469 -7470 -7469 (-7470, -7469, 1) > > ** hw -> hw, 100 bytes > -5228 -5229 -5228 -5229 -5228 -5228 -5228 -5228 (-5229, -5228, 1) > -5229 -5228 -5228 -5229 -5228 -5228 -5229 -5229 (-5229, -5228, 1) > -5227 -5228 -5227 -5228 -5228 -5229 -5227 -5229 (-5229, -5227, 2) > -5229 -5227 -5227 -5228 -5228 -5229 -5227 -5227 (-5229, -5227, 2) > -5228 -5230 -5228 -5229 -5229 -5229 -5229 -5229 (-5230, -5228, 2) > > ** sw -> hw, 30 bytes > -7481 -7481 -7481 -7481 -7480 -7481 -7481 -7481 (-7481, -7480, 1) > -7481 -7482 -7480 -7479 -7481 -7481 -7480 -7481 (-7482, -7479, 3) > -7482 -7482 -7482 -7481 -7481 -7481 -7482 -7482 (-7482, -7481, 1) > -7482 -7481 -7481 -7481 -7481 -7481 -7482 -7481 (-7482, -7481, 1) > -7482 -7480 -7481 -7480 -7480 -7481 -7481 -7480 (-7482, -7480, 2) > > ** sw -> hw, 100 bytes > -5241 -5241 -5242 -5242 -5242 -5243 -5241 -5241 (-5243, -5241, 2) > -5241 -5241 -5242 -5242 -5241 -5241 -5241 -5241 (-5242, -5241, 1) > -5240 -5240 -5242 -5242 -5241 -5240 -5241 -5241 (-5242, -5240, 2) > -5243 -5241 -5243 -5242 -5242 -5242 -5243 -5242 (-5243, -5241, 2) > -5241 -5240 -5240 -5242 -5242 -5241 -5242 -5242 (-5242, -5240, 2) > > ** hw -> sw, 30 bytes > 12 10 12 12 9 11 11 11 ( 9, 12, 3) > 11 12 10 11 12 11 12 12 ( 10, 12, 2) > 11 10 10 10 11 11 9 10 ( 9, 11, 2) > 10 10 10 9 9 9 10 9 ( 9, 10, 1) > 11 9 10 11 11 11 10 11 ( 9, 11, 2) > > ** hw -> sw, 100 bytes > 11 11 12 11 13 11 12 12 ( 11, 13, 2) > 11 11 10 11 10 12 10 11 ( 10, 12, 2) > 12 12 10 12 11 11 12 10 ( 10, 12, 2) > 11 12 11 12 12 10 11 12 ( 10, 12, 2) > 13 12 12 12 11 12 12 11 ( 11, 13, 2) > > Hope that is of help. > > Regards, > *Linh > > > On Thu, Feb 11, 2010 at 11:09 PM, Miklos Maroti <[email protected]> > wrote: >> >> Hi Linh, >> >> I do not know the cause of the problem. I took special steps to >> correct the time stamps since the interrupts are signaled at different >> times, and the delays depend on the payload length. I try to correct >> for these, but apparently it does not work. I would like to ask you to >> do a few tests for me, to get answers to these questions: >> >> 1) does the delay depend on the payload length >> 2) is it time stamping or time sync related >> 3) is the problem on the sender or receiver side >> >> I have wrote a new test program (completely untested, it compiles), >> which should be much more careful about the measurement. Node 0 sends >> full messages at every 100 milliseconds, node 1 receives them. When >> sendDone is signaled for node 0, then we start an asynchronous timer >> to toggle LED 0 exactly after 30000 microseconds from the time when >> the SFD field of the payload was transmitted over the air (as recorded >> in the time stamp field of the message). On the receiver side, when >> receive is signaled for node 1, then we do the same, we toggle LED 1 >> exactly after 30000 microseconds from the time stamp recorded in the >> received message. These two LEDs should blink exactly at the same >> time. Please download the code from: >> >> >> http://szte-wsn.cvs.sourceforge.net/viewvc/szte-wsn/tinyos/apps/TestTimeSync/ >> >> Please do the following tests (I have no IRIS at home and does not >> have an oscilloscope) >> >> 1) Use software ACK and check that the program works. I am sure that >> there is some bias in this case as well, and I would like to know the >> exact time stamping error. Please use different payload sizes, but >> this should not affect the error value. I would like to know the delay >> between the two signals in mirco seconds if possible. >> >> 2) Use hardware ACK on both nodes, and run a test with 30 and 100 >> payload sizes. I would like to know the errors for both. >> >> 3) Use software ACK for the sender, and hardware ACK for the receiver, >> and do the same tests with the two payload sizes. >> >> 4) Use hardware ACK for the sender and software ACK on the receiver, >> and do the same tests with the two payload sizes. >> >> Thanks, >> Miklos >> >> On Thu, Feb 11, 2010 at 8:27 AM, HL truong <[email protected]> wrote: >> > We have discovered a time-synchronization bug in the TinyOS code. The >> > error >> > can be reproduced with the attached code. >> > >> > Bug description: >> > >> > On the XBow IRIS platform, when hardware acknowledgements are enabled, >> > the >> > node receiving a time synchronization message will in fact receive the >> > time >> > stamp with a value corresponding to t - 7ms (so there is a constant -7ms >> > time shift). This bug has been observed with the most recent CVS tinyos >> > version. >> > >> > Reproduction: >> > >> > The attached code will make a mote with NodeID 0 the synchronization >> > master >> > node, and a mote with NodeID 1 the slave node. The master node will send >> > every 10s a time synchronization code. Both the master and the slave >> > nodes >> > will enable PortF6 (Pin 3 on the JTag header of the MIB520, Pin 10 being >> > the >> > ground) for about 10ms each cycle. These pins can then be used on an >> > oscilloscope or logic analyzer to measure the synchronization error. >> > When >> > hardware acks are enabled, the synchronization error is -7ms (plus >> > noise); >> > when hardware acks are disabled, the synchronization error is 0ms (plus >> > noise). >> > >> > Any idea on how to fix that bug is very appreciated. >> > >> > *Linh >> > >> > _______________________________________________ >> > Tinyos-help mailing list >> > [email protected] >> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >> > > > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
