Advertising limit on number of services

Question

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.

Pål Håland · Accepted Answer

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