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

Heartrate Value jumps to 000 #1881

Closed
1 task done
0x0000ff opened this issue Oct 6, 2023 · 10 comments · Fixed by #1887
Closed
1 task done

Heartrate Value jumps to 000 #1881

0x0000ff opened this issue Oct 6, 2023 · 10 comments · Fixed by #1887
Labels
bug Something isn't working

Comments

@0x0000ff
Copy link

0x0000ff commented Oct 6, 2023

Verification

  • I searched for similar bug reports (including closed issues) and found none was relevant.

What happened?

The heartrate monitor will sporadically jump to 000, and will sometimes stay at that value. for a long time

What should happen instead?

No response

Reproduction steps

Wearing the watch, I select the heart rate app and leave it running.

More details?

No response

Version

v1.13.0

Companion app

Not currently paired with phone.

@0x0000ff 0x0000ff added the bug Something isn't working label Oct 6, 2023
@minacode
Copy link
Contributor

minacode commented Oct 7, 2023

Isn't this is the expected behavior when the measurement fails?

Edit: if it is, the watch should communicate that state better.

@mark9064
Copy link
Member

mark9064 commented Oct 7, 2023

Yeah, when the algorithm can't find a clean signal it reports 0

Would --- make more sense than 000? I think that'd be better - same goes for watchfaces (they could be just -) or even an ascii spinner if we're feeling a bit fun

@hellodarkness
Copy link

Yeah, when the algorithm can't find a clean signal it reports 0

Would --- make more sense than 000? I think that'd be better - same goes for watchfaces (they could be just -) or even an ascii spinner if we're feeling a bit fun

I agree with this. --- would match what's standard for a null reading on most devices.

I think feeding back a null value for watchface designers to choose how to handle might be good? Some of the fancier custom watch faces wouldn't suit an ascii spininer in my opinon.

@minacode
Copy link
Contributor

minacode commented Oct 8, 2023

Are these false zero values sent via Bluetooth? Might be correct to send nothing instead, if they are.

@mark9064
Copy link
Member

mark9064 commented Oct 9, 2023

They are sent by bluetooth, but it's the way to go there. There's no way in the bluetooth specification to signal that there is no value available, so zero is recognised as a null there. The only flag is to say whether sensor touch is present, and that's something quite different from an algorithm not being able to lock onto the HR.

@minacode
Copy link
Contributor

Shouldn't we have another flag for "no good measurement" then?
It's nice that the algorithm has the detection, but I think that we can use it better.

@mark9064
Copy link
Member

For bluetooth - no, as the characteristic is standardised. Every BLE device exposing heart rate values does so in the exact same format (in the BT SIG GATT spec)

On the watch - well there are only 3 states: off, on + no reading, on + reading. Arguably, there's also on + waiting for data (when it's just been started), but this is lumped into on + no reading currently. Currently, the on + no reading state reports a 0 on watchfaces / the HR app, and the idea here is to display --- / - instead of 0

I wasn't sure of the purpose of the flag you suggested here - these are the two ways I can interpret it. Or did you mean something else?

@minacode
Copy link
Contributor

Yes, that was helpful. Let me rephrase my question:
Do we send 0 via Bluetooth when the state is on + no reading?

@mark9064
Copy link
Member

Let's think about only reading the heart rate characteristic for a second (rather than notifications). Bluetooth characteristics (supporting read) always have a value present. So even if the sensor is completely off, the heart rate characteristic must have a value for the bpm (an integer). The only value that makes sense here is 0.

Since we always keep the state of client subscribed with notifications consistent with the value returned by reading a characteristic, it is correct to send a 0 whenever a value isn't available.

@minacode
Copy link
Contributor

Ok, thank you!

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

Successfully merging a pull request may close this issue.

4 participants