Bangle.js 2 Cutting Edge - new heart rate algorithm

Ahh ok, so it may well be an issue with the algorithm expecting almost identical time differences - in their example the HRM is calibrated to give readings at the right rate, not the other way around.

Looking at you file there is some variation - but worryingly I actually see some much bigger gaps every so often - like one sample is being missed which I guess is just due to a difference in frequency between the HRM and the bangle:

0.0355224609375 
0.0321044921875 
0.034027099609375 
0.03515625 
0.03411865234375 
0.033935546875 
0.032073974609375 
0.03515625 
0.067596435546875 !!!
0.03399658203125 
0.03216552734375 
0.035400390625 
0.03375244140625 
0.0341796875 
0.0364990234375 
0.030853271484375 
0.0322265625 
0.03387451171875 
0.033721923828125 
0.0340576171875 
0.0335693359375 
0.03656005859375 
0.031097412109375 
0.0340576171875 
0.033966064453125 
0.03350830078125 
0.033721923828125 
0.0340576171875 
0.0335693359375 
0.0340576171875 
0.0335693359375 
0.033935546875 
0.03369140625 
0.069732666015625 !!!
0.031829833984375 
0.03375244140625 
0.03387451171875 
0.03387451171875 
0.033966064453125 
0.037689208984375 
0.029693603515625 
0.035430908203125 
0.0321044921875 

But maybe that one long sample throws the algorithm off (when the original one would cope with it).

You see it is better on newer watches?

Well, when I tested the HRM measurements I got against a Bangle running old firmware, they were almost identical.

Maybe you could try - in heartrate_vc31_binary.c - changing:

Algo_Input(&inputData, timeDiff, hrmInfo.sportMode, 0/*surfaceRecogMode*/,0/*opticalAidMode*/);

to:

if (timeDiff*2 > hrmPollInterval*3){ // > 1.5x
  timeDiff/=2;
  Algo_Input(&inputData, timeDiff, hrmInfo.sportMode, 0/*surfaceRecogMode*/,0/*opticalAidMode*/);
}
Algo_Input(&inputData, timeDiff, hrmInfo.sportMode, 0/*surfaceRecogMode*/,0/*opticalAidMode*/);

So it effectively just splits the double-length gap into 2