• State Not Answered
  • Replies 1 reply
  • Subscribers 74 subscribers
  • Views 341 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 331950
Options

nrf5340 + nrf7002 as multi-protocol (Wifi + BLE + Thread / Zigbee) controller solution of Linux host

Tony Cheng

I am looking for a solution of a multi-protocol controller for Linux host. 

1. Coexistence of Wifi & BLE & Thread / Zigbee 

The ble-coex / thread-coex example has the WiFi stacks on the 5340. If the WiFi stack is on the Linux host (nrf70-linux-driver), can it coexist with HCI driver / ZBOSS driver / OpenThread RCP driver on 5340?

I check the "Bluetooth LE/IEEE 802.15.4 Coexistence", it seems like the PTA unit is not bundle to the WiFi stack / HCI driver / ZBOSS driver / OpenThread RCP driver. it just works as long as the kconfig and api call is correct. Right?

2. Coexistence of Thread & Zigbee 

I know the Thread / Zigbee is not capable to coexist because they both have active RX most of the time. Can I build a FW that can switch between them? 

Maybe have both enabled in the kconfig.h, but only one of them is used (calling the enable api) at a time? 

Maybe toggle a pin on the linux host then reset the 5340, and 5340 determine which protocol to use based on the pin level when boot up?

Anything need to be care of?

3. Support of nrf70-linux-driver

Will this driver be continuously updated?

Will this driver have security update? 

May I ask how much support to our project will we have, if we use the nrf7002 + nrf70-linux-driver? We are planning to build it for some NXP platform. 

Thank you so much. 

Parents
  • 0

    Hello,

    We discussed this in my team, and it seems like this is a bit too much to ask for, given what we currently have.

    If you take WiFi out of the equation, then it is still a big ask to make the nRF53 work as a generic BLE and Zigbee or Thread device. (As you say, you can't do both Zigbee and Thread in parallel, so let us assume we only do one at the time. The challenge is that there is no built in way to determine where the serial commands should go. To the Bluetooth stack or the Zigbee/Thread. 

    Now, I haven't worked too much with WiFi and our nRF7002, but I don't think it is possible to run a generic BLE HCI device in combination with the equivalent on WiFi. 

    The closest that I can think of, is a way that you can get it to work with all protocols, but only one at the time. You would have to include a bootloader, and have the host update the firmware on the device every time you want to switch protocol. This would, however, mean that if you wanted to support all 3 (4) protocols at the same time, you would need 3 (4) nRF5340s (and the nRF7002). 

    Best regards,

    Edvin

Reply
  • 0

    Hello,

    We discussed this in my team, and it seems like this is a bit too much to ask for, given what we currently have.

    If you take WiFi out of the equation, then it is still a big ask to make the nRF53 work as a generic BLE and Zigbee or Thread device. (As you say, you can't do both Zigbee and Thread in parallel, so let us assume we only do one at the time. The challenge is that there is no built in way to determine where the serial commands should go. To the Bluetooth stack or the Zigbee/Thread. 

    Now, I haven't worked too much with WiFi and our nRF7002, but I don't think it is possible to run a generic BLE HCI device in combination with the equivalent on WiFi. 

    The closest that I can think of, is a way that you can get it to work with all protocols, but only one at the time. You would have to include a bootloader, and have the host update the firmware on the device every time you want to switch protocol. This would, however, mean that if you wanted to support all 3 (4) protocols at the same time, you would need 3 (4) nRF5340s (and the nRF7002). 

    Best regards,

    Edvin

Children
No Data
Related
Terms of service