Hi Guys, Dear Linh, thanks for doing all the tests for me! I have uploaded a new version of the HW ACK driver for the RF230. Phil, this should NOT affect the pending release, since this code is completely disabled by default, and this is the first time it is released.
I have found 3 issues: 1) I was working with an incorrect length field (which has been used for a counter before) to compensate, 2) I should have casted an 8-bit value to 16-bit before shifting it, 3) I have found some undocumented 8 microsecond delay on the RX path. The current code has to use floating points to properly calculate the correction. However, if you do not care too much about precision, then define RF230_HWACK_SLOPPY_TIMESTAMP to decrease the code size (and introduce up to 400 microsecond time stamping error depending on the length of the packet). Note, then even in this case I do compensate, but omit the multiplication by a 0.9216 factor which comes from the difference between the 7.28 MHz actual and 8 MHz theoretical MCU frequency. Linh, please run all of your tests as before, just to verify that it works as I thing it should. best, Miklos On Fri, Feb 12, 2010 at 5:43 PM, Miklos Maroti <[email protected]> wrote: > Hi Thomas and Linh, > >> Miklos: Do I understand the rf230 datasheet correct in that on the TX >> side, you get the IRQ once the message is sent out, > > This part is correct. > >> but on the RX side it is when the SFD is received? > > With hardware ACK you get an interrupt when the whole message has been > received and the CRC has been verified and the address is matched. You > do not get an interrupt for the SFD. > > I do try to compensate for this, but I am afraid that that that part > of the code is not called. This large 7ms error is very curious. I > still have to think about it, I will get back to you tonight. > > Miklos > >> >> 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 >> > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
