|
Data Acquisition
I am experiencing crosstalk. Should I be angry?
<Chris Regier chris.regierATni.com>
(Timeless)
Crosstalk is the influence of one channel on the measurement of another channel. Therefore the signal of a channel may be influenced by its neighbouring channels and vice versa.
Crosstalk behavior is not surprising at all, and is common to all DAQ boards with a scanning front end. Scanning works great under the right circumstances, yielding highly accurate results at low per-channel cost, but it can cause all sorts of problems under certain conditions. To explain what is happening; there is capacitance at the output of the channel multiplexer on the DAQ board. DAQ board manufacturers don't put capacitors there, it comes for "free" as an undesired effect in the multiplexers, PGIA, and board layout. Anyway, when you scan, the voltage on one channel gets stored on the capacitance and transferred to the next channel in the scan. If the impedance of the source on the second channel is not low enough, the source can't charge the capacitance to its value in its allotted time, and you get the crosstalk effect.
(back)
Is there a workaround to the crosstalk problem?
<Chris Regier chris.regierATni.com>
(Timeless)
There are several things you can try. First, don't scan any faster than you have to, and set the interchannel delay as large as you can tolerate. I'm not sure what value of interchannel delay NI-DAQ picks for you as a default, but I know you can change it easily by wiring up the appropriate control. Obviously, don't scan at all if you don't have to. Second, use low impedance sources. Try to stay under 1 kohm. Third, scan a grounded channel between your other channels. This will discharge the capacitance, and virtually eliminate the channel coupling. However, if your source impedances are too large, your channels still won't read correctly, since they'll still have to charge up that capacitance. This method also costs you one channel and half your speed.
(back)
How should I measure the relative phase between two noisy signals?
<Paul Sullivan PaulATSULLutions.com>
(Timeless)
Usually the best way to measure phase angles between noisy signals is the CrossCorrelation function in Analysis >> Digital Signal Processing. Crosscorrelation (whether by this VI or any other means) uses ALL the data at ALL phases to determine the relation between the two signals, so its signal-to-noise ratio improves as the square root of the number of samples processed. No fancy sampling near a single site (peak or zero crossing) can match this S/N. And crosscorrelation works even for signals that are wildly non-sinusoidal.
In fact, it is a good general rule to use as much data as possible in ANY measurement. For instance, use rms measurements to determine the relative amplitudes of two noisy signals, autocorrelation to measure frequencies, etc.
(back)
Is there a way to scan SCXI 1100 or 1102 channels out of order?
<Ted White twhiteATdateppli.com>
(Timeless)
There is a hardware limitation on the 1100 and 1102 cards that only allows you to scan contiguous channel lists. You must scan this way but you do not have to read all the channels. If you use the "Channel to Index.vi" (from the "Calibration and Configuration" palette) and "AI Buffer Read.vi" (from the "Advanced Analog Input" palette) you can read a subset of the channels that have been scanned.
(back)
Why do all the Fieldpoint examples not use FP Read. Should I FP Advise someone?"
<Aaron Gelfand>
(May 2002)
This question was posed: "I'm doing some FieldPoint work and in perusing the examples I became
curious. Most of the examples show reads from FieldPoint using the FP Advise function even though a read function is available. Does anyone know if the Advise is better for reading the I/O and why?"
and Aaron Gelfrand from National Instruments replied:
Actually, at this point we have been re-writing the majority of the examples to use the FP Read.vi rather than the FP Advise.vi. There is a simple fundamental difference between the two although they can often be used interchangeably. The FP Read.vi is synchronous and the FP Advise.vi is asynchronous (and can be trickier to use).
What does this mean in terms of use? Let's illustrate by creating a system consisting of a computer with LabVIEW, an FP-1000 (a serial network module) and an FP-AI-100. We create a program that starts with an FP Open.vi, a FP Create Tag.vi and then in a while loop, we place a FP Read.vi. Also, in the loop, we need to place a delay timer such as wait until next millisecond multiple. If we give our timer a 500 ms value, then every 500 ms, the loop will execute. When the loop executes the FP Read.vi, the read calls into the FieldPoint Server which in turns polls the FP-AI-100 using the !G optomux command (see the FP-1000/1001 Progammers Reference Manual for information on the Optomux protocol used by FieldPoint Serial modules). The FP-1000 responds to the poll by reading the FP-AI-100 and sending the data back. Then the server returns the data to the FP Read.vi which passes it to your chart (or whatever you do with the data). The key thing to note here is that the command sent to the FP-1000 is only sent each time the FP Read.vi is executed.
Now, let us create the same program using the FP Advise.vi. Using the FP Advise, one parameter that we give it is Advise Rate. The Advise Rate causes the FieldPoint Server to set up an asynchronous callback that occurs automatically at the advise rate. So we start our program and the FP Advise (on the first iteration) starts the callback. What now occurs is that the FieldPoint Server polls the FP-1000/FP-AI-100 at the specified advise rate automatically. Whenever the poll occurs, the FP Advise.vi is notified. So how exactly is this different? Well, for one, we no longer need a delay timer in our loop. The FP Advise will always trigger at the advise rate (note: it may be slower depending upon the number of channels on the system). Additionally, we now have the option of having the FP Advise.vi returning data on data change only, allowing you to put the while loop to sleep while data is not changing. In other words the FieldPoint Server is polling the module but your LabVIEW VI can be asleep allowing more processing power to be used by other parts of your program.
So, when do you use the FP Read vs the FP Advise? The general rule of thumb is to use the FP Read.vi when you are newer to FieldPoint programming, if you need to multiplex FP Refnums (for example create an array of Refnums, then use a For Loop to index the array), or when you will have multiple FieldPoint accesses in a single loop. The FP Advise.vi should generally be used for individual loops that should be put to sleep for specific intervals where there is no additional processes in the loop that will be adversly affected by the timing of the FP Advise or the On Change option.
Since the FP Read.vi is easier to use and less prone to being misused, we decided that the basic examples should illustrate the use of the FP Read.vi and that more advanced examples would demonstrate the proper use of the FP Advise.vi.
(back)
|
