As well as some other posts - it's really catching a lot of people out. Unless they won't fit, services should go in the standard Advertising packet.
The API is also a bit rubbish since the service should really be specified in 'setAdvertising' - we should maybe deprecate the old method.
Also related to #1371 Espruino uses the Nordic API to work out the advertising packet, but there isn't really a nice way of detecting when there's too much stuff to advertise. It's so simple we should probably make Espruino create the advertising packet, then we might have some options about how we notify the user and/or start moving advertised services into the scan response.
The text was updated successfully, but these errors were encountered:
just comment about idea 'put there everything what fits', there are low power guides that mention making advertising packet smallest and return rest only on request (=in scan response). So should be overridable in some way for those wanting to maximize battery life, see https://www.novelbits.io/ble-power-consumption-optimization/ part Advertising state - Advertising data length
Thanks - good idea. Maybe it's best not to even bother doing it automatically and to just error. One issue is the Nordic UART and HID service IDs get automatically added to the scan response when enabled, but maybe we actually just ignore that and when you specify a scan response the UART/HID stuff is overwritten.
Right now NRF.setAdvertising basically uses NRF.getAdvertisingData to get the data internally.
What I'm hoping is where you want to stick stuff in a scan response, you do NRF.setScanResponse(NRF.getAdvertisingData(...)).
Note to me: Scan Response is currently broken for SDK15 builds because of the way it needs setting alongside advertising data. This would be a good opportunity to fix that.