On Tue, Dec 9, 2014 at 10:01 AM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: > Hi Jakub, > > On Tue, Dec 09, 2014, Jakub Pawlowski wrote: >> > Same as we should check for HCI_QUIRK_STRICT_DUPLICATE_FILTER >> > setting and only do the restart scan stuff if the driver told us >> > that this controller is not providing multiple reports. >> >> So I did some tests on 4 controllers I described in this email: >> http://marc.info/?l=linux-bluetooth&m=141764424929887&w=2 >> I think that HCI_QUIRK_STRICT_DUPLICATE_FILTER wil be valid if we were >> doing HCI_OP_INQUIRY, when I was using HCI_OP_LE_SET_SCAN_ENABLE with >> LE_SCAN_FILTER_DUP_ENABLE none of the controllers I used reported >> device twice with different RSSI except for marevell, which seems to >> ignore >> LE_SCAN_FILTER_DUP_ENABLE, and reports all advertisements. >> >> The way I conducted this tests was to start the scan "tools/mgmt find >> -l", and try to approach (15-20 meters) or move away from scanning >> device, walk back and forth, or just keep the advertiser in place. I >> was monitoring both btmgmt output and dmesg kernel logs (I added some >> additional BT_INFO to make sure I won't miss anything) >> >> Do you have different experience for LE scan ? Or maybe I just picked >> wrong controllers for my tests ? > > Please add CSR dongles to your mix. The most commonly available one is > probably the PTS dongle. They also report multiple advertisements as the > RSSI changes. Thanks for info! I'll test on them, and modify my code to make sure that they work ok. > > Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html