Posted at 2022-02-05 by HughB

Excuse me asking what is PPG?

Posted at 2022-02-05 by myownself

Photoplethysmography. It is the principle behind the heart rate monitor on most smart watches. Heart rate itself is just the tip of the iceberg, but heart rate during exercise is probably the top of the list.

Posted at 2022-02-05 by HughB

Ok - so this thread is for fixing the HRM on Bangle 2.
I'd be happy to do some tests but dont want to get sucked into doing R&D for it.
In fact I just went out on a 4 mile walk with the Run and recorder on.

I also wore my amazfit bip on the same wrist and could clearly see when the Bangle HRM was struggling. Its all down to speed of movement. Unfortunately after about 1h20 the watches clashed together and a long button press occurred on the Amizfit and stopped the activity. The Amizfit frooze and actually crashed (first time I have seen it do that) and the log was lost. Just about to see what I can pull off from the Recorder App.

Posted at 2022-02-05 by myownself

Yes, that is exactly what it is about, and eventually more.

I am not sure that I am even getting a reasonable heart rate when staying still at the moment, but I need to get something to compare to.

Posted at 2022-02-05 by Mi

I was in the mountains today (therfore myownself was faster answering you @hughb for the PPG) and for some time did record bangle HR/Confidence and H10 reference simultaniously. Will do a statistic later this evening to compare were we are when it comes to walking on rough terrain.
(we do not yet have the ability to record the raw PPG data on the go though, but halemmerichs hrmaccevents is a great starting point for quick experiments with raw input, bt hrm gold standard and acc to compensate for motion)

Posted at 2022-02-05 by HughB

I'm using 2v12.0 firmware and my feel of the heart rate is that it is beleivable up to about 2mph. After that it quickly goes off piste. But I did see my heart rate at 145 bpm when I was moving at 3mph. My perception is that is slighly improved by definitely not good enough for running yet.

Glad you guys are working on this. I wish you every success. Happy to do some test runs of new versions of stuff. I have an AmizFit Bip, Fitbit HR and Amizfit GTS2 if you want me to compare against.

Posted at 2022-02-05 by myownself

Oh I hadn't seen that. @halemmerich seems like you should be in this thread.

Posted at 2022-02-06 by myownself

@mi (trying to keep the HRM chat in one place, although follows on from the run app thread): is it easy to extract data from the H10? Would I be able to use it to record data and then extract it to a Linux computer easily enough, or do I need to connect it to something to live transfer it?

Posted at 2022-02-06 by Mi

Did a first statistic of current state HR when moving but not heavily (walking and in car as a passanger). By mistake posted this in other thread:
http://forum.espruino.com/comments/16387601/
In essence: pretty good when confidence >90 which was the case in a little bit over 10% of the readings. For other times the standard deviation gets much higher but when averaging the values are not totally off for more than half the time.

Posted at 2022-02-06 by myownself

Article I linked from other thread: https://asp-eurasipjournals.springeropen.com/articles/10.1186/s13634-020-00714-2

Here is another good overview article: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6426305/

Posted at 2022-02-06 by Mi

yes, recognized my error - before seeing your remark and question

is it easy to extract data from the H10? Would I be able to use it to record data and then extract it to a Linux computer easily enough

Its very easy. Heaving installed the BT HRM App it does write both internally measured and bluetooth measured values in the csv of recorder app. I just read in this csv with pandas in a jupyter notebook on linux and could do statistics easily.
If you are interested I can post this nb or see if I can check in somewhere

UPDATE: File is actually not that big, so just added it here

Attachments:

• Bangle HR statistics.ipynb

Posted at 2022-02-06 by myownself

Excellent. Thanks. That was (besides price) one of the things giving me qualms.
I'll think about it further before getting one, maybe there are enough people who can provide data already and the last 2 weeks I have been too busy with work (and now being ill) to spend the time I want with the Bangle. Hopefully that is going to improve soon.

Posted at 2022-02-06 by Mi

What the polar does not have as an ECG device is SpO2 obviosly (don't see that for their opticals either though).
I do have a pollux 400 here, which can measure and record SpO2, but this has no bluetooth so sync will be more effort.

Posted at 2022-02-06 by Mi

@hughb: Some even easier plots, clearly showing the effectiveness of Confidence:
(ideally all dots should be on the diagonal. Be careful: I didn't manage to have the axis the same)
Now the task is "just" to get more dots with high confidence :-)

Attachments:

• Scatter_HRvsHR.png

Posted at 2022-02-06 by myownself

Ah, I will have a think, perhaps getting something for that makes more sense.

I have access to a Blood Pressure cuff when we have got the basics sorted. I don't know of any devices that claim to do BP without requiring calibration, nor in motion, so lack of Bluetooth isn't a big deal there.

Posted at 2022-02-06 by myownself

I've done a few old fashioned tests (watch and finger on pulse) and have confirmed pretty much what I suspected. Even staying still, the Bangle is missing every second beat. It reports pretty much exactly half my actual heart rate, sometimes claiming 100% confidence.

Posted at 2022-02-06 by Mi

What firmware are you using? Make sure to have the newset.
I had the same behaviour, but I don't see that halve values anymore with current firmware 2v12.
(probably that change I guess: espruino/Espruino@407dd17)

Posted at 2022-02-06 by myownself

I am on 2.12.

Posted at 2022-02-06 by Mi

Got an overview of the current HR algorithm at https://github.com/espruino/Espruino/blob/407dd17e0903840df724ebf25f83d2bb95863fb5/libs/misc/heartrate.c
Basically a FIR filter emphasizing 0.9 Hz - 3 Hz with step recognition via demanding two upward steps after having been below moving average. [Idea that comes into mind is to demand upward steps to be above moving average? Will try]:
Then a median filter from the last 8 peaks. Confidence is out of the spread of those 8 values.

I struggled a bit with line 268. Seems to introduce a factor of 175/16=10.9.
Probably to bring result in good range for integer arithmetic?

And here is where the raw values come from.: https://github.com/espruino/Espruino/blob/407dd17e0903840df724ebf25f83d2bb95863fb5/libs/misc/hrm_vc31.c Need to understand what was done to the signal already and what options the hardware brings.

Posted at 2022-02-06 by Fteacher

I'm happy to contribute with running data. I have an arm bthrm. For those like me who'd like to contribute can you specify which settings are ideal to get consistent data to help ?
How do you want the watch to be worn ? Like tight, slightly loose, like everyday ?
Which settings in bthrm and apps ? Which file do you then want: csv, gpx, kml, all of them ?
Something else ? Like informations on the kind of surface ?

Posted at 2022-02-06 by myownself

I would say wear it as you usually do, unless you usually wear it very loose so that it slides around your wrist. I know that for some (probably cheaper) watches people do say they need to wear them very tight, but that isn't what we should be aiming for I don't think.

I will let someone who has more experience with the actual monitors answer about the format, but I suspect CSV is going to be fine.

Information that will be helpful: which Bangle (the hardware in the kickstarter and non-kickstarter bangle 2 is slightly different), which reference device. What activity and terrain etc. might be useful but not as useful as the reference data itself.

Posted at 2022-02-07 by Fteacher

Ok, thanks @MyOwnSelf !

• What about the settings in the recorder app ? I log gps every 5 seconds, more, less ? I suppose I log hr, bthr and steps, something else ?
• in the bthr app, I use the settings:
  Use BT HRM: ON
  Replace HRM:off
  Is that fine ? I suppose other settings don't matter.

Posted at 2022-02-07 by myownself

What we need ideally is the raw hrm signal, the accelerometer, and the values from your other hrm. I don't think we have the means to get all of this yet. I'd hold off doing any recordings at the moment. What do you say @mi?

Posted at 2022-02-07 by Mi

Thank a lot Fteachter for the offer - we will come back to it.
But as @MyOwnSelf said, and I wrote in the Run app thread some days ago, we are not yet ready for that. We first need to make the software and testsuite running. To see if that works some of my own recordings are sufficient. We come back to you as soon as data is the bottleneck - and then with precise format wishes since homogenity then saves effort for us.

Posted at 2022-02-07 by @gfwilliams

@mi I'm really heartened to see your Confidence>90 graph. I know right now we struggle with movement but it's a big help having something that knows when it's accurate :)

What we need ideally is the raw hrm signal, the accelerometer, and the values from your other hrm

Yes - and ideally use an ECG one for the second HRM. I have something that straps on my chest which I think would give much more sensible figures during exercise.

A test harness along the lines of https://github.com/gfwilliams/step-count would be perfect - and then we can build up some data and make some properly educated tweaks to the algorithm

Posted at 2022-02-07 by Mi

@gfwilliams, happy you like it. And what you say is exactly the path forward I am planning.

but it's a big help having something that knows when it's accurate

Totally agree. Any sensor that is not totally random is useful as long as there is a good sensor model. An almost perfect sensor can be usless for critical applications if the "almost" can not be known.

Yes - and ideally use an ECG one for the second HRM

I have a polar H10 here and I am already looking into getting the ECG data as gold standad:
https://towardsdatascience.com/creating-a-data-stream-with-polar-device-a5c93c9ccc59

A test harness along the lines of ...

Yes exactly. ( I have a sensor data fusion and ML background. so that is totally natural to me)
I did look at step-count already and have it running here.

But please don't hold your breath. Time is a little bit of a problem.

Posted at 2022-02-07 by Mi

And a quistion for @gfwilliams or anybody more familiar with the bandwith restrictions on bangle:
As the recorder is intended to be the central instance for recording, would it be possible to include raw ppg and acc here?
Since that would be only for collection test data battery shouldn't be a concern, but is possible from a bandwith standpoint?

Posted at 2022-02-07 by @gfwilliams

recorder ... would it be possible to include raw ppg and acc here?

Kind of, but that's not really how Recorder is designed. It writes an update of the state of all data every set amount of time, but realistically for developing an algorithm you want something that writes the exact data received (no more, no less).

I believe HRM Accelerometer event recorder already does this? However if your question is 'could we write all the data to a file on the Bangle so you don't need a PC/Phone within range' then yes, we could possibly do that. I think the reason it wasn't done is the file gets big and then you have to wait to download it between data collections. Normally it's not a hugely big deal to just have a phone on, even during a run.

Posted at 2022-02-07 by Mi

ah ok. Makes sense.
Actually had used HRM Accelerometer event recorder only with desktop so far. Didn't even come to my mind to just use it on the phone. Thanks
(And yes you are right, for development we do want to have the complete stream).

Posted at 2022-02-07 by Mi

and to add: in fact I do have two very big files already on bangle that web IDE cant get (timeout). So totally see your point.
Is there another way to download without too much effort (which would not be worth it)

Posted at 2022-02-07 by @halemmerich

The event recorder takes every event it gets and write one line in the .csv for it. I tried writing to a local file, but 1 minute of recording was about 200k, so tethering to the browser on PC/Phone is probably better. The code is still in there to write into a file, you could try it out by changing line 18 in custom.html to var method=2;.

Posted at 2022-02-07 by @halemmerich

If the ECG data can be obtained as a BT characteristic, it is probably enough to change the supportedCharacteristicsand supportedServicesobjects to add support to BTHRM. The handler function in the characteristic needs to parse the BT data and emit an event. Alternatively you can just store data in a variable and piggyback onto the BTHRM to send it. I do that with battery and location data which are from different characteristics and cached in lastReceivedData.

Posted at 2022-02-08 by Mi

Thanks a lot for those hints. Will try this evening.
I am totally new to bluetooth, but looking into the python code linked above looks like its a BT characteristic that I can copy over.
So far had some problems getting the python code to run, but could fix that now. So I have something running from which I can learn and copy.

Posted at 2022-02-08 by Mi

@gfwilliams: you showed some images for PPG signals (also with beat marks) here http://forum.espruino.com/comments/16384408/
Is this visualization reusable. Can you point us to some code?

Posted at 2022-02-08 by @gfwilliams

The code I used for that is:

var M = g.getWidth()/2;

var yr,yg,yc,yd;
var hrm;
var n = 0;
var sps = 0;
Bangle.on("HRM-raw",h => {
  hrm = h;
  sps++;
  /*if (n=!n) */g.scroll(0,1);
  g.setPixel(M,0,"#ff0");
  g.setColor(hrm.adjusted?"#000":"#0F0").fillRect(yg, 0,yg=(h.raw/32),0);
  g.setColor("#F00").fillRect(yr, 0,yr=(M + h.filt/256 - 30),0);
  g.setColor("#F0F").fillRect(yc, 0,yc=(M + (h.raw-h.avg)/128 + 30),0);
  if (hrm.isBeat) g.fillRect(yr-4, 0,yr+4,0);  
});
Bangle.setHRMPower(1);
Bangle.setLCDTimeout(0);
Bangle.setLCDPower(1)
/*Bangle.on("HRM",h => {
  h.history.sort();
  print(h);
});*/
setInterval(function() {
  console.log(sps,"SPS");
  sps=0;
},1000);

Posted at 2022-02-08 by HughB

Tested Run and Recorder today. Heart rate was all over the place at higher speeds.
I have attached the recorder log - hopefuly useful for someone.

This is a 1.03 mile walk run, done in about 13 minutes. My AmizFit was warning me that I was over 140bpm at various points when the bangle was saying 77bpm etc.

Attachments:

• Bangle.js Track 0.csv

Posted at 2022-02-09 by myownself

So reporting approx half the actual rate @hughb? Half the actual rate is actually better than I expected for while running (although looking back you said all over the place), and is what I am still sometimes seeing when absolutely still.
Seems to happen when the heart goes over a certain rate, because I was consistently getting readings in the 40s when my heart was going over 90bpm but I get an accurate reading when it is in the 70s.

Posted at 2022-02-09 by @gfwilliams

Seems to happen when the heart goes over a certain rate

It may actually be the filter that's applied is too narrow so it's filtering out the higher frequency... But realistically what we need is a bunch of data files so we can make informed decisions about it.

With no accelerometer input, it's also possible that while running the Bangle is picking up your running pace rather than heart rate.

Posted at 2022-02-09 by myownself

It may actually be the filter that's applied is too narrow so it's filtering out the higher frequency

That was my theory too, I have a recording but haven't had chance to look at it yet.

I've been ill on the couch for a week, so in my case definitely not motion artifacts.

Posted at 2022-02-09 by HughB

But realistically what we need is a >bunch of data files so we can make >informed decisions about it.

By data file do you mean a recorder log file or something else?

Posted at 2022-02-09 by Mi

Recoreder log files can give an impression of the state but unfortunatly dont help with development.
From step-counter your should know: what you needed was the acc files to feed in through the algorithm on different parametrizations and you needed a step count as goal.
So whats needed here is at least ppg to feed in and a hrm (even better the less indirect ecg/ppg) from an other device as goal, and additionally acc.

Right now "HRM Accelerometer event recorder " is the tool to do this. I only used it in PC so far, should work on phone also as Gordon pointed out. File will be stored directly on phone.

Posted at 2022-02-09 by myownself

I've used it on my phone, it works, but I then failed to get jupyter or similar running on my phone to look at it properly.

Exactly as @mi said: for evaluation recorder files plus similar from another device, for development the raw signal (ideally and accelerometer) are needed.

@mi I have bought a pulse oximeter for immediate personal needs but will be useful when we work on the SPO2 functionality.

Posted at 2022-02-09 by Mi

@MyOwnSelf: why not move to pc and look at it there?
You say juptiter. So you are also working in python?
Was thinking of the right language choice. I liked the C in step-counter because it directly connects to the algorithm actually in the firmware and is minimal effort to onboard people, but think jupyiter is probably a much faster development environment.
@halemmerich: what have you used to watch? Do you actually work on any data analysis?

I am currently thinking of a fork with a differcent file format since bringing the different raw signals into one line will become more and more difficult and wasteful (eg. H10 ECG comes in 138 value chunks).
One idea close to current was a firxed csv format line for each event: timestamp, label, ...:
A "grep label" would then still give a simple csv file for that event type so one would have the choice to still use (several) csv reads or a specific read routine.

Posted at 2022-02-09 by Mi

@MyOwnSelf: for your half frequency readings: Did you try to look at the data eg. with code above from gordon? Maybe just looking at it you may see whether the frequency is not visible or it is clearly there but peak detection fails for some reason.
The first steps of the algorithm until peak detection are very simple. Should be reproducible in jupyter within half an hour or so to be able to have an even closer look.

Posted at 2022-02-09 by myownself

@mi I just haven't had the energy. I'll get to it.

Python is my first choice for trying things out. For step counter experiments I used Python and then translated the best option into C, but it would be awesome if we could be language agnostic for testing algorithms - that way people can contribute whatever language they prefer and the algorithm can be translated to C afterwards.

Posted at 2022-02-09 by myownself

I have just remembered, regarding my half value readings, the correct range is shown initially with 0 confidence, but by the time confidence >90% is reached it is showing the low BPM.

Posted at 2022-02-09 by HughB

Right now "HRM Accelerometer event
recorder " is the tool to do this.
Should work on a phone.

I briefly tried it out on my phone and seems to work.

One concern I have is, if I go for a run I will have the watch on my wrist and the phone in my pocket. All I get is a blank red screen on the Bangle, how do I know whats being recorded? Can the heart rate and record count be displayed on the Bangle so I know it's running? I don't want to do a run only to find the recorder switched off in my pocket etc.

Posted at 2022-02-09 by @halemmerich

Actually I didn't do anything more than just plot it using gnuplot. I have attached the files I used for plotting if you want to try it out.

The hrmaccevents app just stores a line per event, so filtering per event type could be done by throwing away all lines that do not have content in the other columns, no label needed.

Attachments:

• plot.gnuplot
• plotfile.sh

Posted at 2022-02-09 by @halemmerich

The bangles screen goes green when it actually starts sending data over. For that to happen all recorded event types must have been seen at least one time. I didn't implement showing data on screen to keep the CPU as free as possible for sending BLE data. It's probably possible to show something on screen, without loosing performance on the sending part. Maybe just printing the send lines to the display would be cheap enough. Record count is currently unknown in the app, just the browser counts the incoming lines. Storing that in RAM and printing it should be no problem.

Posted at 2022-02-09 by HughB

I don't think a simple 2 line display that was updated on sending a record would be too heavy on the Cpu

HRM 66
COUNT 255

The count does have to be an exact record count but just something that shows the recording is progressing and data is being sent. Printing HRM value allows observations to be made about the recording to be made while running etc. Eg I know my heart was 145 but it showed 89 etc.

Posted at 2022-03-26 by Mi

The following is a compressed summery of what I found out so far (No code from me so far. Credit goes to gordon, helmrich, myownself and others)
Please correct me where I am wrong or point me to good information I did't find so far.

Where is the problem?

• As all smartwatches, bangle usese optical sensing ("PPG" = "Photoplethysmography") not electrical as chestbelts do in order to measure heart related information.
• This type of sensor signal is much more vulnerable to disturbance, especially by movement, and therefore considerably more difficult to interpret.
• On the other hand it contains additional information that eg. could enables estimation of oxygen saturation (SpO2) and more.
• There is a proprietory interpretation software blob from the chip manufacturer, but we try to stay open source if possible.
  (http://forum.espruino.com/conversations/371899/#16355245)
• Here is some literature on how such algorithms work:
  http://forum.espruino.com/conversations/372681/#16387616
  http://forum.espruino.com/conversations/373033/?offset=25#16668809

What is the current state?

• Right now heart rate estimation is implemented in C within espruino.
  http://forum.espruino.com/conversations/­372681/#16388080
• For most people HR estimation works pretty ok in rest, but not good while moving. Some people also have wrong reading at rest.
  http://forum.espruino.com/conversations/373033/#comment16423860
• In addition to the HR espruino provides a confidence measure. The confidence is a pretty good indicator of the validity of the HR. You shouldn't trust HR below confidence of ~90. Some apps (eg daisy or circle clock) can use that and hide unreliable readings.
  http://forum.espruino.com/conversations/372681/#16387732

How can I have a quick look or start experimenting?

• For a quick start, you may want to just paste this code into left side of WebIDE
  http://forum.espruino.com/conversations/­372681/?offset=25#16390275
  Yellow is the raw input signal, red the improved filtered one and after a while you can see all recognised peaks marked in purple over the red graph.
  You can see how good the current algorithm works for you (and see that there is even low hanging fruit for improvement still)
• The "HRM Accelerometer event recorder" App allows a more detailed analyses by recording this data and more on a computer/phone into a csv file. https://banglejs.com/apps/?id=hrmacceven­ts
  With this csv you can start analysing and testing in whatever tool/language you prefer.
  As the name suggests also acceleration data is recorded, which so far is not used at all in espruino HRM. Including it should really make a difference.
  Heart rate sensor accuracy/confidence BangleApps#1248
  This app is also a good example to learn how to get all the relevant sensor readings.
• Gorden has setup a test harness and repository to collect test data: https://github.com/gfwilliams/EspruinoHRMTestHarness http://forum.espruino.com/conversations/373033/#comment16554946

What is the plan?

• Set up a test harness where a potential algorithm can be optimized and reproducably evaluated on a train/validation/test set of recordings.
• Collect a good (increasing level of difficulty; from different persons) set of recordings of bangle PPL and Acc sensor data toghether with refernce data from a good external sensor via BLE
• Try differnt algorithms starting with basic ones as eg.
  • just ignore all PPL readings above a certain threshold of movement measured by Accelerometer
  • Improve peak finding (as with the eye one sees very clear peaks that are not found)

Result of attempts so far and analysis:

• http://forum.espruino.com/conversations/373033/?offset=25#16653576

How can I get reliable heart rate right now?
(until me/you/somebody finds the time to improve the algorithm)

• Use a BT chest belt. Bangle can recieve, show, store heartrate via bluetooth.

Posted at 2022-03-26 by Mi

Actually wrote that summery some time ago already, but wanted to post it only after having some code ready - then some unexpected urgent tasks came into the way preventing any work on bangle unfortunatly. Plan to spent some time this weekend though finally.

Posted at 2022-03-26 by myownself

Awsome summary! Please don't credit me, I haven't contributed to any of the code, just messed around a bit. I've also not had chance to do anything a while. Iwas ill in Feb and been playing catch up since then.

Posted at 2022-03-28 by user107850

Hi all,

linking to this other thread, I had setup a repo for testing algorithms on Bangle JS. We currently have algos for step counting but it would make sense to add HR as well.

I have some student working on HR from PPG on mobile phones, but, if time allows, would like also to contribute to BangleJS.

The first thing to do would be to collect raw PPG data, as it comes to the algorithm, with a reference HR from another, trusted, sensor.

Once we are happy with the HR, it would be also cool to see if we can extract other parameters, such as respiration rate, but that would probably come later...

Posted at 2022-03-28 by Mi

Yes.

I am hesitant to ask for recordings though before having done a whole iteration.
Typically then one finds some improvements or missing parts (eg in the file format or naming convention or ...) that are easyly corrected before building the recording library but difficult thereafter.

The first thing to do would be to collect raw PPG data, as it comes to the algorithm, with a reference HR from another, trusted, sensor.

So to me that would be the second thing after having implemented testing harness and at least one algorithm to be parametrized and done that with two or three short recordings of myself.

Posted at 2022-03-28 by @gfwilliams

The original step counting test repo is at https://github.com/gfwilliams/step-count too - that's what we've been using to tune step counting so far.

But definitely the only way to make real improvements (IMO) is to get the data. Personally I think HR data without a trusted HR source to compare to isn't that useful at all.

I believe @halemmerich has actually done all the work there already - he has an app that'll connect to an external BLE sensor and will log the Bangle's HRM data and the trusted data to a file on your PC, so it seems like that'd be a great start.

But yes, if it's just a matter of setting up a repo and test harness and getting some code running then I guess pretty much any data should do it - although if you're doing file parsing it seems it's be worth getting it parsing @halemmerich's files as a first try

Posted at 2022-03-30 by @halemmerich

Mentioned app is at https://banglejs.com/apps/?id=hrmaccevents .
The format is simple csv. Recording of a reference HRM via bluetooth requires https://banglejs.com/apps/?id=bthrm to be installed.

Posted at 2022-03-31 by user107850

For developing a good algorithm we would need the following:

1. raw PPG signal (as it comes from the driver)
2. acceleration signal (useful for trying out motion artefacts cancellation)
3. reference HR

looks like we can get all of them with the apps we have?

Posted at 2022-03-31 by @gfwilliams

Yes - I think hrmacceven­ts does that all for you in one go

Posted at 2022-04-02 by HughB

I had a look at this app and I think if we want to get people to use it and submit logs it needs to be documented with a README file and a few UI changes are needed.

The current way it works is a bit odd, in that you get a blank screen. I would have tried to capture some logs but there is no way I am walking or running with my watch showing a blank screen as I have no way of knowing if the thing is working or not. Plus you have to carry a phone etc with you. I think it would be better to make this app work like the accellog app - where the data is stored in Flash and then downloaded later. A 20 minute trace is probably more than adequate and that should fit into the Flash storage on a Bangle 2.

The README needs to cover:

1. what the app is for
2. how to use it
3. pre-requisties - eg you need you install a reference HRM

Posted at 2022-04-04 by @gfwilliams

I think it would be better to make this app work like the accellog app - where the data is stored in Flash and then downloaded later

There were discussions about this and I think @halemmerich had some troubles getting the relatively big file off the watch afterwards which is why he went direct.

Honestly, for the few HRM traces we need to get started, I think it's probably not the end of the world to have a phone in your pocket. It's not perfect I know, but it's not a reason not to use an app that does exactly what we need right now.

But yes, screen & readme could be added and I'm sure PRs for those would be appreciated - but again, I think there are probably only a handful of people that are going to actually do this with an external HRM, and for them a simple forum post with a few steps would work just fine

Posted at 2022-06-07 by @gfwilliams

Ok, I've just created a repo for the test harness, with some sample data in there. Info at http://forum.espruino.com/conversations/373033/#comment16554946

Posted at 2022-06-22 by user145221

Hmm, I have recorded about 2.5 hours worth of data (including a "gold standard" reference from Garmin watch), but I am not able to download the log.csv file from the web IDE - it says "downloading ...", and after maybe 10 minutes it prints many rows of what looks like base64 data to the left panel, but no file gets downloaded. Is it too large?

Posted at 2022-06-22 by nravanelli

@user145221 Yeah, your log.csv file is probably too big.

By 'gold standard', do you mean another PPG sensor? ECG/EKG chest straps are the ideal reference and would be your gold standard here. Another PPG sensor might have the same issues (i.e. movement artifacts).

Posted at 2022-06-22 by @halemmerich

You can try to make a backup with the app loader and get the file from the resulting zip. That worked for me when I had your problem.

Posted at 2022-06-22 by user145221

@halemmerich: yes, this worked for me. Will upload CSV soon.

Should I fill a bug report against the web IDE not being to download large files?

Posted at 2022-06-23 by user145221

I take the above back. Downloading the backup did not fail, but the ZIP file has storage-files/log.csv, which covers only about 45 minutes worth of data, instead of 2+ hours, if I interpret the Time column as miliseconds since Epoch - it starts at 1655828999759.82763671875 and ends at "165583160794" (the last line seems to be truncated).

Posted at 2022-06-28 by @gfwilliams

Should I fill a bug report against the web IDE not being to download large files?

I think there is already an issue about this.

Honestly, I think right now, for the heart rate analysis, maybe we can just keep the data files to a lower length, like a half hour maximum? Given how we're plotting graphs right now we don't really have the tools to view useful information out of files larger than a few minutes - so while they could be run through the test harness, if they didn't work out well it'd be pretty hard to figure out why.

Posted at 2022-09-03 by user140377

One thing I have not mentioned in my analysis is that I wonder how the closed blob mentioned above works. Maybe it requires to also sets a few registers to improve signal quality?
I assume we still do not have a datasheet?
Has anyone even tested the blob?

Posted at 2022-09-03 by Mi

Would also be interesting to feed test data to that blob to see how it compares (as kind of a "at least that is actually possible" SOTA).
Could that blob maybe somehow integrated into the test harness ? @gfwilliams
[in case it does not actually set registers, which I don't know]

Posted at 2022-09-07 by @gfwilliams

That's an interesting thought... The blob itself is compiled for ARM Thumb-2 so running it on a PC isn't really an option. I guess it might be possible to get it running on a raspberry pi.

If someone has an unmodified SMA Q3 watch (I know some do) then it's easy enough to see how well that manages, and I think it is a bit better than we can do it. It is also possible to reverse engineer the HRM algorithm from the Q3's original firmware (and if anyone's interested I can send them my Ghidra project) - but my initial inspection of the HRM algorithm seemed to show it was nontrivial :)

Posted at 2022-09-07 by user140377

Shouldn't qemu be able to run it? Emulating the sensors might be more difficult..

What I would be interested in is someone sniffing the data between the CPU and the PPG/ACC-Sensors with the Q3 Firmware. Having the computed BPM result what be a good extra. We could then compare the result with e.g. the WPFV algorithm.

It still irritates me, that state of the art algorithms do fail on the data recorded from by Bangle 2.

Posted at 2022-09-09 by @gfwilliams

Shouldn't qemu be able to run it?

Quite possibly. You're welcome to try but personally, getting that working well would take me some time!

I don't think sniffing sensor data would help you too much, as it really is just the PPG values you get.

One potential addition (I mentioned in previous threads) is ensuring that the sensor's auto-exposure calculations are disabled when there is increased acceleration. That way the raw PPG value might end up being a bit more stable when the acceleration is done

Posted at 2022-12-28 by user152235

Thank you for this great summary! Just got bangejs 2. Some interesting research still ongoing regarding skin colour as well!

https://pubmed.ncbi.nlm.nih.gov/35846008/

Posted at 2023-04-12 by KTibow

I modified the test code a bit, and it seems that the HRM event always gets a higher BPM than the manual counting:

var M = g.getWidth() / 2;
var yr, yg, yc, yd;
let beats = [];
Bangle.on("HRM-raw", (hrm) => {
  g.scroll(0, 1);
  g.setPixel(M, 0, "#ff0");
  g.setColor(hrm.adjusted ? "#000" : "#0F0").fillRect(
    yg,
    0,
    (yg = hrm.raw / 32),
    0
  );
  g.setColor("#F00").fillRect(yr, 0, (yr = M + hrm.filt / 256 - 30), 0);
  g.setColor("#F0F").fillRect(yc, 0, (yc = M + (hrm.raw - hrm.avg) / 128 + 30), 0);
  if (hrm.isBeat) {
    g.fillRect(yr - 4, 0, yr + 4, 0);
    beats.push(Date.now());
  }
});
Bangle.setHRMPower(1);
Bangle.setLCDTimeout(0);
Bangle.setLCDPower(1);
setInterval(() => {
  beats = beats.filter(b => b > Date.now() - 60 * 1000);
  console.log(beats.length, "BPM");
}, 1000);
Bangle.on("HRM", (hrm) => console.log("OFFICIAL:", hrm.bpm, "BPM", hrm.confidence));

Any idea why?

Posted at 2023-04-12 by @gfwilliams

How much higher?

I guess it's possible that it is missing an HRM-raw event every so often? And which one do you think is correct?

But the HRM code works by taking all the times between the beats and median-filtering them, so while there could be something wrong with that calculation, the filtering will end up changing the value a bit.

Code is here: https://github.com/espruino/Espruino/blob/master/libs/misc/heartrate.c#L290-L347

Posted at 2023-04-12 by KTibow

HRM: 87 BPM (87% confidence)
Counting beats: 65 BPM
Google Fit (finger on camera): 95 BPM
I suppose the HRM event is more correct, and doing filtering. I still don't know why the Health app claims my heart rate is 40 though.

Posted at 2023-04-13 by @gfwilliams

Looking at the code there is a possibility that if it detected a second beat very close to the first one, it would drop it and then measure the time period between the second and third beat (rather than 1st and 3rd) - but in that case, counting beats should have given you an even higher value so I don't think that's it

I still don't know why the Health app claims my heart rate is 40 though.

No, that is very strange. The Health app should store what it considered was the latest, most accurate reading from the HRM. You could check what it thought the reading was for the current 10 minute block in the IDE with Bangle.getHealthStatus() or Bangle.getHealthStatus("last") for the last 10 minutes.

It might help you figure out whether it was the health app that wasn't recording the data correctly, or the Bangle firmware that was deciding that the 'best' HRM value was 40

Posted at 2023-04-13 by KTibow

In another test it genuinely believed my heart rate was 51 bpm, with 100% confidence. Anyway, after looking at the source code of the Health app, I made a PR to update the HRM logic.

Posted at 2023-04-14 by HughB

Had a look at the PR and will test if you post a link to your personal loader.

I noticed that the key bit of code appears to be:

   if (h.confidence > 80 && Math.abs(Bangle.getHealthStatus().bpm - h.bpm) < 1) Bangle.setHRMPower(0, "health");

IE turn off the HRM power if confidence is greater than 80 we are not getting heart rate values different to the recorded value.

I wonder if the same change needs to be put into the clockInfo module ?

The reason I say this is that I did not realise that the heart rate clock info will only update once when it is displayed for the first time. Only if you tap it, will it update. OR it will get updated periodically without inter-action if you have the health app installed as that will wake up and measure your heart rate more often.

The confidence threshold level in the clock_info is greater than 60 will stop measuring. So this would make the very first reading displayed by the clock_info less accurate than subsequent events generated by the health app waking up the hrm. I appreciate in practice nobody will notice or care. This is just me trying to understand how the heart rate stuff works.

Even with this PR though - its not tackling the HRT accuracy beyond resting heart rate. There is still the issue of the the heart rate slowing down on movement. I did try the Artifact Removal app but not sure if I could see it working or not. The guy that wrote that app is non contactable.

https://banglejs.com/apps/?id=hrmmar

I'd be interested to know if anyone has a description of how to show that the artifact removal app works or not.

Posted at 2023-04-14 by KTibow

That change wasn't to make sure it stayed stable. It was to make sure that the health bpm had updated, since it only updates when it gets a higher confidence than the last stored one.
In order to test I just used the Espruino IDE.

Posted at 2023-04-15 by user140377

On the watch itself a confidence=0 indicates hrmmar is active. Also in the console you can subscribe to the HRM event:

Bangle.on('HRM', print)

If you see a value in bpm_orig and confidence_orig hrmmar has replaced the firmware value with a value it thinks is not motion affected. For a confidence value of >= 90 the firmware value is displayed.

Please note that the fft elimination needs 8 seconds of sensor data to compute its value on so it might not be suited for the health app. Maybe it is a good idea to disable hrmmar when health is requesting the hrm data, I did only run short tests with health but have not seen an issue here.

Update: Because of alphabetically order health.boot.js should load before hrmmar.boot.js so health should ignore any modification of hrmmar.

Posted at 2023-04-19 by HughB

so health should ignore any modification of hrmmar.

But surely the point is to modify the heart rate detected by patching the code by installing the hrmmar app ?

I dont see much point of installing an app that is meant to improve the heart rate detection only to find that it only works under experimental situations. The whole heart rate measurement thing is a bit confusing right now with different apps all tweaking things differently.

I tried out the app and logged to the console as you suggested whilst sat on the sofa. I had been up and down the stairs a few times so my heart rate was around 80bpm. All the time I could see confidence = 0 the corrected bpm recorded in the logging was around 95-110, wheras the original value was actually closer to what it was ( I also used an AmazFit bip on the same wrist to check it).. So not improved but made worse. I could understand it not working well if I was actaully moving about a lot but I think the app is basically not working. I have attached the log.

Attachments:

• hrm_artifacts.log

Posted at 2023-04-20 by user140377

I can't say for sure for your case but usually when sitting still the noise from the accelerometer is so high that the result of the fft is invalid. Personally I don't see this as a big issue because the firmware value is used when confidence is high. Which also only happens when the wrist is not moved.

I've also seen cases in the same situation (sitting still after movement) where firmware reports about 40BPM, hrmmar says 100 and the real value was 80.

However yes there is lots of room for improvement.

But surely the point is to modify the heart rate detected by patching the code by installing the hrmmar app ?

The usecase this targets are apps like Heart Rate Monitor , not Health.