Best approach for collecting data from hundreds of sensors

[gweppler]

Hello, 

I'm looking for some general guidance on the following application:

• 1 nRF52840 based gateway to cloud, on power supply
• a few hundred nRF52832 sensor nodes, all battery operated, all within reach of the GW
• sensor nodes are asleep most of the time (events wake them up, then they send data while a certain condition is met, then go back to sleep after a while).
• Updates from sensor nodes to gw are 10-15 bytes each, at intervals of 1s-30s.
• Acks from GW to nodes "required"/very nice to have but lack of acks is not necessarily a show stopper as very few lost updates wouldn't be a massive problem. Just not a perferred starting point for us. 

We have this running fine with GATT connections for up to 20 sensors until we hit the softdevice's concurrent connection limit in the GW.

Questions

1) What approaches would be best suited to scale this beyond 20 sensor nodes? We are currently considering the following options: 

a) BLE/GATT/connection based as per our status quo, but adding some logic on top that builds the lists of sensor nodes to connect to next. First tests seem to indicate the connecting/disconnecting will take a couple of seconds so this maybe to slow to reach above goals. Is there a best practice approach of how to build the scheduler on top of the 20-connections-limit so that the number of devices can increase significantly? 

b) Advertisements only / Beacon. No acks... 

c) mesh. All sensor nodes would be LPNs. All of them are within RF reach of the GW. Would this work with mesh? 

d) ESB. 

Which of these make most sense for above scenario?

2) Are there other alternatives that we should consider? 

3) Any other hints that could help us with the above?

Thanks much in advance!

gj

[Edvin]

What seems to be the varying part now? I suspect that the time from "connecting to target" until "Disconnect" is more or less the same, is that correct?

What you can try is to decrease the advertising interval, but be aware that cutting the advertising interval in half will double the current consumption. I am not sure whether it is possible to shorten it much more using BLE. If you want it quicker, you may need to use ESB, where you control all the packets, and you don't need to wait for service discovery, and all the other packets going back and forth during the establishment of the connection.

By the way, from the central, when do you enable the notifications?

[gweppler]

We found an error on our part affecting the previously reported times. Corrected measurements:

BLE UART central example started. 
Scan-Started @ 0000 ms 
Time b/n Scan@ 0000 ms 
Start Connecting. @ 0011 ms 
Connecting to target 35BD962F40DA 
ATT MTU exchange completed @  0056 ms 
Ble NUS max data length set to 0xF4(244) 
Discovery complete @  0123 ms 
Connected to device with Nordic UART Service. @  0123 ms 
Receiving data. @ 0139 ms 
Start Disconnecting. @ 0139 ms 
Disconnected. 
Scan-Started @ 0153 ms 
Time b/n Scan@ 0153 ms 
Disconnected. conn_handle: 0x0, reason: 0x16 
Disconnected at  0153 ms

Around 140 ms per cycle.

Edvin said:

I suspect that the time from "connecting to target" until "Disconnect" is more or less the same, is that correct?

yes, it is around 125 ms-127ms.

Edvin said:

What you can try is to decrease the advertising interval

We were using the minimum advertising interval (20 ms) already.

Edvin said:

By the way, from the central, when do you enable the notifications?

As per ble_app_uart_c example project in ble_nus_c_evt_handler (with BLE_NUS_C_EVT_DISCOVERY_COMPLETE event). Unchanged from original Nordic example.

[Edvin]

Ok. Then I think there is not much more you can do to reduce the time it takes from disconnected -> receive data -> disconnected. 

If this is still too long for your use case, I think you have to use ESB. 

[gweppler]

We'll look into ESB. Thank you for your support!