Hi,
I have two CC2530 radios right next to each other that are sending simple data packets between each other every 5 seconds.
I am using AUTO_ACK, AUTO_CRC, and RX_ENABLE_ON_TX.
My data packets have virtually 100% success rate reception rate. However, I only get about 80% of ACKs successfully received (meaning my data packets get unnecessarily transmitted again). I am verifying this by counting my TXACKDONE interrupts on the sender and the FIFOP interrupts (where the FIFOCNT == 6) on the receiver. The acks are getting sent and the receiver is not getting it. I have enable all RFERRM interrupts and see no errors occur on either.
Since the switching the radio from transmit to receive happens automatically in HW and the ACK send is also done in HW, I have no idea why these are getting lost (timing?).
I have even tried using ISACK to send the ACKs manually, but I still get 80% loss on my ACKs (and ~100% on data packets).
Also, I never lose two ACKs in a row, (i.e. after the second data transmission, the ACK always succeeds).
Any thoughts?
Bryce
OK. I found a fix.
I changed the MDMCTRL0.PREAMBLE_LENGTH from 4 leading zeroes to 9 leading zeros. Now I get 100% data and 100% ACKs.
Is this the right way to fix this. I could also try playing with CORR_THRESH value I suppose.
Wait, scratch that. If I move a distance away, I get many dropped packets (more than using 4 leading zeroes).
Hmm, Not sure what else to try.
Hi Bryce
This problem puzzles me.
I havenot encountered this problem when using two CC2530EM’s, are you using the TI development kit or your own HW?
Are you using CSMA-CCA? I am just thinking if this somehow can be related to mid air collisions. I am a HW engineer and not an expert on the CCA operation in ZigBee. However, if CCA is used prior to sending a package this can explain the 100% success rate when sending packages. If no CCA is performed prior to sending an acknowledgement this ACK might collide with anther transmission.
To validate this try turning other 2.4GHz devices such as WLAN and Bluetooth off and repeat your test.
If this fixes the problem changing channel is the only counter measure available.
I struggle to se how this relates to the experiment with increased preamble. However the observation might just be related to random variation in 2.4GHz traffic.
Tor-Inge
Thanks for your response. I was indeed using the CCA incorrectly.
I have fixed it now I get 100% data and acks.
How did you manage to use the manual ISACK strobe? because I am unable to use this. Maybe a code example could be very helpful.
Many thanks,
Mircea
Sorry for the delay. Unfortunately I can't post the full source, but basically after I have successfully received a packet I set the following register.
RFST = 0xE6;
This triggers an ACK to be sent.
Thanks for the reply. I will try to do that.
All the best
hello, I have a question about the ACK.
When the coordinator receives the data frame, it will wait for aTurnaroundTime(=12symbol),and then send ACK frame back to the transmitter .
And my question is whether the ACK frame need obey the CSMA-CA algorithm or the ACK frame will be sent immediately ignoring the channel is busy.
And I have another question ,when a sensor node doesnot receive an ACK after macAckWaitDuration symbols, it will retry transimte the former data frame.
And my question is whether the former data frame will obey the CSMA-CA algorithm or the former data frame will be sent immediately ignoring the channel is busy.