Issues in ble_advertising - BLE_ADV_MODE_IDLE not set as current advertising mode on connection

[Malcolm]

There are a number of issues in ble_advertising that relate to changing the status of advertising in response to events. Specifically the current adv mode is not changed on connection and is left as the mode when the connection is made. This causes errors later if the current advertising mode is used for decisions.

Likewise the code for uint32_t ble_advertising_start, which seemingly takes as parameter BLE_ADV_MODE_IDLE doesn't stop any ongoing advertising, which results in errors later if advertising is restarted.

[Einar Thorsrud]

Hi,

Which SDK version are you referring to?

Referring to SDK 16 it is correct that the advertising model is not changed when connected. However, it is set when restarting advertising for some reason, depending on the reason and the configuration. For instance, on disconnect, advertising is always started with BLE_ADV_MODE_DIRECTED_HIGH_DUTY (though it will only be used if enabled, as there is a ladder in the advertising module). Different events are handled differently though. For instance, If there is a timeout event, then the same model is used again. Also, If the user starts advertising with a call to ble_advertising_start(), then the mode is always provided, so it is up to you.

Can you elaborate on in which situation you would want the advertising module to behave differently, and how it should behave instead?

[Malcolm]

1. When the device becomes connected, advertising should return to IDLE, now it remains on HIGH (or whatever was the mode when the connection was made). Currently the button press sends the same signal for advertising stopped and running (it only changes when connected), therefore I need to know if advertising is stopped or running to determine the required action (start or stop respectively) and I can determine this by inspecting the advertising current mode.

2. The function uint32_t ble_advertising_start should stop advertising when the parameter passed is BLE_ADV_MODE_IDLE. Currently it only propagates the event but does not stop advertising and so the propagated event is incorrect. Any attempt to start advertising will incur an error as advertising will be in the incorrect state (unless otherwise it stopped).

[Malcolm]

I have nRF5SDK160098a08e2.zip

[Einar Thorsrud]

Hi,

I see. I think this is mostly that you would like the advertising module to behave in a different way (which I can understand), and not that these are actual bugs in the module. There are several ways around this, either using the module as is and working around it, modify the module to get your preference, or skip it altogether and use SoftDevice APIs for advertising directly.

Malcolm said:

1. When the device becomes connected, advertising should return to IDLE, now it remains on HIGH (or whatever was the mode when the connection was made). Currently the button press sends the same signal for advertising stopped and running (it only changes when connected), therefore I need to know if advertising is stopped or running to determine the required action (start or stop respectively) and I can determine this by inspecting the advertising current mode.

You can always call sd_ble_gap_adv_stop() and ignore the return value before you call ble_advertising_start().

[Malcolm]

I have made the suggested workarounds so that my applications works as intended. The problem is keeping track of where changes are made in core code in case a new version is released.