Synchronization of Two Digital/Clock Pulse Waveforms

[Michael.Proctor]

Hello,

I need a DAQ board whose major requirement is to produce two digital pulse waveforms that need to be synchronized.

My ideal concept is that once setup these waveforms can operate autonomously and only need software input if the waveforms need modifying. The need to modify them would be from a user interface and update speed 0.5 -1 s. ie not that fast.

The waveforms themselves are :

1. TTL 200 Hz - 2kHz frequency square wave with ~33% duty cycle ie on 33% of the time, off 66%


2. TTL same frequency range as above. This pulse should be triggered from the first waveform's rising edge, with a precision in the delay of ~1% of the waveform_1 pulse, ie at ~1-2µs and pulse width ~100µs

please see enclosed image.

Does this need two DIO/Counter Timer boards one to trigger the other as I have read to set up two waveforms on one board one needs two software channels and this could possibly cause an uncertainty in the delay as the software runtime is not guaranteed to service the two channels precise or can one board be configured to have two waveforms that have internal triggering.

What are the minimum specifications that i need to look at in selecting a suitable DAQ board.

thanks
michael

[Kevin_Price]

Don't see the "enclosed image."

If both pulse trains are continuous, you'll only need 2 counter/timer channels.  I would suggest you consider an M-series board which gives you 2 counters plus a whole lot of additional future versatility.  A counter timer board would also work but is less versatile.

If either or both are finite, you'll need 3 or 4 counter/timer channels because a finite pulse train uses counters in pairs.  A 6601 counter board should work for your immediate needs, but a 6602 would be a better value if you can eventually use its additional capabilities.  You could also use 2 M-series boards connected with a RTSI cable.

Note that continuous pulse trains can have their freqs changed on-the-fly, while finite pulse trains will require a stop, reconfigure, and restart.

-Kevin P.

[Michael.Proctor]

Hi Kevin,

thanks foe your reply and your board recommendations. I am beginning to understand the terminology.
I am a long time Labview developer - but never used DAQ boards previously.
I probably will use an M series board as I do need some AI, but the pulse trains are the most critical.

HOwever as this is a private adventure i need to keep the cost to a minimum and preferable it can run off a lap top so USB solution is also desirable.


My pulses trains will be continues so that is good that I can update the frequencies on the fly.
You did not mention how I can have the second pulse train stay in sync with the first, or as the pulsees use counter/timers there is no jitter issues.

I hope the image comes through this time.

thanks again

michael

[ryan_d]

Hi Michael,

To synchronize your two pulse trains, set up a hardware start trigger for both pulse tasks on the same PFI line. I’d check out the shipping example that come with DAQmx (Help » Find Examples…) located under Hardware Input and Output » DAQmx.

As for the delay, you can set the delay in the Create Virtual Channel VI.

Please post back if you have any questions. Have a great day!

Message Edited by ryan_d on 02-06-2008 06:02 PM

[stilly32]

Hi,

While staring the counters with a trigger to maintain synchronization is not a problem, changing them on the fly and keeping the phase\timing delay may pose a problem. Would you be changing the frequency or just the duty cycle? Basically all changes to the pulse specs that are done on the fly are software timed and not deterministic. So if you try to change both counters at the "same time" in SW, when they get updated in HW may be off and cause some skew. I'm not sure what your application is, but this may pose a problem for you. There should be a way around this - running your continuous pulse train generation, and creating a retriggerable single pulse on the second counter off of the leading edge of your first should give you what you need - you just may have to work with some settings. Do you need a pulse at that time, or just a rising edge? If you keep the frequency and vary the duty cycle, it shouldn't be in issue.

Hope this helps,

Andrew S

[Michael.Proctor]

Hi Ryan and Andrew,

thanks for the feedback.

For this application for the most part it will be not necessary to change the frequency or duty cycle on the fly of both waveforms.
It would be desirable, but not absolutely necessary to change the delay between the two waveforms on the fly. If it is not possible to change on the fly, i would set them to zero, define the new pulses and their relative positions and then send a retrigger to enable them. If this can happen in software in less than a second it should work - at least for a version 1. However reading your post it seems that as we will only be adjusting the delay on the second waveform and not touching the first waveform we can do that on the fly.

When we need to change frequency we can tolerate some downtime ( ie reset to zero) while setting up the counter time parameters/task.

My only remaining quesitons is if the USB series of boards such as a USB-6221 will give me a 1µs to 1.5µs resolution ( maybe relaxed to 2µs ) in the pulse delay of the second pulse to the first.

I see the specs state 1MHz, however is the a best case or a precise guarantee.

Thanks very much for the links to the DAQ material. I did search the ni site but those links somehow did come to my attention, however I think I now have the basic concepts and happy that my project will be reasonably straight forward to implement.

thanks again
Michael

[Kevin_Price]

I haven't used the USB boards, but I'm pretty sure the 1 MHz spec on the datasheet is in reference to the hardware-clockable digital port.  While it may not be immediately obvious, this spec is *distinct* from the timing resolution for counter / timers.  The counter timers are listed as being based on an 80 MHz timebase, just like the PCI M-series boards I'm familiar with.

In short, you should easily get absolute accuracy of <1 usec and repeatability that is far better than that.

Let's suppose your 1st pulsetrain is set at, say, the max of 2 kHz and will remain constant throughout a given test run.  Your 2nd pulse needs to be the same frequency as the 1st on any given run, but the delay may need to vary within the run.  Let's say you start with a 25 usec delay and later want to change that to a 100 usec delay.   I'll further suppose that only the rising edge of the 2nd pulse train really matters so the pulse width and the falling edge time can be chosen for convenience.

Here's how to do it:  As Andrew S. suggested, configure pulse train 2 as a retriggerable single pulse.  Let the rising edge of pulse train 1 be the trigger.  Configure pulse 2 in terms of low time and high time where low time is your initial desired delay of 25 usec.  Set your high time to a small usable value like 1 usec or 10 usec.  The lower you can set it, the more you can vary your low time (the delay) without wrapping across the next edge from pulse 1 and missing it.

Start pulse 2's task first so it's ready to be triggered when you first start pulse 1.  When you want to change your delay, simply write a new "low time" value to pulse 2's task.  Note: there's a chance that you'll need to also re-write the constant "high time" value at the same time in order to commit the change in the DAQmx driver.  I do know that for pulses defined as freq / duty cycle, you can't commit changes to duty cycle alone, you must also re-write the old freq value at the same time.

I don't have hw handy here to test, but this approach should work.  Note that if you can't change the pulse specs with DAQmx Write, you should be able to do it through a DAQmx Channel property node.

-Kevin P.