CC2652P: Does Zigbee device implement CSMA/CA before sending beacon request/beacon?

Add some background: the origin of this question is that a customer found an end device hardly sends beacon request using a certain channel(19 or 20), but the same device is normal using other channels. So the customer would like to know if it is because the end device won't send the beacon request when the channel is too noisy.

The customer has done some more tests about the issue after, and found their hardware behaved normally on channel 19 and 20 with SDK example, but badly with their own code. But I'm not sure which software configuration would cause this behavior, please kindly give your suggestion, thanks.

Best regards,

Shuyang

add:
In our project, we fixed the device on channel 19 for periodic scanning. We found that the device can send a BeaconReq once when it is powered on, and then the BeaconReq message sent by the device cannot be seen, but the debugging information shows that the device is in cycle Call the API added by the network and the return status is success.

In this case, we only modify the channel to 24, and the BeaconReq sent by the device can be periodically seen in the sniffer and it can join the network normally.

We tested it in a shielded box, and it was still the same phenomenon.

We read the CCFG configuration information of the device, and the differences are as follows (SampleDemo on the left, and our project on the right):

Hello Shuyang, Howjie,

I've spoken with Software R&D and they believe that the CSMA mechanism is utilized during Beacon Requests.  Regarding the CCFG changes, a higher DCDC_VMIN value and disabling EXT_LOAD is warranted if using the PA output.  Please consider changing accordingly and monitor whether this makes any difference inside your system.  I also recall through prior E2E posts that CSMA values have been changed in the past so please review these as they compare with the default SimpleLink demos, among any other possible MAC changes.  Is it SDK v5.20 which is being evaluated?  All Zigbee application and Z-Stack network changes are inconsequential towards this issue.

Regards,
Ryan

Our application is a sleep end device (SDK 5.20), it does not use PA.

In our project, the CCA threshold has always been the default value.

There is basically no difference from bdb start commissioning to NLME_NetworkDiscoveryRequest().

There is no new discovery in our project compared with SampleLink Demo.

The current test results are very confusing.
When there is a problem with the device, we burn the Sample Demo firmware and the device returns to normal (we can see the Beacon Req sent by the device on channel 19), and then the device is also normal after we burn our latest firmware, and the normal state will continue for a while Time, not sure at which moment, the device will have this phenomenon again. In other words, we are not sure how to reproduce the problem for this type of device.

We only found a problematic device, which behaves normally when it burns our initial version of the firmware. When we burn the latest version of the firmware, it will have problems. The problem can be reproduced stably by repeating the above process. At present, we are trying to use this device to perform a version rollback to narrow the scope of the problem.

Note: Our current tests are carried out in shielded boxes.

Thanks,

Howjie

Is the issue corrected if you power cycle or soft reset the device?  During your tests does the device ever actually join a network and do you ever factory reset instead of completely re-programming the device?  Does behavior change if you reduce the frequency of scans?  Are all hardware boards affected or does the behavior appear to differ per device?  I'll be interested to hear the results of your software version comparisons.

Regards,
Ryan

Thanks for following up Howjie, I've marked your response as the resolution but feel free to add more information to this thread as you see fit.

Regards,
Ryan

Hi Ryan,

What is the default CCA mode in Zstack?

How to modify the CCA Mode in the protocol stack? 

Is it possible to directly modify the related variables of ccaOpt in ti_radio_config.c according to the information in the TMR?

Thanks，

Howjie

HI Ryan,

After we disable "include in build" in the syscfg GUI and then configure ccaOpt, the CCA Mode still cannot be modified?

MAC_CCA_TYPE_CSMA_CA means CCA Mode 1 defined in the IEEE 802.15.4 standard?

Thanks,

Howjie

That is correct, and yes.

Regards,
Ryan

Hi Ryan,

Is there a way to check out the status of Zstackapi_bdbStartCommissioningReq through software? Such like if the scan was successful, and if the MAC association was sent, etc.

We have checked with Howjie about their PCB layout and software settings, no obvious problem was found, but the association request was still not sent out. The RF performance has also been tested with SmartRF studio and no suspicious difference was found between channel 19 and other channels. So I'm wondering if we could find more clues through software debugging, thanks.

Best regards,

Shuyang

Hi Shuyang,

As stated in the TI Z-Stack API Guide, zstackmsg_CmdIDs_BDB_NOTIFICATION will be delivered to your application through an OsalPort message after a request to perform Zstackapi_bdbStartCommissioningReq().  So you will know the bdbCommissioningStatus ( BDB_COMMISSIONING_SUCCESS, BDB_COMMISSIONING_NO_NETWORK, BDB_COMMISSIONING_TCLK_EX_FAILURE, BDB_COMMISSIONING_FORMATION_FAILURE, BDB_COMMISSIONING_FAILURE) of the current bdbCommissioningMode (BDB_COMMISSIONING_FORMATION or BDB_COMMISSIONING_NWK_STEERING).

Make sure the design has been submitted to SIMPLELINK-2-4GHZ-DESIGN-REVIEWS for review and further compare differences between this code and the default SDK examples which were earlier stated to be more reliable.

Regards,
Ryan