Can nRF51/nRF52 support 100 or more notes?

[philipyeung]

I have a wireless project. Requirements as:

• Support platforms: Desktop/Laptop and mobile, Pc/Mac/IOS/Android. etc.

• many connections: flexible but can support 100+ connections

• Response time: human response time, about 100ms

• Device Input: just 1 button press, and the platforms will recognize which device button is pressed

• PCB Size: 1cm~3cm square/circle, as small as possible

I think the design is like this: (BLE Central platform(s) )<==button press UUID info.==(BLE Peripheral device)<==button press UUID==(BLE Central button device 1, 2, 3...100...)
And targeting nRF51/nRF52 for my development.
So, my questions are:

1. Can nRF51/nRF52  support 100+ Central notes? Did anyone try out the max. number of notes in real case?
   
2. nRF52 has more Flash and RAM than nRF51. Will the Flash or RAM size affect the number of connecting notes? Like larger memory to save more UUID in bonding/mapping table.
3. Will the notes connect number affect the response time? (i.e. the time from button pressed to platform received info.). If yes, how bad will the response time be in the 100 notes case?
4. Is nRF52 rather nRF51 in my project?
5. Please give me advice if there is a better solution. (e.g. using zigbee/zwave instead; better topology design; better module other than nRF51/52. etc.)

[Joakim Jakobsen]

Hi!

With standard BLE using our Softdevice, the concurrent connections is limited to 20, so that won't work for you I guess.

I think you will have to consider using a mesh solution for your project.
Using Mesh there isn't really a real upper limit of the number of nodes in your network. The theoretical max number is  32768 nodes.

1.
Yes, if you are using Mesh, there shouldn't be a problem connecting 100+ nodes. As you can see from my comment above the theoretical max number is very high, so I don't know of anyone that has done a test using that many nodes. 

2.
Yes, the nRF52832 does offer double the amount of flash compared to the nRF51.
However, there are some data that needs to be stored for each new node stored on the provisioner, such as the device key, the node address if the provisioner want to re-configure a node. That is why we actually don't recommend to use the nRF52 as a provisioner, but instead the database should be stored on PC or mobile phone. 

3.
In a sense, yes. The number of nodes will affect the response time, depending on the distance between them and the no_of_hops.
The latency in the mesh network would be (2ms + advertising_interval) / 2 * no_of_hops.

4.
In general I would always suggest using the nRF52-series.
Note that the Mesh SDK has deprecated nRF51, so you should really consider using nRF52 for new product development.

5.
From what I can see it looks like a good fit to use Mesh for your project.

More documentation and information below:
Blog - Introducing nRF5 SDK for Mesh
Infocenter documentation - SDK for Mesh
Blog - Things you should know about Bluetooth Mesh
Blog - Provision, Configure and control Bluetooth mesh networks with nRF Mesh

Also, there is a lot of Q&Aa regarding mesh around DevZone so you might be able to find the information you need here.
If you can't find what you need, you are welcome to post a new question here on DevZone.

Best regards,
Joakim.