see http://forum.espruino.com/conversations/373033 for a discussion on the problem. You can use
Bangle.on('HRM-raw', (hrm) => {...});
to get the raw sensor value. So no need to modify the firmware for experimentation. In the long run implementing the algorithm in the firmware in C might be more efficient...
Current implementation is https://github.com/espruino/Espruino/blob/master/libs/misc/heartrate.c

A paper that might get you started could be Pollreisz, D., TaheriNejad, N. Detection and Removal of Motion Artifacts in PPG Signals. Mobile Netw Appl (2019).

Hi - thanks - as mentioned there are some attempts to improve this (above).

One issue you may be hitting is that the initial filter is designed for 50Hz but the default Bangle.js 2 sample rate is 25Hz, so it'll be filtering out the wrong frequencies - so a quick fix is just to raise the sample rate to 50Hz with http://www.espruino.com/Reference#l_Bangle_setOptions and that may help you somewhat.

But what we really need is some recorded data, and then hopefully we can start to make some more scientific improvements

Hi, thanks for your help. I am however not sure what to do. When I connect to my bangle.js v2 with the web ide, and run Bangle.getOptions(), I see hrmPollInterval: 20 - I guess these are miliseconds, so it means it already uses 50 Hz sample rate. Am I wrong?

Looks like the interval was reduces from 50Hz to 25Hz quite recently. hrmPollInterval on mine says 40.

@Yenya What firmware version are you running?

Looks like the interval was reduces from 50Hz to 25Hz quite recently

The reported interval was, and on Bangle.js 2 kickstarter version it was dropped. All Bangles since the KickStarter have been 25Hz though.

@Yenya What firmware version are you running?

This - older firmwares reported the poll rate wrong (and also didn't allow changing it). You'd actually need to be on a 'cutting edge' build to be able to change the poll rate.

It says "2v13". When I click to "Firmware update" at banglejs.com/apps, it says "Your current firmware is 2v13 and bootloader is unknown (CRC 4056371285)".

I flashed a newer firmware 2v13.136. After reboot, the hrmPollInterval value is 40. I tried to set it to 20 - now I see 40 to 60 bpm with Confidence around 60-70 % (there is no way for me to have 40 bpm heart rate).

What debugging data should I provide? I can for example record the heart rate with Garmin Vivoactive together with Bangle.js v2. What is the best way to record the raw data? And how much data do you need? (sorry, I am pretty new to this :-).

Please follow the discussion in the forum: http://forum.espruino.com/conversations/372681/?offset=50 there is a hrmaccevents app in the apploader.

I tried to set it to 20 - now I see 40 to 60 bpm with Confidence around 60-70 % (there is no way for me to have 40 bpm heart rate)

What was the heart rate you got reported before you changed the option? Is it the same?

You have to have set hrmPollInterval before the HRM is turned on - not sure if that helps at all?

What debugging data should I provide?

As @nxdefiant says. However...

I was kind of hoping one of the people on the forum would set something up, but it looks like it's not the case. I've just got back from a week off and I'm still working through emails, but I'll try and set up a test harness in a similar way to what I've done for the step counter, hopefully today.

But to really help, ideally we need an external bluetooth heart rate monitor as well - then we have some proper data to compare to

OK, let's move to the forum.

However, in order to not leave the above questions unanswered:

You are right, I had HRM turned on all the time. When I turned it off, and only then set hrmPollInterval to 20, it now shows higher values than before. Yesterday I recorded two hours worth of data (of which the middle 1:20h is me cycling). Looking at the values, I think the highest values from any 10 or 20 surrounding ones show real data. I expect to have about 70 bpm when idle, 140-175 during the cycling workout, then quickly return to about 90-100 bpm, and then slowly decrease to the idle value.
recorder9.csv

Test harness now at https://github.com/gfwilliams/EspruinoHRMTestHarness

More info in http://forum.espruino.com/conversations/373033/#comment16554946

Is there a way that I might be able to help here? I am in the process of ordering a Polar H10 to get something resembling ground truth. I would love to contribute to this awesome project if I can.

@luc-spec I think one thing is to contribute more data into the "data" folder on the test harness repo @gfwilliams linked to above. I meant to do that as well but haven't yet...

Edit: You can read threads on hrm on the forum, e.g. https://forum.espruino.com/comments/16454552/

Edit2: Also this thread: https://forum.espruino.com/conversations/385922/

I should add that since this the last post on this bug report I've completely changed the HRM algorithm to a binary blob one supplied by the manufacturer of the sensor, which is significantly better. That happened in 2v18/Mar 2023 or before.

So personally I'd think maybe this issue could be closed...

Obviously more data for comparison is good (someone thought their sensor was always 10% on their watch but I wasn't able to verify that here), but we're not using the algorithm from https://github.com/gfwilliams/EspruinoHRMTestHarness now unless someone explicitly enables it in their build, and I think to switch back to that from the binary blob, the algorithm would need totally rewriting.