respiratory rate

[burcu]

Doesn't indice 0 respresent the x value and indice 1 represent the y value ? Thus we calculate the difference between these two indiceses which is x-y?

[chilly_charly]

Burcu, you missed something : there are also values for index = , 3, 4, etc...
Indices is an ARRAY, with n elements, where n is the number of peaks.
To visualise more easily the values, you can expand the "Indices" indicator, as shown in the jpg.

CC

[burcu]

Ok,
I'm sending indices now.

[rpursley8]

Your Indices variable should contain the index (x-axis) of every point in your array of data that meets the input criteria (threshold and width). So the number of elements in your Indices variable should equal the number of peaks in your data. Now to get BPM you want to find the difference between adjacent peaks which should be adjacent elements in your Indices array.

[rpursley8]

Here is a front panel of a working program and how your results should look.

[rpursley8]

Here is the block diagram used to generate the front panel.

[chilly_charly]

Burcu, Randall
The origin of the problem is simple : the peak detect vi is not fed with a sufficient number of data !
Look at the results : there are only one or two values in the indice array, whatever the number of peaks in the display. The confusion is due to the fact that Burcu's vi is working with real time data, while Randall and I have been discussing file data or graphic display data (a chart displaying time-stacked data).
In order to work properly, the peak detection algorithm should be fed with at least two peaks. That's not the case here : the vi takes 1300 pts on 3 channels = 433 pts for BR, at a rate of 440/3 = 147 samples/s. Accordingly, less than 3 seconds are recorded at each loop iteration !!!!

Possible solutions to the problem :
A: adapt the actual program
A1/ increase the number of samples, to be sure to get at least 2 peaks (BTW, forget the first peak, and use only peak 1 and 2 : means that you have to record 3 peaks = 15 seconds of record = ask for 6000-7000 pts.
A2/ keep the same sample number, but decrease the sampling rate (BTW Burcu, you are absolutely right with your concern about the sampling rate of ECG data: the sampling frequency is already too low !)

B/ change the algorithm to be able to compute the BR from a series of data acquisitions.

I think there is not enough time for Burcu to rewrite completly his program (sol 3), so the best solutions are 1 or 2. Solution 2 will make things even worse for ECG.

CC

[burcu]

Charlie,

You are absolutely right! You solved my problem.I set the number of samples to 6600 and sample rate to 750. I've changed 440 to 750 because I could't see any ECG peak values at 440 with 6600. At the worst case there is always two peaks values for breathing.Thus, I had to take 0 and 1 values for breathing.Due to the fact that I'm acquiring 6600 samples at 750 it takes 8,8 seconds for each iteration and data comes very slowly to the chart.Thus, it is hard to say that this is a real time acquisition but this solved my problem in the best way.
You can see the acquired data and last modified version of vi enclosed.

I don't know how to thank you Charlie.You saved my life again.

By the way thanks for your effort Randall.

[burcu]

Here is the modified vi.

[burcu]

Here is the modified vi.