Dear all, I'm currently working on implementing the Orinoco routing protocol (which is based on RI-MAC) for the TelosB/Tmote platform. Things work fine with one exception: packets get lost due to the following, strange behavior (I won't go into protocol details but just explain what happens):
We have 3 nodes: one receiver R and two senders A and B. Software ACKs are used. 1.) Both A and B send their packets to R (at about the same time). 2.) R only accepts one packet at a time, for which it sends an ACK. Assume R acks the packet from A (and ignores the packet from B). It sends out an ACK from R addressed to A. 3.) A receives the ACK (and correctly deletes the just sent message from its queue) 4.) B receives the ACK and usually sees that it is for A, so that B has to resend its packets. Thus far, thus fine. Now comes the problem: Sometimes node B receives an ACK that is addressed to itself, so that it falsely deletes the just sent packet from its queue. I put quite some effort into finding out what's going on here: - I installed a sniffing node to see what really is on the channel: only the ACK from R to A (no ACK from R to B!) - I added lots of printf/debug lines to the code to see what kind of packets are sent and received. I went down to the layers right above the hardware, where I saw that the "wrong ACK" really comes from the RXFIFO. I also realized that the "wrong" ACKs are actually received twice: The first time (some seconds earlier), they are correct ACKs (in a sense that they actually ack a packet reception from B to R). The second time, they come in when a different ack (the one from R to A) is expected. - I'm pretty confident that the problem is no pointer mistake - I checked the DSNs of the (software) ACKs to validate that the problem is caused by "old" ACKs (received for a second time) Since the ACK is received twice, it looks like it remains in the RXFIFO of the CC2420 and is taken from there a second time, possibly in case of buffer overflow. I logged the FIFO and FIFOP pins and realized that they usually have the values 0 and 1, respectively, whereas they always have the values 1 and 0 when the problem occurs. The question now is if it is possible that a packet from the RXFIFO is obtained a second time and how this issue could be solved. I had no success modifying the CC2420 driver myself (my attempts ended up in no change or a locked up transceive ). May be I am even missing something and the problem is somewhere else. Any help would be welcome. Kind regards and best wishes Christian _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
