Search results for:

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

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.

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

In principle yes, but it is probably a tough problem.
Thats the thread for this:
http://forum.espruino.com/conversations/372681/?offset=25#comment16390084
First goal there is to get HRM right when not in rest. But there are people interested in SPO2 and other things to squeeze out of that sensor data. You are invited to participate.

EDIT: oh, same time answer, got interrupted by phone call :-)

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.

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)

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

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

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.

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.

For meauring one version against another what should the test methodology be at running speed

Right now the statiscs only reflect the algorithm used at recording time and are not suitable to compare differenct parameters/approaches.
Before we can start assembling a test suite for the runners use case we first need to make sure we can record all data necessary, especially ppg, acc and some bt reference in sync and are able to do something useful with that data.
To ensure the last point we have halemmerichs hrmaccevents for now as a great starting point for local use at the computer as said.

But then yes, a set of files from different runners is what I think of. I don't know how relevant the concrete speed is above some point - depends on style I would guess, but we see the speed roughly from number of steps or more accurate from GPS if provided in the file anyway.
[Due to an injury, I can't run for some time unfortunatly, will start with cycling]

---

And sorry that I posted those statistics here in the Run App Review Thread
I will stop discussing this here and continue in the PPG thread until we have a conrete call for data donations.

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: https://github.com/espruino/Espruino/commit/407dd17e0903840df724ebf25f83d2bb95863fb5)

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

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.

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

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.

Did some statistics. We were both right sort of:
While the standard deviation gets much bigger with lower confidence and also the mean error gets bigger, it is still not as totally off as I would have expected:

See scatter plot of dHR over confidence (dHR is differnce between bangle reading and a polar H10) and the standard deviation over confidence in the two attached pictures.

This recording is from walking on pavement and driving car as a passanger. For an other recording with walking on rough terrain, the result is pretty much the same, just higher amount of data with low confidence.

On Bangle 1 I came to the conclusion that confidence was a waste of time and it was better ignored and heart rate averaged

My impression is exactly opposite right now. Should have a real statistic by tomoorow. But it seems HR is really good when confidence is high (>90) and way off with low confidence which would make any averages useless. I got this impression from looking on BT HRM which show all relevant values.

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)

Polar OH1+: works great without any tweaking.
is super close to the precision of a chest strap (without the annoyance)

Are you after the "works great without tweaking" or "without the annoyance of cheststrap"?
If first then you can go for H10 also, which should be one of the most precise. It can also send medical grade ECG. Will see if I can manage to store those with bangle.

Ok, just didn't wait long enough - .bthrv is only written after 300sec.
Can confirm everything looks good. See data in recorder file also.
Get RR and HRV for polar H10 (not Contact and BT Battery though)

Hello - this thread is intended to colaborate on PPG analyis, especially for bangle.
This discussion bagan in other threads (eg. http://forum.espruino.com/conversations/371899/?offset=75#comment16386217) where it doesent really belong.

I will try to collect a summery of the status quo soon.
[Update]: not really soon, but finally here is introduction overview and summery of the current state:
[Update 3.9.22: @Gordon test harness; Analysis and literature from @user140377 ]

http://forum.espruino.com/conversations/372681/?offset=50#16454552

Thanks @myownself.
And I will open a new thread for PPG analysis

UPDATE: Done http://forum.espruino.com/conversations/372681/

Working again :-) I see connection and HR recorded with recorder app.

How would I test the new functionality?
bthrv file is existent but empty:
Time,10s,20s,30s,60s,120s,300s,RR_max,RR_min,Measurements
hrv app doesn't work, but that is to be expected as H10 doesent provide HRV as far as I now.
RR should be available though (https://github.com/polarofficial/polar-ble-sdk)

And another feedback: the settings arent clear to me:
if only use bt hrm is selected I see both in the app and in the recording,
if both options are selected bt is no longer shown???