Hi Marcel. I started implementing service scanning and I have a questions: We initially agreed on version that uses le deduplication that needs to be restarted after each device found. When I started looking into that it's going to be much more restarting: - need to restart after each packet from device that advertise service we're interested that's not in RSSI range. That's because controller that I use doesn't send advertisement again when RSSI changes. - need to restart every 0.5 or 1 second in case when some device added service I'm interested at to it's advertisement Can we conseider implementation using le scan without deduplication, and do packet de-duplication in kernel in hci_le_adv_report_evt ? I've started implementing it this way and it works really nice. The issue here might be that it might consume more energy. On Fri, Oct 10, 2014 at 8:49 AM, Jakub Pawlowski <jpawlowski@xxxxxxxxxx> wrote: > Thanks for info! > > I'll look into that. > > On Fri, Oct 10, 2014 at 3:52 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: >> Hi Jakub, >> >>>>>> Ok, new updated version - we do only passive scan, and we send Device >>>>>> found event: >>>>>> >>>>>> >>>>>> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt >>>>>> index 11e2490..3d03617 100644 >>>>>> --- a/doc/mgmt-api.txt >>>>>> +++ b/doc/mgmt-api.txt >>>>>> @@ -2135,6 +2135,29 @@ Set Public Address Command >>>>>> Invalid Index >>>>>> >>>>>> >>>>>> +Start Passive LE Filtered Device Scan >>>>>> +======================= >>>>>> + >>>>>> + Command Code: 0x003A >>>>>> + Controller Index: <controller id> >>>>>> + Command Parameters: UUID (16 Octets) >>>>>> + max_pathloss (1 octet) >>>>>> + >>>>>> + Return Parameters: >>>>>> + >>>>>> + This command starts passive LE scan, and filter received >>>>>> advertisements: if AD contains both TX power level and Service >>>>>> Solicitation, and UUID is contained in Service Solicitation and >>>>>> computed pathloss is smaller than max_pathloss parameter, then a >>>>>> Device Found event will be sent. >>>>> >>>>> generally we tried to avoid to specific LE only commands. Our attempts with the kernel APIs where to make them as generic as possible. So I think something along the lines of adding and removing UUID filters should be something we should target at. >>>>> >>>>> Add UUID Notification Filter >>>>> ============================ >>>>> >>>>> Command Parameters: Address_Type (1 Octet) >>>>> UUID (16 Octets) >>>>> Max_Pathloss (1 Octet) >>>>> Return Parameters: Address_Type (1 Octet) >>>>> >>>>> >>>>> Remove UUID Notification Filter >>>>> =============================== >>>>> >>>>> Command Parameters: Address_Type (1 Octet) >>>>> UUID (16 Octets) >>>>> Return Parameters: Address_Type (1 Octet) >>>>> >>>>> The Address_Type would be defined the same way as for Start Discovery command. >>>>> >>>>> Now we can discuss if on the mgmt level we want to use pathloss or rather a range of RSSI. I have seen that RSSI is preferred and that the translation from RSSI and advertising data with TX power level is done in the daemon. So for kernel API it might be better to expose RSSI range. >>>>> >>>>> Besides a RSSI range, we might also want to allow giving a RSSI threshold that defines how much the RSSI to change between events to be reported again. >>>> >>>> Some mobile devices that I'm working can change power level for >>>> advertising, that makes raw RSSI filter useless. It must be pathloss, >>>> that's why I require TX power in advertisement. >>> >>> you will still get it, but just have to do the math in the daemon. The only difference is that the daemon gets woken up for RSSI ranges that in the end you might filter out. >>> >>>>> >>>>> That said, the danger with a generic notification filter like this is that we can not implement it efficiently with current hardware without vendor commands. If you use duplicate filtering, then Broadcom and CSR chips behave fully different. Broadcom only filters on BD_ADDR and report devices once no matter what the RSSI, while CSR will report the same device again if the RSSI changes. >>>>> >>>>> With that in mind, it might be safer to introduce a one-shot mgmt API that needs to be repeatedly called to keep scanning for new devices. >>>>> >>>>> Start Service Discovery >>>>> ======================= >>>>> >>>>> Command Parameters: Address_Type (1 Octet) >>>>> Min_RSSI (1 Octet) >>>>> Max_RSSI (1 Octet) >>>>> Num_UUID (1 Octet) >>>>> UUID[i] (16 Octets) >>>>> Return Parameters: Address_Type (1 Octet) >>>>> >>>>> Stop Service Discovery >>>>> ====================== >>>>> >>>>> Command Parameters: Address_Type (1 Octet) >>>>> Return Parameters: Address_Type (1 Octet) >>>>> >>>>> Without having dedicated controller support for filtering, having such a dedicated discovery for services with a specific UUID seems to be more appropriate and more safe. Since we could always add controller based filtering for background scanning once there is controller support. >>>> >>>> I preffer the "Add UUID Notification Filter" and "Remove UUID >>>> Notification Filter". For controllers like Broadcom that reports only >>>> one advertisement can we restart scan internally in kernel ? Why >>>> propagate that event higher ? >>> >>> Personally I would prefer just adding another filter as well. However it might be better to start with something like a one-shot handling and see where that is taking us. It is a little bit less intrusive and you could also use active scanning. At the same time you could also easily make it work for BR/EDR. I am thinking here along the lines of something wanting to pair a mouse. You just give the HID UUID and start interleaved discovery for that service on both transports. >> >> I send a proposal for doing an one-shot service discovery. So you can propose a RSSI Threshold and a list of possible UUIDs to look for. >> >> If RSSI Threshold is 127 or the Num_UUID is 0, then it will behave the same way as Start Discovery. I think this is how we should get started to tackle this problem. >> >> Regards >> >> Marcel >> -- 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
