Creating Polar Heart Rate Receiver Object to submit to Obex
rwgast_logicdesign
Posts: 1,464
So the heart rate receiver is one of the major reasons I requested this kit. The the thing is fairly easy to use, the kick start demo is super simple!! I need more functionality out of the thing than sending beat to the serial terminal every time my heart beats though. Ive been reading the Propeller Education Kit to sharpen my skills for this contest. I figured maybe I could write an Obex Object for the heart rate reciver that does a bit more than the simple kick start, gives average heart rate, time between heart beats etc. Im going to try to provide a sample program for the object that uses the BOE's SD slot to do some data logging this way you could go for a walk with your BOE and the heart rate receiver and view some meaningful info about your heart rate during walking vs resting. I was orginally going to use a nokia 5110 screen for the demo but mine crapped out, plus an SD card is more generic, I hate when driver demos use something I dont have available to me.
Anyways I just wanted to say im open to any ideas you guys would like to see in the driver for the heart rate reciver, as long as im capable of writing it, and it fits in with the concept of a driver and not a full blown program. I figured Id post here instead of the Prop forum because most anyone with these polar heart rate monitors is probably checking this forum, wether there a regular or not.
Anyways I just wanted to say im open to any ideas you guys would like to see in the driver for the heart rate reciver, as long as im capable of writing it, and it fits in with the concept of a driver and not a full blown program. I figured Id post here instead of the Prop forum because most anyone with these polar heart rate monitors is probably checking this forum, wether there a regular or not.
Comments
My primary concern is how good the Polar device is at determining that a signal is truly a QRS complex vs artifact. Had a patient in the other day who had so much pectoral muscle activity from overusing his inhaled beta agonists that it was impossible to get an EKG and essentially every time we tried we just got a 12 lead surface EMG. The Polar technology seems to be fairly good in healthy individuals as it seems to reliably detect my HR when I'm working out but would have to compare it against an actual EKG recording to find out what it's missing or adding.
For healthy individuals, the Polar HR device is very easy to use, but when someones sick - it would help to know the limitations of the proprietary technology. I'm probably going to go with raw EKG but the problem there is electrode placement as it's easy to build a high CMRR EKG amplifier but then there's environmental electrical noise to deal with as well as non-cardiac EMG noise. EKG signal amplitude is decreased by presence of a conductive fluid between the heart and chest ie blood and one is going to need a backup for the Polar monitor if it's going to be used to deal with very sick people.
So, getting HR data for a healthy individual jogging is easy but for wounded soldiers not as straightforward and backup systems would be necessary - ie use of photoplethysmography for detecting heart rate (or the old fashioned manual stethoscope).
LEARN.PARALLAX.COM has a page on getting started with it, I used it and works like a charm. Hope this helps when you get yours.
Polar Heart Rate Receiver
http://learn.parallax.com/KickStart/28048
@borisg - The sensor seems pretty sensitive when I'm wearing it, but I am reading a regular heart beat (or at least I hope) and decently healthy.
1. It would be wise to include a feature that compares the value of the current heartbeat with your current average and if the difference is abnormally large, it may be safe to assume it was a spurious reading. (transmitter bounced on the chest, etc). Developing a method that compares the current value with the average, then decides its validity based on a threshold you define will enable clean readings/averages.
2. Since the human heart can actually change rates fairly quickly (usually increasing), you need some way to determine when that is occurring so that you don't dump valid data from item number 1 above. By using two unique averaging buffers (one is used to hold the working or current average and another is used to "acquire" a new average). You start pushing heart rate values into the acquire buffer when they are different from the current buffer's average and once you cross some threshold you move the new buffer over to be the working buffer. You need to discriminate against both buffers. You reset the acquiring buffer every time there is variation in incoming data that isn't passed through the discriminator so that you "know" when you've got a valid new series.
Simply put, you need to discriminate against beats that are invalid and average the sequences of beats that are valid. For humans, you can easily setup your "filter" to weed out any readings that are outside of the 40-200 BPM range. From there, weed out any results that are different than your current average BPM by X amount. Not sure how quickly the human heart can change rates, but by use of a second buffer that has a rolling average, you can catch the rapid increases even if you ignore a few of the initial readings for the current average buffer.
So, if you can code buffers, it should be easy to develop an object that provides a very stable BPM reading.
WRT human heart rates, the range needs to be wider. The lowest HR I've seen in sinus rhythm was a patient of mine in the ICU whose HR was 26. The cardiologist and I both assumed that she'd be getting ventricular escape at 30 but here she was sleeping soundly at 26 bpm with a stable bp, and rather than giving her some atropine, we just let her brady along for a couple of days till she woke up. This is not a usual condition and I suspect what she had was a vagal freezing response.
Also, extremely fit individuals can have sleeping heart rates of 30 or less. One of my CCU experiences as a resident involved a fireman admitted for smoke inhalation who'd drop his HR to 30 every time he fell asleep. The minimum bradycardia rate that could be preset on the monitor was 35 and he spent the night being yelled at by nurses to wake up so that the alarm could be silenced. So, when looking at bradycardia, one should make a system flexible enough to deal with human extremes. We're talking about some ludicrously fit military personnel as potential users of the device.
On the high side, young people can have HR's >200 and I've seen young people with SVT of 240 (obviously not for long as they were quickly cardioverted back to NSR). Thus, to make any system usable with the range of human physiologic variability, I'd have a range of 25 to 250 for HR. Also, one should have an indication that one is picking up electrical activity consistent with HR outside of those ranges. Generally one doesn't see VT at 300 last for very long.
Human HR is not regular but rather has significant variability which, in young healthy people, is largely respiratory sinus arrhythmia. It's a challenge sometimes to distinguish respiratory sinus arrhythmia from atrial fibrillation which can be done fairly easy clinically by observing the jugular venous pulse. Atrial fibrillation detection would be nice to have and the easiest way to pick it up would be having a HR > photoplethysmograpic peripheral pulse waveform. This gives one the old "pulse deficit" which is the difference in HR one gets from auscultating the heart with a stethoscope and peripheral pulse.
One of the most annoying things about the Polar HR monitor is that it's proprietary and thus we have no knowledge of what it considers to be a normal QRS. I have no idea if it looks for a P wave or whether it just triggers on high voltage QRS spikes. It must have a fairly robust algorithm for rejecting surface EMG activity as I know lots of people who've worn the Polar monitors while working out and it gives HR consistent with what one would expect for the physical exercise they're doing. If anyone does have any more details about the Polar algorithm, I'd be interested in hearing them.
Noticed that there's no battery slot on the Polar chest strap and I'm assuming that one just wets the sensor pads and attaches it to ones chest and it will start transmitting? Will find out tonight.
The nice thing about the Propeller chip is that it's fast enough to log an EKG waveform sampled at 1 KHz as well as all of the other things I'm planning to cram into my project. This has been the most fun programming I've had since I first got to play with a PDP8 computer 40 years ago.
Maybe having someone hooked up to an EKG and wearing this Polar unit at the same time would enable you to determine what the algorithm is triggering from?
I'm curious how other people have gone about interfacing to the Polar monitor - PASM or Spin? Most of my coding has been in PASM and the first thing I did was to write a 1 msec clock which runs in a cog, wrote a RTC to go along with it and added the Polar receiver interface in my 1 msec clock loop so I can sample start of the Polar pulse to 1 msec precision. Use the duration of the pulse as an indication of whether it's real or artifact. My worries about running out of space in cog RAM were unwarranted as event with the msec clock, RTC and Polar HR monitor I'm not even at 50% of RAM. Realizing how powerful 32 bit assembler can be, especially with the control one has over setting of c and z flags.
I was planning to submit my Polar monitor object to Obex once I get the code cleaned up (I've removed almost all absolute hub locations now that I know how to access variables defined in Spin). My approach to this problem is to first create a precise time source and then generate a stream of HR events which just now consist of a 32 bit msec time as well as the pulse duration to check for noise. These events are written to a hub location and Spin has been more than fast enough to grab an event before it's overwritten. IMO, just getting the events into a hub RAM location is all that one needs for the Polar driver. Having a RTC saves me from having to write down the time that I start collecting data as I just send a timestamp to my SD logger.
Has anyone been using the cog timers as a precise timebase? Despite multiple readings of the documentation in one of the Parallax application notes, I just haven't been able to make a msec clock from two timers. Thus, just use standard timing loops in PASM.
WBA thank you for that, it is exactly the input I was looking for, I have played with this sensor and started the driver, I still have a bit more research to do about using the counters, for this and 5 other things. But you are telling me this sensor gives false beats? Sometimes when I have it plugged in I see something like a beat..........beat...beat.......beat..........beat, I had assumed those timings were my heart not the sensor messing up. Will the paper you linked to explain why this happens and how to tell when it is happening?
Polar's site has zero information on the monitors aside from how to hook them up. May have to build an EKG amplifier and put the electrodes close to the polar ones to find out what it's picking up and what it's rejecting. The surface EMG signal rejection must be quite good as tensing my pectorals didn't result in any additional beats and only showed the slight increase in HR that one would expect for isometric exercise. Have to try to get as much done in the next 3 days as it's back to work monday morning and dealing with defective meatware systems.
NWC, there are other development systems for the Propeller besides SPIN... see here: http://www.parallax.com/ThirdPartyPropellerDevelopmentTools/tabid/252/Default.aspx
I just got my polar transmitter/receiver and I have been looking at the BEEP
on the serial terminal and it is no fun. I have added an LED to blink every time
The receiver received a beep.
Knikula, would you be willing to share your polar receiver monitor source code.
I saw your you tube and it looks great. Or point me on the right direction on what
PWM routine that you use?
Rey
Glad you liked the youtube video, I use that treadmill every other day for an hour, with the Propeller spitting out the PWM signal to the motor driver board at 20Hz 15 to 85% duty cycle...and reading the heart rate...with MonitorPWM.spin
I'm not the best organized programmer (not even 2nd best), but here goes...
VAR
long Stack[260] hrate ' I used a really big stack for the other cogs and stuff
byte Cog 'Hold ID of cog in use, if any
long tHprobe, tlprobe, pulseCnt, ' I don't use pulseCnt for anything... these are global variables, available for any part of the program to have access to...
OBJ
probe : "MonitorPWM" ' this is MonitorPWM.spin from PE Kit 7- Counter modules and Circuit Applications on my PC as c:/parallax inc/propellertool v1.3.2/examples/PEKit/7-CounterModules and Circuit applications
PUB Main | dum1
probe.start(8, @tHprobe, @tLprobe, @pulseCnt) 'HR data input routine Pin 8 is the signal in from the HR receiver board, the function call has to include these variables, in this order, as specified by MonitorPWM.spin object
dum1:= (tHprobe+ tlprobe)/1000 '(time in clock cycles high + time in clock cycles low)reduced by factor of 1000 to avoid integer overflow
hrate:= 4800000/dum1 'hrate is in units of beats per minute , updated for every beat... dum1 is heart rate period measures in 1/80,000th of a second
That's about it...I cut out the treadmill specific stuff, hope I didn't remove something significant...
email me at knikula at yahoo.com if you need more timely help...
pretty easy, hey?
Regards,
Ken
I have the PE kit. I guess time to hit the book again and read up on the counter section.
- reyp