Device name showing as "n/a"

RE: Device name showing as "n/a"

Sensors — Sat, 04 Jul 2015 19:42:52 GMT

Stepping through it, it appears that it's fine stepping into this whole section of the name_encode() function:

// Check if device internd to use short name and it can fit available data size.
if ((p_advdata->name_type == BLE_ADVDATA_FULL_NAME) && (actual_length <= rem_adv_data_len))
{
    // Complete device name can fit, setting Complete Name in Adv Data.
    adv_data_format  = BLE_GAP_AD_TYPE_COMPLETE_LOCAL_NAME;
    rem_adv_data_len = actual_length;
}

EDIT: seems like after using the sd_ble_uuid_vs_add() function I'm able to get the device to show a name while still using the BLE_UUID_TYPE_VENDOR_BEGIN. Like you had anticipated, Bill, I'm fairly limited in the length of the device name but it seems to be showing okay if it's 4 characters or less.

RE: Device name showing as "n/a"

Bill Siever — Sat, 04 Jul 2015 12:58:35 GMT

The Bluetooth SIG UUIDs only take 2 bytes whereas a custom UUID will take 16. When included in the advertisement, each will also include a length byte and a type byte, so each advertised Bluetooth SIG Service will take 4 bytes and each advertised custom UUID will take 18 bytes. You also include flags and appearance. Since the advertising packet is only 31 bytes, it doesn't leave much space for a name. (I.e. about <= 7 bytes for a name). As you can see in name_encode(), if there isn't enough space for the complete name it will attempt to use the short name. Did you actually debug the call to name_decode() and step through the if-statements to see which path it is taking?

RE: Device name showing as "n/a"

Sensors — Sat, 04 Jul 2015 09:08:13 GMT

IT seems to have had something to do with this line:

ble_uuid_t m_adv_uuids[] = {{X_SERVICE_UUID,BLE_UUID_TYPE_VENDOR_BEGIN}};

But I don't understand why.

When I set the UUID type to BLE_UUID_TYPE_BLE, I don't get the problem any more.

RE: Device name showing as "n/a"

Sensors — Sat, 04 Jul 2015 08:40:58 GMT

This is what I'm seeing: http://i.imgur.com/H0EIFbJ.png I tried the short name, no luck with that either. I would expect to at least see some flags or an appearance or something.

RE: Device name showing as "n/a"

Bill Siever — Fri, 03 Jul 2015 16:49:08 GMT

After posting I realized that the power_manage() probably wasn't significant, but I forgot to update.

You may not have enough space in the advertising packet for the full name. If you look at the name_encode() function in ble_advdata.c you'll see that it only uses the full name if there is still sufficient space left (you'd have to check more details to see what was added first). Can you put a breakpoint on the if-statement in name_encode() to see if it is using the full name or if it's falling back to the short name? If that is the cause of the problem you can a) choose a smaller name; and/or b) put less info in the advertising packet; and/or c) configure the short name length (so it at least includes a partial name) via advdata.short_name_len in the advertising_init().

RE: Device name showing as "n/a"

Sensors — Fri, 03 Jul 2015 16:15:20 GMT

Bill, it is advertising I think... Using the nRF master control panel app I can see it, but it doesn't have any data. It says 'n/a', has the device address, 'Not Bonded' and 'Type: Unknown'. I've thrown in the power_manage() into the while loop now with the same result.

RE: Device name showing as "n/a"

Bill Siever — Wed, 01 Jul 2015 18:09:15 GMT

Is it advertising at all? And, if so, how do you know (via a packet-level sniffer, like with Nordic's dongle or with a browser tool, like LightBlue)?

If it isn't actually advertising at all, you might want to think carefully about your while(1) {} loop. It may be starving out the events necessary for advertising. Note that Nordic's examples typically include a call to sd_app_evt_wait() (sometimes through a wrapper function named power_manage()) to allow the SoftDevice to process events.