NI-USB-6259, multiple analog inputs (voltage)

[tushar1209]

Greetings,

I am working on a project measuring pressure sensor voltages across multiple channels using a NI USB-6259 DAQ. Specifically, I am using PCB 113B22 sensors (see attached manual) distributed 12 inches apart along a tube.

To control the timing and sample rates, I coded the DAQ logic in LabVIEW using the DAQ Create Channel, DAQ Virtual Channel, and DAQ Timing rather than the DAQ Assistant. However, the analog input signals appear to stack on top of each other during acquisition (see screenshot) - which should not occur given the spatial distribution of the sensors.

To troubleshoot, I wrote simplified LabVIEW VIs (attached) to visualize the signals. Yet even here, the pressure peaks align perfectly over time when they should be staggered if the pressure wave is moving at 1 inch/ms.

Before assuming hardware failure, I wanted to check if anyone noticed any issues in my logic or setup that could explain this phenomenon. Could something in my DAQ configuration or timing cause such simultaneous measurement across spatially separated sensors? Or might you otherwise have any tips for troubleshooting the odd synchronization of distinct pressure signals?

I greatly appreciate any insights or assistance with this puzzling behavior. Please find my code and output image attached. Thank you for your time examining this issue - I'm happy to provide any other details that may be helpful.

Regards,

[ZYOng]

Looks like a crosstalk issue. 

Try How Do I Eliminate Ghosting from My Measurements?

[Michael_Munroe]

Your charts lack the resolution to quantify your problem.  The charts show a 5 second window with only 2 seconds of actual data.  You expect to see a 12ms separation of the pulses, which is only 0.6% of the data.  Please zoom into the charts to show only 0.1 seconds of time.  Enter the start and stop times to get the alignment exact.

The diagram show a differential connection, which is great. Confirm the differential wiring for each channel as AI0/8, AI1/9 and AI2/10.

The 6259 samples at 1.25MHz multiplexed.  So there is almost a 1us skew between the readings.

[tushar1209]

Hello Michael --

I appreciate the swift response and pinout resource. For additional clarity, please find attached a 0.1-second zoomed view of my signal output.

Based on your expertise, would you have an example demonstrating how to properly align sensor start and stop times in the DAQ configuration? I want to ensure timing accuracy across spatially separated sensors.

If helpful, a mock screenshot or snippet walking through settings for channel-specific delay values would be tremendously valuable for my learning. What sequence of logic blocks or property adjustments can correctly introduce sensor offsets?

I aim to acquire pressure waveforms at three precise locations (for now) along a tube with 1 inch/1 ms wave propagation. The sensors are 12 inches apart - so seeing three staggered peaks is ideal. Please let me know if further elaboration would benefit this end goal or any other aspects.

Thank you again sincerely for lending your knowledge to illuminate where my timing logic may fall short. I look forward to your insights on how best to structure the start/stop synchronization across channels.

Thank you!

[tushar1209]

Hello ZYOng --

I greatly appreciate the swift guidance on implementing proper channel offsets. I will work to integrate your recommendations into my code today and observe if it yields the intended staggered waveform behavior.

If any issues persist after applying the timing sequence you outlined, I will document the problem in detail and reply here for additional troubleshooting. After following the steps you described, screenshots of erroneous outputs would likely offer the most clarity.

[Kevin_Price]

Is this a pressure wave propagating in air?  A quick lookup of the standard speed of sound sets it at more like 1 foot per msec rather than 1 inch.  So your 12 inch spacing corresponds to more like 1 msec, not 12.

-Kevin P

[tushar1209]

Hello Kevin,

I appreciate you clarifying the experimental setup. Currently, one end of the tube is open, while a spark at the other closed-end generates the pressure wave. Four sensors are distributed:

Sensor 1 - 2.5 ft from spark
Sensor 2 - 3.5 ft from spark (1 ft away from Sensor 1)

Sensor 3 - 4.5 ft from spark (1 ft away from Sensor 2)

Sensor 4 - 5.5 ft from spark (1 ft away from Sensor 3)

So, with the wave moving at 1 foot/ms, your deduction is spot on - we should observe the peaks reaching:

Sensor 1 - 2.5 ms

Sensor 2 - 3.5 ms

Sensor 3 - 4.5 ms

Sensor 4 - 5.5 ms

However, the previously attached output chart shows the simultaneous peaks across sensors. This synchronization is physically unrealistic, given the spatial distribution and wave speed.

Thank you again for taking the time to think through the expected propagation timing. Verifying my assumptions around sequencing before digging deeper into the odd measurement artifact causing such alignment is extremely helpful. Please let me know if any part of the configuration could be better described or if you have any other insights into what could trigger this phenomenon. I sincerely appreciate you lending your expertise.

Regards

[Kevin_Price]

When I zoom in on that screencap, I *do* see a small offset between the peaks.   Right-click your chart and choose "Visible Items" and turn on the Graph Palette.  Then use the horizontal zoom to get an even closer look at the time separation of the peak values.   Better yet, save the data out to a file where you can determine the time separation to within +/- 1 sample interval.

(Note: as already mentioned by Michael_Munroe, the 6259 is a multiplexing device so there will be a little bit of skew between the instants when the different channels are sampled.  However, you're not really at a point to need to worry about it, not yet.  Your peak pressure times are already quantized to limit your timing resolution to +/- 1 sample interval, and you probably still have room to improve that resolution simply by upping your sample rate.  And as you do that, the skew from multiplexing will always be a fraction of that, by definition. 

    There are times and places to know or control multiplexing skew, I just don't suspect your current setup is one of them.  But it *IS* worth being aware of the issue for whenever that time arrives.)

-Kevin P

[Edit: P.S.   A closer look at the chart shows that the middle red data is almost an order of magnitude smaller than the others.  Seems kinda suspicious to me -- I'd focus initial assessments about peak timing on the other channels.]

[tushar1209]

Hello Kevin,

I reconfigured my VI to acquire pressure data at 300,000 Hz per your suggestion.

Unfortunately, sampling more rapidly did not resolve the unphysical synchronization issue, as evident in the attached updated graphs and text file outputs. All three sensors still exhibit aligned peaks rather than the expected staggered timing discussed previously.

[P.S.- Could you please elaborate on the peak timing, I didn't catch your explanation for the part.]

Regards,

[Kevin_Price]

Spark phenomena aren't my field, but the alignment you show in the latest screencap is making me wonder whether the sensors might be picking up RF noise from the spark rather than simply responding to a pressure wave...

Maybe try pulling the sensors out of the tube so they aren't subjected to any pressure wave, but leave them at the same relative distance from the spark.  Do you get a somewhat similar data set once you've taken pressure out of the picture?

-Kevin P