Setting the counter output mastertimebase divider?

[conzemic]

Hello

I want to output single short pulses with varying pauses. My MuFu DAQ card has 20 MHz master clock rate and 24 bit counter (Good ol'6052E). When I try to output 1 µs with a pause duration of more than 839 ms, I get an error due to mismatch of clockrate and counter bit size with short and long duration. This is explained in great detail in the corresponding help:

2/ counter clock rate <= X <= 2^24 / counter clock rate. with counter clock rate = master clock rate / divider

0.1 µs               <= X     <=   16777215 / 20Mhz = 839 ms

I could strech my limits by manually setting the CO.CounterTimebaseMasterTimebaseDivider to 10. But I've searched all property nodes I could find but I have not found this property.

Does anyone know where it is hidden, and to which values it can be set?

Thank you

Michael

[John_P1]

Hi Michael,

Unfortunately that property doesn't exist.  There are a few "Divisor" properties available for other subsystems (e.g. see Analog Input timing block diagram below).

However, you'll notice in the above diagram that the valid divisors of the master timebase are only 1 or 200 (which then gives the AI Sample Clock Timebase).  You can get similar behavior on the counter by specifying to use the 20 MHz timebase or 100 kHz timebase for your source.  However, using the 100 kHz (1/10 us) timebase is going to prevent you from properly generating the narrow 1 us pulses that you require.

So, you can use 20 MHz or 100 kHz without any additional resources, but 100 kHz wouldn't allow you to have a 1 us pulse, and 20 MHz won't let you have a high or low time of greater than ~839 ms.  You could generate frequencies in between these to use as the counter timebase (either use the frequency output or use the second counter to generate the desired frequency, or perhaps configure a dummy analog task) but of course there would always be a tradeoff between the resolution of the pulse and the maximum time between pulses.

If you do have the 2nd counter available, here is my suggestion to get the best of both worlds:

1.  Configure a counter output to generate a pulse every N seconds (I suggest configuring the output to generate at 1/N frequency at 50% duty cycle).  When you configure this counter, DAQmx will choose an appropriate timebase for you.  When N is less than ~1.67 seconds, DAQmx will use the 20 MHz timebase (since both the high and low time would be under the 839 ms).  When N is > 1.67 seconds but below ~335 seconds, DAQmx will use the 100 kHz timebase.  If you intend on modifying the rate of the output (to something above 1.67 seconds) after the task has started you would need to make sure to specify to use the 100 kHz timebase rather than relying on the DAQmx default.  You can't use a built-in timebase if you want to generate a delay greater than 335 seconds, but if you wanted to you could handle this case by checking for it and configuring the frequency output to generate an even lower timebase.

2.  To generate the actual output signal, configure a retriggerable single pulse generation to be triggered off of the signal generated above.  This signal will be based off of the 20 MHz timebase (assuming you configure a pulse width less than ~839 ms) and so will give you a good resolution on the available pulse widths that you can generate.

In summary, doing this would let you decouple the resolution of your generated pulse width from the resolution of the delay between the pulses.  The downside is that it uses two counters.

The other option which I previously mentioned (and what you were asking about) would be to find a timebase that meets the two requirements: 1) fast enough to generate a narrow pulse and 2) slow enough to not roll-over between pulses.  You have 100 kHz and 20 MHz available to you, but you can generate intermediate frequencies using the frequency output.  If you plan on using a counter to generate the timebase instead, you should consider the other option which decouples the two counters.

Of course, using a device with a higher counter resolution (most newer DAQ devices use 32-bit counters) would probably also resolve your issue depending on the full range of  delays that you need.  The downside here is the cost of new hardware.

Best Regards,