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

Central Scan Continuously and Peripheral/Beacon Broadcast

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

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

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

Children
No Data
Related