Beacon and DFU

RE: Beacon and DFU

Ken A — Tue, 23 Jun 2020 13:40:41 GMT

I solved the original problem after some research.

Services do not need to be advertised, as long as they are added as services. Then the services are visible after a central device connects to the peripheral.

RE: Beacon and DFU

Hung Bui — Thu, 18 Jun 2020 09:01:32 GMT

No, it's not. There is a slightly effect of having small period to listen to connect request meaning you don't scan in that period, but it's very small.

RE: Beacon and DFU

Ken A — Wed, 17 Jun 2020 15:54:56 GMT

One more thing. The device operates simultaneously in BLE Central mode (to scan for certain UUID values) and a BLE peripheral (iBeacon mode). Will this affect the ability of peripheral mode to be connectable?

RE: Beacon and DFU

Hung Bui — Wed, 17 Jun 2020 14:02:17 GMT

As far as I know there isn't a requirement that when you do iBeacon you need to do non-connectable advertising. So I think you can just do connectable advertising and implement DFU service in the GATT table.
But be aware that doing connectable advertising draw more current than non-connectable. Check here.

RE: Beacon and DFU

Ken A — Wed, 17 Jun 2020 13:48:10 GMT

Hi,

The BLE is configured as an iBeacon.

RE: Beacon and DFU

Hung Bui — Wed, 17 Jun 2020 13:31:36 GMT

Hi Ken,

Could you let me know if you follow any beacon standard ? For example Eddystone ?
Beacon by definition is simply advertising packet. You can have connectable beacon if you want. When advertise in connectable mode it allows the phone to connect to it and trigger the Buttonless DFU service.
If it's a requirement to do non-connectable advertising, you can do both, occasionally advertise with connectable mode. For example doing connectable advertising for 10 second every 1 minute.