ADPLL I Think ?

Hi, I have an Optical encoder on a system. I want to double / triple..... etc the incoming pulses.

I want to include an ADPLL in a Altera FPGA, Currently the design is in verilog. Does anybody have any code and an example how to use it.

The Freq of the Altera is 20Mhz The max freq of the encoder is 25Khz The max Freq of output is 30Khz

Please Help.

Pliers

Reply to
Pliers
Loading thread data ...

With such a massive ratio between system freq and encoder freq there is no need for a PLL. Just sample the encoder input using the system clock and add in pulses as desired.

Reply to
Kevin Neilson

"Kevin Neilson" schrieb im Newsbeitrag news:ct66gl$ snipped-for-privacy@xco-news.xilinx.com...

;-)) then it would be still a ADPLL. But the goal ist to have the pulses spaced as equal as possible. This reqires a ADPLL. But after all, even a ADPLL is "just" a clever FSM.

Regards Falk

Reply to
Falk Brunner

You're right. For some reason I was thinking he wanted to use a PLL or DLL, but he does clearly say he wants an ADPLL. So the correct answer is: no, I don't have any code for that, but if the input pulse edges are clean, making an ADPLL should be very straightforward: just make an NCO and then add a value to the NCO's phase increment that is proportional to the phase difference between the NCO and the input clock.

Reply to
Kevin Neilson

Ok, I'm totally confused now. I'm a newbie to this so please bare with me.

The project is a line scan camera with a low res encoder that i want to double up / triple etc.

The encoder can go from 0hz to 25khz To i count how many system clocks in that period i get ? do i need a ADPLL ? what is a NCO ?

Can you describe the basic's

Many Regards Pliers

Newsbeitrag

spaced

Reply to
Gary Crean

"Gary Crean" schrieb im Newsbeitrag news:M8UJd.1308$ snipped-for-privacy@newsfe1-gui.ntli.net...

Uhhh, a ADPLL isnt neccessary a thing to start with.

The encoder frequency (and so the rotation of the belt/drum/whatever is better reasonable constant, otherwise the PLL gets in trouble.

Yes.

Most probably.

Same as DCO ;-)

NCO = Numerical Controled Oscillator.

Regards Falk

Reply to
Falk Brunner

OK, this post is intentionally written for a newbie audience, so please bear with me if it tells you stuff you already know.

I'll try.

I *think* that the abbreviation ADPLL stands for "All Digital Phase Locked Loop". How that differs from DPLL is somewhat beyond me. It sounds like one of those acronyms that were so hideously popular in audio-land a while back, like OCL (Output Capacitor Less). Yuck.

Anyhows, DPLLs I kinda understand. Here goes.

First I'll try to rehearse the real basics so we can all agree what's going on. You have a linescan camera that's imaging thin strips of something. To get the second dimension of the image, you are scanning the camera past the object or vice versa. This second direction of scan is mechanical and comparatively slow, because the movement during one line-scan readout time must be quite small. To establish precisely how the second direction of scan is moving, you have an encoder or pulse generator somewhere on its mechanics. This encoder is rather coarse, so that you need many scan lines for each pulse it generates.

OK so far?

Next problem: If your encoder is coarse, it's probably also not very accurate - in other words, its edges or pulses are not very precisely located. So your interpolation between those edges needs to do a certain amount of smoothing-out of the jitter that inevitably comes with low-res encoders. (Think a standard mouse, with its ultra-cheap moulded encoder disks with nasty rough edges on the slots, and fairly poor quality optics on the optical detectors).

Both of these issues are nicely dealt with by a phase-locked loop. The idea is that you run a variable-frequency oscillator at the fast (interpolated) pulse rate. Then you divide that oscillator by the interpolation factor. The divided-down oscillator should now be running at exactly the same frequency as your encoder output (but, of course, it won't be). Now you feed both the encoder output and the divided oscillator into a phase comparator, which detects how far adrift the oscillator is with respect to the encoder that it's trying to track. This error signal can then be fed back to modify the oscillator's frequency. In this way the frequency (oscillator/N) is kept exactly in step with the frequency (encoder), so the oscillator is obviously running at (N*encoder).

The really tough part of any PLL design is how you process the error signal before using it to control the oscillator's frequency. This aspect of the design is generally known as the "loop filter".

Your specific problem is rather hard because of the extremely wide (ratio) range of frequency you must cover - you say

0 to 25kHz, but I guess you don't need real phase-lock performance over anywhere near that range. However, it's also simplified (I hope!) because the encoder is probably attached to a fairly large lump of mechanical doohickey, so its frequency is known to change only very slowly. In the jargon: your PLL needs a very large capture range, but it needs to track frequency changes only quite slowly.

The "oscillator" in your digital system is, of course, not an oscillator at all, but some kind of divided version of your system clock which I think you said was about 25MHz. The traditional way to do this is to use a numerically controlled oscillator.

Now that I've given you that background, I guess you should be able to Google for some of the following:

digital phase comparator numerically controlled oscillator phase locked loop digital phase locked loop lead-lag loop filter

and I suspect you'll find more stuff than you know what to do with. Once you've taken a look at it and have got some ideas about how to do your own implementation, you may want to come back here to calibrate your thinking again - there are plenty of folk on this group who have done lots of this kind of thing.

Finally, one simple and obvious suggestion that isn't a PLL at all, but may get you to an implementation a bit quicker:

Count the time between encoder edges, using a clock that is your system clock divided by your required frequency- multiplication ratio. Now, use that counted time value as the factor in a programmable frequency divider to get a divided-down version of your system clock. The output of this programmable frequency divider will be the encoder frequency multiplied by your required ratio. This method is prone to all manner of errors because it takes no account of encoder jitter, speed variations and so on - but it is very easy to implement, and it may help to get you started.

Good luck

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
 Click to see the full signature
Reply to
Jonathan Bromley

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.