Central Scan Continuously and Peripheral/Beacon Broadcast

[kian79]

Hi all,

I have a use case where I have about 40 buttons that can be pressed anytime. I need know when these buttons are pressed on multiple receivers devices. So every receiver device needs to know the status of all 40 buttons. It does not have to report immediately. I can have a delay of up to 1 second.

For the buttons, I am thinking of two possibilities:

1. Using a non-connectable peripheral that broadcast for 5 seconds whenever the button is pressed. After 5 seconds it stops broadcasting and goes to sleep.
2. Using a beacon that continuously broadcast the button status at regular intervals, e.g. every 1 second.

For the receivers, I am thinking of implementing it as a central device that scans continuously. In the case for a peripheral broadcasting for 5 seconds, it should be able to scan for the device name of the buttons and report which button is pressed. In the case of the beacon, the status of the button is encoded in the major or minor value in the beacon packet.

Its this a good strategy for implementing this use case? Should I use method 1 or method 2 for the buttons? Or is there other better methods to do this?

Thanks in advance!

*Edit: I mean 40 different broadcasters. Each can broadcast anytime , depending on when the button is pressed.

*Followup Questions:

1. I have been trying this for a few hours and had a few observations. It seems like for a beacon, I can't have a device name. And for a peripheral that is broadcasting, I can set a device name, but it has to be connectable. I can't seem to set it to non-connectable and still have a device name. Is it possible to have a device name and yet be in non-connectable mode?

[RK]

Since a beacon is just a non-connectable advertiser with a specific packet definition then your two methods are pretty equivalent really. I would just run a non-connectable advertiser constantly (not just for 5 second, you're not wasting much battery advertising) but with my own packet definition, not the beacon one, it's not really a beacon. Since you have lots of space in the packet you could even encode the last sequence of button presses and not just the current one, which gives your receivers even more time to read what happened.

[kian79]

Hi RK, What will be a good starting example to use? ble_app_beacon or ble_app——template?

[RK]

either really. If you start with the beacon you have the advertising and just need to change the packet, but need to add the button handling. If you start with the app you may find some button handling already but need to change the advertising.

Since you have a ton of buttons your button code will probably be custom so I'd start with the beacon code myself and go from there, it's simpler.

[kian79]

ah. I think there is a misunderstanding in my question. What I meant is that I have 40 different broadcasters. Each has its own buttons, and they can be pressed anytime.

[Petter Myhre]

I would go for something like 1. But why broadcast for 5 seconds if your maximum latency is 1 second?

Remember that advertising and scanning is typically done on three channels. You may want to consider using only one channel for both, like done in the BLE Mesh implementation. Advertising on one channel is supported by our SoftDevices, scanning on one is not, but it shouldn't be too hard to do it anyway, there are some threads on here describing how to do it.

Yes, it is possible to have a device name and yet be in non-connectable mode. How have you implemented this? What happens?