> -----Original Message----- > From: Anderson Lizardo [mailto:anderson.lizardo@xxxxxxxxxxxxx] > Sent: Thursday, June 16, 2011 4:45 PM > To: Ganir, Chen > Cc: Marcel Holtmann; anderson.briglia@xxxxxxxxxxxxx; linux- > bluetooth@xxxxxxxxxxxxxxx; Bruna Moreira > Subject: Re: [RFC 7/7] Update Management API documentation > > Hi Chen, > > On Thu, Jun 16, 2011 at 2:03 AM, Ganir, Chen <chen.ganir@xxxxxx> 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. 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 updated periodically, or read each time the characteristic is accessed for reading (with the suggested GATT server callback mechanism).Furthermore, it is clearly specified that on BR/EDR, when the TX Power level changes, the reporter should notify the monitor about the change, if it's registered for these notifications. I see no reason to implement different behavior or logic for BE/EDR or LE. In addition, I do not believe it is the responsibility of the bluez stack (adapter in this case) to set the intervals for getting this info - it is the responsibility of the profile, whether it is implemented as a bluez plugin (so the plugin initiates the RSSI/TX Power readings according to its own timing) or by an external profile (if future bluez implementation allows this). Thanks, 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
