Hi Jakub,
>>>>>> I think that RSSI_Threshold should be per UUID:
>>>>>>
>>>>>> + Command Parameters: Address_Type (1 Octet)
>>>>>> + Num_Filters (1 Octet)
>>>>>> + Filter1 {
>>>>>> + RSSI_Threshold (1 Octet)
>>>>>> + UUID[i] (16 Octets)
>>>>>> + }
>>>>>> + Filter2 {}
>>>>>> + ...
>>>>>
>>>>> I need a bit more reason for this. Stating it does not convince me ;)
>>>>>
>>>>> My take is that it is not needed for this one-shot discovering. Just select some good enough RSSI threshold and filter the rest later when you get TX power information. Like with Start Discovery it will stop once it is done with the search. So next time around you can select a different RSSI threshold.
>>>>
>>>> Let's say I'm scanning for two kinds services:
>>>> - some security token, that needs to be very close to my machine
>>>> - temperature sensor, with no particular interest in range
>>>> - controller receives one packet from security token that advertise at
>>>> very high TX power and is very close, so I specify very high rssi
>>>> threshold
>>>> - then the temperature sensor, that advertises on low power will not be reported
>>>>
>>>> If I had rssi specified per UUID that won't be the case.
>>>
>>> I think having that is a good idea in general. Just not in the case of a one-shot discovery trigger. We should do that for adding these UUID filters to the background scanning.
>>>
>>> The difference between discovery and background scanning is that during discovery we are using active scanning (meaning scan responses will be requested) and during background scanning we are using passive scanning.
>>>
>>> So my thinking is that you use the service discovery to find your device/service now. You are actively looking for it at that point in time. In that case it really does not matter that you get a few false positives. You are actively using your radio to send scan requests anyway.
>>
>> Ok, I'll modify my patches so that start service discovery would get
>> only one rssi value for all services.
>>
>
> I just fixed my patches work as you described in doc/mgmt-api.txt
> Writing it as you proposed made the code much simpler and cleaner. Thanks!
> Can you please 'git am' this doc/mgmt.txt patch, or is there something
> more to do ?
I pushed the doc/mgmt-api.txt updates now.
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
