PPG analysis beyond HR at rest

@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

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

And a quistion for @Gordon 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?

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.

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

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)

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

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.

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.

@Gordon: 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?

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);

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.

1 Attachment

• Bangle.js Track 0.csv

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.

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.

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.

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?

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.

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.

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

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

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

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.

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.

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.

2 Attachments

• plot.gnuplot
• plotfile.sh

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.