Trailing HR / moving average HR - and a question on eliminating HR spikes

[DonTomGot]

To smoothen HR and minimize fluctuations I have previously used (Ambit2) trailing HR - but it seems it now needs to be calculated. As I had some problems in succeeding with this pretty simple task I thought someone else might benefit from my findings/hypothesis.

Initially I tried this, to achieve a trailing (5s) heartrate:

function evaluate(input, output) {

HRacc5.shift(); //shifts the array one step left

HRacc5[4] = input.HRCurrent; //adds current heart rate to index 4 in array

var calculateAverage = function(arr) {
    var sum = 0;
    for (var i = 0; i < arr.length; i++) {
        sum += arr[i];
    }
    return sum / arr.length;
}

var HRavg5 = calculateAverage(HRacc5);

output.RecalcAvgHR = 60 * HRavg5;

Which worked well in the simulator. But IRL it did not work at all. The watch froze after a couple of minutes in all workouts and it became quite frustrating since troubleshooting on watch seemed advanced - and I am not advanced.

As the watch seemed to freeze at very random points - sometimes 20 mins into a workout - I came to the conclusion that perhaps the input causes friction, as it works in the simulator? the hypothesis is now that unregistered heartbeat returns ‘undefined’ so next attempt was the inclusion of:

HRacc5 = HRacc5.filter(Number);

Supposedly filtering out everything that is not recognized as numbers.

Now the app worked!

(writing this primarily to avoid repeating the same frustrating workouts again, and potentially help others with similar ideas)

Second topic: Sometimes (often when tired/poor sleep quality/hung over) I get heart rate spikes that I would like to eliminate. I would imagine that they can be identified as rapid elevations in heart rate where also the trailing heart rate can be a good baseline. But how could an algorithm be designed to eliminate these spikes with minimum disturbance to the trailing HR? All input most welcome!

[matram]

@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.