EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: NivagSwerdna on May 31, 2017, 07:39:03 am
-
I bought a second hand Rb frequency reference that outputs a 10MHz sine
What is the smallest/cheapest/simplest way to divide by 10M to get a 1PPS pulse?
Thanks in advance
-
After a bit of googling...
http://www.leapsecond.com/pic/picdiv.htm (http://www.leapsecond.com/pic/picdiv.htm)
That's quite a sweet solution... and apparently it works with the sine rather than square clock.
-
Ironically the cheapest way maybe a 50c mcu.
Clock it from the 10mhz and setup a timer to toggle a pin at 1pps in hardware
-
It all depends what you want to do with 1pps. If it is only to drive an alarm clock, then it is fine to do that with a MCU.
If you are actually going to feed it to a discipline clock generator which will use 1pps input to drive PLL in order to generate a perfectly phase aligned clock, then think twice. Your MCU is likely to generate quite some jitter that will ruin your output clock.
That's why all GPS modules have 1pps output, but timing optimized GPS modules are so expensive -- the former generates 1pps for counting seconds, the latter generates 1pps for disciplining an oscillator, hence phase alignment (jitter) is crucial.
A typical microcontroller should not generate any jitter at all (except from some analogue jitter due to the clock input not being perfect) as long as you use a constant divider factor, because everything runs synchronous to the input clock. Small microcontrollers have a highly predictable diming, even when doing the division in software.
As far as I know the 1pps signal on GPS modules is generated in software. Fast microcontrollers with cache don't have a very predictable interrupt latency, therefore the exact timing will vary slightly.
-
It all depends what you want to do with 1pps. If it is only to drive an alarm clock, then it is fine to do that with a MCU.
If you are actually going to feed it to a discipline clock generator which will use 1pps input to drive PLL in order to generate a perfectly phase aligned clock, then think twice. Your MCU is likely to generate quite some jitter that will ruin your output clock.
If you are clocking the micro from the GPS 10MHz clock, and the division is performed by a timer rather then software, then you are only adding the residual jitter from the hardware timer. This isn't something you'd ever see specified in a datasheet, do you have any numbers?
Disciplined clock sources perform a lot of averaging on the 1PPS signal anyway, so a small amount of jitter shouldn't be a problem.
-
The original link, seems to say it is less than 2 ps of jitter ...
Output accuracy is equal to input accuracy. Jitter is extremely low since the PIC is a synchronous device. Recent measurement suggest it is less than 2 ps.
http://www.leapsecond.com/pic/picdiv.htm (http://www.leapsecond.com/pic/picdiv.htm)
-
The original link, seems to say it is less than 2 ps of jitter ...
Output accuracy is equal to input accuracy. Jitter is extremely low since the PIC is a synchronous device. Recent measurement suggest it is less than 2 ps.
http://www.leapsecond.com/pic/picdiv.htm (http://www.leapsecond.com/pic/picdiv.htm)
I don't know how it's measured, but according to some FPGAs' datasheets, even hard PLLs can't guarantee to generate such clean clock. I wonder how can an MCU do that.
Also, jitter is not jitter. There are different kinds of jitter, measured in timing domain (period jitter) or in frequency domain (deferred from phase noise), and there are integration frequency range and RMS vs pp. I don't know what the 2ps is.
Maybe PIC is exceptionally good in distributing clock internally, but can this stand for other MCUs or PLDs is still questionable.
If I'm to do this in a high demand system (high speed ADC/DAC, SFP+, high end audio, etc.), I would use a professional clock generator from TI or Micrel or Maxim, at least I have a very certain jitter number coupled with actual measured plots showing how it's done and per what standard.
I agree with you.
2 Pico Seconds sounds way too good.
For all the author knows. Some Pic devices (even with identical part numbers), could be considerably worse than others and/or his results could be wrong or out by a bit. Maybe there are certain critical temperatures (or supply voltages, etc), where the device ends up being especially jittery.
E.g. Measure a few identical type number and manufacturers silicon diodes, and the leakage current maybe less than a nanoamp.
But there could still be some (<1%) of the same identical type of diodes (but different batches), which are closer to the datasheet limit of a microamp. Because of production/process variations, even from the same manufacturer/factory.
-
An Arduino? An Arduino Pro Mini is a couple of bucks and quite small.
Set timer1 to 'external clock', connect a wire to the input pin, divide it down.
(nb. Pretty much any microcontroller can do this - Atmel Tiny85 comes in an 8 pin package if you want something smaller or use a PIC if that's your cup of tea)
Whether that qualifies as "easy" or not is up to you... :popcorn:
Edit: Ooops! 10MHz is too fast for a 16Mhz Arduino. You'd have to put in an external divider chip to bring it down a bit, eg 74LS73 Dual flip-flop.
-
If you want it to be 'cool' you can use decade counters:
eg. 74LS163
http://users.ece.utexas.edu/~valvano/Datasheets/74LS163.pdf (http://users.ece.utexas.edu/~valvano/Datasheets/74LS163.pdf)
Each one will divide by ten, just join a few together.
(...and if you want to be 'retro' you can do it all with 74LS flip-flops. The details are left as an exercise for the reader. :popcorn: )
-
Use a PSOC 4, plus you get an ARM core, other random logic, LUT,
ADC, OpAmp......
See attached screenshot.
If you need 10 pps, .1 pps, simple, just add another divider component (a
component is an internal chip resource) to schematic. But would need a 5LP
part to do that. Or stay with PSOC 4 and do a mixed HW and SW counter
using interrupts.
Regards, Dana.
-
I've done big divides before using basic PIC's. Works great, just don't use the PLL - something really simple like the 16F54. You will get a lower jitter if you drive the PIC from a low noise supply, the jitter will mainly be down to the schmitt trigger in the CLOCK input in the PIC.
You could always use the PIC to gate a flip-flop driven by the 10MHz.
Have you a method of measuring jitter in those regions - 2ps seems optimistic and difficult to test.
-
FWIW my PICDIV attempt from last year.
http://www.anderswallin.net/2016/04/picdiv-frequency-divider/ (http://www.anderswallin.net/2016/04/picdiv-frequency-divider/)
I'm not sure you absolutely need the sine-to-square converter-chip, biasing the PIC CLK-pin to half-way and AC-coupling a ~1Vpp sine-wave might be just as good?
Directly out of the PIC12F675 I got quite a low voltage (700mV) into 50R and not that great of a rise-time (4 ns).
Perhaps adding a simple buffer like 74HC04 or 74HC14 with three outputs or so in parallel would drive 2-3 V into 50R with a better rise-time.
With a typical good counter like a 53230A that has a 20ps single-shot spec I have a feeling it is quite hard to measure any added jitter that the PICDIV would generate - in other words it should be good enough for most purposes. I didn't try this last year but might return to this at some point..
-
The late Ulrich B , made an AVR PPSDIV (Picdiv lookalike)
The M8 version ought to be easy to adapt to an arduino
http://www.ulrich-bangert.de/html/downloads.html (http://www.ulrich-bangert.de/html/downloads.html)
/Bingo
-
If it needs to be more accurate, use an extra high speed (e.g. ECL, 74AHC or better) flipflop to synchronize the output of the divider to the reference clock. It is only that last sync stage that sets the jitter.
The jitter a divider made from a small µC (just make sure it does not use an internal PLL) is mainly form the internal synchronization circuit. So one can expect it about at the same level as one might get from a few 74HC flipflops, maybe a little more. The 2 ps might be a little on the optimistic side, but not much. These 2 ps are just relative to the 10 MHz reference clock. So for the 1 second period there would be additional jitter from the source, that could be at least of comparable size.
-
Any divider solution with a PIC is the simplest and cheapest one.
The asm code is freely available, so if you have a programmer, just burn the code on your own.
Besides Ulrich Bangert and Tom van Baak, there's Brooke Clark http://www.prc68.com/I/PRC68COM.shtml#TVB, (http://www.prc68.com/I/PRC68COM.shtml#TVB,) and the TAPR, which offers the best solution kit TADD-2, with input amplifier / sine square converter, divider and output driver / distribution, http://www.tapr.org/kits_tadd-2.html. (http://www.tapr.org/kits_tadd-2.html.)
They also host different asm codes somewhere.
I used PIC 16F88, or 16F690, and had to slightly modify the code.
Using ordinary TTL divider-by-10 is no good idea, because these are mostly asynchronous dividers, having big jitter.
The delay time is strongly temperature dependent, also on synchronous dividers, afaik, so not good at all for T.I. measurements.
So the PICDIV solution is also the best technical one.
Frank
-
If you want it to be 'cool' you can use decade counters:
eg. 74LS163
http://users.ece.utexas.edu/~valvano/Datasheets/74LS163.pdf (http://users.ece.utexas.edu/~valvano/Datasheets/74LS163.pdf)
Each one will divide by ten, just join a few together.
(...and if you want to be 'retro' you can do it all with 74LS flip-flops. The details are left as an exercise for the reader. :popcorn: )
This is the approach that James Miller does (to get down 10 10kHz so not quite as far) in his simple but good GPSDO:
http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm (http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm)
Each chip can divide by 100 so 4 of them would be required, rather a lot of board space but simple and cheap.
-
I'd use a small CPLD like the XC9536, I'm already set up to work with those though.
-
Using ordinary TTL divider-by-10 is no good idea, because these are mostly asynchronous dividers, having big jitter.
You can fix this by clocking the output through a good flip flop (as long as the jitter is less than 1 clock cycle).
(Or for a synchronous divider, 74HC4518 is a good choice.)
The delay time is strongly temperature dependent, also on synchronous dividers, afaik, so not good at all for T.I. measurements.
Why would a logic part be worse than a PIC? CMOS is CMOS.
-
I don't know how it's measured, but according to some FPGAs' datasheets, even hard PLLs can't guarantee to generate such clean clock.
A PLL uses it's own inferior oscillator. A pure synchronous divider will always have the advantage in that respect, even if it's a PIC.
-
Using ordinary TTL divider-by-10 is no good idea, because these are mostly asynchronous dividers, having big jitter.
The delay time is strongly temperature dependent, also on synchronous dividers, afaik, so not good at all for T.I. measurements.
Why would a logic part be worse than a PIC? CMOS is CMOS.
There was a lengthy discussion on the time-nuts list, but I don't catch the correct argument anymore, too long ago, sorry.
A synchronous divider chain is for sure much less effort, than carefully programming the PIC, so there's a good reasoning, why the PIC solution is much superior.
A 10^7 divider chain consists of 28 flip flops, each having about 25ns delay.
Even if it's synchronized, that gives rise to delay jitter, which a state machine does not have, because it's no FF chain inside.. and that's the difference.
Maybe it's possible to search time-nuts for that topic.
Frank
-
Even if it's synchronized, that gives rise to delay jitter, which a state machine does not have, because it's no FF chain inside.. and that's the difference.
AFAICS standard logic counter doesn't ripple the result through all the flipflops every cycle, it is a state machine which uses the internal state from the previous cycle with logic gates to determine what to output on the next clock. Each flipflop is just an individual clocked latch.
-
A 10^7 divider chain consists of 28 flip flops, each having about 25ns delay.
I don't see how that is relevant. The delays do not cascade, except in the case of a ripple counter.
Even if it's synchronized, that gives rise to delay jitter, which a state machine does not have, because it's no FF chain inside.. and that's the difference.
I don't see that. Surely for all 3 cases (ripple counter + synchronizer, synchronous counter, MCU state machine), the output delay jitter is only due to the final stage.
-
If you are clocking the micro from the GPS 10MHz clock, and the division is performed by a timer rather then software, then you are only adding the residual jitter from the hardware timer. This isn't something you'd ever see specified in a datasheet, do you have any numbers?
The whole point of PICDIV is that if you clock the micro from the 10MHz input, you don't need a hardware timer, because software timing is about as good.
-
Using ordinary TTL divider-by-10 is no good idea, because these are mostly asynchronous dividers, having big jitter.
The delay time is strongly temperature dependent, also on synchronous dividers, afaik, so not good at all for T.I. measurements.
Why would a logic part be worse than a PIC? CMOS is CMOS.
There was a lengthy discussion on the time-nuts list, but I don't catch the correct argument anymore, too long ago, sorry.
A synchronous divider chain is for sure much less effort, than carefully programming the PIC, so there's a good reasoning, why the PIC solution is much superior.
A 10^7 divider chain consists of 28 flip flops, each having about 25ns delay.
Even if it's synchronized, that gives rise to delay jitter, which a state machine does not have, because it's no FF chain inside.. and that's the difference.
Maybe it's possible to search time-nuts for that topic.
Frank
You could use a synchronous counter and then a final latch (flip flop) that was armed but then switched from the original signal but then the circuit is getting more complicated.
-
ARRRGGG, this is kinda getting nuts. If you want your PIC output 1 second high/low pulse to sit right on a rising edge of the 10 MHZ source any better than it already does, just put the PIC output to the data in of a 74AC74 D-latch flipflop and tie the flip-flop's clock input to the 10MHz source clock.
Running a cheap loop in the pic to count the equivalent of 5 million clock ins, output high, another 5 million clocks in and output low, without any PLL or timer is a brainless trivial piece of loop code in assembly. No PLL, no timer, no watchdog, no interrupts, no special sleep cycles, nothing else needed, it will just run without fail. Making the code pulse the output pin high/low as quick as it can after every 10 million clocks is the same 10-15 lines of assembly code.
-
It all depends what you want to do with 1pps. If it is only to drive an alarm clock, then it is fine to do that with a MCU.
If you are actually going to feed it to a discipline clock generator which will use 1pps input to drive PLL in order to generate a perfectly phase aligned clock, then think twice. Your MCU is likely to generate quite some jitter that will ruin your output clock.
If you are clocking the micro from the GPS 10MHz clock, and the division is performed by a timer rather then software, then you are only adding the residual jitter from the hardware timer. This isn't something you'd ever see specified in a datasheet, do you have any numbers?
Disciplined clock sources perform a lot of averaging on the 1PPS signal anyway, so a small amount of jitter shouldn't be a problem.
*than
-
It all depends what you want to do with 1pps. If it is only to drive an alarm clock, then it is fine to do that with a MCU.
If you are actually going to feed it to a discipline clock generator which will use 1pps input to drive PLL in order to generate a perfectly phase aligned clock, then think twice. Your MCU is likely to generate quite some jitter that will ruin your output clock.
If you are clocking the micro from the GPS 10MHz clock, and the division is performed by a timer rather then software, then you are only adding the residual jitter from the hardware timer. This isn't something you'd ever see specified in a datasheet, do you have any numbers?
Disciplined clock sources perform a lot of averaging on the 1PPS signal anyway, so a small amount of jitter shouldn't be a problem.
*than
Sorry, don't quite understand?
-
He corrected you on using then instead of than, without properly quoting only the relevant part.
-
The late Ulrich B , made an AVR PPSDIV (Picdiv lookalike)
The M8 version ought to be easy to adapt to an arduino
http://www.ulrich-bangert.de/html/downloads.html (http://www.ulrich-bangert.de/html/downloads.html)
/Bingo
Sorry to resurrect an old thread, but I'm hoping to get a bit of information about the AVR PPSDIV code that Ulrich B posted for a decade frequency divider using AVR and Mega8 devices. I'm a complete newbie to the world of microcontrollers and am clueless about assembly code. At this stage of my life, I'm not sure that I want to learn to write it.
There seems to be no documentation about his rewrite of Tom van Baak's project. Can anyone tell me which model(s) of AVR and Mega8 the code can be written into and work as described? I'm assuming that the code is specific to only one or very few models.
I have a couple projects in mind that would seriously benefit from a single-chip solution to a decade divider that would, starting with a 10MHz input, provide decade frequency outputs from 1MHz to 1Hz (simultaneously). I realize that the Ulrich B project doesn't provide a 1MHz output, but I could live with an extra divider chip if I could get the rest of the decades in a single chip. But which chips can I use with this code?
Thanks for any advice,
Dave M
-
I think i assembled (compiled) it for a Tiny84 here (Not tested i real Hw)
https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/msg2042386/#msg2042386 (https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/msg2042386/#msg2042386)
T84 code here
https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/?action=dlattach;attach=597535 (https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/?action=dlattach;attach=597535)
This one ought to run on a M8 (Full port D) - You can't use it on an Arduino (board) , as the Arduino Serial port are on Port D , but you prob. could on a "bare M328"
http://www.ulrich-bangert.de/PPSDividerMega8.zip (http://www.ulrich-bangert.de/PPSDividerMega8.zip)
/Bingo
-
ATtiny84 (or 44/24, whichever you can get cheaper) looks like a perfect device. In addition to full PORT A, it has a PWM output right on the next pin after PORT A, which means that 1MHz generation can be added seamlessly by means of a hardware timer.
-
ATtiny84 (or 44/24, whichever you can get cheaper) looks like a perfect device. In addition to full PORT A, it has a PWM output right on the next pin after PORT A, which means that 1MHz generation can be added seamlessly by means of a hardware timer.
Just my thought - CTC and load (10-1) into the ocra , pull 1MHz out on the OCRA pin :-+
/Bingo
-
And, with 90% probability, up to nine NOPs to align 1MHz with all the bitbanged clocks ;)
-
Today’s bloat programmers approach this using all the flash available filling it with nearly 10 million NOPs, two GPIO twiddles and a jump, and have plenty of time to berate the greybeards who achieved the same task in a dozen bytes of object code.
-
Today’s bloat programmers approach this using all the flash available filling it with nearly 10 million NOPs, two GPIO twiddles and a jump, and have plenty of time to berate the greybeards who achieved the same task in a dozen bytes of object code.
;D
But you forgot to add that the end result would probably only meet the specs remotely. So they may end up with a 9999897 division instead. Oh crap, isn't that good enough? The "user story" didn't even state a required tolerance!
Anyway, if you're not happy with it, just create a new "user story". You may get the fix in a few "sprints", if you're lucky (meaning, if other user stories, such as adding a cute blinking LED, are not scheduled first.) :-DD
-
I can't help with all outputs available at once but I do have some code that will provide switch selectable frequencies from a 10MHz source using an ATtiny85.
Extract from my notes about a GPSDO which I've had running for a while now...
A range of output frequencies is provided by a second ATtiny85 again clocked from the OCXO.
It also provides a fixed 10MHz output from its clock buffer pin.
A 10 way switch is used to select frequencies of Off, 5M, 2.5M, 1M, 100k, 10k, 1k, 100, 10 or 1Hz
(Off position ensures no subharmonics on 10MHz output.)
ATtiny85 has limited number of I/O pins so resistor chain and (single) Analog Input pin was used.
Running the A/D continuously would compromise output purity so the comparator was used to generate interrupt when switch position changed.
This was achieved by the use of ten resistors in two chains arranged such that odd switch positions give voltages below the internal comparator reference (1.1v) and even positions give voltages above.
The ‘interrupt on comparator change’ function is then used to start the A/D only when required.
(The switch I used was MBB so the wiper was always connected. A stop was required between positions 1 and 10 to avoid shorting the supply.)
(My first attempt at writing AVR assembler so please be gentle, I'm more used to coding with a soldering iron.)
asm & hex files attached in the zip
Jim
-
It occurs to me that one could daisy-chain two 16 bit Compare modules in an MCU and create a one-chip purely hardware solution, with one Compare module acting as a prescaler for the other.
Example: In the PIC18F family, Timers can be clocked by an external pin. The associated CCP module can control an output pin. The first CCP can take in the original signal, and its output pin can be hardwired to the input pin of the second Timer. The second CCP's output pin then becomes your divided output signal. You'd have 32 bits of divisor, and by setting that to 50% of the desired value you'd get a 50% duty cycle output waveform implemented purely in hardware. If your use of the output signal is edge sensitive, you're good to go.
The firmware's only job would be to configure the Timer and CCP modules. Thereafter, the hardware would run autonomously with no firmware involvement at all. This completely eliminates the question of firmware latency, eases the fear of those concerned about Assembly language, etc. Just put the firmware in a tight loop that does nothing. It might even be possible to halt code execution to save power and reduce noise. Putting the core into a light sleep mode might do it, many peripheral modules can be configured to continue hardware operation while the core is asleep.
The one hangup is maximum Timer input frequency. A quick glance at the PIC18F family reveals that 10MHz is a bit too fast. But the concept still holds, and other families (from other manufacturers?) may support the frequency in question. Looks like the PIC18F would handle inputs under 5MHz, for example.
Just another way of looking at the "problem". An MCU can sometimes be used as a programmable logic block without direct ongoing firmware involvement.
-
Today’s bloat programmers approach this using all the flash available filling it with nearly 10 million NOPs, two GPIO twiddles and a jump, and have plenty of time to berate the greybeards who achieved the same task in a dozen bytes of object code.
Oh I don't know, Don Lancaster was using much the same technique to generate video timings back it the '70s.
-
Latest AVRs can cascade timers without wiring up physical pins, and supposedly many ARMs can too.
But really, look at the dates :scared:
You responded to a question asked 2 years ago which has been bumped by somebody with a related but slightly different problem ;)
-
Yeah, I saw that, but since the thread got resurrected I thought somebody might search it someday.
-
I think you'll find that the 2pS figure is in the right ballpark.
The guy who did that really knows his stuff, is a real expert on the bleeding edge of precision timekeeping.
David
-
I think you should never use interrupts for this because the unpredictable interrupt latency would introduce some jitter. Just nops and loops should be fine.
-
I think you should never use interrupts for this because the unpredictable interrupt latency would introduce some jitter. Just nops and loops should be fine.
In general I would agree, however if the MCU does nothing but sleep waiting for an interrupt which is synchronous with the system clock then latency is fixed and not a problem.
In the example I posted earlier there are two sources of interrupts, Timer1 which meets the above criteria and Analog comparator which is effectively resets everything.
Jim
-
Today’s bloat programmers approach this using all the flash available filling it with nearly 10 million NOPs, two GPIO twiddles and a jump, and have plenty of time to berate the greybeards who achieved the same task in a dozen bytes of object code.
Oh I don't know, Don Lancaster was using much the same technique to generate video timings back it the '70s.
Back in those days such jiggery pokery was for sound engineering reasons, where the overriding design axiom was to keep costs down: it also coincided with a golden age when real programmers knew the cycle count of each instruction and cared about code size, speed and determinism... I am not sure many of today’s programmers would know where to start on those facets!
-
I think you should never use interrupts for this because the unpredictable interrupt latency would introduce some jitter. Just nops and loops should be fine.
Arm NVIC has predictable IRQ's , that was a design goal in the Cortex.
But a decent ARM , prob has enough 32 & 16 bit timers + OCR regs to do it all from timers ... 5..10 outputs.
NXP used to have several 32bit timers , and TI too , STM has a few in the larger packets.
/Bingo
-
Back in those days such jiggery pokery was for sound engineering reasons, where the overriding design axiom was to keep costs down: it also coincided with a golden age when real programmers knew the cycle count of each instruction and cared about code size, speed and determinism... I am not sure many of today’s programmers would know where to start on those facets!
Are you quite sure it was a golden age? You CAN still do it. But all the intervening development has been to allow you the luxury of not having to.