1. Home
  2. Official Espruino Devices
  3. Bangle.js

PPG analysis beyond HR at rest

Posted on
Page
of 4
First Prev
/ 4
Next
  • • #51

    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.

  • • #52

    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?

    What is the current state?

    How can I have a quick look or start experimenting?

    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:

    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.
  • • #53

    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.

  • • #54

    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.

  • • #55

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

  • • #56

    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.

  • • #57

    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

  • • #58

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

  • • #59

    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?

  • • #60

    Yes - I think hrmaccevents does that all for you in one go

  • • #61

    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
  • • #62

    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

  • • #63

    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

  • • #64

    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?

  • • #65

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

  • • #66

    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.

  • • #67

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

  • • #68

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

  • • #69

    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.

  • • #70

    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?

  • • #71

    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 ? @Gordon
    [in case it does not actually set registers, which I don't know]

  • • #72

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

  • • #73

    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.

  • • #74

    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

  • • #75

    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­/

Page
of 4
First Prev
/ 4
Next
  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
Post a reply
About

PPG analysis beyond HR at rest

Posted by Avatar for Mi @Mi

Actions

© Espruino, powered by microcosm.

About Terms of Use Privacy Policy Cookie Policy Report a problem