Back to back calls to ble_advertising_start(..) in nRF SDK 16.0.0 fails with INVALID_PARAMETER (i.e. 10)

[RMV]

I am using SDK 16.0.0.
I want to switch from a NON-CONNECTABLE, NON-SCANNABLE advertisement to a CONNECTABLE, SCANNABLE advertisement.
I launch the first advertisement and wait for it to finish after its 'DURATION' expires.
Then I launch the second advertisement (this is triggered Out of Band with a GPIOTE event).
The firmware rexecutes ALL the steps it took when it launched the first advertisement EXCEPT it uses the same configuration tag as was used in the first advertisement.

The start operation for the second advertisement fails with the error 10 i.e. INVALID PARAMETER.
The only thing I have been able to figure out is that the 'type' is different than it was before.
But the firmware DOES initialize the advertising module with the NEW type.

So, I do not understand why the Soft Device is responding with the error 10.

[RMV]

Hi Karl,

Sorry but I have worked around this by basically separating out the values being set at the GAP level versus the values I pass to the advertising module. The problem only occurs if I keep them the same. I am not sure if this is a good, robust, solution but I will spend some time with this before thinking of other options.

I cannot isolate the sample code, but here is the generic sequence.
1. Set GAP parameters to CONNECTABLE, SCANNABLE.
2. Copy the GAP parameters and pass them to the call to ble_advertisement_init. i.e. I expect these parameters (and I know that they are so) to be NON-CONNECTABLE, NON-SCANNABLE.
3. Call ble_advertising_start(...)
..... /* some time later */....
4. Cleanly stop any ongoing advertisement.
5. Set/Update GAP parameters to NON-CONNECTABLE, NON-SCANNABLE
6. Copy the GAP parameters and pass them to the call to ble_advertisement_init. i.e. I expect these parameters (and I know that they are so) to be NON-CONNECTABLE, NON-SCANNABLE
7. Call ble_advertising_start(...)    // GENERATES ERROR. NOTE: item (6) above does not generate any errors.

CAVEAT:
I did copy the ble_advertising.c from the SDK to my local folder and modify it to have the upper layer control the 'type'of advertisement that was being launched. Without this change, the module was always converting the GAP set up to be a 'CONNECTABLE, SCANNABLE' broadcast. I had opened another ticket here that further explains my issues.

RMV

[Karl Ylvisaker]

Hello RMV,

RMV said:

Sorry but I have worked around this by basically separating out the values being set at the GAP level versus the values I pass to the advertising module. The problem only occurs if I keep them the same. I am not sure if this is a good, robust, solution but I will spend some time with this before thinking of other options.

I am happy to hear that you have found a workaround that works for your application.
I am not sure I have understood your issue here correctly, but it seems to me that the issue was resolved by creating a local copy of the ble_advertising.c library, and changing the advertising type set there - is this correct? I understand this from reading the other ticket you have referenced.
If this is not the case, please elaborate. 

RMV said:

I did copy the ble_advertising.c from the SDK to my local folder and modify it to have the upper layer control the 'type'of advertisement that was being launched. Without this change, the module was always converting the GAP set up to be a 'CONNECTABLE, SCANNABLE' broadcast. I had opened another ticket here that further explains my issues.

It is correct that the intended use of the advertising module is to facilitate connectable advertising. This is mentioned in the second sentence of the library's documentation, but I agree that this perhaps could be highlighted better. By creating a local copy and modifying the advertising type, you should be able to change the advertising to non-connectable.
Alternatively, non-connectable advertising is demonstrated in the ble_app_beacon example in the SDK that my colleague Simon referenced in your other ticket.
Non-connectable, non-scannable advertisement is a lot 'easier' to setup and use than the connectable ones (please see the beacon example) since you do not have to handle any external requests or prompts, and I suppose this is why the library is made to support connectable advertising primarily.

Best regards,
Karl 

[RMV]

Karl Ylvisaker said:

am happy to hear that you have found a workaround that works for your application.
I am not sure I have understood your issue here correctly, but it seems to me that the issue was resolved by creating a local copy of the ble_advertising.c library, and changing the advertising type set there - is this correct? I understand this from reading the other ticket you have referenced.
If this is not the case, please elaborate. 

The workaround listed above was for the problem listed in the other ticket.

The problem listed in this current ticket needs another workaround in my application (not the advertising library).
That workaround is to change ONLY the GAP parameters but keep the advertising type FIXED.
I realize this may not be the most prudent solution but right now I have nothing better that I can use at such a short notice.

[Karl Ylvisaker]

Hello,

RMV said:

The workaround listed above was for the problem listed in the other ticket.

My apologies, it seems I misunderstood your issue's description. The two issues seemed to be caused by the type field, and thus I thought you meant they both had been solved.

RMV said:

That workaround is to change ONLY the GAP parameters but keep the advertising type FIXED.
I realize this may not be the most prudent solution but right now I have nothing better that I can use at such a short notice.

It would be greatly helpful for me to have seen the code snippet where you are stopping and reconfiguring the advertisement data directly prior to it failing. Without having seen this, it is very hard for me to pinpoint or identify the root of this issue.
My understanding is that you can not keep your advertising type fixed as a solution, since you want to go from CONNECTABLE to NON-CONNECTABLE, is this not correct?

Either way, you could implement your NON-CONNECTABLE advertising as demonstrated in the beacon example referenced earlier, and then stop advertising and start using the advertising module to do your connectable advertisings, and visa versa.

Best regards,
Karl