Short Name at end of Advertisement Packet?

[RVM]

I am using Nordic SDK v15.3.0.

I have set all the required parameters and content before I call the API "ble_advdata_encode(..)".

I ran into two issues one of which I can work around -- more like hack around it -- and that is that the SDK only encodes the name as a short name if it does not have enough payload capacity available to insert the provided name.

The larger issue is that the SDK puts the short name at the END of the advertisement packet -- unlike your competitor where they strictly follow the packet layout that I provide in my application before calling the encoding function.

Is there an option (other than me changing the SDK API implementation, which I prefer not to do) to force the API to encode the short name to the exact size specifications at the beginning of the packet?

[Jared]

Hi,

I'm not sure I understand what you mean by the end of the packet. The Bluetooth core spec specifies how a advertisement packet should look like and what it should contain. Are you saying that it doesn't follow the spec, could you share an example of it?

[RVM]

I think this question can me marked as answered -- it was more to understand than to raise any concerns or bug reports.

I am not saying there is anything wrong or in violation of any specifications.

I was previously using an ordered list of AD field elements to initialize an advertisement (on a different vendor's platform).
It appears that Nordic, rather than sequencing through a user list of AD field elements, picks them out as named fields from a C struct. This prevents me, as a user, from expecting any predefined sequence of AD fields in the output packet. It also turns out that the Nordic SDK updates the "name" (or "short name") field at the end of the function that generates the output advertisement packet.