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.

CC2674R10: Switching from BLE to Zigbee at runtime without effect on the other stack

Part Number: CC2674R10

Hi, 

Here is my use-case :

- I want to use the CC2674R10 in BLE only and then switch to Zigbee only in runtime. 

- Once in Zigbee, I don't want the BLE stack / radio to have any impact on Zigbee and vice versa. 

Questions : 

- Is there a way (API?) to start & stop the BLE or Zigbee stack ? 

- If no, should DMM be used by setting BLE / Zigbee in block mode ? 

"A blocked stack will still be able to schedule commands and the current policy and GPT will be used to make scheduling decisions. This means that while a stack might have a blocking constraint set, it could still impact radio access for the other stack. This would happen in case the blocked stack’s radio commands is scheduled into the future (more then a few ms) while also being considered to be of higher priority."

- Is there a known settings (policy table, GPT..) where we will be sure that BLE does not impact ZIgbee when blocked and Zigbee won't impact BLE when blocked ? 

Regards,

Geoffrey

  • Hi Geoffrey,

    I do not recommend completely starting/stopping two independent radio stack without the intervention of DMM.  You can review Block Mode from the DMM User's Guide and use DMMPolicy_setBlockModeOn as described in the DMM Runtime APIs to effectively block a stack from operating.  You should update the Application/Stack States (DMMPolicy_updateApplicationState/DMMPolicy_updateStackState) such that the active Priority table selects the correct weights to accommodate your desired operation.  It should not be necessary to change the default Zigbee/BLE GPTs to accomplish your requirements.  You can review the DMM SLAs for more use-cases and information.

    Regards,
    Ryan