Calculating Heart Rate from the incoming serial data on VISA

[NapDynamite]

Bob,

Personal experience. Using such techniques as this guy is employing would also need you to worry about both software application and hardware too. One wrong division with wrong resolution can create havoc. Probably could make you lose your PC. 

[Bob_Schor]

---

@NapDynamite wrote:

Bob,

Personal experience. Using such techniques as this guy is employing would also need you to worry about both software application and hardware too. One wrong division with wrong resolution can create havoc. Probably could make you lose your PC. 

---

... or even worse, your heart ...

BS

[NapDynamite]

[msmeulers]

Hello Abuzar,

attached are the 2013 versions.

From timing perspective: you need to be sure that your microprocessor is sampling with a high time accuracy, and that you don't lose data between the processor and the PC. This can also create inacurracies in the heart rate since we are looking to beats per second.

Like Dynamite said: with a NI DAQ device you are ablo to stream data to the PC with high time accuracy, or it is even possible (with some devices) to count pulses directly with the DAQ device.

Best regards,

Martijn 

[Abuzar]

Thanks Bob here is the details of my project.

/ Did you see my earlier post?/

I am installing the biomedical toolkit and will let you know about it.

/ I'm curious about the data you are acquiring.  It appears that you are getting single bytes (your Byte Count is 1) from some device and processing it in your Consumer loop.  I understand that your device is running at 9600 Baud, which means you are getting about 960 Bytes/second.  What are these data?  Are you acquiring an analog signal (at roughly 1 KHz) representing an EKG?/

Yes i am getting an analog signal being digitized and send on UART. I have not sampled the data as you can see and just presented it on Waveform Chart. So its an anlog signal of EKG which is digitized on 8 bit and then sent on Serial Port.

/ What are you trying to do in the Consumer loop?  I can see your code, of course, but I cannot "read your mind" to decide what it is you are trying to compute, particularly with feedback loops, multiple shift registers, creating arrays, and doing Statistics.  A verbal description of your intended algorithm would be helpful.  Note that without knowing what the data represents, it is impossible to make any assessment on the validity of the code in the Consumer loop, even if it were more transparent./

I have labled my diagram and attached it for your reference.

/   A word about Queues -- the Consumer loop does not need to carry the Queue in a Shift Register, and doesn't need to bring it to the right-hand shift register terminal.  A Queue wire is a reference to the Queue -- once the Dequeue function reads it, it knows everything it needs to know to use the Queue./

I have followed the example of Producer Consumer loop at ni page. I will try the changes you mentioned and inform you.

Thanks Bob Schor.

[Abuzar]

Dear all friends especially Dynamite

Pls watch the video on the below link in which i have completly described my project.

http://www.dailymotion.com/video/x32bsxx

Regards

[NapDynamite]

Abuzar,

Please post your VI in LV12 version for me to see.

Thank you. 

[NapDynamite]

Abuzar,

I managed to watch that video you posted. Seems to me that you're acquisition is perfect but your 'processing' has gone nuts. I have doubts over the "maths" you're trying to solve here (particulalry over those shift registers). If you could post your VI again in LV12 version, I could have a look.

Regards.

[msmeulers]

Thanks for the video Abuzar,

With the video in mind, in my opinion, it is more and more advisable to check if you are getting all the data from your micro controller, or is your microcontroller grabbing all the data? But first things first, I would suggest to check all the links between you and the microcontroller.

- Maybe it is best if you can see if (for test purpose) you can leave the zigbee part out of the setup and see if all data is coming through.

- It is also maybe an idea to let the controller just generate an increasing counter at the same rate you are reading the analog input and see if you are getting all the samples

I don't think there is a way in this set up that you can guarantee you are getting all the data and with that exact the correct result. It is maybe possible to increase the size of the serial messages and pack more data into one message. But again this is only reducing the chance of loosing data. Again I am only guessing here and this is something you can just use to trouble shoot.

Good luck!

Best regards,

Martijn

[Bob_Schor]

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