Re: [RFC] need for new scan api for bluetooth low energy.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
+
+       This command can only be used when the controller is powered.
+
+       This command generates a Command Complete event on success or failure.
+
+       Possible errors:        Busy
+                               Not Supported
+                               Invalid Parameters
+                               Not Powered
+                               Invalid Index
+
+
 Command Complete Event
 ======================


On Tue, Sep 30, 2014 at 10:31 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
> Hi Jakub,
>
>>>> ---
>>>> doc/mgmt-api.txt | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 69 insertions(+)
>>>>
>>>> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
>>>> index 11e2490..1c78f1c 100644
>>>> --- a/doc/mgmt-api.txt
>>>> +++ b/doc/mgmt-api.txt
>>>> @@ -2135,6 +2135,34 @@ Set Public Address Command
>>>> Invalid Index
>>>>
>>>>
>>>> +Start LE Filtered Device Scan
>>>> +=======================
>>>> +
>>>> + Command Code: 0x003A
>>>> + Controller Index: <controller id>
>>>> + Command Parameters: UUID (16 Octets)
>>>> +             max_pathloss (1 octet)
>>>> +             is_active (1 octet)
>>>> +
>>>> + Return Parameters:
>>>> +
>>>> + This command starts 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 Advertisement Received event will
>>>> be sent.
>>>> +
>>>> + Possible values for the is_active parameter:
>>>> + 0 Start passive scan
>>>> + 1 Start active scan
>>>
>>> is really like a one-shot scan? Or is this something you would be running all the time in the background?
>>>
>>> Fundamentally if it is one-shot thing then you always want to do active scan, but if it runs in the background then you only want to do passive scanning.
>>
>> I'm working on two projects, one require scanning up to 2 minutes,
>> second requires long term scanning in background.
>> I'd preffer to have scan type as argument, but having only passive
>> scan is also good option for me.
>
> I prefer to have these as separate commands. So one is actually a specialized active scanning to find a specific set of devices. Similar to Start Discovery. The other is to add an additional filter for our background scanning.
>
> Remember that this has to work in sync with the auto-connection logic that the kernel is running. If you are messing that up, then you might find the device you are looking for, but the HID mouse will not re-connect.
>
>>>> +
>>>> + This command can only be used when the controller is powered.
>>>> +
>>>> + This command generates a Command Complete event on success or failure.
>>>> +
>>>> + Possible errors: Busy
>>>> + Not Supported
>>>> + Invalid Parameters
>>>> + Not Powered
>>>> + Invalid Index
>>>> +
>>>> +
>>>> Command Complete Event
>>>> ======================
>>>>
>>>> @@ -2851,3 +2879,44 @@ New Configuration Options Event
>>>>
>>>> This event indicates that one or more of the options for the
>>>> controller configuration has changed.
>>>> +
>>>> +
>>>> +Advertisement Received Event
>>>> +==============================
>>>> +
>>>> + Event Code: 0x0020
>>>> + Controller Index: <controller id>
>>>> + Event Parameters: Address (6 Octets)
>>>> + Address_Type (1 Octet)
>>>> + RSSI (1 Octet)
>>>> + Flags (4 Octets)
>>>> + AD_Data_Length (2 Octets)
>>>> + AD_Data (0-65535 Octets)
>>>
>>> Device Found event not good enough here? Why would you need a new event with exactly the same parameters?
>>
>> Because Device Found event always contains EIR data, and mine would
>> sometimes contain only AD data.
>> Also this will be send for each advertisement received, not for first one only.
>
> Do not get confused because Device Found says EIR_Data. It will return EIR_Data for BR/EDR devices and AD_Data for LE devices. We just never bothered to find a more common name.
>
> We could easily send multiple Device Found events. Besides Start Discovery, we also have Add Device with Action 0x00 sending out Device Found events. So that would not be a problem. We just need to define the context properly.
>
> 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




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux