> -----Original Message----- > From: linux-bluetooth-owner@xxxxxxxxxxxxxxx [mailto:linux-bluetooth- > owner@xxxxxxxxxxxxxxx] On Behalf Of Anderson Lizardo > Sent: Thursday, June 16, 2011 2:48 AM > To: Marcel Holtmann > Cc: anderson.briglia@xxxxxxxxxxxxx; linux-bluetooth@xxxxxxxxxxxxxxx; > Bruna Moreira > Subject: Re: [RFC 7/7] Update Management API documentation > > Hi Marcel, > > On Wed, Jun 15, 2011 at 6:10 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> > 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. Anderson, Please note that this is currently true for LE connection, but may change in the future. 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. Chen Ganir. -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
