From: Bruna Moreira <[email protected]>
Add Read RSSI and Read TX Power level commands in Management API
documentation.
---
doc/mgmt-api.txt | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 353705e..b442cc5 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -319,6 +319,26 @@ Stop Discovery Command
Command Parameters:
Return Parameters:
+Read RSSI Command
+=================
+
+ Command Code: 0x001D
+ Controller Index: <controller id>
+ Command Parameters: Address (6 Octets)
+ Return Parameters: Status (1 Octet)
+ Address (6 Octets)
+ RSSI (1 Octet)
+
+Read TX Power Level Command
+===========================
+
+ Command Code: 0x001E
+ Controller Index: <controller id>
+ Command Parameters: Address (6 Octets)
+ Return Parameters: Address (6 Octets)
+ Status (1 Octet)
+ Level (1 Octet)
+
Read Tracing Buffer Size Command
================================
--
1.7.4.1
Hi Anderson,
> >> >> >>> if TX power is only read once than the kernel should just do it once
> >> >> >>> and
> >> >> >>> be done with it.
> >> >> >>>
> >> >> >>> And for RSSI, it would be better if the kernel read this periodically
> >> >> >>> based on current sniff mode etc. Userspace can not trigger this with
> >> >> >>> proper timing anyway. And it will potentially at some point start
> >> >> >>> blocking the controller. Only the kernel really knows when it is
> >> >> >>> acceptable to read the RSSI value.
> >> >> >>
> >> >> >> Reading the RSSI by the kernel, will force a certain limitation on the
> >> >> >> current and future Profiles. I believe setting the timing should be done
> >> >> >> by the profile itself, not the bluez user space code or the kernel. It
> >> >> >> is the responsibility of the profile to periodically poll the RSSI Level.
> >> >> >> For some cases, polling it every 5 seconds would be ok, and for some
> >> >> >> Others, it may be better to read it every second. I believe we must not
> >> >> >> impose any limitation here.
> >> >> >
> >> >> > You probably forgot that besides bluetoothd there should be no other
> >> >> > application holding the mgmt socket, so not you can't really do it in
> >> >> > poll in the application side and doing it over D-Bus is overkill. Also
> >> >> > I notice that from some parties, you include, there is some tendency
> >> >> > to have the profiles split from the bluetoothd, IMO this will only add
> >> >> > fragmentation with each and every platform using BlueZ having their
> >> >> > own implementation of each profile and not sharing much, making the
> >> >> > IOP a complete mess.
> >> >> >
> >> >>
> >> >> Some additional comments...
> >> >>
> >> >> Health plugin will need a similar approach to read the clock. It will
> >> >> be good to implement the same approach.
> >> >> In our suggested implementation the adapter controls when to send the
> >> >> command to read the RSSI, keeping the same logic for both: hciops and
> >> >> mgmtops. If the adapter is managing when to send the commands,
> >> >> repeated commands can be avoided, multiple callbacks can be registered
> >> >> by the profiles, but only one command to read the RSSI will be sent.
> >> >> The cover letter of the userspace patches contains more details how we
> >> >> implemented it.
> >> >>
> >> >> Reading the RSSI directly by the kernel will break hciops. These are
> >> >> the arguments that I have to support our decision.
> >> >
> >> > what I am hearing is that we want the kernel to poll for certain
> >> > information if userspace needs them. And either it is a one-shot poll or
> >> > it is on a regular interval.
> >>
> >> If everybody agree we can do it. Our objective is to have the patches upstream.
> >> To keep the Proximity Monitor functional on both adapter_ops plugins
> >> we can move part of the logic from the adapter.c to the hciops. The
> >> polling to read the RSSI can be moved to hciops, in the management the
> >> polling will be in the kernel. The remaining code to register the
> >> callbacks doesn't need to be changed.
> >
> > Do we have a really good reason to implement this both for hciops and mgmtops?
> > We wrote mgmt interface to solve our problems. So why do we still care about
> > put new stuff on hciops? And then we maintain two pieces of code instead
> > of one.
> >
> > Gustavo
> >
>
> Ok, we could implement it just for mgmtops. But, I need some opinions
> before start coding. We was thinking about the architecture needed
> into the kernel and we have some ideas:
>
> - Add a new Management command called MGMT_ADD_LISTENER or something
> like that, which has two arguments at least: command op code and timer
> interval.
> - A callback called by the expired timer for each monitored command
> will be responsible to send the result (e.g.: Read RSSI or Read
> Clock), to the userspace.
>
> As you could notice, we should have one timer for each command. What
> do you think about this approach?
what you want is an mgmt event that notifies you about changes and that
could be well one event per type. And then you need one mgmt command to
set the trigger here.
Also you might wanna look at the SIG closely. I think they are trying to
fix this on the HCI controller side. So we get at least RSSI updates
when they change and don't have to poll them.
In theory it is always better to define a threshold instead of fixed
poll interval. Even if the threshold is implement as a poll on older
chips, at least for future ones you get this right.
Regards
Marcel
Hi,
On Thu, Jun 16, 2011 at 4:45 PM, Gustavo F. Padovan
<[email protected]> wrote:
> * Claudio Takahasi <[email protected]> [2011-06-16 12:12:53 =
-0300]:
>
>> Hi Marcel,
>>
>> On Thu, Jun 16, 2011 at 11:47 AM, Marcel Holtmann <[email protected]> =
wrote:
>> > Hi Claudio,
>> >
>> >> >>> if TX power is only read once than the kernel should just do it o=
nce
>> >> >>> and
>> >> >>> be done with it.
>> >> >>>
>> >> >>> And for RSSI, it would be better if the kernel read this periodic=
ally
>> >> >>> based on current sniff mode etc. Userspace can not trigger this w=
ith
>> >> >>> proper timing anyway. And it will potentially at some point start
>> >> >>> blocking the controller. Only the kernel really knows when it is
>> >> >>> acceptable to read the RSSI value.
>> >> >>
>> >> >> Reading the RSSI by the kernel, will force a certain limitation on=
the
>> >> >> current and future Profiles. I believe setting the timing should b=
e done
>> >> >> by the profile itself, not the bluez user space code or the kernel=
. It
>> >> >> is the responsibility of the profile to periodically poll the RSSI=
Level.
>> >> >> For some cases, polling it every 5 seconds would be ok, and for so=
me
>> >> >> Others, it may be better to read it every second. I believe we mus=
t not
>> >> >> impose any limitation here.
>> >> >
>> >> > You probably forgot that besides bluetoothd there should be no othe=
r
>> >> > application holding the mgmt socket, so not you can't really do it =
in
>> >> > poll in the application side and doing it over D-Bus is overkill. A=
lso
>> >> > I notice that from some parties, you include, there is some tendenc=
y
>> >> > to have the profiles split from the bluetoothd, IMO this will only =
add
>> >> > fragmentation with each and every platform using BlueZ having their
>> >> > own implementation of each profile and not sharing much, making the
>> >> > IOP a complete mess.
>> >> >
>> >>
>> >> Some additional comments...
>> >>
>> >> Health plugin will need a similar approach to read the clock. It will
>> >> be good to implement the same approach.
>> >> In our suggested implementation the adapter controls when to send the
>> >> command to read the RSSI, keeping the same logic for both: hciops and
>> >> mgmtops. If the adapter is managing when to send the commands,
>> >> repeated commands can be avoided, multiple callbacks can be registere=
d
>> >> by the profiles, but only one command to read the RSSI will be sent.
>> >> The cover letter of the userspace patches contains more details how w=
e
>> >> implemented it.
>> >>
>> >> Reading the RSSI directly by the kernel will break hciops. These are
>> >> the arguments that I have to support our decision.
>> >
>> > what I am hearing is that we want the kernel to poll for certain
>> > information if userspace needs them. And either it is a one-shot poll =
or
>> > it is on a regular interval.
>>
>> If everybody agree we can do it. Our objective is to have the patches up=
stream.
>> To keep the Proximity Monitor functional on both adapter_ops plugins
>> we can move part of the logic from the adapter.c to the hciops. The
>> polling to read the RSSI can be moved to hciops, in the management the
>> polling will be in the kernel. The remaining code to register the
>> callbacks doesn't need to be changed.
>
> Do we have a really good reason to implement this both for hciops and mgm=
tops?
> We wrote mgmt interface to solve our problems. So why do we still care ab=
out
> put new stuff on hciops? And then we maintain two pieces of code instead
> of one.
>
> =A0 =A0 =A0 =A0Gustavo
>
Ok, we could implement it just for mgmtops. But, I need some opinions
before start coding. We was thinking about the architecture needed
into the kernel and we have some ideas:
- Add a new Management command called MGMT_ADD_LISTENER or something
like that, which has two arguments at least: command op code and timer
interval.
- A callback called by the expired timer for each monitored command
will be responsible to send the result (e.g.: Read RSSI or Read
Clock), to the userspace.
As you could notice, we should have one timer for each command. What
do you think about this approach?
Regards,
Anderson Briglia
--=20
INdT - Instituto Nokia de tecnologia
+55 2126 1122
Hi Anderson,
>> The way I see it is that the pace of profile spec ratification in the SIG or the pace of development of profiles in BlueZ will probably be too slow
>> for the larger community of device manufacturers and Application developers for platforms like Android.
>> Besides, the usecases being addressed by the profiles in pipeline would probably be only a fraction of the real potential of GATT, which device manufacturers might want to tap into.
>
>I agree. But note that currently we lack use cases which justify a
>complete GATT API over D-Bus. Feel free to discuss your own use cases,
>and propose an API for them.
The point that I was trying to make is that you or me trying to figure out the possible usecases over GATT and then trying to cater to them may prove to be inadequate quite soon after widespread Ble deployment. I thought the usecases over GATT beyond those that are thought over by the SIG are best left to the imagination of the users of GATT which could be the peripheral device manufacturers. Giving BlueZ a comprehensive GATT API will enable any of these usecases and would pave the way for widespread and faster usage of Ble/GATT, at the same time giving freedom to the user to decide what usecases he/she wants in his/her BlueZ powered device.
I do not have any specific usecase in mind (or it could be that I have just too many of them), but the system of interest to me is Android.
>> Do you see problems in including GATT Servers too in it?
>> Are you open to stronger contributions to the GATT DBUS API? ( I am interested to do that)
>
>I believe we are always open to discussions and contributions :). But
>before you begin implementing your proposal, I'd suggest discussing a
>draft API first on this list. I'm sure there are other parties
>interested on helping on that as well.
Sure. I shall send out an API RFC before I start on it.
Thank you,
ajay
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at http://www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at http://www.csr.com/blog
Hi
2011/6/17 Anderson Lizardo <[email protected]>:
> Hi,
>
> On Fri, Jun 17, 2011 at 8:22 AM, Santiago Carot <[email protected]> wrote:
>> Just a note. If there is a full GATT API and we do BlueZ plugins over
>> GATT (wich have their own D-Bus API as usual in BlueZ). The GATT API
>> may be in conflict with those APIs exposed by those plugins because
>> Applications will be able to use Attribute D-Bus one avoiding those
>> APIs exposed by plugins. Do not?
>
> As long as all APIs use the same stack, there is no issue AFAIK. For
> instance, if someone uses the Proximity D-Bus API and another
> application does the same operation over the "generic" Attribute API,
> both operations will be processed the same way inside the BlueZ GATT
> stack (because they use the same functions internally). At least this
> is the intended behavior, we don't do much testing like that :)
>
Yes, sure. the GATT API will allow applications to avoid use API
provided for GATT based plugins. In this scenario there will be two
ways to doing things. A) Using the plugin API and B)Through the GATT
API. ... or in the worst case, an Application may use both.
> Regards,
> --
> Anderson Lizardo
> Instituto Nokia de Tecnologia - INdT
> Manaus - Brazil
>
Hi,
On Fri, Jun 17, 2011 at 8:22 AM, Santiago Carot <[email protected]> wrote:
> Just a note. If there is a full GATT API and we do BlueZ plugins over
> GATT (wich have their own D-Bus API as usual in BlueZ). The GATT API
> may be in conflict with those APIs exposed by those plugins because
> Applications will be able to use Attribute D-Bus one avoiding those
> APIs exposed by plugins. Do not?
As long as all APIs use the same stack, there is no issue AFAIK. For
instance, if someone uses the Proximity D-Bus API and another
application does the same operation over the "generic" Attribute API,
both operations will be processed the same way inside the BlueZ GATT
stack (because they use the same functions internally). At least this
is the intended behavior, we don't do much testing like that :)
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hi,
2011/6/17 Anderson Lizardo <[email protected]>:
> Hi Ajay,
>
> On Fri, Jun 17, 2011 at 5:30 AM, Ajay Pillai <[email protected]> wrote:
>> I saw another post from you which seemed to indicate that the GATT DBUS API is not
>> meant to be used extensively in systems for implementing profiles or for general App integration.
>> (Please correct me if I interpreted wrong)
>
> The current API implementation (documented in doc/attribute-api.txt)
> is not suitable for implementing external profiles, correct.
>
>> However this information coupled with the tightly coupled nature of the GATT based profiles (as derived from your reply) in BlueZ, is giving
>> me an impression that the current development direction in BlueZ can severely curb the freedom of device implementers
>> to use the capability of GATT. (not sure if you have discussed this before an concluded, in which case I would be interested to be pointed to another post)
>
> If these implementers create a BlueZ plugin (in C), they have the full
> power of BlueZ GATT stack. Of course, there are the licensing
> requirements (I suppose).
>
>> The way I see it is that the pace of profile spec ratification in the SIG or the pace of development of profiles in BlueZ will probably be too slow
>> for the larger community of device manufacturers and Application developers for platforms like Android.
>> Besides, the usecases being addressed by the profiles in pipeline would probably be only a fraction of the real potential of GATT, which device manufacturers might want to tap into.
>
> I agree. But note that currently we lack use cases which justify a
> complete GATT API over D-Bus. Feel free to discuss your own use cases,
> and propose an API for them.
>
>> This makes me think that more focus needs to be given to the GATT DBUS API, than what is implied by your earlier post.
>
> So far we have been focusing on implementing officially adopted
> profiles, the current D-Bus API was proposed and implemented at a time
> when there were no actual GATT profiles, and so far it has been used
> for testing purposes.
>
>> Do you have plans for making the GATT DBUS API more feature complete?
>
> At least on the team I work, there are no plans for that. But I wanted
> to bring up the discussion anyway, thus my e-mail.
>
>> Do you see problems in including GATT Servers too in it?
>> Are you open to stronger contributions to the GATT DBUS API? ( I am interested to do that)
>
> I believe we are always open to discussions and contributions :). But
> before you begin implementing your proposal, I'd suggest discussing a
> draft API first on this list. I'm sure there are other parties
> interested on helping on that as well.
>
>> You posted earlier:
>>>To be able to implement a full GATT profile externally (client role),
>>>we would need to expose the full GATT (or even ATT) stack over D-Bus.
>>>For instance, have methods for each GATT operation, and signals for
>>>notifications/indications.
>>
>>>Is that really what we want? If yes, the Attribute API could have to
>>>be severely redesigned. It was not (and currently still not is)
>>>intended for that.
>> Could you elaborate what is the scope of this redesign?
>
> If you take a look on doc/attribute-api.txt on BlueZ source, you might
> identify some limitations already (assuming you already have some use
> cases in mind):
>
> * There are no way to access custom characteristic descriptors (only
> presentation format and user description descriptors are currently
> exposed). This is a major limitation if you want to access custom
> descriptors.
> * No D-Bus API e.g. the server side (only client side) for managing
> the Attribute server
> * Notifications/indications are registered per server, not per
> characteristic (this might be a limitation or not)
> * Currently no way to handle cases where new services/characteristics
> are added "on the fly" on the server side (i.e. suport for the
> "Service Changed" GATT characteristic). Idea: new services or
> characteristics could be announced as D-Bus signals.
>
>> I am interested to know if system integrators can have a mutually exclusive choice between external profiles using BlueZ GATT and BlueZ built-in profiles.
>
> They could coexist just fine. But for that to work, the attribute
> server database needs to be managed by BlueZ, which would allocate
> attribute handles as necessary. Also note that UUIDs would need to be
> allocated for proprietary profiles (not sure how BT SIG handles that).
>
> Also consider contributing to the officially adopted profiles (once
> they are actually adopted). I really hope we don't see multiple
> implementations of an adopted GATT profile.
>
Just a note. If there is a full GATT API and we do BlueZ plugins over
GATT (wich have their own D-Bus API as usual in BlueZ). The GATT API
may be in conflict with those APIs exposed by those plugins because
Applications will be able to use Attribute D-Bus one avoiding those
APIs exposed by plugins. Do not?
Regards
Hi Ajay,
On Fri, Jun 17, 2011 at 5:30 AM, Ajay Pillai <[email protected]> wrote:
> I saw another post from you which seemed to indicate that the GATT DBUS API is not
> meant to be used extensively in systems for implementing profiles or for general App integration.
> (Please correct me if I interpreted wrong)
The current API implementation (documented in doc/attribute-api.txt)
is not suitable for implementing external profiles, correct.
> However this information coupled with the tightly coupled nature of the GATT based profiles (as derived from your reply) in BlueZ, is giving
> me an impression that the current development direction in BlueZ can severely curb the freedom of device implementers
> to use the capability of GATT. (not sure if you have discussed this before an concluded, in which case I would be interested to be pointed to another post)
If these implementers create a BlueZ plugin (in C), they have the full
power of BlueZ GATT stack. Of course, there are the licensing
requirements (I suppose).
> The way I see it is that the pace of profile spec ratification in the SIG or the pace of development of profiles in BlueZ will probably be too slow
> for the larger community of device manufacturers and Application developers for platforms like Android.
> Besides, the usecases being addressed by the profiles in pipeline would probably be only a fraction of the real potential of GATT, which device manufacturers might want to tap into.
I agree. But note that currently we lack use cases which justify a
complete GATT API over D-Bus. Feel free to discuss your own use cases,
and propose an API for them.
> This makes me think that more focus needs to be given to the GATT DBUS API, than what is implied by your earlier post.
So far we have been focusing on implementing officially adopted
profiles, the current D-Bus API was proposed and implemented at a time
when there were no actual GATT profiles, and so far it has been used
for testing purposes.
> Do you have plans for making the GATT DBUS API more feature complete?
At least on the team I work, there are no plans for that. But I wanted
to bring up the discussion anyway, thus my e-mail.
> Do you see problems in including GATT Servers too in it?
> Are you open to stronger contributions to the GATT DBUS API? ( I am interested to do that)
I believe we are always open to discussions and contributions :). But
before you begin implementing your proposal, I'd suggest discussing a
draft API first on this list. I'm sure there are other parties
interested on helping on that as well.
> You posted earlier:
>>To be able to implement a full GATT profile externally (client role),
>>we would need to expose the full GATT (or even ATT) stack over D-Bus.
>>For instance, have methods for each GATT operation, and signals for
>>notifications/indications.
>
>>Is that really what we want? If yes, the Attribute API could have to
>>be severely redesigned. It was not (and currently still not is)
>>intended for that.
> Could you elaborate what is the scope of this redesign?
If you take a look on doc/attribute-api.txt on BlueZ source, you might
identify some limitations already (assuming you already have some use
cases in mind):
* There are no way to access custom characteristic descriptors (only
presentation format and user description descriptors are currently
exposed). This is a major limitation if you want to access custom
descriptors.
* No D-Bus API e.g. the server side (only client side) for managing
the Attribute server
* Notifications/indications are registered per server, not per
characteristic (this might be a limitation or not)
* Currently no way to handle cases where new services/characteristics
are added "on the fly" on the server side (i.e. suport for the
"Service Changed" GATT characteristic). Idea: new services or
characteristics could be announced as D-Bus signals.
> I am interested to know if system integrators can have a mutually exclusive choice between external profiles using BlueZ GATT and BlueZ built-in profiles.
They could coexist just fine. But for that to work, the attribute
server database needs to be managed by BlueZ, which would allocate
attribute handles as necessary. Also note that UUIDs would need to be
allocated for proprietary profiles (not sure how BT SIG handles that).
Also consider contributing to the officially adopted profiles (once
they are actually adopted). I really hope we don't see multiple
implementations of an adopted GATT profile.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hi Anderson,
I saw another post from you which seemed to indicate that the GATT DBUS API is not
meant to be used extensively in systems for implementing profiles or for general App integration.
(Please correct me if I interpreted wrong)
However this information coupled with the tightly coupled nature of the GATT based profiles (as derived from your reply) in BlueZ, is giving
me an impression that the current development direction in BlueZ can severely curb the freedom of device implementers
to use the capability of GATT. (not sure if you have discussed this before an concluded, in which case I would be interested to be pointed to another post)
The way I see it is that the pace of profile spec ratification in the SIG or the pace of development of profiles in BlueZ will probably be too slow
for the larger community of device manufacturers and Application developers for platforms like Android.
Besides, the usecases being addressed by the profiles in pipeline would probably be only a fraction of the real potential of GATT, which device manufacturers might want to tap into.
This makes me think that more focus needs to be given to the GATT DBUS API, than what is implied by your earlier post.
Do you have plans for making the GATT DBUS API more feature complete?
Do you see problems in including GATT Servers too in it?
Are you open to stronger contributions to the GATT DBUS API? ( I am interested to do that)
You posted earlier:
>To be able to implement a full GATT profile externally (client role),
>we would need to expose the full GATT (or even ATT) stack over D-Bus.
>For instance, have methods for each GATT operation, and signals for
>notifications/indications.
>Is that really what we want? If yes, the Attribute API could have to
>be severely redesigned. It was not (and currently still not is)
>intended for that.
Could you elaborate what is the scope of this redesign?
I am interested to know if system integrators can have a mutually exclusive choice between external profiles using BlueZ GATT and BlueZ built-in profiles.
Thank you
ajay
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at http://www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at http://www.csr.com/blog
* Claudio Takahasi <[email protected]> [2011-06-16 12:12:53 -0300]:
> Hi Marcel,
>
> On Thu, Jun 16, 2011 at 11:47 AM, Marcel Holtmann <[email protected]> wrote:
> > Hi Claudio,
> >
> >> >>> if TX power is only read once than the kernel should just do it once
> >> >>> and
> >> >>> be done with it.
> >> >>>
> >> >>> And for RSSI, it would be better if the kernel read this periodically
> >> >>> based on current sniff mode etc. Userspace can not trigger this with
> >> >>> proper timing anyway. And it will potentially at some point start
> >> >>> blocking the controller. Only the kernel really knows when it is
> >> >>> acceptable to read the RSSI value.
> >> >>
> >> >> Reading the RSSI by the kernel, will force a certain limitation on the
> >> >> current and future Profiles. I believe setting the timing should be done
> >> >> by the profile itself, not the bluez user space code or the kernel. It
> >> >> is the responsibility of the profile to periodically poll the RSSI Level.
> >> >> For some cases, polling it every 5 seconds would be ok, and for some
> >> >> Others, it may be better to read it every second. I believe we must not
> >> >> impose any limitation here.
> >> >
> >> > You probably forgot that besides bluetoothd there should be no other
> >> > application holding the mgmt socket, so not you can't really do it in
> >> > poll in the application side and doing it over D-Bus is overkill. Also
> >> > I notice that from some parties, you include, there is some tendency
> >> > to have the profiles split from the bluetoothd, IMO this will only add
> >> > fragmentation with each and every platform using BlueZ having their
> >> > own implementation of each profile and not sharing much, making the
> >> > IOP a complete mess.
> >> >
> >>
> >> Some additional comments...
> >>
> >> Health plugin will need a similar approach to read the clock. It will
> >> be good to implement the same approach.
> >> In our suggested implementation the adapter controls when to send the
> >> command to read the RSSI, keeping the same logic for both: hciops and
> >> mgmtops. If the adapter is managing when to send the commands,
> >> repeated commands can be avoided, multiple callbacks can be registered
> >> by the profiles, but only one command to read the RSSI will be sent.
> >> The cover letter of the userspace patches contains more details how we
> >> implemented it.
> >>
> >> Reading the RSSI directly by the kernel will break hciops. These are
> >> the arguments that I have to support our decision.
> >
> > what I am hearing is that we want the kernel to poll for certain
> > information if userspace needs them. And either it is a one-shot poll or
> > it is on a regular interval.
>
> If everybody agree we can do it. Our objective is to have the patches upstream.
> To keep the Proximity Monitor functional on both adapter_ops plugins
> we can move part of the logic from the adapter.c to the hciops. The
> polling to read the RSSI can be moved to hciops, in the management the
> polling will be in the kernel. The remaining code to register the
> callbacks doesn't need to be changed.
Do we have a really good reason to implement this both for hciops and mgmtops?
We wrote mgmt interface to solve our problems. So why do we still care about
put new stuff on hciops? And then we maintain two pieces of code instead
of one.
Gustavo
Hi Claudio,
> >> >>> if TX power is only read once than the kernel should just do it once
> >> >>> and
> >> >>> be done with it.
> >> >>>
> >> >>> And for RSSI, it would be better if the kernel read this periodically
> >> >>> based on current sniff mode etc. Userspace can not trigger this with
> >> >>> proper timing anyway. And it will potentially at some point start
> >> >>> blocking the controller. Only the kernel really knows when it is
> >> >>> acceptable to read the RSSI value.
> >> >>
> >> >> Reading the RSSI by the kernel, will force a certain limitation on the
> >> >> current and future Profiles. I believe setting the timing should be done
> >> >> by the profile itself, not the bluez user space code or the kernel. It
> >> >> is the responsibility of the profile to periodically poll the RSSI Level.
> >> >> For some cases, polling it every 5 seconds would be ok, and for some
> >> >> Others, it may be better to read it every second. I believe we must not
> >> >> impose any limitation here.
> >> >
> >> > You probably forgot that besides bluetoothd there should be no other
> >> > application holding the mgmt socket, so not you can't really do it in
> >> > poll in the application side and doing it over D-Bus is overkill. Also
> >> > I notice that from some parties, you include, there is some tendency
> >> > to have the profiles split from the bluetoothd, IMO this will only add
> >> > fragmentation with each and every platform using BlueZ having their
> >> > own implementation of each profile and not sharing much, making the
> >> > IOP a complete mess.
> >> >
> >>
> >> Some additional comments...
> >>
> >> Health plugin will need a similar approach to read the clock. It will
> >> be good to implement the same approach.
> >> In our suggested implementation the adapter controls when to send the
> >> command to read the RSSI, keeping the same logic for both: hciops and
> >> mgmtops. If the adapter is managing when to send the commands,
> >> repeated commands can be avoided, multiple callbacks can be registered
> >> by the profiles, but only one command to read the RSSI will be sent.
> >> The cover letter of the userspace patches contains more details how we
> >> implemented it.
> >>
> >> Reading the RSSI directly by the kernel will break hciops. These are
> >> the arguments that I have to support our decision.
> >
> > what I am hearing is that we want the kernel to poll for certain
> > information if userspace needs them. And either it is a one-shot poll or
> > it is on a regular interval.
>
> If everybody agree we can do it. Our objective is to have the patches upstream.
> To keep the Proximity Monitor functional on both adapter_ops plugins
> we can move part of the logic from the adapter.c to the hciops. The
> polling to read the RSSI can be moved to hciops, in the management the
> polling will be in the kernel. The remaining code to register the
> callbacks doesn't need to be changed.
> Do you agree?
I am really open for suggestion, but just duplicating HCI is not going
to cut it. We have to be a lot smarter with the kernel mgmt interface.
So lets give this approach and go and see how it works out. And btw. I
do not care about the hciops that much anymore. If you wanna do the hard
work to make it work, fine with me.
> > The management interface will be primarily used by bluetoothd, but it is
> > open for other users as well. Mainly some low-level system tools or more
> > important qualification tools.
> >
> > So triggering certain actions from userspace is always tricky and then
> > we need to have bluetoothd sync with itself, its plugins etc. So I
> > rather prefer that we tell the kernel which pollable information to read
> > at which interval and then just get a notification if they have changed.
> > Let the kernel do its job without having to wakeup half of userspace to
> > make a simple decision to poll a value.
> >
> > And don't get me wrong, the stupid Bluetooth chip should be able to poll
> > this value with an interval natively. The best we can do is emulate that
> > in the kernel.
>
> No problem. We will change the code and send another RFC.
> Do you want another channel in the BTPROTO_HCI socket or keep
> everything inside HCI_CHANNEL_CONTROL?
It is an async event on HCI_CHANNEL_CONTROL. That is good enough for me.
Regards
Marcel
Hi Marcel,
On Thu, Jun 16, 2011 at 11:47 AM, Marcel Holtmann <[email protected]> wrote:
> Hi Claudio,
>
>> >>> if TX power is only read once than the kernel should just do it once
>> >>> and
>> >>> be done with it.
>> >>>
>> >>> And for RSSI, it would be better if the kernel read this periodically
>> >>> based on current sniff mode etc. Userspace can not trigger this with
>> >>> proper timing anyway. And it will potentially at some point start
>> >>> blocking the controller. Only the kernel really knows when it is
>> >>> acceptable to read the RSSI value.
>> >>
>> >> Reading the RSSI by the kernel, will force a certain limitation on the
>> >> current and future Profiles. I believe setting the timing should be done
>> >> by the profile itself, not the bluez user space code or the kernel. It
>> >> is the responsibility of the profile to periodically poll the RSSI Level.
>> >> For some cases, polling it every 5 seconds would be ok, and for some
>> >> Others, it may be better to read it every second. I believe we must not
>> >> impose any limitation here.
>> >
>> > You probably forgot that besides bluetoothd there should be no other
>> > application holding the mgmt socket, so not you can't really do it in
>> > poll in the application side and doing it over D-Bus is overkill. Also
>> > I notice that from some parties, you include, there is some tendency
>> > to have the profiles split from the bluetoothd, IMO this will only add
>> > fragmentation with each and every platform using BlueZ having their
>> > own implementation of each profile and not sharing much, making the
>> > IOP a complete mess.
>> >
>>
>> Some additional comments...
>>
>> Health plugin will need a similar approach to read the clock. It will
>> be good to implement the same approach.
>> In our suggested implementation the adapter controls when to send the
>> command to read the RSSI, keeping the same logic for both: hciops and
>> mgmtops. If the adapter is managing when to send the commands,
>> repeated commands can be avoided, multiple callbacks can be registered
>> by the profiles, but only one command to read the RSSI will be sent.
>> The cover letter of the userspace patches contains more details how we
>> implemented it.
>>
>> Reading the RSSI directly by the kernel will break hciops. These are
>> the arguments that I have to support our decision.
>
> what I am hearing is that we want the kernel to poll for certain
> information if userspace needs them. And either it is a one-shot poll or
> it is on a regular interval.
If everybody agree we can do it. Our objective is to have the patches upstream.
To keep the Proximity Monitor functional on both adapter_ops plugins
we can move part of the logic from the adapter.c to the hciops. The
polling to read the RSSI can be moved to hciops, in the management the
polling will be in the kernel. The remaining code to register the
callbacks doesn't need to be changed.
Do you agree?
>
> The management interface will be primarily used by bluetoothd, but it is
> open for other users as well. Mainly some low-level system tools or more
> important qualification tools.
>
> So triggering certain actions from userspace is always tricky and then
> we need to have bluetoothd sync with itself, its plugins etc. So I
> rather prefer that we tell the kernel which pollable information to read
> at which interval and then just get a notification if they have changed.
> Let the kernel do its job without having to wakeup half of userspace to
> make a simple decision to poll a value.
>
> And don't get me wrong, the stupid Bluetooth chip should be able to poll
> this value with an interval natively. The best we can do is emulate that
> in the kernel.
No problem. We will change the code and send another RFC.
Do you want another channel in the BTPROTO_HCI socket or keep
everything inside HCI_CHANNEL_CONTROL?
BR,
Claudio.
>
> Regards
>
> Marcel
>
Hi Claudio,
> >>> if TX power is only read once than the kernel should just do it once
> >>> and
> >>> be done with it.
> >>>
> >>> And for RSSI, it would be better if the kernel read this periodically
> >>> based on current sniff mode etc. Userspace can not trigger this with
> >>> proper timing anyway. And it will potentially at some point start
> >>> blocking the controller. Only the kernel really knows when it is
> >>> acceptable to read the RSSI value.
> >>
> >> Reading the RSSI by the kernel, will force a certain limitation on the
> >> current and future Profiles. I believe setting the timing should be done
> >> by the profile itself, not the bluez user space code or the kernel. It
> >> is the responsibility of the profile to periodically poll the RSSI Level.
> >> For some cases, polling it every 5 seconds would be ok, and for some
> >> Others, it may be better to read it every second. I believe we must not
> >> impose any limitation here.
> >
> > You probably forgot that besides bluetoothd there should be no other
> > application holding the mgmt socket, so not you can't really do it in
> > poll in the application side and doing it over D-Bus is overkill. Also
> > I notice that from some parties, you include, there is some tendency
> > to have the profiles split from the bluetoothd, IMO this will only add
> > fragmentation with each and every platform using BlueZ having their
> > own implementation of each profile and not sharing much, making the
> > IOP a complete mess.
> >
>
> Some additional comments...
>
> Health plugin will need a similar approach to read the clock. It will
> be good to implement the same approach.
> In our suggested implementation the adapter controls when to send the
> command to read the RSSI, keeping the same logic for both: hciops and
> mgmtops. If the adapter is managing when to send the commands,
> repeated commands can be avoided, multiple callbacks can be registered
> by the profiles, but only one command to read the RSSI will be sent.
> The cover letter of the userspace patches contains more details how we
> implemented it.
>
> Reading the RSSI directly by the kernel will break hciops. These are
> the arguments that I have to support our decision.
what I am hearing is that we want the kernel to poll for certain
information if userspace needs them. And either it is a one-shot poll or
it is on a regular interval.
The management interface will be primarily used by bluetoothd, but it is
open for other users as well. Mainly some low-level system tools or more
important qualification tools.
So triggering certain actions from userspace is always tricky and then
we need to have bluetoothd sync with itself, its plugins etc. So I
rather prefer that we tell the kernel which pollable information to read
at which interval and then just get a notification if they have changed.
Let the kernel do its job without having to wakeup half of userspace to
make a simple decision to poll a value.
And don't get me wrong, the stupid Bluetooth chip should be able to poll
this value with an interval natively. The best we can do is emulate that
in the kernel.
Regards
Marcel
> -----Original Message-----
> From: Anderson Lizardo [mailto:[email protected]]
> Sent: Thursday, June 16, 2011 4:45 PM
> To: Ganir, Chen
> Cc: Marcel Holtmann; [email protected]; linux-
> [email protected]; Bruna Moreira
> Subject: Re: [RFC 7/7] Update Management API documentation
>=20
> Hi Chen,
>=20
> On Thu, Jun 16, 2011 at 2:03 AM, Ganir, Chen <[email protected]> wrote:
> > Please note that this is currently true for LE connection, but may
> change
> > in the future.
>=20
> If you read the latest Proximity draft (not from bluetooth.org, from
> the mailing lists), you will see that the recommendation to read TX
> power once on LE is to conserve power (specially on the single mode
> device, I suppose, but it would waste power on the BlueZ side as
> well). Unfortunately, if they change the recommendation again (in this
> case they would be returning to a previous decision), we would
> inevitably have to change implementation anyway.
Anderson,
>From the version I have (d10), it is clearly seen that it can support both
BR/EDR and LE as well (service discovery for example is explained for both
BR/EDR and LE). In addition, it is stated in this version of the spec that
The TX power characteristic should return the current TX power level. This
means that if there is any chance that this level changes, it must be updat=
ed
periodically, or read each time the characteristic is accessed for reading
(with the suggested GATT server callback mechanism).Furthermore, it is clea=
rly=20
specified that on BR/EDR, when the TX Power level changes, the reporter=20
should notify the monitor about the change, if it's registered for these=20
notifications.
I see no reason to implement different behavior or logic for BE/EDR or LE.=
=20
In addition, I do not believe it is the responsibility of the bluez stack=20
(adapter in this case) to set the intervals for getting this info - it is=20
the responsibility of the profile, whether it is implemented as a bluez plu=
gin=20
(so the plugin initiates the RSSI/TX Power readings according to its own=20
timing) or by an external profile (if future bluez implementation allows th=
is).
Thanks,
Chen Ganir
Hi Johan,
On Thu, Jun 16, 2011 at 10:08 AM, Johan Hedberg <[email protected]> wrote:
>> I would like to bring attention to a thread I attempted to start some
>> time ago, named "D-Bus GATT API for external/proprietary profiles". If
>> anyone is really willing to implement external profiles over D-Bus,
>> please voice your points that would support this. Note that this
>> attempt never happened before, AFAIK all bluez supported profiles are
>> implemented internally on bluez source code, usually as plugins.
>
> Not all profiles. There's e.g. the OBEX profiles provided by obexd. The
> main reason for that separation is that practically everything handled
> by obexd is user data which doesn't belong in a system level daemon like
> bluetoothd. The same system-user separation could be a reason for other
> profiles to exist in separate processes. Then there's also partial
> splits like that for HFP where audio is handled by an audio subsystem
> like PulseAudio and signaling by a cellular subsystem like oFono.
Thanks for the clarification. I completely forgot about these cases
(also I don't actually know how obexd integrates with bluetoothd,
blame on me). But looks like the decision to whether to implement a
profile fully inside or outside (partially or not) bluez is per
profile, right? I think GATT profiles are so diverse that we would
have to make the decision on a profile basis. In this case, it helps
each profile having its own D-Bus API and plugin.
Proximity, for instance, is so attached to the connection state (and
depending on RSSI and TX power) that it would be an example of one
profile that is best implemented next to BlueZ.
Future GATT profiles which might need to read a lot of user
information might need a split from bluetoothd process.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hi Lizardo,
On Thu, Jun 16, 2011, Anderson Lizardo wrote:
> On Thu, Jun 16, 2011 at 3:54 AM, Luiz Augusto von Dentz
> <[email protected]> wrote:
> > You probably forgot that besides bluetoothd there should be no other
> > application holding the mgmt socket, so not you can't really do it in
> > poll in the application side and doing it over D-Bus is overkill. Also
> > I notice that from some parties, you include, there is some tendency
> > to have the profiles split from the bluetoothd, IMO this will only add
> > fragmentation with each and every platform using BlueZ having their
> > own implementation of each profile and not sharing much, making the
> > IOP a complete mess.
>
> I would like to bring attention to a thread I attempted to start some
> time ago, named "D-Bus GATT API for external/proprietary profiles". If
> anyone is really willing to implement external profiles over D-Bus,
> please voice your points that would support this. Note that this
> attempt never happened before, AFAIK all bluez supported profiles are
> implemented internally on bluez source code, usually as plugins.
Not all profiles. There's e.g. the OBEX profiles provided by obexd. The
main reason for that separation is that practically everything handled
by obexd is user data which doesn't belong in a system level daemon like
bluetoothd. The same system-user separation could be a reason for other
profiles to exist in separate processes. Then there's also partial
splits like that for HFP where audio is handled by an audio subsystem
like PulseAudio and signaling by a cellular subsystem like oFono.
Johan
Hi Ajay,
On Thu, Jun 16, 2011 at 3:15 AM, Ajay Pillai <[email protected]> wrote:
> I have been reading some posts where the GATT profiles were referred to as "plugins".
>
> Could you tell me what is a "plugin" in this context?
It is a BlueZ plugin. See the plugins/ directory on BlueZ sources for
example of simple (non-GATT) plugins. There are other plugins
dedicated directories as well, run "grep -R BLUETOOTH_PLUGIN_DEFINE *"
on source to find them.
> Are these profiles running in a separate process space (to rest of BlueZ having GATT /ATT)?
Same process. They are usually builtin (statically linked with
bluetoothd binary), but can be also .so files loaded when bluetoothd
is started.
> Can these profiles be brought up and down at run time?
Not really. But they can be prevented from being started, if you pass
the -P <pluginname> option.
> Can nonstandard usecases be implemented and plugged in to use GATT from BlueZ?
If you implement your own BlueZ plugin, yes. But be sure to check the
BlueZ license, I don't know if standalone plugins would have to follow
the same license as BlueZ itself (I assume yes, as there is no
"exception" to GPL like on kernel).
> I am happy to have some code references that can show me the answer to these.
Be sure to follow the latest LE related patches which are being sent
to the list, and the ones which are going to be sent in the next days.
We are trying to submit upstream the infrastructure necessary for
implementing LE profiles ASAP. They will be probably sent as RFC, as
they add new infrastructure which we would like to get some feedback
first.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hi,
On Thu, Jun 16, 2011 at 3:54 AM, Luiz Augusto von Dentz
<[email protected]> wrote:
> You probably forgot that besides bluetoothd there should be no other
> application holding the mgmt socket, so not you can't really do it in
> poll in the application side and doing it over D-Bus is overkill. Also
> I notice that from some parties, you include, there is some tendency
> to have the profiles split from the bluetoothd, IMO this will only add
> fragmentation with each and every platform using BlueZ having their
> own implementation of each profile and not sharing much, making the
> IOP a complete mess.
I would like to bring attention to a thread I attempted to start some
time ago, named "D-Bus GATT API for external/proprietary profiles". If
anyone is really willing to implement external profiles over D-Bus,
please voice your points that would support this. Note that this
attempt never happened before, AFAIK all bluez supported profiles are
implemented internally on bluez source code, usually as plugins.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hi Chen,
On Thu, Jun 16, 2011 at 2:03 AM, Ganir, Chen <[email protected]> wrote:
> Please note that this is currently true for LE connection, but may change
> in the future.
If you read the latest Proximity draft (not from bluetooth.org, from
the mailing lists), you will see that the recommendation to read TX
power once on LE is to conserve power (specially on the single mode
device, I suppose, but it would waste power on the BlueZ side as
well). Unfortunately, if they change the recommendation again (in this
case they would be returning to a previous decision), we would
inevitably have to change implementation anyway.
> In addition, TX Power for BR/EDR may change during the
> connection (by the controller, depending on LMP commands), so reading it
> periodically and updating the GATT server must be implemented.
I don't really feel comfortable on discussing things which are not
adopted on BT-SIG yet but... Are you aware of any latest GATT profiles
which support BR/EDR? Be sure to check the latest drafts from BT-SIG
mailing lists.
I'm not saying it will *never* happen, but I think we should make
development decisions on what we know at the moment, not on what might
be possibly added to a future (not yet existing) profile. Otherwise we
risk doing unnecessary things for current profiles, like reading TX
Power periodically when a GATT profile would recommend reading once.
My two cents,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hi,
On Thu, Jun 16, 2011 at 4:54 AM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi,
>
> On Thu, Jun 16, 2011 at 9:07 AM, Ganir, Chen <[email protected]> wrote:
>>>
>>> if TX power is only read once than the kernel should just do it once
>>> and
>>> be done with it.
>>>
>>> And for RSSI, it would be better if the kernel read this periodically
>>> based on current sniff mode etc. Userspace can not trigger this with
>>> proper timing anyway. And it will potentially at some point start
>>> blocking the controller. Only the kernel really knows when it is
>>> acceptable to read the RSSI value.
>>>
>>> Regards
>>>
>>> Marcel
>>>
>>>
>>
>> Marcel,
>>
>> Reading the RSSI by the kernel, will force a certain limitation on the
>> current and future Profiles. I believe setting the timing should be done
>> by the profile itself, not the bluez user space code or the kernel. It
>> is the responsibility of the profile to periodically poll the RSSI Level.
>> For some cases, polling it every 5 seconds would be ok, and for some
>> Others, it may be better to read it every second. I believe we must not
>> impose any limitation here.
>
> You probably forgot that besides bluetoothd there should be no other
> application holding the mgmt socket, so not you can't really do it in
> poll in the application side and doing it over D-Bus is overkill. Also
> I notice that from some parties, you include, there is some tendency
> to have the profiles split from the bluetoothd, IMO this will only add
> fragmentation with each and every platform using BlueZ having their
> own implementation of each profile and not sharing much, making the
> IOP a complete mess.
>
>
> --
> Luiz Augusto von Dentz
> --
Some additional comments...
Health plugin will need a similar approach to read the clock. It will
be good to implement the same approach.
In our suggested implementation the adapter controls when to send the
command to read the RSSI, keeping the same logic for both: hciops and
mgmtops. If the adapter is managing when to send the commands,
repeated commands can be avoided, multiple callbacks can be registered
by the profiles, but only one command to read the RSSI will be sent.
The cover letter of the userspace patches contains more details how we
implemented it.
Reading the RSSI directly by the kernel will break hciops. These are
the arguments that I have to support our decision.
BR,
Claudio.
Hi,
On Thu, Jun 16, 2011 at 9:07 AM, Ganir, Chen <[email protected]> wrote:
>>
>> if TX power is only read once than the kernel should just do it once
>> and
>> be done with it.
>>
>> And for RSSI, it would be better if the kernel read this periodically
>> based on current sniff mode etc. Userspace can not trigger this with
>> proper timing anyway. And it will potentially at some point start
>> blocking the controller. Only the kernel really knows when it is
>> acceptable to read the RSSI value.
>>
>> Regards
>>
>> Marcel
>>
>>
>
> Marcel,
>
> Reading the RSSI by the kernel, will force a certain limitation on the
> current and future Profiles. I believe setting the timing should be done
> by the profile itself, not the bluez user space code or the kernel. It
> is the responsibility of the profile to periodically poll the RSSI Level.
> For some cases, polling it every 5 seconds would be ok, and for some
> Others, it may be better to read it every second. I believe we must not
> impose any limitation here.
You probably forgot that besides bluetoothd there should be no other
application holding the mgmt socket, so not you can't really do it in
poll in the application side and doing it over D-Bus is overkill. Also
I notice that from some parties, you include, there is some tendency
to have the profiles split from the bluetoothd, IMO this will only add
fragmentation with each and every platform using BlueZ having their
own implementation of each profile and not sharing much, making the
IOP a complete mess.
--
Luiz Augusto von Dentz
SGksDQoNCkkgaGF2ZSBiZWVuIHJlYWRpbmcgc29tZSBwb3N0cyB3aGVyZSB0
aGUgR0FUVCBwcm9maWxlcyB3ZXJlIHJlZmVycmVkIHRvIGFzICJwbHVnaW5z
Ii4NCg0KQ291bGQgeW91IHRlbGwgbWUgd2hhdCBpcyBhICJwbHVnaW4iIGlu
IHRoaXMgY29udGV4dD8NCkFyZSB0aGVzZSBwcm9maWxlcyBydW5uaW5nIGlu
IGEgc2VwYXJhdGUgcHJvY2VzcyBzcGFjZSAodG8gcmVzdCBvZiBCbHVlWiBo
YXZpbmcgR0FUVCAvQVRUKT8NCkNhbiB0aGVzZSBwcm9maWxlcyBiZSBicm91
Z2h0IHVwIGFuZCBkb3duIGF0IHJ1biB0aW1lPw0KQ2FuIG5vbnN0YW5kYXJk
IHVzZWNhc2VzIGJlIGltcGxlbWVudGVkIGFuZCBwbHVnZ2VkIGluIHRvIHVz
ZSBHQVRUIGZyb20gQmx1ZVo/DQoNCkkgYW0gaGFwcHkgdG8gaGF2ZSBzb21l
IGNvZGUgcmVmZXJlbmNlcyB0aGF0IGNhbiBzaG93IG1lIHRoZSBhbnN3ZXIg
dG8gdGhlc2UuDQoNClRoYW5rIHlvdQ0KYWpheQ0KCgpNZW1iZXIgb2YgdGhl
IENTUiBwbGMgZ3JvdXAgb2YgY29tcGFuaWVzLiBDU1IgcGxjIHJlZ2lzdGVy
ZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMsIHJlZ2lzdGVyZWQgbnVtYmVyIDQx
ODczNDYsIHJlZ2lzdGVyZWQgb2ZmaWNlIENodXJjaGlsbCBIb3VzZSwgQ2Ft
YnJpZGdlIEJ1c2luZXNzIFBhcmssIENvd2xleSBSb2FkLCBDYW1icmlkZ2Us
IENCNCAwV1osIFVuaXRlZCBLaW5nZG9tCk1vcmUgaW5mb3JtYXRpb24gY2Fu
IGJlIGZvdW5kIGF0IHd3dy5jc3IuY29tLiBGb2xsb3cgQ1NSIG9uIFR3aXR0
ZXIgYXQgaHR0cDovL3R3aXR0ZXIuY29tL0NTUl9QTEMgYW5kIHJlYWQgb3Vy
IGJsb2cgYXQgd3d3LmNzci5jb20vYmxvZwo=
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsaW51eC1ibHVldG9vdGgtb3du
ZXJAdmdlci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtYmx1ZXRvb3RoLQ0KPiBvd25lckB2Z2Vy
Lmtlcm5lbC5vcmddIE9uIEJlaGFsZiBPZiBNYXJjZWwgSG9sdG1hbm4NCj4gU2VudDogVGh1cnNk
YXksIEp1bmUgMTYsIDIwMTEgNToyOSBBTQ0KPiBUbzogQW5kZXJzb24gTGl6YXJkbw0KPiBDYzog
YW5kZXJzb24uYnJpZ2xpYUBvcGVuYm9zc2Eub3JnOyBsaW51eC1ibHVldG9vdGhAdmdlci5rZXJu
ZWwub3JnOw0KPiBCcnVuYSBNb3JlaXJhDQo+IFN1YmplY3Q6IFJlOiBbUkZDIDcvN10gVXBkYXRl
IE1hbmFnZW1lbnQgQVBJIGRvY3VtZW50YXRpb24NCj4gDQo+IEhpIEFuZGVyc29uLA0KPiANCj4g
PiA+IHNvIHdoeSBhcmUgdGhlc2UgdHdvIHNlcGFyYXRlIGNvbW1hbmRzLiBKdXN0IHJlYWRpbmcg
dGhlbSBpbiBvbmUNCj4ga2VybmVsDQo+ID4gPiBjYWxsIG1pZ2h0IGJlIGEgbG90IGJldHRlci4g
SW5jbHVkaW5nIGV2ZXJ5dGhpbmcgZWxzZSB5b3UgbmVlZCB0bw0KPiBrbm93DQo+ID4gPiBhYm91
dCB0aGUgY29ubmVjdGlvbi4gQWxzbyBUWCBwb3dlciBjYW4gYmUgbG9jYWwgYW5kIHJlbW90ZSBU
WA0KPiBwb3dlciBpZg0KPiA+ID4gSSByZW1lbWJlciB0aGlzIGNvcnJlY3RseS4NCj4gPg0KPiA+
IFRoZSBpc3N1ZSBJIHNlZSB3aXRoIHlvdXIgcHJvcG9zYWwgaXMgdGhhdCBmb3IgUHJveGltaXR5
IChjdXJyZW50bHkNCj4gPiB0aGUgb25seSB1c2VyIG9mIHRoaXMgaW5mb3JtYXRpb24pIHdlIHJl
YWQgVFggcG93ZXIgZnJvbSBzZXJ2ZXINCj4gPiAocmVwb3J0ZXIpIHVzaW5nIEdBVFQsIHdoaWxl
IFJTU0kgaXMgcmVhZCBvbiBjbGllbnQgKG1vbml0b3IpIHNpZGUuDQo+IEJ5DQo+ID4gcmVhZGlu
ZyBib3RoLCB3ZSB3b3VsZCBuZWVkIHRvIGlzc3VlIHR3byBzZXBhcmF0ZSBIQ0kgY29tbWFuZHMg
KGFuZA0KPiA+IHdhaXQgZm9yIGJvdGggcmVzcG9uc2VzKSwgYnV0IHdpbGwgYWx3YXlzIHVzZSBv
bmx5IG9uZSB2YWx1ZSwNCj4gPiBkZXBlbmRpbmcgb24gbG9jYWwgQmx1ZVogcm9sZS4NCj4gPg0K
PiA+IEFsc28gbm90ZSB0aGF0IG9uIGxhdGVzdCBQcm94aW1pdHkgcHJvZmlsZSBkcmFmdHMsIGl0
IGlzIG1lbnRpb25lZA0KPiA+IHRoYXQgdGhlIFRYIHBvd2VyIG9uIHJlcG9ydGVyIHdpbGwgbmV2
ZXIgY2hhbmdlIGR1cmluZyBhIGNvbm5lY3Rpb24sDQo+ID4gYW5kIHRodXMgaXQgc2hvdWxkIGJl
IHJlYWQgb25seSBvbmNlIHdoZW4gdGhlIGNvbm5lY3Rpb24gaXMNCj4gPiBlc3RhYmxpc2hlZC4g
UlNTSSAod2hpY2ggaXMgcmVhZCAibG9jYWxseSIgb24gbW9uaXRvciBzaWRlKSwgb24gdGhlDQo+
ID4gb3RoZXIgaGFuZCwgc2hvdWxkIGJlIHJlYWQgcGVyaW9kaWNhbGx5IGZvciBwYXRoIGxvc3Mg
Y2FsY3VsYXRpb24uDQo+IA0KPiBpZiBUWCBwb3dlciBpcyBvbmx5IHJlYWQgb25jZSB0aGFuIHRo
ZSBrZXJuZWwgc2hvdWxkIGp1c3QgZG8gaXQgb25jZQ0KPiBhbmQNCj4gYmUgZG9uZSB3aXRoIGl0
Lg0KPiANCj4gQW5kIGZvciBSU1NJLCBpdCB3b3VsZCBiZSBiZXR0ZXIgaWYgdGhlIGtlcm5lbCBy
ZWFkIHRoaXMgcGVyaW9kaWNhbGx5DQo+IGJhc2VkIG9uIGN1cnJlbnQgc25pZmYgbW9kZSBldGMu
IFVzZXJzcGFjZSBjYW4gbm90IHRyaWdnZXIgdGhpcyB3aXRoDQo+IHByb3BlciB0aW1pbmcgYW55
d2F5LiBBbmQgaXQgd2lsbCBwb3RlbnRpYWxseSBhdCBzb21lIHBvaW50IHN0YXJ0DQo+IGJsb2Nr
aW5nIHRoZSBjb250cm9sbGVyLiBPbmx5IHRoZSBrZXJuZWwgcmVhbGx5IGtub3dzIHdoZW4gaXQg
aXMNCj4gYWNjZXB0YWJsZSB0byByZWFkIHRoZSBSU1NJIHZhbHVlLg0KPiANCj4gUmVnYXJkcw0K
PiANCj4gTWFyY2VsDQo+IA0KPiANCg0KTWFyY2VsLA0KDQpSZWFkaW5nIHRoZSBSU1NJIGJ5IHRo
ZSBrZXJuZWwsIHdpbGwgZm9yY2UgYSBjZXJ0YWluIGxpbWl0YXRpb24gb24gdGhlIA0KY3VycmVu
dCBhbmQgZnV0dXJlIFByb2ZpbGVzLiBJIGJlbGlldmUgc2V0dGluZyB0aGUgdGltaW5nIHNob3Vs
ZCBiZSBkb25lIA0KYnkgdGhlIHByb2ZpbGUgaXRzZWxmLCBub3QgdGhlIGJsdWV6IHVzZXIgc3Bh
Y2UgY29kZSBvciB0aGUga2VybmVsLiBJdCANCmlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUg
cHJvZmlsZSB0byBwZXJpb2RpY2FsbHkgcG9sbCB0aGUgUlNTSSBMZXZlbC4NCkZvciBzb21lIGNh
c2VzLCBwb2xsaW5nIGl0IGV2ZXJ5IDUgc2Vjb25kcyB3b3VsZCBiZSBvaywgYW5kIGZvciBzb21l
IA0KT3RoZXJzLCBpdCBtYXkgYmUgYmV0dGVyIHRvIHJlYWQgaXQgZXZlcnkgc2Vjb25kLiBJIGJl
bGlldmUgd2UgbXVzdCBub3QgDQppbXBvc2UgYW55IGxpbWl0YXRpb24gaGVyZS4NCg0KSW4gYWRk
aXRpb24sIFJTU0kgbGV2ZWxzIG1heSBub3QgYWx3YXlzIGJlIHJlcXVpcmVkIC0gc28gd2h5IHNo
b3VsZCB0aGUgDQpLZXJuZWwgcmVhZCB0aG9zZSB2YWx1ZXMgYW5kIHdhc3RlIGJhbmR3aWR0aD8N
Cg0KVGhhbmtzLA0KQ2hlbiBHYW5pci4NCg0K
> -----Original Message-----
> From: [email protected] [mailto:linux-bluetooth-
> [email protected]] On Behalf Of Anderson Lizardo
> Sent: Thursday, June 16, 2011 2:48 AM
> To: Marcel Holtmann
> Cc: [email protected]; [email protected];
> Bruna Moreira
> Subject: Re: [RFC 7/7] Update Management API documentation
>=20
> Hi Marcel,
>=20
> On Wed, Jun 15, 2011 at 6:10 PM, Marcel Holtmann <[email protected]>
> wrote:
> > so why are these two separate commands. Just reading them in one
> kernel
> > call might be a lot better. Including everything else you need to
> know
> > about the connection. Also TX power can be local and remote TX power
> if
> > I remember this correctly.
>=20
> The issue I see with your proposal is that for Proximity (currently
> the only user of this information) we read TX power from server
> (reporter) using GATT, while RSSI is read on client (monitor) side. By
> reading both, we would need to issue two separate HCI commands (and
> wait for both responses), but will always use only one value,
> depending on local BlueZ role.
>=20
> Also note that on latest Proximity profile drafts, it is mentioned
> that the TX power on reporter will never change during a connection,
> and thus it should be read only once when the connection is
> established. RSSI (which is read "locally" on monitor side), on the
> other hand, should be read periodically for path loss calculation.
Anderson,
Please note that this is currently true for LE connection, but may change=20
in the future. In addition, TX Power for BR/EDR may change during the=20
connection (by the controller, depending on LMP commands), so reading it=20
periodically and updating the GATT server must be implemented.
Chen Ganir.
Hi Anderson,
> > so why are these two separate commands. Just reading them in one kernel
> > call might be a lot better. Including everything else you need to know
> > about the connection. Also TX power can be local and remote TX power if
> > I remember this correctly.
>
> The issue I see with your proposal is that for Proximity (currently
> the only user of this information) we read TX power from server
> (reporter) using GATT, while RSSI is read on client (monitor) side. By
> reading both, we would need to issue two separate HCI commands (and
> wait for both responses), but will always use only one value,
> depending on local BlueZ role.
>
> Also note that on latest Proximity profile drafts, it is mentioned
> that the TX power on reporter will never change during a connection,
> and thus it should be read only once when the connection is
> established. RSSI (which is read "locally" on monitor side), on the
> other hand, should be read periodically for path loss calculation.
if TX power is only read once than the kernel should just do it once and
be done with it.
And for RSSI, it would be better if the kernel read this periodically
based on current sniff mode etc. Userspace can not trigger this with
proper timing anyway. And it will potentially at some point start
blocking the controller. Only the kernel really knows when it is
acceptable to read the RSSI value.
Regards
Marcel
Hi Marcel,
On Wed, Jun 15, 2011 at 6:10 PM, Marcel Holtmann <[email protected]> wrote:
> so why are these two separate commands. Just reading them in one kernel
> call might be a lot better. Including everything else you need to know
> about the connection. Also TX power can be local and remote TX power if
> I remember this correctly.
The issue I see with your proposal is that for Proximity (currently
the only user of this information) we read TX power from server
(reporter) using GATT, while RSSI is read on client (monitor) side. By
reading both, we would need to issue two separate HCI commands (and
wait for both responses), but will always use only one value,
depending on local BlueZ role.
Also note that on latest Proximity profile drafts, it is mentioned
that the TX power on reporter will never change during a connection,
and thus it should be read only once when the connection is
established. RSSI (which is read "locally" on monitor side), on the
other hand, should be read periodically for path loss calculation.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hi Anderson,
> Add Read RSSI and Read TX Power level commands in Management API
> documentation.
> ---
> doc/mgmt-api.txt | 20 ++++++++++++++++++++
> 1 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index 353705e..b442cc5 100644
> --- a/doc/mgmt-api.txt
> +++ b/doc/mgmt-api.txt
> @@ -319,6 +319,26 @@ Stop Discovery Command
> Command Parameters:
> Return Parameters:
>
> +Read RSSI Command
> +=================
> +
> + Command Code: 0x001D
> + Controller Index: <controller id>
> + Command Parameters: Address (6 Octets)
> + Return Parameters: Status (1 Octet)
> + Address (6 Octets)
> + RSSI (1 Octet)
> +
> +Read TX Power Level Command
> +===========================
> +
> + Command Code: 0x001E
> + Controller Index: <controller id>
> + Command Parameters: Address (6 Octets)
> + Return Parameters: Address (6 Octets)
> + Status (1 Octet)
> + Level (1 Octet)
> +
so why are these two separate commands. Just reading them in one kernel
call might be a lot better. Including everything else you need to know
about the connection. Also TX power can be local and remote TX power if
I remember this correctly.
Regards
Marcel