Heart rate too low

The app loader does seem to be better about downloading big files - it wouldn't take long to make a 'interface.html' file for hrmaccevents pull back the files i guess as it's just a call to Utils.readStorageFile

I took a look at this and I have to give up now because I'm out of ideas. A few papers have code online, e.g. WPFV [2]. I tried them on data collected on my Bangle JS2, but they all failed to recover the exact heart rate, or even a value close to it.

The following picture shows the frequencies in BPM of a random 8 second sample of motion artifacts in a PPG signal from the IEEE Signal Processing Cup 2015 [1], dataset 1, downsampled to 25Hz:

We can simply see that the first and second dominant PPG peeks (blue) at about 90 BPM and 176 BPM are caused by motion because we can identify the spikes from the acceleration sensor at the same frequency. That leaves the third spike at 165 BPM as the real BPM which closely matches the ground truth at 163 BPM.

Lets now look at the data I have recorded from my Bangle JS2:

We can see the motion introduced spike on 70BPM. The problem is that at the real heart rate at about 110BPM we do not see any value. Second highest peak is at 123 BPM which is also overlapped by x acceleration.

I think we now get an idea why the algorithms fail. Now lets take a look at the raw signal. First ieee:

Now Bangle Js2, raw signal in blue, FIR filtered in red, both zero averaged:

Even at the no-motion-phase at the beginning the signal appears more noisy compared to the more clean one from the ieee dataset. I'm not a signal processing or PPG sensor export, but at this point I assume the Bangle JS ppg sensor is not of high enough quality.

The BangleJS2 data has been recorded with acc rate=25Hz, hrm rate=50Hz, both sampled at 25Hz. See the attached recordppg.js. Though the sampling rate is not exact (more ~23Hz on mine)

[1] https://signalprocessingsociety.org/comm­unity-involvement/ieee-signal-processing­-cup-2015
[2] https://github.com/andtem2000/PPG

1 Attachment

• recordppg.js

Well I said I give up, but well..

As said I checked some algorithms that do remove motion artifacts from PPG with acceleration data and they all failed. I tried to analyze why the fail and, as result, developed a very simple mechanism: Lets just take the fft of both PPG and ACC and remove the frequencies from the PPG spectrum that have noise in ACC spectrum.

• It will not have a high resolution.
  
• It will most certainly fail if heart rate frequency is close to the acceleration noise frequency.
  
• Mean error will not get closer to the real heart rate then 5-10BPM.
  
  

So my algorithm does not always get closer to the truth but it sometimes can, see the attachment. BPM of firmware in red, real BPM from belt sensor in green, calculated BPM in blue. X-Axis is time, Y-Axis BPM.

1 Attachment

Recommended reading list aka the better ones (unsorted):

• Heart rate tracking in photoplethysmography signals affected by motion artifacts: a review
  
• The quest for raw signals: a quality review of publicly available photoplethysmography datasets
  
• Optimal Preprocessing of Raw Signals from Reflective Mode Photoplethysmography in Wearable Devices
  
• An efficient method for heart rate monitoring using wrist-type photoplethysmographic signals during intensive physical exercise
  
• A Robust Heart Rate Monitoring Scheme Using Photoplethysmographic Signals Corrupted by Intense Motion Artifacts
  
• Accurate Heart Rate Monitoring During Physical Exercises Using PPG (Temko/WFPV)
  
  
• Robust PPG-based Ambulatory Heart Rate Tracking Algorithm Tapir
  
• Photoplethysmography-Based Biomedical Signal Processing (Schäck
  )
  

It looks like it kind of stabilize around the ground truth from the middle point onward, with some oscillation. Is that only a coincident with these particular data or generally the case?

Well done in any case!

This oscillation is visible in all datasets I have tried.

1 Attachment

Thanks a lot @user140377.
Have made links to your analysis and literature from my summary.
http://forum.espruino.com/conversations/­­372681/?offset=50#16454552

Looks like I posted to the wrong thread. Lets continue the discussion in the other one.
http://forum.espruino.com/conversations/­372681/

Since the "Heart Rate Monitor"-application shall not be changed, I'll clone it. Any suggestions for a name? If not I'll default to "Heart Rate Monitor 2".

Heart Rate Monitor (movement compensated) or something like that ?

Thats pretty long. Also movement compensation needs to be enabled in settings first.

Well, to make things simple we could just make it do movement compensation by default.

Maybe Advanced Heart Rate Monitor / Advanced HRM

"Adavanced" might raise the expectations to much (If I had a advertising department they would kill me).

But reading "advanced" there is another word in the english language in my mind: "alternate", in short "alt. HRM" or "HRM alt"

That's fine. Really we just need a way to point out that it's doing something extra behind the scenes

For me, the heart rate is way off even at rest (measured 40~60 BPM while the real BPM is ~90 as measured by a pulse oximeter). Changing the poll interval to 20ms helps greatly, the result is nearly identical with the pulse oximeter at rest.

Could we maybe change the default poll interval to 20ms? What are the tradeoffs of doing that?

That's interesting - really the trade-off is power consumption. I just checked and it's 1mA when on at the default period, and 1.6mA at 20ms.

You could always just use the Custom Boot Code app, paste Bangle.setOptions({hrmPollInterval:20}) into it and that would fix it for you.

In theory at 90 BPM there shouldn't really be a big problem with the default 25Hz poll interval - if you're running the HRM app can you still see a pretty clear pulse with it?

It's possible that the filter used for the algorithm is filtering out too much high frequency