> -----Original Message----- > From: linux-bluetooth-owner@xxxxxxxxxxxxxxx [mailto:linux-bluetooth- > owner@xxxxxxxxxxxxxxx] On Behalf Of Marcel Holtmann > Sent: Thursday, June 16, 2011 5:29 AM > To: Anderson Lizardo > Cc: anderson.briglia@xxxxxxxxxxxxx; linux-bluetooth@xxxxxxxxxxxxxxx; > Bruna Moreira > Subject: Re: [RFC 7/7] Update Management API documentation > > 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 > > 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. In addition, RSSI levels may not always be required - so why should the Kernel read those values and waste bandwidth? Thanks, Chen Ganir. ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±ý¶ â^n‡r¡öë¨è&£ûz¹Þúzf£¢·hšˆ§~††Ûÿÿïÿ‘ê_èæ+v‰¨þ)ßø
