This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1310: excessive repeated messages/retry even first attempted transmission is successful

Part Number: CC1310
Other Parts Discussed in Thread: ENERGYTRACE, , CC1190

Hi,

We have developed a network co-processor based on TI-15.4 stack collector/sensor example code. After putting everything together, we found a little problem. In the following test setup, there are way too many repeated messages on the receiving end.

Sending end: MSP430 + CC1310-sensor node, a message of 9 bytes is sent out periodically, with a frameID counter at the end of each message.

Receiving end: CC1310-collector node, connected to another MCU which captures the messages, analyzes the frameID counter, and decides if it is a repeat of previous message, or if a message is missing.

Among 407 messages received by receiving end over the course of 8 hours, 104 of them are repeated message, with no missing message, and RSSI range from -20dBm to -47dBm. Some of the repeated messages have slightly different RSSI value so it is unlikely that they are introduced by external MCUs. 

I assume repeated messages happens when sensor node thinks the first attempted transmission is unsuccessful. then retry up to CONFIG_MAX_RETRIES defined in config.h. Generally it is better to have repeated messages which can be filtered out on the receiving end than to miss messages. But  when 1/3 of messages is re-transmitted, sometimes twice, at near perfect transmission environment as judged by RSSI, this becomes excessive. Sensor nodes will consume more power than necessary, and there might be traffic jam once number of sensor nodes increases.

My question is,  how do we reduce those retries? Changing CONFIG_MAX_RETRIES won't help much because majority of retries happen only once. Is there a way to increase the delay to retry?

Update: both sensor and collector nodes run customized board, with external PA+LNA, and  tx power is set at max 26db, not sure if this is relevant though.

Thanks.

  • Update: on current traces captured by EnergyTrace, re-transmission happens ~30ms after first attempt. I also don't see API to change the behavior of acknowledgement, re-transmission. I guess at this point we as end users of TI-15.4 stack cannot do anything about this.

    BTW, it is too bad I cannot upload images from local computer in the new forum.

  • Update 2: the problem seems caused by some sort of defect in the customized radio hardware. When CC1310/CC13-90 launchpads were used on both sending and receiving ends, no re-transmission was found after ~150 messages. When CC1310 launchpad was used on the receiving end, and customized CC13-90 radio was used on the sending end, the re-transmission was still there but a lot less than the previous rate.

    Going forward, how shall troubleshoot and improve the customized radio hardware?

  • Hi,

    Have you measured the frequency offset on your Tx and on your Rx units ?

    You can always increase the Rx bandwidth as well just to test/debug if it helps reduce the re-transmission rate.

    Regards,

       Richard

  • Hi Richard,

    Thanks for your reply. In a more finished batch, the re-transmission rate dropped to 0 - 5/1000 messages, similar to what we saw in CC1310/CC13-90 launchpads. So this is no longer a problem.

    The main difference between the batch that we saw 30% re-transmission are: 1) Those radios use RFX1010 instead of CC1190; 2) No metal shield on top of PCB. Just curious, do you think those two difference contributed to the high re-transmission/failure of acknowledgement?

    Best,

    ZL