@DonTomGot
Do not know if this helps. But some suggestions from my side.
Heap memory is tight on the watch and effectively unlimited in the simulator. I bumped into this several times. Two fixes I used:
Use Uint8Array for HR data - up to 4000 samples seems to be OK
Do not declare “scratch” variables in callbacks, make them global
Yes, you will need to protect against undefined and null data, but I have only encountered this when starting an exercise. I think the problem you are seeing is probably memory related.
Here are some things you could look for in the System Event Log from the watch.
Log line
Meaning
ERR UI_FRAMEWORK : JS:0x...SyntaxError
JS syntax error in a template
ERR APPLICATION : Zapp:relMemCb (exec:ui)
Memory pressure — release requested
ERR APPLICATION : Zapp:RelMem→None avail
Heap fully exhausted
ERR DUKTAPE : JSalloc:16
JS engine can’t allocate — out of memory
ERR WBMAIN
Background worker error (often follows heap exhaustion)
Second topic: when working on my AerobicGuide I was looking for the opposite type of algorithm, preserving spikes. I think the basic idea is to try to establish a slower-moving baseline and then look at rapid deviations from that. You can probably find something in Python that you can play with. Then it becomes a question of picking a simple enough algorithm that it can be implemented on the watch.