On Mon, Jan 19, 2009 at 4:12 PM, Razvan Musaloiu-E. <[email protected]> wrote: > Hi! > > On Mon, 19 Jan 2009, Andrey Gursky wrote: > >> Hi Razvan and Miklos! >> >> Razvan Musaloiu-E. wrote: >>> Hi! >>> >>> On Wed, 14 Jan 2009, Andrey Gursky wrote: >>> >>>> Hi Razvan! >>>> >>>> I haven't such deeply tests as Miklos. My observations on the app level: >>>> the messages are being successfully sent, but on the remote mote they >>>> are being not received. >>> >>> What does "successfully sent" mean? You got an ack back? :P >> >> You're right, there are really many NACK. But many packets, which were >> sent but not acknowledged, has being successfully received. What could >> result in this? >> > > I'm not familiar with the way the acks are implemented in RF230. On CC2420 > the reverse problem was observed: a packet was acked even if it was not > properly retrieved from the CC2420 FIFO. The solution was to use software > acks: the MCU retrieved the packet and then sends a command to CC2420 > to ask for an ack to be send.
The ack packet on the RF230 is generated in software. If the message was received, then it has passed the CRC check and then an ACK must have been generated. However, the channel might have been noisy (another message started just before the ACK packet was to be sent) so you did not see the ACK packet, You can use the RF230Sniffer application to display all packets (not just ones that pass the CRC check). With that you can see that there are lots of random messages received on channel 26 but not on channel 11. These messages do not show up in general because they do not pass the CRC check, but they are there and keep the radio busy. I think we should NOT use channel 26 for the IRIS until someone figures it our why this happens. Razvan, please revert the change. Miklos _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
