Connect to 21 peripherals

[Brian]

I have an application that requires talking to 21 sensors wirelessly.  The bandwidth required by each sensor is relatively small - roughly 2KB/sec.  The sensors need to talk to a host computer running Windows.  The sensors and the host computer are all relatively close to each other - all within 10 meters.  Do any Nordic devices meet these requirements?  Will any of the BLE devices support 21 peripherals?

Thanks!

[Turbo J]

Two KByte/sec is not "small" in terms of BLE. You probably need multiple radios on the host side - which windows does not support directly (at least for bluetooth). One possible solution would be using 4 nRF52832 chips in central mode connected via USB2UART chip (e.g. FT4232H).

[Brian]

Thanks for the response!  I think wi-fi may be my best bet for this situation.

[Brian]

I've been reading about Bluetooth mesh.  Is there any reason a Bluetooth mesh network of sensors would not meet these requirements?  It looks like Bluetooth 5 can support a data rate of ~1.4 Mbps, and the mesh capabilities can handle the 21 connections.  Are there other considerations to using Bluetooth mesh that I'm overlooking?  Would the nRF5 SDK for Mesh support development with these requirements?

[leonwj]

hello Brian,

As you have been reading, Bluetooth Mesh does indeed support many-to-many device communication over Bluetooth and you can have up to 32,767 uniquely addressable elements in a single mesh network. However, mesh is designed for command/control type applications where the inherent message sizes are fairly small and Bluetooth 5 data rates are not directly achievable over a mesh network. 

Bluetooth Mesh packet sizes are 15 bytes for unsegmented messages (unack'd/unreliable), however, it is also possible to send a segmented message which can consist of 12 bytes per packet (3 byte packet overhead for segmentation) with a 32 segment max, which would yield a 384 byte total message size. Obviously, segmented messages are much slower than unsegmented due to the required ack'd response from the receiver. You should also note that the mesh specification (see section 2.3.9.4 of the spec) limits any single node from sending more than 100 PDUs/packets in a 10 second window (essentially 1 message per 100 msecs).

Despite the above, all is not lost since it is possible to have concurrent mesh and standard BLE stacks in operation. So depending on your application requirements, you could potentially utilize the mesh to communicate between the devices/sensors and then utilize a BLE (v4.2 and/or v5) connection to transfer data between end-points (outside of the mesh) but obviously within radio range. Again, the specifics really depend upon your application. e.g. if you had a Nordic Soc connected (via USB) to your Windows host you could build and strip down the BLE connection(s) on demand.

Finally, if you want to stay away from the complexity of the above (and would like to remain on Nordic Socs - nrf52832/nrf52840), then you could also potentially look at the Apache MyNewt implementation. Apache MyNewt Nimble supports up to 32 concurrent connections in any combination of Central and Peripheral devices under Bluetooth 5, but obviously the resource requirements (as well as the learning curve) would be quite steep as well.

Once you've had a chance to digest the above, let us know if you have any additional questions and we can try to elaborate further.

Regards,

[David Edwin]

The specification in section 2.3.9.4 states "However, a node should not send more than 100 Network PDUs in any 10 second window". Since this is a should it is not a hard restriction as a "shall".

Additionally you can use the Instaburst feature of Nordic BTLE the can deliver larger bandwidth as compared to the BTLE Mesh 1.0.

You can open a private case to request test data for the Nordic BTLE Mesh releases with standard BTLE Mesh 1.0 and with Instaburst feature enabled to get a better understanding of the performance at this point.

[leonwj]

hello David,

Thanks for your response... Yes, I guess the hard restriction would be the previous line in the spec which details as follows: "...thereby limiting the frequency that a node can transmit messages to 24 Hz" which would essentially mean around 1 message per 41.x msecs. and aligns with Nordic's documented 24.3 msgs/s limit. Though still not enough for significant data rates over mesh.

For clarification, my understanding is that using the Instaburst feature would deem any mesh solution as non-compliant with SIG mesh, whilst using a combination of the standard mesh stack along with say Bluetooth 5 'enhanced' features outside of mesh would still be seen as compliant. Your thoughts on this would be welcome...

Finally, I'll take up your suggestion regarding the internal Instaburst test data as I'm sure there will be a clamour for that type of ''addition' to SIG mesh in the near future.

Regards,

[Brian]

Thank you for the detailed info, leonwj?  It sounds like MyNewt/NimBLE is exactly what I'm looking for.  My application is fairly simple - read a sensor and send the data every couple of msecs.  I even have the flexibility of buffering up multiple readings and sending them every 100 msecs.  On the central side, I need to read the data coming in from the 21 sensors and then send this out over some wired (possibly UART) connection to an attached Windows PC which will process the sensor data.  I'm a little concerned over your comment about the steep learning curve for MyNewt - is this from personal experience?  I've used other RTOS's, most recently FreeRTOS - is it comparable to that level of difficulty?  Is the MyNewt infrastructure difficult to use?  Are there reasons to steer away from this solution?

Thanks again for the info!