Re: [PATCH] mgmt-api: add read Tx power level command

On Mon, Mar 19, 2012 at 19:44, Marcel Holtmann [off-list ref] wrote:

Hi Arik,

quoted

quoted

quoted

quoted

quoted

quoted

+ =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)

quoted

quoted

quoted

quoted

quoted

quoted

+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Type (1=

 Octet)

quoted

quoted

quoted

quoted

quoted

quoted

+ =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)

quoted

quoted

quoted

quoted

quoted

quoted

+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Status =

(1 Octet)

quoted

quoted

quoted

quoted

quoted

quoted

+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Level (=

1 Octet)

quoted

quoted

quoted

quoted

quoted

quoted

+
+ =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

quoted

quoted

quoted

quoted

quoted

quoted

+ =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 Maximum Transmit Power Le=

vel

quoted

quoted

quoted

quoted

quoted

Which ones do you care about? And why not just read both and retur=

n both

quoted

quoted

quoted

quoted

quoted

at the same time.

I think that I made this pretty clear multiple times already. The =

mgmt

quoted

quoted

quoted

quoted

quoted

API is not for stuffing random HCI commands into it. Please explai=

n your

quoted

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

quoted

query the reporter for the Tx power level. The spec claims there's n=

o

quoted

quoted

quoted

quoted

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?

quoted

quoted

quoted

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.

quoted

quoted

Both profiles only care about the current Tx power level. I added th=

e

quoted

quoted

quoted

quoted

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