Hmm - that's interesting then - so it looks like maybe you have a similar issue to @fanoush with the HRM differences. @fanoush yours is one of the earlier watches too? eg not with the VC31B
I wonder whether maybe for some reason we're getting duplicate readings - maybe the VC31 code still forwards HRM data when there is nothing. @fanoush if you look at HRM-raw can you see duplicate entries?
I just tried with an original bangle here:
var last = {};
function r(h) {
print(h.vcPPG==last.vcPPG, h.vcPPG);
last = h;
}
Bangle.on('HRM-raw',r);
Bangle.setHRMPower(1);
And I see it returning false reliably - but if it was reporting true 1 in 10 times then I guess we might expect that would be causing a lower HRM to be reported?
But even so I don't really see it. hrm_new gets called whenever there is a new bit if data, and it keeps track of the amount of time that has passed between each call and feeds it directly into the algorithm. It feels like the only way it could be 10% off is if the clock was running 10% fast!
for me there is true but very rarely. in 10 out of 2749 samples.
mine is possibly one of the earliest ones, the one you sent me when figuring out the HW pinout
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Hmm - that's interesting then - so it looks like maybe you have a similar issue to @fanoush with the HRM differences. @fanoush yours is one of the earlier watches too? eg not with the VC31B
I wonder whether maybe for some reason we're getting duplicate readings - maybe the VC31 code still forwards HRM data when there is nothing. @fanoush if you look at HRM-raw can you see duplicate entries?
I just tried with an original bangle here:
And I see it returning false reliably - but if it was reporting true 1 in 10 times then I guess we might expect that would be causing a lower HRM to be reported?
But even so I don't really see it.
hrm_new
gets called whenever there is a new bit if data, and it keeps track of the amount of time that has passed between each call and feeds it directly into the algorithm. It feels like the only way it could be 10% off is if the clock was running 10% fast!