Large number of BLE devices with an iPad

[Ingolf Petersen]

Question: Can a nrf51822 acting as a server/slave message a client/master (iPad), that it has bonded with previously, to let it know that new data is available without having a link open?

Why? I want to have a lot of custom devices running nrf51822s communicate with the iPad but the iPad can only sustain 8-10 Bluetooth connections at each point in time. The link has to be able to transmit data fast in both directions.

Background I have a working system which consists of a number of custom devices, equipped with various sensors, each running equipped with a nrf51822 which communicates with an iPad via Bluetooth. The communication is 2way and has to happen as fast as possible or at least fast enough to be perceived as "instant" by the human eye. This is especially important when the devices send updates regarding measurements to the iPad.

In the current setup, the link between the devices and the iPad is kept open and works very well with up to 10 devices. However, due to limitations of the iPad, using a larger number of devices at the same time instant is impossible.

Recently a need to add more devices to the system arose. To be able to do that an architecture change is needed. That is, the connection can not be kept open to all the devices all the time. The main problem is the one stated above, how can the client know when a server has a new update when the link is not open?

My first idea was to use advertising packets to do so but I'm not sure it can be done fast enough. Ideally, I would want each peripheral device to be able to hint to the iPad that it has new data. The iPad would then initiate the connection, receive the data in question and close the connection again.

Anyone out there who can point me in the right direction? I'm having problems figuring out what's the best way to go about this or if it's possible at all.

[Ingolf Petersen]

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.