How to generate an (re-) synchronized pulse train

Question

Hello,
using a PCI-6601
I want to generate an endless pulse train of (e.g. 80Hz, high==low) synchronized to an external clock (ca.1Hz, ca 5ms pulse width).
The output should _re_synchronize with the clock if there is a clock signal but if one clock-pulse is missing it should continue hoping for the next.
It should look like this:
Perfect:
A1) tt________________tt________________tt_________...
A2) ooo___ooo___ooo___ooo___ooo___ooo___ooo___ooo__...
    0__1__2__3__4__5__6__7__8__9__0__1__2__3__4__5_...
Output is too fast:
B1) tt_________________TT________________tt________...
B2) ooo___ooo___ooo___oxxx___xxx___xxx___xxx___xxx_...
    0__1__2__3__4__5__6__7__8__9__0__1__2__3__4__5_...
Output is too slow:
C1) tt_______________PP________________tt__________...
C2) ooo___ooo___ooo__xxx___xxx___xxx___xxx___xxx___...
    0__1__2__3__4__5__6__7__8__9__0__1__2__3__4__5_...
Clock is missing:
D1) tt________________._________________tt__________...
D2) ooo___ooo___ooo___xxx___xxx___xxx___xxx____xxx__...
    0__1__2__3__4__5__6__7__8__9__0__1__2__3__4__5__...
The external clock is assumed to be "the truth", so the pulse width for the 80Hz output is recomputed from time to time
by measuring the clock and then setting then output pulse width.
Until now I used register programming but this is not a must.
The examples I've found either generate finite pulse trains or the sync only once.
Is there a way to do what I want without software interaction?
Thanks in advance
Toni Schilling

Answer 1

I have a possible idea for you, but my experience is with LabVIEW so I can't offer any help with register programming, interrupt callbacks, etc.  Also, the continuous syncing will have to be a software function that continuously performs cycles of measure/adjust, measure/adjust, measure/adjust...   I know of no way to set up the hardware to do this autonomously.
The approach I would take is to add another counter task and a little extra wiring.  The other task will be for "Two Edge Separation", and you want to measure from the active (lead) edge of the master clock to the passive (trail) edge of your sync'ed pulse train.  There's a reason NOT to measure to the active (lead) edge of your pulse train and it's because counters can only measure finite times of at least 2 timebase cycles.  Whereas you would *like* to have an actual two-edge separation time of 0 between the lead edges.  That just seems like the kind of detail that's gonna burn you sooner or later.
Let's just suppose the master clock is nominally about 1 Hz and your pulse train is nominally 100 Hz and 50% duty cycle so I can talk through details with some specifics.  Whenever the two lead edges are truly sync'ed, you'll measure a 0.005 sec two edge separation time from the master clock to your pulse train's trail edge.  If you measure slightly *less* than that, your pulse train is going just a little too fast and needs its freq slightly reduced.  If you measure slightly more, then your pulse train is too slow and needs its freq slightly increased.
It is probably quite likely that you *cannot* expect to maintain perfect sync *without* constant monitoring and adjustment.  Fundamentally, you can only produce pulses with high and low times that are an integer multiple of the 6601's timebase of 20 MHz.  That card's oscillator won't be perfect, nor will it be utterly constant over temperature variations, etc.   So its idea of a perfect 100 Hz pulse train will in fact be very very close but not *actually* perfect.
And your ability to adjust the frequency away from a nominal 100 Hz will only be possible in discrete steps.
A 100 Hz pulse train takes 200000 cycles of the 20 MHz clock.  If you adjust your square wave to take 199998 or 200002 cycles, you can produce a nominal freq of 100.001 or 99.999 Hz.  Those are the smallest increments away from 100.00000000 that are possible with a 50% duty cycle. 
Statistically, it's very unlikely that the frequency needed to perfectly match the external master clock is even *possible* to produce exactly.  I think you need to *expect* an imperfect sync with continual subtle adjustments to your pulse train.  If you watched the signals on a scope while triggering from the master clock, I think you should expect to see your pulse train oscillating back and forth by some small amount, perhaps in the microsecond realm.
Summary (for 1 Hz master clock, 100 Hz user pulse train at 50% duty cycle):
Measure two-edge separation from lead edge of master clock to trail edge of user pulse train.  Use units of "Ticks" with 20 MHz timebase.  Nominal expected value when sync'ed is (1/2)*(20 MHz / current user freq) = 100000.
Subtract measured ticks from nominal to produce your "error signal". 
Use current error signal its recent history in a control algorithm to determine the amount of adjustment to make to your pulse train.  Hint: it will probably NOT be correct to directly change the user pulse width by an amount equal to the error signal.  I suspect that you'll want to pay closest scrutiny to the derivative of the error signal.  Note also that the correct AMOUNT of adjustment will depend on the RATE at which you run your measurement / adjust loop.
Change user pulse specs on-the-fly.
Return to step 1.
Caution: Let's suppose your software measurement / adjust loop runs at a nominal 10 Hz.  From the time you make an adjustment until the next time you do a measurement, your user pulse train will have generated almost 10 cycles with the recently-adjusted specs.  If you weren't careful to make your previous adjustment subtle enough, you'll find that you now have a *larger* error of the opposite sign, and you are well on your way to instability.
   You need to do an adjustment that lets you expect your *next* measurement to have an error close to 0.
-Kevin P.