adaptive heart rate monitor app

[antimo0f]

No description provided.

[RKBoss6]

This looks really cool! One question - does this modify the existing heart rate function, so if another app calls Bangle.setHRMPower, will it use this, and return the value in firmware-level events, like the health event?

[antimo0f]

This looks really cool! One question - does this modify the existing heart rate function, so if another app calls Bangle.setHRMPower, will it use this, and return the value in firmware-level events, like the health event?

Thank you for your answer, this code does not modify or overwrite the native Bangle.setHRMPower function.
It does not affect the core Espruino functionalities.
The firmware will continue to handle its standard events exactly as it did before. Consequently, the values returned in firmware-level events (like the health event) will not be altered by the script.

I’m very open to receiving other comments or suggestions!
I plan to improve this over time and add new features, including a dedicated UI.

[RKBoss6]

Is it possible to modify the hrm to use this? From what I can tell, this looks like it's another (maybe better) hrm algorithm, so it would make sense to have this modify the existing hrm... but correct me if I'm wrong about anything!

Also, you don't need to add more changelog entries if it's all in the first pr. Since this will be the first pr update on this app, all the changes can be bundled into 0.01 :)

[antimo0f]

Yes! the algorithm surely decides to switch on and off the hrm in a smarter way. I originally designed this app to function primarily as data logger (saving to CSV). The main goal was to move away from fixed-interval measurements and instead use a 'smart' approach—triggering measurements only when it is actually useful to have the heart rate data, i tested it for a long time while i was writing my thesis at university, and it worked !

• I thought it would be better to keep the algorithm logic separate and use the standard APIs, rather than doing a direct override. I want to avoid forcing other apps that rely on the HRM API to adopt my specific sensor switching logic, as that might interfere with their functionality.

• If setHRMPower(0) and setHRMPower(1) are called too frequently from outside, the logic technically still functions, but the timing at which measurements arrive in the data structures (used to decide when to switch the sensor) will no longer match the intended period. This would break expectations for other apps. For example, if an app calls setHRMPower(1), it expects to receive an HR event immediately. However, that event might never arrive because in that case my algorithm has decided to only trigger a measurement every 10 minutes!

The answer is, Yes it is possible to use it to override the original HRM, but after you should consider the differences from the default one. The logic is explained in the Readme file.

Let me know your thoughts on this!

Also, I’ve adjusted the changelogs as requested. I'll bundle all the changes into the initial 0.01 release." ;)

[bobrippling]

Thanks for the app! A few comments