High heart rate values
#1
Hi,

I recently bought a 3 pack pinetimes and flashed one of them with infinitime 1.0 RC 4 and another with 1.0. Now, both heart rate sensors show really high values for my heart rate going up to 200 and more, but mostly being around 120-140. When I sensed my heart rate manually I counted between 60-70 bpm.
I am wearing them normal, not too tight, not too loose. I also tried different positions or to press them stronger to my skin, without any effect.
I don't know. Am I missing something? Is anybody else experiencing high heart rate values?

Cheers
Andy
  Reply
#2
The first reading is usually high for me too, but the second reading (without turning off the display) tends to be better. I'm very sure there is some issue in the firmware regarding value reading.

You should add a bug report: https://github.com/JF002/InfiniTime/issues

It also takes *forever* for the first value to come through - it should be able to begin estimating with less data, even if the accuracy isn't there. I would personally expect the heart rate value to update every few seconds based on a moving average.
  Reply
#3
Are you able to try (temporarily) switching to wasp-os and looking at the graphs in the heart rate app?

[Image: HeartApp.png]

Infinitime and wasp-os use the same (relatively simple) algorithm but wasp-os will visualize the (cleaned up) data as it is captured. This would offer you some clues about what is going on. It certainly helps uses see when the sensor is doing it's thing properly.

This video is slightly out-of-date, you now have to upgrade infinitime after restoring the original bootloader, but if you want to see how to get the graph from wasp-os (and how to get back again) then take a look at:
[Image: 0.jpg]

PS I really must get round to adding an (optional) raw heart rate sensor capture tool to wasp-os so we can capture data from a wide range of users. The current algorithm was developed and tested against 100 separate captures but all data originates from exactly one test subject (me). If people are getting round to hammering on this stuff now then being able to capture a large range of samples to work on would be very helpful.
PineTime: wasp-os and MicroPython, Pinebook Pro:  Debian Bullseye
  Reply
#4
I flashed wasp-os to see if my heart gets more relaxed, but I found it still running. I have been looking now for more than 10 minutes on the graph and values are still high. I had quite a period (maybe 30s) with heart rates around 57, but then they went up again and are above 100 usually. I also found 'None bpm' values.
The graph also doesn't make a lot of sense to me, I don't see how the value shown and the graph are connected. It is not even clear to me what is shown on the y-axis of the graph. Sometimes I have similar looking consecutive graphs, but the values differ a lot (85 and 176).
Now, if I knew how to capture data I could do that and send it to you if that helps. I could also record a video of the graph, maybe it makes more sense to you.
  Reply
#5
What you see in the graph in wasp-os is pretty much what comes of the sensor. There is a little basic signal processing applied (DC removal, high frequency removal and automatic gain control) but what you see is basically the data the heart rate algorithm has to interpret to determine the heart rate.

The graph *should* show a strong periodic signal with the peaks occurring roughly half a beat *after* you feel your pulse in your neck (or if you prefer the troughs are aligned with the pulse in your neck). Occasionally there is a bit of noise so there are two peaks in close succession but algorithm will ignore these. You can see a live recording of the graph filling in this video which might offer some idea of what to expect. The samples in the video shows more noise than the screenshot about, especially in the first 10 seconds:
[Image: 0.jpg]

One thing that is very important with optical wrist based sensors is not to apply any pressure at all when measuring. The sensor should work fine with a loose strap and even gives good readings when unstrapped and just resting on the wrist. This is because the sensor measures changes in blood diffusion near the surface of the skin and if you apply pressure to the sensor then you are basically squashing most of the "spare" blood away leaving nothing to measure!

A video might be useful and the captured data certainly would be! I'll look into adding support for that in the self test program when I get a chance (although it might be fiddly to get the data out since you'd need a GNU/Linux system with working bluetooth low energy to do that).
PineTime: wasp-os and MicroPython, Pinebook Pro:  Debian Bullseye
  Reply
#6
(04-28-2021, 04:06 AM)danielt Wrote: PS I really must get round to adding an (optional) raw heart rate sensor capture tool to wasp-os so we can capture data from a wide range of users. The current algorithm was developed and tested against 100 separate captures but all data originates from exactly one test subject (me). If people are getting round to hammering on this stuff now then being able to capture a large range of samples to work on would be very helpful.

So I've made the changes to wasp-os to allow it to record the data from the sensor so we can try and figure out what is happening.

Implementation is here, CI binaries are here and documentation is here.
PineTime: wasp-os and MicroPython, Pinebook Pro:  Debian Bullseye
  Reply
#7
(05-07-2021, 02:15 AM)danielt Wrote:
(04-28-2021, 04:06 AM)danielt Wrote: PS I really must get round to adding an (optional) raw heart rate sensor capture tool to wasp-os so we can capture data from a wide range of users. The current algorithm was developed and tested against 100 separate captures but all data originates from exactly one test subject (me). If people are getting round to hammering on this stuff now then being able to capture a large range of samples to work on would be very helpful.

So I've made the changes to wasp-os to allow it to record the data from the sensor so we can try and figure out what is happening.

Implementation is here, CI binaries are here and documentation is here.

Great, this looks like an adventure, and I love adventures. Lets see how far I get :D

In case of success, how long should the log be?
  Reply
#8
(05-11-2021, 06:11 AM)Andy--- Wrote: Great, this looks like an adventure, and I love adventures. Lets see how far I get Big Grin

In case of success, how long should the log be?

Good question!

It is a binary file that grows by roughly 500 bytes for every ten seconds the HR monitor program is running (it stores the data every time the BPM field at the top is updated).

It is just a collection of records delimited by header so if you pass the file through a hexdump you should see the header:

0xffff:
YYYY (year, 16-bit)
MMMM (month, 16-bit)
DDDD (day, 16-bit)
hhhh (hour, 16-bit)
mmmm (minute, 16-bit)
ssss (seconds, 16-bit)

Note the header was constructed for convenience of writing rather then efficient packing. Also all those zeros make it easy to resync on the data if we get lost processing it. Anyhow after each header is 480 bytes of raw data (e.g. 240 16-bit samples exactly as they are read from the sensor) except for the first set of samples which could be any length from 1 to 240.

Note that it is impossible to read 0xffff from the sensor so you can just read the raw HR data until you get 0xffff and you will know you just found a new header.
PineTime: wasp-os and MicroPython, Pinebook Pro:  Debian Bullseye
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)