How to filter starttrigger on counter output precisely

[rashp8]

Hi,

I want to visualize 8 MHz counter clock on one of digital input line. For this I generated 8 MHz clock using counter 0 which is default output on PFI 12 line. This PFI 12 i have connected to one of digital input line Port 0 line 0. At 1 MHz it is a regular 1s and 0s pattern, which is ok. But as I am increasing frequency i am observersing irregular 1 and 0 patterns. Why this behaviour? Shouldn't it be a regular pulse train?

[Kevin_Price]

What device are you using?  For example, 10 MHz is the max supported sample rate on many common multifunction devices that support hw-clocked DIO on port 0.  There's a good chance you're running into Nyquist issues.  With a 10 MHz sample rate, you could only hope to capture every state change of a 5 MHz pulse train -- and that's *only* if it's a pure 50% duty cycle square wave.   If either the high or low time of thepulse train get any shorter (whether due to frequency or duty cycle), you should expect aliasing artifacts.

-Kevin P

[rashp8]

Hi Kevin P,

I am using PXIe-6366. It says I can generate pulse train upto 25 MHz using counters.

[Kevin_Price]

Sure, you can *generate* a faster pulse train.  But you can't *capture* it accurately with a DI task that can only sample at 10 MHz max.

-Kevin P

[rashp8]

Hi Kevin P,

Thanks a lot. But I was wondering all DI has to do to is make a threshold and decide what should be logic 1 and logic 0 for the incoming pulse train. No need to sample it, so no role of sampling rate.

Also I visualized the counter clock on oscilloscope, it's showing pulse train having 0V and 5V voltage levels. I can't seem to find a control to change the peak voltages. There are controls to change the frequency and duty cycle and not for voltage levels.

[Kevin_Price]

I don't follow what you're saying about DI, it doesn't make any sense to me.  If you aren't trying to sample the digital state, what's the task for?

No, the voltage level isn't configurable in software.  You'd need external circuitry to change the voltage levels.  

-Kevin P

[rashp8]

Hi Kevin P,

Nevermind, I got my solution. Thanks! One other small doubt regarding sample rate is this. Please consider.

1. I have a signal waveform having 60 kHz bandwidth (270- 330 kHz) and 3MHz sample rate. I have resampled it at 170 kHz using ' Resample Waveform(continuous).vi'. The resulting signal's spectrum is showing bandwidth of 60 kHz (10-70 kHz). Which is as desired.

2. Now on a separste vi I performed loopback using AO and AI and received the signal. I have used sample rate 170 kHz in DAQmx timing vi. The resulting signal's spectrum is showing bandwidth of 60 kHz ( but range is from 5-65 kHz). I can't seem to understand why this offset in bandwidth. Aren't these two processes same? I am resampling the waveform in both the cases and keeping the resampling rate same for both. I am cross correlating the waveforms of the two cases but not getting peak because of this mismatch in bandwidth ranges.

I am using PXIe-6366.

[Kevin_Price]

I use the term "bandwidth" in a kind of loose, general way.  I'm sure I don't visualize the exact same thing as you by your reference to "a signal waveform having 60 kHz bandwidth (270- 330 kHz) and 3MHz sample rate".

What it *sounds* like to me is that the signal has frequency content ranging between 270 and 330 kHz.  Nothing appreciable above or below that.   If that's the case, then I don't understand why you'd resample at 170 kHz.   All the frequency content would get aliased.

Now if that's some special technique based on knowledge of this special kind of signal, then I'm probably no particular help because I've got no familiarity with it whatsoever.

The only thing I can think to suggest is to confirm your *actual* sample rates, which might be different than your *intended* sample rates.  The way the 6366 (like many NI DAQ boards) derives a sample clock is to divide a timebase down by some integer factor.  Not all *intended* sample rates are actually possible to produce.

At some point after calling DAQmx Timing to configure your *intended* rate, you can place a DAQmx Timing property node that *queries* the sample rate to learn the *actual* value.   You could also look at the "dt" value in an AI waveform because it will be the reciprocal of the *actual* rate.

   If you find that your rates aren't what you thought, hopefully that will be a step toward solving your mystery.  

-Kevin P

[rashp8]

Hi Kevin P,

In my attempt to debug above problem I started with a sinusoidal signal of 300 kHz which I generated using waveform generation vi.
1. Debugging with PXI-6711.
I sent above signal using AO ( of PXI- 6711; analog output card with update rate rated at 1 Msps). Further I observed the signal on oscilloscope. On oscilloscope the observed signal is 300 kHz. Which is ok. Now I started increasing the sample rate of generation and DAQmx timing vi. Upto 2.5 MSps sample rate, observed signal is 300 kHz only. But above 2.5 MSps it started showing somewhat lesser frequency than desired 300 kHz. More the sample rate above 2.5 MSps lesser the frequency visualized. It was because of this behavior only that I was getting that bandwidth mismatch. Because I was using sample rate of DAQmx timing vi as 3 MSps, which was more than 2.5 MSps. And I was getting lesser frequency signal at the output of the card.
But I don't understand why I am able to output and desirably visualize the signal on oscilloscope as far as I am keeping sample rate of DAQmx timing vi less than 2.5 MSps. It is rated for maximum 1 MSps update rate right?

2. Debugging with PXIe-6366.
Puzzeled I did the same procedure with PXIe-6366 (multifunction DAQ card rated with maximum 3.3 MSps update rate). In this case also I am able to visualize the desired signal as far as I am keeping sample rate of DAQmx timing vi as 7.2 MSps.
I don't understand why these two devices are outputting nicely well above there update rate.

Thanks for reading it. Hope I made myself clearer this time. Please suggest.

[Kevin_Price]

I was pretty surprised by your observations about running above the board's rated sample rate.  At the end of the day, I spent a few minutes fiddling about and had some partly similar and partly different observations.  My fiddling used a simulated 6733 (AO card w/ 1 MHz max rated sampling freq like your 6711) and a real 6341 (900 kHz max rated sampling freq).  No scope though, only had a few minutes.

When I programmed an *intended* rate of 2.5 MHz, my query for the *actual* sample rate reported back 2.5 MHz on both devices.  The simulated device gave me a warning that I was exceeding the rated capabilities.  The real device produced an error indicating that the D/A converter wasn't ready for the next sample (a reasonable real error when the sample clock freq exceeds the board's capabilities).

I then set up a counter task to measure the AO sample clock rate on the real device.  It only saw a real sample clock signal when I stayed within the board's specs.  When I exceeded the specs, the AO task gave an error and my counter task timed out with no measured intervals.

So, I don't really know what's going on when you seem to be able to generate AO samples faster than the board specs suggest you can (or at least should).  I don't seem to be able to do the same thing here.

All that aside, I still really don't follow the main idea of what you're trying to do.  I'm certain I don't clearly understand what *you* mean when you use the term "bandwidth".  I also don't have any idea what your signal processing is supposed to accomplish.  Maybe you have a good reason for doing the unconventional things you're doing, but from here it sounds confused.  Why take a 300 kHz sine wave, downsample it at 170 kHz, and then do analysis on this distorted data set?  Is this a known technique in your field?  It sounds like a very unusual thing to do in realms where I've had experience.

-Kevin P