Some programing work: Heart Rate Spectrum Analysis Project
May 19, 2010 at 3:08am
Some programing work: Heart Rate Spectrum Analysis Project
I’m looking for someone to do some programming work to share, and would be interested to learn about different approaches to commissioning and tendering of work over the internet – tapping into international networks for people programming for MaxMSP, and approaches to cooperative funding of programming projects.
The idea is to make an open source/CC version of the popular HeartMath or Wild Divine heart rate biofeedback applications – but minus the cheesy displays, and new age jargon!
HeartMath Emwave < http://store.heartmath.org/emwave-pc>
Technically all these apps do is track resonance in heart rate oscilations at around 0.01Hz (6 cycles per minute), that are produced when people engage in very focussed and sustained feelings of appreciation/peacefullness. Sounds crazy – but based on my own experience with these two pieces of software – it does work!!
So the idea would be to either create a Max object that does this – and would let Max folks create emotionally mediated interactives
Its also important to able to test this signal – so some type of inverse FFT that would allow users to feed in test signals and test the responsiveness.
Because heart rate data is irregularly sampled, Lomb-type approaches are recommended. Timing accuracy is critical, so it needs to be independent of the Max scheduler?
Perhaps a much simpler approach would be to convert the heart rate data to audio signal (ULF!) then feed it into a standard FFT/fiddle object – but that means having to wait a long time to fill the sample buffer if you want to measure signals at 0.001 Hz, that’s a long wait (5-10 mins).
I have a modest budget of around $500-1000 AUD.
I’d like to SHARE the completed object/abstraction with others in the interactive art/design/music community – CC, Shareware license or similar.
May 19, 2010 at 10:04am
That sounds like a great idea !
Do you have any medical/technical paper on this heart rate resonance ?
The most difficult part of the programming will probably be the data interface between the hardware device (respectivly the driver/SDK) and max/msp.
Or do you plan to also make the hardware “open source” ? (like openEEG)
Of course, you can simply tape a microphone onto you chest ;)
May 19, 2010 at 3:01pm
Open Source sounds like a good way to go. Ideally it would be separate from the actual acquisition of the heart beats, to allow for a range of heart beat sensing hardware.
Frequency Domain analysis of periodic data (non audio) seems like it could have applications beyond heart rate – I reckon there is lots of potential with gestural interaction (Wii Motes etc.) – tracking repetitive gestures like shaking, spinning, drawing shapes etc.
You could develop a whole library of objects for this fq domain stuff! to filter sensor data/realtime data feeds (pachube etc.)…
I remember a long time ago seeing a book on golden mean, fibonaci, etc, and some investigation into fourier analysis of ballet dancing – harmonic arrangements of wave like gestures etc.
heart RATE variation is what we are measuring here, not the beats per se. This means we are measuring changes in heart RATE – speeding up and slowing down, in time with breathing etc. (hence the 6 breaths/cycles per minute).
Because we are measuring heart RATE, the accuracy of timing is critical, so you need a signal that is clean enough to give you a reliable beat. There are many ways to get this, so I figure to make it as useful as possible – to let other people sort this side of it – they just need to supply a BANG for each beat, then ‘our’ software measures the amount of time between each beat (known as the Inter Beat Interval or IBI for short), and an analysis of these changes in the frequency domain, resonance at 0.01 Hz and a few other variables.
Re sensor hardware and acquisition,
I’ve used Vernier wireless heart rate sensors in the past, but unfortunately they use a noise filtering algorythm that effecctively quantizes/down samples the heart rate data – when you put it into Fq Domain analysis – the high fq components are very weak.
ECG/EKG is good but requires lots of prepping. The very popular and affordable Polar sensors, again, use lots of filtering to for noise reduction – so dont provide realtime data (its averaged out and resampled).
I’m planning on using Pulse Oximetry (infra red pulse plethysmograph) like what they put on your finger in hospital – not good in cold weather, but easy to connect, and provides realtime, analogue signal to work with via Phidgets USB interface. Stethoscopes are cool, but to noisey to extract reliable heart RATE data. A combination interface would be cool – but that’s a separate problem!
I have a load of papers that I can share with interested people, but its not appropriate that I post them here!
I also have some code written for me that is almost complete, but the programmer is too busy to work on it any more – its written in UNIX, and uses a LOMB type analysis method, which seems the recommended way to go these days – if you are working with irregularly sampled data.
Apr 27, 2011 at 11:23am
I’m starting a heart rate monitoring project for my dissertation and i’d be really interested to read the aforementioned papers. Also i’d love to hear from anyone that has got a decent heart rate signal going into Max.
Jun 1, 2011 at 11:40pm
‘Decent heart rate signal’ depends on what you what information you are looking for. Check out the collective I’ve uploaded to my website – it uses a basic IR plethysmograph, connected to Arduino – then FTDI > USB > Serial port in Max > then lots of signal conditioning, schmidt triggers etc. Its still far from perfect, and there are lots of tricks for building robust plethysmographs with greed and IR lights etc.
There are also HR kits available from SparkFun for listening to Polar heart rate monitors, but you wont get individual beats out of it, just average heart rate or *average* interbeat interaval in ms
Jun 2, 2011 at 7:38pm
There is a workaround for getting a raw heart rate signal from the Sparkfun Polar Heart Rate Monitor Interface. It’s described in one of the posted comments on the Sparkfun web page for the product. We had one in-house for testing for awhile, and the method seemed to work, but it appears to have a potential error as high as 60ms. for each interbeat interval. Since I was planning to use it in a clinical setting, I wanted greater precision.
So, I found another way. There is a pin on the receiver chip on that board that provides a 1ms. pulse on each heart beat. You can hack into that, bring the signal into Max on an audio line, and process it just as you would an audio click track.
Anyone handy with electronics can simply buy the receiver chip from Sparkfun and build an interface without the more expensive board. I’ve built a couple and they work well when the person being monitored is relatively motionless. Things get a bit more complicated for both ECG and plethysmography when the person is moving.
Jun 2, 2011 at 7:58pm
take a look at this project if you want to implement it in java
Nov 18, 2013 at 4:03pm
I also have the wilddivine box but never figured out how to use it with different software.
Nov 19, 2013 at 3:32am
I’m not sure what you are measuring: the pulse trace (i.e. the “ba boom” or ‘whosh” rhythm)or variations in the time between pulse intervals (Heart Rate variability aka HRV) – they are very different data.
My focus is on Heart Rate Variability – which means you need to use a Schmidt trigger to detect a reliable and accurate ‘beat’ for each pulse period i.e. trigger a bang , then measure time in milliseconds between bangs – this is the inter beat interval (IBI) – that the HRV pattern is calculated from.
Here’s a link to the app that was developed for OSX that runs from the Terminal (runs on OSX 10.8), using LOMB method to obtain spectrum analysis:
You need to send it an OSC pulse message “/heart/pulse/1 1″ and then parse the OSC incoming messages from the terminal app.
All the best George
Nov 19, 2013 at 3:43am
You must be logged in to reply to this topic.