• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 524 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.

CC1352P: Will CC1352P/CC1352R support BLE central+Zigbee coordinator/router DMM mode?

YiKai Chen
Guru 735685 points
Part Number: CC1352P
Other Parts Discussed in Thread: CC1352R

Will CC1352P/CC1352R support BLE central+Zigbee coordinator/router DMM mode?

  • 0
    TI__Guru 58425 points
    Hi YiKai,

    The Zigbee stack will officially support the DMM starting from the next SDK. As a base line, only BLE Peripheral and Zigbee end device is available as an example.

    As for BLE Central + Zigbee coordinator/router, this would be is a tricky use case. There is nothing in the DMM preventing it while there is no specific features to ease the use case. You could however try to implement it yourself and see if you can get it to work as you want it to. I would expect better support for "coordinator type of applications" in the DMM somewhere around the first half of next year.
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Guru 735685 points
    I am asking this because RF loading of BLE central and Zigbee coordinator are much heavy than BLE Peripheral and Zigbee end device. I expect TI can give us a solid YES or NO to achieve such application with CC1352P or CC1352R.
  • 0 in reply to YiKai Chen
    TI__Guru 58425 points
    The RF loading of the BLE central + Zigbee coordinator as you say is very heavy and as I said, there is no DMM specific support for this as part of the next SDK. It is not a use case characterized by TI today and thus nothing we provide support on at this time.

    If your particular use case could be possible to some extent now or in the future SDKs is harder to day as there so many variables to take into consideration. One thing that is for sure is that you would have some degree of performance hit for both stacks.

    Could you maybe specify each side a bit more in like how many connections does the BLE central handle, what would be the connection parameters be etc.? I could try to give you a better answer based on this and could also let the designers know more about the use case you are looking at.
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Guru 735685 points
    We usually have 3 or 4 BLE peripherals connect to BLE central with connection interval set to 7.5 ms. For Zigbee, we usually have 30-40 devices (including 10-20 routers) connect to coordinator. Do you think this is feasible to make it with Cc1352P/CC1352R DMM?
  • 0 in reply to YiKai Chen
    TI__Guru 58425 points
    Hi YiKai,

    I would not expect this particular use case to work with a satisfying result. With more "relaxed" BLE connection parameters, it might be possible to some extent. There is work being done to implement functionality in the DMM to better support coordinator/router kind of applications, but as the BLE and Zigbee are sharing the same radio, you would have to count with the coordinator/router being "unresponsive" when ever the BLE stack is running.

    As for BLE Central, the minimum time between connection in our scheduler is 5 ms. This means the minimum connection interval if having 4 connections would be 20 ms.

    As for feasibility, let's look at the use case at a high level. Let's assume the "optimal scenario" where air time is the only variable (assuming 20ms connection interval) and we are only sending empty packets. An empty BLE packet would take up maybe ~0.5ms of air time, meaning the 4 connections would consume ~10% of the air time available, the rest could be used by the other stack.

    Now, we need to account for things such as radio patching and configuration when moving between different PHYs. Now this time varies a lot depending on PHY, but let's say it take 1ms (often this is faster, but better count high). Assuming the radio activity would be in line with:

    BLE Conn 1 -> Zigbee -> BLE Conn 2 -> Zigbee -> BLE Conn 3 -> Zigbee -> BLE Conn 4 -> Zigbee -> BLE Conn 1 ->...

    This means we have at least 8 PHY switches during this time, consuming ~40% of the 20 ms radio time while also not giving the Zigbee any significant time to run between connection events. In this scenario, the Zigbee stack would have ~2.5ms to run between connection events.

    Now if we also expect to have data exchange during the BLE connections, the Zigbee side would loose out on even more radio time, which means we would starve it even more.

    These numbers are on a very high level and the actual switching times etc. can in some combinations be a lot faster (this depends on if the radio need patches etc.). However, it helps showcase what adds to the limitations of the DMM. I hope what I wrote is clear, let me know if there is anything I need to clarify!
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Guru 735685 points
    @M-W, Thanks for such detail elaboration. I suppose the easy answer to my original question is negative.