InfiniTimeOrg
Sample heart rate proportional to variance / inverse to stable bpm?
Verification
- [x] 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
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.
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...
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?
@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.
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.
+1 for configurable dynamic logging rate
side note (big tangent)
imo we should have more tunables. stuff like HR logging rates (be it dynamic and/or static), sync/data/stats exchange rate, and pedometer logging rate also a dynamic logginng rate for that would be nice too).
I feel I should mention that I don't expect any of these features, I just think they'd be lovely to have. :3 I understand the nature of foss and the need to prioritize core functionality over what is essentially bells and whistles, but it still doesn't hurt to share desired functionality. and yeah ik "why not implement them yourself" truly, contributing to this project or even having my own personal fork is a life goal for me. there's just something so fascinating about embedded devices, and being able to literally see the work that people (and eventually myself) put into this project and devices like the pinetime is just so beautiful. eventually I hope to have the mental energy to properly wrap my head around this project enough to be able contribute meaningful changes that benefit us all. okay I'm sorry for the very large tangent. also extra apologies to plain-text email subscribers ;w;
RE https://github.com/InfiniTimeOrg/InfiniTime/issues/2366#issuecomment-3508744364
Rightt, I see
I like your idea in concept - my concern is that the heart rate algorithm is so inconsistent that I don't think the data is good enough quality to start doing smart things with it like analysing trends. The signal to noise ratio on PPG (with this sensor) is really terrible, it's hard to describe without seeing the raw data. So for example there's no way you're analysing skipped beats unless you're completely still, and even then trying to resolve a change in the signal caused by motion versus some real PPG change is going to be next to impossible
RE https://github.com/InfiniTimeOrg/InfiniTime/issues/2366#issuecomment-3587454720
go for it :) if you know some C++ the project is not too hard to get started with imo. sure implementing OS functionality is harder but you could start with some smaller things to make it more the way you like (like changing some colours). and of course you're welcome to ask any questions you might have (the pinetime chat channels on matrix/discord/telegram are probably best)
not quite sure on what you mean by dynamic logging rates, what would that look like for the pedometer for example? currently it's sampled 10 times per second for any changes and they're broadcast immediately to any connected bluetooth device. there's no on device logging of steps history (other than #2120 which tracks daily step counts)
and yes feature suggestions are always welcome :) the discussions page is quite good for them as people can vote up the ones they want the most and discuss in a more forum like way
@mark9064 having had the watch for a bit now, and now that I'm more actively paying attention to the reported bpm, I'm noticing that for me at least the watch quite often I suppose is "dropping" to 0. I attempted to use it as a heart rate monitor for a training exercise and the other device essentially kept pausing because of the nonsense values, so at the moment I'm actually very interested in getting your ppgv2 branch working, but so far I've not had bpm results that make any sense. I think I messed up the twiddle factors for the FFT in the process of getting it to compile, I'm not sure, I'm going to have to restudy FFTs to make sense of what they should be.
Well given my day to day is C++ development, I quite like having a watch I can reprogram for fun. I didn't realize there were chat channels, I'll probably stick to pr comments. I suppose the major thing for me to make sense of this faster is the general code path that the microcontroller takes, or the build options, I think something's wrong in my setup, because all of my custom DFUs I've flashed, there's been one consistent quirk, that I lose the step tracker / motion controller. So for the moment I'm avoiding making edits for the step tracker.
Actually I need help with #2376, every tweak I've made hasn't resulted in the heart rate tracker pausing. I've managed to create a consistent crash, or having the screen constantly stay on. Does sending a "message" rewake the device or something?
@mark9064 your ppgv2 branch would be a good start I think, working from the results of the fft there should be plenty of data to work with.