Acquire signal with constant phase in daqmx with external source

[பூபதிராஜா]

Hello Mates,

I am facing a problem in acquiring the signal (known signal) with a constant phase in continuous acquiring mode.

For example, my source is an external arbitrary generator with signal parameters of 10kHz frequency with a 2V amplitude and 0 deg phase.

I have connected this source to my DAQ card and trying to acquire the signal with a constant phase in every iteration. 

Problems:

1. While trying to acquire the signal in the loop rate with respect to the number of samples to read, I acquired (Waveform Sample) the value of each iteration with a different phase that doesn't have any repeated patterns. (I used the Extract Single Tone Information.vi function to get the signal parameters)

2. I tried by using Analog Input trigger with Level and phase can be achieved for one iteration (Analog Trigger outside the loop before Start) and which is not continuing the trigger from 2nd iteration. But if I changed the trigger option with the Analog trigger, signal start, Read and stop functions inside the loop and allows to run every time results with a constant phase (with 1deg tolerance may be a problem with my source-not verified) that consumes more time than usual and felt this is not the correct way of programming. 

I tried syncing the reference clock of AO and AI were, I have generated the same signal from AO and measured in AI with AO reference clock to AI. I achieved the exact phase in a continuous read method every time. 

Please guide me if anyone has suggestions/solutions.

Thanks in advance.

Boopathy Raja S

[Kevin_Price]

Sorry, but I really don't quite understand exactly what you're looking for.  Hopefully this helps a bit:

There are inevitable, unavoidable limitations:

- your external arb generator and your DAQ device each have their own (very slightly) different idea of time based on their own internal clocks.  A lot of NI's DAQ devices are spec'ed to have time accuracy in the neighborhood of 50 ppm.  Your arb will have a spec of its own.   The two will generally NOT match up perfectly.

- your DAQ device likely has additional quantization built into the achievable sample rates.  It's highly unlikely that any of them will make it possible for any integer number of DAQ samples to correspond *EXACTLY* to the period of one cycle of the complicated arb waveform .

The sync you seem to be describing when generating AO on the *SAME* device that you use for AI is because that's a very special case that can avoid both problems above.  But when you generate on one and capture on another, you often can't avoid them.  You then need to accept them, understand their implications for your particular situation, and find a way to deal with it.

    This will vary from app to app, and I don't understand yours enough to offer specific advice at this point.

-Kevin P

[mcduff]

---

@பூபதிராஜா wrote:

Hello Mates,

I am facing a problem in acquiring the signal (known signal) with a constant phase in continuous acquiring mode.

For example, my source is an external arbitrary generator with signal parameters of 10kHz frequency with a 2V amplitude and 0 deg phase.

I have connected this source to my DAQ card and trying to acquire the signal with a constant phase in every iteration. 

Problems:

1. While trying to acquire the signal in the loop rate with respect to the number of samples to read, I acquired (Waveform Sample) the value of each iteration with a different phase that doesn't have any repeated patterns. (I used the Extract Single Tone Information.vi function to get the signal parameters)

2. I tried by using Analog Input trigger with Level and phase can be achieved for one iteration (Analog Trigger outside the loop before Start) and which is not continuing the trigger from 2nd iteration. But if I changed the trigger option with the Analog trigger, signal start, Read and stop functions inside the loop and allows to run every time results with a constant phase (with 1deg tolerance may be a problem with my source-not verified) that consumes more time than usual and felt this is not the correct way of programming. 

I tried syncing the reference clock of AO and AI were, I have generated the same signal from AO and measured in AI with AO reference clock to AI. I achieved the exact phase in a continuous read method every time. 

Please guide me if anyone has suggestions/solutions.

Thanks in advance.

Boopathy Raja S

---

Simple fix, but probably not what you want. Use a triggered acquisition, for your trigger use the TTL output from your function generator. The TTL and Function output should always be in phase and you will start your acquisition at the same point. You want the TTL as it is a sharp transition, triggering on a sine wave will not work.

mcduff

[பூபதிராஜா]

Thanks, Kevin

You understood the exact scenario which I was looking for. Sorry if I missed adding clear content. I am giving a detailed explanation below. 

As you said, I agree with the words where we have some spec'ed available to match the ppm with the external source. I already have hardware like NI RT Controller NI PXIe-8840, NI PXIe-6396, Keysight 33210A Function Generator (Opt. 002). 

Here my app specification, A signal generated with a frequency of 10kHz with 0 deg phase with my NI Analog Output Card and allowed to UUT. A response from UUT will be continuously acquired which has different phases in every iteration. In this case, I need to read the signal with a constant phase.

So I tried simulating the UUT output signal using Function Generator and NI AO Card. If I am using an NI AO card (NI PXIe-6396) for generation and acquisition in the same card which results in constant phase acquisition through clock reference. 

If I try using an external source (Keysight Function Generator) for generation and acquired in AI card (NI PXIe-6396) results with different phases for each iteration without any clock reference.

I hope you might get an idea for my application. 

Please suggest if you have any idea regarding this.

Thanks

Boopathy Raja S

[பூபதிராஜா]

Thanks, mcduff

I can use the TTL signal as a reference in simulation mode. As in the actual scenario, I don't have any reference from my actual UUT. 

Triggering analog signal is not a solution. It's a ransom try to get an alternate method. Because I don't know the level of my actual UUT signal which is less than 10V. 

Thanks in advance

Boopathy Raja S

[Kevin_Price]

It still isn't clear what role your "iterations" play in the whole scenario, but I'm getting pretty inclined to think that you're gonna best off with an approach like this:

1. Capture *BOTH* the stimulus and response signal with a Continuous Sampling AI task

2. Perform the necessary post-processing to discover or compensate for phase, whatever exactly it is that you're looking for.  

Note: if you capture with a multiplexing board rather than a simultaneously sampling board, your post-processing will also need to account for the slight time difference when each AI channel is converted.  You can discover this difference by querying a DAQmx Timing named something similar to "Convert Clock Rate."

-Kevin P

[Henrik_Volkers]

If you have a spare input channel, I would also always considder to capture the exitation. *

Next: If you can, use the AO of your DAQ (check output power)

If you stick with the external AWG and you want a fixed samplerate correlation, you need to sync the timebases.

If you also have opt001 you can use the 10 MHz output of the PXI chassis to sync your generator.

If no Ref In is provided at your AWG, you can try to lock the PXI-clock to the AWG generator 10 MHz output, but I assume the clock specs are worse, so I don't recommend that.

If you use the AO choose configure the the same clock source but use different slopes of the clock.

We had jitter in the phase measurement due to the small 'race conditions' between setting the DAC of the AO and reading of the ADC.

Finally: Use the lastest DAQ Driver...  seems to be some bugs in the <19.5? versions

see

https://www.ni.com/de-de/support/documentation/supplemental/19/ni-pxie-6386-and-ni-pxie-6396-supplem...

*) By doing so, you can swap the channels and check for delays. by using 1m RG58 as a DUT you should be able to measure a 5ns delay 🙂  (apply a 100kHz sine , use tone detection  or correlation)

[mcduff]

---

@Kevin_Price wrote:

It still isn't clear what role your "iterations" play in the whole scenario, but I'm getting pretty inclined to think that you're gonna best off with an approach like this:

1. Capture *BOTH* the stimulus and response signal with a Continuous Sampling AI task

2. Perform the necessary post-processing to discover or compensate for phase, whatever exactly it is that you're looking for.  

Note: if you capture with a multiplexing board rather than a simultaneously sampling board, your post-processing will also need to account for the slight time difference when each AI channel is converted.  You can discover this difference by querying a DAQmx Timing named something similar to "Convert Clock Rate."

-Kevin P

---

If you want to go the Continuous Acquisition Way, then you can either post-process as Kevin suggested or process inline. Either way you can use phase sensitive detection methodology, like a "Lock-in Amplifier", to continuously monitor phase shifts with respect to a reference. See https://www.thinksrs.com/downloads/pdfs/applicationnotes/AboutLIAs.pdf

mcduff

[Kevin_Price]

To the OP:

FWIW,  as far as I'm concerned, mcduff is among the relatively few who've earned my "trust, then verify" designation.  That's well beyond my usual *verify, then maybe trust" approach to most peoples' thoughts, including family members who don't particularly appreciate my selectivity.

So, I don't retract my advice, but I also don't insist on it as complete.  Follow mcduff's link as well.   Consider both, use what applies.   We're each just looking to help.

For the record, what I call "post-processing" is basically anything that happens in software after the hardware capture, whether it happens in near-real-time or long after the fact.  A lot of my help & advice on these forums relates to ways to rely on hardware *instead of* software.  So I tend to draw my line between hardware-based and software-based (post-processed, in my terms) methods.  It's probably more common that others draw their line between between (more-or-less) real-time and long-after-the-fact processing.   To-MAY-to, to-MAH-to.

-Kevin P

[mcduff]

Thanks Kevin for the kind words.

FYI you are on my About Menu because of your forum advice. Need to figure out a way for you to critique our work.

To the OP

Phase sensitive detection is a powerful technique that is used throughout the signal processing world. Remember phase is a relative measurement not an absolute, your value depends on the reference.

One suggestion, follow the pdf I gave, multiply your signal by a Sin and Cos of the same frequency, (this can be a table generated by you), then low pass filter the multiplications. You then have the Real and Imaginary parts of your signal, I and Q. The phase is then an ArcTan of Q/I. If you monitor this over time you will see how your phase shifts. Stuff similar to this is also used in FM radio and such to demodulate a signal; the signal is the phase of the demodulated FM signal.

mcduff