Issue in using option "BT_LE_SCAN_OPT_FILTER_DUPLICATE" from version v1.3.0 to v1.4.0

[unknownvendor]

Hello,

I am using NCS v1.3.0 and nrf52840 dk board. In the central_uart demo example, there is a macro called "BT_LE_SCAN_PASSIVE" which has an option set as  "BT_LE_SCAN_OPT_FILTER_DUPLICATE" which filters out the device address in the cb when multiple advertisement packets come from the same device address. I cross verified this by printing the device address in the "scan_device_found" routine which is available in scan.c file. (...\ncs\v1.3.0\nrf\subsys\bluetooth\scan.c)

Now, when I shifted to NCS 1.4.0 with the same board. In the central_uart example, there is a macro called "BT_LE_SCAN_PASSIVE" which has an option set as "BT_LE_SCAN_OPT_FILTER_DUPLICATE" which SHOULD have filtered out the device addresses. But I see the same result as "BT_LE_SCAN_OPT_NONE" option (which does not filter out the device addresses ). In order to see the expected results, I added this config option in the prj.conf file - "CONFIG_BT_LL_SW_SPLIT=y". After adding this option, I was able to see the filtering. In 1.4.0, "bt_le_scan_start" has "NULL" as it's callback so I modified the  scan.c file a little bit. 

Changes which I did:

1) line 1537 in scan.c - int err = bt_le_scan_start(&bt_scan.scan_param, NULL); - changed NULL to scan_device_found ( int err = bt_le_scan_start(&bt_scan.scan_param, scan_device_found);  and added the following function in the same file.

static void scan_device_found(const bt_addr_le_t *addr, int8_t rssi, uint8_t type,
struct net_buf_simple *ad)
{
  printk("Coming in callback again and again\n");
}

2) comment line 1330 - // bt_le_scan_cb_register(&scan_cb);

 

You will see that the print statement will be printed continuously.

Now add the config option I mentioned above, and try the same procedure again which will only result in a couple of print statements proving that the callback is only called when the new device address is found which is the expected result with "BT_LE_SCAN_OPT_FILTER_DUPLICATE" option.

When I add this particular config option, I am changing the controller portion of the stack from Nordic to Zephyr and I am able to get the expected results.

Picture on the left is the one without setting config option and picture on the right is with config option.

So is this the correct way I am testing in v1.4.0, if not could you tell me how shall I test it? Is there an issue with the controller portion of the Nordic stack?

Thanks

 

 

[Edvin]

Hello,

I am terribly sorry for the slow response.

I see that you added the "coming in callback again and again" is something you have added. Please note that there is an "insert -> code" option on devzone, to insert code so that the formatting is not ignored.

Is this callback always coming from the same device, with the same address? And is this the address of one of the devices you are already connected to?

Is it possible to zip attach the projects that you are using to replicate this so that I can try on my own setup?

Best regards,

Edvin

[unknownvendor]

I have attached 3 zip folders for your reference.

(you might have to change the name of the folder in order to build these projects)

1) central_uart_v1.3.2 - You will see that the device addresses are not repeated at all. You might see some addresses coming 2 times, but that's the adv type 0 and 4. The option is set to "BT_LE_SCAN_OPT_FILTER_DUPLICATE".

2) central_uart_v1.4.99-dev1_without_config - You will see that the same address come again and again even if the scan option is set to "BT_LE_SCAN_OPT_FILTER_DUPLICATE"

3) central_uart_v1.4.99-dev1_with_config - You will see that the same address WILL NOT come again and again when the scan option is set to "BT_LE_SCAN_OPT_FILTER_DUPLICATE". In this I have set the config option as CONFIG_BT_LL_SW_SPLIT=y (you can find it in the prj.conf file)

   4643.central_uart_v1.3.2.zip          8666.central_uart_v1.4.99-dev_without_config.zip      2313.central_uart_v1.4.99-dev1_with_config.zip    

[unknownvendor]

Yes, you can keep ".connect_if_match = 0," to avoid connection.

When you run "central_uart_with_config" - Note that you see the duplicates only 2 times, which is correct. It is because of advertising data and scan response data.

When you run "central_uart_without_config" - You will see the duplicates many times (Continuously printing)

That's the difference.

Can you post terminal screenshot of both these code by keeping "connect_if_match=0" and NOT editing the scan_init() function?

..\ncs\v1.4.2\zephyr\include\bluetooth\bluetooth.h - File where  "BT_LE_SCAN_OPT_FILTER_DUPLICATE" is set

[unknownvendor]

Hello,

Do you have any update?

Thanks

[Edvin]

Hello,

Sorry again for the late reply.

I talked to our Softdevice Controller team, and they said that the BT_LE_SCAN_OPT_FILTER_DUPLICATE is not implemented in the Softdevice Controller, which is the BLE stack that Nordic delivers. The reason that it was working in v1.3.0 was probably that the default BLE controller in that version was the Zephyr controller. From 1.4.0, the default BLE controller is the SoftDevice Controller from Nordic. 

As far as I know there are no plans to implement this filter in the softdevice controller. If you want to do this filtering, it needs to be applied in the application layer. 

It would be quite simple, I believe. Just keep track of the last N advertisement addresses in a circular buffer, and check whether or not the received advertisement is using an advertisement address from your buffer or not. Please be aware that by using such a filter, you will not receive any scan responses.

Best regards,

Edvin

[variant]

How does someone know which Zephyr options are not implemented in a Nordic Softdevice (SD) Controller?  

If I go to the Zephyr documentation for the BT_LE_SCAN_OPT_FILTER_DUPLICATE, would I know that that option is a Zephyr BLE controller option and not a Zephyr BLE host option?  If we know what options are controller options, then we would have to know to check if we are using the Nordic or Zephyr controller to determine if that Zephyr option is supported.  Right?

[Edvin]

Hello,

This one, in particular is going to be added to the known issues page. It is currently waiting to be approved:

https://github.com/nrfconnect/sdk-nrf/pull/4122/commits/27e8b3bc4aec1d321334da26b014b7afe3aea14d

But it should be up soon. 

Best regards,

Edvin