Central Scan Continuously and Peripheral/Beacon Broadcast

RE: Central Scan Continuously and Peripheral/Beacon Broadcast

Petter Myhre — Mon, 20 Nov 2017 16:29:20 GMT

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?

RE: Central Scan Continuously and Peripheral/Beacon Broadcast

kian79 — Mon, 20 Nov 2017 08:08:44 GMT

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.

RE: Central Scan Continuously and Peripheral/Beacon Broadcast

RK — Mon, 20 Nov 2017 08:05:52 GMT

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.

RE: Central Scan Continuously and Peripheral/Beacon Broadcast

kian79 — Mon, 20 Nov 2017 07:45:54 GMT

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

RE: Central Scan Continuously and Peripheral/Beacon Broadcast

RK — Mon, 20 Nov 2017 07:29:38 GMT

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.