Sample heart rate proportional to variance / inverse to stable bpm?

[Andersama]

Verification

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

Introduce the issue

The heart rate sensor appears to keep a history of samples, and the header for the heart rate tracker now appears to try to estimate when to sample. Consider making a togglable option or scale to reduce the frequency of updates, except where variance is high in the event of strange heart activity.

EG: If the ppg samples variance is high, have the background sample rate increase. Similarly if the heart rate is decreasing or increasing, sample more often. I'd imagine variance is more of an important factor.

Preferred solution

No response

Version

No response

[mark9064]

The sampling rate of sensor can be changed, but it is not useful as increasing it only gives more information on higher frequency components in the PPG signal (see nyquist theorem). A lower frequency would limit the heart rate detection range (and also isn't well supported by the hardware)

The frequency at which the heart rate estimation is made from the PPG signal can also be changed, but since it use welch's method to cope with spectral noise increasing the frequency won't do a whole lot (you just end up sampling an averaged signal more often). You could decrease it as well, but you'll begin to lose the spectral denoising property that comes with averaging often enough. The mathematics of HR inference as implemented in InfiniTime are not that expensive power wise, the PPG sensor is the vast majority of the power cost.

[Andersama]

Yeah I'm familiar with nyquist rate, I've written audio plugins. I'm talking about the heart rate tracker running in the background presumably not querying for heart rate data as often. EG: instead of running constantly, maybe every minute, five minutes...etc...

[mark9064]

Ah right, sorry I misread you there

The current implementation assumes if the screen is on the user is actively interfacing with the watch and so the heart rate should be kept up to date, and with #2322 you can choose if you want background measurements and with what frequency they should happen.

Just to check I've got you right, your suggestion is to switch to measuring less often when screen on with the goal of saving power?

[Andersama]

@mark9064 roughly speaking it'd probably just deal with stuff in the background. I'm thinking instead of a fixed delay there'd be an added option which would vary, and then I'd probably include some float/slider options to change how aggressive/relaxed the delays are. For me for example I have a slightly higher heart rate I'm working on keeping down, it's fairly consistent, but not always. So for the most part, I wouldn't mind a fixed delay, but* if it could adjust to sample more often when things get strange I'd take as a plus, and/or sample less often if things seem ok to save battery, also not bad.

[Andersama]

Lets say for example 70bpm is a fairly ok resting heart rate and 140 bpm for exercise.

I'd have some linear relationship probably taking the absolute difference between 70 and the actual rate. I'd probably skew it such that a lower than normal rate increases the sample rate quicker. Then I'd take the rate of change as a factor, EG: if heart rate spikes rapidly or drops I'd add that in. Then lastly there'd be the variance (not the average) of the samples recorded. I don't know what a normal pulse looks like to a ppg, but ideally you'd be able to catch something with the variance, so if something funky happens like you skip a beat or something that'd also be an indicator to sample more often.