We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I was thinking whether its feasible to use a 8-bit counter with auto-reload to capture the number of peaks detected within 100ms.
You mean getting the heartbeat peaks within 100ms is too short?
Yes, way too short.
I have to get the peak within 1sec? and multiply it by 60 to get the pulse per min?
That would still be a very unsatisfactory approach.
Consider a situation where you have 65 beats per minute. If you measure the number of beats in each second, you'll still only get two different values: 1 and 2. So your display would mostly be showing "60 bpm" and once every couple of seconds jump to "120 bpm".
Even worse, if you have 55 bpm, you'll end up with 1 or 0 beats per second (and usualy, having a heart rate of 0 bpm isn't a good thing).
You either need to count the number of beats in a much longer interval (for example, 60 seconds), which will give you a nice, steady average value but will be very slow to respond to heart rate changes. Or you measure the time between two heart beats, which will give you great beat-to-beat accuracy but a very unsteady number (you could output an average of this number over several beats to get a more stable output).
If i measure the time between 2 heartbeats, how do i convert it to bpm?
"you could output an average of this number over several beats to get a more stable output"
Meaning i have to repeat the cycles several more times to get a more stable output?
High-end equipment always measures the time between each individual beat. Then it is possible to display a frequency (after averaging) and to perform jitter analysis of the data. For example, the heart beat interval changes when you are filling the lungs. If the body isn't stressed, the heart can avoid fighting for the same space with the lung. This can be used to estimate over-training.
Frequency (f) is the inverse of period (T):
f = 1/T
Measuring the time between two heartbeats gives you the period T in a unit of your choice (if you don't want to deal with fractional numbers or floating point just yet, I would suggest you use milliseconds at this point, but you'll need to do some fractional calculations later on).
For example, if you measure 750 ms, you would get
f = 1/(0.75 s) = 1.33 Hz = 80 bpm
Yes. The heartbeat has quite a bit of beat-to-beat variation, and if you don't want to see that in your application, you can average several measurements (how many depends on how stable you'd like the number and how slow of a response to changes you can accept).
"High-end equipment always measures the time between each individual beat. Then it is possible to display a frequency"
You mean using a oscilloscope? If not, my sensor is a simple DIY sensor connected to an amplifier of 100 gain.
T = 1/f, so f = 1/T.
When displaying the information, you might want to measure the sum of five intervals. Divide by five (gives you an average for the five intervals).
1120ms => 1/ 1.120 => 0.89 Hz 0.89 Hz * 60 => 53 bpm
The 1120ms is the average time of the time between 2 heartbeats for 5 cycles?
If so, how can i use programming to measure the time between the 2 heartbeats?
Oscilloscope? You are aware that the heart beat speed in bmp is a frequency? Why would you want to use an oscilloscope to display the bmp? An oscilloscope isn't used to display a frequency (possibly to measure a frequency) but to display the shape of a curve.
It is only for stress analysis where it would be nise with a graph to display the inter-beat variation, but that is something completely different from measuring the heart beat frequency.
You can use a high-speed counter and capture the time of a pulse. After you have captured enough pulses, you know (from the running counter) how long time has passed according to the counter tick frequency and number of ticks.
Oh. But how do you use programming to get the time between 2 heartbeats?
You will need to set up one time to generate your "base" clock (1 millisecond ticks). Then you use either an interrupt or polling (heart rates are slow enough to allow this) to wait for the heartbeats.
I see... So I'm using a integrated 16-bit counter with capture... Thanks...
"A high-to-low transition on the T2EX input pin causes the 16-bit value in Timer 2 (TH2, TL2) to be loaded into the capture registers (RCAP2H, RCAP2L)."
This means that my counter can only capture the values of TH2 and TL2? How do i capture the time than?
Does it matter if you measure the time between two low-to-high or two high-to-low flanks? Are you expecting them to come at different frequencies???
Note that each tick of the timer do represent real time. Hence, the capture represents a specific position on the time scale. When you have received a capture, remember the time and rearm for a new capture.
I see. So i have to run the timer for some time(lets say 3 sec) and whenever theres a high-to-low transition, the timer will capture the high-to-low transition and stores the position in TL2 and TH2?
And from TH2 and TL2, how do i find out the time?
"to be loaded into the capture registers (RCAP2H, RCAP2L"
If you had a normal clock ticking one step every ms, and you have the ability to now and then capture a value - how would you then figure out how long time have passed?