liegepr
commented
1 year ago In the attached txt file, you may count 51 qrs in 23 seconds. Mean + sd HR should be 133.04 ± 25.7 bpm in place of 170 – 174 bpm. Note that the range 170 – 174 read on the HR txt file logged by the app matches the values that were displayed real-time on the bike computer paired to the H10. The data are part of a larger dataset that I've analysed using EDFbrowser (starting with qrs detection). The software did not report such higher HRs.
Platform your question concerns:
Device:
Description:
I would like to align the detected qrs peaks with the ECG record
How is the parameter ppErrorEstimate being calculated? By aggregating on sliding time windows such as when calculating rolling (moving) averages?
As noted in issue #13 a heart rate measurement in beats per minute (± 2 to 5%) is stored once every second which is suboptimal. How is this measurement being estimated? I noticed a severe overestimation of HR where important variations exist between consecutive RR intervals. This should not be the case since RR intervals are accurately estimated. Indeed I could visually check on an ECG trace that the H10' qrs detector performed well in such cases. I've read a discussion about the ECG signal quality in the product's whitepaper (Nov. 11, 2019) but signal quality looks good for my data. Looks as if the corrections to compensate for poor signal quality would impair calculations with non sinus rhythms.
NB: The RR, HR and ECG records I am referring to were obtained using the Android app "Polar sensor logger", but the app doesn't seem relevant to the above 3 questions.