I need a circuit that takes a 400hz sync pulse and multiplies it to 19.2khz.
I was reading around the net on PLL multipliers, but everything I have seen are way up into the mhz range with really no schematics on aiding to design one.
Mike wrote: > I need a circuit that takes a 400hz sync pulse and multiplies it to > 19.2khz.
> I was reading around the net on PLL multipliers, but everything I have > seen are way up into the mhz range with really no schematics on aiding > to design one.
>> I need a circuit that takes a 400hz sync pulse and multiplies it to >> 19.2khz.
>> I was reading around the net on PLL multipliers, but everything I have >> seen are way up into the mhz range with really no schematics on aiding >> to design one.
> I've never used it, but maybe the old 4046 works:
19200 / 400 = 48. So, if you have a 19.2 KHz VCO, take its output and divide it by 48 (DIV3 followed by DIV16) . Run this signal into the feedback input of a phase comparator, and the 400 Hz into the reference input. If you use one of the 4046 variants, be sure to use the edge triggered comparator.
>> I need a circuit that takes a 400hz sync pulse and multiplies it to >> 19.2khz.
>> I was reading around the net on PLL multipliers, but everything I have >> seen are way up into the mhz range with really no schematics on aiding >> to design one.
> I've never used it, but maybe the old 4046 works:
But the real Frank Buss method would be to pipe that 400Hz into a uC and run a timer in there. A software loop would keep adjusting the timer's overflow register until the timer does exactly 96 rollovers per 400Hz cycle. Then use that timer overflow signal to toggle a port pin which will now deliver exactly 19.2kHz at 50% duty cycle. This method should require the least in parts. Heck, the uC doesn't even need a stable clock, it can run off its on-chip RC oscillator. Best case it'll be two components, the uC itself and a 0.1uF bypass cap.
Of course us analog guys will always have run out of timers by the time a function such as this is added into the mix. Somehow there are never enough timers ...
Mike, I can't see your posts because you probably use the google domain. But if you want to build something around a 4046 here is the recipe, figure 2:
The divider would be a bit more cumbersome because you have to provide a divide ration of 48 in this circuit. Most likely needs two chips instead of that one. But I am sure you can piece that together. Your 400Hz goes into pin 14 and your 19.2kHz emerge at pin 4. The timing parts to the right of the 4046 may also need some changes, that's where the datasheet comes in.
If this runs at voltages <5V I suggest to use 74HC series chips. The PLL comes in that family as well, would be called 74HC4046.
Joerg wrote: > But the real Frank Buss method would be to pipe that 400Hz into a uC and > run a timer in there. A software loop would keep adjusting the timer's > overflow register until the timer does exactly 96 rollovers per 400Hz > cycle. Then use that timer overflow signal to toggle a port pin which > will now deliver exactly 19.2kHz at 50% duty cycle. This method should > require the least in parts. Heck, the uC doesn't even need a stable > clock, it can run off its on-chip RC oscillator. Best case it'll be two > components, the uC itself and a 0.1uF bypass cap.
It depends on the accuracy requirements. If I use a cheap PIC with 4 MHz internal clock, I would need some machine cycles (4 MHz PICs runs with one million instructions per second) to toggle the pin. Would need considerably work to balance the code paths for the same time and even then there would be a jitter of about 2% (19.2 kHz / 1 MHz * 100), and worse when I need to adjust it up/down by one. I assume the CD4046 is more accurate.
>> But the real Frank Buss method would be to pipe that 400Hz into a uC and >> run a timer in there. A software loop would keep adjusting the timer's >> overflow register until the timer does exactly 96 rollovers per 400Hz >> cycle. Then use that timer overflow signal to toggle a port pin which >> will now deliver exactly 19.2kHz at 50% duty cycle. This method should >> require the least in parts. Heck, the uC doesn't even need a stable >> clock, it can run off its on-chip RC oscillator. Best case it'll be two >> components, the uC itself and a 0.1uF bypass cap.
> It depends on the accuracy requirements. If I use a cheap PIC with 4 MHz > internal clock, I would need some machine cycles (4 MHz PICs runs with one > million instructions per second) to toggle the pin. Would need considerably > work to balance the code paths for the same time and even then there would > be a jitter of about 2% (19.2 kHz / 1 MHz * 100), and worse when I need to > adjust it up/down by one. I assume the CD4046 is more accurate.
Yes, there will be some jitter and the 4046 will be more accurate. But sometimes it'll be good enough if you average out the jitter over the long term. Depends on Mike's application.
You could also do a timer up/down scheme which avoids the toggle, then it's done by HW inside the timer CCR area. Use a zippier uC such as a MSP430F2xxx or even better a 100MHz 8051, run the timer at max and only nudge the rollover register a bit by your code. Takes a lot of the jitter out.
>> But the real Frank Buss method would be to pipe that 400Hz into a uC and >> run a timer in there. A software loop would keep adjusting the timer's >> overflow register until the timer does exactly 96 rollovers per 400Hz >> cycle. Then use that timer overflow signal to toggle a port pin which >> will now deliver exactly 19.2kHz at 50% duty cycle. This method should >> require the least in parts. Heck, the uC doesn't even need a stable >> clock, it can run off its on-chip RC oscillator. Best case it'll be two >> components, the uC itself and a 0.1uF bypass cap.
> It depends on the accuracy requirements. If I use a cheap PIC with 4 MHz > internal clock, I would need some machine cycles (4 MHz PICs runs with one > million instructions per second) to toggle the pin. Would need considerably > work to balance the code paths for the same time and even then there would > be a jitter of about 2% (19.2 kHz / 1 MHz * 100), and worse when I need to > adjust it up/down by one. I assume the CD4046 is more accurate.
Another thought in case this comes up in some project: If you make sure the timer overflow has the highest interrupt priority there won't be more jitter than the granularity of the master clock. Just make sure the assembler routine for that ISR takes exactly xx clock cycles every time.
> >> I need a circuit that takes a 400hz sync pulse and multiplies it to > >> 19.2khz.
> >> I was reading around the net on PLL multipliers, but everything I have > >> seen are way up into the mhz range with really no schematics on aiding > >> to design one.
> > I've never used it, but maybe the old 4046 works:
> But the real Frank Buss method would be to pipe that 400Hz into a uC and > run a timer in there. A software loop would keep adjusting the timer's > overflow register until the timer does exactly 96 rollovers per 400Hz > cycle. Then use that timer overflow signal to toggle a port pin which > will now deliver exactly 19.2kHz at 50% duty cycle. This method should > require the least in parts. Heck, the uC doesn't even need a stable > clock, it can run off its on-chip RC oscillator. Best case it'll be two > components, the uC itself and a 0.1uF bypass cap.
> Of course us analog guys will always have run out of timers by the time > a function such as this is added into the mix. Somehow there are never > enough timers ...
> Mike, I can't see your posts because you probably use the google domain. > But if you want to build something around a 4046 here is the recipe, > figure 2:
> The divider would be a bit more cumbersome because you have to provide a > divide ration of 48 in this circuit. Most likely needs two chips instead > of that one. But I am sure you can piece that together. Your 400Hz goes > into pin 14 and your 19.2kHz emerge at pin 4. The timing parts to the > right of the 4046 may also need some changes, that's where the datasheet > comes in.
> If this runs at voltages <5V I suggest to use 74HC series chips. The PLL > comes in that family as well, would be called 74HC4046.
The NXP 74HC9046 is nicer (if you can find anybody who stocks it) and the 74HC40103 eight-bit counter can be used as a single-chip divide- by-48 albeit the 400Hz output would be a series of 52usec wide pulses - fine for the edge-detecting phase detector.
Well timing has to be rather critical. its being used in a narrow band video sync. so it has to be accurate.
Well, see i play around with NBTV scanning disk television as a hobby. I was going to make an NBTV emulator with a 32x48 LED matrix.
since it is a 32 line resolution, at 12.5 frames per second, you have a line sync of 400hz.
the problem is theres 48 vertical resolution pixels per 1 line scan. so that means i would have to multiply my 400hz pulse by 48 or 19.2khz to scan the vertical LEDs to keep them in sync.
Im going to be using an ATmel AVR, so if you know of a way to make a multiplier out of an AVR CPU. let me know.
On 2008-07-03, Joerg <notthisjoerg...@removethispacbell.net> wrote:
>> I've never used it, but maybe the old 4046 works:
> But the real Frank Buss method would be to pipe that 400Hz into a uC and > run a timer in there. A software loop would keep adjusting the timer's > overflow register...
Implementing a good digital PLL has all the design challenges of an analog PLL, but in discrete time instead of continuous time. The major difference is that EEs get training in PLL design, and even if they can't recall it immediately, they know that there are tools like Bode plots and impulse response to help them evaluate their design. Computer programmers have not been warned about hazards like poor step response, long settling time and instability and even if they discover those hazards experimentally it's not obvious how to fix them.
So I would recommend even to someone more comfortable with microcontrollers that if you have to ask this question ('how do I multiply 400Hz by 48?') you should strongly consider the analog solution. There are a lot more 4046 cookbooks out there than there are examples of how to build a digital PLL that will perform as well.
If you do decide to use the uC, shine the batsignal in the sky and Tim Wescott will swoop down and remind you that he wrote a book that you should read.
Mike wrote: > Well timing has to be rather critical. its being used in a narrow band > video sync. so it has to be accurate.
> Well, see i play around with NBTV scanning disk television as a hobby. > I was going to make an NBTV emulator with a 32x48 LED matrix.
> since it is a 32 line resolution, at 12.5 frames per second, you have > a line sync of 400hz.
NBTV sounds interesting. But according to this webpage http://www.nbtv.wyenet.co.uk/index1.htm (chapter "Club standard"), there is a sync every line. So I don't think that it would be a good idea to use a PLL for the pixel clock, but you should simply start scanning with each sync pulse. You can even increase or decrease the pixel clock to scale the image, like with old analog monitors. Or you can measure the average time between two syncs and calculate a counter delay for full screen fit, like the auto-adjust button on more modern monitors.
A PLL could be useful for restoring missing line syncs with noisy signals.
> Im going to be using an ATmel AVR, so if you know of a way to make a > multiplier out of an AVR CPU. let me know.
There are ATMega parts with hardware multipliers, but I think you won't need it for this project.
