Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sensor keeps disconnecting #39

Open
Fbrufino opened this issue May 3, 2024 · 4 comments
Open

Sensor keeps disconnecting #39

Fbrufino opened this issue May 3, 2024 · 4 comments
Labels
bug Something isn't working Linux

Comments

@Fbrufino
Copy link

Fbrufino commented May 3, 2024

Hi guys. First off, congrats for a great app, I'm really enjoying it so far.

The problem I have is my Polar H10 keeps disconnecting exactly 150 seconds after connection -- importantly, I'm referring to system-wide connection and disconnection, not within the app --, which is the same behavior I get when I just connect the H10 to the system and do nothing with it.

What made me conclude it's something related to the software -- or that the software can override, at least -- is that the same thing doesn't happen when I use another python HRV training module called Every Breath You Take (although I much prefer OpenHRV's feedback and recording capability).

I've tested this on two machines, and the behavior is the same across them:

  1. Debian 12, 6.1.0-20-amd64 kernel, TP-Link UB500 USB bluetooth adapter;
  2. Debian 12, 6.8.8-x64v3-xanmod1, onboard bluetooth adapter

Polar H10 info:

  • Firmware Revision: 5.0.0
  • Hardware Revision: 00760690.03
  • Software Revision: 3.2.0

I've tried changing /etc/bluetooth/input.conf, setting idletimeout=0 and userspaceHID=true, all with no success.

@Fbrufino Fbrufino changed the title Device keeps disconnecting Sensor keeps disconnecting May 4, 2024
@JanCBrammer JanCBrammer added the bug Something isn't working label May 4, 2024
@JanCBrammer
Copy link
Owner

JanCBrammer commented May 4, 2024

Thanks for the issue and thorough investigation @Fbrufino! I can confirm the issue on Ubuntu 22.04.4 (6.5.0 kernel) with an onboard Bluetooth adapter (Intel Corp. AX200 Bluetooth), OpenHRV 1.0.0, and a Polar H9 (firmware version 1.0.6). I'll dig into this if I find time. Which version of OpenHRV are you using? Are you running OpenHRV.bin from https://github.com/JanCBrammer/OpenHRV/releases/tag/v1.0.0, or via python -m openhrv.app?

@Fbrufino
Copy link
Author

Fbrufino commented May 5, 2024

Sorry, I did forget to mention I'm using OpenHRV 1.0.0 via python -m openhrv.app, CPython v3.9.11.

Don't know if it's relevant, but I couldn't determine if the disconnection is issued by Linux or the sensor, but my initial assumption is it's the sensor.

@JanCBrammer
Copy link
Owner

My initial hypothesis is that the disconnection is caused by a Qt timeout.
Every time the sensor disconnects, the following line shows up in the terminal:

print(f"Discarding sensor at {self._sensor_address()}.")

@Fbrufino
Copy link
Author

Fbrufino commented May 12, 2024

My initial hypothesis is that the disconnection is caused by a Qt timeout. Every time the sensor disconnects, the following line shows up in the terminal:

print(f"Discarding sensor at {self._sensor_address()}.")

I dunno, if I understood correctly that would be something the application does. The fact that either launching OpenHRV or doing nothing with the sensor (i.e. don't launch any application that interacts with it) after connection have the exact same result (disconnection from Linux after 150 secs) points me toward some internal configuration within the sensors to avoid idle connections.

Crucially, during some rounds of testing in the last few days, I ended up discovering that if I launch Every Breath You Take after connection, I can close it immediately after the app shows the first data points and then the sensor no longer disconnects even if I do nothing with it. So, as well as being a temporary workaround, this suggests the issue is something OpenHRV is not doing, rather than something it is doing. More exactly, I think there's some signal the Polar sensors are expecting in order to conclude that the connection is an "active" or valid one, and EBYT is sending that, possibly indirectly through its usage of bleak.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Linux
Projects
None yet
Development

No branches or pull requests

2 participants