Help with understanding advertising choices

[Keith Brafford]

I am building a project that is based on the custom service example https://github.com/bjornspockeli/custom_ble_service_example but I don't like how it advertises in a way that only leaves 4 characters for my device name.

I grafted on the advertising method from ble_app_blinky as an alternate advertising function in my app (so I can go back and forth), and I get the full device name to show up in nRFConnect.  It doesn't work 100% yet--it won't launch into advertising again after a disconnect--but other than that think I like the result better.  Can someone help me understand why the blinky method leaves more space for the name, and what I am giving up by doing it that way?

Here's my "alt" advertising functions:

static uint8_t m_adv_handle = BLE_GAP_ADV_SET_HANDLE_NOT_SET; /**< Advertising handle used to identify an advertising set. */
static uint8_t m_enc_advdata[BLE_GAP_ADV_SET_DATA_SIZE_MAX]; /**< Buffer for storing an encoded advertising set. */
static uint8_t m_enc_scan_response_data[BLE_GAP_ADV_SET_DATA_SIZE_MAX]; /**< Buffer for storing an encoded scan data. */

/**@brief Struct that contains pointers to the encoded advertising data. */
static ble_gap_adv_data_t m_adv_data =
{
.adv_data =
{
  .p_data = m_enc_advdata,
  .len = BLE_GAP_ADV_SET_DATA_SIZE_MAX
},
.scan_rsp_data =
{
  .p_data = m_enc_scan_response_data,
  .len = BLE_GAP_ADV_SET_DATA_SIZE_MAX

}
};

static void advertising_init_alt(void)
{
  ret_code_t err_code;
  ble_advdata_t advdata;
  ble_advdata_t srdata;

  ble_uuid_t adv_uuids[] = {{CUSTOM_SERVICE_UUID, m_cus.uuid_type}};

  // Build and set advertising data.
  memset(&advdata, 0, sizeof(advdata));

  advdata.name_type = BLE_ADVDATA_FULL_NAME;
  advdata.include_appearance = true;
  advdata.flags = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;

  memset(&srdata, 0, sizeof(srdata));
  srdata.uuids_complete.uuid_cnt = sizeof(adv_uuids) / sizeof(adv_uuids[0]);
  srdata.uuids_complete.p_uuids = adv_uuids;

  err_code = ble_advdata_encode(&advdata, m_adv_data.adv_data.p_data, &m_adv_data.adv_data.len);
  APP_ERROR_CHECK(err_code);

  err_code = ble_advdata_encode(&srdata, m_adv_data.scan_rsp_data.p_data, &m_adv_data.scan_rsp_data.len);
  APP_ERROR_CHECK(err_code);

  ble_gap_adv_params_t adv_params;

  // Set advertising parameters.
  memset(&adv_params, 0, sizeof(adv_params));

  adv_params.primary_phy = BLE_GAP_PHY_1MBPS;
  adv_params.duration = APP_ADV_DURATION;
  adv_params.properties.type = BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED;
  adv_params.p_peer_addr = NULL;
  adv_params.filter_policy = BLE_GAP_ADV_FP_ANY;
  adv_params.interval = APP_ADV_INTERVAL;

  err_code = sd_ble_gap_adv_set_configure(&m_adv_handle, &m_adv_data, &adv_params);
  APP_ERROR_CHECK(err_code);
}

static void advertising_start_alt(bool erase_bonds)
{
  ret_code_t err_code;

  if (erase_bonds == true)
  {
  delete_bonds();
  // Advertising is started by PM_EVT_PEERS_DELETED_SUCEEDED event
  }
  else
  { 

  err_code = sd_ble_gap_adv_start(m_adv_handle, APP_BLE_CONN_CFG_TAG);
  APP_ERROR_CHECK(err_code);
  }
}

[Simonr]

Hi Keith

The main difference between your advertising init and the one in my colleague's example is that he has included the UUID in his advertising packet, while your alternative includes this UUID in the scan response packet. The UUID takes up quite a few of the 29 bytes available in an advertising packet, which is why there is less room for the device name in the example. So you could move the UUID into the scan response packet instead of the advertising packet instead, and you should have room for a longer device name in the example as well.

Best regards,

Simon

[Keith Brafford]

Thanks for the explanation. Another difference in approaches is the custom example uses the "ble_advertising" module, but the blink app goes straight to the soft device, right?  Can you help me understand what I would need to do to make the ble_advertising module behave like the blinky approach (i.e. put the full UUID in the scan response)?  Or is it just better to not use that module if you want to do this?

[Simonr]

Hey Keith

This tutorial should be helpful for learning how to make a scan response packet, but if you're using the approach in the Blinky example anyway, I think it would be faster/easier to add the custom service(s) to that example project instead.

Best regards,

Simon

[Keith Brafford]

Thanks for the responses.

So you're saying that the ble_advertising module isn't the "nordic preferred" approach?  Since the ble_advertising module works well with the peer manager, I was hoping you could explain to me how I can use the module to get the desired behavior. 

[Keith Brafford]

Simon, I am mostly looking for clarity and understanding.  For instance, I notice that ble_app_uart appears to do the same thing as the custom_ble_service_example does as far as advertising goes, yet uart gets "Nordic_UART" to show up while my version of the example only gets the first 4 characters. That is further confusing.