jitter and delay of counter outputs

[abdel2]

I am using M-series PCI 6259 DAQ. I want to generate a pulse with two frequencies but because a single counter only supports one frequency, I am using 2 counters and their output is combined using a T-connector.

First off, for a single counter, what kind of jitter is there in the output? I am trying to generate a pulse at 8 Hz, with 0.3 ms pulse duration. I know there will be jitter in starting and stopping the counter (because it is software timed) but I am hoping once the counter starts, the jitter will be in nano seconds.

Secondly, if I am using 2 counters in the same task, is there a jitter or delay in starting the second counter? In my case, I'm starting the second counter exactly 1us after starting the first one (using intial delay parameter), but when I view the resulting waveform on the oscilloscope, the delay looks more like 8us. Is this a constant delay or a jitter? If it is constant, I can compensate for it but if it is a jitter (eg: will be different for a given delay of 200us), that's a big problem.

[Andrew McL]

Hi abdel2,

I've added a link to the datasheet for a PCI 6259 DAQ device here. According to the datasheet, the counter accuracy is 50 ppm, so I wouldn't have thought it would factor into your jitter problems.

Thanks,

[Chris_W.]

Hi Abdel,

First of all, what type of jitter are you referring to for the counter output? The output signal should be clean. At the speeds that you are running you should not see any noticeable jitter, if you are using the 10MHz reference clock. If there is any jitter on a given clock tick, which is a .1us pulse, you should not notice it using a 0.3 millisecond pulse. How are you starting these output tasks? Assuming you’re using the same trigger as a start trigger for both of the counter output tasks, you should be able to achieve that 1us separation, by using the initial delay parameter of the DAQmx Create Channel.vi, if you are using the 10MHz reference clock as your sample clock. However, if you are not using an external trigger for these tasks, you may not be able to achieve 1us separation between the start of these two counter outputs, because it is software timed, and therefore system dependent.

My suggestion would be to use a DAQmx Triggering Node to use an “Arm Start Trigger.” You can use a rising edge of the 10MHz reference clock as an arm start trigger for both of the tasks. In this property node you can also specify each of the start delays, which should give you much better timing between the starts of these two signals. I have attached a vi that basically does what I have just described.

There is a possibility that the start of these two tasks will not be on exactly the same 10MHz reference clock tick because that is such a fast clock, but that will be a miniscule phase shift in the signals.

The best way to do this, would be to use an external start trigger to trigger both of these tasks. This could be done by simply inputting a pulse to one of the PFI lines and triggering the tasks on that PFI line.

Regards,

Chris N White
Applications Engineer::High Speed Product Group  

Message Edited by Chris W. on 10-27-2008 06:09 PM

[Broken_Arrow]

Are you using Notifiers inside a timed loop by chance?

[abdel2]

Thanks everyone.

Chris, I am starting both counters in the same task. If I set the initial delay parameter of the first counter to 0 and the second counter to 1us, I get around 8us delay on the oscilloscope.  The actual pulse width and frequency of each counter looks perfect though.

How do I know what clock I am using by default?

PS: I am starting the task in a loop where I am checking 2 digital signals to see if both of them are logic-high. That loop is running at 100 kHz, but I don't think the loop has any effect on the hardware time once the task actually starts.

Broken Arrow,  I'm not using any notifiers.

[Kevin_Price]

I've done a *ton* of stuff with counter/timers but must admit that I haven't ever generated 2 pulsetrains in a single task.

I have a nagging suspicion that the actual start time for the 2 pulsetrains isn't hardware-sync'ed by default.  I kinda suspect that DAQmx gives you an interface to treat them like 1 task, but deep down under the hood is code that arms them sequentially.   Hence, the several microsecond extra delay.

As Chris W suggested, you can hardware-sync the pulse trains if you set them up as 2 tasks that use the same "arm-start" trigger.  However, I'd recommend that you trigger off a signal that you can control instead of using a continuously running reference clock.  That way you can configure and start the 2 tasks so both are waiting *before* you generate the triggering signal.  Then you should get rid of those extra microseconds you called "jitter."

-Kevin P.

[Andrew McL]

Hi abdel2,

I wonder if you could achieve what you want to do by using a triggerable task that uses the slower of the two pulse trains as a reference to start. I would have thought that this would start both of the counters at the same time. 

Hope this helps,

[Chris_W.]

Hi Abdel,

What Kevin mentioned about the DAQmx task treating the two outputs as sequential is essentially true. The reason for this, however, is not because the outputs are in the same task, but actually because you are using a 6259, which is an M series board. This means there is only one Digital to Analog Converter, so the outputs of these channels have to be muxed through to generate their outputs. In order to avoid this, you would actually need to have an S series board, which has multiple DAC's, meaning true simultaneous sampling. I hope this clarifies why you're seeing that discrepancy.

Chris N White

High Speed Products Group 

[Chris_W.]

Hi Abdel,

I just re-read my post and realized that the multiplexing doesn't apply here, I forgot that you were using counter outputs. I'm sorry for leading you astray here.

I did also have some questions about your use of a T-type connector to combine these two signals. What do you mean that these two signals are going to be different frequencies? It would be nice to get an idea of what these signals actually look like and why you need to combine them to one line. Combining the outputs of these signals with a T-type connector directly will present some issues. There can be times when one line is driving the signal high and the other is driving it low. In this case I'm not sure what will happen. What are you trying to do overall?

Chris N White

High Speed Products Group