This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Advertising limit on number of services

Adding two services with 128bit GUID's to the advertising data structure fails with NRF_ERROR_DATA_SIZE.

I'm adding the service UUID's to the uuids_complete structure. In the function uuid_list_sized_encode you check for buffer overflows, and it then fails when I'm adding two services that have their own 128bit GUIDs to the advertising data structure.

Shouldn't it be possible to specify any number of services, or are we limited to one packet?

I'm also a little in doubt on the other handles - like when to use: uuids_more_available uuids_solicited

It would sound reasonable to add the most important service to the complete structure, and less important services to more_available. Maybe you could sheed some light on this.

Parents
  • Hi KPE,

    The reason why advertising with two 128 bit UUID's fails is quite simple.

    There are room for 31 byte in advertising packet, and 31 bytes in scan response packet. If you check Core Version 4.0, Volume 3, Part C, 11, then you can see how advertising data fits in to an advertising packet or scan response packet)

    When you try to add two 128 bit services in one advertising packet, that would be 1 byte for length + 1 byte for AD Type + 32 byte for 2 128 bit services = 34 bytes.

    What you could do is to have one of the services in the scan response data, or alternate between advertising them if you do this then I would recommend using the AD Type uuids_more_available.

    If you are not able to fit all the services in to the advertising data, then you should use uuids_more_available, if you are looking for a peer that have certain services, then you should use uuids_solicited.

    -- Pål

  • I think this would be an optional thing as it is more information to the peer device. But since you won't be able to have all of the services in one advertisement packet it does not matter that much. The most important thing is to have the "more 128-bit UUIDs available" type set. As this would indicate to the peer that the service in the adv packet is not the only one available, and a full service discovery would be required to find all of them. If you use the "complete list of 128-bit UUIDs available", then the peer would not even have to connect if he don't see the UUID he's looking for in that list.

Reply
  • I think this would be an optional thing as it is more information to the peer device. But since you won't be able to have all of the services in one advertisement packet it does not matter that much. The most important thing is to have the "more 128-bit UUIDs available" type set. As this would indicate to the peer that the service in the adv packet is not the only one available, and a full service discovery would be required to find all of them. If you use the "complete list of 128-bit UUIDs available", then the peer would not even have to connect if he don't see the UUID he's looking for in that list.

Children
No Data
Related