Divide by 10000000

[NivagSwerdna]

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

[NivagSwerdna]

After a  bit of googling...

http://www.leapsecond.com/pic/picdiv.htm

That's quite a sweet solution... and apparently it works with the sine rather than square clock.

[Psi]

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

[bktemp]

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.

[mikerj]

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.

[MK14]

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

[MK14]

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

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.

[Fungus]

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... 

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.

[Fungus]

If you want it to be 'cool' you can use decade counters:

eg. 74LS163

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.  )

[danadak]

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.

[fcb]

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.

[awallin]

FWIW my PICDIV attempt from last year.
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..

[bingo600]

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

/Bingo

[Kleinstein]

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.

[Dr. Frank]

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, 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.

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

[jpb]

If you want it to be 'cool' you can use decade counters:

eg. 74LS163

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.  )

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

Each chip can divide by 100 so 4 of them would be required, rather a lot of board space but simple and cheap.

[james_s]

I'd use a small CPLD like the XC9536, I'm already set up to work with those though.

[edavid]

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.

[Marco]

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.

[Dr. Frank]

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

[Marco]

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.

[edavid]

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.
 

[edavid]

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.

[jpb]

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.

[BrianHG]

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.