• State Verified Answer
  • Replies 4 replies
  • Subscribers 90 subscribers
  • Views 1101 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 299202
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Is multiprotocol_802154_config.c required for Zigbee + BLE applications?

anusha_14

Hello Nordic team,

I have looked at the BLE + Zigbee multiprotocol examples from nRF5 SDK and in these examples, I see that there is a file 'multiprotocol_802154_config.c' used. I would like to know if this file is required for my application that uses BLE + Zigbee but not at the same time (protocol to be used is determined at application startup).

Regards,

Anusha

  • 0

    Hi,

    If your device is meant to be strictly either Bluetooth Low Energy or ZigBee, the config you mention is not required. However if you intend to use both throughout the devices lifetime, you will have to use the multiprotocol config.

    I understand your design to be the first of those two alternatives, so you will have to have both stacks on your application with the option to select which of the stacks you're supposed to initialize after a power cycle is done. 

    If you intend to rapidly swap between the protocols like in this hypothetical scenario: Device is ZigBee for a few minutes to join a network -> power cycle and become a BLE device for a few minutes -> power cycle back to ZigBee and to join the same network, you will also have to make sure that the network data for the protocols are not deleted when power cycling. Other challenges may occur, as a selection of which protocol to be used in the example I mentioned is not necessarily compatible with how the ZigBee network expects a ZigBee device to behave, so keep-alive mechanisms may be disrupted.

    I hope this answers your question,

    Kind regards,
    Andreas

  • 0 in reply to AHaug

    Hi A Haug,

    Thanks for the information. Based on this, I guess I don't have to use multiprotocol_config as I don't use both at the same time.

    I did not completely understand this point: Other challenges may occur, as a selection of which protocol to be used in the example I mentioned is not necessarily compatible with how the ZigBee network expects a ZigBee device to behave, so keep-alive mechanisms may be disrupted. Could you please elaborate on this?

    Thanks,

    Anusha

  • +1 in reply to anusha_14

    Hi,

    Yes, of course! I will do my best to clarify what I ment.

    In the Zigbee-stack there are routines that monitors and ensures that a Zigbee-device is healthy, alive and present in the network it has been provisioned into. These routines often has requirements such as sending messages in between the Zigbee device and routers/the controller within a given time interval. If the device leaves the network for a long enough time, it may be assumed to be broken, and or/removed from the network.

    If there are any key changes, or other routines that changes the security of the network while your device is out of the network, you will also have to provision the device that you take out of the network once more (in this case you've taken it out to change to a BLE device instead and then back again), because it can no longer join the network due to having old keys that does not work any more.

    This is just an example of what may be a challenge, but then again it will depend on your use-case.  If you intend for the device to never swap protocols or at least not power cycle more than once (from BLE to Zigbee), you should be good.

    Let me know if this clarifies anything for you!

    Kind regards,
    Andreas

  • 0 in reply to AHaug

    Hi Andreas,

    Thank you for these details. This clarifies my question. 

    Regards,

    Anusha

Related
Terms of service