Initializing ETS Pulse Generation

[snowman13]

Hi,
I am just trying to find an example program that initiates the ETS Pulse Generation. More simply put, I am trying to use the auto incremental counter so that I can receive my input waveform and then output this pulse that will trigger another part of my system for undersampling purposes. I cannot figure out how to use it. I have attached my code, which is most certainly very incorrect. Any help would be appreciated. I do not think that I should have that retriggerable channel property. I am pretty new to LV and very clueless on using the DAQMX.
Thanks
Tyler

[Kevin_Price]

I'm not near a LV machine right now, but will try to give this a look later on.  Just letting you know you've "been heard..."

I haven't personally used the auto-increment feature, but *think* I have a fair-to-middling understanding of it.  That said, I think that you *do* need to be configured as "retriggerable."  The idea is that on subsequent triggers, the delay from trigger to the leading edge of your pulse will keep incrementing by the # of "ticks" you specify.  If you then use that output pulse as an analog sampling clock, you may be able to characterize a well-behaved periodic signal despite drastic undersampling.

Suppose there's a 50 kHz sine wave coming in.  You'd like to capture 20 samples per cycle in order to define a reasonably sinusoidal shape.  The standard option would be to sample at 1 MHz and you'd collect 1 million samples per second.  The samples would be spaced at 2 usec increments.  Fine, but some boards can't handle it and/or you may not want that high a data rate to contend with.

If the sine wave is steady and regular, you can use the ETS / auto-increment feature to accomplish something equivalent with far fewer samples.  All you need to do is make sure that each subsequent sample happens after an interval of (N * sinusoid period) + 2 usec.   So you would setup your auto-increment to represent a time of 22 usec, or 42 usec, or 102 usec, or 1002 usec or...

Since real-world signals are often not rock-solid steady, a fairly reasonable first attempt would probably to go with (1 sinusoid period) + 1 usec = 22 usec.  The more drastic undersampling is much more prone to trouble if the signal varies slightly or is simply not known with extreme precision.  You'd accumulate phasing error over all the sinusoid cycles you're skipping.

-Kevin P.

[stilly32]

Hi all,

Thanks for the great explanation Kevin P - you make my job easier. For the implementation, you are actually pretty close.  You don't need to use retriggerable but you do need to implement the timing:

I tested this out and was able to see a varying frequency pulse train, which you should be able to use to clock your AI. This sounds like an interesting application, feel free to post your code when you finish so others can see how its done

Please post back if this doesn't work for you.

Cheers,

Andrew S.

National Instruments

Message Edited by stilly32 on 02-01-2007 01:41 PM

[snowman13]

Thank you Kevin and Silly. The only problem I am having now is that since the period of my sync is 25 ns, I dont want the delay procuced by the increment to exceed 25 ns, because once it reaches this point, it will skip over an entire period of my sync. So I would like to format the increment into a loop such that it starts back at zero after reaching a delay of 25 ns or so. Does anyone know of the most time-efficient way to accomplish this?

[stilly32]

Hi Snowman13,

What hardware are you using? Generally the fastest clock we have on our cards is a 80Mhz clock, which if I'm doing my math right should mean that the smallest increment you can use is 12.5 ns. So each time you will be incrementing in at least that time. If you keep the increment constant, you will never jump over an entire period of 25ns. Even if you keep the Auto Increment constant, you will be increasing your count each time. If you run the code I showed you with a constant Auto increment (use a large one for testing) and view it using an scope or the ai on your card (if you have it) you will see that over time the frequency of your pulse train will decrease.

Hope this helps,

Andrew S

[Kevin_Price]

---

...The only problem I am having now is that since the period of my sync is 25 ns, I dont want the delay procuced by the increment to exceed 25 ns, because once it reaches this point, it will skip over an entire period of my sync. So I would like to format the increment into a loop such that it starts back at zero after reaching a delay of 25 ns or so. Does anyone know of the most time-efficient way to accomplish this?

---

If I'm interpreting your post correctly, you may not be able to get there from here using the NI 80 MHz (12.5 nanosec) timebases.

In order to define these ETS pulses, you need to define both a 'delay time' and a 'pulse time' which correspond to 'low time' and 'high time' (or vice versa if you change the output polarity -- but I digress...).  NI's counters require a MINIMUM of 2 timebases edges EACH for the delay and for the pulse for a total of 4.

You'd have a MINIMUM case of 25 nanosec delay followed by a 25 nanosec pulse.  Next cycle would be a 37.5 nanosec delay followed by a 25 nanosec pulse.  ALL of these cases would cause you to miss sync signals that are coming in every 25 nanosec.

Frankly, this is one heck of a requirement.  If you need to generate a pulse inside each 25 nanosec window and you need the pulse to have a variable delay after each 25 nanosec sync signal,  you're probably looking to vary by no more than 1 or 2 nanosec per cycle?  Yikes!  You need some hardware that's good to about 1 GHz!  I'm afraid I don't know of anything to point you toward.

-Kevin P.

[snowman13]

Stilly,

Yes. That is what I am seeing. My pulse train is decreasing over time. Thats why I am wanting to reset the delay and start the increment over at some point. I am using an PCI-6259.
And yes, my card is equipped with the 80 Mhz time base. How I understand it is that if I define my increment to be 12.5 ns, then after I receive the triggering edge of my sync, I am going to get a 12.5 ns delay, then a pulse. When I get my 2nd triggering edge, I am going to have a 25 ns delay, then a pulse. After my third triggering edge, I will have a 37.5 ns delay then a pulse. Having this 37.5 ns delay will cause for my output pulse to be after another entire sync period passes(this is what I am trying to avoid). I would like create an output pulse once on every period of the sync input.

The whole point of my application is that I am driving some equipment with a 40khz square wave, and I have an object moving at 40khz (sinusoidal) which I am trying to record data for. I am trying to make an application such that these output pulses trigger a data aqcuisition, by undersampling. Since I cannot(don't want to) do it real time. I probably should have said that earlier.
Thanks

Message Edited by snowman13 on 02-05-2007 09:42 PM

[snowman13]

I can trigger off of one period of the sync and create my pulse during the following period of my sync. However, I must have one pulse created for EVERY input sync period. That is really the only stipulation.

[Kevin_Price]

If you need to retrigger at 40 kHz, that's going to give you a much more manageable 25 usec rather than 25 nanosec between syncs. 

It sounds like you (probably) will want to set this up using retriggerable single pulse generation.  I myself just learned from stilly32's earlier reply that ETS variable-freq pulses can be generated without retriggering.  I now would question whether the retriggered mode I used to think was necessary is actually supported at all.

If you use the mode shown by stilly32, about the only downside I see is that the phase of your 1st pulse relative to your 40 kHz sinusoid will be unpredicatable.  But all the pulses thereafter should produce the right relative timing.  Within a couple "apparent sinusoid cycles" worth of acq data, you can probably determine what that initial phase was.

Eventually, the ever-increasing delay involved in the ETS mode will overrun even a 25 usec interval, and you'll miss some cycles while you reconfigure.  If you use the minimum increment of 12.5 nanosec, you'll get almost 2000 cycles of auto-incrementing delay -- but that still only represents 50 msec worth of data collection.

-Kevin P.

[stilly32]

Hi All,

Kevin has the right idea. Using the method I showed about will give you a deterministic time varying pulse generation, but it doesn't work so well for ETS. With the method I outlined above, your period does increase by the auto increment each time. The problem is, where your sample is taken is offset by the previous tick so instead of instead of your sample clock occurring at t0 + n*d, your sample clock occurs at t0 + (1+2....n)*d where t0 = initial time, n = nth sample and d = increment delay. 

So how do we get around this? This is where Kevin's suggestion comes into play. If we retrigger a single pulse generation and auto increment each time, we can get what we need. The problem becomes, what do we trigger off of? There are 2 options. If we know the frequency we're trying to characterize, we can generate a pulse train and trigger off of that but we would have to know the frequency and we would have to have the counters to do it. The nice thing is we can do this on any periodic signal. The other option is what I implemented. If you set up your analog task to trigger off of an analog edge, you can have the counter retrigger off of the Analog Comparison Event/AI Trigger. Your counter will now trigger at a known point in your signal and will increment each time so a sample is taken at a known point. You can now do your ETS measurement. For example, if you use the 80Mhz timebase at an increment of 10, you can effectively sample a full period of your 40khz sine wave at 8Mhz in 200 samples. You could sample at 80MHz but that would take 2000 samples for a full period. This is great if you have a unique level to trigger off of - if it is an arbitrary periodic signal then you'll need to use the pulse train method.

We normally try to stay away from generating code, but since this one in the end was solved from the combination of two LabVIEW examples (bonus points to whoever figures out which ones), the addition of a property node and the correct settings I'll go ahead and post it anyway. Plus, its a really cool application. Just as a note to all of you that are envisioning using your M series to effectively sample a high frequency signal, the M-Series cards have a Bandwidth of ~3.4MHz - so you're not going to be able to beat out our Scopes.

Also, Snowman13 - 40khz is well within the sample rate of our card- Is there a reason you have to use ETS? This is a pretty advanced method (this is the first example program I've been able to find) for something that can be achieved by just sampling at 1MS/s. 

Try this out, please post back if there are any issues.

Andrew S

National Instruments

Message Edited by stilly32 on 02-07-2007 01:23 PM