• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 55 subscribers
  • Views 775 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

CC2652R: CCA Threshold modify

CC2652R: CCA RSSI Threshold changes not taking effect

Grant China
Prodigy 110 points
Part Number: CC2652R
Other Parts Discussed in Thread: CC2592, , LAUNCHXL-CC1352P, SMARTRFTM-STUDIO, SIMPLELINK-2-4GHZ-DESIGN-REVIEWS, LAUNCHXL-CC26X2R1

Hi there, we have a CC2652R based device that is having trouble transmitting Zigbee packets.  We’re pairing the CC2652R with a CC2592 range extender and we’re using SimpleLink CC13x2 26x2 SDK 4.20.1.04.  Our product is not running on battery power so our near field electrical noise floor is not as quiet.

We’ve got a fair bit of data suggesting that the problem is the CSMA logic.  Our antenna is quite sensitive and I suspect that even on an idle channel, the normal operating noise floor is very close to the RSSI threshold of the CSMA logic.  Since the baseline measured RSSI often exceeds the threshold, the CSMA logic times out trying to send the packets and the result is significant packet loss.

I have followed the advice in the linked thread and changed the RF_cmdIEEERx.ccaRssiThr value in mac_settings.c.  I didn’t see any change in behavior and further investigation is showing that this field is getting changed by something else in the stack later on, after initialization.

I have also tried changing the value of RF_cmdIEEERx.ccaRssiThr later on in my code then calling macSetupReceiveCmd() to try to duplicate some of the code in mac_settings.c.  While I do see that my change to RF_cmdIEEERx.ccaRssiThr is persistent, it doesn’t look like my value is actually getting sent down to the hardware.

The first and foremost question that I’ve got right now is what is the correct way to change the value of RF_cmdIEEERx.ccaRssiThr?  As I said, changing it in mac_settings.c doesn’t seem to stick.  Is there a way to read back the current value from the hardware?

By the way, I have also tried changing macMaxBE, BE and macMaxCSMABackoffs as suggested in the other thread and those values also get overwritten.  In fact, I stuck in code to change them periodically and something else in the stack is continuously overwriting my change.  Any insight into that would also be appreciated.

Regards,

Grant China

WattIQ

  • 0
    TI__Guru**** 219997 points

    Hi Grant,

    Have you evaluated your hardware's RF radio capabilities with SMARTRFTM-STUDIO?  Also, have you tried using LAUNCHXL-CC1352P (-2) or LAUNCHXL-CC26X2R1 in your environment?  In most applications it should not be necessary to modify the CSMA.  I recommend you submit your hardware design to SIMPLELINK-2-4GHZ-DESIGN-REVIEWS.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 110 points

    Hi Ryan, thanks for the response.  Our hardware team is still discussing submitting our hardware design.  In the meantime, what types of values are you looking for from SmartRF Studio?  When I start up the "Continuous RX" test on an idle Zigbee channel, I see a fairly flat line in the graph ranging from -80dBm to -86dBm, averaging roughly -84dBm.

    As mentioned, our board is not battery powered, meaning that it is normally powered from 120V AC wall power.  It would be a bad idea to attach the JTAG while the board is plugged in to AC power so I can only run SmartRF Studio when the board is solely powered by the JTAG.  It's likely that in normal operation, powered by AC wall power, there could be a bit more noise in the system and a higher noise floor in the radio.

    Also, I have instrumented our firmware to periodically print out the value of RF_cmdIEEECsma.lastRssi in the debugger console.  That value ranges from -75 to -85.  Again, this is when the board is powered by the JTAG so the noise floor might be even higher when it's plugged in to AC wall power.

    Regards,

    Grant

  • 0 in reply to Grant China
    TI__Guru**** 219997 points

    You are already aware of the RSSI threshold value locations in the code.  The default RF_cmdIEEERx.ccaRssiThr value is 0x64 so the AC wall power could be introducing a substantial amount of noise. I think it would be a good test to see if the issue appears when your board is powered only through JTAG.  

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 110 points

    Hi Ryan, I figured out how to change the value of RF_cmdIEEERx.ccaRssiThr and get it to stick.  It looks like the that field gets overwritten with the value in the rssiThreshold field of the macPibDefaults structure in the mac_cfg.c file.  The default value in mac_cfg.c is -83.  If I set that value appropriately higher than the average baseline RSSI that I see on our hardware, my transmit problem is pretty much fixed.

    I'll note that the information provided in the original thread appears to be incorrect, at least for the version fo SimpleLink that I'm using.  Changing the value of RF_cmdIEEERx.ccaRssiThr in mac_settings.c doesn't help because that value gets overwritten by something else in the stack with the value in mac_cfg.c.

    Before I mark this issue as resolved, are there any other fields in the macPibDefaults structure in mac_settings.c file that will affect radio performance and that I should be aware of?  Is there any documentation on that structure?

    Thanks,

    Grant

  • 0 in reply to Grant China
    TI__Guru**** 219997 points

    Hi Grant,

    It's good to hear that you've made progress on the RSSI threshold, thank you for providing an update.  There is no further documentation on the MAC PIB structure, you may be interested in the MAC_DEFAULT_[MIN/MAX]_BE but I do not see any other values needing further evaluation.

    Regards,
    Ryan