Unable to Receive Directed Advertisements

[karl]

For some reason I'm not able to receive directed advertisements on the nRF51 development kit. I verified my nRF51 peripheral is sending the direct advertisement packets using the Sniffer tool, but the I don't see any BLE_GAP_EVT_ADV_REPORTS being generated on the central while its scanning.

The central does however see the advertisements if I configure them on the peripheral as connectable undirected.

I'm using SDK 10.0.0 for the peripheral and Windows BLE Driver 0.5.0 for the Central.

Thanks

[Petter Myhre]

@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?

[karl]

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

[Aaron Bilger]

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...

[Aaron Bilger]

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.

[Petter Myhre]

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.