WICED Studio Bluetooth

[FrGu_4702376]

Dear Cypress,

We are developing a new version of our product using the CYBT-413034-02. The product is a Bluetooth 'access point' that is scanning for incoming advertisement messages from surrounding peripherals, parsing the payload and then forwarding this to the network.
This system is applied in the 'smart building' industry and we are supplying to international parties such as Microsoft, Ernst&Young, Heineken and Unilever, as well as other large parties in Commercial Real Estate and airports. We are running into some technical issues with our latest product development and hope you can help us in resolving this.

While our device is scanning for incoming BLE advertisements using 'hcitool lescan', we are noticing that packet loss is quite high.
Our peripherals are sending bursts of 0.5s every 30 seconds, and each burst has unique payload. We see in btmon that duplicate-filtering is enabled so we expect one message to come in every 30 seconds, but we are often (>30%) missing these packets. However, when we disable the duplicate-filtering: 'hcitool lescan --duplicates', we reliably receive a burst every 30 seconds, with multiple packets per burst.

It looks like the bluetooth controller is not able to process all incoming messages when 'duplicate-filtering' is enabled. However, from our application we are using higher-level BlueZ mgmt api, which does not allow disabling of duplicate-filtering. Could you help us in understanding and resolving this? Could you explain how the duplicate-filtering is done and if there are any limitations in computing that might cause the 'package-loss' or how we might improve performance?

[SheetalJ]

Hi frgu_4702376​,

Can you please this help article to understand Duplicate Filtering- BLE Central unable to Receive Multiple Advertisement Packets from Peripheral – KBA220285

I think this might solve your doubt.

If you enable the maximum scan interval and scan window, device will continuously scan for maximum time to see if there are any advertising devices around. This will increase the chance of receiving the advertising packet on the first scan.

[FrGu_4702376]

Hi @SheetalJ_96,

Thanks for you response.

Unfortunately from Linux userspace, using mgmt-api it is not possible to disable duplicate-filtering and BlueZ developers said this will not likely be supported in the near future. Our application uses mgmt interface, but because of this I'm using the hcitool to do root-cause analysis into why we're missing the packets.

We already looked into the window length too, but the scan window is smaller (default for hcitool = 10seconds) than the interval of sending a new burst (30 seconds). I would therefore expect that any burst would be treated as a new, non-duplicated packet.

I failed to mention that our peripheral is also sending beacon packets at 100ms intervals, which might trigger the duplicate filtering. Could you tell me if the payload is actually inspected in the filter, or if only it only looks at the device' mac_address?

As a reference for my test method: I'm running hcitool for scanning, and then running btmon to monitor the results, using grep for filtering a particular device serial. Judging from the fact that hcitool lescan --duplicates gives me many more results, I'm excluding the possibility that my setup is not able to handle the throughput. Therefore my suspicion is that the CYBT-413034-02 is too busy processing all the incoming messages when duplicate-filtering is enabled. I rarely miss packets in 'smaller' projects with ~20 peripherals, but I miss a lot of packets in scenarios with >100 peripherals. Is there some kind of limitation on the number of devices that can be filtered, or are there other throughput constraints that could cause the missing packets?

[SheetalJ]

Hi frgu_4702376,

Central only looks at the device address of the peripheral while filtering duplicate packets. There is no role of payload here.

I do not have the exact number, but there is some limitation on the number of devices which can be filtered (definitely less than 100). It is possible that higher number of devices advertising is causing the loss of packets.

[FrGu_4702376]

SheetalJ_96​, again thanks for the clarification. This confirms my suspicion of the root-cause of our issue, but I don't know yet how to overcome this . Could you tell me if there is any option to disable the filtering altogether (even if kernel/host continuously attempts to enable it)?

Additionally, just to confirm that I understand your explanation about scan window and interval: is the duplicate filtering reset after every window? In other words, if my peripheral is advertising continuously then I can expect a message in btmon after every scan window (filter should see it as a 'new' device again)?