Is it feasible to run both matter and SIG mesh on the same chip? Are there any corresponding examples?Assessment of Memory and Resources?
Is it feasible to run both matter and SIG mesh on the same chip? Are there any corresponding examples?Assessment of Memory and Resources?
Hi,
Are there any corresponding examples?
I am afraid we do not have any multiprotocol samples demonstrating concurrent use of Matter and Bluetooth Mesh.
Is it feasible to run both matter and SIG mesh on the same chip?
Feasibility depends on the type of Matter / Mesh devices, as well as the memory requirements of the application.
Typical Bluetooth Mesh nodes must be in RX most of the time, in order to relay or receive messages. Time spent for Matter will impact negatively the ability of the Bluetooth Mesh node to receive mesh messages. Likewise, there might be degradation of Matter communication if a lot of radio time is spent for Bluetooth Mesh.
In Bluetooth Mesh, there are also Low Power Nodes (LPN), which do not have the same RX requirements as other nodes. LPN nodes rely on a Friend node for receiving messages (but send messages directly.) Please note that the required Friend node does have the requirement of being in RX for most of the time.
In Matter over Thread, there are Sleepy End Devivces (SED), with similar characteristics.
In other words, if your device is a Bluetooth Mesh LPN and/or Matter Thread SED, it may be possible to combine the two without too much impact.
Assessment of Memory and Resources?
Memory is a concern, as both protocols may be demanding in terms of both non-volatile memory (RRAM on the nRF54L15) and RAM. Typical ballpark figures might reach around 1 MB NVM (of the 1.5 MB of RRAM) and 200 kB of RAM (of the 256 kB available), for the functionality of the two protocols combined. The number however depends on the type of device and the ballpark number is for basic functionality. I encourage you to have a look at the samples (for Bluetooth Mesh and Matter separately) to get an idea of the memory requirements. For a baseline roughly corresponding to common functionality you can use a basic sample without use of any wireless protocols, such as the Zephyr project blinky sample.
Please note that Matter can run over both Thread and Zigbee, and numbers may vary depending on the underlying stack. See Matter integration in the nRF Connect SDK.
For information on concurrent Thread/Zigbee (Matter) and e.g. BLE, see Multiprotocol support.
Regards,
Terje
Hi,
Are there any corresponding examples?
I am afraid we do not have any multiprotocol samples demonstrating concurrent use of Matter and Bluetooth Mesh.
Is it feasible to run both matter and SIG mesh on the same chip?
Feasibility depends on the type of Matter / Mesh devices, as well as the memory requirements of the application.
Typical Bluetooth Mesh nodes must be in RX most of the time, in order to relay or receive messages. Time spent for Matter will impact negatively the ability of the Bluetooth Mesh node to receive mesh messages. Likewise, there might be degradation of Matter communication if a lot of radio time is spent for Bluetooth Mesh.
In Bluetooth Mesh, there are also Low Power Nodes (LPN), which do not have the same RX requirements as other nodes. LPN nodes rely on a Friend node for receiving messages (but send messages directly.) Please note that the required Friend node does have the requirement of being in RX for most of the time.
In Matter over Thread, there are Sleepy End Devivces (SED), with similar characteristics.
In other words, if your device is a Bluetooth Mesh LPN and/or Matter Thread SED, it may be possible to combine the two without too much impact.
Assessment of Memory and Resources?
Memory is a concern, as both protocols may be demanding in terms of both non-volatile memory (RRAM on the nRF54L15) and RAM. Typical ballpark figures might reach around 1 MB NVM (of the 1.5 MB of RRAM) and 200 kB of RAM (of the 256 kB available), for the functionality of the two protocols combined. The number however depends on the type of device and the ballpark number is for basic functionality. I encourage you to have a look at the samples (for Bluetooth Mesh and Matter separately) to get an idea of the memory requirements. For a baseline roughly corresponding to common functionality you can use a basic sample without use of any wireless protocols, such as the Zephyr project blinky sample.
Please note that Matter can run over both Thread and Zigbee, and numbers may vary depending on the underlying stack. See Matter integration in the nRF Connect SDK.
For information on concurrent Thread/Zigbee (Matter) and e.g. BLE, see Multiprotocol support.
Regards,
Terje
Thank you very much for your answers. The device is neither a Bluetooth Mesh Low Power Node (LPN) nor a Matter over Thread Sleepy End Device (SED).
1.Is it feasible to use a hardware DIP switch setting to toggle the chip's core protocol stack between Matter over Thread mode and Bluetooth Mesh mode?
2.During the device commissioning process, can the unused protocol stack be automatically disabled based on the specific commissioning method chosen (e.g., disabling the Bluetooth Mesh stack if Thread commissioning is selected)?
We appreciate your insights on the feasibility of these implementations.
Hi,
My previous answer was for if you wanted to run the two concurrently. I understand now that you want to use only one of them at a time.
It should be able to initialize, or enable, only one stack at a time, yes. For instance on basis of a DIP switch, or even a pure software solution (by storing information about what stack to run in NVM.) For instance, store which stack has provisioning or commisioning, and use that one. (But ideally you have a user friendly way to reset, for the user to change stack.)
Please note that you cannot necessarily then switch between the stacks at runtime, depending on the solution, so you may have to reset in order then to initialize the other stack.
The NVM requirements would still apply, but if you only initialize one stack then you do not need RAM for the other. There will also be no conflicts for radio time, which means whichever stack is running can run without trouble.
Regards,
Terje
