Analyses on single point data signal

[johnsold]

You say you did not get the result.  What did you get and what result did you expect?  Does the Graph show your waveform?  How many points of data are accumulated?  How fast does the outer loop (not shown) iterate?

I suspect that  part of the problem is that when you convert the array to dynamic data, you do not provide any timing information to the Tone Measurements VI.WIthout knowing the sampling rate it will make some assumption (probably 1 sample per second) and use that determining the frequency.  Unless the default sampling rate happens to match your actual rate, any frequency will be wrong.

This programming is not magic.  The VI only knows the information available at its inputs.  The amplitude data is there but not the timing data.  Also, the first time through the loop there will only be one point.  The second time there will be two points.  It will take a while to accumulate enough data to make a meaningful measurement.  

Lynn

[Getwonder]

Thanks,

Kindly inform me how to mention the sampling rate.

Thanks

[johnsold]

Actually I have no idea of how to tell the Express VI, which uses the Dynamic Data Type, what the sampling rate is.  I almost never use the Express VIs because they hide so much of the functionality that it is hard to tell what they are doing.

I would likely use the FFT.vi and calculate the frequency bins externally or use the Extract Single Tone Information.vi.  The latter uses the Waveform datatype which is just a cluster and can easily be manipulated to include the sampling rate (dt = 1/fs).

Lynn

[Getwonder]

Thanks johnsold.

Same condition.

I think that i have to convert the orange wire into the brown i.e array into time signal. 

Can you suggest how it could be done.

[Getwonder]

Can you guide me how could i decide the 

fs

when using in a bandstop filter

i want to remove signal in the array in the range of 45-55 Hz

i have am using buttorworth filter with

fl= 45

fh= 55

fs= 105

order = 10

but unable to remove signal in this range.

Thanks

[johnsold]

If you are still using something like the image posted in message 3 to collect your data, your sampling rate is approximately 1/(Delay 1 + Delay 2 + communication time).  It is highly unlikely that you are actually getting a 105 Hz sampling rate.  Also your sample intervals are not going to be equal because the OS latencies in calling the serial port will vary from call to call.  Unevenly sampled data cannot be meaningfully processed by standard filters or Fourier transforms without resampling.

The image here shows how to combine the data array and the sampling frequency fs into a waveform.

Lynn

[Getwonder]

Thanks very much again.

Kindly guide me how to address the following problems.

1- The data has been taken as serially thorough com port and then joined to create a 16 bit. The delays are kept to allow the controller read the data through ADC so that communication errors could be avoided.

2- This is a continous process and i have to perform the analysis simultaneously.

3- How to handle the serial communication issues (that you wrote).

4- Also the noise that is present in the signal is of 50 Hz. And the baud rate is 19200. So i think that this will also a problem of not getting the noise signal accurately by the PC so that it could be removed. 

5- All the analysis should be done in the while loop in which the signal is Acquired and plotted on the graph.

T.C

[johnsold]

Here are some ideas.  I am missing some information so these may not work.

1. How long are the delays?  How many bytes are sent by the VISA Writes?

If each command is one byte, then your timing looks like this: Time for one cycle = Delay 1 + 0.5 ms (Write 1) + OS latency + 0.5 ms (Read 1) + Delay 2 + 0.5 ms (Write 2) + OS latency + 0.5 ms (Read 2) + calculation and display time.  The 0.5 ms is the approximate time of one byte at 19200 baud.  You have no control over the OS latencies or the display time.  If the delays are each 1 ms (the minimum non-zero delay), you are down to ~250 Hz sampling before accounting for OS latencies.  Displays usually update about 60-80 times per second.  Writing to the indicator more often than that is wasteful.  The user cannot perceive changes faster than about 10-20 per second.  Writing to the indicator faster than that is meaningless.

2. 3. See comments below.

4. It is always best to remove the noise as early in the process as possible.  Differential amplifiers preceding the analog to digital conversion are best. As I said in previous post, you appear to have two problems with the analysis and noise removal issue: Your sampling may not be fast enough and the sampling is not uniform in time.

5. Is this a requirement?  Often the best approach to this type of project is to separate the data acquisition from the analysis and display using tow parallel loops.

Comments: If the remote system can be set up to acquire data periodically and store it in a buffer, then the serial communications timing issues go away so long as the average communication rate is greater than the sampling rate.  If you must use software timing, I think you will never be able to get good enough results to successfully remove the 50 Hz interference.  Look at the Producer/Consumer Design Patterns which come with LV and the many discussion on this Forum about the topic.  Make the serial communications be the Producer and the data processing, analysis, filtering, and display be the Consumer. 

Lynn

[Getwonder]

Thanks johnslod for continuous guidance. And sorry for replying late as I got busy in some other matters so not getting time to write.

Wel here are the answers of it.

1-      Background Behind introducing delays and Write command

As you know that I am transmitting 16 bit data serially. So there some time occours error of misinterpretating the first and second byte of the two 8 bit data. To get out of this problem, I introduced the write command which sends the first or second bit when the data is written.

Now the delays:- The delays are introduced to so that the sampling time may be overcome and the data has been collected by the controller. Because it was also creating a problem of read write error. So a delay of 0.001 has been placed

Q :-  How did you calculated the delay of 0.5ms?

2-      +3 The device sending the data is working in a continuous mode. It collects the data from the ADC and transmit it to the PC.

4-      Removing the noise in analog part is quite difficult technique especially when the signal is in mV. I have already tried it but was not succeeded in cleaning it completely. So that I decided to try LabVIEW’s efficiency to do this.

5-      As the process is going on continuously how could I separate the Data Acquisition and Data Processing.

Thanks a lot again.

Take care

[Drew_T]

Intelligent,

It seems that you and johnsold have been conversing extensively over this topic, but since they have yet to reply, I will attampt to jump in and provide some help.

1-Have you tried using johnsold's method of calculating sampling time?  It seems from previous posts that your data is not evenly sampled, and like they said, this is important during analysis.

Q-As far athe the read/write delay of 0.5 ms, johnsold answered that in their previous post:

---

@johnsold wrote:

The 0.5 ms is the approximate time of one byte at 19200 baud.

---

2/3-I understand that the data collection is continuous, but if you use a buffer, it will reduce the chance of data being lost.  I suggest you look into this if the remote system is capable of it.  Buffering Data.

4-I would agree with johnsold that removing noise early is best, but it is your perogative.

5- johnsold is right about the parallel loops to collect and process data.  Even if the data is being read continuously, a producer - consumer loop structure will allow you to pass data from one loop to another, continuously.  There are also plenty of examples in the LabVIEW example finder for this architecture.

Good luck!

Drew