Closed Eichhof closed 6 years ago
Wow, I don't know how help you with that 😕 I have never used a polar H10 chest strap and have no experience with "precomputed" RR intervals data such as yours. However, if I were you, I think I'll directly use the RR-interval column, sweep the Timestamp column under the carpet, and hope that the RR intervals are correct.
Thanks you for your answer. I will try to progress as you proposed.
Did you put into account that the time unit for RR interval in Polar electronics is 1/1024 seconds?
Hi,
Regarding HRV, I’m using the polar H10 chest strap which works in general very well but I have faced a weird behavior. For example, I have observed the following values:
The first column is the timestamp in milliseconds (in UNIX time). The second column is the corresponding RR-interval
The polar device sends me one package around every second (with a RR-interval value). As you can see in one package there are two RR values. This happens from time to time. According to the bluetooth protocol this is valid, but it is a bit strange to me. I think the RR interval should approximate real time. 1508770158345– 1508770156395 = 1950ms = 1.950s but when I sum up the RR intervals I’m getting 892 + 905 + 863 + 846 = 3506ms = 3.506s.
I don’t know how to approach this. The ecg_hrv function from neurokit, that computes HRV features, needs R peaks location as input. The step, in theory, before RRi computation. So we have to somehow transform your RRi data back into R peaks location. We can do it by computing the cumulative sum. But this assumes that the rr intervals sums up to real time which seems not to be the case in the above example.