Hi!

Try TVB's picDiv at http://www.leapsecond.com/pic/picdiv.htm

Edésio

On Wed, Jan 13, 2016 at 09:22:09AM +0000, Jerome Blaha wrote:

Tom Van Baak has developed dividers based on simple PIC chips that will
produce 1 PPS from several input frequencies.  These dividers have
remarkably low jitter, down in the couple-of-picosecond range, and are
very simple.

I've implemented life support circuitry around two versions of Tom's
code, both available as kits from TAPR:

The TADD-2 is a 4x6 inch board with 6 BNC outputs, each of which can be
set to provide 1, 10, 100, 1K, or 10K PPS from either a 5 or 10 MHz input:
http://tapr.org/kits_tadd-2.html

The T2-Mini is a tiny board with a single input and output.  The default
firmware allows PPS output for 1, 2.5, 5, or 10MHz input:
http://tapr.org/kits_t2-mini.html

Both of these devices have a low-jitter sine-to-square converter on the
input, and work over a wide input amplitude range, so just about any
sine wave will drive them.

John

On 1/13/2016 4:22 AM, Jerome Blaha wrote:

Sounds like a PICDIV is just about right:
http://www.leapsecond.com/pic/picdiv.htm

Ole

On Wed, Jan 13, 2016 at 10:22 AM, Jerome Blaha jblaha@polariswireless.com
wrote:

If anyone is interested in the equivalent functionality using an ATTiny25 (for instance, if you’re already heavily invested in AVR instead of PIC, like I am), ping me. I’ve privately written code to solve almost the same problem and it could easily be adapted into doing the same job.

Just shy of a half dozen folks have asked, so I'll post here as soon as I finish cleaning it up. I'll put it on Github when it's ready. I just need a day or two.

Sent from my iPhone

The code is at

https://github.com/nsayer/GPS-disciplined-OXCO/blob/master/tiny_divider.c

It’s a first cut. The code at the moment will just divide the input clock by 10 million, so you get a 1 PPS 50% duty square wave out. It should run on any ATTinyx5 model - it certainly will fit on at ATTiny25 if you wish.

I’ve not exhaustively tested it yet. I need to feed it into my TIA to make sure it’s exactly 1 Hz - it’s conceivable I’ve committed a fencepost error that would make it off enough that my scope can’t tell (my TIA is busy at the moment).

I believe the code won’t do the math properly below 10 MHz. You’d need to select the next lower prescale setting and change a couple of the formulae, but I don’t foresee an issue with doing so.

I’ll come back with an exhaustive test report (and any bug fixes) when I get my TIA back from GPSDO ADEV duty. :)

Nick, can the Attiny25 divide down a 20Mhz input. I understand the 12fxxx pics max out at 20Mhz on a input so not sure if they would be suitable for my purpose. Can't seem to find anything in the datasheet for the tiny that explains the maximum frequency on a input pin.

-=Bryan=-

Hi

The way pretty much all of these work is to take the “10 MHz” in on the clock input port.
The critical spec is the upper frequency for an external clock input. With some chips this
is in the vicinity of 50 MHz. On others it tops out at 4 MHz.

The next step after wiring it up is to check the jitter on the resulting output. It would be
nice if all input circuits were designed equally well. There is evidence out there that this
is not the case…..In some cases the performance can be improved by feeding the MCU
input with a high slew rate signal rather than a sine wave. About all that takes is a single
gate.

Bob

I'm curious if that code will perform the intended function (down to the clock cycle) when compiled. A check in the simulator would be a good idea while the TIA is busy.

If it doesn't give you the performance you are looking for, try programming it in assembly, as was done for the PicDiv.

Dan

I did a test last night (I accidentally bonked the device I was testing and it sort of went nuts, so I had to start it over) and found and fixed a fencepost bug. After that, it was accurate down to the limits of my TIA (something like the 10s of ps range). My test methodology was to feed 10 MHz from one of my GPSDOs into the TIA reference and the same 10 MHz into the device input. I then had the TIA perform period measurements with a 10 second gate. The result was 1 second, ± maybe a dozen or two ps on average, but again, that’s where the limits of my TIA (Keysight 53220A) lie.

The whole point of using the timer subsystem the way I am is so that you don’t have to care about the instruction timings. As long as the code is quick enough not to overrun any interrupts, it’s all good. And by using the timer prescaler, you have pretty good assurance that that’s the case.

I was thinking to make a frequency divider by using FPGA. Here is my
attempt to implement it using VHDL.
This is frequency divder plus D flip-flop which I was planed to use as
source of 60Hz for my Telechron clock.
However I never implement it in HW. Instead I was using STM32F4 with its
timers.
The purpose was to divide 9.8304 Mhz OCXO output by 81920 to get 60Hz
and use the D flip-flop to keep output in sync.
Some day I'll return to this with my soldering iron in hands. ;-)

-- Company:
-- Engineer: V.P.

-- Create Date:    17:58:43 11/09/2015
-- Design Name:
-- Module Name:    freq_div - Behavioral
-- Project Name:
-- Target Devices:
-- Tool versions:
-- Description:

-- Dependencies:

-- Revision:
-- Revision 0.01 - File Created
-- Additional Comments:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
use IEEE.NUMERIC_STD.ALL;

-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity freq_div is
Port ( clk_in : in  STD_LOGIC;
rst : in  STD_LOGIC;
clk_out : out  STD_LOGIC);
end freq_div;

architecture Behavioral1 of freq_div is

signal prescaler : integer range 0 to 81919 :=0;
signal clk_out_i : std_logic;

begin

gen_clk : process (clk_in, rst)
begin  -- process gen_clk
	if rst = '1' then
		clk_out_i   <= '0';
		prescaler   <= 0;
	elsif rising_edge(clk_in) then   -- rising clock edge
		if (prescaler = 81919) then
			prescaler   <= 0;
			clk_out_i   <= not clk_out_i;
		else
			prescaler <= prescaler + 1;
		end if;
	end if;
end process gen_clk;

clk_out <= clk_out_i;

end Behavioral1;

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity d_ff is
Port ( d_clk_in : in  STD_LOGIC;
d_rst : in STD_LOGIC;
D : in  STD_LOGIC;
Q : out  STD_LOGIC
);
end d_ff;

architecture Behavioral2 of d_ff is

begin

d_ff_clk : process (d_clk_in, d_rst, D)
begin  -- process d_ff_clk

	if ( rising_edge(d_clk_in) ) then  --This makes the process 

synchronous(with clock)
if(d_rst = '1') then
Q <= '0';
else
Q <= D;
end if;
end if;
end process;  --end of process statement.

end Behavioral2;

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use work.all;

entity Z1 is
Port ( z1in : in  STD_LOGIC; -- clk_in
z2in : in  STD_LOGIC; -- reset
z1out : out  STD_LOGIC -- Signal Out

 );

end Z1;

architecture SOut of Z1 is

component freq_div is
	Port ( clk_in : in  STD_LOGIC;
        rst : in  STD_LOGIC;
        clk_out : out  STD_LOGIC
	);
end component;

component d_ff is
	Port ( d_clk_in : in  STD_LOGIC;
		  d_rst : in STD_LOGIC;
        D : in  STD_LOGIC;
		  Q : out  STD_LOGIC
	);
end component;

signal wire: std_logic;	-- put signal to "wire" or use it as a "wire"

begin

u0:
freq_div
port map (
clk_in => z1in,
rst => z2in,
clk_out => wire
);
u1:
d_ff
port map (
d_clk_in => z1in,
d_rst => z2in,
D => wire,
Q => z1out
);

end SOut;

On 2016-01-13 21:35, Nick Sayer via time-nuts wrote:

--
WBW,

V.P.

For the AVRs I generally use (including the ATTinyx5s the subject here), it’s 10 MHz if you’re running at 3.3 volts and 20 MHz at 5 volts.

My testing last night (I described the methodology elsewhere) went to the limits of my TIA. The output from my GPSDO is a square wave, so I didn’t condition the input. In the past what I’ve used for that is a DC blocking cap, followed by a Thevenin termination (100Ω to ground and Vcc) feeding a 74LVC1G17 Schmitt trigger buffer. I don’t know if that’s up to Time Nuts standard or not. The one downside I’ve seen with it is that it kind of requires a larger input amplitude than is sometimes convenient.

On Wed, 13 Jan 2016 14:31:25 +0100, Ole Petter Ronningen wrote:

Ulrich B made an AVRDIV, for those who use AVR's (bottom of page)

http://www.ulrich-bangert.de/html/downloads.html

/CFO

Am 14.01.2016 um 15:50 schrieb Vlad:

A year or 2  ago, I have posted a VHDL solution here that fits into half
a Xilinx
Coolrunner 2C64A-5. When the input clock is pretty (50% duty cycle) it
runs at
200 MHz in. (tested)
The 2C64 does not take a lot of space:

<
https://picasaweb.google.com/lh/photo/4Bpcfouj8WH0shNGIyuVUtMTjNZETYmyPJy0liipFm0?feat=directlink

The bottom row of test circuits are a 100->200 MHz doubler and a
200->400MHz doubler
with a wide SAW filter to kill the harmonics.

Since the 10811 oven is so big, the Coolrunner will find a niche on the
universal VCXO carrier board I talked about 6 Weeks ago. Also, Charles
Steinmetz' version of the Wenzel and the LT limiter, so we can compare
them easily.

I have chosen to use W.J. Riley's ring mixer PLL and not the AD9901, no
point to
re-invent the wheel. But that will cost the ability to lock on external
1pps; only
lock to external 10 MHz is provided.

BTW. I have coded an AD9901 work-alike in VHDL that could also fit into
this
Coolrunner, but it was never tested because we have solved our problem
otherwise.

regards, Gerhard

I and others have written divider routines in assembler for the ATtiny25
etc.  The version I have is crude but divides by 10, 100, and 1000.  I
also have a version that divides by 1E4, 1E5, and 1E6.  I also have a
version that generates 3 pps outputs, one with a 50% duty cycle plus
positive and negative short duration pulses.

All three sync up to the 10 MHz clock using a pps input.  The sync takes
about 2 to 3 s, is within several clock cycles (adjustable) but always
has one clock cycle  uncertainty.  Basically we look for an interrupt on
the pps input and if one occurs we poll the pin to find the next one.
This leads to the one cycle uncertainty.  I tried interrupts but had
more variance than polling - ymmv. If there is no pps interrupt the wdt
times out and we jump into the main loop.

I'm working from memory but I seem to recall there's several ns
variation between the three outputs and they change about 14 to 16 ns
after the clock.

I'm happy to email the assembler code to anyone who wants to start from
it.  Its crude and will need testing/tweeking.  I have several chips in
use that work well but I just changed a few things and have not burned
and tested the changes in a circuit.

Drop me a line if you want the sources.

bob

On 1/14/2016 7:20 AM, Daniel Watson wrote:

Nick wrote:

You will get less jitter (as well as more sensitivity) if you use a
buffer without a Schmitt input (it should also be "native" CMOS --
with an input threshold of 1/2 Vcc -- not CMOS with TTL input
thresholds).  For best performance, the input signal should be scaled
to drive the buffer input quite close to both logic power supply
rails.  You can use Shottky diodes (1N5711, 1N6263) to clamp the
buffer input to 0 and Vcc if necessary (I would include such diodes
as a best practice, even if I did not expect input excursions beyond
the rails).

Best regards,

Charles

For lowest jitter the gate power supply noise needs to be very low.Biasing the input at 50% supply helps somewhat but the gate threshold is never exactly 50% and the low pass filtering effect of the coupling capacitor increases the contribution of power supply noise to jitter.
A power supply noise below 10nV/rtHz is probably required to achieve the lowest jitter. Few regulators achieve this particularly at low frequencies.

Bruce

On Friday, 15 January 2016 8:10 PM, Charles Steinmetz <csteinmetz@yandex.com> wrote:

Nick wrote:

You will get less jitter (as well as more sensitivity) if you use a
buffer without a Schmitt input (it should also be "native" CMOS --
with an input threshold of 1/2 Vcc -- not CMOS with TTL input
thresholds).  For best performance, the input signal should be scaled
to drive the buffer input quite close to both logic power supply
rails.  You can use Shottky diodes (1N5711, 1N6263) to clamp the
buffer input to 0 and Vcc if necessary (I would include such diodes
as a best practice, even if I did not expect input excursions beyond
the rails).

Best regards,

Charles

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

On Thu, 14 Jan 2016 09:50:15 -0500
Vlad time@patoka.org wrote:

Nice!

As side note: when using an FPGA anyways, it might be good to use
something like a lambda divider [1,2].

I'm not so sure whether their explanation why this improves the noise
floor is the right one, but it definitly helps and is quite easy to
implement.

		Attila Kinali

[1] " The sampling theorem in Pi and Lambda dividers", by Calosso, Rubiola, 2013
http://rubiola.org/pdf-articles/conference/2013-ifcs-Frequency-dividers.pdf

[2] Slides to the above
http://rubiola.org/pdf-slides/2013C-IFCS--Dividers.pdf

--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson

On Friday, January 15, 2016 12:13:47 PM Attila Kinali wrote:

A lambda divider is only useful when one wants a sinewave or a triangular wave
output. In the case of a CMOS divider It reduces output noise by averaging the
upconverted supply noise produced by sampling the supply noise at different
phases of the output signal period. When upconverted power supply noise
dominates merely paralleling outputs that sample the power supply noise at the
same time will have little discernable effect on the output noise.

Bruce

Am 15.01.2016 um 10:14 schrieb Bruce Griffiths:

I have recently measured the noise of some regulators, LEDs and Zeners
with partly unexpected results.
I'll do a write-up and put it on my web site, but here are 3 pictures
that already tell a lot:

Zeners:

<
https://www.flickr.com/photos/137684711@N07/24411798996/in/album-72157662535945536/

Note the low 1/f corner of the BZX84 C2V7 and 3V3.
And 0 dB is the noise of a 60 Ohm resistor, or the INPUT referred noise
of an AD797 or LT1028.

LEDs abused as References:

<
https://www.flickr.com/photos/137684711@N07/24354944411/in/album-72157662535945536/

The Avago HLMP-6000 is the clear winner in terms of noise. Optically,
it's quite dim.

Regulators:

<
https://www.flickr.com/photos/137684711@N07/24070698809/in/album-72157662535945536/

The clear winner here is the LT3042. Now if they made it in an
acceptable package!
I mounted the MSOP-10 dead bug style on unetched FR4, soldered a thick
1mm Cu wire across
the exposed pad and put the rest of the circuit on raster board. That
was no fun, even under the
microscope.

BTW the extra quiet reference of the LT3042 is a current source, so
there is no
real justification for the repeated claims here that ECL must be noisy
because of
its integrated current source.

Batteries:

I have done the writeup already:
<
http://www.hoffmann-hochfrequenz.de/downloads/NoiseMeasurementsOnChemicalBatteries.pdf

and since we are at it:  Lab supplies

<
http://www.hoffmann-hochfrequenz.de/downloads/Noise_Measurements_On_Some_Laboratory_Power_Supplies.pdf

(still incomplete, but no longer high priority for me)

regards, Gerhard

In message 569BC23A.3030400@arcor.de, Gerhard Hoffmann writes:

This is one of the most stupid ideas ever, because LEDs works both ways.

(Back when LED wrist-watches first came out, people soon discovered
that they would reset themselves when photographed with flash.)

If you insist on using LEDs as voltage references, the first thing
you need to do is to dip the LED in something which shields it 100%
from incoming light including infrared

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

On Sun, 17 Jan 2016 17:32:58 +0100
Gerhard Hoffmann dk4xp@arcor.de wrote:

Thanks a lot! This is some very valuable data.

If you could note also the exact circuits you used, that would help
to compare the circuits.

		Attila Kinali

--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson

On Wed, 13 Jan 2016 09:22:09 +0000, Jerome Blaha wrote:

Ulrich B. has made an AVR 1PPS, for those that uses AVR's instead of PIC's
AVR PPSDIV 2008-09-06 - in bottom of page.
http://www.ulrich-bangert.de/html/downloads.html

The Mega8 version should be easy to port to an Arduino clone

CFO

Hi

Back in the 70’s I was involved in making LCD watches. The whole “photo”
issue had not been fully through through. One day our chief marketing guy for
the project was driving around in Phoenix AZ. He looks down and notices that
his watch is dead. Pops out a spare, puts it on, confirms it it working. Hangs his arm out
the window and …. that one is dead as well.

We changed the die coat on the ASIC to an opaque version soon after that …

Light does indeed interact with semiconductors. It happens even on circuits that
you would not think are photo sensitive. Physics is nasty that way ….

Bob

You might have come across the Raspberry Pi story : one of the revised
versions had a SMPS control chip that was intended to be buried inside a
phone, not exposed on an open pcb.

https://www.raspberrypi.org/forums/viewtopic.php?t=99042

On Mon, Jan 18, 2016 at 3:11 PM, Bob Camp kb8tq@n1k.org wrote:

Looking to the complex solutions for the frequency divider (CPLD/MCU), I
start to think about skews and propagation delays. Its not obvious from
the first glance. But I think such things exists.
It could be interesting to compare the numbers.  Is it worth to consider
some correction to avoid phase difference between of input and output ?

On 2016-01-18 08:59, cfo wrote:

--
WBW,

V.P.

Indeed Bob in the 70s I built a failure diagnostic equipment to record the
Idd of a chip as a function of a position of a spot of light scanning the
surface. The intensity was very low and not optimum wavelength.......it was
a scope raster demagnified by using a microscope camera accessory backwards.
The intensity was modulated and the signal detected on a PSD and displayed
on a modified Robot SSTV receiver.....but it showed just how senstive chips
are to light.

Alan
G3NYK

----- Original Message -----
From: "Bob Camp" kb8tq@n1k.org
To: "Discussion of precise time and frequency measurement"
time-nuts@febo.com
Sent: Monday, January 18, 2016 3:11 PM
Subject: Re: [time-nuts] Generating a solid PPS from 10Mhz source

Hi

The same issue come into random logic. The most common chip logic way to do this is with rippling
divide by 10’s.  Been there / done that.. The output pulse in that case is delayed  by quite a bit. Put
a “sync” flip flop on the output and the (obvious) question is — do you know the delay is << 100 ns?
When it’s not, you start doing full up programmable dividers …. you then have a Fmax question.

The nice thing about a FPGA (or CPLD) is that they come with a cute timing analyzer. You can indeed
answer questions like this with a quite high level of confidence. That assumes that you bother to set
up the timing analyzer :)

With an MCU, you have pretty good information on the output delay. The ambiguity comes on the clock
input. It’s rare to see that fully documented. You are then back to a “measure it and see” situation. You
probably could guess that the input delay and output delays relate to the clock delay.

Regardless of the divider it’s self, you will have the sine to square conversion. You also
may have a sensitivity on a square back to sine conversion. All of it (and the divider) will have both temperature
and voltage sensitivity. Most of that will be in the “measure it and see” category.

Based on measurements, all of it comes out in the “no big deal” range for normal applications.

Bob