Heart rate measurement accuracy

[Riksu9000]

I have done some experiments with the heart rate sensor. I think one of the issue is that small movements while measuring can produce noise that could throw off the measurement. I don't think there's any code that detects noisy data and ignores it. The accelerometer could also be used to ignore data while there is movement. For some reason decreasing the gain improves accuracy for people. Why is that?

Setting the gain from 64 to 8 may have improved the results a bit. It worked at least as well as before.

Setting the LED current to 40mA didn't seem to make a difference.

The ambient light sensor could be used to detect if the watch isn't on the wrist, or if it's too loose, which could cause incorrect measurements as well.

Below you can see the SPL value graphed. This was with gain set to eight. The blinking light I added might actually be more accurate than the number shown, implying there might be an issue with the conversion to BPM. EDIT: Maybe its just HRV?

The data looks clean enough so it should be possible to get accurate measurements.

Here's the branch if anyone wants to test this.
https://github.com/Riksu9000/InfiniTime/tree/heartrate_test

VID_20210728_114837.mp4

[Riksu9000]

I just read that the sensor actually gives better results with less pressure. I think everyones first instinct is to tighten the strap to get better contact, myself included. Perhaps this is why people are having issues with it, and if so, we should make it known to everyone. Maybe even add instructions to the app.

[JF002]

The algorithm for the HR measurement comes from [WaspOS]'https://github.com/daniel-thompson/wasp-os/blob/master/wasp/ppg.py). I ported it from Python to C++. When I talked to Daniel about it, he told me that it was quite simple and should/could probably be much improved :)

I'm certainly not a specialist in signal processing, so I'm glad someone takes the time to have a look at this!
And the graph with the SPL values on the background of the HR app looks really good!!

[hatmajster]

Yes, very nice Riksu, I don't know how you guys do it here, but I would personally even merge this graph, its really nice to debug behavior of sensor :) Though maybe its feature creep in me;)
I've combined it with my own PR to change gain via options (#531) and was testing it a bit.
You say that 64x -> 8x may have improved things a bit. Well to me it fixes the problem - I don't expect the pine's sensor to be really accurate and there's probably much room for improvement - but current setting of x64 is just RNG:/ See for Yourself (its a bit badly cropped, but it should be visible, sorry). In the video I show how gain 8x, 4x and 64x works for me:

hrs.mp4

The left one is tomtom sports touch, some cheap oldish wristband. As You can see it probably has some filtering applied to bpm, because its too smooth. Or idk maybe just does things better, incrementally somehow.
I don't know what's the reason for such difference in opinions, when some folks claim that x64 is fine, and some (myself included) claim its terrible, maybe its the sensor itself, maybe something about blood pressure, etc. All I know is that to me x1-x8 is okayish, x64 is just lottery.
That's why I think it would be good idea to have a temporary gain customization (#531), just to let folks find their own favorite gain, and at some point pick one best in a survey or something like that. After this gain option will probably be not needed anymore. And besides maybe even by then InfiniTime will have some sophisticated approach to have even better sensor readings;)

[hatmajster]

Oh and also, I've been testing the ambient light sensor, and it kinda worked in detecting if I had clock on my hand or not, but I wouldn't consider this feature as necessary... Though tomtom I showed in the video nicely detects if its on hand or not

[Riksu9000]

That's interesting. There definitely isn't that big of a difference for me. I wonder why just gain would cause this. The gain is a hardware feature, so it should be better than digitally boosting the signal.

The driver sets some reserved bits in registers PDriver and Res (0x0c and 0x16), so I wonder if they do something unexpected on some units.
https://github.com/JF002/InfiniTime/blob/514481ef7f9c71ad816b31d979c6ab39ce9380dd/src/drivers/Hrs3300.cpp#L22

The 16 bit uint SPL value is converted to float, filtered, and converted to an 8 bit int. Do we know the result always fits in 8 bits? On the video we can see that there is some "calibration" happening, but this might be the filters doing their job. I hope I won't have to be the one to decipher what these numbers mean..

Ppg::Ppg()
  : hpf {0.87033078, -1.74066156, 0.87033078, -1.72377617, 0.75754694},
    agc {20, 0.971, 2},
    lpf {0.11595249, 0.23190498, 0.11595249, -0.72168143, 0.18549138} {
}

The bpm value should be possible to update more often, because currently only a buffer full of new and unused data is ever converted to a bpm. We can refresh it more often if we reuse some of the data. Also if we can detect an error in the measurement, we could force the buffer to be filled with new data before continuing the conversion.

The ambient light sensor should at least be used to turn off the measurement and stop the light from flashing.

Having the graph merged would be useful, but I feel it's too ugly in its current state at least.

[bearclaws8]

I did some testing with the sensor to see how values looked for different parts of my body to see if there were any correlations to getting odd/high values. Now, before you run away after I said "different parts of my body" it was all perfectly benign. I hadn't seen any info like this written here or on the forum so it may help with debugging. Here is what I noticed, and some thoughts:

• Top of wrist, w/ hair, dry: erratic and frequently over 100 /under 50
• Bottom of wrist, no hair, dry: stable and very close to actual
• Palm/thumb, no hair, dry: stable and very close to actual
• Ankle, no hair, dry: stable and close to actual
• Top of wrist, w/ hair, wet: stable and close to actual
• Other areas, no hair, wet: stable and close to actual

All of these were with the watch lose on my skin, like wearing the band comfortably. When wet it was after swimming in the pool, shower, and/or a work out. The more water retained between the sensor and skin the better.

So based on this, I think hair is part of the big problem. This isn't a new problem for these types of sensors and assume a few of you may already know this. Even light/fair hair for women or children seems to throw the sensor off. I guess that the light may be bouncing off of the hair and picked up as extra hits/noise in the sensor. This may be obvious to some but if this is a common cause of the issue then it may help with finding a solution for signal processing. I do not have a background in signal processing but it reminds me of doing CPK and SPC charts for manufacturing processes, maybe we can implement something like that here? (I would not know where to start in code... yet)

The current gain control seems to be reasonably accurate without hair in the way. At this time, if I want to use the HR sensor I simply roll the watch to the underside of my wrist and the values are accurate enough and stable. Maybe we put a band-aid in place for now with an animation suggesting the user to roll the watch to their forearm until a better signal processing is place (this is the "easy" solution a mechanical person comes up with☺️).

I did like the animation that @Riksu9000 showed in the top post. It was cool in my opinion and helped show that the monitor was actually doing something. I'm not sure if it was actually following the data, but something like that would be neat. Jut my $0.02.

[Avamander]

@bearclaws8 this PR will probably improve things for some people: #531

[Riksu9000]

The current gain control seems to be reasonably accurate without hair in the way. At this time, if I want to use the HR sensor I simply roll the watch to the underside of my wrist and the values are accurate enough and stable. Maybe we put a band-aid in place for now with an animation suggesting the user to roll the watch to their forearm until a better signal processing is place (this is the "easy" solution a mechanical person comes up withrelaxed).

This sounds a bit silly, but honestly I kind of like this idea. This won't work for everyone though because I think some people want to leave it running and not just take a measurement sometimes.

The animation shows real data after preprocessing.

[DoctorAllcome]

Would it help if you had data like comparing heartbeat of PT and other devices (e.g. other wearables, consumer and professional blood pressure meters), taken simultaneously?

And if yes what could be a good schema? If I would make a file with BPM measured by PT in the first column and BPM measured by a comparing device in a second column would that be fine?
Could be enriched with information like the PT software version, the model of the comparing device, daytime, body activity (e.g. during sport, after sport, during rest, with fever). Of course all the later things optional so that people could spend only data they are comfortable with (e.n. with respect to privacy).

And how could we practically take the actual measurements of a value that is dynamic while maintaining consistency? How can we capture the values of two devices while correctly associate them with each other. For example writing down a value measured by PT and writing down the corresponding value of the other device and not an unrelated value 10 seconds later.

[bearclaws8]

This sounds a bit silly, but honestly I kind of like this idea. This won't work for everyone though because I think some people want to leave it running and not just take a measurement sometimes.

@Riksu9000 I am full of silly ideas, glad you like it.

The animation shows real data after preprocessing.

Thanks for the clarification. I wonder if it is smoothing the peaks a bit too much, which can make it seem "fake". I don't know enough coding to know how to stop it from smoothing the peaks but my gut tells me that may be the vidual disconnect.

[Riksu9000]

Would it help if you had data like comparing heartbeat of PT and other devices (e.g. other wearables, consumer and professional blood pressure meters), taken simultaneously?

I'm not sure if it would help with this. From the graph we can see that when it is working correctly, the signal is quite clean after preprocessing and measuring the bpm is basically just counting the peaks. What would help is if the watch could detect when an error happens during measurement.

[bearclaws8]

Does anyone have some sample raw data that could be shared? I am not sure how to pull such data from my PT, and even less sure how to tweak code to help. But I could try fumbling about in processing data to see if an equation or logic can be identified to help flag when deviating.

[hatmajster]

So I just shaved my wrist (its completely unnoticable with the watch) and well, for me it didn't help. I am a total ignorant in biology, but I think bottom of the wrist or finger are just are much closer to veins, than the top of the wrist - hence better measurements. But still maybe if someone wants to have correct measurements, its just the best approach to measure closer to the veins - bottom wrist. Its pretty simple and clever @bearclaws8 ;)

This might interest You: I am doing my own testing utilizing FitoTrack, but my old phone keeps betraying me when I run, loses GPS and breaks the whole training data, so I don't have much to show yet - I just noticed for now that 8x gain seems to be better than 4x gain while running. Also, maybe related to blood pressure, but it seems like I can't get the watch too tight while running - the measurements are always quite okay. But can't back it up with any data yet.

FitoTrack naturally shows parsed, not raw data (and I suspect it even tries to fix stuff itself a little). But here's what You can do to get raw measurements - using #560 You can log all readings in real time, or store them in file and later print with console. I want to do it myself, but currently don't have time...

[bearclaws8]

So I just shaved my wrist

@hatmajster that is some serious dedication to a project! And thank you for the suggestion for pulling raw data. I too will have to find the time to learn how to use this and then actually use it

[danielbarry]

I'm also seeing issues with the readings, specifically when my heart rate is greatly increased. Currently it appears as though when the measurement is above ~160 BPM it caps out and goes back down ~50/60 BPM, which is literally impossible whilst running.

Lower heart rate values appear to work much better. I am happy to share data if somebody can tell me how to record it.

Has anybody been able to test this against a known good device, like a Garmin watch?