CC2340R5: Basic BLE example and non-connectable advertising.

Hi,

Thank you for reaching out. Can you confirm the SDK version you are using? When running the program is debug mode, can you check if the code is hanging?

Best Regards,

Jan

simplelink_lowpower_f3_sdk_7_20_01_10 

Installed a fresh copy of the basic_ble example.

Compiled and ran with the terminal so that I can see output from device.

I see my BLE RP address is... 0x.......

I check in sniffer and I see many ADV_IND packets coming from that address.

Next open sysconfig

Go to BLE, then Broadcaster Configuration

Pick Advertisement Parameters 1

Change "Connectable and scanable undirected" to "Non-Connectable and non-scanable undirected"

recompile, run debug

get new addresses from terminal.

look in sniffer, observe device is not generating ADV_NONCONN_IND packets.

App is not obviously hung, it goes through app_main and stops in vTaskStartScheduler() which it should do.

Shouldn't changing this setting in Sysconfig work to generate non-connectable advertising packets? Or is more code change needed?

Jon,

This looks like it could be a similar issue to the other thread you posted. Let me know if you still see the same issue once you install Sysconfig v1.17.0 and retry the steps as detailed above. I will test on my end in the meantime as well.

Thanks,
Luke

I just checked with 1.17 - same behavior as 1.18.

It is setting the advertising parameters like this:

When I check in the sniffer it is not advertising. I when I set it back to scanable I can see the device.

I know the sniffer can see non-connectable adverts...

Those ADV_NONCONN_IND are Apple Air Tags someone is carrying near me. I should see ADV_NONCONN_IND packets from the CC2340r5 with the above settings, but I don't see anything.

Jon,

I am still working on duplicating this effort on my end and can not think of a cause for this off the top of my head. I would recommend you take a look through the Scanning and Advertising section in SimpleLink Academy for the CC23xx devices if you have not yet to provide some more detail into the differences between the advertisement types and their functionality.

Thanks,

Luke

I find it a little odd that there is no member of the enum for nonconnectible.

From gap_advertiser.h

/// GAP Advertising Event Param Properties
enum GapAdv_eventProps_t
{
  GAP_ADV_PROP_CONNECTABLE =  BV(0),  //!< Connectable advertising
  GAP_ADV_PROP_SCANNABLE =    BV(1),  //!< Scannable advertising
  GAP_ADV_PROP_DIRECTED =     BV(2),  //!< Directed advertising
  GAP_ADV_PROP_HDC =          BV(3),  //!< High Duty Cycle Directed Advertising
  GAP_ADV_PROP_LEGACY =       BV(4),  //!< Use legacy advertising PDU's
  GAP_ADV_PROP_ANONYMOUS =    BV(5),  //!< Omit advertiser's address from PDU's
  GAP_ADV_PROP_TX_POWER =     BV(6)   //!< Include TxPower in the extended header
                                      //!< of the advertising PDU
};

It mentions non-connectable in the docs, this makes sense that these is no secondary packet. This is only mention I see in the docs.

"If advertising non-connectable and non-scannable, an ADV_EXT_IND PDU with no Adv Data can be sent without an auxiliary packet. In all other cases, the ADV_EXT_IND PDU must contain a pointer to an auxiliary advertisement packet, AUX_ADV_IND. The AUX_ADV_IND PDU is sent on the PHY given in secPhy, and on one of the secondary channels (also known as data channels)."

I believe I found the problem, when you switch over to "Non-Connectable and non-scanable undirected" in the Advertising Parameters you also have to go into the Advertisement Data and clear "LE General Discoverable Mode"

I suspect why there are no packets is because "Non-Connectable and non-scanable undirected" and "LE General Discoverable Mode" are conflicting options. 

Sysconfig probably should clear "LE General Discoverable Mode"  when "Non-Connectable and non-scanable undirected" is selected.

Jon,

I am glad to hear you have found the issue you were facing. In clearing the "LE General Discoverable Mode" when "Non-Connectable and non-scannable undirected" is selected, were you able to see the ADV_NONCONN_IND packets from the CC2340R5 as expected?

Thanks,

Luke

Shuyang, 

Your assumption sounds correct. Does changing this from 0 to NULL alleviate the issue or are you still unable to see the expected packets? I can work to recrate this on my side as well but want to understand your point correctly first. 

Thanks,

Luke

Yes, it alleviates the issue. I can see the broadcasting after the changes.

Shuyang,

Great, thanks for sharing that solution!

Best regards,

Luke

Thanks Jon! Will pass this along to our internal team.

Best regards,

Luke