PCI-6602 square waves (i.e. 15 kHz and 3kHz) drifting in and out of phase

[Bokonon]

I am using a PCI-6602 to generate square waves that control two devices in an experiment.  The second signal's frequancy must be a fraction of that of the first, usually 1/2, 1/3, 1/4, or 1/5.  In my VI I have a task that creates a 20MHz timebase on ctr 0, then these two signals are triggered off of that task.  Usually this works great, I can have two signals running for minutes and they stay in phase (1 pulse of the slow signal for every few pulses of the fast).  I can also use the initial delay node to delay one signal if I want them to be slightly out of phase, but they will stay that way.  

With other combinations of frequencies, say 15 kHz and 3 kHz, the two signals will drift in and out of phase about once a second.  This is very undesirable for my particular experiment.    The readability of my oscilloscope does not display any difference in period of the two signals, but I'm sure a tiny difference will throw their relation off after thousands of cycles.  I have not been able to discover a common thread between these bad pairs, it is a surprise each time: . . . 14 & 3.5kHz stays in phase, 6&1kHz drifts, 7&1kHz drifts ever so slowly, 8&2kHz is good . . .

I believe this may have something to do with how the counter generates frequencies by dividing the system clock.  Please let me know what you think.

[John_P1]

Hi Bokonon,

Your hunch is absolutely correct.  The 6602 can only generate frequencies that are a divide-down of the internal timebase.  The timebases available are {80 MHz, 20 MHz, 100 kHz}.  If you specify a frequency that is not obtainable, the driver will coerce the divisor to the nearest integer.

For example, 15 kHz (80 MHz / 5333.3333...) coerces to (80 MHz / 5333).  3 kHz (80 MHz / 26666.6666...) coerces to (80 MHz / 26667).  While the nominal 15 kHz and 3 kHz are multiples of each other, the coerced values (~15.00094 and ~2.99996) are not.

8 kHz and 2 kHz are both achievable by dividing-down an internal timebase, so there would not be any coercion (and thus drift) with these specified frequencies.

It's interesting that you reported that 14 kHz and 3.5 kHz also remain in phase.   These frequencies are coerced, but they will only drift very slightly since the coerced frequencies are still close to a multiple of each other.  The period of the coerced 14 kHz output is 71.425 us.  The period of the coerced 3.5 kHz output is 285.7125 us.  4 * 71.425 us = 285.7 us.  So, for every period of the 3.5 kHz signal, the signals should drift by .0125 us (12.5 ns).

The easiest way around this is to read back the coerced frequency from your faster task, and divide this down for your slower task. 

   

In the above case, you'll end up generating ~14.0007 kHz and ~3.500175 kHz, which gives you the closest frequencies to the specified 14/3.5 kHz that the counter can generate which are also exact multiples of each other.

Best Regards,

[Bokonon]

Wow John I can't thank you enough for your thorough response.  Interestingly I chose 14 and 3.5 in an attempt to force this problem to arise.  I figured that 14 was a relatively nasty number as a multiple of 7 and indivisible by 4.  I was actually double checking it after my post last night and I noticed that this particular combination did drift slowly if you watch the oscilloscope long enough (as you predicted).

I impleted your suggestion into my code and the result works perfectly.  No noticable drift in the relative phase of the two signals while I left them on for ten minutes.  This is quite good as I only need to generate the signals for 5 to 10 seconds at a time.  Thank you for your help.

[John_P1]

Hi Bokonon,

I'm glad to hear it's working.  You mentioned that you tested for 10 minutes, but I wanted to point out that you wouldn't ever see any drift if using the above suggestion.  Reading back the coerced value ensures the set frequencies are direct multiples of each other and both channels are derived from the same timebase.

Best Regards,