Unable to Receive Directed Advertisements

RE: Unable to Receive Directed Advertisements

Petter Myhre — Tue, 05 Apr 2016 07:52:49 GMT

Aaron. Det behavior you describe is expected. Great that you figured it out. Karl. Sorry to hear that you never got it working, but great that you found a workaround.

RE: Unable to Receive Directed Advertisements

Aaron Bilger — Mon, 04 Apr 2016 17:03:41 GMT

It took a while to confirm, but this looks correct per spec. Bluetooth 4.0 spec section 2.3.1 shows ADV_DIRECT_IND must have the InitA (initiator address to advertise to), but lacks the AdvData payload field which all other advertisement types (ADV_IND, ADV_NONCONN_IND, ADV_SCAN_IND).

So directed advertisements cannot, per the spec, include UUID, name, or other such info. I haven't found this in Nordic docs and the SDK examples don't handle this case, but BT spec itself is clear. And good news is the S120 SoftDevice code itself appears to be getting the packets correctly.

I'm going to add a special check for ADV_DIRECT_IND, where if its address matches my whitelist (manual check), I'll assuming it has the services I need and just go to connect.

Hopefully this approach resolves what you have too, karl? Thanks for getting back with me Petter. I'll let you know if this approach fails.

RE: Unable to Receive Directed Advertisements

Aaron Bilger — Mon, 04 Apr 2016 16:56:04 GMT

I've done more digging, and will keep it here in case it's an easier resolve. I think the actual packet sending and receiving is correct, but the SDK example code doesn't handle directed packets on the central side, leading to the confusion.

I am now seeing BLE_GAP_EVT_ADV_REPORT. That part was just a mistake on my part checking inside the BLE_GAP_EVT_ADV_REPORT handler case after some error checks. I should have checked immediately, prior to error checks.

The error checks on parsing for name or UUID16 fail, causing the BLE central example code to ignore directed advertising packets. They fail because directed packets (p_gap_evt->params.adv_report in example code) have a dlen of 0, so no parseable data.

Continued...

RE: Unable to Receive Directed Advertisements

karl — Mon, 04 Apr 2016 14:46:10 GMT

By the way, I never was able to get direct advertisements working. We control both Peripheral and Central in our application, so I was able to do a work around

RE: Unable to Receive Directed Advertisements

Petter Myhre — Mon, 04 Apr 2016 12:01:27 GMT

@Aaron Bilger I have just tested this, and it seems to be working fine. Could you open a new question, where you explain your test setup in detail? Maybe you can include your complete test projects as well?

RE: Unable to Receive Directed Advertisements

Aaron Bilger — Fri, 01 Apr 2016 21:51:40 GMT

I wanted to add that I am experiencing the exact same issue, and provide more detail on my scenario.

Using:

nRF51822 on both sides
SDK 10.0
SD1.10 8.0.0 on peripheral side
SD1.20 2.1.0 on central side
both central and peripheral use consistent type 1 (random, static) addresses obtained with sd_ble_gap_address_get()

Code was based on SDK10 examples for heart rate monitor. As long as peripheral uses non-directed advertising, central quickly sees its advertisements and can connect to it. If directed (fast or slow) advertising is used, the advertisements are never seen (i.e. no BLE_GAP_EVT_ADV_REPORT received).

I've confirmed using Master Control Panel 3.10 that the peripheral is seen sending directed or non-directed advertisements fine.

Let me know if you have any other ideas, or if there's anything else I can provide. Thanks.

RE: Unable to Receive Directed Advertisements

Petter Myhre — Mon, 18 Jan 2016 10:15:54 GMT

I see. Then I'm out of ideas. No, there is not any logging in the SoftDevice. Could you edit the question and attach:

The complete peripheral application project (Which SoftDevice are you using?)

The modified heart rate collector code. (Which hex file have you flashe the dongle with?)

Then I can try and test you code here.

RE: Unable to Receive Directed Advertisements

karl — Fri, 15 Jan 2016 19:03:23 GMT

I assume the directed advertisements are not being received because I don't see the ADV REPORT events in the serial log messages.

Is there a way to turn on some kind of logging in SoftDevice stack?

RE: Unable to Receive Directed Advertisements

Petter Myhre — Fri, 15 Jan 2016 10:21:05 GMT

Strange. It should work. How are you checking the if you are receiving directed advertising events?

RE: Unable to Receive Directed Advertisements

karl — Thu, 14 Jan 2016 18:21:43 GMT

Currently I have the address of the Central, 0xDE05F038D922, hard-coded in the Peripheral:

gap_addr->addr_type = 1;
gap_addr->addr[0] = 0x22;
gap_addr->addr[1] = 0xD9;
gap_addr->addr[2] = 0x38;
gap_addr->addr[3] = 0xF0;
gap_addr->addr[4] = 0x05;
gap_addr->addr[5] = 0xDE;

And I acquired the Central address using the sd_ble_gap_address_get API in the Central and dumping it to the console output:

[0]=22 [1]=D9 [2]=38 [3]=F0 [4]=05 [5]=DE type=1

Again I verified the address is being sent over the air in the direct advertisement packet by using the sniffer tool.

RE: Unable to Receive Directed Advertisements

Petter Myhre — Thu, 14 Jan 2016 11:06:51 GMT

It is not up to the application, the SoftDevice will only forward directed advertising events with matching device address. If you are absolutely sure that you are using the correct device address? Could you explain to me how you extract it from the central, and how you add it to the peripheral?

RE: Unable to Receive Directed Advertisements

karl — Wed, 13 Jan 2016 18:10:33 GMT

Hi Petter, My peripheral is an nRF51 PCA10028 development board. My peripheral application code is based on your ble peripheral hrs example provided in SDK 10.0.0. But I'm not using the ble_advertising module which was used by the original hrs code. My application is interfacing directly to sd_ble_gap_adv_data_set and sd_ble_gap_adv_start.

My Central is an nRF51 PCA10000 dongle connected to a Windows 10 notebook computer. The application code is based on the heart rate collector example code that came with the Win 0.5.0 BLE driver. The scan window is 50ms and the scan interval is set to 100ms. My application requires the Central to also broadcast beacons every 50ms, so I'm running a thread that alternates between sd_ble_gap_adv_start and sd_ble_gap_adv_stop every 25ms. However I don't believe this is related to my problem with the direct advertisements because I still cannot connect if I disable the beacons.

If I switch the peripheral advertisements to connectable undirected with 20ms adv interval, my central receives the advertisements and my application is able to connect using sd_ble_gap_connect. So it appears my central scanning is working.

By the way, when scanning for direct advertisements, is it up to the application to examine the peer_adr in the adv report and determine if the advertisement is targeted for him, or does SoftDevice do this automatically?

RE: Unable to Receive Directed Advertisements

Petter Myhre — Wed, 13 Jan 2016 08:20:32 GMT

Yes. I used the Windows BLE Driver 0.5.0. Could you explain a bit more on how are you testing this?

RE: Unable to Receive Directed Advertisements

karl — Tue, 12 Jan 2016 19:31:01 GMT

Yes, I verified the Initiator address and the RxAdd bit using the sniffer tool and WireShark.

Did you use a Win32 console application to control the Central? I'm wandering if my problem has something to do with that.

RE: Unable to Receive Directed Advertisements

Petter Myhre — Tue, 12 Jan 2016 16:01:56 GMT

Seems to be working fine here. Are you sure the device address and address type included in the advertising packet matches with the central you are sending to? The SoftDevice will only forward directed advertising events to the application with matching device address and address type.