PPG analysis beyond HR at rest

You are reading a single comment by @halemmerich and its replies. Click here to read the full conversation.

•

Mi

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

•

halemmerich in reply to @Mi

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.

•

Mi in reply to @halemmerich

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.

About

Avatar for halemmerich @halemmerich started