Problems with a full advertising name

[AHass]

Hi,

my project is based on the example 'ble_app_proximity' from SDK ver 17.0.2. When I set a longer DEVICE_NAME, for example

#define DEVICE_NAME "123456789ABCDEF"

the string is cut up after the first 12 characters, so I am just seeing the name "123456789ABC" when advertising., even though in the advertising_init, I set the name type to full name:

init.advdata.name_type  = BLE_ADVDATA_FULL_NAME;

I am aware of another question in this forum where it was suggested to put the list of UUID's in the scan response packet rather than the advertise packet due to missing space in the advertise packet. But this would mean my scanner would need to send a scan request in order to get the list of UUID's, and this is not an option in my case.

Is there any other workaround that does not include changing the scanner's behaviour?

Thank you kindly for your help.

[Karl Ylvisaker]

Hello,

I am aware of another question in this forum where it was suggested to put the list of UUID's in the scan response packet rather than the advertise packet due to missing space in the advertise packet. But this would mean my scanner would need to send a scan request in order to get the list of UUID's, and this is not an option in my case.

How many UUID's are you including in your advertising? How many bytes total do you use for your advertising?
For the record, I will mention here the limit of 31 bytes for the advertising packet.

Is there any other workaround that does not include changing the scanner's behaviour?

What is the total contents of your advertising packet?
Does your application require a 15 byte device name? Please note that each added field adds 2 byte overhead to your advertisement, so a 15 byte name in reality requires 17 bytes to advertise. That is more than half the available packet length, spent on the name.

the string is cut up after the first 12 characters, so I am just seeing the name "123456789ABC" when advertising., even though in the advertising_init, I set the name type to full name:

Yes, this is as expected. Please see the note in the ble_advdata_encode API Reference Documentation.
Are you seeing any errors being returned, at any point of your advdata initialization?

Best regards,
Karl

[AHass]

Hi Karl,

it is a late reply, but your tips helped. I've solved the issue by advertising fewer services. Since I misunderstood the function of scan response packets it was not a proper solution for me at the time. After reading more about that topic it got clear that it is indeed a solution for my case. Now I only advertise one custom service, the rest of my cusotm services is read by the smartphone app.

Thanks for your help!

[Karl Ylvisaker]

Hello again,

AHass said:

it is a late reply, but your tips helped. I've solved the issue by advertising fewer services.

No problem at all, I am happy to hear that you found my reply helpful!

AHass said:

Now I only advertise one custom service, the rest of my cusotm services is read by the smartphone app.

Perfect, this is usually a very good solution - this way, you can use the single custom UUID to recognize your device, and then discover the rest during the service discovery.

Please do not hesitate to ask if you should encounter any issues or questions in the future.

Good luck with your development!

Best regards,
Karl

[Sachin Rawat]

Karl Ylvisaker said:

Yes, this is as expected. Please see the note in the ble_advdata_encode API Reference Documentation.

Hi, I am also facing the same problem that the advertising name is only showing 11 lengths but I have given the 18 lengths to the advertising name by using the bt_set_name(), Can you brief me about how to increase the buffer size that is used for advertising name 

This will helps me a lot. 

[Karl Ylvisaker]

Hello sachin,

The shortening of the advertised name is usually due to the ADV packet having exceeded the possible length - the advertising module will truncate the NAME parameter in the case that you exceed the hard 31 byte advertising length limit. Please keep in mind that you will use 2 bytes of overhead for each datafield your advertising packet contains.
What is the total contents of the packet you are trying to advertise, and are you using an additional Scan Response packet?

Best regards,
Karl