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
