Ble LE multiple peripheral [nodes] communication to central device [receiver] Suggest suitable type of communication.

[rutwik.bhatta]

Hi Nordic team,

We are working on a design that includes more than 50 peripheral node devices, each capturing sensor data and sending it to a single central receiver. I’m trying to determine the most suitable BLE communication method for this topology.

1. Connection-based communication:
As far as I understand, a central device can maintain only about 10–15 simultaneous BLE connections. Because we have 50–80 node devices, this seems impractical. Please confirm if this limitation still applies.

2. Broadcast (advertising)-based communication:
If we switch to connectionless communication where each node advertises its sensor data, will this approach be reliable with 50–80 advertising devices in the same area?

Should we expect packet loss at this scale?
Any recommended parameters (intervals, channels, data length) to improve reliability?

3. ACK / delivery confirmation:
In broadcast mode, is there any way for the central receiver to acknowledge that it has received the advertisement packet?
I assume the BLE stack does not provide ACK for advertisements, but I’d like confirmation or recommended alternatives (e.g., periodic scanning response, periodic sync, or other BLE features).

Any guidance on the best BLE topology for this number of nodes would be greatly appreciated.

Thank you.

[Elfving]

Hi,

1. Connection-based communication:
As far as I understand, a central device can maintain only about 10–15 simultaneous BLE connections. Because we have 50–80 node devices, this seems impractical. Please confirm if this limitation still applies.

Well no the hard limit for our softdevice controller is 20 (and the open source zephyr one has no max), though you would typically prefer not using that many. 

2. Broadcast (advertising)-based communication:
If we switch to connectionless communication where each node advertises its sensor data, will this approach be reliable with 50–80 advertising devices in the same area?

Should we expect packet loss at this scale?
Any recommended parameters (intervals, channels, data length) to improve reliability?

I would say this depends on the amount of data sent, both how often it is sent and packet length. Packet loss should generally be expected. 

3. ACK / delivery confirmation:
In broadcast mode, is there any way for the central receiver to acknowledge that it has received the advertisement packet?
I assume the BLE stack does not provide ACK for advertisements, but I’d like confirmation or recommended alternatives (e.g., periodic scanning response, periodic sync, or other BLE features).

There are protocols that do support this, but a normal BLE broadcaster would not. Though like you say, there are alternative protocols here. How much data are you planning on sending? And how large of an area are you considering using for this? Mesh, PAwR, and ESL comes to mind.

Regards,

Elfving

[rutwik.bhatta]

Hi, I’d like to clarify my use case and requirements:

• Data Transmission Needs:
  • Approximately 11 KB of data every 5 minutes for 3–4 days.
  • Afterwards, 4 KB of data every 1 hour.

• Range Requirement:
  • Maximum range needed is around 500 meters in an open field, though there will be some obstacles.

• Power Constraints:
  • The device will be battery-operated, so low-power consumption is a key requirement.

• Network Size:
  • There will be around 50–100 nodes, all sending their data to a single receiver/base station.

I’m looking for recommendations on the best communication technology or hardware that can meet these requirements.

Thanks!

[Elfving]

What stands out to me here is the range needed. Have you done any tests on what sort of range you can get for BLE connection there given the obstacles etc?

rutwik.bhatta said:

The device will be battery-operated, so low-power consumption is a key requirement.

And that counts for all the devices? There isn't any that could be connected to mains power?

Regards,

Elfving

[rutwik.bhatta]

Elfving said:

And that counts for all the devices? There isn't any that could be connected to mains power?

Only one Receiver will be connected to the mains power mounted on specific height for receiving data from all nodes. Remaining all node devices will be battery operated. Because the node will be mounted on moving objects.

[Elfving]

I see. And for that reason, I assume the network topology will also be very "dynamic"? As all the nodes might move freely within this 500 meters field.

Do you need this data sent "live"? I understand that the nodes have 11 KB worth sending every 5 minutes, though do you need this new data every five minutes as well?

Regards,

Elfving

[rutwik.bhatta]

Elfving said:

Do you need this data sent "live"?

• Yes, we need to send this data to server.

• The node will generate new data every 5 minutes.

• After generating the data, the node attempts to send it to the receiver.

• If the node does not receive an ACK from the receiver:

  • The unsent old data will be appended to the newly generated data.

  • The combined data will be sent again during the next 5-minute cycle.

• If no data is successfully received for 1 hour, the system will mark that period as data loss.

[rutwik.bhatta]

So, we need a reliable communication protocol capable of transmitting larger data packets over long distances with very low power consumption. The protocol must support an ACK-based mechanism to ensure guaranteed delivery with no data loss. Because the module will remain in sleep mode most of the time, the on-air time and wake-up time must be minimal. The device should wake up, capture sensor data, attempt transmission, wait for an ACK, and then return to sleep. If an ACK is not received, the node should queue the data and retry during the next scheduled transmission window.

[Elfving]

I think PAwR sounds like a good idea here. I figured that I could've convinced you to go for something like BLE Mesh if that were to fit your use-case best, though it seems to me that you are rather clear on exactly how many nodes you need, etc., and that is not subject to change. In any case, the use-case you do describe here does sound similar to something that can be achieved with PAwR. Here is also more on how to get started with it.

Though the range and data (the sending etc. wouldn't work exactly the way you'd prefer it to) might still be a problem. 

Coded phy and a FEM might help with the range, but it would be best for you to test the sort of connection quality you can get in the environment in question. 

Regards,

Elfving

[rutwik.bhatta]

I have one more doubt.

As Advertiser assigns all the configuration or parameters required for communication purpose to all scanners. Means only Advertiser can advertise the data and all scanners will only give response to that advertisement. Scanners will not be able to initiate the communication by advertising.

Is there any possibility to switch the roles in runtime condition without resetting the modules.

Another doubt is that can I make multiple advertiser and single scanner type of architecture for communication?