This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Large number of BLE devices with an iPad

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.

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

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

  • 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

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

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

    Thanks for the info, will come in handy!

Related