HCI USB firmware based on nRF Connect SDK 1.7.0 doesn't filter duplicate advertising reports

[Adrian Eggenberger]

Hi

I've built a USB HCI fimrware based on the sample from the nRF Connect SDK for the nRF52840DK.

See also: (+) HCI USB based on nRF Connect SDK 1.7.0 failed to update connection parameter from slave - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com)

Our application tries to scan for advertisings with the option to filter out duplicates.

Independently to the switch to filter duplicates the reports contain the same device multiple times. It seems that the "filter dupliate" switch is ignored.

See my recorded capture of the HCI communication:

/cfs-file/__key/communityserver-discussions-components-files/4/CaptureB.cfa 

Time: 0.085 => Start scan with filter duplicates
Time: 0.131 => First report from the device f1:50:7a:ad:b9:5e
Time: 0.169 => 2nd report for the same device
Time: 0.217 => 3rd report for the same device

Is it possible that the "filter duplicates" setting is ignored?

Regards Adrian

[Edvin]

Hello Adrian,

Indeed, the Softdevice Controller (Nordic's Bluetooth stack in NCS) hasn't implemented the "filter duplicates" filter. There has been some discussions internally about this, and it doesn't really make sense to implement this filter, as it takes up space, requires a lot of memory, and is not very commonly used. The workaround is to implement such a filter in the application. You need to store the addresses that you see an advertisement from and check whether or not the next advertisement's advertising address is already present in the list. 

Best regards,

Edvin

[Adrian Eggenberger]

Hi Edvin

Thanks for your explanation. So my observations where correct so far. I can totally understand your point from the prospective of the Softdevice Controller. We also never used the duplicate filter in our products.

On this particular project we provide a HCI USB device that should follow the bluetooth core specification as close as possible. If the duplicate filter is used or not should be decided by our customer who implements the application.

In earlier releases we used the Zephyr Bluetooth stack implementation (CONFIG_BT_LL_SW_SPLIT=y) for our project. There the duplicate filter is implemented as specified. We thought that it might me the right way to go in the future if we switch to the Nordic's Bluetooth Stack as it seems to be the recommended stack for Nordic SoC's. Is this maybe not the right decision for a HCI USB project? 

Should we stick with the Zephyr implementation in the future? Do you see any negative impacts for a HCI USB project in using the Zephyr Bluetooth stack?

Regards Adrian

[Edvin]

I meant to include this link in the previous reply, but I forgot it:

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

That is the known issues link for the duplicate filter not being implemented.

As long as the Zephyr stack works for the HCI USB project, and you want the option to enable the duplicate filter, I guess there is no problem using Zephyr's BLE stack. 

New features will be implemented from our side on the Nordic BLE stack, and we are continuously working on making it more power-efficient for battery based products. I guess that is not really that important in a USB device either. 

It is only a couple of years since we started working on NCS/Zephyr. Before that we didn't support HCI, so all customers requesting it was redirected to Zephyr, which already had it working on our chips using their own BLE stack, so I would say that for an HCI project, it is a pretty well-tested choise. 

Best regards,

Edvin

[Adrian Eggenberger]

Hi Edvin

Thanks for your response. I've decided to go the way with the Zephyr Stack for this particular project. For HCI USB it looks like the better choice for now.

What about support for issues with the HCI USB sample. It is mostly based on the Zephyr code so the Zephyr support team would be right spot. On the other hand it's mostly related to using Zephyr with Nordic Devices  and therefore a Nordic topic somehow. What support team would be the better choice?

Regards Adrian

[Edvin]

I guess it depends on the question. For strictly Zephyr related questions, I would think that the Zephyr support team has more knowledge, but I guess you can create a ticket in both instances (zephyr support and here on devzone). 

If you have questions regarding hardware or PCB layout, that would probably be more relevant to ask here on DevZone. I guess an HCI USB application is not something you need to modify too much, but I haven't looked too much into that sample, since it is traditionally handled by the Zephyr support. 

Best regards,

Edvin