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@febo.com >https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > > > _______________________________________________ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts