Large number of BLE devices with an iPad

RE: Large number of BLE devices with an iPad

Ingolf Petersen — Mon, 10 Feb 2014 17:14:33 GMT

Hi all,

Update on the progress. We've got it very close to working. We ran into the problem of the firmware not disconnecting fast enough. We tried changing the Connection Supervision Timeout to the lowest possible value that still fullfils the constraints posed in the nordic SDK and by Apple (developer.apple.com/.../BluetoothDesignGuidelines.pdf - chapter 3.6). That didn't change anything really, the nrf51822s still thought they were connect for 5-10 seconds after the disconnection in the iPad app. To counter this we use a message from the iPad to trigger a call to sd_ble_gap_disconnect(m_conn_handle, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);

We then make our custom modules with the nrf51822s only advertise when there is new data to send and the iPad is scanning very frequently and connecting to modules that it has been told to communicate with.

We use the following values in the firmware:

#define APP_ADV_INTERVAL 32 /**< The advertising interval (in units of 0.625 ms. This value corresponds to 40 ms). */

#define MIN_CONN_INTERVAL 16 /< Minimum acceptable connection interval (7.5 ms), Connection interval uses 1.25 ms units. */ #define MAX_CONN_INTERVAL 40 /< Maximum acceptable connection interval (7.5 ms), Connection interval uses 1.25 ms units. */ #define SLAVE_LATENCY 0 /< Slave latency. */ #define CONN_SUP_TIMEOUT 400 /< Connection supervisory timeout (4 seconds), Supervision Timeout uses 10 ms units. */ #define FIRST_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(20000, APP_TIMER_PRESCALER) /< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (15 seconds). */ #define NEXT_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(5000, APP_TIMER_PRESCALER) /< Time between each call to sd_ble_gap_conn_param_update after the first (5 seconds). */ #define MAX_CONN_PARAMS_UPDATE_COUNT 3 /**< Number of attempts before giving up the connection parameter negotiation. */

We still have some tests to do to see if it's real-time viable but it's looking very good.

RE: Large number of BLE devices with an iPad

Ole Morten — Fri, 07 Feb 2014 11:54:03 GMT

This is really the Connection Supervision Timeout, that you can configure in your application. Take a look at this question for details on connection parameters: https://devzone.nordicsemi.com/index.php/what-is-connection-parameters

If you have further questions on this, I suggest to post a separate question.

RE: Large number of BLE devices with an iPad

Ingolf Petersen — Fri, 07 Feb 2014 11:52:31 GMT

Small update:

Working on it but the main problem now is that the nrf51822s sometimes take up to 5-10 seconds to notice that there's no connection after the iPad breaks it.

Is there any timeout parameter or similar that can be changed to speed the process?

RE: Large number of BLE devices with an iPad

Carles — Wed, 05 Feb 2014 18:03:30 GMT

Yes, that would be a broadcaster. You would not have bidirectional data transfer as a broadcaster, only from the peripheral to the central (i.e. from the broadcaster to the scanner) but I was suggesting this as a way to notify the iPad that new data is available so that the iPad could then subsequently connect and exchange data with the nRF51-based device

RE: Large number of BLE devices with an iPad

Ingolf Petersen — Wed, 05 Feb 2014 17:05:40 GMT

@Carles: Thanks for the info. That makes sense as it then is a Broadcaster, right?

Anyway, the peripherals also need to be able to accept data so I'm not sure that that's what I'm looking for. Maybe it is possible to use another advertisement type and encode the data from the peripherals to the advertisement packages and then only have the iPad initiate a connection to a specific device them when it needs to send data?

RE: Large number of BLE devices with an iPad

Ingolf Petersen — Wed, 05 Feb 2014 17:01:32 GMT

Don't know yet as it's not entirely up to me :)

Thanks for the info, will come in handy!

RE: Large number of BLE devices with an iPad

Carles — Wed, 05 Feb 2014 16:57:10 GMT

Please note that if you use either BLE_GAP_ADV_TYPE_ADV_SCAN_IND or BLE_GAP_ADV_TYPE_ADV_NONCONN_IND as your advertisement type, the peripheral device is not connectable, and therefore the intent to broadcast data is inherently expressed.

RE: Large number of BLE devices with an iPad

Ole Morten — Wed, 05 Feb 2014 16:39:44 GMT

One could say that the mere act of advertising is to request a connection, but you're right that a Peripheral can never actually initiate the connection. I'm looking forward to hear how your test goes! Do you intend to test both, or just the latter?

I would normally consider this to be a perfectly fine example of how BLE can be used, but if you actually have a hard real-time requirement on the link establishment, that of course complicates things.

Note that there isn't any strict relation between being a Central and GATT Client and Peripheral/GATT Server. You may have use in taking a look at this: https://devzone.nordicsemi.com/index.php/what-is-a-client-and-server-in-ble

RE: Large number of BLE devices with an iPad

Ingolf Petersen — Wed, 05 Feb 2014 16:30:22 GMT

Thanks for the reply. That's the only thing I could think of as well. I assume I will try it in the coming week and see how it works out. I'll post any updates to this thread.

It does however sound like using the BLE protocol in a way it's not meant to be used but as I understand it that's the only way to do this (apart from polling all the devices which will take way to long anyway). At least it is my understanding that a peripheral/server can never initiate or requesta a connection, that task is always left to the central/client.

RE: Large number of BLE devices with an iPad

Ole Morten — Wed, 05 Feb 2014 16:22:33 GMT

You can have custom data in the manufacturer specific data field of the advertisement packet, and when the application is in the foreground, it's possible to read this data on the iOS device, and then connect. How fast you can get this working, I'm not completely certain about, so this you'd have to test.

Another option could be to just let your devices not advertise by default, and only start advertising when they actually have data. In that way, you can (hopefully) just start initiating connections to all known devices from iOS, and once a device starts advertising, it will be connected to as fast as possible. Beware that I have never tested how many connects that an iOS device can have pending at a certain time, so it could be that there are similar limitations there, but I wouldn't really expect that.

Those two are my best initial suggestions. If anyone else have any, I'd be happy to hear them.