This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Which is currently more stable/complete/fit-for-production, BLE mesh or BLE relay (simultaneous central and peripheral roles)? Is either likely to be simpler to implement?

We are developing a system with multiple sensors that are spaced far enough apart that the furthest sensors won't be able to communicate directly with the user's device (also custom hardware), so either BLE relay or BLE mesh is necessary. We would like to shorten development time and avoid using relatively bleeding-edge technology in order to reduce problems during development and in the field. 

How do BLE mesh and simultaneous central and peripheral roles compare especially for stability, but also for ease of implementation? We noticed that all four simultaneous central/peripheral role/relay example programs in the nRF5 SDK 15 are marked as experimental, and that made us wonder if BLE mesh is preferable from stability/simplicity standpoints. 

I tried searching the Nordic DevZone and didn't see any info comparing the relative stability of multiple simultaneous BLE roles vs BLE mesh. It does seem like mesh would be simpler to develop and use mesh than a complex array of simultaneous roles. 

Parents
  • Hi,

    It is hard to point out any differences in stability between a solution based on Bluetooth Mesh and a solution based on BLE, as both SDKs are generally stable. Both SDKs are production quality and qualified with the Bluetooth SIG. The quality of the final application will mostly rely on the application specific code. As always you should test your final product in order to assure that it works as intended.

    Although the BLE Relay Example is experimental, it is built on a fully qualified BLE stack, and its individual components are in use in other non-experimental examples (heart rate and running speed examples for both peripheral and central.) The quality of the resulting application should not differ greatly whether you base it off that example or if you put together your own application by merging peripheral and central functionality.

    What to choose, between BLE and Mesh, mostly depends on your needs. What solution will demand the most development time and what solution will be the most stable depends on factors such as what functionality you need, how large your network will be, to what extent will nodes enter or leave the network, will there be multiple hops or changing topology, will third party devices be part of the network, etc. In short: To what extent can you leverage the functionality that the stack and SDK has to offer.

    Personally I find Mesh a bit more complicated than BLE, but it includes mechanisms for adding nodes to the network and configure what nodes send data to what other nodes, etc. It gets you further in creating and managing your network, and abstracts away network topology from the application. On the other hand BLE gives the highest throughput and has been around for a longer time as a technology. That means wider support among existing devices such as sensors, collectors and smartphones.

    Regards,
    Terje

Reply
  • Hi,

    It is hard to point out any differences in stability between a solution based on Bluetooth Mesh and a solution based on BLE, as both SDKs are generally stable. Both SDKs are production quality and qualified with the Bluetooth SIG. The quality of the final application will mostly rely on the application specific code. As always you should test your final product in order to assure that it works as intended.

    Although the BLE Relay Example is experimental, it is built on a fully qualified BLE stack, and its individual components are in use in other non-experimental examples (heart rate and running speed examples for both peripheral and central.) The quality of the resulting application should not differ greatly whether you base it off that example or if you put together your own application by merging peripheral and central functionality.

    What to choose, between BLE and Mesh, mostly depends on your needs. What solution will demand the most development time and what solution will be the most stable depends on factors such as what functionality you need, how large your network will be, to what extent will nodes enter or leave the network, will there be multiple hops or changing topology, will third party devices be part of the network, etc. In short: To what extent can you leverage the functionality that the stack and SDK has to offer.

    Personally I find Mesh a bit more complicated than BLE, but it includes mechanisms for adding nodes to the network and configure what nodes send data to what other nodes, etc. It gets you further in creating and managing your network, and abstracts away network topology from the application. On the other hand BLE gives the highest throughput and has been around for a longer time as a technology. That means wider support among existing devices such as sensors, collectors and smartphones.

    Regards,
    Terje

Children
No Data
Related