Hi Luiz,
On 03.08.2016 12:48, Luiz Augusto von Dentz wrote:
Hi Andrey,
On Tue, Aug 2, 2016 at 7:55 PM, Andrey Zheregelya
<andrey.zheregelya@xxxxxxxxxxxxxxx> wrote:
On 02.08.2016 18:57, Bastien Nocera wrote:
It's doesn't, really, until you apply heuristics to it. How do you plan
to use this?
Initially, there is a requirement for application to detect if a list of
device are available for connection or not. Before connection and after.
As far as I understood, d-bus interface doesn't provide any way to detect if
device is advertising or not.
le_seen and bredr_seen provides the last time when device's advertisement
packet was detected (Of course if my understanding is correct)
Application can read LastSeen time, read current time and compare with
application-defined timeout to make a decision if device is alive.
Yes, this property doesn't answer to direct question "Alive or not". But in
this way user can apply any heuristic algorithm he wants.
And this approach doesn't require any BLE connections to device.
But can't you use the last time you received a RSSI from the device?
Just timestamp it in the application side, in the other hand if
duplicate filtering is active this won't update in every packet
received since the controller can omit them.
Do you mean processing of PropertyChanged event for RSSI property?
If so, this means that GLib main loop should be used to process events.
Correct me if I'm wrong.
But application may has its own scheduler with a requirement not to use
Glib related schedule logic.
Offtopic:
Luiz, do you mean device_merge_duplicate function when mentioned about
duplicate filtering? How does it affect to RSSI updates?
--
Best regards, Andrey Zheregelya
--
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
