HRM statistics that we don't have yet (and a summary of previous conversation about them)

1. HRV
   
   • Because we switched to the proprietary algorithm, it's going to be harder to calculate this either in the firmware and in userspace. However I think this would be useful to track as it gives information relevant to stress and sleep.
     
   • Gordon: you can get all the absolute heart rate values for each heartbeat so can work out HRV pretty easily with an app. HRV calculations are not built in to the firmware though. What is the model of the heart rate monitor?
     
   • Notes: HRV already has some implementations (an app on github and an app on the store) but they're either broken or don't use the built in HRV monitor.
     
2. Blood pressure
   
   • In order to implement it, the manufacturer code needs to be set up and someone needs to test it. It might also mean worse performance, but it would be nice to have.
     
   • Gordon: The Bangle.js 2 sensor can handle Blood Pressure - hopefully I'll be able to expose that eventually possibilities and potentials of bangle.js.
     
   • Gordon (implying they don't want to use manufacturer code): It's just finding a decent algorithm, which I guess just looks at the rising and falling times. possibilities and potentials of bangle.js.
     
   • Gordon (mentioning manufacturer code): I do have that code as well, yes. [...] I also don't have a blood pressure tester here so it's not something I'd have any confidence in testing - I never had much confidence in using PPG for blood pressure, but if it worked for you maybe there's hope :) Bangle.js 2 Cutting Edge - new heart rate algorithm
     
   • Notes: This requires using the mode with faster readings
     
3. SpO2
   
   • Same goes as for blood pressure
     
   • Gordon: It's definitely possible and I can provide the binaries to anyone who is interested in looking into it, but it's quite a lot of work. Bangle.js 2 Cutting Edge - new heart rate algorithm
     
   • Gordon: The VC31B is capable, but it's something provided by a binary blob which we don't include in the firmware. What is the model of the heart rate monitor?
     
   • Gordon: The VC31 in KickStarter bangle 2s didn't advertise the capability but the VC31B in the new batch does. [...] It has to be calculated from raw data so the value is going to be a bit of a guesstimate. Measuring Blood Saturation. Would that be possibile?
     
   • Notes: This requires using the mode with faster readings
     
     

Hope this doesn't give off the wrong vibe or anything, just making this post to see what others think and possibly help people looking for a summary.

Nice to get a summary! May I suggest you edit in links to the sources with the [info](url) format?

Sources added.

Gordon: you can get all the absolute heart rate values for each heartbeat

Yes - just Bangle.on("HRM-raw", ...)

And yes, I think now we've gone down the route of using a binary blob we could potentially pull in the other binary blobs for different data, however the sensor needs setting up in a different way (faster HRM measurement and interleaving env measurements) so it's not as easy as just dumping it in.

And looking again at the HRM binary blobs I see Sp02 but I have I don't see any Blood pressure algorithm, and even though the original watch firmware has an option for Blood pressure I can't seem to get it working.

Yes - just Bangle.on("HRM-raw", ...)

It's hard though because the data can be a bit all over the place, even when filtered using our algorithms (see attachments - green: raw, magenta: adjusted for bias, red: filtered). While the new algorithm for measuring BPM is very accurate, it's going to be hard to compete with its ability to count beats.

Also after I spent a bit looking through the Espruino code trying to understand some stuff, I have some questions: Where does raw come from with the vc31? The only place I see raw getting set is in heartrate.c, and I thought heartrate_vc31_binary.c is used instead with the vc31, so raw shouldn't be set. And in theory could you modify the manufacturer code to expose their filtered version?

4 Attachments

• download.bmp
• download (1).bmp
• download (2).bmp
• 

Where does raw come from with the vc31?

Interesting - do you still see useful values in raw? As you say it looks almost like it's not set anywhere. It should probably be set with hrmInfo.raw = hrmValue; in heartrate_vc31_binary too.

And in theory could you modify the manufacturer code to expose their filtered version?

Not really - it's a binary blob so can't be modified or examined (apart from with a decompiler). I think it works in a different way anyway - by taking blocks of HRM data and examining each block, rather than by 'streaming' it in as our algorithm did.

Interesting - do you still see useful values in raw? As you say it looks almost like it's not set anywhere. It should probably be set with hrmInfo.raw = hrmValue; in heartrate_vc31_binary too.

You're right. .raw is always 0 (as such the magenta line is just displaying the inverse of the average). Should I make a PR or do you want to add that line?

I think it works in a different way anyway - by taking blocks of HRM data and examining each block, rather than by 'streaming' it in as our algorithm did.

Decompiled it and yeah I have no idea what it does ¯\_(ツ)_/¯
Also here's the decompiled version for anyone who wants it https://ktibow.github.io/blog/vcareexpla­nation/

Thanks - but no problem, I just pushed the change

.. and thanks for the info about it. Did that explanation all come from GPT-4? It's quite impressive

Yeah it was all from GPT-4. Note that it did hallucinate a bit (the arguments are hallucinated given that the decompiler doesn't have the type defs and I didn't provide the type defs, and it got the hex decoding wrong once), but when I tried providing more info I found the other explanations lower quality than the first one.

Hi I originally made a HRV app for the Bangle 1, which I can probably check and change if it's busted since I last updated it. I can definitely make it more efficient. I've been looking at making a similar one for the Bangle 2, which I recently got; it's a great watch but the PPG signal is definitely harder to work with either raw or filtered, signal moves around a lot probably because of the auto-adjustments it seems to make. Will try get something working for it though, I'm trying different options around polling rates and locking the LED auto-adjustment to see if I can get it more stable.

For Sp02, I doubt this would give anything useful - SP02 is usually red + IR light you need to measure not green because your blood absorbs green. I've seen notes on research using different shades of green but not green + IR. You basically do comparisons of the 2 signals to see light absorption at different wavelengths in the same kind of range but because green and IR are so far apart I'm not sure it would work. Datasheet doesn't suggest it has a red LED. It's possible they have a different similar model that uses a red LED instead of the green tailored more for Sp02.

For blood pressure, it looks like you need quite a clean, stationary signal for this. I actually think it's possible to get blood pressure from recorded data out of Bangle 1 easily. The caveat is the algorithm would probably have to be done outside of the watch so would need to use a phone or something that can handle more power and transfer the data by bluetooth or do it retrospectively. The easiest methods I've seen take PPG signals directly and run them through a neural net. The Bangle can run tensorflow so theoretically, if you get a small enough tflite model that can take a low 25Hz signal it could work but I think the pre-filtering you need to do beforehand as well with it might all be too much.

While the signal does move around, I think one of the reported values (.raw?) does have some filtering to smooth out the big jerks caused by the LED power changing over time. If that's run through a filter to remove the low frequency parts it should be reasonably good.

There are the .filt values that is bandpass filtered but it has issues with clipping out I guess because they are all 16 bit. It also bandpasses the wrong frequencies at 25Hz I think? I might have a better approach for filtering from the raw signal that I've put a write up on in more detail here:

https://www.majorinput.co.uk/post/bangle­-js-2-dealing-with-noisy-ppg-signals

Basically you take a sample of .raw data then:

1. apply differencing to remove low frequency noise (subract last value by current in each array element)
   
2. apply differencing again (I didn't mention it in the blog post but it works better doing it twice)
   
3. convolve with a gaussian filter.
   
   

With the above, you won't get clipping issues because the values reduce as it's filtered down and you get a much better fourier transform. You could derive the HR by FFT from this even with shorter windows or calculate by peak detection and then based on the average interval/gap in the window. I've got a javascript app that runs on the bangle alligned to this but step 3 in the above is running a bit slow, I'll try getting it to run faster or even try your test harness thing and see how it works at firmware level. To be honest I think the proprietary HR algorythm seems fine so wouldn't change it for HR but this could be useful for HRV if it works ok and replace the filter algorythm.