Dear ANT+ experts and novices,
I would like to share some observations with you that I have made regarding the timing of heart-rate
events and
transmissions.
As context, this adventure started here
https://www.thisisant.com/forum/viewthread/4299/ and an indication of the script I was using is provided here
https://www.thisisant.com/forum/viewthread/4358/
It is important to know that the log-file I create (written out from SimulANT+) contains the following columns:
(1) Event time [1/1024 s]
(2) Event count (8-bit seq. num.)
(3) Heart-rate [bpm]
(4) Local computer system time [HH:mm:ss.000]
So the first issue is that most "events" resulted in 3 transmissions, each with their own local computer clock timestamp. (When I say computer, think PC or laptop.) Although sometimes only 2 or even just 1.
This was evident because for each event the Event time and Event count were identical, as were the reported Heart rate values.
It might be anticipated that the data would be broadcast perhaps at 1 Hz (once per second), and, indeed, this is what the manufacturer has told me. However, according to my system clock timestamps, the transmission interval took several values that were all multiples (approximately) of 250 ms, as if by 4Hz sampling. See attachment 1.
Actually, I don't care that much about the transmission times, partly due to the known unreliability of PC time clocks anyway, along with the greater importance of the timing of the event than its broadcast, and the complication of having up to three data transmissions for a single event. Thus, I focussed on Event time.
They key thing I noticed was that the
interval between Event times was
almost exactly varying in
inverse relation to the HR. See attachment 2.
This seemed to indicate that each event was the detection of a pulse! How great, so I could then obtain a millisecond-precise estimate of intervals between pulses!
But further investigation showed that the relationship was 'too perfect'. The intervals between physiological pulses should be allowed to have any millisecond value from about 300 ms up to to 1500 ms.
For example, an interval of 1481 ms (corresponding, if extrapolated, to 40.51 bpm) should be possible to observe. But in the data series such intervals were never observed.
Only intervals which converted almost perfectly to integer values of HR were reported in the data set! It is hard to imagine how this can happen.
In the meanwhile, I have also been informed by the company that the HR reported is a "blended" value, which I presume means is not literally 'instantaneous', but is a filtered value computed from the last few events.
Below is an abridged and amended version of what I have sent the company. However, they have ultimately been unable to fully explain this to me.
~~~~~~~~~
...we never seemed to obtain intervals such as 803 ms or 747 ms, for which the HR would be most accurately estimated as non-integer (74.72 bpm and 80.32 bpm).
Rather, we only ever seemed to obtain intervals such as 800 ms or 750 ms, for which the HR would be most accurately estimated as integer (75.00 bpm and 80.00 bpm), to one or two decimal places [according to the precision of the timestamp].
In my mind this seems to break the direct connection between the timing of the physical pulse and the signal transmission from the device.
In that case it would have to follow a pattern more like the following:
Time = 0 ms: Beat detected.
Time ~ 1 ms: The device computes that there was an interval of
X ms from the previously detected beat. It might also consider a moving window of (say) the ten previous beats, check for noise, etc.; it then estimates the current HR as
Y bpm. By
rounding the HR to
Y* bpm, the device determines that it should report this value associated with a fictitious event occurring
Z ms after the previous fictitious event.
Time = 300 ms: Time of latest fictitious event.
Time = 500 ms: The device reports the current HR as (approx.)
Y* bpm, with Event time=300ms.
Time = 803 ms: Beat detected.
Time ~ 804 ms: The device computes that there was an interval of 803 ms from the previously detected beat (803 – 0). It might also consider a moving window of (say) the ten previous beats, check for noise, etc.; it then estimates the current HR as (say) 74.80 bpm. By
rounding the HR to 75 bpm, the device determines that it should report this value associated with a fictitious event occurring 800 ms after the previous fictitious event.
Time = 1100 ms: Time of latest fictitious event (300 + 800).
Time = 1250 ms: The device reports the current HR as (approx.) 75 bpm, with Event time=1100ms.
Time = 1550 ms: Beat detected.
Time ~ 1551 ms: The device computes that there was an interval of 747 ms from the previously detected beat (1550 – 803). It might also consider a moving window of (say) the ten previous beats, check for noise, etc.; it then estimates the current HR as (say) 80.41 bpm. By
rounding the HR to 80 bpm, the device determines that it should report this value associated with a fictitious event occurring 750 ms after the previous fictitious event.
Time = 1850 ms: Time of latest fictitious event (1100 + 750).
Time = 2000 ms: The device reports the current HR as (approx.) 80 bpm, with Event time=1850ms.
If this is what happens, it might still provide useful information.
I guess this would mean that the transmission intervals still have some relationship to the interval between physiological pulses of blood, albeit complicated.
~~~~~~~~~
Can anybody shed light on whether the above makes sense, and how & why it would be implemented like that?
I only got this data from one model of device (wrist monitor). I did not get such data from a chest-strap.
Image Attachments
Click thumbnail to see full-size image
]
