Hi,
I am working on Proximity Monitor Role using BlueZ 4.96 + and have a
query on the need for Timeout in case of Immediate Alert in file
proximity/monitor.c.
I feel that this timer is not required, because this will lead to
following scenario in case of Proximity Profile:
If Path loss has occurred and Immediate Alert has been written, then
after Timeout (5 seconds), Proximity Monitor will set immediate alert
level to ?none?, which will indicate to Proximity Reporter that Path
Loss is now within threshold, which actually might not be the case.
As per Sec 4.6 of Proximity Profile Spec,
?If the path loss falls below a threshold set on the Proximity Monitor
it shall write in the Alert Level characteristic of the Immediate
Alert service, using the GATT Write Without Response sub-procedure, to
cause the Proximity Reporter to end the alert. When the path loss is
below the threshold the Proximity Monitor should stop alerting.?
So this means that the proximity monitor should not change the alert
level to ?None? until the path loss is above Threshold.
Please let me know if my understanding is correct.
--
Best Regards
Hemant Gupta
ST-Ericsson India
Hi Lizardo,
On Thu, Dec 15, 2011 at 11:40 AM, Anderson Lizardo
<[email protected]> wrote:
> Hi Claudio,
>
> On Wed, Dec 14, 2011 at 12:46 PM, Claudio Takahasi
> <[email protected]> wrote:
>> Removing the timeout and write to "none" has a side effect: the remote
>> and the local value can have different values if the remote changes
>> the value. Alert Level characteristic doesn't support read,
>> notification or indication. Probably, all devices disable the alert
>> after some seconds to avoid drain the battery or be annoying.
>> The main problem is consistency: show to the user the correct value.
>
> In this case, I think the ImmediateAlertLevel should be write only
> (not readable). This forces applications to always write the level
> they want the peer device to alert. It means some spurious ATT write
> commands, but I think the spec assumes this is the case (otherwise it
> would allow read or notify).
>
> The problem is: is there such thing as "write only property" in BlueZ?
AFAIK there isn't example of write only property in BlueZ.
BR,
Claudio.
Hi Hemant,
On Wed, Dec 14, 2011 at 2:14 PM, Hemant Gupta <[email protected]> wrote:
> Hi Claudio,
>
> On Wed, Dec 14, 2011 at 10:16 PM, Claudio Takahasi
> <[email protected]> wrote:
>> Hi Hemant,
>>
>> On Wed, Dec 14, 2011 at 11:33 AM, Anderson Lizardo
>> <[email protected]> wrote:
>>> Hi Hemant,
>>>
>>> On Wed, Dec 14, 2011 at 10:18 AM, Hemant Gupta
>>> <[email protected]> wrote:
>>>> Hi,
>>>>
>>>> I am working on Proximity Monitor Role using BlueZ 4.96 + and have a
>>>> query on the need for Timeout in case of Immediate Alert in file
>>>> proximity/monitor.c.
>>>>
>>>> I feel that this timer is not required, because this will lead to
>>>> following scenario in case of Proximity Profile:
>>>>
>>>> If Path loss has occurred and Immediate Alert has been written, then
>>>> after Timeout (5 seconds), Proximity Monitor will set immediate alert
>>>> level to “none”, which will indicate to Proximity Reporter that Path
>>>> Loss is now within threshold, which actually might not be the case.
>>>
>>> I think this timeout is causing more harm than good (sometimes due to
>>> temporary latency between the two writes, the "none" alert level may
>>> arrive right after the previous level, which may cause the reporter to
>>> remain silent), so I agree with you. But I will wait for Claudio's
>>> opinion as he implemented this timeout in the first place :)
>>
>> Remember that Immediate Alert Service is used by Path Loss and Find Me.
>> How are you testing it if kernel RSSI Monitor patches are not upstream?
>
> I have implemented the RSSI monitoring in kernel and BlueZ and
> currently testing the same.
> I would upload the same soon on community.
Please sync with Anderson Briglia, he already sent a RFC to the ML
some months ago.
In the Bluetooth Summit(Prague), we decided to not proceed with RSSI
monitor emulation in the kernel until we have a clear idea or spec
defining how the controllers will implement RSSI monitoring.
The ideia was to provide transparency, the userspace doesn't need to
know if RSSI monitoring is emulated or not.
>>
>> Removing the timeout and write to "none" has a side effect: the remote
>> and the local value can have different values if the remote changes
>> the value. Alert Level characteristic doesn't support read,
>> notification or indication. Probably, all devices disable the alert
>> after some seconds to avoid drain the battery or be annoying.
>> The main problem is consistency: show to the user the correct value.
> Could you please elaborate a bit on this. I don't understand when you say the
> remote changes the value ? As per my understanding spec does not mention
> anything about consistency between the 2 Proximity devices for the Immediate
> alert level.
> Also as you mentioned there is no way of notifications, read from
> Immediate Alert
> Value on remote side, even having timer does not solve the purpose, as
> remote side might
> have a different timeout on alert (less than 5 seconds).
The timer is there to trigger overwriting the value if it is already
"none" or to disable the alert. The behavior in the remote side can be
implementation specific, the user can also interfere disabling the
alert(eg: pressing a button).
My point is: think in the UI elements behavior to implement the Find
Me Locator APP. It is easy to implement a event driven action than add
timers in the APP to control/block the user to press the
button(control states).
Does it help if we add a new property? eg: ImmediateAlertTimeout, zero
means disabled.
>>
>>>
>>>> As per Sec 4.6 of Proximity Profile Spec,
>>>> “If the path loss falls below a threshold set on the Proximity Monitor
>>>> it shall write in the Alert Level characteristic of the Immediate
>>>> Alert service, using the GATT Write Without Response sub-procedure, to
>>>> cause the Proximity Reporter to end the alert. When the path loss is
>>>> below the threshold the Proximity Monitor should stop alerting.”
>>>>
>>>> So this means that the proximity monitor should not change the alert
>>>> level to “None” until the path loss is above Threshold.
>>>
>>> I think it is better to not have BlueZ itself change the alert level
>>> to "none", instead the application can do this when it detects the
>>> path loss above Threshold. This can be easily achieved by monitoring
>>> the "SignalLevel" property changes on the Proximity API, and writing
>>> to ImmediateAlertLevel as necessary. After all, the threshold is
>>> dependent on the application settings.
>>
>> If this change doesn't cause problems to Find Me I agree with removing
>> this timeout/write.
> I don't think there is issue in case we remove the timer, if remote
> device is only supporting FindMe, because the alert should stop as
> soon as physical link is disconnected as per IAS specification Section
> 4.1
> This alert continues until one of following conditions occurs:
> - An implementation specific timeout.
> - User interaction on this device.
> - A new alert level is written.
> - The physical link is disconnected.
>
> Also it is assumed that the remote device would have some
> implementation specific timeout for the alert, as mentioned in spec,
> so in case we have both proximity and findme supported on remote
> device, then the
> remote side would stop alerting in case we have findme immediate alert
> on target.
When both are enabled it not possible to determine which service
triggered the IAS alert. If my previous suggestion doesn't help, I
don't see another way to keep both services qualifiable unless we
remove the timer and move the logic to the upper layer(I'd like to
avoid if possible).
BR,
Claudio.
Hi Claudio,
On Wed, Dec 14, 2011 at 12:46 PM, Claudio Takahasi
<[email protected]> wrote:
> Removing the timeout and write to "none" has a side effect: the remote
> and the local value can have different values if the remote changes
> the value. Alert Level characteristic doesn't support read,
> notification or indication. Probably, all devices disable the alert
> after some seconds to avoid drain the battery or be annoying.
> The main problem is consistency: show to the user the correct value.
In this case, I think the ImmediateAlertLevel should be write only
(not readable). This forces applications to always write the level
they want the peer device to alert. It means some spurious ATT write
commands, but I think the spec assumes this is the case (otherwise it
would allow read or notify).
The problem is: is there such thing as "write only property" in BlueZ?
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hi Claudio,
On Wed, Dec 14, 2011 at 10:16 PM, Claudio Takahasi
<[email protected]> wrote:
> Hi Hemant,
>
> On Wed, Dec 14, 2011 at 11:33 AM, Anderson Lizardo
> <[email protected]> wrote:
>> Hi Hemant,
>>
>> On Wed, Dec 14, 2011 at 10:18 AM, Hemant Gupta
>> <[email protected]> wrote:
>>> Hi,
>>>
>>> I am working on Proximity Monitor Role using BlueZ 4.96 + and have a
>>> query on the need for Timeout in case of Immediate Alert in file
>>> proximity/monitor.c.
>>>
>>> I feel that this timer is not required, because this will lead to
>>> following scenario in case of Proximity Profile:
>>>
>>> If Path loss has occurred and Immediate Alert has been written, then
>>> after Timeout (5 seconds), Proximity Monitor will set immediate alert
>>> level to ?none?, which will indicate to Proximity Reporter that Path
>>> Loss is now within threshold, which actually might not be the case.
>>
>> I think this timeout is causing more harm than good (sometimes due to
>> temporary latency between the two writes, the "none" alert level may
>> arrive right after the previous level, which may cause the reporter to
>> remain silent), so I agree with you. But I will wait for Claudio's
>> opinion as he implemented this timeout in the first place :)
>
> Remember that Immediate Alert Service is used by Path Loss and Find Me.
> How are you testing it if kernel RSSI Monitor patches are not upstream?
I have implemented the RSSI monitoring in kernel and BlueZ and
currently testing the same.
I would upload the same soon on community.
>
> Removing the timeout and write to "none" has a side effect: the remote
> and the local value can have different values if the remote changes
> the value. Alert Level characteristic doesn't support read,
> notification or indication. Probably, all devices disable the alert
> after some seconds to avoid drain the battery or be annoying.
> The main problem is consistency: show to the user the correct value.
Could you please elaborate a bit on this. I don't understand when you say the
remote changes the value ? As per my understanding spec does not mention
anything about consistency between the 2 Proximity devices for the Immediate
alert level.
Also as you mentioned there is no way of notifications, read from
Immediate Alert
Value on remote side, even having timer does not solve the purpose, as
remote side might
have a different timeout on alert (less than 5 seconds).
>
>>
>>> As per Sec 4.6 of Proximity Profile Spec,
>>> ?If the path loss falls below a threshold set on the Proximity Monitor
>>> it shall write in the Alert Level characteristic of the Immediate
>>> Alert service, using the GATT Write Without Response sub-procedure, to
>>> cause the Proximity Reporter to end the alert. When the path loss is
>>> below the threshold the Proximity Monitor should stop alerting.?
>>>
>>> So this means that the proximity monitor should not change the alert
>>> level to ?None? until the path loss is above Threshold.
>>
>> I think it is better to not have BlueZ itself change the alert level
>> to "none", instead the application can do this when it detects the
>> path loss above Threshold. This can be easily achieved by monitoring
>> the "SignalLevel" property changes on the Proximity API, and writing
>> to ImmediateAlertLevel as necessary. After all, the threshold is
>> dependent on the application settings.
>
> If this change doesn't cause problems to Find Me I agree with removing
> this timeout/write.
I don't think there is issue in case we remove the timer, if remote
device is only supporting FindMe, because the alert should stop as
soon as physical link is disconnected as per IAS specification Section
4.1
This alert continues until one of following conditions occurs:
- An implementation specific timeout.
- User interaction on this device.
- A new alert level is written.
- The physical link is disconnected.
Also it is assumed that the remote device would have some
implementation specific timeout for the alert, as mentioned in spec,
so in case we have both proximity and findme supported on remote
device, then the
remote side would stop alerting in case we have findme immediate alert
on target.
>
> Regards,
> Claudio
--
Best Regards
Hemant Gupta
ST-Ericsson India
Hi Hemant,
On Wed, Dec 14, 2011 at 11:33 AM, Anderson Lizardo
<[email protected]> wrote:
> Hi Hemant,
>
> On Wed, Dec 14, 2011 at 10:18 AM, Hemant Gupta
> <[email protected]> wrote:
>> Hi,
>>
>> I am working on Proximity Monitor Role using BlueZ 4.96 + and have a
>> query on the need for Timeout in case of Immediate Alert in file
>> proximity/monitor.c.
>>
>> I feel that this timer is not required, because this will lead to
>> following scenario in case of Proximity Profile:
>>
>> If Path loss has occurred and Immediate Alert has been written, then
>> after Timeout (5 seconds), Proximity Monitor will set immediate alert
>> level to “none”, which will indicate to Proximity Reporter that Path
>> Loss is now within threshold, which actually might not be the case.
>
> I think this timeout is causing more harm than good (sometimes due to
> temporary latency between the two writes, the "none" alert level may
> arrive right after the previous level, which may cause the reporter to
> remain silent), so I agree with you. But I will wait for Claudio's
> opinion as he implemented this timeout in the first place :)
Remember that Immediate Alert Service is used by Path Loss and Find Me.
How are you testing it if kernel RSSI Monitor patches are not upstream?
Removing the timeout and write to "none" has a side effect: the remote
and the local value can have different values if the remote changes
the value. Alert Level characteristic doesn't support read,
notification or indication. Probably, all devices disable the alert
after some seconds to avoid drain the battery or be annoying.
The main problem is consistency: show to the user the correct value.
>
>> As per Sec 4.6 of Proximity Profile Spec,
>> “If the path loss falls below a threshold set on the Proximity Monitor
>> it shall write in the Alert Level characteristic of the Immediate
>> Alert service, using the GATT Write Without Response sub-procedure, to
>> cause the Proximity Reporter to end the alert. When the path loss is
>> below the threshold the Proximity Monitor should stop alerting.”
>>
>> So this means that the proximity monitor should not change the alert
>> level to “None” until the path loss is above Threshold.
>
> I think it is better to not have BlueZ itself change the alert level
> to "none", instead the application can do this when it detects the
> path loss above Threshold. This can be easily achieved by monitoring
> the "SignalLevel" property changes on the Proximity API, and writing
> to ImmediateAlertLevel as necessary. After all, the threshold is
> dependent on the application settings.
If this change doesn't cause problems to Find Me I agree with removing
this timeout/write.
Regards,
Claudio
Hi Hemant,
On Wed, Dec 14, 2011 at 10:18 AM, Hemant Gupta
<[email protected]> wrote:
> Hi,
>
> I am working on Proximity Monitor Role using BlueZ 4.96 + and have a
> query on the need for Timeout in case of Immediate Alert in file
> proximity/monitor.c.
>
> I feel that this timer is not required, because this will lead to
> following scenario in case of Proximity Profile:
>
> If Path loss has occurred and Immediate Alert has been written, then
> after Timeout (5 seconds), Proximity Monitor will set immediate alert
> level to ?none?, which will indicate to Proximity Reporter that Path
> Loss is now within threshold, which actually might not be the case.
I think this timeout is causing more harm than good (sometimes due to
temporary latency between the two writes, the "none" alert level may
arrive right after the previous level, which may cause the reporter to
remain silent), so I agree with you. But I will wait for Claudio's
opinion as he implemented this timeout in the first place :)
> As per Sec 4.6 of Proximity Profile Spec,
> ?If the path loss falls below a threshold set on the Proximity Monitor
> it shall write in the Alert Level characteristic of the Immediate
> Alert service, using the GATT Write Without Response sub-procedure, to
> cause the Proximity Reporter to end the alert. When the path loss is
> below the threshold the Proximity Monitor should stop alerting.?
>
> So this means that the proximity monitor should not change the alert
> level to ?None? until the path loss is above Threshold.
I think it is better to not have BlueZ itself change the alert level
to "none", instead the application can do this when it detects the
path loss above Threshold. This can be easily achieved by monitoring
the "SignalLevel" property changes on the Proximity API, and writing
to ImmediateAlertLevel as necessary. After all, the threshold is
dependent on the application settings.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil