point to multipoint with UART (multilink on the S120)

[snowball]

I'm interested in using BT LE to collect data from a number of serial based devices -- a point-to-multipoint configuration. I'm familiar with the UART examples and have seen the multilink example.

The "devices" would be connected to a BT "remote" via the UART (+ level shifter etc), any serial traffic needs to be sent over the BT LE link to a single master BT device connected to a PC which can read the data (probably via the UART again).

However, I'm not 100% sure of the model, maybe it's just the terminology. In the multipoint example, there is a central (Softdevice 120) and peripheral (Softdevice 110). The central connects to the peripheral(s) to collect data, which is the opposite to how I need it to work (or is this just convention and can either end initiate the xfer?).

Finally, what are the limitations, I think the multipoint allows up to 8 simultaneous connections, can I have more "parked" connections? i.e. how many device+BTLE "remotes" combinations can I associate with a single BT LE master? (even if only 8 can communicate concurrently).

Thanks!

[Ole Morten]

First and foremost, be aware that the S120 limits the throughput of each link to one packet per connection interval, and it can hence not do 128 kbps, even with a single link.

You'll most likely also have use in reading this question, as well as nAN-36, which tries to cover some basic BLE terminology (on-air operations, data structuring in services).

There isn't really any limit to the number of bonds a Central can have apart from storage for encryption keys, but if you want to use whitelisting in the Central role, you'd be limited to 8 devices.

Edit: Considering your additional questions, you should first decide whether you want to use BLE or not. Do you for example need any of the devices to have smartphone connectivity?

If the answer to that is yes, then you should use BLE and keep the device you call "uplink" as the Central, and the "remotes" as Peripherals. If 8 remotes are sufficient, each remote can be connected to the Central by default, and transfer data as needed. If you need more than 8, you'll have to make the remotes be disconnected by default, and only start advertising to be connected when they have new data to transfer. After finishing data transfer, they'd have to disconnect to make room for new connections to the Central.

The primary reason for having it this way is that Central is a more current-intensive role than being a Peripheral, and that a Peripheral can only be connected to one Central at a time, which may be problematic for the uplink.

However, if the answer to the initial question is no, you could consider using Gazell instead of BLE. This is a proprietary radio protocol, that was initially made for wireless desktop scenarios, but that may also be useful here. In that case, the "uplink" would be what Gazell calls a Host, while the "remotes" would be Devices. Gazell supports any number of devices, as long as the data throughput of each of them is relatively low.

Gazell is explained in our online SDK documentation here.

If you don't need BLE, you could also consider building your own protocol right on top of the RADIO peripheral, but that may easily get complicated.

[Ole Morten]

Gazell is limited to 8 pipes, but you can in principle have any number of devices sending data on one pipe.

The latency for advertise/connect/disconnect will be very dependent on advertising intervals and scan window on the Central side. If you use a short advertising interval, and a scan window close to the scan interval, you should be able to achieve pretty short latencies, at the cost of higher current consumption. Take a look at section 2.1 of nAN-36.