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.
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?
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.
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)?