• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 263 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2651R3SIPA: Update Random Address for Adv

Jaco Pretorius
Prodigy 20 points
Part Number: CC2651R3SIPA

Tool/software:

When an advertising set is created, I can Update the adv data by calling GapAdv_loadByHandle(). This works fine. How do I update the random address that will be used as the MAC address? 

It was passed with this function (GAP_DeviceInit() ) when the GAP device was initialised, but I want to update it to other values as I load new adv data.

  • 0
    TI__Expert 5000 points

    Hi !

    If you are using RPA (Resolvable Private Address) for your MAC address, the Bluetooth Core Specifications Version 5.3 specifies a default timeout interval of 15 minutes before the device changes its device address. This can be changed via the GAP_PARAM_PRIVATE_ADDR_INT parameter in GAP_SetParamValue().

    If you are using a static address, you can use GapAdv_setVirtualAdvAddr to change your address, but it can only be done for Legacy Non-Connectable and Non-Scanable PDUs.

    Kind regards,
    Maxence

  • 0 in reply to Maxence Mathieu
    Prodigy 20 points

    Thank you for clearing that for me. What I want to do is alternate between 2 adv packets. I want each one to be transmitted on it own mac address, and each one will have its own payload. Thus it seems that I should rather use static address, as I cannot change the random address in quick succession. I am experiencing a new problem now, and it is probably due to my limited knowledge. When I set my advertising device as Legacy Non-Connectable and Non-Scannable, I no longer get the ADV reports on my central device that scans for advertising packets. I can not see how to set it up differently to still be able to 'hear' the broadcasts. 

  • 0 in reply to Jaco Pretorius
    TI__Expert 5000 points

    Hi !

    It's likely that your non-connectable ADV reports get filtered out by your central, because it considers them "not useful" since the central cannot connect to them. Which scan/central are you using ? Can you still see the advertisements through another mean like a sniffer ?

    Kind regards,
    Maxence

  • 0 in reply to Maxence Mathieu
    Prodigy 20 points

    Hi, My central is also a CC2651R3Sipa device that I've set up to listen to my adv packets. As soon as I make my peripheral not connectable and not scannable, I no longer can see the adv. I do not have a sniffer?

  • 0 in reply to Jaco Pretorius
    TI__Expert 5000 points

    Hi !

    Could you follow this guide to setup your CC2651R3SIPA as a sniffer ? Once this is setup and you have wireshark running, you should be able to see the packets from your peripheral in wireshark.

    Kind regards,
    Maxence

  • 0 in reply to Maxence Mathieu
    Prodigy 20 points

    Hi, I did not manage to set up the sniffer with that guide. It seems that the CC2651R3SIPA  is not supported for that. 

    What I still do not understand is why my receiving CC2651R3SIPA device stopped to be able to receive the ADV packets once I changed the address to be static (and making it to be not scannable and not connectable) . Before that I could receive  the ADV packets on this event: SC_EVT_ADV_REPORT. I know that the transmitter is still working, as my 3r party device does receive the ADV packets, but my own CC2651R3SIPA device does not. Is there a setting to be able to receive ADV reports if the transmitter is not scannable and not connectable?

  • +1 in reply to Jaco Pretorius
    TI__Expert 5000 points

    Hi,

    One reason why your ADV packets are not appearing in the SC_EVT_ADV_REPORT event might be that you filtered them out using the Scanning Filter Policy with GapScan_setParam. It's possible that you use this function somewhere in your code, or that the default value filters out non-connectable and non-scannable ADV packets. One way to fix that would be to call GapScan_setParam with the SCAN_PARAM_FLT_POLICY paramId, and 0 as the paramValue.

    Once you've done that, enable the scanner and see if you can find your packets or not.

    You can read all the possible filter values here.

    Kind regards,
    Maxence

  • +1 in reply to Maxence Mathieu
    Prodigy 20 points

    Thank you, I will look into it.