* [PATCH] mgmt-api: add read Tx power level command
@ 2012-03-11 22:10 Arik Nemtsov
2012-03-12 0:42 ` Marcel Holtmann
0 siblings, 1 reply; 8+ messages in thread
From: Arik Nemtsov @ 2012-03-11 22:10 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Arik Nemtsov
This command reads the Tx power level for a given connected device
---
doc/mgmt-api.txt | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 4ede43d..8dae2b4 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -815,6 +815,34 @@ Unblock Device Command
or failure.
+Read Tx Power Level Command
+======================
+
+ Command Code: 0x0028
+ Controller Index: <controller id>
+ Command Parameters: Address (6 Octets)
+ Address_Type (1 Octet)
+ Type (1 Octet)
+ Return Parameters: Address (6 Octets)
+ Address_Type (1 Octet)
+ Status (1 Octet)
+ Level (1 Octet)
+
+ Possible values for the Address_Type parameter:
+ 0 BR/EDR
+ 1 LE Public
+ 2 LE Random
+
+ Possible values for the Type parameter:
+ 0 Current Transmit Power Level
+ 1 Maximum Transmit Power Level
+
+ This command can only be used when the controller is powered.
+
+ This command generates a Command Complete event on success
+ or failure.
+
+
Set Device ID Command
=====================
--
1.7.5.4
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] mgmt-api: add read Tx power level command
2012-03-11 22:10 [PATCH] mgmt-api: add read Tx power level command Arik Nemtsov
@ 2012-03-12 0:42 ` Marcel Holtmann
2012-03-12 7:39 ` Arik Nemtsov
0 siblings, 1 reply; 8+ messages in thread
From: Marcel Holtmann @ 2012-03-12 0:42 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-bluetooth
Hi Arik,
> This command reads the Tx power level for a given connected device
> ---
> doc/mgmt-api.txt | 28 ++++++++++++++++++++++++++++
> 1 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index 4ede43d..8dae2b4 100644
> --- a/doc/mgmt-api.txt
> +++ b/doc/mgmt-api.txt
> @@ -815,6 +815,34 @@ Unblock Device Command
> or failure.
>
>
> +Read Tx Power Level Command
> +======================
> +
> + Command Code: 0x0028
how is this suppose to work. This command and Set Device ID are suppose
to have the same command code?
> + Controller Index: <controller id>
> + Command Parameters: Address (6 Octets)
> + Address_Type (1 Octet)
> + Type (1 Octet)
> + Return Parameters: Address (6 Octets)
> + Address_Type (1 Octet)
> + Status (1 Octet)
> + Level (1 Octet)
> +
> + Possible values for the Address_Type parameter:
> + 0 BR/EDR
> + 1 LE Public
> + 2 LE Random
> +
> + Possible values for the Type parameter:
> + 0 Current Transmit Power Level
> + 1 Maximum Transmit Power Level
Which ones do you care about? And why not just read both and return both
at the same time.
I think that I made this pretty clear multiple times already. The mgmt
API is not for stuffing random HCI commands into it. Please explain your
usage pattern of the results clearly.
Who is triggering this command and who is consuming the results?
Regards
Marcel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mgmt-api: add read Tx power level command
2012-03-12 0:42 ` Marcel Holtmann
@ 2012-03-12 7:39 ` Arik Nemtsov
2012-03-12 17:29 ` Marcel Holtmann
0 siblings, 1 reply; 8+ messages in thread
From: Arik Nemtsov @ 2012-03-12 7:39 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
On Mon, Mar 12, 2012 at 02:42, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Arik,
>
>> This command reads the Tx power level for a given connected device
>> ---
>> =A0doc/mgmt-api.txt | =A0 28 ++++++++++++++++++++++++++++
>> =A01 files changed, 28 insertions(+), 0 deletions(-)
>>
>> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
>> index 4ede43d..8dae2b4 100644
>> --- a/doc/mgmt-api.txt
>> +++ b/doc/mgmt-api.txt
>> @@ -815,6 +815,34 @@ Unblock Device Command
>> =A0 =A0 =A0 or failure.
>>
>>
>> +Read Tx Power Level Command
>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> +
>> + =A0 =A0 Command Code: =A0 =A0 =A0 =A0 =A0 0x0028
>
> how is this suppose to work. This command and Set Device ID are suppose
> to have the same command code?
Ah you're right I missed that. I'll put 0x29 then.
>
>> + =A0 =A0 Controller Index: =A0 =A0 =A0 <controller id>
>> + =A0 =A0 Command Parameters: =A0 =A0 Address (6 Octets)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Address_Type (=
1 Octet)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Type (1 Octet)
>> + =A0 =A0 Return Parameters: =A0 =A0 =A0Address (6 Octets)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Address_Type (=
1 Octet)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Status (1 Octe=
t)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Level (1 Octet=
)
>> +
>> + =A0 =A0 Possible values for the Address_Type parameter:
>> + =A0 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 BR/EDR
>> + =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 LE Public
>> + =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 LE Random
>> +
>> + =A0 =A0 Possible values for the Type parameter:
>> + =A0 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 Current Transmit Power Level
>> + =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 Maximum Transmit Power Level
>
> Which ones do you care about? And why not just read both and return both
> at the same time.
>
> I think that I made this pretty clear multiple times already. The mgmt
> API is not for stuffing random HCI commands into it. Please explain your
> usage pattern of the results clearly.
>
> Who is triggering this command and who is consuming the results?
Well the proximity reporter and proximity monitor profiles are the
ones using this (with LE connections only). The proximity monitor can
query the reporter for the Tx power level. The spec claims there's no
point in polling for this, as the value doesn't change during an LE
connection.
Both profiles only care about the current Tx power level. I added the
type for flexibility. It can be removed of course.
In the proposed implementation the reporter reads this value when a
device connects and caches it. When a remote device asks for this
value (via an ATT read as part of the TPS profile), we return the
cached value.
Regards,
Arik
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mgmt-api: add read Tx power level command
2012-03-12 7:39 ` Arik Nemtsov
@ 2012-03-12 17:29 ` Marcel Holtmann
2012-03-12 18:07 ` Arik Nemtsov
0 siblings, 1 reply; 8+ messages in thread
From: Marcel Holtmann @ 2012-03-12 17:29 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-bluetooth
Hi Arik,
> >> This command reads the Tx power level for a given connected device
> >> ---
> >> doc/mgmt-api.txt | 28 ++++++++++++++++++++++++++++
> >> 1 files changed, 28 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> >> index 4ede43d..8dae2b4 100644
> >> --- a/doc/mgmt-api.txt
> >> +++ b/doc/mgmt-api.txt
> >> @@ -815,6 +815,34 @@ Unblock Device Command
> >> or failure.
> >>
> >>
> >> +Read Tx Power Level Command
> >> +======================
> >> +
> >> + Command Code: 0x0028
> >
> > how is this suppose to work. This command and Set Device ID are suppose
> > to have the same command code?
>
> Ah you're right I missed that. I'll put 0x29 then.
>
> >
> >> + Controller Index: <controller id>
> >> + Command Parameters: Address (6 Octets)
> >> + Address_Type (1 Octet)
> >> + Type (1 Octet)
> >> + Return Parameters: Address (6 Octets)
> >> + Address_Type (1 Octet)
> >> + Status (1 Octet)
> >> + Level (1 Octet)
> >> +
> >> + Possible values for the Address_Type parameter:
> >> + 0 BR/EDR
> >> + 1 LE Public
> >> + 2 LE Random
> >> +
> >> + Possible values for the Type parameter:
> >> + 0 Current Transmit Power Level
> >> + 1 Maximum Transmit Power Level
> >
> > Which ones do you care about? And why not just read both and return both
> > at the same time.
> >
> > I think that I made this pretty clear multiple times already. The mgmt
> > API is not for stuffing random HCI commands into it. Please explain your
> > usage pattern of the results clearly.
> >
> > Who is triggering this command and who is consuming the results?
>
> Well the proximity reporter and proximity monitor profiles are the
> ones using this (with LE connections only). The proximity monitor can
> query the reporter for the Tx power level. The spec claims there's no
> point in polling for this, as the value doesn't change during an LE
> connection.
so why are we not just reading that value when creating a LE connection?
What is the penalty for doing it on every LE connection?
> Both profiles only care about the current Tx power level. I added the
> type for flexibility. It can be removed of course.
>
> In the proposed implementation the reporter reads this value when a
> device connects and caches it. When a remote device asks for this
> value (via an ATT read as part of the TPS profile), we return the
> cached value.
So it gets always read anyway.
Regards
Marcel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mgmt-api: add read Tx power level command
2012-03-12 17:29 ` Marcel Holtmann
@ 2012-03-12 18:07 ` Arik Nemtsov
2012-03-19 9:00 ` Arik Nemtsov
0 siblings, 1 reply; 8+ messages in thread
From: Arik Nemtsov @ 2012-03-12 18:07 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
On Mon, Mar 12, 2012 at 19:29, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Arik,
>
>> >> This command reads the Tx power level for a given connected device
>> >> ---
>> >> =A0doc/mgmt-api.txt | =A0 28 ++++++++++++++++++++++++++++
>> >> =A01 files changed, 28 insertions(+), 0 deletions(-)
>> >>
>> >> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
>> >> index 4ede43d..8dae2b4 100644
>> >> --- a/doc/mgmt-api.txt
>> >> +++ b/doc/mgmt-api.txt
>> >> @@ -815,6 +815,34 @@ Unblock Device Command
>> >> =A0 =A0 =A0 or failure.
>> >>
>> >>
>> >> +Read Tx Power Level Command
>> >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >> +
>> >> + =A0 =A0 Command Code: =A0 =A0 =A0 =A0 =A0 0x0028
>> >
>> > how is this suppose to work. This command and Set Device ID are suppos=
e
>> > to have the same command code?
>>
>> Ah you're right I missed that. I'll put 0x29 then.
>>
>> >
>> >> + =A0 =A0 Controller Index: =A0 =A0 =A0 <controller id>
>> >> + =A0 =A0 Command Parameters: =A0 =A0 Address (6 Octets)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Address_Typ=
e (1 Octet)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Type (1 Oct=
et)
>> >> + =A0 =A0 Return Parameters: =A0 =A0 =A0Address (6 Octets)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Address_Typ=
e (1 Octet)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Status (1 O=
ctet)
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Level (1 Oc=
tet)
>> >> +
>> >> + =A0 =A0 Possible values for the Address_Type parameter:
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 BR/EDR
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 LE Public
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 LE Random
>> >> +
>> >> + =A0 =A0 Possible values for the Type parameter:
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 Current Transmit Power Level
>> >> + =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 Maximum Transmit Power Level
>> >
>> > Which ones do you care about? And why not just read both and return bo=
th
>> > at the same time.
>> >
>> > I think that I made this pretty clear multiple times already. The mgmt
>> > API is not for stuffing random HCI commands into it. Please explain yo=
ur
>> > usage pattern of the results clearly.
>> >
>> > Who is triggering this command and who is consuming the results?
>>
>> Well the proximity reporter and proximity monitor profiles are the
>> ones using this (with LE connections only). The proximity monitor can
>> query the reporter for the Tx power level. The spec claims there's no
>> point in polling for this, as the value doesn't change during an LE
>> connection.
>
> so why are we not just reading that value when creating a LE connection?
> What is the penalty for doing it on every LE connection?
Well presumably it should only be read when the TPS profile if
enabled. The cost is sending another command to the controller on each
connection. Not sure it's very high.
Maybe we can even integrate it into the "device connected" event, and
just read it for all connecting devices.
I guess it's a matter of personal preference.
I think this API is better for future proofing - it gives the caller
the option to get the Tx power for BR/EDR devices as well, at
arbitrary times (since it can change during a BR connection).
Some earlier emails suggested it might be useful.
>
>> Both profiles only care about the current Tx power level. I added the
>> type for flexibility. It can be removed of course.
>>
>> In the proposed implementation the reporter reads this value when a
>> device connects and caches it. When a remote device asks for this
>> value (via an ATT read as part of the TPS profile), we return the
>> cached value.
>
> So it gets always read anyway.
Only when TPS server is enabled.
Arik
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mgmt-api: add read Tx power level command
2012-03-12 18:07 ` Arik Nemtsov
@ 2012-03-19 9:00 ` Arik Nemtsov
2012-03-19 17:44 ` Marcel Holtmann
0 siblings, 1 reply; 8+ messages in thread
From: Arik Nemtsov @ 2012-03-19 9:00 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
On Mon, Mar 12, 2012 at 20:07, Arik Nemtsov <arik@wizery.com> wrote:
>>> >> + =A0 =A0 Controller Index: =A0 =A0 =A0 <controller id>
>>> >> + =A0 =A0 Command Parameters: =A0 =A0 Address (6 Octets)
>>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Address_Ty=
pe (1 Octet)
>>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Type (1 Oc=
tet)
>>> >> + =A0 =A0 Return Parameters: =A0 =A0 =A0Address (6 Octets)
>>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Address_Ty=
pe (1 Octet)
>>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Status (1 =
Octet)
>>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Level (1 O=
ctet)
>>> >> +
>>> >> + =A0 =A0 Possible values for the Address_Type parameter:
>>> >> + =A0 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 BR/EDR
>>> >> + =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 LE Public
>>> >> + =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 LE Random
>>> >> +
>>> >> + =A0 =A0 Possible values for the Type parameter:
>>> >> + =A0 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 Current Transmit Power Level
>>> >> + =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 Maximum Transmit Power Level
>>> >
>>> > Which ones do you care about? And why not just read both and return b=
oth
>>> > at the same time.
>>> >
>>> > I think that I made this pretty clear multiple times already. The mgm=
t
>>> > API is not for stuffing random HCI commands into it. Please explain y=
our
>>> > usage pattern of the results clearly.
>>> >
>>> > Who is triggering this command and who is consuming the results?
>>>
>>> Well the proximity reporter and proximity monitor profiles are the
>>> ones using this (with LE connections only). The proximity monitor can
>>> query the reporter for the Tx power level. The spec claims there's no
>>> point in polling for this, as the value doesn't change during an LE
>>> connection.
>>
>> so why are we not just reading that value when creating a LE connection?
>> What is the penalty for doing it on every LE connection?
>
> Well presumably it should only be read when the TPS profile if
> enabled. The cost is sending another command to the controller on each
> connection. Not sure it's very high.
> Maybe we can even integrate it into the "device connected" event, and
> just read it for all connecting devices.
>
> I guess it's a matter of personal preference.
>
> I think this API is better for future proofing - it gives the caller
> the option to get the Tx power for BR/EDR devices as well, at
> arbitrary times (since it can change during a BR connection).
> Some earlier emails suggested it might be useful.
>
>>
>>> Both profiles only care about the current Tx power level. I added the
>>> type for flexibility. It can be removed of course.
>>>
>>> In the proposed implementation the reporter reads this value when a
>>> device connects and caches it. When a remote device asks for this
>>> value (via an ATT read as part of the TPS profile), we return the
>>> cached value.
>>
>> So it gets always read anyway.
>
> Only when TPS server is enabled.
Is the current API acceptable?
Regards,
Arik
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mgmt-api: add read Tx power level command
2012-03-19 9:00 ` Arik Nemtsov
@ 2012-03-19 17:44 ` Marcel Holtmann
2012-03-20 16:07 ` Arik Nemtsov
0 siblings, 1 reply; 8+ messages in thread
From: Marcel Holtmann @ 2012-03-19 17:44 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-bluetooth
Hi Arik,
> >>> >> + Controller Index: <controller id>
> >>> >> + Command Parameters: Address (6 Octets)
> >>> >> + Address_Type (1 Octet)
> >>> >> + Type (1 Octet)
> >>> >> + Return Parameters: Address (6 Octets)
> >>> >> + Address_Type (1 Octet)
> >>> >> + Status (1 Octet)
> >>> >> + Level (1 Octet)
> >>> >> +
> >>> >> + Possible values for the Address_Type parameter:
> >>> >> + 0 BR/EDR
> >>> >> + 1 LE Public
> >>> >> + 2 LE Random
> >>> >> +
> >>> >> + Possible values for the Type parameter:
> >>> >> + 0 Current Transmit Power Level
> >>> >> + 1 Maximum Transmit Power Level
> >>> >
> >>> > Which ones do you care about? And why not just read both and return both
> >>> > at the same time.
> >>> >
> >>> > I think that I made this pretty clear multiple times already. The mgmt
> >>> > API is not for stuffing random HCI commands into it. Please explain your
> >>> > usage pattern of the results clearly.
> >>> >
> >>> > Who is triggering this command and who is consuming the results?
> >>>
> >>> Well the proximity reporter and proximity monitor profiles are the
> >>> ones using this (with LE connections only). The proximity monitor can
> >>> query the reporter for the Tx power level. The spec claims there's no
> >>> point in polling for this, as the value doesn't change during an LE
> >>> connection.
> >>
> >> so why are we not just reading that value when creating a LE connection?
> >> What is the penalty for doing it on every LE connection?
> >
> > Well presumably it should only be read when the TPS profile if
> > enabled. The cost is sending another command to the controller on each
> > connection. Not sure it's very high.
> > Maybe we can even integrate it into the "device connected" event, and
> > just read it for all connecting devices.
> >
> > I guess it's a matter of personal preference.
> >
> > I think this API is better for future proofing - it gives the caller
> > the option to get the Tx power for BR/EDR devices as well, at
> > arbitrary times (since it can change during a BR connection).
> > Some earlier emails suggested it might be useful.
> >
> >>
> >>> Both profiles only care about the current Tx power level. I added the
> >>> type for flexibility. It can be removed of course.
> >>>
> >>> In the proposed implementation the reporter reads this value when a
> >>> device connects and caches it. When a remote device asks for this
> >>> value (via an ATT read as part of the TPS profile), we return the
> >>> cached value.
> >>
> >> So it gets always read anyway.
> >
> > Only when TPS server is enabled.
>
> Is the current API acceptable?
I don't know yet. Send a new version with detailed explanation and I
have another look. I am currently not fully convinced. I have the
feeling we should be doing this differently.
Regards
Marcel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mgmt-api: add read Tx power level command
2012-03-19 17:44 ` Marcel Holtmann
@ 2012-03-20 16:07 ` Arik Nemtsov
0 siblings, 0 replies; 8+ messages in thread
From: Arik Nemtsov @ 2012-03-20 16:07 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
On Mon, Mar 19, 2012 at 19:44, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Arik,
>
>> >>> >> + =A0 =A0 Controller Index: =A0 =A0 =A0 <controller id>
>> >>> >> + =A0 =A0 Command Parameters: =A0 =A0 Address (6 Octets)
>> >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Address=
_Type (1 Octet)
>> >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Type (1=
Octet)
>> >>> >> + =A0 =A0 Return Parameters: =A0 =A0 =A0Address (6 Octets)
>> >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Address=
_Type (1 Octet)
>> >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Status =
(1 Octet)
>> >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Level (=
1 Octet)
>> >>> >> +
>> >>> >> + =A0 =A0 Possible values for the Address_Type parameter:
>> >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 BR/EDR
>> >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 LE Public
>> >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 LE Random
>> >>> >> +
>> >>> >> + =A0 =A0 Possible values for the Type parameter:
>> >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 Current Transmit Power Le=
vel
>> >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 Maximum Transmit Power Le=
vel
>> >>> >
>> >>> > Which ones do you care about? And why not just read both and retur=
n both
>> >>> > at the same time.
>> >>> >
>> >>> > I think that I made this pretty clear multiple times already. The =
mgmt
>> >>> > API is not for stuffing random HCI commands into it. Please explai=
n your
>> >>> > usage pattern of the results clearly.
>> >>> >
>> >>> > Who is triggering this command and who is consuming the results?
>> >>>
>> >>> Well the proximity reporter and proximity monitor profiles are the
>> >>> ones using this (with LE connections only). The proximity monitor ca=
n
>> >>> query the reporter for the Tx power level. The spec claims there's n=
o
>> >>> point in polling for this, as the value doesn't change during an LE
>> >>> connection.
>> >>
>> >> so why are we not just reading that value when creating a LE connecti=
on?
>> >> What is the penalty for doing it on every LE connection?
>> >
>> > Well presumably it should only be read when the TPS profile if
>> > enabled. The cost is sending another command to the controller on each
>> > connection. Not sure it's very high.
>> > Maybe we can even integrate it into the "device connected" event, and
>> > just read it for all connecting devices.
>> >
>> > I guess it's a matter of personal preference.
>> >
>> > I think this API is better for future proofing - it gives the caller
>> > the option to get the Tx power for BR/EDR devices as well, at
>> > arbitrary times (since it can change during a BR connection).
>> > Some earlier emails suggested it might be useful.
>> >
>> >>
>> >>> Both profiles only care about the current Tx power level. I added th=
e
>> >>> type for flexibility. It can be removed of course.
>> >>>
>> >>> In the proposed implementation the reporter reads this value when a
>> >>> device connects and caches it. When a remote device asks for this
>> >>> value (via an ATT read as part of the TPS profile), we return the
>> >>> cached value.
>> >>
>> >> So it gets always read anyway.
>> >
>> > Only when TPS server is enabled.
>>
>> Is the current API acceptable?
>
> I don't know yet. Send a new version with detailed explanation and I
> have another look. I am currently not fully convinced. I have the
> feeling we should be doing this differently.
>
Sure. It'll take me a couple of days to formulate it.
Regards,
Arik
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-03-20 16:07 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-11 22:10 [PATCH] mgmt-api: add read Tx power level command Arik Nemtsov
2012-03-12 0:42 ` Marcel Holtmann
2012-03-12 7:39 ` Arik Nemtsov
2012-03-12 17:29 ` Marcel Holtmann
2012-03-12 18:07 ` Arik Nemtsov
2012-03-19 9:00 ` Arik Nemtsov
2012-03-19 17:44 ` Marcel Holtmann
2012-03-20 16:07 ` Arik Nemtsov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox