Calculating Heart Rate from the incoming serial data on VISA

[NapDynamite]

---

@Bob_Schor wrote:

Thank you for the video -- it makes it easier to understand what you are doing.  Here are some questions/suggestions:

• What is the sampling rate (or A/D conversion rate) of your Arduino board?  I'm guessing it is substantially less than 1KHz -- could it be something like 100Hz?
• At least while you are in "development" mode, why not plug the USB out from the Arduino into a USB port on your PC and acquire the data directly into LabVIEW?  [I know this is possible -- I played with doing this about three years ago, but found the Arduino unsuited for my task].  As some have noted, this cuts out several intermediate steps that could lead to the loss of data (though, to be honest, your waveform graphs look pretty similar to your oscilloscope readings of the input signal).
• It seems to me that the most logical explanation for "fluctuating rate" has to do with determining when the "beat" occurs.  Thus the accuracy and reliability of your "beat-detector" algorithm might be very important.  The Sampling Rate (see first point) now becomes extremely critical.

To illustrate the last point I made, let's assume that you have a "perfect" signal and no points are being lost.  Let's also assume that your sampling rate is 20Hz (which I made very low in order to illustrate the point I'm about to make).  80 BPM is 1.33 B/s, or 15 samples/beat.  If I have a perfect algorithm, I'd expect to see the samples/beat as 15, 15, 15, 15, which would compute to 80, 80, 80, 80 BPM.  However, if I'm off by even one sample, say 15, 14, 16, 15, I'd compute 80, 86, 75, 80 BPM.

I look forward to learning more about your setup.

Bob Schor

---

Now two aspects can come at play here:

1. The rate at which heart simulator is feeding signal to Arduino.

2. The rate at which Arduino is feeding this signal to PC.

Since Arduino is throwing bytes and 9600 baud rate, let me leave it there for a while.
Coming towards the interface between heart simulator and Arduino, there could arise loads of issues. We also need to know the max frequency at which heart simulator is giving signal to Arduino. And inside the Arduino, there supposedly be a routine, fetching analog signal at some rate. I want to make sure whether the sampling rate defined inside Arduino is same as the the rate at which the heart simulator is feeding out. 

Now since Arduino has a single core for processing, he should also make sure both routines i.e. getting analog signal, converting them to byte + sending bytes to serial I/O of Arduino, are both working in separate loops. Make one loop run as fast as possible while the one with analog signal fetching should run at the same speed the heart simulator is working. 

I hope he gets me point. The above description is an "Anecdote" from my college years. 

[Abuzar]

Friends i dont have PC at the moment so pasting some informative resources 1-  The Arduino uno board uses ATMEGA328P. Details available from the link bekow

https://www.arduino.cc/en/Main/arduinoBoardUno

The pg26 of the controller explains its technical detail.

 The ADC is  provided  with a dedicated clock domain.  This  allows halting  the CPU and I/O  clocks in  order  to  reduce  noise  generated  by  digital  circuitry.  This  gives more  accurate  ADC conversion results.

This is the link of ECG SIMULATOR but unfortunately nothing mentioned about samoling frequency on it. 

http://www.flukebiomedical.com/biomedical/usen/patient-simulators/ps410-multiparameter-arrhythmia-si...

[Dennis_Knutson]

Does this mean you don't remember how you programmed the arduino? You should have programmed the sample rate of the adc to be about 10 times the highest frequency you are measuring. The actual sample rate is what you need in the LabVIEW code. The baud rate is irrelevant as long as it is high enough to transmit the captured data without any loss of digitized signal.

[Bob_Schor]

Hmm, I thought I wrote a post here that said "The information you have given us suggests that you abandon the Arduino and spend a little more on a DAQ system that includes a Sample Clock and an internal buffer", but maybe that was another post today.

My strong suspicion (and I'm happy to be proven wrong about this) is there is no control of the sampling rate -- I'm guessing the code said "Take one sample, send it via Serial Communication, and repeat as fast as you can".

What you really want to do, as Dennis says, is figure out what a reasonable Sampling Rate would be.  For an EKG at 80 BPM = 1.33 BPS, the waveform lasts about 0.75 seconds, so if you sampled at 100 Hz, you'd define the waveform with 75 points, and could estimate time to within 0.01".  Being "off" by one sample (0.01") would translate to an "error" of about 1 BPM, which seems tolerable.  

A DAQ device like the NI USB-6009 (there are similar, less expensive, devices also available) would let you collect 100 samples and then send all of them directly to the PC through its USB port (which takes far less than 1 second), implying a virtual guarantee that no samples are missed, and that the sampling times are known and identical.  You "give up" wireless by doing this, but you get reliability and data you can trust.

If wireless is a requirement, and reliability and confidence in the data are not important, your present design can work ...

Bob Schor

[msmeulers]

well a enet DAQ device has native streaming support and is very reliable in transferring all the data. Only if your connection fails for a longer period of time you will loose data (but the same counts for USB), but at leas you will get an error message. We use this devices at 100 kS/s, very reliable.

I believe you can achieve the same with a microcontroller, but then you need to communicate both ways, so confirm the message. I worked with a device which send the message back you send, but then inverted. But there are better less bus consuming solutions possible. To achieve this you need to pack more data in one message (on the arduino), and buffer messages in the memory. The PC side needs to be fast enough to grab those messages. I'm not sure what is possible on an Arduino but this is what we do on our LV based RT systems, you should be able to achieve the same.

An easy way with the probability in loosing data is to pack 1 second of data in 1 message. Then you are sure that your 1 sec calculation on the PC is heart beats/s. So grab 1 sec on data on the arduino and send this over as one message. This of course if connection is an issue.

Best regards,

Martijn Smeulers

[Abuzar]

Hello friends,

I was out for a visit, i am back now and have started working on your suggestions.

Meanwhile NapDynamite i am attaching the file in 2012 version.

Regards

[Abuzar]

Friends, many of you raised the issue of Sampling frequency at which the ADC is digitzing the data, so i am quoting the complete mathematics that will give you its pic.

The frequency at which the Arduino uno board is working is 16 MHz or 6.25 x 10 -8 sec

According to this http://www.gammon.com.au/adc it takes 13 cycles for the adc to convert the data to digital form.

So 6.25 x 10-8  x 13 = 8.125 x 10-7 sec to this time is taken by the controller to convert the data completly.

Now taking its reciporcal will give us the frequency at which we are having the data so its 1.23MHz

And this is very high frequency, what i conclude from here that my sampling frequency will now be the one at which i am sending my data serially.

If that true than guide me where should i include that frequency.

Regards

[NapDynamite]

Abuzar,

Do us a favor and just write a simple LabVIEW code, with no producer-consumer architecture, rather a simple VISA read enclosed in a while loop with some delay. Check if the data you want is being received over this end. 

Regards.

[Abuzar]

Dear NapDynamite

upto my observations, there is no problem in receiving the data, if you need something to be confirmed still, inform me, i will re make my code and then will run it and will show its results.

But as seen in the video there isnt any issue with the data being received.

Regards

[NapDynamite]

Few debugging steps I would want you to take:

1. Forget about post-processing code. Just monitor the exact data you're receiving i.e. the bytes from VISA read.

2. Observe if they are steady over a period of time or fluctuate.

3. Repeat 1 and 2 for different BPMs from your heart simulator. 

Regards.