Are you using your own ack frames or the defaulf 802.15.4 ack frames because as far as I know there is no dest field in the ack frame of 802.15.4, so there are possibilities of messing up with acks. See the data sheet of CC2420 for more details and CTP neo paper from Omparkash, this problem has been mentioned there in a minor details.
On Tue, Sep 3, 2013 at 3:40 PM, Thomas Schmid <[email protected]>wrote: > Christian, > > Try to use the cc2420x driver and see if the problem persists. > On Sep 3, 2013 6:03 AM, "Christian Renner" <[email protected]> > wrote: > >> >> 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 >> > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > -- Wasif Masood
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
