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!

[snowball]

To answer some of my own questions:

• There appears to be a limit of 8 bonded centrals in a peripheral
• Thus the "remote" is a peripheral (server) that provides an attribute and a notification
  • Attribute for "writing" to the remote from the central
  • Notification for "reading" from the remote (serial data gets sent up to the central)
• The notion of "parking" isn't applicable to BLE (it's a BT classic concept?)
• Performance:
  • Need to use the smallest slot time of 7.5ms
  • nRF51822 can do 6 pkts per slot
  • 20 byte packets max
  • Use Notification rather than an indication (to avoid acks)
  • Can get up to 128Kbps (see https://devzone.nordicsemi.com/index.php/how-do-i-calculate-throughput-for-a-ble-link#reply-3441)

Remaining question are:

1. How many peripherals can bond to a single central?
2. What will the throughput be per peripheral if there are N of them? (e.g. 128Kbps/N?)

[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.

[snowball]

Interesting. Thanks for the links, I think I have the terminology sorted out now. BTW nAN-36 is a really interesting document!

I'm going to restate my question (see above) as an EDIT to hopefully keep this posting readable to future readers.

[snowball]

So let me restate my original question using the proper terminology:

• I have a number (>8) of "remotes", that is a nRF51822 (BLE) module talking to a "device" (e.g. a data logger) using the UART.
• I have an "uplink" which consists of another nRF51822 (BLE) module talking to a PC via a UART

I need to be able to:

a) Have the "remotes" discover the "uplink" and associate (whatever that means) b) Whenever a remote receives a data packet to log via it's UART, it wakes up on the interrupt and sends the packet to the "uplink" which then logs it into it's db and provides a short ack packet that must be routed back through the "remote" to the device c) Have the "uplink" occasionally ping the "remotes" to make sure they're still alive

Now for the remaining questions:

1. For (a), do I make the uplink actually be a peripheral advertising an "uplink-service" and have the "remotes" do the scanning and discovery?
2. It seems that for (b), the "remote" is the master as it's initiating a connection (although I could do this with a notification)
3. Can the master-client roles be reversed depending on the needs? (I need to read more deeply into nAN-36 I think)
4. How many "remotes" can a single "uplink" serve?
   • I don't think I need to whitelist anything (I know the NRF_RADIO peripheral only has 8 address slots)
   • The packets are small (20-80 bytes), any thoughts on overall performance if I had say 20 remotes?
5. Seems like the softdevices might be too limited
   • Do I have to do direct NRF_RADIO access?
   • Can I mix and match, e.g. use the softdevice to do advertisement/discovery, but use NRF_RADIO for the actual comms

[Ole Morten]

I expanded my answer somewhat to try answering your new questions. If you have any further ones, it might be better to just post them separately. :)