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
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

We will work with the developers to see if we can provide some guidance on this one Frank.

0 Likes
Anonymous
Not applicable

Hello Frank,

1.  Unfortunately the development team has listed this as a bug that will not be fixed.

2.  You can print out contents of extern BD_ADDR bleprofile_remote_addr; to confirm that it is advertising right.

3.  Yes, only the scanner that is being addressed in the directed adv will see it.

4.  You may also decide to use a Frontline Sniffer as well.

Thanks

JT

0 Likes
Anonymous
Not applicable

Hi JT,

  Yes I understand how to print out the BD Address that is one of the ways I was verifying what I was sending out in the DIRECTED Advertising was correct.  This is rather disappointing because on top of this White Lists are not functional on the BCM2073x platform.  So that being the case how does Broadcom propose to ONLY allow a device to connect/pair to a priorly connected device while not allowing others to connect to it during an Advertising Event?  Being that White Lists are not functional and DIRECTED Advertising does not work I am not seeing how this is possible which ultimately means any Client can ultimately be allowed to connect/pair with a BCM2073x based Peripheral.  We have a need to have this functionality and not seeing a way to handle this case.

Regards,

Frank

0 Likes

My understanding is that the bug is in *printing* the bd address, not in the directed advertisements themselves; So essentially we are not planning on fixing the traces.

0 Likes
Anonymous
Not applicable

That is quite strange as I have tried just about everything I can think of to get the DIRECTED_ADVERTISEMENTS to work including using a simple example like Hello_Sensor and it never shows up as an advertisement to the Client.  As an example take the Hello Sensor example and in the Connection_Down() and Advertising_Stopped() functions replace the LOW_UNDIRECTED with HIGH_DIRECTED and populate in the ble_profile_cfg structure some valid Intervals/Duration values for DIRECTED advertising it does not work? 

  Another interesting thing is that again using the simplest example hello_sensor what is read as the bda address of the client via emconninfo_getPeerPubAddr() provides an address that does not match the Client address I am using but is always the same each time so I would have to assume it is not a Private Random Address otherwise it would be different each time.  The address that the emconninfo_getPeerPubAddr() provides the following address every time for the same device when it pairs.

hello_sample, encryption changed 020100200400

the actual BD Address of my iPhone when I look at the settings is 2C: BE: 08: C6: AB: C0?

Later after the encryption has been done and in the smp_bond_result() the bda address changes to a different BD address which I would have to assume is the Private Address since the secure pairing/key exchange has been completed and the device is bonded to the client. 

Regardless, I have tried feeding each of these addresses into a HIGH_DIRECTED advertisement and none of them end up being seen by the client?  Maybe I am missing something obvious but I would appreciate if you could try this yourself.  Here is the simple changes to the hello_sensor app to try yourself.

You can use the following variable definition to force your own BD Address of say an iPhone by finding its BD Address in its BT settings...

BD_ADDR iphone        = {0xC0, 0xAB, 0xC6, 0x08, 0xBE, 0x2C};

void hello_sensor_connection_down(void)

{

    ble_trace1("handle:%d\n", hello_sensor_connection_handle);

    ble_trace0("sensor_connection_down()\n");

    memset (hello_sensor_remote_addr, 0, 6);

    hello_sensor_connection_handle = 0;

    // If we are configured to stay connected, disconnection was caused by the

    // peer, start low advertisements, so that peer can connect when it wakes up.

    if (hello_sensor_stay_connected)

    {

            //This line can be used to force a particular Client BD Address, leave commmented to use the bdaddr that is   //             read and stored in hostinfo.bdaddr from emconninfo_getPeerPubAddr()  

//        memcpy(hello_sensor_hostinfo.bdaddr, emcon_iphone, sizeof(BD_ADDR));

        bleprofile_Discoverable(HIGH_DIRECTED_DISCOVERABLE, hello_sensor_hostinfo.bdaddr);

        ble_trace2("ADV start: %08x%04x\n",

                      (hello_sensor_hostinfo.bdaddr[5] << 24 ) + (hello_sensor_hostinfo.bdaddr[4] <<16) +

                      (hello_sensor_hostinfo.bdaddr[3] << 8 ) + hello_sensor_hostinfo.bdaddr[2],

                      (hello_sensor_hostinfo.bdaddr[1] << 8 ) + hello_sensor_hostinfo.bdaddr[0]);

    }

}

void hello_sensor_advertisement_stopped(void)

{

    ble_trace0("ADV stop!!!!");

    // If we are configured to stay connected, disconnection was caused by the

    // peer, start low advertisements, so that peer can connect when it wakes up.

    if (hello_sensor_stay_connected)

    {

            //This line can be used to force a particular Client BD Address, leave commmented to use the bdaddr that is   //             read and stored in hostinfo.bdaddr from emconninfo_getPeerPubAddr()  

//        memcpy(hello_sensor_hostinfo.bdaddr, emcon_iphone, sizeof(BD_ADDR));

        bleprofile_Discoverable(HIGH_DIRECTED_DISCOVERABLE, hello_sensor_hostinfo.bdaddr);

        ble_trace2("ADV start: %08x%04x\n",

                      (hello_sensor_hostinfo.bdaddr[5] << 24 ) + (hello_sensor_hostinfo.bdaddr[4] <<16) +

                      (hello_sensor_hostinfo.bdaddr[3] << 8 ) + hello_sensor_hostinfo.bdaddr[2],

                      (hello_sensor_hostinfo.bdaddr[1] << 8 ) + hello_sensor_hostinfo.bdaddr[0]);

    }

}

Regards,

Frank

0 Likes
Anonymous
Not applicable

BTW - I believe there is a work-around being that I can't seem to get the DIRECTED Advertisements to work which is to manually screen the Client BD addresses when the connection first occurs but what I still am not understanding is why the address from emconn_getPeerPubAddr does not match the BT address shows in the phone settings prior to the Key Exchange?

Regards,

Frank

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

Anonymous
Not applicable

Hey Shawn,

  You were on the right track here.  After doing further research on the iOS Side it has been validated that for some brilliant reason iOS does not allow 'Directed Advertisements'.  Question Answered.  Thanks Guys!!