01-28-2010 10:42 AM
Hi. I am having a little trouble with measuring the phase difference of two sine waves.
The sine wave signals are; one simulated in LabView (and sent to an ultrasonic transmitter which in turn sends the signal to an ultrasonic receiver), the other is the sine wave acquired from an ultrasonic receiver.
My program appears to be able to measure the two phases and determine the difference, the problem is that the phase of the acquired wave is constantly changing (and quite radically too).
If it is essentially the same wave being sent and received (only the received is delayed, due to distance between sensors and therefore there should be a constant phase difference?)
I have attached my program (LabView 8.2 although I have 8.5 available to me as well) could someone take a quick look at it to see if everything is in order?
If anyone can offer any ideas as to why the phase measurement of the second wave is changing so rampantly it would be greatly appreciated.
Regards
01-29-2010 10:04 AM
01-30-2010 10:47 AM
Hi. I initially had the inputs and outputs in seperate loops, however when I attempt to bring the signals (phase) from tone measurements outside the loops to a common area, where I can subtract them to find difference, I get no readings. Is there a specific way to send the phase measurement, or any signal outside a loop.
I am working on this as a part of my final year project in college, however there is nobody here who is experienced in LabView the only instruction I received for send and acquiring signals was to us DAQ assistants. Can you point me to some literature on alternatives (the more effective programming you mentioned)
Thanks
01-30-2010 06:00 PM
02-01-2010 04:34 AM
You need to syncronize the output and the input of the DAQ, otherwise you will have a phase difference between both and hence no correct phase difference between transmitter and receiver.
A simple way to do it will be to read the output back via a second channel. Setup yor ai task for both channels and use these to extract the phase.
Better but more complicated would be to use the DAQmx functions instead of the Express VIs and syncronize output and input via shared sample clock and common trigger.
Also note that there are better ways to measure the phase difference (you introduce some error/noise by allowing any frequency in both evaluations, where it is physically the same frequency).
Felix
02-01-2010 06:14 AM
Hello JacktheLad,
Express VIs are simple to configure and use in your VI, however, each time they are called, they introduce a larger amount of overhead head than lower level VIs. When trying to accurately measure phase difference, this general overhead, along with your single loop architecture, this could introduce errors.
At the moment you can try and improve the current VI by implementing two good practices.
I have used the Error Cluster (Green wire) between the Analog Output and the Analog Input. This ensures that the Data is read into your VI after you have been able to output. Furthermore, without Execution timing, your while loop will try to run very quickly. A 100 ms iteration delay on the while loop will help.
A good example of synchronized Analog Input and Output with lower level VIs can be found in the LabVIEW Example finder
Run LabVIEW
Regards,
02-01-2010 07:40 AM
02-05-2010 04:42 PM
I recommend measuring both signals. If you do, you eliminate a source of error. Another source of error will be the delay between the sample of each channel (if you are not using a simultaneous sampling DAQ card). This could be significant if the phase difference you are measuring is very small.
02-08-2010 02:44 AM
Two things:
In most cases you only need to trigger the output and can assume (and test) that you only need to measure the source phase once.
Take a look at SAM (sinus approximation method) to measure phase. Basically it's a 3 (or 4) parameter fit
y(t) = a*sin(w*t) + b*cos(w*t) + c
a,b,c are the parameters (phase = atan(b/a)
w might be a parameter to fit, if greater or constant doppler shift is expected, otherwise it can be set to w_source
y(t) don't have to be equi-distance samples but should cover at least a half periode . You will find that, as better your input SNR as fewer point you will need.
I attach a quick and dirty prove of concept for a 6 parameter fit (two tones or one tone with hum) I made as a starting point