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

Why my DeviceName is limited with 8 characters in DFU program?

image description

Here are 4 broadcast signal, the first is send with dfu, whenever how I try, it only display 8 characters in max.

And the second and the fourth named begin with "LOCK_" , is send with the application program, there can be display 32 characters in max.

the parameter in both program is defined as below: /**@brief GAP device name maximum length. */ #define BLE_GAP_DEVNAME_MAX_LEN 31

The question is: how can I made the device name equal to the max length(31 characters) ? Thanks!

Parents
  • Firstly you will never be able to broadcast (unless both sides are enabled with BT 5.0 broadcast message extensions which isn't your case) more then 31 bytes of effective payload. On top of that basically all BLE devices today are GAP compliant to that steals few more bytes for mandatory elements (like Flags AD object) and L-T-V AD object header. So maximum size of device name broadcasted (= shortened, once you connect you can get full name over respective GATT Characteristic!) is 31-3-2=26 bytes. In case of DFU most probably other AD objects are placed into Adv. data (like 128-bit UUID list which takes typically 18 bytes) so space for Device Name is more and more limited. So to debug correctly see RAW format of Adv. data in nRF Connect (or similar app, you can indeed also use BLE radio sniffer/analyzer). I guess you will spot the reason straight ahead. Workarounds could be: deciding not to place other AD objects into Adv. data (but honestly device name should be more or less irrelevant for BLE apps to work together on the background - they use MAC and GATT UUIDs to find proper peers - so I wouldn't go that way) or you can use Scan Response data for that (= not placing it to Adv. data at all but move it to Scan Resp. because most of Observers/Central devices will actively scan so they will find it and you might get access to maximum buffer size for your string which is 31-2=29).

Reply
  • Firstly you will never be able to broadcast (unless both sides are enabled with BT 5.0 broadcast message extensions which isn't your case) more then 31 bytes of effective payload. On top of that basically all BLE devices today are GAP compliant to that steals few more bytes for mandatory elements (like Flags AD object) and L-T-V AD object header. So maximum size of device name broadcasted (= shortened, once you connect you can get full name over respective GATT Characteristic!) is 31-3-2=26 bytes. In case of DFU most probably other AD objects are placed into Adv. data (like 128-bit UUID list which takes typically 18 bytes) so space for Device Name is more and more limited. So to debug correctly see RAW format of Adv. data in nRF Connect (or similar app, you can indeed also use BLE radio sniffer/analyzer). I guess you will spot the reason straight ahead. Workarounds could be: deciding not to place other AD objects into Adv. data (but honestly device name should be more or less irrelevant for BLE apps to work together on the background - they use MAC and GATT UUIDs to find proper peers - so I wouldn't go that way) or you can use Scan Response data for that (= not placing it to Adv. data at all but move it to Scan Resp. because most of Observers/Central devices will actively scan so they will find it and you might get access to maximum buffer size for your string which is 31-2=29).

Children
No Data
Related