Is it possible to atomically change GAP Address and Advertising?

RE: Is it possible to atomically change GAP Address and Advertising?

Hung Bui — Wed, 09 Aug 2017 11:34:00 GMT

I can internally post that as a request. But I afraid it won't get out very soon.

RE: Is it possible to atomically change GAP Address and Advertising?

Marius Heil — Wed, 09 Aug 2017 11:31:28 GMT

Any chance that scanning could be excluded? I see the need for connecting and advertising to conform to the BLE spec, but during scanning seems a bit arbitrary and makes this a little difficult. Using a timeslot is always a possibility, but if its avoidable, that would be nice to keep the overhead down.

RE: Is it possible to atomically change GAP Address and Advertising?

Hung Bui — Wed, 09 Aug 2017 11:28:30 GMT

Hi Marius,

I checked with R&D and it seems that we wanted to avoid the race condition may occur if we let application change the address when we are doing advertising or connecting. The scanning and connecting has almost the same implementation so it's included in the restriction. In addition, changing the identity address (public or random static) is not allowed during operation by BLE spec.

Maybe you can think of scanning using timeslot ?

RE: Is it possible to atomically change GAP Address and Advertising?

Marius Heil — Tue, 08 Aug 2017 11:19:22 GMT

According to the documentation, changing the address is also not possible while scanning. Therefore I would have to disable scanning as well. I don't know why this restriction is in place. Would be nice to know the overhead of stopping and starting advertising each time, instead of only changing the advertising data. When a connected event comes in, I would rather use the own_addr that comes in the connected part of the ble event. I will also have to pay attention that the Softdevice is not in the connecting state, or I must stop connecting and restart it.

RE: Is it possible to atomically change GAP Address and Advertising?

Hung Bui — Tue, 08 Aug 2017 09:17:03 GMT

Hi Marius,

I don't know why you say it's no longer to change GAP address? The sd_ble_gap_addr_set() is still there. The only limitation is that you need to stop advertising, change the address and then start advertise again. When you have a CONNECTED event, you can call sd_ble_gap_addr_get() to know which address you are advertising with.

RE: Is it possible to atomically change GAP Address and Advertising?

Marius Heil — Fri, 04 Aug 2017 14:14:59 GMT

I implemented this myself now and was starting to get really fond of my implementation when I accidentially stumbled upon a devzone entry that changing the GAP address is no longer possible in SoftDevices with v3 and up. I guess that sucks.

RE: Is it possible to atomically change GAP Address and Advertising?

endnode — Thu, 27 Jul 2017 15:46:59 GMT

Theoretically yes but setting address is simple RAM register setting so it will take few clock cycles. In addition if you run advertising only then you can use radio_notification handler which will notify you before and after each radio session so you are basically 100% sure that you don't miss the event and both adv. data and address are applied together.

RE: Is it possible to atomically change GAP Address and Advertising?

Marius Heil — Thu, 27 Jul 2017 13:32:29 GMT

Sounds interesting, I am wondering weather the Softdevice might send an advertisement with a wrong address which might happen when I set the gap address and the Softdevice takes away the control via an interrupt before I am able to exchange the advertising data.

RE: Is it possible to atomically change GAP Address and Advertising?

endnode — Thu, 27 Jul 2017 13:04:58 GMT

I was running multiplexed broadcasts by switching the adv. data and I was also switching GAP address, it works well. GAP Central devices around were seeing the device as virtually two broadcasters and also connection requests were coming correctly. There are indeed limitations in adv. intervals of these two (or more) virtual broadcasters because they use only single GAP Broadcasting role in Nordic SD (so they need to use the same adv. type and also they will be effectively broadcasting with half frequency = double the interval of the "base" adv. interval provisioned in SD). You also need to remember that as soon as one connection is established you would need to restart another Peripheral role if you want to keep second virtual broadcaster in the air. And there I don't know if playing with GAP address during connection doesn't harm the link (I believe that it shouldn't because only Access address is used in LL PDUs) but that should be easy to test.