It it possible to send data one way to multiple centrals?

[Nerdwolf]

Hi,

I want to send data from one peripheral(nRF51 DK) to multiple Android Phones. This will be a one way connection from the peripheral to the smartphones. I red on the forum that no multiple central connections are possible so therefore I wondered if it would be a good idea to send the data using the 'custom manufacture data' in the advertising.

This way multiple phones can receive the data if within the advertising range. Am I forgetting about something? How many packets will be lost? I know this will not have some kind of handshaking for redundancy but maybe this can be build in into the manufacture data using CRC or something simular?

Or are there other ways to send data to multiple smartphone centrals?

[RK]

Yep one peripheral can be connected only to one central. There are other BTLE stacks which allow multiple peripheral instances, but this one doesn't.

So if you want to 'send' data to multiple servers you pretty much have to put it in the advertising data and if you do that, there's no way to know absolutely that a central received it, it may, it may not. If it's in range, listening and you advertise long enough there's a good chance it will, but no guarantees.

One interesting observation is that, if you happened to know the peer addresses of all the clients you want to receive data, you can tell if they've received it. You put your data in the manufacturer data and you make your advertising scannable. When the peer gets the advertisement it will scan you and you get a BLE_GAP_EVT_SCAN_REQ_REPORT with the peer address. Since it must have received the ad data in order to scan, you know it got it. It would be rather unusual however to know all of the peer addresses of all the devices you want to send data to.

How critical is it that everyone gets the data?

[Nerdwolf]

It is not very critical. I want them to receive data once every second+- but whether it's 1.1s or 0.9s it's not that important. It is more important that the received data is correct. Is some kind of redundancy build in in the advertising? So I know for sure some bits of a packet are not changed over air?

Also regarding power consumption: would the power consumption be lower in advertising mode compared to connected mode if I send data every second? I could not find this in the datasheet ( maybe I overlooked it).

[RK]

Advertising data is protected by the same CRC that every other packet is. 24 bits of CRC. So it's as protected as a normal packet.

Once a second however .. remember that when you're in a connection the connection intervals are timed, in advertising you're just blasting into the void. The shorter time you send data for, the higher the chance that one of the receivers wasn't listening during the few bursts of data you sent, or a WiFi router next to you obliterated them. The more often you advertise (there are spec limits) and the more often the device is scanning, the more likely you are to get the data, but at that kind of level any one 'chunk' of data may just not get there. If it's important for the clients to receive ALL the data, then this isn't going to work, they will probably receive most of the data most of the time.

The power consumption stuff is in the S110 spec.

[Nerdwolf]

Thank you very much RK. Im currently trying to use the advertising data and see how it performs in noisy environments. Do you think it should be possible to use some kind of synchronization using the provided 'timestamps' attached to an advertising packet ( mTimestampNanos ) ?