[time-nuts] Do we need something like this ?

[John Ackermann N8UR]

Hi Ulich --

Just at first glance, WOW!  That sounds like a great design.  There are
others here who can give you a much more detailed technical critique,
but I certainly think you have a pretty great idea there.

You might also consider a sub-project that would just be the TIC
component... a 110ps resolution counter would be a handy thing to have
for many other applications as well!

John
----

Ulrich Bangert wrote:

>Hi Folks,
>
>I am absolutely new to time nuts, but having studied the last month's
>topics i feel i finally found a place to discuss some of my ideas
>concerning frequency standards for use in amateur radio & elsewhere.
>
>To be concise: It is more than just ideas. Almost everything that i
>thought it has to be done has been realized in a breadboarded running
>prototype. I am currently at a point where everything needs to be
>ordered and a (multilayer) pcb has to be designed. Before i do, i would
>like to present the basic ideas and features of the design to you and
>leave it to your jugdement. I urgently need some feedback on it by some
>qualified guys and i believe to have found them. For reasons that become
>clearer in a few seconds, i call the device AOS, like A(rbitrary)
>O(scillator) S(ynchronizer). So, do we need something like this: 
>
>The design basically consists of 4 building blocks.
>
>1) A Motorola M12+ GPS receiver. No need to talk about this one. The
>only perhaps extraordinary is the fact that the receiver's sawtooth
>correction value is used in the regulation loop which effectivley lowers
>the receiver's pps's allan deviation to some 2E-9 @ 1 s. This allows to
>use integrating time constants a order of magnitude smaller than without
>using the sawtooth correction. This in turn makes even some not so good
>suited oscillators candidates for use in the standard. Note: The double
>oven 10811 in the Z3801 is NOT because HP tried to make everything as
>perfect as possible! It is a NECESSARY prerequisite for the operation of
>the Z3801. With the ancient receiver technology used these days in
>conjunction with gps's SA the receiver would easily have a Allan
>deviaton of 100E-9 @ 1 s. That noisy signal needs 50 times longer
>integration time constants compared to the M12+ to give the same
>accuracy, resulting in the need for much better LO specifications than a
>single oven 10811 could give. So a double oven design became necessary.
>>From a today point of view the Z3801 is by far not as good as a lot of
>people think. As my design shows, current amateur designs can achieve
>superior results.
>
>2) A Analog Devices AD9852 DDS. Basically i do not steer the LO by
>analogue electronis but use it to clock a DDS. This has (so it seems to
>me) the following advantages: 
>
>A) You need no voltage controlled oscillator, instead any stable source
>of frequency will do. The LO is not part of the project. Thanks to the
>DDS the user of this device supplies whatever he feels is a adequate
>source of short time stability, may be quarz, may be rubidium, may be
>cesium just whatever you like even if you thought it was not steerable
>at all.
>
>B) The DDS features a built in clock multiplier, so you can get out 10
>MHz on a 10 MHz clock input signal with only a slight increase in phase
>noise. In fact, due to the clock multiplier and the DDS principle the
>clock signal does not NEED to be 10 MHz but may be anything between 1
>and 20 MHz will do for a 10 MHz output. Do not hesitate to buy a good
>oscillator having a absolutely odd frequency, it will be perfect for use
>in this design. Using a all digital DDS removes a lot of the problems
>building a frequency standard that relate to the need for high precision
>low noise analogue electronics which would otherwise be necessary. With
>analogue electronics the thermo-voltages of simple solder joints can get
>a serious design issue.
>
>C) The AD9852 is one of the few DDSs giving 48 bit frequency resolution.
>You may easily calculate that this results in frequency steps of some
>4E-14 relative to the desired output frequency. I thought that was fine
>enough. Agreed? Surely it is better than anything i have seen realized
>with analogue parts.
>
>3) A Altera gate array of the 10K class holds almost all of the logic.
>Beneath controlling a rotation shaft encoder and a 2X40 lcd display the
>main logic necessary is of course the TIC and the 1E7 divider chain to
>generate a pps out of the locally generated 10 MHz. The TIC realized
>here has a resolution of app. 110 ps and uses a delay element scheme.
>The delay in a single element is temperature and supply voltage
>dependand. For that reason the delay chain calibrates itself against the
>gps signal on a regular basis. I studied Shera's design very intensive
>and one of the really big design clues is also one of the big design
>flaws: By limiting the delay between gps pps and a locally derived
>signal to the millisecond range it is indeed possible to use a low class
>timebase like the ordinary canned oscillator that Brooke uses without
>any limitation on accuracy of the measurement. (This topic has already
>been discussed elsewhere in the group) However, with a phase measurement
>range in the millisecond region, the LO has to be extreme close to the
>desired frequency to make the pll lock and results in the oscillator
>setup procedure that is necessary with this design. With pps signals a
>delay of 0.5 s gives the maximum phase tolerance in both directions
>early / late and that is why my dpll's 'center phase' is 0.5 s. With
>discrete devices a 10 MHz binary counter chain for 0.5 s would be
>unpractical long in terms of number of devices used, but no problem
>inside a fpga. For that reason the LO may be far off initially in my
>design because the phase measurement range is 0 to 1 s. 
>
>4) A Beck SC12 microcontroller. Most possibly you have not heard about
>it because it is a German product. Google for "Beck" and "SC12" to learn
>more about it. Imagine a part with a DIL-32 footprint that contains a 20
>MHz clocked 80186, a lot of flash memory, a interrupt controller, 2
>UARTs, a network controller with a ethernet interface and some other
>goodies. The part comes with a DOS like real time operating system and
>Borland C or Borland Pascal 7 is used to write programs for it. As if
>this alone were not astonishing enough, the part comes with a built in
>web server (!) a built in FTP server (!) and a built in Telnet server
>(!), you name it. Due to the multitasking environment all this stuff
>runs concurrent and parallel to your own application. The gate array
>works as a memory mapped i/o device on the controller's bus. The
>application software is a 80 K byte Pascal program. Regulation is done
>by means of a digital pll. The pll's natural time constant can be set
>from seconds to days and a pre-filter for the samples having 1/6 the
>time constant of the pll's natural time constant can be switched on/off.
>If that reminds you to something you remember about the Stanford
>Research PRS10 loop: Not by chance! All (and i mean really all)
>parameters of the regulation are stored in a non-volatile ram on a
>second-by-second base. I case of power loss these values are loaded back
>at restart, so chances are, you still have a "lock condition" after
>restart if only the LO has a UPS. Regulation can even be switched off,
>giving you a open-loop system that is ideal to characterize the LO and
>to determine the integration time constant that is ideal for this
>specific LO and gps receiver combination. 
>
>All information from the gps receiver (of course in a decoded form..) is
>available at the display, that includes the information about the status
>of all used receiver channels as well as the status of all currently
>received sats. All current values of the regulation process are
>available at the display. All relevant parameters can by changed by
>means of a rotation shaft encoder and are stored non-volatile. The
>receiver may be completely reset or a 'site survey' may be initiated.
>The device works as a NTP time server in networks and can send UDP
>packets containing all relevant process information to a pc in the same
>network segment or send broadcast to all members of the segment. A pc
>software for the realtime display of this data as well as longtime
>storage for later analysis exists. Output is of course Stable32
>compatible. Note, that generating 48 bit control word for the DDS
>involves using arithmetic BETTER than 48 bit resolution. The software
>uses Borland's 64 bit 'Extended' data type for all calculations.
>
>The M12's serial output as well as the pps is routed to a standard RS232
>port so that the device may serve as the hardware for CNS's well known
>TAC32 software. To drive things to the top, the device can mimic the
>serial output of a Agilent 53131 counter in TIC mode on a second serial
>port. That includes the second by second messages as well as the 100 s
>averaged TIA messages. That saves you thousand's of dollars for a real
>53131 in case you want to use the TAC32+ with the additional TIC module
>in conjunction with this device.
>
>In a locked condition the DDS's frequency control word is a direct and
>error free measure of how far the LO is currently off. This being due to
>the fact that in a locked condition this control word is exactly what is
>needed to compensate for the LO's offset. That makes the control word a
>extreme good measure for oscillator characterizing.
>
>Due to the internal phase comparison i can tell the device's Allan
>deviation for all observation times where the gps receiver's phase noise
>is the dominant factor. Due to a lack of measurememt equipment (this is
>a second project of mine) i currently can not tell exactly how far the
>LO's phase noise is deteriored by the DDS for observation times up to 1
>h or so.  
>
>Any comment from you on this project is highly appreciated, no matter it
>is critics or suggestion for improvements. If you feel, a lot has
>already been done, let me inform you that i am working on this project
>since some 3 years now.
>
>Thanks in advance for your comment. English is not my natural language,
>so sorry for typos and other errors.
>
>Ulrich Bangert, DF6JB
>
>
>_______________________________________________
>time-nuts mailing list
>time-nuts at febo.com
>https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>
>
>  
>