DIRECTED ADVERTISING NOT WORKING...?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hello,

  I have recently been trying to use DIRECTED_ADVERTISING mode to directly advertise to a prior device.  What always appears to happen is that the last 2 bytes of the Client BD Address are not getting handled correctly using Direct Advertising.  I have verified this by the following...

1) I print out the stored BD Address of the client so I know it is the correct address from the prior paired/bonded event.

2) There are numerous examples of loading a Remote_Addr into the bleprofile_Discoverable() function and it works perfectly fine with using UNDIRECTED advertisements though I guess this is somewhat of a misnomer including the REMOTE_ADDR while using UNDIRECTED Advertisements as it really doesn't matter.

3) I never see the peripheral during a scan from the client.

4)  When I look at the Debug Output I see the following...

01:24:31   direct adv[5:2]: 70 59 49 63

01:24:31   direct adv[1:0]: 00 00

The top line is exactly what I would expect as to what I am supplying as the Remote_Addr but as you can see the last 2 bytes are zero no matter what I do.  I am using SDK2.1

Part 2:  Correct me if I am wrong but a 'DIRECTED_ADVERTISEMENT' will ONLY show up at the client address that the Remote_Address is targeted to, correct?  At least that is what the Core Spec appears to indicate...

pastedImage_4.png

Regards,

Frank

0 Likes
1 Solution
ShawnA_01
Employee
Employee
10 questions asked 5 comments on KBA First comment on KBA

Hi Frank,

I am not sure if your problem is the exact same on another customer CSP case I had, but I was informed we should not try to use the built in state machine for directed adv.   Maybe the text below will help you too?

And per our Hero (you know who I am referring to, whose initials are A.S.).... he gave me the following info:

Its better to do it using the lower level API.  Set BLE_PROFILE_CFG.default_adv = NO_DISCOVERABLE. This will turn off the profile level state machine. Just like you register for the advertisement stop callback event, register for the directed adv stop callback event in your application's create function, as follows:

void app_directedAdvStopInd(void);

void _application_create(void)

{

  extern void bleprofile_regAppEvtHandler_DirectedAdvStop(BLEPROFILE_NO_PARAM_CB handler);

  // do all other init

  // Register callback when directed adv stops. Directed adv lasts only for a max of 1.28s. When no connection

  // is established in this time, directed adv will stop and this callback will be invoked. Apps typically switch to

  // regular undirected adv in this callback.

  bleprofile_regAppEvtHandler_DirectedAdvStop(app_directedAdvStopInd);

}

void app_directedAdvStopInd(void)

{

  // Do undirected adv here.

}

And when you are ready to start directed adv:

void app_start_directedAdv(void)

{

      // start advertise.

      blecm_startAdv(

          BLECM_ADV_CONNECTABLE_DIRECT_EVENT,      //// Start directed adv.

          32,                                                                                         //// 1.28 seconds adv interval. This parameter will be ignored.

          BLECM_ADV_CHANNEL_MAP_MASK ,                       // all channels.

          BLECM_PUBLIC_ADDRESS,

          BLECM_ADV_FILTER_POLICY_WHITE_LIST_NOT_USED, // int advFilterPolicy,

          bdAddrType,                                                                     //  int initiatorAdrType, peer address type.

          bdAddr                                                                              //  BD_ADDR of the host we are trying to connect to. valid for Directed Adv.

      );

}

In my case I was using an iPad, and AS told me "I" may not be 'see'ing  this device with LightBlue because iOS may be blocking directed adv.


Good luck.

View solution in original post

8 Replies