Shop OBEX P1 Docs P2 Docs Learn Events
Creating Polar Heart Rate Receiver Object to submit to Obex — Parallax Forums

Creating Polar Heart Rate Receiver Object to submit to Obex

rwgast_logicdesignrwgast_logicdesign Posts: 1,464
edited 2013-04-29 15:45 in Announcements
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.

Comments

  • borisgborisg Posts: 39
    edited 2013-02-11 01:50
    Still waiting for my Micromedic contest kit to come in, but the Polar HR monitor seems to be about the simplest device to interface to. From the documentation, it sends a pulse to the receiver every time it picks up a QRS complex and it's just a matter of picking up that pulse and timing it. The first thing that I did was to write a 1 msec timer which will be used to time all events coming into the system and HR is one of the easiest to time given that one is dealing with an inter-event interval of some 250 -2000 msec (very fit individuals do have heart rates of 30 while sleeping).

    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).
  • JDJD Posts: 570
    edited 2013-02-11 11:53
    @rwgast_logicdesign - I have the polar sensor receiver and it works super simple as borisg stated. Just wipe the sensors on the band with a damp towel when you start, and program the controller to watch an input pin.

    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.
  • WBA ConsultingWBA Consulting Posts: 2,933
    edited 2013-02-11 13:09
    I would suggest reading the datasheets and manual for Dan Julio's Polar Heart Rate Monitor Interface (HRMI) that is sold through Sparkfun as P/N SEN-08661. He has some explanations about the Algorithms he uses on page 22 of the manual and also has some example applications on his site. I was looking at his module when I was thinking of adding a Polar receiver to my plungelogger. Haven't done it yet, but I have harvested some pointers from his expertise:

    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.
  • borisgborisg Posts: 39
    edited 2013-02-12 20:34
    Just got my MicroMedic contest kit today and so much for any thought of sleep tonight. Have the week off and last night put an accelerometer and SD data logger on a Propeller development board so finally have portability!!

    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.
  • WBA ConsultingWBA Consulting Posts: 2,933
    edited 2013-02-12 23:43
    Good feedback on the heart rates, I was just using typical heart rates from wikipedia. As far as the chest strap, the batteries are replaceable for some models and it appears to be the case for this model according to this page on the Polar site. It should last a few years. I have an HT1 that is 3 years old and still works great.

    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?
  • borisgborisg Posts: 39
    edited 2013-02-14 02:10
    As Joshua has noted, the Polar unit is very easy to use. Now sitting here typing while watching my heart rate interval data stream into my laptop. As the documentation notes, the pulse width is 15 msec and that's exactly what I'm finding. So far haven't been able to make it miss beats except by walking far enough away from the receiver (seems to pick up signal within 10' or so). Next step is to do what Andrew suggested and that's to build an EKG amplifier and compare the two signals. Approaching the EKG amplifier with a bit of trepidation as I tend to be far better at digital electronics than analog circuitry. I've made EKG amplifiers in the past but that was when I had access to good quality oscilloscopes whereas now my "oscilloscope" is a Phidgets 1 KHz A/D converter which displays a signal on my laptop. Am actually at the point where I'll be able to do sleep HR monitoring tonight together with my pulse oximeter to figure out how the pulse oximeter calculates heart rates.

    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.
  • rwgast_logicdesignrwgast_logicdesign Posts: 1,464
    edited 2013-02-15 17:10
    I know this sensor is simple and that is why I chose it, the point was to make an easy interface that could run in the background, independent of your main code. It was also to just add some stuff to find the average rate per 60 seconds, determine the time between a falling edge and rising edge, for real time averages etc, etc.. Ive gotten a bit side tracked lately with a few other projects, and my partner on this has been dealing with a bunch of car issues and insurance company's, thank god that is over for him when his car is back, already been to the shop 3x and broke down 6 hours later each time. Gotta love when a drunk driver hits you and the insurance co, trys to screw you every way possible.

    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?
  • borisgborisg Posts: 39
    edited 2013-02-15 17:50
    rwgast_logicdesign, have spent a couple of days now playing with the Polar transmitter and, aside from moving out of range, it hasn't given any false beats that I could tell. What you may be seeing is either premature atrial contractions (PAC's) or premature ventricular contractions (PVC's). The pattern I've found (and I've been ingesting far too much caffeine lately) is that of a short interval followed by a long pause. The sum of the short interval and long pause is about double a usual RR interval. I'm assuming these events are PAC's as I can feel PVC's when they happen.

    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.
  • NWCCTVNWCCTV Posts: 3,629
    edited 2013-03-29 16:43
    So I got to reading this example applications on his site. as suggested. Is this same thing even possible with a Stamp? If not I can switch over to the Prop but how do I program the Prop in C without having to recreate the wheel? I am new to Spin but have coded in C and C++ in the past but it has been a while. Has anyone maybe made an OBEX yet or Stamp version by chance? Also, can the Prop be programmed with Visual C or C++?
  • knikulaknikula Posts: 26
    edited 2013-03-29 23:43
    I used the PWM monitor routine from the SPIN library, which makes use of one timer. It gives you the time in clock cycles that the signal is high, and the time in clock cycles that the signal is low. I add those together to get the period of the heart rate. Works pretty good to give a decent heart rate. I use mine while running on a treadmill, and if you are a heavy sweater, the strap can move around and give some erroneous readings. I also have an occasional PVC issue, and it shows up as the quick beat, and then the looong beat. I can also feel it. The receiver that I'm using picks up EMI from the treadmill, and from my TV...so that requires some interesting receiver placement.

    NWC, there are other development systems for the Propeller besides SPIN... see here: http://www.parallax.com/ThirdPartyPropellerDevelopmentTools/tabid/252/Default.aspx
  • Reyp2000Reyp2000 Posts: 10
    edited 2013-04-10 02:55
    Did anybody submitted an object code to OBEX?

    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
  • knikulaknikula Posts: 26
    edited 2013-04-13 19:55
    sorry it took so long to get back at you...somehow I should be able to get email notifications from here...gotta dig that PWM info back up...
  • knikulaknikula Posts: 26
    edited 2013-04-13 20:39
    Reyp,
    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
  • Reyp2000Reyp2000 Posts: 10
    edited 2013-04-15 01:54
    Knikula, thanks for sharing. Ill have to try it tomorrow night. I need to finish my taxes till yet.
    I have the PE kit. I guess time to hit the book again and read up on the counter section.

    - reyp
  • rwgast_logicdesignrwgast_logicdesign Posts: 1,464
    edited 2013-04-15 11:54
    Im sorry I just saw that this thread had been updated, I am glad kinkula was able to help out! I started writing a driver because I wanted a dedicated cog to monitor the heartbeat, using waitpeq, and I planned to add a bunch of different functions to average the heart rate depending on the accuracy needed vs the time allotted for samples. I basically got some code running monitoring the sensor in it's own cog, I would say what I have done is no more interesting than the beat example. I've been distracted with other projects lately, and unfortunately I may have to change my whole micro medic idea due to my partner bailing, in which case I won't even need to monitor heart rate. Once I get a chance to stop building hardware and start writing code again I do plan to finish up what I have, because the base code is actually useful for any application where pulses need to be counted. It just has not been a pressing matter since I might not even need the sensor now.
  • Invent-O-DocInvent-O-Doc Posts: 768
    edited 2013-04-29 15:45
    Saw an interesting item on Sparkfun's weekly new product page - they have a muscle twitch sensor with microcontroller interface...
Sign In or Register to comment.