Non-connectable Long Range advertisement

[K Foit]

Hi,

We're using nRF52840 rev. A with s140_nrf52840_6.0.0-6.alpha SoftDevice and patched SDK 14.2.0. We've succesfully launched Long Range advertisements on one device and LR scanner on another. However we don't neeed the device to be connectable, so obviously we've tried setting .connectable = 0,. The problem is that function sd_ble_gap_adv_start returns NRF_ERROR_INTERNAL. Any idea why or (even better) how to launch this? Here's our code:

uint32_t bluetooth_advertisingInit(void)
{
	uint8_t custom_data[8] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07};
	ble_advdata_manuf_data_t manuf_data =
	{
			.company_identifier = 0xFFFF,
			.data.size = 8,
			.data.p_data = custom_data,
	};
	ble_advdata_t adv_data;
	memset(&adv_data, 0, sizeof(adv_data));
	adv_data.name_type          = BLE_ADVDATA_NO_NAME;
	adv_data.flags              = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;
	adv_data.include_appearance = false;
	adv_data.p_manuf_specific_data = &manuf_data;

    ret_code_t err_code = ble_advdata_set(&adv_data, NULL);
    APP_ERROR_CHECK(err_code);
    app_timer_create(&bluetooth_advertisementTimer,
                     APP_TIMER_MODE_SINGLE_SHOT,
                     bluetooth_advertisementTimerHandler);


#if defined(S140)
    // Set maximum output power for advertiser, scanner, and initiator.
    sd_ble_gap_tx_power_set(BLE_GAP_TX_POWER_ROLE_ADV, BLE_CONN_HANDLE_INVALID, 9);
    sd_ble_gap_tx_power_set(BLE_GAP_TX_POWER_ROLE_SCAN_INIT, BLE_CONN_HANDLE_INVALID, 9);
#endif
    return err_code;
}

void bluetooth_advertisingStart(void)
{
    ble_gap_adv_params_t const adv_params =
    {
        .properties    =
        {
          .connectable = 0,
		  .scannable   = 0,
		  .directed    = 0,
		  .high_duty   = 0,
		  .legacy_pdu  = 0,
		  .anonymous   = 0,
        },
        .p_peer_addr   = NULL,
        .fp            = BLE_GAP_ADV_FP_ANY,
        .interval      = BLUETOOTH_ADVERTISEMENT_FAST_INTERVAL,
        .duration      = 0,
		.scan_req_notification = 0,
#if defined(S140)
        .primary_phy   = BLE_GAP_PHY_CODED,
        .secondary_phy = BLE_GAP_PHY_CODED,
#else
        .primary_phy   = BLE_GAP_PHY_1MBPS,
        .secondary_phy = BLE_GAP_PHY_1MBPS,
#endif
    };
    ret_code_t err_code = sd_ble_gap_adv_start(BLE_GAP_ADV_SET_HANDLE_DEFAULT, &adv_params, BLUETOOTH_CONNECTION_CONFIG_TAG);
    APP_ERROR_CHECK(err_code);
}

[Petter Myhre]

Non-connectable advertising is not supported by S140 6.0.0-6.alpha, it is not really a bug, it just hasn't been implemented yet.

[K Foit]

OK, I can live with that for now, but when you will release SoftDevice that will support this? Other issue is that we've noticed that in the latest SoftDevice (6 alpha) there is significant current consumption after sending advertisement. Here are our measurements: images81.fotosik.pl/.../120e10a29a250528.png We used 20 Ohm resistor in series to measure current consumption. White graph shows SD6 with LR, Yellow one shows SD5 with 1Mbps mode. You can see that on older SD5 packets are sent (on each adv. channel) and then system goes to sleep. On the newer SD (white graph) the times are obviously longer, since we're using LR in 125kbps, but after those 3 packets there is one more, much wider phase of high current consumption. To be clear: We didn't removed capacitors on power supply lines near nRF52840, so you cannot distinguish TX from RX phases, but both of them are there.

[Petter Myhre]

For release dates you should contact the regional sales manager for your area, if you don't know who it is, send me a PM with your location, and I'll let you know.

Yes, they are longer because each but requires 8 symbols on air.

There is one more because it is using advertising extensions. Advertising extensions has to be used to do long range advertising.

Three ADV_EXT_IND PDUs are sent on the three advertising channels, but there is one more PDU, the AUX_ADV_IND. This is transmitted on a data channel. The ADV_EXT_IND PDUs contain information about when and on which data channel AUX_ADV_IND should be sent.

I assume the last peak is the received waiting for a potential connection request (AUX_CONNECT_REQ).

This might become clearer if you look at Section 4.4.2.7, Part B, Vol. 6 in the Bluetooth Core v5.0 specification.