Re: [time-nuts] Thought experiment on a low cost timing board
I have done several GPSDOs using the NAVMAN receiver, so I add a few
comments to the discussion:
- Both the G3RUH
([1]http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm) and
I2PHD ([2]http://gpsdo.i2phd.com/) designs use 74HC390 divider chips;
I also tried them. What I found was that the 74HC390 dividers had very
strong temperature sensitivity, amounting to well over 100 nsec with a
mild diurnal room temperature change. Of course this is due to the
'HC390s being a cascaded series of ripple counters. To go from 10 MHz
to 10 kHz, you end up with 12 CMOS stages being cascaded.
My solution was to replace the 'HC390 change with the elegant
PIC-based divider chain invented by Tom van Baak. This uses the 10 MHz
signal as the PIC's clock, and the tight code based on a fixed number
of wait states makes a fully synchronous divider. I was unable to
measure ANY temperature effects. The PIC requires less real estate
than the 'HC390s and is also quite cost effective. - I did a lot of work to optimize the integrator time constants. What
ended up dominating the stability was the "hanging bridges" that
result from "zero beats" when the sawtooth error on the timing pulses
is NOT dithered for several seconds. I ended up with best performance
with a "lag" analog time constant of ~10 seconds and a "lead" of ~1
second. This required the use of an op amp in the analog feedback leg
and high quality polystyrene capacitors in the RC network. - My design was also made more complicated because the long time
constant led to a very long lock-up time. So I developed a simple
phase/frequency lock detector that included a "gear shift" between the
fast and slow time constant states. This made use of the fact that
TvB's divider could be repeatably reset to acquire approximate time
lock before the phase steering clicked in. - TvB asked about the properties of the Jupiter-T 10 kHz output.
Here's what I remember:
* The 10 kHz output shows the same ±~13 nsec nsec sawtooth "dither"
because timing pulses are synchronous with the edges of a ~40 MHz
clock in the GPS receiver. The older ONCORE had ± 52 nsec dither
because it came from a ~9.5 MHz clock. The newer M12+ is like the
Jupiter-T with a ~40 MHz clock.
* The Jupiter-T receiver, when operating in the position hold (that
I often call the "Zero-D Timing") mode works quite well. The
Jupiter-T was made to be a FFF (Form, Fit & Function) replacement
for the older 8-channel Oncore, and it supports most of the
Motorola (@@Xy) instructions. It is a 12 channel receiver which
will use all the satellites it can find. Rick Hambly's TAC-32
software properly drives the Jupiter-T, and my old TAC-2 board
will properly mount a Jupiter-T (except that the 10 kPPS output
needs to be added on the 10-pin header).
* A major difference from the ONCORE is that the Jupiter-T does NOT
return the timing error on the next pulse (in the @@Ea message),
so the dither cannot be removed in software. This is because the
Jupiter-T achieves its timing output by twiddling the rate of a
numerically controlled oscillator (NCO) to make the next pulse be
as correct as possible; the ONCORE counts the integrated pulses .
This then results in the Jupiter-T not knowing its constant of
integration, and hence it is not able to predict the error.
In short -- The Jupiter-T is a good timing receiver.
Hope these factoids helped -- Tom
References
From: "Tom Clark, K3IO (ex W3IWI)" K3IO@verizon.net
I have done several GPSDOs using the NAVMAN receiver, so I add a few
comments to the discussion:
- Both the G3RUH
([1]http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm) and
I2PHD ([2]http://gpsdo.i2phd.com/) designs use 74HC390 divider chips;
I also want to thank G3RUH and I2PHD for the links. I
tend to get caught up with such high performance that
I overlook simpler (though somewhat less performing)
solutions like those.
I also tried them. What I found was that the 74HC390 dividers had very
strong temperature sensitivity, amounting to well over 100 nsec with a
mild diurnal room temperature change. Of course this is due to the
'HC390s being a cascaded series of ripple counters. To go from 10 MHz
to 10 kHz, you end up with 12 CMOS stages being cascaded.
My solution was to replace the 'HC390 change with the elegant
PIC-based divider chain invented by Tom van Baak. This uses the 10 MHz
signal as the PIC's clock, and the tight code based on a fixed number
of wait states makes a fully synchronous divider. I was unable to
measure ANY temperature effects. The PIC requires less real estate
than the 'HC390s and is also quite cost effective.
For those of you interested -- the free PIC source code
for the divider is at:
http://www.leapsecond.com/tools/PPSDIV.ASM
Also I think Brooks Shera keeps a copy of the code at:
http://www.rt66.com/~shera/index_fs.htm
Although written years ago for the PIC16C84 it works with
little modification to almost any PIC. Remember to turn on
the HS osc fuse, turn off the WDT fuse, and use a PIC part
that handles a 10 MHz clock.
...
In short -- The Jupiter-T is a good timing receiver.
Hope these factoids helped -- Tom
Yes, thanks much. Always a pleasure to hear from you.
My solution was to replace the 'HC390 change with the elegant
PIC-based divider chain invented by Tom van Baak. This uses the 10 MHz
signal as the PIC's clock, and the tight code based on a fixed number
of wait states makes a fully synchronous divider. I was unable to
measure ANY temperature effects. The PIC requires less real estate
than the 'HC390s and is also quite cost effective.
For those of you interested -- the free PIC source code
for the divider is at:
http://www.leapsecond.com/tools/PPSDIV.ASM
Very interesting.
Thank you very much to both Toms for your work and the listing, and of
course to Brooks, who did a fantastic job.
Also I think Brooks Shera keeps a copy of the code at:
http://www.rt66.com/~shera/index_fs.htm
Unfortunately there is only the hex list of the pic code.
As I would like to experiment as well with this modification
and try to change some parameters to fit my LPRO
and some different OCXOs I own,
is there a way to get the commented source code of it?
Although written years ago for the PIC16C84 it works with
little modification to almost any PIC. Remember to turn on
the HS osc fuse, turn off the WDT fuse, and use a PIC part
that handles a 10 MHz clock.
...
In short -- The Jupiter-T is a good timing receiver.
Hope these factoids helped -- Tom
Yes, thanks much. Always a pleasure to hear from you.
The pleasure is as well mine to read all the good comments
from you.
I have still the idea to use a higher clock for the pulse
counter instead of the 24 MHz for a better resolution.
I could not get any M12+ GPS-receiver on the market,
so I bought the Jupiter-T as well and I want to compare the
behaviour with the Trimble Resolution T later on,
but before I have to get all that running.
(Is it possible to compete or beat the off the shelf
solutions? ;-) )
Have always a good Time!
Arnold, DK2WT
--
DSL-Aktion wegen gro�er Nachfrage bis 28.2.2006 verl�ngert:
GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
Arnold Tibus wrote:
Unfortunately there is only the hex list of the pic code.
As I would like to experiment as well with this modification
and try to change some parameters to fit my LPRO
and some different OCXOs I own,
is there a way to get the commented source code of it?
I designed and implemented a couple of years ago a GPSDO along the
conceptual lines of that of Brooks Shera, but with a different
processor (an AVR ATmel AT90S8535) and using a 20 bit PWM instead
of the DAC (difficult to obtain). It kept the OCXO disciplined
in a few parts over 10^11, confirmed also by comparisons against
a Z3801A.
If you want the source code of my AVR program (assembly language)
just ask.
73 Alberto I2PHD
Old message:
Von: Alberto di Bene dibene@usa.net
An: Discussion of precise time and frequency measurement
time-nuts@febo.com
Betreff: Re: [time-nuts] Thought experiment on a low cost timing board
Datum: Sat, 25 Feb 2006 15:37:02 +0100
Arnold Tibus wrote:
Unfortunately there is only the hex list of the pic code.
is there a way to get the commented source code of it?
I designed and implemented a couple of years ago a GPSDO along the
conceptual lines of that of Brooks Shera, but with a different
processor (an AVR ATmel AT90S8535) and using a 20 bit PWM instead
of the DAC (difficult to obtain). It kept the OCXO disciplined
in a few parts over 10^11, confirmed also by comparisons against
a Z3801A.
If you want the source code of my AVR program (assembly language)
just ask.
Hi Alberto,
You would help me a lot with your informations you are willing to share
with me, yes I am interested!
As the tasks increases I got already some impressions
about the need to switch to another processor, but I did not
decide yet.
First of all I want to finish the nice project from Brooks Shera,
then I will continue.
I am not a good programmer, so I am not in the position to reinvent the
wheel.
Any help is therefore welcome.
I will need some time to do and finish the ideas I have in mind,
but I will keep you informed, if you are interested on.
Please use my e-mail address to send me the informations and files.
Are you perhaps not far located from the Alps?
On the 2m band using SSB I crossed sometimes the
Alps using only low power. I am located at the
Lake Constance.
Thank you very much,
gracias e saludos to Italia,
buen giorno, ciao
Arnold, DK2WT
--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen f�r GMX Partner: http://www.gmx.net/de/go/partner
Alberto,
I have been reading the time-nuts archives and ran across a Feb 25, 2006
post where you mention you coded a GPSDO for an Atmel AT90s8535. Is
that code still available and could I please get a copy of it. Also, if
you have a schematic I would like to see same if possible.
Thanks,
Bob Darby