EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: TERRA Operative on September 03, 2020, 04:55:55 pm
-
I have a few Tektronix TM500 modules that require a stable 1MHz frequency source for testing and calibration.
I have a few 10MHz OCXO's here, but nothing in 1MHz. Does anyone have any suggestions to easily divide 10MHz down to 1MHz?
Is this something easy to build or is an ebay module the easiest thing to use?
-
See last schematic here: http://amateurtele.com/index.php?artikel=221 (http://amateurtele.com/index.php?artikel=221)
At 5V a 74HC390 has a fmax=55MHz, at 2V it has a fmax=20MHz. So it should handle any Vcc you may have.
At 5V a 74LS390 has a fmax=35Mhz for standard TTL.
https://assets.nexperia.com/documents/data-sheet/74HC_HCT390.pdf (https://assets.nexperia.com/documents/data-sheet/74HC_HCT390.pdf)
https://www.ti.com/lit/gpn/sn54ls393-sp (https://www.ti.com/lit/gpn/sn54ls393-sp)
-
If you want to maintain a 1:1 mark/space on the output, then you need to connect it so that the divide by 5 stage is followed by the divide by 2 stage.
A divide by 10 only requires one half of the 74xx390. You could use a 74xx90 instead, although they seem to be a bit less common these days. You can use the other half of the 390 to provide another divide by 10, or 2, or 5 (not 1:1).
-
Single CMOS D type flipflop with a RC delay between /Q and D so it divides by ten at or near 10MHz in, not by two. With symmetrical logic thresholds the duty cycle is inherently 50%. The two nearest division ratios it can lock to are 8:1 and 12:1, 1.25MHz and 833Khz respectively so its easy enough to measure that and trim the R to the midpoint between the two extremes where it looses its 10:1 lock. You can probably build it and trim it in less time than it takes to find a suitable divider you can order!
-
For an actual 1MHz oscillator rather than a clock, the
best easiest is probably phase-locking a VCO to the 10MHz reference XO.
-
If you want to maintain a 1:1 mark/space on the output, then you need to connect it so that the divide by 5 stage is followed by the divide by 2 stage.
Isn't the order irrelevant since going through the first flip-flop automatically gives you a 50% mark/space since a state transition is only triggered on the same falling (or leading) edge of the clock; not both edges. See attached.
EDIT: While the above is true, it becomes false after the 2nd and 3rd flip-flop. See my post later in this thread.
Also, one should probably add a buffer with schmitt trigger input (like 74HC14 or 74HC132) to square-up the incoming 10MHz.
Of course, I'm assuming here a square wave output is all that's required. Is a sine wave absolutely needed to feed the Tektronix TM500 modules?
-
For an actual 1MHz oscillator rather than a clock, the best easiest is probably phase-locking a VCO to the 10MHz reference XO.
Why on earth would you introduce a PLL, when a simple divide circuit can do the job? A /10 divider with a 1:1 mark space, aka, 50% duty cycle, is the easiest job in the world.
Gyro's suggestion of a /5, /2 counter is spot on.
-
Isn't the order irrelevant since going through the first flip-flop automatically gives you a 50% mark/space since a state transition is only triggered on the same falling (or leading) edge of the clock; not both edges.
I think you need to re-read "Digital counters 101". Counter output is normally just one clock cycle wide. Dividing the output by 2 brings 50% DC.
-
I don't know what you have for equipment, but if this is a one-time thing just for testing and not something continually used, I would connect the OCXO to the external reference input of my AWG or RF Generator and set it for a 1MHz output.
-
+1 for a 74HC390 here. Or two 74LS90's
-
Isn't the order irrelevant since going through the first flip-flop automatically gives you a 50% mark/space since a state transition is only triggered on the same falling (or leading) edge of the clock; not both edges.
I think you need to re-read "Digital counters 101". Counter output is normally just one clock cycle wide. Dividing the output by 2 brings 50% DC.
I take it back; the order of the divide-by-2 vs divide-by-5 parts of the 74HC390 is relevant. First divide-by-5 then divide-by-2 as per the schematic that I referenced in my first post.
The reason is that the divide-by-5 part cycles the outputs Q3..Q1 from LLL to HLL (0..4 decimal). If you're to pick off the output at Q3, that gives 4 Ls and 1 H (after 5 clocks); that's not 50% mark/space. Now feeding this Q3 to CP0 (the divide-by-2 part), this will do as I said, turn any input not at 50% duty into an output (Q0) at half the frequency and also at 50% duty cycle (since it transitions on only 1 edge).
-
You might want to consider the picDIV dividers!
8pin DIP or SOIC, provide power, input, and you get your output!
http://www.leapsecond.com/pic/picdiv.htm (http://www.leapsecond.com/pic/picdiv.htm)
The closest one is the pd02 which divides by 100.
pd02.asm:; PD02 -- PIC "4-pin" 10^2 frequency divider (10 MHz to 100 kHz)
Full list here: http://www.leapsecond.com/pic/picdiv-list.htm (http://www.leapsecond.com/pic/picdiv-list.htm)
You could maybe contact Tom Van Baak and see if a divide by 10 would work.
tvb@LeapSecond.com
Cheers,
Corby
-
It wouldn't as the 8 bit PICs he uses take four clock cycles per instruction and everything is locked to that ratio. The only way of getting round that would be to port his concept to a newer 8 bit chip that has an internal 4x PLL multiplier for the clock, which allows it to execute one instruction per external clock. You'd then set up Timer 2 for a period of 10 instruction cycles and set up a PWM module for 50% duty cycle, at which point you've just done the job of the proposed 74xx390 with several times the jitter and cost.
You could also get there by injection locking a classic two transistor astable multivibrator, using a pullup resistor and a third transistor as a saturated switch for the output.
-
I would suggest a 4017, except I'm not sure if it would operate at 10MHz.
Maybe you could find something similar, with an adequate frequency range, rather than get tied down with combinations of other division ratios.
The Drake SSR1 radio used a 10MHz xtal osc, divided down to 1MHz.
From memory, it used a single device, but not a 4017.
-
I would suggest a 4017, except I'm not sure if it would operate at 10MHz.
Maybe you could find something similar, with an adequate frequency range, rather than get tied down with combinations of other division ratios.
The Drake SSR1 radio used a 10MHz xtal osc, divided down to 1MHz.
From memory, it used a single device, but not a 4017.
Well, you better believe that the 74HC4017 will reach the 10Mhz mark...
In fact, we are talking 30MHz at 5v.
It will even do 10MHz at 2.5v.
And its readily available everywhere...
-
Awesome info, thanks all!
It looks like the 74xx390 is the go, simple to use and it just so happens that I have a tube of 25 of HD74HC390P, so I think I'm set.
Who says hoarding old parts never comes in handy! ;D
-
For an actual 1MHz oscillator rather than a clock, the best easiest is probably phase-locking a VCO to the 10MHz reference XO.
Why on earth would you introduce a PLL, when a simple divide circuit can do the job? A /10 divider with a 1:1 mark space, aka, 50% duty cycle, is the easiest job in the world. Gyro's suggestion of a /5, /2 counter is spot on.
Why would you introduce a counter, when a simple single transistor 1 MHz oscillator can be injection locked to the 10 MHz source? An injection locked oscillator is the easiest job in the solar system.
-
Well I had a poke around with a schematic just now, taking ideas from here and there. I thought I'd give myself some options on output frequency. :)
Should I be terminating the input maybe? Let me know if there are any glaring mistakes or omissions. :-/O
-
Should I be terminating the input maybe? Let me know if there are any glaring mistakes or omissions. :-/O
At 10 MHz, a termination should not be required unless your patch cables are really really long, and really not even then if source termination is used unless the cable is more than point-to-point.
74HC390 counters are a good way to go for this. Why make things more complicated? I do not see any obvious mistakes.
In a high performance design, I would optimize for low phase noise and some kind of universal driver for the outputs.
-
Well I had a poke around with a schematic just now, taking ideas from here and there. I thought I'd give myself some options on output frequency. :)
Should I be terminating the input maybe? Let me know if there are any glaring mistakes or omissions. :-/O
U1.4 and U1.3 outputs should be 1MHz and 5MHz, respectively.
U2.2 is a divide-by-5 into a divide-by-2 whereas U2.1 is just a divide-by-2.
-
For smallest solution, use any DIP8/SO8/SOT3-6 microcontroller with clock input pin and PWM :D
-
No. Not *any*. See my comments in reply 12 above. The PWM clock has to be taken direct from the input clock to be able to get the right frequency at 50% duty cycle. Older low pin count PICs don't support that.
-
With an ATMega8 microprocessor, one can obtain 5MHz and 1MHz by CTC on Timer1 and Timer2 output respectively. This is a hardware solution and operates without software support after setting up.
Then with a bit of creative programming of cycle counting, it is then possible to obtain 100KHz, 10KHz, ...0.01Hz simultaneously on the 8-bit PORTD pins. All with 50% duty cycle.
A true one chip solution.
-
How accurate is that? Enough for using as a reference for calibrating test gear?
-
Suggesting a "solution" needing software development (not a lot), a programming and debugging environment, programming/burning hardware etc. instead of just buying a 25 cent part with far superior timing characteristics (74HC390) and just using it 'as is' is "better"?
Wow. I see parallel universes that seem to consist of pull-down menus, PIC and ATMega brainwash.
If those contributors worked with me, they'd be fired on the spot. Just throwing any 8-pin MCU at any problem is not engineering to me.
Sorry, had to get that off my chest.
-
Suggesting a "solution" needing software development (not a lot), a programming and debugging environment, programming/burning hardware etc. instead of just buying a 25 cent part with far superior timing characteristics (74HC390) and just using it 'as is' is "better"?
Wow. I see parallel universes that seem to consist of pull-down menus, PIC and ATMega brainwash.
If those contributors worked with me, they'd be fired on the spot. Just throwing any 8-pin MCU at any problem is not engineering to me.
Sorry, had to get that off my chest.
Completely agree
-
Wow, I thought any idea was OK to share? :-//
The picDIV dividers are synchronous and only have a couple picosecond jitter and are a very cost effective solution to a lot of "divide by" problems.
Since the programming files are free and the pics are dirt cheap and programmers ditto, why not consider them!
I have used them to provide 1PPS outputs for HP 5065A and 5061A that lacked that option with excellent results.
I've also used them to provide 1PPS outputs from the cheaper 10Mhz miniature Rubidiums.
I'm not saying they are a panacea for all divider applications but should at least be considered.
Ian.M was correct however in that they can't be used for low division ratios.
Cheers,
Corby
-
Yes. The fastest possible 'classic' midrange PIC bit toggle loop with 50% duty cycle takes six instruction cycles per output cycle which is 24 input clock cycles, or four instruction cycles if a 25% or 75% duty cycle is acceptable, which is 16 input clock cycles: a hard lower limit on the division ratio of a PIC software divider, and also all divider divisors must be factorisable with a factor of four, so the lowest possible 10n decimal divider PICdiv can do is divide by 100, and not at an exact 50% duty cycle, as the constraint for 50% duty cycle is eight must be a factor.
As to whether or not its appropriate, it depends if you've got Microchip MPASM and a programmer set up on your bench PC, and some PICs handy. If so its probably easier than digging through your collection of logic chips. If you are talking production, as long as the code's well tested, performs the task to specification and you can legally use it, it only puts a couple of tens of cents on the price to have MicrochipDirect preprogram the chips for you and drop-ship them to your assembler, who will treat it as an essentially custom IC. If the cost of doing so is more than recovered by resulting BOM savings, why not?
-
The picDIV dividers are synchronous and only have a couple picosecond jitter and are a very cost effective solution to a lot of "divide by" problems.
I have now read the "divPIC" page you referred to, and you're either a snake-oil salesman connected to that site, or certifiably gullible.
The so called divPICs are preprogrammed normal MCUs using standard CMOS technology.
And they should achieve "2 ps jitter" performance? Companies working with silicon ECL, SiC or GaAs technology dream of that kind of performance.
I strongly suspect that you're involved in this scam.
-
Ok, thanks to all this excessive BS, I'll say use a 'EPM7032AETC44-10N' PLD with a few inputs tied to dip switches to select the divide output to anything you can fit into a 24bit counter, meaning all the way down to a 1Hz clock from a 10MHz source, including passing the 10MHz out as well as multiple outputs.
No software to hang or crash. Your counter divides or it doesn't.
-
2ps |O Just the energy of my neurons firing in my brain every time my neighbor's dog starts barking might be strong enough to interfere with the electrons buzzing around the circuitry to mess up that degree of precision.
-
Wow, I thought any idea was OK to share? :-//
Of course it was OK to share! I was about to suggest the PIC myself, but then I looked at the minimum divide ratio obtainable and saw it wouldn't work for 10M -> 1M.
And that most certainly is "engineering". There's nothing with using a cheap 8-pin device if it meets your requirements, and it might even be the *best* choice depending on various factors.
-
Benta,
I am not a "snake-oil salesman connected to that site, or certifiably gullible."
I also am not "involved in this scam." Which is not a scam!
First if you would explore Tom Van Baak's leapsecond.com site you will find he is a certainly a professional when it comes to time and frequency.
He has presented papers at the PTTI (Precise Time and Time Interval) conference, and has appeared on PBS in an episode of the TV series called GENIUS by Stephen Hawking.
He owns and operates several Hydrogen Masers and MANY other high stability standards.
His equipment can measure right up there with most any lab.
His picDIV fills a need for many TimeNuts that make their measurements using 1PPS.
My recommendation was based on how easy I have found it to use the picDIVS and just wanted to share!
I thought about hooking a couple up to my Maser and measuring the jitter but I decided I will spend my time more wisely working on my own projects.
This kind of "smack down" does not encourage people to share! I have seen quite a few friends stop posting on TimeNuts when similar things happened.
Cheers,
Corby
-
Using PICs in the past to generate sub-clocks, and we are talking the PIC16C54 and some later variants, I can confirm that making a simple instruction cycle based loop dividing algorithm which I've written in assembly in the late 90s, no interrupts, has dead perfect output timing.
This is the same for the PIC12Fxxx variants so long as you disable all the unused hardware resources.
I cannot speak for the PICs with PLL multipliers in them, but, following my rules, I bet they are just as clean under these controlled circumstances.
-
Suggesting a "solution" needing software development (not a lot), a programming and debugging environment, programming/burning hardware etc. instead of just buying a 25 cent part with far superior timing characteristics (74HC390) and just using it 'as is' is "better"?
One of those times when an Arduino with its friendly bootloader would be a marked improvement :-+ 8) :D
I don't see jitter specifications in any 74HC390 datasheet. Neither in micros. Anyone measured it, by any chance?
Many micros have hardware counters and PWM generators, which makes them like a sorta 74HC390 with arbitrarily programmable division ratio. Software just sets it up and goes to sleep.
You can also do the same with PLDs/FPGAs as someone suggested, not sure about availability in the smallest packages, though.
-
Suggesting a "solution" needing software development (not a lot), a programming and debugging environment, programming/burning hardware etc. instead of just buying a 25 cent part with far superior timing characteristics (74HC390) and just using it 'as is' is "better"?
Surely many have mistaken my intention. I'm not advocating using a processor for solving every problem, far from it. Of course it is madness to use a MCU to replace a 74HC390 if a single divider ratio is needed. I had offered my comment after seeing the OP's proposed design in Reply#17.
Please take a look at OP's Reply#17 first, before offering harsh comments. He wanted many lower frequencies options. If you think a 25 cent part can do the job, then I applause you.
I don't understand how come you can be so sure that 74HC390 has far superior timing when the MCU solution is using the similar digital technology and clocking along, and changing output states synchronously to the the clock from the OCXO. Obviously all these happens using assembly language programming. May be you do have proofs.
But then, I don't want to argue with you anymore, after you have called a perfectly legit webpage a "scam" and other users "a snake-oil salesman connected to that site, or certifiably gullible."
-
Suggesting a "solution" needing software development (not a lot), a programming and debugging environment, programming/burning hardware etc. instead of just buying a 25 cent part with far superior timing characteristics (74HC390) and just using it 'as is' is "better"?
Surely many have mistaken my intention. I'm not advocating using a processor for solving every problem, far from it. Of course it is madness to use a MCU to replace a 74HC390 if a single divider ratio is needed. I had offered my comment after seeing the OP's proposed design in Reply#17.
Please take a look at OP's Reply#17 first, before offering harsh comments. He wanted many lower frequencies options. If you think a 25 cent part can do the job, then I applause you.
I don't understand how come you can be so sure that 74HC390 has far superior timing when the MCU solution is using the similar digital technology and clocking along, and changing output states synchronously to the the clock from the OCXO. Obviously all these happens using assembly language programming. May be you do have proofs.
But then, I don't want to argue with you anymore, after you have called a perfectly legit webpage a "scam" and other users "a snake-oil salesman connected to that site, or certifiably gullible."
To be fair, until the OP posted his schematic in reply #17, everyone was working on the basis of his stated requirement of a easiest 10MHz to 1MHz divider. It was only when he posted the schematic that all of the other frequency divides appeared.
Maybe it was my fault for pointing out that he had a spare divider in the 390 that he could use for another divide - he seems to have got rather 'enthusiastic' from there! ;D
-
It does not matter whether one would use a ripple counter or synchronous counter for a single division ratio.
However, getting other lower frequencies divide by cascading ripple counters is not one I would recommend. I think it is prudent to use only synchronous counters for such division, as each edge changes would be related to the clocking. This, however, couldn't be achieved by the 74HC390 as it is a ripple counter, despite its "far superior timing" characteristic.
-
I won't be using a micro or other programmable controller. I program with solder, software is beyond my scope for now. :)
The simplest method to me for a 10MHz to 1MHz divider is a single 74HC390, but if I am going to get a PCB made anyway, and I have a tube of 25 Hitachi chips sitting right beside me that I bought for 370yen, I may as well add a few extras to get some more frequency options. It's not like I'm spending much cash to do so when they cost me 15 cents a pop... :)
-
TERRA Operative has his solution which meets his requirements using hardware and I would not argue with that.
As microprocessors have had a rather bad press in previous posts I would like to comment...
As has been mentioned PIC processors are unsuitable (instruction cycle = 4 clock cycles), however an AVR processor does not have this limitation (instruction cycle = 1 clock cycle), they also have a 'toggle output' instruction which means that even divide by 2 is possible.
Still overkill for a simple divide by 10, but for 7 decades or more???
This post https://www.eevblog.com/forum/projects/divide-by-10000000/msg2816502/#msg2816502 (https://www.eevblog.com/forum/projects/divide-by-10000000/msg2816502/#msg2816502) shows an 8pin ATtiny85 used to give
(10MHz) plus switch selectable frequencies of Off, 5M, 2.5M, 1M, 100k, 10k, 1k, 100, 10 or 1Hz (Off position ensures no subharmonics on 10MHz output.)
Divider outputs are 1:1 M/S and are effectively clocked synchronously.
Jim
-
For an actual 1MHz oscillator rather than a clock, the best easiest is probably phase-locking a VCO to the 10MHz reference XO.
Why on earth would you introduce a PLL, when a simple divide circuit can do the job?
I don't understand the question. Are you asking why sinusoidals are used for frequency references? Or why a frequency divider should produce an output phase-locked to the reference? Why propagation delays ruin the utility of multi-frequency references? Or something else?
-
For an actual 1MHz oscillator rather than a clock, the best easiest is probably phase-locking a VCO to the 10MHz reference XO.
Why on earth would you introduce a PLL, when a simple divide circuit can do the job?
I don't understand the question. Are you asking why sinusoidals are used for frequency references? Or why a frequency divider should produce an output phase-locked to the reference? Why propagation delays ruin the utility of multi-frequency references? Or something else?
Some Tektronix TM500 modules can optionally be fed a TTL signal of 1 MHz if you're not satisfied with the internal frequency reference.
No one ever spoke about sinusoidals, and there's nothing about "locking to a reference" involved. And propagation delays and multi-frequencies are in this case also totally irrelevant.
It's simply about generating a nice, stable, 1 MHz TTL signal from a 10 MHz oscillator.
I don't understand YOUR response, though.
-
It does not matter whether one would use a ripple counter or synchronous counter for a single division ratio.
However, getting other lower frequencies divide by cascading ripple counters is not one I would recommend. I think it is prudent to use only synchronous counters for such division, as each edge changes would be related to the clocking. This, however, couldn't be achieved by the 74HC390 as it is a ripple counter, despite its "far superior timing" characteristic.
Here we really speak the same language :)
I'm also a stickler for synchronous design in digital circuits.
However, in this case I'll support a ripple design, as it's a simple frequency divider with no implications on other circuits.
-
Benta,
I am not a "snake-oil salesman connected to that site, or certifiably gullible."
I also am not "involved in this scam." Which is not a scam!
First if you would explore Tom Van Baak's leapsecond.com site you will find he is a certainly a professional when it comes to time and frequency.
He has presented papers at the PTTI (Precise Time and Time Interval) conference, and has appeared on PBS in an episode of the TV series called GENIUS by Stephen Hawking.
He owns and operates several Hydrogen Masers and MANY other high stability standards.
His equipment can measure right up there with most any lab.
His picDIV fills a need for many TimeNuts that make their measurements using 1PPS.
My recommendation was based on how easy I have found it to use the picDIVS and just wanted to share!
I thought about hooking a couple up to my Maser and measuring the jitter but I decided I will spend my time more wisely working on my own projects.
This kind of "smack down" does not encourage people to share! I have seen quite a few friends stop posting on TimeNuts when similar things happened.
Cheers,
Corby
Corby, I did not want to shame you, but that falls back on your friend "van Baak". The page you linked to had statements like these:
"Jitter is extremely low since the PIC is a synchronous device. Recent measurement suggest it is less than 2 ps."
"Output jitter is less than 2 ps."
This is patently ridiculous, and caused me to regard this guy as a con artist trying to sell programmed PICs as snake oil. I'll stay with that assessment until he changes those claims and comes back to earth.
Of course you're always welcome here, and I've realized that the OP post #17 caused a lot of confusion. I unfortunately didn't look at the crazy schematic until too late.
PS: Do not confuse 1 PPS (1 pulse per second) with 2 ps (2 picoseconds), which would make the PIC a 500 GHz capable device.
-
The picDIV dividers are synchronous and only have a couple picosecond jitter and are a very cost effective solution to a lot of "divide by" problems.
Have you measured it?
I don't see jitter specifications in any 74HC390 datasheet. Neither in micros. Anyone measured it, by any chance?
The image below shows the jitter from a 74LS90 asynchronous counter chain but *not* from the chain itself. (1) The jitter actually comes from a poorly performing delay stage following the counter chain which is getting modulated by the supply voltage variation produced from the logic states of the 74LS90 counter chain.
My example illustrates the problem with integrated logic and good jitter performance; internally produced ground and power bounce modulate the logic thresholds of all stages including the last clocked stage setting a lower limit on the output jitter. Lower jitter requires output signals to be reclocked with discrete logic.
(1) In my example, the jitter is magnified many times over what would normally be expected even from TTL asynchronous logic. Unfortunately at the time, it did not occur to me to measure the output jitter of the counter chain by itself.
-
TERRA Operative has his solution which meets his requirements using hardware and I would not argue with that.
Indeed. And that doesn't mean the discussion should stop just yet. :)
I only need a few frequencies now, and phase delay etc doesn't matter as I'll only ever use one frequency output at a time, however, it doesn't mean I won't have a poke at using some different methods in the future. :)
I do want to start getting into micros one day. I might add this to the to-do list of projects.
-
I think a PIC18F14K22 based multiple 1/10n outputs PICdiv style divider for 10Mhz input would be an interesting challenge. Its got the clasic Timer 2 + (E)CCP module 10 bit PWM, which, with the 4x PLL active could be configured for 10 Fosc/4 cycles period and 50% duty cycle, to give 1MHz. Timer 2 has also got a post scaler that can be configured to divide by 5, and as PIC18 interrupt latency with only a single internal interrupt source is entirely deterministic, it would be reasonably easy to get the 100KHz edges to align with the 1MHz ones to within one input clock period. By using a mask to determine which port C pins to toggle at each timer 2 interrupt, updated by the main program every ten interrupts, and double buffered by the ISR, the other 10n divider outputs could be toggled synchronously, all the way down to 0.1Hz.
-
I think a PIC18F14K22 based multiple 1/10n outputs PICdiv style divider for 10Mhz input would be an interesting challenge. Its got the clasic Timer 2 + (E)CCP module 10 bit PWM, which, with the 4x PLL active could be configured for 10 Fosc/4 cycles period and 50% duty cycle, to give 1MHz. Timer 2 has also got a post scaler that can be configured to divide by 5, and as PIC18 interrupt latency with only a single internal interrupt source is entirely deterministic, it would be reasonably easy to get the 100KHz edges to align with the 1MHz ones to within one input clock period. By using a mask to determine which port C pins to toggle at each timer 2 interrupt, updated by the main program every ten interrupts, and double buffered by the ISR, the other 10n divider outputs could be toggled synchronously, all the way down to 0.1Hz.
Do not even bother with the input timers/PWMs if you don't want to.
Software code in the PIC at 40MHz (10MHz in, with x4 PLL on) to create 1MHz would be no more than:
(Example partial illustrated code only, port IO tristate setup and enabling the 4x PLL needs to be configured beforehand.)
mhz_1loop incf portb,F ; If you just want 1 1MHz clock output, use bcf portb,0
movf porta,w ; read input switches
xorlw MODE_1MHZ ; defined switch setting for 1 MHz
btfss status,Z ; skip the next instruction if the switches on porta = MODE_1MHZ.
goto sub_1mhz_loop ; escape this 1mhz generating loop
incf portb,F ; If you just want 1 1MHz clock output, use bsf portb,0
nop
nop
goto mhz_1loop
sub_1mhz_loop incf portb,F ; If you just want 1 1MHz clock output, use bcf portb,0
movf porta,w ; read input switches
xorlw MODE_1MHZ ; defined switch setting for 1 MHz
btfsc status,Z ; skip the next instruction if the switches on porta != MODE_1MHZ.
goto mhz_1loop ; go back into the 1mhz generating loop
nop
call delay_function
incf portb,F ; If you just want 1 1MHz clock output, use bsf portb,0
nop
nop
nop
call delay_function
goto sub_1mhz_loop
With this code,
PORTB output bit 0 = input clock /10, IE 1MHz
PORTB output bit 1 = PORTB bit 0 /2, IE 500KHz
PORTB output bit 2 = PORTB bit 1 /2, IE 250KHz
...ect...
The delay_function would be a 16 bit programmable loop which will loop according to a set number based on the remainder of alternate dip switch settings to generate 100KHz, 10Khz, 1KHz, ...ect... with all their associated /2, /4, /8... outputs.
I would pick the 'PIC18F24Q10' since if you need it, it's available in DIP and SMD.
The DIP version will run from 1.8v to 5.5v @ $1.16 USD. SMD version is 92cents.
-
PS: Do not confuse 1 PPS (1 pulse per second) with 2 ps (2 picoseconds), which would make the PIC a 500 GHz capable device.
500 GHz capable? What are you talking about? That 2ps number is for jitter, not toggle-rate. I have no idea if 2ps number is accurate, but I do know that "van Baak" is certainly familiar with the difference.
-
PS: Do not confuse 1 PPS (1 pulse per second) with 2 ps (2 picoseconds), which would make the PIC a 500 GHz capable device.
500 GHz capable? What are you talking about? That 2ps number is for jitter, not toggle-rate. I have no idea if 2ps number is accurate, but I do know that "van Baak" is certainly familiar with the difference.
As I see it, there are two things to note.
(1). The 2 picoseconds seems to come from the following (my guess), from accessing and reading his website.
20 microseconds high pulse width, every second, via a 10 MHz clock signal.
So 20 microseconds / 10,000,000 = 2 picoseconds.
I.e. 2 picoseconds per clock cycle (of 10 MHz).
So, somehow, he setup an experiment (I can't find the details, anywhere on his website), which did just that, and so came up with the 2 picoseconds.
(2). Ignoring the above (suspicious) result. Can we factually get a ball park figure on the jitter for a similar microcontroller. Apparently, yes.
Microchip do a jitter (related) application note ( http://ww1.microchip.com/downloads/en/AppNotes/00002450A.pdf (http://ww1.microchip.com/downloads/en/AppNotes/00002450A.pdf) ), which is for a similar (but not identical) mcu.
It gives a ballpark figure (by examining various figures in the app note), of around 10 to 20 nanoseconds.
The app note is more about the clock oscillator and stuff, so might not apply to using a timer, but I hope it will do as a rough ball park figure.
Let me quickly do my own ballpark figure.
The MCUs clock rate (max) of around 20 MHz, has a period of 1000 / 20 = 50 nanoseconds.
So 10 nanoseconds would be about 20% jitter of the clock period.
Yes, that sounds reasonable to me.
tl;dr
I have much more faith in the Microchip application note, than some website, which doesn't seem to explain how the measurement was taken, or even define what he means by jitter.
-
PS: Do not confuse 1 PPS (1 pulse per second) with 2 ps (2 picoseconds), which would make the PIC a 500 GHz capable device.
500 GHz capable? What are you talking about? That 2ps number is for jitter, not toggle-rate. I have no idea if 2ps number is accurate, but I do know that "van Baak" is certainly familiar with the difference.
To 5065AGuru and his 2ps PIC jitter comment:
Just to wrap your head around a 2ps jitter. Here is a 'SINGLE 28GHz D-FLIP-FLOP' whose deterministic jitter is 2ps:
HMC853LC3 -> https://www.digikey.com/product-detail/en/analog-devices-inc/HMC853LC3/1127-1239-ND/3881936 (https://www.digikey.com/product-detail/en/analog-devices-inc/HMC853LC3/1127-1239-ND/3881936)
It is a 207$ part for 1 single D-flip-flop.
Whoever spouts 2ps jitter would require a testing scope fixture from Lecroy worth over 1M$ to verify this so called fact.
Unless the manufacturer of the 2ps jitter IC is at least the size of Analog Devices or Texas Instruments, and they specify the exact PCB fixture and leads required to achieve that figure & the IC is over 200$ each, it is completely bogus.
Expect a ~1ns jitter when using the PIC to divide your clock when using the cheaper PICs without the internal PLL. I suspect, but have no evidence, this figure may increase to ~1.5ns with the internal 4x PLL versions. This is assuming you drive the CLK input with a clean oscillator, not a crystal.
(Their IOs on the PIC16/18/12 series are really clean when using a dumb IO pin with nothing more than BSF, BCF or MOVWF command and you drive the CLK input pin from an oscilator. (bit set port F, bit clear port F, move Wreg to port F.))
-
There was a "Simple or Lowpower , cant remember which" div by 5/10 discussion on timenuts not so long ago.
The below was somehow, the condensed outcome.
I seem to remember it was for freq's up to 100MHz
/Bingo
The 74XX160/74XX162 is the decade divider that runs at maximum
clock rate for the chip. Meaning no external feedback is
necessary to make it work at divide by 5/10.
The 74XX161/74XX163 can only divide by powers of 2 at maximum
clock rate. You have to add feedback to divide by 5 and THAT
is what slows it down so much. Dividing by 10 is even slower
in most logic families.
There is also 74XX190 series.
-
(2). Ignoring the above (suspicious) result. Can we factually get a ball park figure on the jitter for a similar microcontroller. Apparently, yes.
Microchip do a jitter (related) application note ( http://ww1.microchip.com/downloads/en/AppNotes/00002450A.pdf (http://ww1.microchip.com/downloads/en/AppNotes/00002450A.pdf) ), which is for a similar (but not identical) mcu.
It gives a ballpark figure (by examining various figures in the app note), of around 10 to 20 nanoseconds.
The app note is more about the clock oscillator and stuff, so might not apply to using a timer, but I hope it will do as a rough ball park figure.
Look, I'm not defending that 2ps number (although I do believe that Mr. van Baak has some expertise in this area), but that uChip app note is, as you noted, about the jitter in the free-running R-C controlled oscillator of their part. This has virtually no relevance to the clock-to-Q timing jitter of a synchronous part like the PIC in question. These aren't even close to being the same thing -- they're not in the same universe, let alone ball park.
-
Look, I'm not defending that 2ps number (although I do believe that Mr. van Baak has some expertise in this area), but that uChip app note is, as you noted, about the jitter in the free-running R-C controlled oscillator of their part. This has virtually no relevance to the clock-to-Q timing jitter of a synchronous part like the PIC in question. These aren't even close to being the same thing -- they're not in the same universe, let alone ball park.
You're right, I agree. My quick skim read through that app note, missed those important facts. It was at least partly, about the internal oscillator.
When the internal PLL is used, with a crystal, I've got another ballpack figure. Via another app note, http://ww1.microchip.com/downloads/en/DeviceDoc/93008b.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/93008b.pdf) . This (For the faster DSpic series), seems to suggest, that when using the PLL, the clock jitter is +/- 3% of the clock frequency = 6% total.
Which would suggest (at 10 MHz), a jitter of about 6 ns. (10MHz=100 ns period, 6% of that).
So, without using the PLL, presumably it would be more like 100 ps, or 1 ns. (Presumably).
Not linked information, is that getting below 100 ps jitter, becomes extremely difficult, because the slightest voltage variation, radio signal interference, thermal noise and other random effects. Cause these (difficult to overcome), variations (Jitter).
I guess we need a time nut metrology time expert, who works (worked) at Microchip (or similar), who can verify (or not), my/our? claims. That 2 ps, is NOT the right figure, and give clues/information as to what the jitter might be, when not using the PLL.
-
I was just following this thread for some reason, had a mega4809 hooked up so just tried to make a freq divider. The main clock has a divider from 1 to 64 (1 2 4 6 8 10 12 16 24 32 48 64) of which the /10 is useful for lower freqs or if you just wanted 1MHz on clkout (and just a few lines of code).
The tca timer is 16bit, and has a freq mode, so made a simple little class to set tca to output all available integer frequencies from 1Hz to 5MHz (55 total choices out of 64k). Below 80Hz the timer prescale starts to get used and the cpu div will use /10 for some of them. Not much code, and half of it is a lookup table for the values I generated (cpudiv, tcadiv, tcacmp, freq).
FreqGenerate10Mhz fg;
while( true ){
Print( oled, "\tHz: %7lu", fg.freq ); //\t is my 'home' command
while( board.sw.isOff() ){}
fg.next(); //5Mhz ... 1Hz
}
The list of available choices-
5M,2.5M,1.25M,1M,625k,500k,312.5k,250k,200k,156.25k,125k,100k,
78.125k,62.5k,50k,40k,31.25k,25k,20k,15.625k,12.5k,10k,
8k,6.25k,5k,4k,3.125k,2.5k,2k,1.6k,1.25k,1k,
800,625,500,400,320,250,200,160,125,100,
80,50,40,32,25,20,16,10,8,5,4,2,1
My meter says it works, but I have no idea how this compares to using logic ic's, and have no idea when the difference starts to matter. It is the simpler option for those that are better at mcu's than dealing with logic ic's, or at least would be the first option to try. An 8 pin avr0/1 would probably do even if a display was wanted (and leaving updi pin for only programming)- pwr/gnd/updi, scl/sda, wo0, switch, extclk. These avr 0/1 need a logic signal to use an external clock, so may still end up using a logic ic to drive a crystal if that is your source.
Even if its not good enough (however defined), it took 15 minutes to get it working and test. If it turns out it does well, then you have a 50cent mcu solution and a square inch of board space needed. If not, you lost 15 minutes of time, plus whatever time it took to test.
-
Maybe even just ask Tom Van Baak how he came to that figure, he's a very knowledgeable, approachable guy and he's the one making the claim.
FWIW, I'd be inclined to believe that he's damn close to being correct because the timenuts community would have called him out on it a *long* time ago otherwise.
That is an interesting comment. I will consider possibly contacting him in the future, about it.
Is he on this forum. Googling for him (here, on EEVblog forums), seems to come up (ironically) with your name and a discussion about him.
I don't seem to be able to find the post, in non-mobile format, and google insists on finding it in the 'other' area (mobile ?).
https://www.eevblog.com/forum/testgear/test-equipment-anonymous-(tea)-group-therapy-thread/155/?wap2 (https://www.eevblog.com/forum/testgear/test-equipment-anonymous-(tea)-group-therapy-thread/155/?wap2)
I suspect, a decently/properly/efficiently programmed MCU (i.e. care taken to make it cycle exact and get the best out of timers and things, not using the PLL, if necessary), should give results at least as good as of the shelf, TTL (modern day equivalents), would. Hopefully even better. Because the internal logic switching speeds should be significantly faster in a MCU, compared to most general logic stuff.
-
Maybe even just ask Tom Van Baak how he came to that figure, he's a very knowledgeable, approachable guy and he's the one making the claim.
FWIW, I'd be inclined to believe that he's damn close to being correct because the timenuts community would have called him out on it a *long* time ago otherwise.
Also FWIW, please remember that in this case jitter has little to do with device speed or propagation time. For the picDiv, jitter will be caused by variations in internal clock-tree and CLK-to-Q prop-delay caused by internal temperature changes, and by the noise figure of the internal mosfets. The noise-figure contribution will be in part reduced by applying a fast rise-time clock input to the PIC (rather than a sinewave).
The more I consider this, the more plausible that 2ps number sounds.
-
Was there a reason why the 74HC4017 wouldn't work for divide-by-10 as vk6gzo suggested in #13? It has a Q5-9 output that provides a 50% duty cycle. So 10MHz in, 1MHz out. Pretty straightforward.
-
Was there a reason why the 74HC4017 wouldn't work for divide-by-10 as vk6gzo suggested in #13? It has a Q5-9 output that provides a 50% duty cycle. So 10MHz in, 1MHz out. Pretty straightforward.
No reason, it's a good solution for the 1/10 problem.
-
I emailed Tom Van Baak about the 2ps, and got this very nice reply:
Thanks for the mail. Given the recent interesting eevblog thread I will try to write something up and post the gory details. But here's a summary for you.
I chose the PIC12F675 in the late 90's because it was a ubiquitous, dirt-simple, fully-synchronous, perfect-cycle-counting MCU. Most MCU and CPU these days employ all sorts of tricks to improve net CPU performance but as a result old fashion cycle counting timing suffers. Of course real engineers would use FPGA for frequency division these days. And if anyone knows of one in a 8-pin DIP for $1, I'll switch tomorrow.
The story continues with the various TAPR pulse distribution amplifiers and then the TAPR frequency divider, which used some of my PIC dividers. In particular I designed most of the dividers to be pin-compatible with John Ackermann's (N8UR) TAPR T2-mini board, a delightful, compact, BNC-to-BNC digital frequency divider.
Since John and I are serious time nuts we were curious about the "noise" (jitter, wander, drift, etc.) that an inline divider would introduce -- not just the PIC chip itself but also the fancy input sinewave signal conditioning and the output buffer. So in 2012 I tested a pair of T2-mini using a TimePod 5330A; not a cheap instrument, and easily capable of sub-ps resolution.
Like I said, I'll see if I can write up the entire test process, but one of the plots is here:
http://leapsecond.com/pic/T2mini-jitter.png (http://leapsecond.com/pic/T2mini-jitter.png)
The ADEV is about 3e-13 @ 1s and the RMS jitter is 8e-13. So that's where the "under a few ps of jitter" comment came from. Feel free to copy/paste this reply. I can follow up with more details shortly.
/tvb
www.LeapSecond.com (http://www.LeapSecond.com)
I think someone here owes Tom an apology...
-
I emailed Tom Van Baak about the 2ps, and got this very nice reply:
Thanks for the mail. Given the recent interesting eevblog thread I will try to write something up and post the gory details. But here's a summary for you.
.....
.....
Like I said, I'll see if I can write up the entire test process, but one of the plots is here:
http://leapsecond.com/pic/T2mini-jitter.png (http://leapsecond.com/pic/T2mini-jitter.png)
The ADEV is about 3e-13 @ 1s and the RMS jitter is 8e-13. So that's where the "under a few ps of jitter" comment came from. Feel free to copy/paste this reply. I can follow up with more details shortly.
/tvb
www.LeapSecond.com (http://www.LeapSecond.com)
I think someone here owes Tom an apology...
:palm: Allan Deviation -> https://en.wikipedia.org/wiki/Allan_variance (https://en.wikipedia.org/wiki/Allan_variance) is not the same as 'Deterministic Jitter' or absolute Jitter which are what's relevant when going from 10MHz to 1MHz. When going from 10MHz to 1KHz or less, the Allan Deviation figure becomes more relevant. Just look at the Allan graph, as you go from .01s up to 100s, notice how the jitter on the plot drops? How can that be possible unless you are not actually measuring the jitter noise output of the pin referenced to the 10MHz input, but, measuring the jitter VS frequency? At any frequency output, the pin jitters and it's 'Deterministic Jitter' will remain the same no matter what spectrum of time you analyze it's output at.
For god sakes, the 'Timepod5330A' test instrument used to measure the PIC's output is a 30MHz spectrum analyzer. Of course it cannot measure the PIC CLK input pin to - IOpin Jitter in any way, it only measures the average output frequency gathered over 10 minutes using only 126K sample points and can deliver an RMS Jitter reading based on the quality of the source clock feeding the PIC since the PICs output pin and clk timing is beyond the instrument's bandwidth capabilities, the output will look as good as the source feeding the PIC.
The PIC outputs are clock D-Flip-Flop latched to the CLK input on the cheap old PICs without any other circuitry in the way. Since the 1Hz code uses no peripherals in those old PICs and it only feeds that 'D-flipflop' input a high and low once in a blue moon, after all the time, that Allan Deviation with reference to the main clock input will look damn near perfect as it is virtually perfect. It's similar to a 74AC74 D-Flipflop clocked at 10MHz, except the PIC's CLK input is also amplified since it was designed to accept a crystal oscillator input.
You need a good 5-20Gsps scope triggered on the PIC's clk input & IO pin, reading an IO pin cycling as fast as possible, and over trillions of samples, not 126Kpoints, measuring the Tmax-Tmin delay on the 50% rise and fall of the IO pin & you will get the Absolute Jitter of the PIC's IO pin VS CLK input, and, it is not as tiny as 2ps, this I can guarantee.
The Allan deviation test and setup chart only says that the PIC can divide the CLK input by 10 million perfectly and that the RMS jitter over 10 minutes as per spec on the provided graphic is 2ps. The response of the PIC's clk input and IO rise and fall time relationship is outside the domain of what a '5330A Programmable Cross Spectrum Analyzer' was designed to measure, IE, except for the output being a square wave, you will be measuring the quality of your source clock you are feeding the PIC.
-
Suggesting a "solution" needing software development (not a lot), a programming and debugging environment, programming/burning hardware etc. instead of just buying a 25 cent part with far superior timing characteristics (74HC390) and just using it 'as is' is "better"?
Wow. I see parallel universes that seem to consist of pull-down menus, PIC and ATMega brainwash.
If those contributors worked with me, they'd be fired on the spot. Just throwing any 8-pin MCU at any problem is not engineering to me.
Sorry, had to get that off my chest.
I'm guessing you don't ever use FPGAs, preferring football field size PCB layouts and shipping container size nuclear reactor PSUs.
Good for you, I like people who can live in the past.
Can you read? I only said that the knee-jerk reaction of selecting an MCU for a problem that a single standard logic IC can solve just as well is overkill. I work with FPGAs and MCUs myself, but apply them where they belong. Don't troll.
-
Why do you think I'm a 'guy'? And you apparently still can't read.
-
Says the guy who suggested anyone who wanted to use a micro 'isn't engineering' and should be sacked.
Seriously, that is some new level of gatekeeping that should be called out. I've seen managers bully people in a similar manner, end result: the best engineers quit, the "cogs in the machine" stayed, which I guess is what they wanted anyway.
-
Why would you introduce a counter, when a simple single transistor 1 MHz oscillator can be injection locked to the 10 MHz source? An injection locked oscillator is the easiest job in the solar system.
I would like to see that "fleshed out" - I've never heard of an injection locked divider, and a quick look around suggests that they need at least two transistors, inductors, and a sinusoidal input. (does the OXCO mentioned by the OP provide a sine wave?)
Not that a tuned transistor circuit will necessarily come out cheaper or smaller than a chip (or a microcontroller, for that matter.)
-
:popcorn:
-
My understanding of his code is that it doesn't use PLL or timers (can't remember if they're even available on the PIC chips he used, 12C508 I think) so they can't add to the jitter, instead I think it relies on cycle exact code.
I'm mired in some STM32 code while attending a virtual radio convention and it's been a while since I looked at PIC .asm so I'm not going to dig into it but the code is nice and simple, it's available for download on his website (1) and its performance has been widely discussed on the Timenuts mailing list, there has been quite a bit of discussion as to why the dirt cheap, simple architecture of the 8 bit PIC chips can make accurate, low jitter divider so well.
The take away is that it's good and well regarded by people who chase parts per billion accuracy and notice jitter at levels most of us just don't care about.
TimeNuts list archives are searchable on the web, febo.com (2) to dig through for the aforementioned discussions.
(1) http://www.leapsecond.com/pic/picdiv.htm (http://www.leapsecond.com/pic/picdiv.htm)
(2) http://lists.febo.com/pipermail/time-nuts_lists.febo.com/ (http://lists.febo.com/pipermail/time-nuts_lists.febo.com/)
Thanks for the nice reply. It has taken me a while to go through the links, and look at some of the stuff.
There is a lot of information/posts in those threads.
To everyone:
This Jitter thing, has turned out to be way more complicated, than I was expecting. But I'm learning new stuff, and it is fun and interesting.
The following app note, seems to explain about the terminology surrounding jitter, and goes into details about some of it:
https://www.nxp.com/docs/en/application-note/AN4056.pdf (https://www.nxp.com/docs/en/application-note/AN4056.pdf)
It seems that for every new thing about jitter, I'm learning/understanding in this thread. I'm also realising that there are another two things that I DON'T understand about jitter.
tl;dr
If I appear to have gone relatively quiet in this thread, it is because I come to the realisation that there is much for me to learn about jitter. Before potentially making a fool of myself, and attempting to tell others, how/why jitter works the way I thought it did.
-
Here is TI's own measurements of a simple modern 3.3v CMOS 74LVTH125 buffer capable of over 100MHz:
(https://www.eevblog.com/forum/projects/easiest-way-to-divide-10mhz-to-1mhz/?action=dlattach;attach=1061478)
It has a 102ps jitter. I would expect an older half-speed 5v 74AC125 to have a 204ps jitter. An old PIC probably cannot do better than 204ps, however, with an entire CPU inside on a die, let's give them the benefit of the doubt and say a 200ps output jitter and my scope measurements in the past with that 1ns jitter noise was inside the error of my 500MHz, 5Gsps setup and PCB noise circuitry.
200ps is 2 orders of magnitude worse than 2ps.
-
To everyone:
This Jitter thing, has turned out to be way more complicated, than I was expecting. But I'm learning new stuff, and it is fun and interesting.
When looking at jitter in these circumstances, remember, there are 2 different issues which have been tackled in this thread and mixed up erroneously.
When you look at CLK jitter on these MCU's data sheets, they are talking about their circuitry's capability of generating a pure clock from a crystal with all their inherent flaws/noise/jitter introduced by many local signals and loads switching throughout the MCU and adjacent pins and power supply noise. Things get even worse when you look at these MCU's built in oscillators which are usually RC based.
What the OP asked for is a 10MHz divider where we are assuming that his 10MHz source is perfect.
Force feeding any of these MCU's CLK input with a perfect 10MHz external clock source, defining how sub-nanosecond timing response of the MCU's core and switching speed of the output pins in relation is actually not defined in the data sheets you are looking at. The closest to thing to this is my old measured 1ns jitter noise on the scope with an old PIC16C/18F series MCU.
This brings us to Allan Deviation measurements. Think about this one carefully, if I have a 1Hz square wave coming out of a PIC & measure it for 10 minutes as in the provided chart, IE 600 cycles. How is it possible to determine 2ps deviation on that IO pin with only 600 transitions compared to the 10MHz source?
The 2ps Deterministic Jitter of that Analog Devices HMC853LC3 D-flifflop was measured running at 25GHz with an Agilent 86100C 33GHz DCA, a scope shot in the data sheet which had to run billions of clock cycles to achieve that 2ps measurement. To analyze a PIC output running at 1Hz with the same fidelity, you would not achieve this mark in 10 minutes, but, you would need to run the analysis for around 792.7 years. 600 cycles of the IO pin, twice a second is not enough to tell you the true extent of the PIC's CLK input to an IO output. And what's worse is that the Allan Deviation is a RMS figure not showing you any spurious peaks. Allan Deviation is a measurement of the quality of a clock for it's total frequency and measuring 1Hz, it's tough to find noise unless your 1Hz source is a true sine wave free of distortion.
-
>I have a few Tektronix TM500 modules that require a stable 1MHz frequency source for testing and calibration.
If your source is a 1 million pico second clock, how would pico seconds in double/triple digits even enter the picture? How can any instrument that takes 1MHz as a timing source be affected by these small jitter values? If they can, then does that mean you can use them to measure ps (I suspect not)?
Maybe worrying about ps jitter is not necessary when you are a mile away from it, and using pretty much anything to divide 10 to 1 will work equally well. I don't know.
Build one of each version, and report back.
-
If you want to maintain a 1:1 mark/space on the output, then you need to connect it so that the divide by 5 stage is followed by the divide by 2 stage.
That sounds logical, but then the two stages are different.
I think it's better to have both stages divide by the sqrt(10).
-
I have gotten pretty good results by estimating jitter from the transition time and supply or ground noise which changes the threshold voltage. The problem is that the transition time of internal nodes may not be known, but it can be roughly calculated for a given process by measuring jitter in a simpler device.
Usually though, I just do not care because I know single ended logic produces jitter from 10s to 100s of picoseconds just from the above source. If I want low jitter, then I use differential signaling to remove the effects of supply and ground noise (ECL) or I carefully decouple and regulate the supply voltage of simple single ended logic. Complex logic is never a place to look for low jitter.
-
>I have a few Tektronix TM500 modules that require a stable 1MHz frequency source for testing and calibration.
If your source is a 1 million pico second clock, how would pico seconds in double/triple digits even enter the picture? How can any instrument that takes 1MHz as a timing source be affected by these small jitter values? If they can, then does that mean you can use them to measure ps (I suspect not)?
Maybe worrying about ps jitter is not necessary when you are a mile away from it, and using pretty much anything to divide 10 to 1 will work equally well. I don't know.
Build one of each version, and report back.
I'm not the one talking about jitter here. :)
I just want to divide 10MHz down to 1MHz in a way to be 'good enough' for my TM500 modules, 6 to 8 display digits depending on specific module etc. :-/O
-
>I have a few Tektronix TM500 modules that require a stable 1MHz frequency source for testing and calibration.
If your source is a 1 million pico second clock, how would pico seconds in double/triple digits even enter the picture? How can any instrument that takes 1MHz as a timing source be affected by these small jitter values? If they can, then does that mean you can use them to measure ps (I suspect not)?
Maybe worrying about ps jitter is not necessary when you are a mile away from it, and using pretty much anything to divide 10 to 1 will work equally well. I don't know.
Build one of each version, and report back.
I'm not the one talking about jitter here. :)
I just want to divide 10MHz down to 1MHz in a way to be 'good enough' for my TM500 modules, 6 to 8 display digits depending on specific module etc. :-/O
LOL, the 74HC4017 decade counter will be all you need. Ignore the rest of this thread...
Tie the CLK to the CLK input, turn on the enable (CE), GND the reset & use the 'TC' (ten count) output as your 1 MHz output.
-
The simplest method to me for a 10MHz to 1MHz divider is a single 74HC390, but if I am going to get a PCB made anyway, and I have a tube of 25 Hitachi chips sitting right beside me that I bought for 370yen, I may as well add a few extras to get some more frequency options. It's not like I'm spending much cash to do so when they cost me 15 cents a pop...
I remember when 370 Yen was US$ 1.03.
A 74HC390 or other 10:1 logic IC is an easy solution (and unlike a locked multivibrator, won't drift out of lock with aging), but a MCU or FPGA could be the best solution if the parts are already there and have spare pins/storage space, or added functionality is desired.
-
The more I consider this, the more plausible that 2ps number sounds.
I emailed Tom Van Baak about the 2ps, and got this very nice reply:
----------------CUT-------------------------------------------------------------------------------
I think someone here owes Tom an apology...
I'm not sure, if you were aiming that comment (apologise), at me, or other(s), in this thread. But, I will make my own excuses, anyway.
We should be able to technically challenge value(s), and statements. Without needing to worry too much about being rude to the original author(s). Such as, commenting that the value(s), in a particular datasheet, seem to be overly optimistic, and things like that.
The details (such as 2 ps), are on a freely available open/public website, so criticising them, shouldn't be a big issue.
I'm not sure what the word is to describe the concept I'm feeling about the 2 ps claim (or even if such word(s) exist). So, let me describe it in words, using an analogy.
But first, a quick summary of the concept. You can't always simply rely on using (possibly expensive/quality) lab equipment measurements, to make claims about certain things.
Analogy:
You want to make a highly accurate voltage reference, and have available a very accurate voltage meter, with a large number of digits of resolution. So, 10 1N4148 diodes are connected together, on a PCB, in series.
By (sheer luck, in reality), it reads 6.500,000,000,002 Volts. Its built in maths function displays:
6.5 Volts plus error of 2 picovolts.
So one proudly claims to have made an accurate 6.5 Volt reference, carefully measured to be no more than 2 picovolts out. Out of very cheap, common garden 1N4148 diodes.
The reality of course, is that the slightest change in temperate, ageing drift, component to component variation, noise, etc etc. Will result in the voltage changing by way, way more than 2 picovolts.
tl;dr
The person who did the measurements, in the analogy, was basically correct, their meter may well be functioning perfectly and given accurate results (within its specification). But, unfortunately, there seems to be a failure, to understand the difference, between taking some measurements, and a circuits real life, production ready, characteristics.
In other words, 2 ps (picoseconds), is such a small amount, that the slightest change in temperature, noise, drift, interference (e.g.radio signals), changes in parasitic effects, etc etc. Will tend to make the jitter, considerably larger than that.
So yes, (I am trying to be technical/scientific/factual here, NOT rude), I am suspicious of the 2 ps claim.
-
So yes, (I am trying to be technical/scientific/factual here, NOT rude), I am suspicious of the 2 ps claim.
Based on his measurements, the RMS Jitter Allan deviation (ADEV) of a square wave generated from a 10MHz reference source which may have been used as the reference for the 'Timepod 5330A' spectrum analyzer from http://www.miles.io/timelab/beta.htm (http://www.miles.io/timelab/beta.htm), has generated a proper Allan deviation (ADEV) measurement,
Again, the provided 'Allan deviation' is:
The Allan deviation (ADEV), also known as sigma-tau, is the square root of the Allan variance, σ y ( τ ) {\displaystyle \sigma _{y}(\tau )} {\displaystyle \sigma _{y}(\tau )}.
Taken from line3 of wiki page https://en.wikipedia.org/wiki/Allan_variance (https://en.wikipedia.org/wiki/Allan_variance).
It is a RMS rounding of the error taken over the 10 minute measurement.
This is all written in borders pf the image provided by 'Tom Van Baak' here:
(http://leapsecond.com/pic/T2mini-jitter.png)
This is not the same as evaluating the time from clock input to the pic to IO output's rise and fall over millions of cycles measuring the minimum time of transition to the maximum time of transition as seen in these scope shots here:
(https://www.eevblog.com/forum/projects/easiest-way-to-divide-10mhz-to-1mhz/?action=dlattach;attach=1061478)
and here:
(https://www.eevblog.com/forum/projects/easiest-way-to-divide-10mhz-to-1mhz/?action=dlattach;attach=1062536)
Wait only 10 minutes for 600 transitions, and average the noise over time + shrink it even more by taking the RMS figure, and yes, a PIC with something like +/-100ps jitter will spit out a 2ps ADEV figure.
-
The more I consider this, the more plausible that 2ps number sounds.
I emailed Tom Van Baak about the 2ps, and got this very nice reply:
----------------CUT-------------------------------------------------------------------------------
I think someone here owes Tom an apology...
I'm not sure, if you were aiming that comment (apologise), at me, or other(s), in this thread. But, I will make my own excuses, anyway.
[...]
I guess I was reacting to the "scam" and "snake oil" comments. I'm not going to go back up-thread to figure out who said what, I would rather move along.
Tom has provided plots that appear to support that 2ps number. Some have suggested that his measurement technique was inappropriate, and so that number is incorrect. I consider that to be a perfectly reasonable type of comment -- in fact, this type of discussion is one of the main reasons I hang out on eevblog. I am really looking forward to learning more about the finer points of jitter measurement.
Looking at Tom's Allan Deviation chart, I believe that he is not measuring the output of a 1 Hz picDIV, but one with a much smaller divisor. I can't figure out from the plot details what frequency is being used, the math doesn't give me plausible numbers (so I am obviously not interpreting them correctly). But with a higher-frequency signal being measured it's not going to take as long to get a useful sample-set. I hope that Tom will chime in here with more detail.
-
This is not the same as evaluating the time from clock input to the pic to IO output's rise and fall over millions of cycles measuring the minimum time of transition to the maximum time of transition as seen in these scope shots here:
(https://www.eevblog.com/forum/projects/easiest-way-to-divide-10mhz-to-1mhz/?action=dlattach;attach=1061478)
Wait only 10 minutes for 600 transitions, and average the noise over time + shrink it even more by taking the RMS figure, and yes, a PIC with something like +/-100ps jitter will spit out a 2ps ADEV figure.
That TI jitter plot is showing the effects of having multiple outputs on the same device switching at different rates. I don't think we can use that to see the jitter when only one output is switching. True, the PIC has a lot going on inside, but only one output is switching, and that probably has the most influence on Vdd and GND noise-related jitter. It does look like the jitter is correlated with the amount of ground-bounce.
As I mentioned above, that Allan Deviation chart tells me that Tom was not measuring a 1Hz signal, (it shows a 4ms sample interval, does that mean a 250 KHz signal?) Or am I wrong? (won't be the first time)
-
As I mentioned above, that Allan Deviation chart tells me that Tom was not measuring a 1Hz signal, (it shows a 4ms sample interval, does that mean a 250 KHz signal?) Or am I wrong? (won't be the first time)
I cannot comment on this. We need more information from Tom on his actual test bench setup.
But, remember:
(https://www.eevblog.com/forum/projects/easiest-way-to-divide-10mhz-to-1mhz/?action=dlattach;attach=1062688)
Allan Deviation measurement is a summation and square root of the Allan Variance.
It is not a measurement of the longest observed delay from input to output MINUS the shortest observed delay from input to output over millions of cycles. IE: Deterministic Jitter. Allan Deviation is a cycle-to-cycle average of timing noise. Average out that TI gate over many more cycles and take the RMS average cycle to cycle noise and it will shrink down to 1ps. If you carefully read the Analog Devices datasheet, you would have seen they quoted the random jitter noise as 0.2ps, not the same as the deterministic jitter of 2ps. (Sort of how I know no one deeply scrutinized much of what is being said & presented here... Otherwise someone should have presented that number.)
Now, all we need to do is re-clock the PIC's 1 Hz output into that D-Flipflop with quality balanced CLK driving it's differential CLK inputs and the Allan Deviation would be down in the femto-second range.
-
That TI jitter plot is showing the effects of having multiple outputs on the same device switching at different rates. I don't think we can use that to see the jitter when only one output is switching. True, the PIC has a lot going on inside, but only one output is switching, and that probably has the most influence on Vdd and GND noise-related jitter. It does look like the jitter is correlated with the amount of ground-bounce.
I do not remember exactly what instrument it was, but I remember a story about a sampling oscilloscope that someone noticed was not meeting its jitter specification and the cause was the "heartbeat" output which was directly driving an LED creating a 10 picosecond shift in the trigger timing. A firmware patch disabled the heartbeat during sampling to fix the problem.
CMOS driving CMOS loads should be much better but I have not had an opportunity to verify this.
-
As has been mentioned, we are talking about different types of jitter: deterministic vs random. As far as I can tell, the folks who are analyzing frequency standards are looking at RMS random jitter. In that case, wouldn't the 2ps number be the appropriate one? (assuming the measurement was done correctly) The claim would then be that the picDIV would likely add less than 2ps to the measured RMS jitter of a given clock.
Yeah, when looking at sampling bits on a high-speed data stream I mainly care about the pk-pk jitter, and its distribution. This helps me work out the BER (bit error rate). In that case the 2ps RMS number wouldn't be the only thing to look at.
Question: Can't the Allen Deviation (or related measurements) also capture deterministic jitter? I can envision a synthesized clock that has a very deterministic jitter component, caused by PLL update rates, or fractional divider artifacts, among others. Clock recovery circuits can also display data-dependent jitter (which would be as deterministic as the data, and certain line codings might introduce these artifacts even with random data). I believe that this type of jitter will show up as spikes in the Allen Deviation chart, and won't disappear after averaging.
I do wish this discussion has a different title, as we have digressed from the original topic in a very interesting direction.
-
As has been mentioned, we are talking about different types of jitter: deterministic vs random. As far as I can tell, the folks who are analyzing frequency standards are looking at RMS random jitter. In that case, wouldn't the 2ps number be the appropriate one?
Yes, finally...
As long as you call it Allan Deviation jitter.
As you've seen in the Wiki link, you take as many samples as possible and accumulate sum the difference in time from point to point & divide by the total number of samples.
When evaluating the performance of your clock over a long period of time, the 'mean error' is what's important.
When evaluating the switch time response of a silicon device best and worst possible cases under a magnitude of repetitive cycles, singling out and capturing the odd absolute worst cases was the jitter measurement I was after when dividing 10MHz down to 1MHz as it was a measurement once can do on a mid quality scope with a reasonable degree of assurance within the scope's capabilities.
-
Here is TI's own measurements of a simple modern 3.3v CMOS 74LVTH125 buffer capable of over 100MHz:
(https://www.eevblog.com/forum/projects/easiest-way-to-divide-10mhz-to-1mhz/?action=dlattach;attach=1061478)
As it turns out, that plot is relevant here.
Since I have some of the picDIV dividers I thought it might be worth testing one. In this case it was a PIC 12F675 with the PD64 code in it, which has four outputs - divide by 64, 128, 256 and 1024.
(source - http://www.leapsecond.com/pic/src/pd64.asm (http://www.leapsecond.com/pic/src/pd64.asm) )
It was just on a solderless breadboard and clocked from a 5MHz 5V square wave output OCXO. The oscilloscope used was a 500MHz HP54515B.
The first tests were done on the divide by 64 output.
The top trace is the main timebase (20us/div). The lower one is the delayed timebase (1ns/div), which was used to show, which was used to show several successive edges.
(https://www.eevblog.com/forum/projects/easiest-way-to-divide-10mhz-to-1mhz/?action=dlattach;attach=1079280)
To make the jitter a bit more obvious and fit more traces on the one plot the scope was set to 400mV/div. For the 400mV traces the scope was left on Auto-store for 5 seconds, which shows all the accumulated samples over that time.
From left to right, the first trace shows the edge that is being used for the trigger. The next four traces show the next four rising edges at approx 12.8, 25.6, 38.4 and 51.2 us (they are slightly offset so they are properly separated).
(https://www.eevblog.com/forum/projects/easiest-way-to-divide-10mhz-to-1mhz/?action=dlattach;attach=1079284)
Triggering is now set to falling, and the these edges have a lot more jitter.
Even looking at the trigger edge, it is obviously different on different cycles.
(https://www.eevblog.com/forum/projects/easiest-way-to-divide-10mhz-to-1mhz/?action=dlattach;attach=1079288)
This shows the first falling edge at 12.8us delay:
(https://www.eevblog.com/forum/projects/easiest-way-to-divide-10mhz-to-1mhz/?action=dlattach;attach=1079292)
The delays are again about 0, 12.8, 25.6, 38.4 and 51.2 us, but there are now up to four separate traces on each.
(https://www.eevblog.com/forum/projects/easiest-way-to-divide-10mhz-to-1mhz/?action=dlattach;attach=1079296)
Next I tested the divide by 1024 output. Here the trigger and next 4 rising edges are at about 0, 1024, 2048, 3072 and 4096 us delay. Again, there is little difference between the different edges.
(https://www.eevblog.com/forum/projects/easiest-way-to-divide-10mhz-to-1mhz/?action=dlattach;attach=1079300)
However, the falling edges for the divide by 1024 output are very much better than for the divide by 64 output.
First the trigger edge:
(https://www.eevblog.com/forum/projects/easiest-way-to-divide-10mhz-to-1mhz/?action=dlattach;attach=1079304)
Now the trigger and next four falling edges. There's none of the multiple different delays and edge shapes that were visible on the divide by 64 output:
(https://www.eevblog.com/forum/projects/easiest-way-to-divide-10mhz-to-1mhz/?action=dlattach;attach=1079308)
The time between a rising clock edge and an output pin changing is around 25ns:
(https://www.eevblog.com/forum/projects/easiest-way-to-divide-10mhz-to-1mhz/?action=dlattach;attach=1079312)
(https://www.eevblog.com/forum/projects/easiest-way-to-divide-10mhz-to-1mhz/?action=dlattach;attach=1079316)
Since this is not a brilliant test setup, and the settings have the scope working at its ragged limit, it might be best not to look too closely at small differences, but I think that it gives a fair idea of what's going on.
As with the SN74LVTH125, there is more of a problem for the faster falling edges.
Having only one frequency output - whether fixed or adjustable by inputs to the PIC - would help, although just adding flip flops to reclock any outputs would probably be best for performance.
It would be interesting to check it with a faster scope to see what exactly is going on.
-
Well, I got mine working. Pretty shitty output, but it'll do the job of calibrating Tektronix TM500 modules.
https://youtu.be/GlKWexGWoXw