Could a PLL do the job ?
Could a PLL do the job ?
(OP)
We have a mechanical device for one of our IR cameras that is rotating a disc in front of the lens.
There is a 40/60% (approx.) duty-cycle signal coming out of the thing (1 pulse pr. rev.) and another that gives two short pulses pr. rev.
The one pulse pr. rev. has a problem, however. At times we have x-tra pulses, or the pulse is delayed 1/2 rev.
The errors usually happen at random with several seconds interval, which coresponds to something like 1% of the pulses.
We want to use this one pulse pr. rev. signal to synchronize our framegrabbing, so we need to correct the signal somehow.
I have thought about creating a PLL by using a 74HC4046, thus creating my own copy of the signal, and use the partly bad signal for keeping it fairly synchronized.
With a slow enough loop filter, the errors should have little enough influence to make it work, or ?
Other ideas ?
The vendor (DIOP, from New Hampshire) has been told about this, but they have received their money long ago and couldn't care less, it seems. We have no documentation on what goes on inside, but I guess it has to do with an internal latch delay or something. Possibly inside a PLD.
There is a 40/60% (approx.) duty-cycle signal coming out of the thing (1 pulse pr. rev.) and another that gives two short pulses pr. rev.
The one pulse pr. rev. has a problem, however. At times we have x-tra pulses, or the pulse is delayed 1/2 rev.
The errors usually happen at random with several seconds interval, which coresponds to something like 1% of the pulses.
We want to use this one pulse pr. rev. signal to synchronize our framegrabbing, so we need to correct the signal somehow.
I have thought about creating a PLL by using a 74HC4046, thus creating my own copy of the signal, and use the partly bad signal for keeping it fairly synchronized.
With a slow enough loop filter, the errors should have little enough influence to make it work, or ?
Other ideas ?
The vendor (DIOP, from New Hampshire) has been told about this, but they have received their money long ago and couldn't care less, it seems. We have no documentation on what goes on inside, but I guess it has to do with an internal latch delay or something. Possibly inside a PLD.





RE: Could a PLL do the job ?
The next best thing seems to be a little micro that "learns" the timing and keeps it so to bridge occasional dropouts.
Another rather crude technique would be to use a huge LC resonant circuit. But I wouldn't recommend it.
RE: Could a PLL do the job ?
RE: Could a PLL do the job ?
Use a double PLL --one for each. Reclock the INDEX
with the phase of the CLK.PLL which leaves the larger
margin.
<nbucska@pcperipherals.com>
RE: Could a PLL do the job ?
Felix
RE: Could a PLL do the job ?
That is a radiant example of "thinking outside the box" and KISS. You get a star for that.
RE: Could a PLL do the job ?
(I currently have no idea how this happens)
In the rest of the cases the pulse seems to simply be delayed 1/2 cycle. (Some internal latch setup delay error is my current guess)
The following pulse in these cases comes 1/2 cycle later and are thus back on track.
I don't think we can live with missing an entire cycle now and then.
Otherwise one could use an extended version of felixc's idea to create a qualifier inside which, a pulse will be accepted.
In our case the one-shots will have to be counter/timer based, however, as the rotation frequency can be adjusted from 5 to 170 Hz.
(We do have a number of counter/timers available
RE: Could a PLL do the job ?
<nbucska@pcperipherals.com>
RE: Could a PLL do the job ?
Felix
RE: Could a PLL do the job ?
RE: Could a PLL do the job ?