Updating Recorder to use average HR instead of last HR

[ruvilonix]

I saw that the Recorder app's heart rate logging saves the last HR sent by the device when it is time to save a new row.

I thought it could be made more robust if it instead kept a running average of all readings sent during a given interval and saved the average instead, so I edited the app to do this. The confidence scores of the readings are also averaged.

It also only incorporates readings that have a confidence score higher than 80. If no readings pass this threshold during the interval, the reading with the highest confidence score is saved instead of an average.

This way, even if the last reading happens to get messed up for some reason and come back with a low confidence score, the app will still log an accurate average based on the rest of the scores logged during the interval, or at least the reading it was most confident about.

Here's the commit: link

Here's a comparison between the old method and the new method for recording HR every 5 seconds, just from a few minutes of moving around:

Not really a dramatic difference in HR values from this small sample - maybe a bit smoother. Either way, I feel more comfortable using an average for this.

[gfwilliams]

Thanks! That looks like a really neat solution. Would you be up for putting in a PR for that (with a Changelog entry and version bump)?

[halemmerich]

bthrm can be configured to fall back to the internal HRM in case of a
dropped connection or otherwise no longer arriving hrm info from the BT
sensor. It can also be configured for parallel use of BT and internal
sensor. In those cases the field should change pretty regularly.
I don't think it would be a relevant loss to no longer have this info
available. I mainly used it a long time ago for comparing different BT
sensors with the internal one while there was some action around the
HRM algorithms.

[ruvilonix]

So it sounds like the two potential scenarios where logging would be innacurate are:

1. HRM switches from internal to BT, or vice versa, and stays switched. There may be one interval during the switch that averages across multiple sources but only labels the CSV row with the last source.
2. Internal sensor and BT send data in parallel. All CSV intervals would show an average across multiple sources, and the last source to send data during each interval would be output as source in the CSV.

For 1, it may indeed give an inaccurate source. But this would only be for one interval at the switch-over point, so may not be a significant concern.

For 2, it seems to me that the Recorder app wouldn't be useful for recording multiple HRM sources in parallel, even as it is written currently. If you have two sources sending data, the app only saves the HR from one source during each interval. And it's effectively random which source it is, based on which one sends data last before a CSV write. So it would drop a lot of data and not really be "parallel".

So I think it would probably be okay to update.

If it was really necessary to make sure source is always correct, it'd be possible with some relatively simple code changes: only readings from whichever source sent data first would be incorporated into the average.

[ruvilonix]

If it was really necessary to make sure source is always correct, it'd be possible with some relatively simple code changes: only readings from whichever source sent data first would be incorporated into the average.

I made another version that does this. Here's the commit with that added: ruvilonix/BangleApps@02e5cb8?w=1

Technically it could be improved further by keeping an average for every different source that sends data during an interval, then only logging the highest confidence source, as opposed to the first source. But I'm not sure it's worth the complexity.

[gfwilliams]

Ok, thanks! Well, to me it sounds like we don't need to worry too much - I probably wouldn't add your code to deal with src as if there were two sources of HRM, likely recorder would then end up randomly selecting one or the other value which would be worse than an average IMO.

I think it would likely make sense if I removed src completely in another commit once yours is merged? As @halemmerich says it was mainly for debugging - I think in normal use it's not really useful and just takes up space and is a bit confusing.

[ruvilonix]

Sounds good. I made a PR.

Only thing I can think of as a plausible use of src here would be if someone wants to know exactly when their BT device disconnected or the battery died and the readings switched to the internal sensor. Not sure how necessary that is though.