On Mon, Oct 20, 2014 at 11:06 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
> 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.
>
> Regards
>
> Marcel
>
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 can also set the RSSI threshold at very low value to get notified
about temperature sensor, but the I'll get a lot of device found
events about security token that will wake my application unnecessary.
We want to avoid that, and that's why we're doing scan in kernel, and
plan to move it to controller.
So my patches right now define rssi threshold per UUID this like that:
struct mgmt_uuid_filter {
__s8 rssi;
__u8 uuid[16];
} __packed;
struct mgmt_cp_start_service_discovery {
__u8 type;
__le16 filter_count;
struct mgmt_uuid_filter filter[0];
} __packed;
--
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
