Re: [time-nuts] PC clock comparison software?
For test purposes I've occassionally set the time server polling routine to once a day and seen 20 minute errors on delinquent PCs. Other PCs might stay within a minute. 1 min per day is 694 ppm 20 min per day is 13880 ppm ntpd calls the crystal inaccuracy drift. ntpd can't handle a clock drift of more than 500 ppm. 100 ppm is reasonable. That's 8.64 seconds per day. (This PC is 115.755 ppm) Long before serious time keeping software, we used to set the equivalent of the drift correction by hand. That got us to a second per week or so on machines that were in a server room with reasonable air conditioning. My guess on your systems that are off by 20 min would be interrupts disabled/busy for long enough so that clock interrupts get lost. It's easy to tickle that if you do a lot of disk activity on a Linux box with DMA disabled on the disks. (Or was a few years ago. I haven't tried it recently.) Were all those way-off clocks running slow? If you can get ntp running on all/most of your systems, it's pretty easy to setup one system to monitor all the others. Turn on logging (peerstats) and add each system you want to monitor as a server (in your config file) with the noselect option. Tweak minpoll/maxpoll if you want to adjust the amount of data you collect. Our network is about 30 PCs on fiber OC12 ( 622Mbps) ATM with 100mbps ethernet network branches. In the near future some video conferencing and remote telescope users will add to the chunkiness of the network variable load. I wouldn't expect network troubles unless parts of your network are seriously overloaded. It's pretty easy to see busy DSL links. The ntp log files will tell you the round trip time as well as the offset of the other system. ntpd assumes network delays are symmetric. If you know the clocks on both ends are good (say both have GPS) you can measure the network delays in each direction. That is the observed offset is really an asymmetric delay. -- These are my opinions, not necessarily my employer's. I hate spam. ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] PC clock comparison software?
Charles S. Osborne said the following on 12/19/2006 09:02 PM: I have a query. Does anyone have a favorite network time sync test software? Here's my situation. Being at a radio and optical observatory, most everything we do has varying degrees of time stamp criticality on the stored data. While I could get obsessive compulsive and try to get everything sync'd every few seconds with the Z3816A/GPSCon server, much of the data is quite usable at 100ms or less time accuracy. I'd like better of course. Hi Charles -- I'm not aware of any PC monitoring software like that, but have you considered running the Windows port of NTP on the machines? That will automatically keep them in sync to within a few milliseconds to your server. Actually, I'm not sure that GPSCon supports the full NTP protocol, so you might need a software change at that end. By the way, if you're interested in having a *really* good time server, for less than $250 you could have a dedicated NTP server that can offer time with low microsecond accuracy. Check http://www.febo.com/time-freq/ntp/soekris/index.html for details and http://www.febo.com/time-freq/ntp/stats/index.html for real-time performance information about a stack of those machines running in my basement. I could probably be talked into putting the box together for you... 73, John ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] LPRO-101 with Brooks Shera's GPS locking circuit
Hal writes: It might be possible to avoid hanging bridges by dithering the sawtooth. I'm thinking of something like a heater under the xtal for the GPS unit that gets driven by a medium frequency - slow relative to the normal sawtooth but fast relative to the PLL time constant. This somehow feels not-good, but I can't see the obvious screwup. Yes on the heater; No on the medium frequency. Bruce writes: Avoidance of hanging bridges requires that the GPS receiver oscillator frequency not be a Hamonic of 1Hz at any time. Using a heater as you suggest will not solve this problem. Ideally it would be best if it were not a rational multiple of 1Hz either. Its generally simpler and easier to use the PPS sawtooth correction, if available. Resultant residual jitter is closer to Gaussian. OK, here's the real story. If you've ever spent hours or days on the bench watching the sawtooth error, noting that the pitch of the teeth changes over time, and even holding your breath waiting for one of those cute little hanging bridges to show up -- it will be obvious to you that any sudden change in the ambient temperature, or even supply voltage, or perhaps shock or vibration, will stop the hang in its tracks. Then the receiver goes back into its classical rapid sawtooth mode. And I second PHK's comments that in most cases, like older GPSDO, sawtooth is your friend. I suggested in an older thread that one place a resistor (as a heater) above the xtal on the PCB -- and when a bridge is detected -- you pulse some power into the resistor to disrupt the temporary harmonic between GPS and the xtal that causes the bridges in the first place. To be honest it was an obvious suggestion but one that I hadn't proved. And like Bruce says, if you have a receiver with sawtooth correction, and can use it, the need to worry about the character of the sawtooth is reduced. But since I hate to make suggestions that I haven't actually tried, I fired up my old SHOWTIME Oncore VP to put my money where my mouth is. The trick is to monitor the 1PPS phase and calculate the delta phase each second (which is a kind of measure of the size and pitch of the teeth). When the sawtooth is coarse and there is cycle wrapping every few seconds there is no problem. But when phase moves slowly and the teeth get large you tend to get a long ramp that is detrimental to 1PPS averaging. And if there is sign reversal during one of these long ramps you get a hanging bridge, even more detrimental to 1PPS averaging. I used a 53131 TIC and wrote code to monitor this: when the phase steps get down to just a few ns and stay that way for a while you have the makings of slow ramp or a bridge. It is at this point that you blow some heat on the xtal. And, like magic, the ramp or bridge goes away, and you go back to a healthy sawtooth mode. For a view of the heater experiment see: http://www.LeapSecond.com/pages/vp/heater.htm For a basic sawtooth example see: http://www.LeapSecond.com/pages/m12/sawtooth.htm In this case, I used my eye to detect the beginnings of a ramp or a bridge and used a hair dyer to make a quick pulse of hot air over the PCB. If you were to make this part of a sawtooth solution you can easily see how replacing my eye with some code and the hair dryer from a meter away with a 50R resistor on top of the xtal would do the trick quite nicely. /tvb ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] PC clock comparison software?
I could be talking a lot of hot air, so please forgive me, but I've had a thought: if PCs still use a Real Time Clock chip, could a hardware modification be done to give them an accurate clock frequency, rather than relying on whatever cheap crystal is installed on the mother board? Maybe one of the aforementioned TAPR Clock-Blocks configured for, I guess, a 32768 Hz output? I am worried by Hals comment though, that NMIs could upset the clock - that suggests the PC clock is not just a simple RTC, which would render the above suggestion invalid. Oh well, just a thought thrown into the arena. Peter ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] PC clock comparison software?
Peter Vince said the following on 12/20/2006 10:11 AM: I could be talking a lot of hot air, so please forgive me, but I've had a thought: if PCs still use a Real Time Clock chip, could a hardware modification be done to give them an accurate clock frequency, rather than relying on whatever cheap crystal is installed on the mother board? Maybe one of the aforementioned TAPR Clock-Blocks configured for, I guess, a 32768 Hz output? One sad thing is that the Clock-Block can't generate a precise 32768 Hz given a common (1, 5, or 10 MHz) input frequency. The available divider ratios just don't work out. (By the way, though, the Clock-Block might be useful for some low-frequency clocking tasks. The main synthesizer chip is spec'd for output down to 2MHz, though it can go quite a bit lower than that, but there is an additional divider chip on the board that can be used to divide the synthesizer output by factors from 16 to 16384.) John ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] PC clock comparison software?
My information could be out of date, but in the past, the realtime clock only set Windows on bootup. During run windows kept time off the bus crystal (hence the sensitivity to interupts) No matter how cheap, only a defective real time clock will err anything close to 1 minute/day, normal values are around 1 sec. Jay I could be talking a lot of hot air, so please forgive me, but I've had a thought: if PCs still use a Real Time Clock chip, could a hardware modification be done to give them an accurate clock frequency, rather than relying on whatever cheap crystal is installed on the mother board? Maybe one of the aforementioned TAPR Clock-Blocks configured for, I guess, a 32768 Hz output? I am worried by Hals comment though, that NMIs could upset the clock - that suggests the PC clock is not just a simple RTC, which would render the above suggestion invalid. Oh well, just a thought thrown into the arena. Peter ___ 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
Re: [time-nuts] LPRO-101 with Brooks Shera's GPS locking circuit
Hello folks, i like to play the bad boy again: My claim is a) that for most of us a GPSD Rb is of little to no use compared to a good GPSD xtal oscillator b) that it is a myth that you may use longer loop time constants with Rb compared to a xtal oscillator Let us first talk about b). It is necessary to have some basic knowledge on temperature controllers in order to understand that. Unless the temperature controller has an active cooling element (i.e. it may heat AND cool) there is a very simple mechanical model for an temperature controlled oven like being used in OCXOs: Imagine a pot having a small hole through which a fluid can slowly pour out of the pot. This hole represents the oven's insulation against the surrounding world and the fluid pouring out represents the energy that the oven looses to its surrounding due to the fact that the insulation is not 100%. Then there is a person with a second pot of fluid. This person can pour out fluid from the second pot into the first pot. The second pot represents the oven's heater by which thermal energy may be poured inside the oven and the person is the temperature controller. The oven's temperature is represented by the level of the fluid in the first pot. The controller's task is to always pour just enough fluid from the second pot into the first pot to keep the fluid level constant despite the fluid lost through the small hole. One refinement of the model is that we also consider that the amount of fluid pouring out of the hole shall not only depend on the hole's size but also on the fluid level itself inside the pot as well as the surrounding's temperature for which there is no good counterpart in the model. While this mechanical model is very easy it resembles everything very well what we need to understand about oven controllers. Now that we have this mechanical model, we can think about the parameters that influence the model's behaviour. One parameter is the size of the hole. The first idea that we might have is to make the hole as small as possible = to make the insulation as good as possible. There are lots of people who pack their HP10811 in big amounts of insulating material in order to improve it. But is it an improvement? It is surely an improvement in terms of energy because the fluid (=energy) pouring out of the hole is lost and we constantly need to put an amount of fluid (=energy) into the oven to keep the temperature constant. Now let us consider what the better insulation does for the control loop: Unlike in other controller loops we cannot take fluid (=energy) OUT of the oven. We can only put fluid (=energy) INTO the oven. Once the controller has generated a overshot (a common effect in controller loops) we cannot compensate for that overshot because the only way that fluid (=energy) can leave the process is through the little hole. Result: If a regulation overshot happens the time constant to get back to the correct temperature depends on the size of the hole. The smaller the hole the longer it will take to get back to the right temperature. Because of that we need to make the loop time constant long enough to hopefully avoid any overshots at all and near us the right temperature very slowly from below. However, if there is now a sudden step in the surrounding's temperature this will have change the amount of fluid (=energy) leaving the hole per time unit and the long loop time constant hinders the loop to react as fast as we would like. Most OCXOs are built that way. Note that the hole (= the not 100% insulation) is the ONLY way that the temperature inside the oven can be made smaller. People who addionally insulate their OCXOs make the hole size smaller and that has the effect that the loop time constant is now too fast for this oven. In contrast to that one may have the idea to make the hole really big compared to the situation above. Consider an oven that is not insulated at all. Instead it has an heating element on one side and a heat sink on the other side. Clearly, because the oven is thermically good coupled to its surrounding it looses lots of energy to the surrounding (= big hole size) so we need to put lots of energy (=fluid) into it permanently. Not a good idea in terms of efficiency but note the effect on the controller's loop time constant. Everything can be made fast compared the small hole size. If there is overshot we can expect the heat sink to remove the overshot quickly. The concept of the big hole size is what we can find with temperature controllers in Rb oscillators. Note: We are not talking about the temperature of the xtal oscillator within the frequency contrtol loop. Instead we talk about the temperature controller for the Rb lamp which is made the 'big hole size way'. Ever had an FRK-L in your hand and wondered about the heat sink on its back? Thats the big hole. Ever wondered why an LPRO shall be mounted on a heat sink of sufficient size: Thats the big hole. Whats the whole story good for
Re: [time-nuts] LPRO-101 with Brooks Shera's GPS locking circuit
In message [EMAIL PROTECTED], Ulrich Bangert writes: a) that for most of us a GPSD Rb is of little to no use compared to a good GPSD xtal oscillator ... if your hold-over requirement is trivial. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] LPRO-101 with Brooks Shera's GPS locking circuit
At 10:25 AM 12/20/2006, you wrote: Hello folks, The controller's task is to always pour just enough fluid from the second pot into the first pot to keep the fluid level constant despite the fluid lost through the small hole. One refinement of the model is that we also consider that the amount of fluid pouring out of the hole shall not only depend on the hole's size but also on the fluid level itself inside the pot as well as the surrounding's temperature for which there is no good counterpart in the model. The model for the surounding temperature is a larger pot with a fluid level which is lower than the level in the oven pot. Flow rate is dependent on the difference in the fluid levels, with the oven loosing less heat when the 'outside' pot is at a higher level. (higher temperature) Tom Buehl ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] PC clock comparison software?
The Timer/Clock interrupt is IRQ 0 no other interrupt has a higher priority, therefore this interrupt is rarely missed. If it were missed then interrupts would have to be turned off longer the 110ms (2 times the clock rate) which is an enormous amount of time and due no doubt to an improperly written device driver or faulty motherboard/card. Having said this; a device driver writer would not have interrupts turned off for long anyway, this is a bit heavy handed on a system. That's what IRQL are for. 99.9% of ISR routines are microsecond range. So this is not a source of lost timer interrupts. Time is extremely important on a telescope (which why I'm going to try the TAPR Clock Block when I get time) and I've studied this issue of lost timer interrupts. I can tell you that they just don't occur even when the system is loaded to the max. We have a watchdog card in our system to detect just such an event, it has never triggered (except when you push the test button). Jack ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
[time-nuts] Obtaining 32768Hz from 10 MHz
A discussion of driving computer clocks from accurate sources recently came up. While it's true that PCs generally use the CPU clock or the baud rate clock for the timekeeping function, the observation was made that it might be nice to run a standard RTC that uses a 32768 Hz crystal from a 10 MHz source. The TAPR Clock Block is not designed to do this, but it is easy to do using a non-PLL approach. Tom Van Baak has programmed a PIC microcontroller to make all decades of frequencies from a 10 MHz source. In a similar way, the PIC can be programmed to produce any frequency desired, such as 32768 Hz, using the method of a dual-modulus prescaler. If you're not familiar with this technique, read the Wikipedia entry: http://en.wikipedia.org/wiki/Dual-modulus_prescaler Since a PIC executes 2.500 MIPS when clocked at 10 MHz, its effective input frequency is 2.5000 MHz. The output frequency is 32768 Hz. Thus the modulus M is 76, and the remainder A is 9632. This means that you would execute 9632 loops that take 77 clock cycles, followed by (32768-9632) = 23136 loops that take 76 clock cycles, to make exactly 32768 output cycles per second given a 10 MHz CPU clock. The code for this should fill considerably less than a page of text. Bear in mind that you would be making a very ugly 32768 Hz signal if viewed in the frequency domain, so only use the above method for timekeeping. ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] LPRO-101 with Brooks Shera's GPS locking circuit
Yes, agreed! -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Poul-Henning Kamp Gesendet: Mittwoch, 20. Dezember 2006 16:43 An: Discussion of precise time and frequency measurement Betreff: Re: [time-nuts] LPRO-101 with Brooks Shera's GPS locking circuit In message [EMAIL PROTECTED], Ulrich Bangert writes: a) that for most of us a GPSD Rb is of little to no use compared to a good GPSD xtal oscillator ... if your hold-over requirement is trivial. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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
Re: [time-nuts] LPRO-101 with Brooks Shera's GPS locking circuit
Hello folks, i like to play the bad boy again: My claim is a) that for most of us a GPSD Rb is of little to no use compared to a good GPSD xtal oscillator Ulrich, That's a rather general statement, but I understand what you mean. Consider, instead of a bold general assertion which can be disproved with a single counter-example, a simple list of advantages of quartz vs. rubidium. Then let the user decide which is appropriate for their unique application. There's more to a GPSDO than its ADEV. For example, Warm-up time -- Many Rb will lock in 5 minutes, typically. Some Qz take much longer to get on-frequency from cold start. This can simplify the initial loop locking algorithm. Power consumption -- Probably Qz-based GPSDO have much lower power consumption than Rb. Physical size -- I would guess most Qz GPSDO are smaller than Rb GPSDO. One could argue that the Casio GPS wrist watches are a type of miniature GPSDO! Hold-over performance -- For mid- to long-term, Rb is vastly superior to Qz; most Rb have daily drift rates 100x better than Qz. Stand-along performance -- Without GPS lock, a free-running Rb can be trusted to be orders of magnitude more accurate than Qz. Environmental -- Is it the case that Rb is less sensitive than Qz to extreme environments? Cost -- As a rule, Qz-based GPSDO are cheaper than Rb. Phase noise -- I'd guess that Qz-based GPSDO could have better short-term stability and phase noise than Rb. Tuning range -- Could it be that Rb will run for many more years without coarse adjust than Qz? Lock indicator -- Most Rb give you a signal when frequency lock has been achieved. Mechanical sensitivity -- Rb GPSDO are much less sensitive to movement and shock than Qz. If you don't believe me watch what happens if you simply take your GPSDO and bump it, or turn it over on your desk. This is especially important during hold-over when no external correction is present. Lifetime -- Is the MTBF of Qz much longer than Rb due to fewer parts and simpler design? Surplus -- There are so many cheap telecom Rb out there it is near irresistible to make a GPSDO out of them. You get the idea; feel free to add the ones I missed. /tvb ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] LPRO-101 with Brooks Shera's GPS locking circuit
In the matter of lifetime (outside of MTBF issues), is it correct that Rb has a built-in life limiting mechanism (the lamp wears out), where Qz does not? If so, Rb oscillators will eventually fail but one might hope a Qz oscillator may not. Didier Tom Van Baak wrote: Hello folks, i like to play the bad boy again: My claim is a) that for most of us a GPSD Rb is of little to no use compared to a good GPSD xtal oscillator Ulrich, That's a rather general statement, but I understand what you mean. Consider, instead of a bold general assertion which can be disproved with a single counter-example, a simple list of advantages of quartz vs. rubidium. Then let the user decide which is appropriate for their unique application. There's more to a GPSDO than its ADEV. For example, Warm-up time -- Many Rb will lock in 5 minutes, typically. Some Qz take much longer to get on-frequency from cold start. This can simplify the initial loop locking algorithm. Power consumption -- Probably Qz-based GPSDO have much lower power consumption than Rb. Physical size -- I would guess most Qz GPSDO are smaller than Rb GPSDO. One could argue that the Casio GPS wrist watches are a type of miniature GPSDO! Hold-over performance -- For mid- to long-term, Rb is vastly superior to Qz; most Rb have daily drift rates 100x better than Qz. Stand-along performance -- Without GPS lock, a free-running Rb can be trusted to be orders of magnitude more accurate than Qz. Environmental -- Is it the case that Rb is less sensitive than Qz to extreme environments? Cost -- As a rule, Qz-based GPSDO are cheaper than Rb. Phase noise -- I'd guess that Qz-based GPSDO could have better short-term stability and phase noise than Rb. Tuning range -- Could it be that Rb will run for many more years without coarse adjust than Qz? Lock indicator -- Most Rb give you a signal when frequency lock has been achieved. Mechanical sensitivity -- Rb GPSDO are much less sensitive to movement and shock than Qz. If you don't believe me watch what happens if you simply take your GPSDO and bump it, or turn it over on your desk. This is especially important during hold-over when no external correction is present. Lifetime -- Is the MTBF of Qz much longer than Rb due to fewer parts and simpler design? Surplus -- There are so many cheap telecom Rb out there it is near irresistible to make a GPSDO out of them. You get the idea; feel free to add the ones I missed. /tvb ___ 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
Re: [time-nuts] PC clock comparison software?
Lots of good info as always from this list. I probably should mention what some of these PCs are doing. Someone asked about the telescope control PCs. The 26m dishes have their own dedicated GPS receivers for their local time standards. Those do the celestial navigation and tracking via their control PCs. Our optical telescope control PCs are almost all on XP or Win2000. So NTP should have them covered reasonably well. Test software would confirm how well. The PCs that tend to misbehave the most are Win98se Pentium 100 ~ 400 MHz. They are doing a variety of menial tasks like: seismic data, solar flare monitoring, meteor burst recording, VLF signal recording for Sudden Ionospheric Disturbances, and cosmic ray montoring. They churn along at 4 ~ 40 samples per second typically of constant data flow to the hard drive. Every minute or so they may push a screen capture to our website. Others with a somewhat higher workload are doing webcam or weather station image pushes to our website once a minute. For time/frequency we have two Z3816As and a Ball Efratom MRT free running Rubidium frequency standard. I tweak it using an HP53131time interval counter compared to the Z3816A. GPSCon V1.038 is the software running on a Win98se box. I have a newer XP box I've been trying to move to for better serving reasons. But it keeps turning itself off every night even though we've tried to turn off power saving and automatic updates. Its on a UPS with four 100AH batteries, plus four 7AH gel cells on float on the Z3816A 48vdc power side. The slightest power glitch still takes the XP computer down even though its on the UPS. But the Win98se P166 plugged into the same outlet strip on the same UPS weathers it all for months at a time without rebooting. The main network servers are Linux of one variety or another. Not sure what the latest flavors are, but mostly Red Hat Linux Fedora Core I think. The network glitches are probably power glitch related even though most things are on UPSs. We're pretty far up in the mountains, so lightning and AC supply side glitches are common. And the sheer size of the facility induces surges from EMP transferred cable to cable on site too. The primary fiber links are via 3Com ATM Core Builders with redundant fiber links. Its mostly once things get out to the localized 8~24 port switches that latch up occurs I think. Diagnostic code would help troubleshoot that since I could see which branches failed when, and if they recover. Network loading is minimal except from the main website server to the Internet via T1 ( soon OC3, then that will be minimally loaded too except during distance learning and video conferencing). tnx, Charles S. Osborne, K4CSO Technical Director Pisgah Astronomical Research Institute 1 PARI Drive, HC 73, Box 638 Rosman, NC 28772-9614 http://www.pari.edu 828-862-5813 direct 828-862-5554 main 828-862-5877 FAX [EMAIL PROTECTED] ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] LPRO-101 with Brooks Shera's GPS locking circuit
In message [EMAIL PROTECTED], Tom Van Baak writes: Warm-up time -- Many Rb will lock in 5 minutes, typically. Some Qz take much longer to get on-frequency from cold start. This can simplify the initial loop locking algorithm. Initial capture is best done with a looser timeconstant in any circumstances. Note that the integrator terms initial condition is undefined in a PLL, this can be used to achieve lock without the initial overshot: Clamp the integrator term to zero and let the proportional term drag the offset into range (use a high rate for this, there is no stability issues). Once the second derivative of the offset approaches zero, unclamp the integrator and switch to a normal but loose set of constants for the PLL. With properly chosen values, you can drag any frequency source into submission of a PPS that way in a fraction of a minute. After this the PLL can adapt its constants based on the statistics (remember what I said earlier about looking at the ADEV shape). Power consumption -- Probably Qz-based GPSDO have much lower power consumption than Rb. Single oven: Maybe, double oven: certainly. Hold-over performance -- For mid- to long-term, Rb is vastly superior to Qz; most Rb have daily drift rates 100x better than Qz. I is likely to be the difference between replacing the GPS antenna now or after the snowstorm is over. Given the price difference, this may be a no-brainer advantage to the Rb. Stand-along performance -- Without GPS lock, a free-running Rb can be trusted to be orders of magnitude more accurate than Qz. Also, if the qz in the rb jumps, the Rb is very likely to tell you it lost lock. A Qz unit will jump and you will not know it, unless the resulting phase jitter kills your microprocessor or similar. Environmental -- Is it the case that Rb is less sensitive than Qz to extreme environments? No significant difference with proper design. The Rb's cooling requirements are tricker to design for than an Qz units bolt down and forget. Cost -- As a rule, Qz-based GPSDO are cheaper than Rb. That's actually not a given. For a decent Qz performance new price approaches $1k and a PRS10 is only $1.5k. Phase noise -- I'd guess that Qz-based GPSDO could have better short-term stability and phase noise than Rb. Depends on your PLL more than anything else. Lifetime -- Is the MTBF of Qz much longer than Rb due to fewer parts and simpler design? Yes, no chemical stress and with proper drive levels, no mechanical stress either. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] A Bunch Of Lucent RFTG-m-RB units on eBay This Morning!
Has anyone got one of these (part number KS24019 L105A) up and running? Is a manual available? Bill Hawkins -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Rabel Sent: Wednesday, December 20, 2006 10:58 AM To: 'Discussion of precise time and frequency measurement' Subject: [time-nuts] A Bunch Of Lucent RFTG-m-RB units on eBay This Morning! Just a heads up, if you search eBay for 'Lucent RFTG' you will see someone has listed a bunch of the rubidium units today with BIN of $130. These are not the previously listed RFG's. The RFTG have the built-in GPS receiver (I think it's a Motorola UT+ or VP), the RFG's do not have the GPS. There's a pinout somewhere in the archives here, it uses +24V I think through some of the pins on the DB9 ports. Just last night a single one auctioned by someone else went for $284... So at the very least you can re-eBay it and probably make some cash. But on the positive side it's about as cheap as you can get for a pre-built GPS disciplined Rb source. Jason ___ 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
Re: [time-nuts] LPRO-101 with Brooks Shera's GPS locking circuit
Tom Van Baak wrote: Hal writes: It might be possible to avoid hanging bridges by dithering the sawtooth. I'm thinking of something like a heater under the xtal for the GPS unit that gets driven by a medium frequency - slow relative to the normal sawtooth but fast relative to the PLL time constant. This somehow feels not-good, but I can't see the obvious screwup. Yes on the heater; No on the medium frequency. Bruce writes: Avoidance of hanging bridges requires that the GPS receiver oscillator frequency not be a Hamonic of 1Hz at any time. Using a heater as you suggest will not solve this problem. Ideally it would be best if it were not a rational multiple of 1Hz either. Its generally simpler and easier to use the PPS sawtooth correction, if available. Resultant residual jitter is closer to Gaussian. OK, here's the real story. If you've ever spent hours or days on the bench watching the sawtooth error, noting that the pitch of the teeth changes over time, and even holding your breath waiting for one of those cute little hanging bridges to show up -- it will be obvious to you that any sudden change in the ambient temperature, or even supply voltage, or perhaps shock or vibration, will stop the hang in its tracks. Then the receiver goes back into its classical rapid sawtooth mode. And I second PHK's comments that in most cases, like older GPSDO, sawtooth is your friend. I suggested in an older thread that one place a resistor (as a heater) above the xtal on the PCB -- and when a bridge is detected -- you pulse some power into the resistor to disrupt the temporary harmonic between GPS and the xtal that causes the bridges in the first place. To be honest it was an obvious suggestion but one that I hadn't proved. And like Bruce says, if you have a receiver with sawtooth correction, and can use it, the need to worry about the character of the sawtooth is reduced. But since I hate to make suggestions that I haven't actually tried, I fired up my old SHOWTIME Oncore VP to put my money where my mouth is. The trick is to monitor the 1PPS phase and calculate the delta phase each second (which is a kind of measure of the size and pitch of the teeth). When the sawtooth is coarse and there is cycle wrapping every few seconds there is no problem. But when phase moves slowly and the teeth get large you tend to get a long ramp that is detrimental to 1PPS averaging. And if there is sign reversal during one of these long ramps you get a hanging bridge, even more detrimental to 1PPS averaging. I used a 53131 TIC and wrote code to monitor this: when the phase steps get down to just a few ns and stay that way for a while you have the makings of slow ramp or a bridge. It is at this point that you blow some heat on the xtal. And, like magic, the ramp or bridge goes away, and you go back to a healthy sawtooth mode. For a view of the heater experiment see: http://www.LeapSecond.com/pages/vp/heater.htm For a basic sawtooth example see: http://www.LeapSecond.com/pages/m12/sawtooth.htm In this case, I used my eye to detect the beginnings of a ramp or a bridge and used a hair dyer to make a quick pulse of hot air over the PCB. If you were to make this part of a sawtooth solution you can easily see how replacing my eye with some code and the hair dryer from a meter away with a 50R resistor on top of the xtal would do the trick quite nicely. /tvb ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts Tom These experiments raise the obvious question. Surely the Brooks Shera phase detector is also inherently subject, in itself, to the hanging bridge and other slow sawtooth measurement errors? Has anyone checked to see if this occurs? Surely these effects can be eliminated by phase modulating the crystal as done in the HP5345A (HP Journal June 1974)? Bruce ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Brooks Shera's GPS locking circuit faults and fixes
The phase detector itself in Brooks Shera's GPS locking circuit has several problems: 1) There are no synchronisers so that the partial width pulse response of the counters biases the output. 2) Possible synchronism between the (24MHz) phase measurement clock and the time interval being measured will bias the result. The cures are 1) use synchronisers to ensure that only full width pulses are counted. 2) Randomly phase modulate the (24MHz) clock to destroy any possible coherence. The necessary phase modulation amplitude can be found in /Time Interval Averaging: Theory, Problems, and Solutions/, David Chu, HP Journal June 1974 pp12-15. Of course one still has to cure the hanging bridges and slow ramp timing errors produced by the GPS receiver. Of course these could be cured by random phase modulation of the GPS receiver PPS output pulse timing clock. Phase modulating the GPS receiver timing clock may also be sufficient to eliminate the synchronous bias in the Brooks Shera phase detector, however synchronisers are still required. Random phase modulation of the receiver local oscillator frequencies may be somewhat counter-productive. Bruce ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Brooks Shera's GPS locking circuit II
Let me add a note. The Shera controller also has a hold mode. This mode will freeze the DAC output at its current voltage. So when its engaged with a rubidium oscillator, your rubidium becomes a normal unit, except it has been super tuned to UTC ! Short term specs return to normal, etc. Somebody asked a question about the GPS sawtooth bridge and the controller. If the controller detects a problem during the measurement period ( and remember it looks at the last value, the present value and the future value), it will throw out that solution, as it is not valid. It holds the last used value in the DAC. ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
[time-nuts] Looking for QST Jan 1990 Article on Crystal S, Q R testing By DeMaw
Hi: I'm looking for the subject article on crystal testing, or any other articles on testing crystals. This is more related to knowing if a given crystal is alive than characterizing it, i.e. a Crystal Activity Meter type thing. Have Fun, Brooke Clarke -- w/Java http://www.PRC68.com w/o Java http://www.pacificsites.com/~brooke/PRC68COM.shtml http://www.precisionclock.com ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] PC clock comparison software?
Probably what to take this off list. Eek screen capture. That's one of those heart stoppers on the Win9x platforms, it's got nothing to do with Windows, it the device driver in some of those old cards that CLI (Clear interrupts) for a long period. We had issues with this causing Netware Client's to start outputting wrong time stamps IIR (It's been 12 years). We solve the power glitch issue with an isolation transformer. We're at the end of a 15 miles of power line and like you, it pickups a lot of trash on the way. I'm sure your guys have done this, but it doesn't hurt to check. Failing that try to push through a req for a toroidal type UPS, there you get isolation with virtually instant cutover. The only issue I have with them is making sure you turn them on without any load; in a glitchy environment the huge current in-rush would cause all the UPS's on that circuit to trip. If you can setup a NTP server that Win98se box with the GPSCon on it; that would solve your time synchronization issues. Question: What are they using to sample data with? Some sort of National Instruments DAC, GPIB, HPIB device, or network? Jack -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles S. Osborne Sent: Wednesday, December 20, 2006 2:30 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] PC clock comparison software? Lots of good info as always from this list. I probably should mention what some of these PCs are doing. Someone asked about the telescope control PCs. The 26m dishes have their own dedicated GPS receivers for their local time standards. Those do the celestial navigation and tracking via their control PCs. Our optical telescope control PCs are almost all on XP or Win2000. So NTP should have them covered reasonably well. Test software would confirm how well. The PCs that tend to misbehave the most are Win98se Pentium 100 ~ 400 MHz. They are doing a variety of menial tasks like: seismic data, solar flare monitoring, meteor burst recording, VLF signal recording for Sudden Ionospheric Disturbances, and cosmic ray montoring. They churn along at 4 ~ 40 samples per second typically of constant data flow to the hard drive. Every minute or so they may push a screen capture to our website. Others with a somewhat higher workload are doing webcam or weather station image pushes to our website once a minute. For time/frequency we have two Z3816As and a Ball Efratom MRT free running Rubidium frequency standard. I tweak it using an HP53131time interval counter compared to the Z3816A. GPSCon V1.038 is the software running on a Win98se box. I have a newer XP box I've been trying to move to for better serving reasons. But it keeps turning itself off every night even though we've tried to turn off power saving and automatic updates. Its on a UPS with four 100AH batteries, plus four 7AH gel cells on float on the Z3816A 48vdc power side. The slightest power glitch still takes the XP computer down even though its on the UPS. But the Win98se P166 plugged into the same outlet strip on the same UPS weathers it all for months at a time without rebooting. The main network servers are Linux of one variety or another. Not sure what the latest flavors are, but mostly Red Hat Linux Fedora Core I think. The network glitches are probably power glitch related even though most things are on UPSs. We're pretty far up in the mountains, so lightning and AC supply side glitches are common. And the sheer size of the facility induces surges from EMP transferred cable to cable on site too. The primary fiber links are via 3Com ATM Core Builders with redundant fiber links. Its mostly once things get out to the localized 8~24 port switches that latch up occurs I think. Diagnostic code would help troubleshoot that since I could see which branches failed when, and if they recover. Network loading is minimal except from the main website server to the Internet via T1 ( soon OC3, then that will be minimally loaded too except during distance learning and video conferencing). tnx, Charles S. Osborne, K4CSO Technical Director Pisgah Astronomical Research Institute 1 PARI Drive, HC 73, Box 638 Rosman, NC 28772-9614 http://www.pari.edu 828-862-5813 direct 828-862-5554 main 828-862-5877 FAX [EMAIL PROTECTED] ___ 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
Re: [time-nuts] A Bunch Of Lucent RFTG-m-RB units on eBay ThisMorning!
There was this post a while back for a RFG: http://www.febo.com/pipermail/time-nuts/2005-October/019674.html But I could of sworn I found a more complete pinout elsewhere. I'm about to search through my browser history to see if I can find the other URL(s) with info. Jason Has anyone got one of these (part number KS24019 L105A) up and running? Is a manual available? Bill Hawkins ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Looking for QST Jan 1990 Article on Crystal S, Q R testing By DeMaw
Brooke - In that case why do not just use a signal generator like an 8640B with the crystal in series with the hot lead and then the other side of the crystal terminated in 1K or so. Then you can put a scope across the 1K resistor and watch the scope as you tune across the suspected resonant frequency. I have done this a lot when I was not sure of the crystal frequency, or, if it was working or not. Real simple to do. If all else fails, I am sure I have the QST you mentioned, and could scan the relevant pages for you. I also have a military crystal activity meter that does do a full characterization, but, it is big and bulky, and, I hardly ever use it. 73 Merry Christmas - Mike Mike B. Feher, N4FS 89 Arnold Blvd. Howell, NJ, 07731 732-886-5960 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brooke Clarke Sent: Wednesday, December 20, 2006 5:15 PM To: Discussion of precise time and frequency measurement Subject: [time-nuts] Looking for QST Jan 1990 Article on Crystal S,Q R testing By DeMaw Hi: I'm looking for the subject article on crystal testing, or any other articles on testing crystals. This is more related to knowing if a given crystal is alive than characterizing it, i.e. a Crystal Activity Meter type thing. Have Fun, Brooke Clarke -- w/Java http://www.PRC68.com w/o Java http://www.pacificsites.com/~brooke/PRC68COM.shtml http://www.precisionclock.com ___ 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
[time-nuts] 9825a printer
got a working hp 9825a that has a strip printer that works also. the printer prints in double size instead of regular size and i have not found the command to reduce the double size printing. would any one on this reflector know what that command would be? tom [EMAIL PROTECTED] ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Looking for QST Jan 1990 Article on Crystal S, Q R testing By DeMaw
Hi Mike: I've received an email asking about where to purchase a crystal activity meter and although I have a hand held unit, see: http://www.pacificsites.com/~brooke/Xam.html don't want to part with it. This is an older unit that uses PNP transistors. I'm now thinking about how to build one using a PIC and to that end would like to see what's in the subject article. So if you would email a copy to mailto:[EMAIL PROTECTED] that sure would help. The final product should be a hand held battery powered easy to use device. Have Fun, Brooke Clarke w/Java http://www.PRC68.com w/o Java http://www.pacificsites.com/~brooke/PRC68COM.shtml http://www.precisionclock.com Mike Feher wrote: Brooke - In that case why do not just use a signal generator like an 8640B with the crystal in series with the hot lead and then the other side of the crystal terminated in 1K or so. Then you can put a scope across the 1K resistor and watch the scope as you tune across the suspected resonant frequency. I have done this a lot when I was not sure of the crystal frequency, or, if it was working or not. Real simple to do. If all else fails, I am sure I have the QST you mentioned, and could scan the relevant pages for you. I also have a military crystal activity meter that does do a full characterization, but, it is big and bulky, and, I hardly ever use it. 73 Merry Christmas - Mike Mike B. Feher, N4FS 89 Arnold Blvd. Howell, NJ, 07731 732-886-5960 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brooke Clarke Sent: Wednesday, December 20, 2006 5:15 PM To: Discussion of precise time and frequency measurement Subject: [time-nuts] Looking for QST Jan 1990 Article on Crystal S,Q R testing By DeMaw Hi: I'm looking for the subject article on crystal testing, or any other articles on testing crystals. This is more related to knowing if a given crystal is alive than characterizing it, i.e. a Crystal Activity Meter type thing. Have Fun, Brooke Clarke ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
[time-nuts] Looking For Brandywine GPS-4 User Manual
Does anyone by chance have a PDF manual for a Brandywine GPS-4 (not the PDF spec sheet on their site)? Also, if it's not mentioned in the manual, what is the power input for the unit? I've tried contacting the Brandywine people a couple times, have not received a reply. :( Thanks, Jason ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Looking for QST Jan 1990 Article on Crystal S, Q R testing By DeMaw
I did just that to check the 50 MHz crystal in my HP 3586 and convince myself it was not dead. The 50 MHz VCXO did not oscillate, for some reason, and finding a replacement crystal would have been a long shot and would have probably cost more than I paid for the instrument. Seeing the proper response (I used the spectrum analyzer instead of a scope, but that's the same idea, I used an HP 8656A as a source, which was not optimum because of the 100 Hz step size, but it worked), I determined the crystal was most likely OK. I added a small cap to the VCXO circuit to increase gain a little bit and the oscillator came alive. It's been working for over a year now. Didier KO4BB Mike Feher wrote: Brooke - In that case why do not just use a signal generator like an 8640B with the crystal in series with the hot lead and then the other side of the crystal terminated in 1K or so. Then you can put a scope across the 1K resistor and watch the scope as you tune across the suspected resonant frequency. I have done this a lot when I was not sure of the crystal frequency, or, if it was working or not. Real simple to do. If all else fails, I am sure I have the QST you mentioned, and could scan the relevant pages for you. I also have a military crystal activity meter that does do a full characterization, but, it is big and bulky, and, I hardly ever use it. 73 Merry Christmas - Mike Mike B. Feher, N4FS 89 Arnold Blvd. Howell, NJ, 07731 732-886-5960 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brooke Clarke Sent: Wednesday, December 20, 2006 5:15 PM To: Discussion of precise time and frequency measurement Subject: [time-nuts] Looking for QST Jan 1990 Article on Crystal S,Q R testing By DeMaw Hi: I'm looking for the subject article on crystal testing, or any other articles on testing crystals. This is more related to knowing if a given crystal is alive than characterizing it, i.e. a Crystal Activity Meter type thing. Have Fun, Brooke Clarke ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] A Bunch Of Lucent RFTG-m-RB units on eBay This Morning!
On Wed, Dec 20, 2006 at 10:58:02AM -0600, Jason Rabel wrote: Just a heads up, if you search eBay for 'Lucent RFTG' you will see someone has listed a bunch of the rubidium units today with BIN of $130. These are not the previously listed RFG's. The RFTG have the built-in GPS receiver (I think it's a Motorola UT+ or VP), the RFG's do not have the GPS. There's a pinout somewhere in the archives here, it uses +24V I think through some of the pins on the DB9 ports. I think you just steered me down a blind alley... I grabbed the last two of these at the newer higher price of $185 BIN but more careful searching shows photos of a box without any evident GPS antenna input. I think the part with the GPS is the RFTG-M-XO which contains a disciplined OXCO with optional rubidium input from the RFTG-M-RB box. I suppose there must be a EFC voltage input or, much more useful, a 1 PPS input that syncs the Rb. But they appear to be a pair. I suppose that isn't too bad a price for a Rb oscillator if they have reasonably low hours and are the long lived telco kind... And a Rb oscillator with a PLL that expects a 1 PPS might be quite useful at that price. -- Dave Emery N1PRE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either. ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Looking For Brandywine GPS-4 User Manual
Hi, Tried sending it via this list, but there is a 128KB limit. Please send me your direct email address. 73, Bob N1VQR -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Rabel Sent: Wednesday, December 20, 2006 8:45 PM To: 'Discussion of precise time and frequency measurement' Subject: [time-nuts] Looking For Brandywine GPS-4 User Manual Does anyone by chance have a PDF manual for a Brandywine GPS-4 (not the PDF spec sheet on their site)? Also, if it's not mentioned in the manual, what is the power input for the unit? I've tried contacting the Brandywine people a couple times, have not received a reply. :( Thanks, Jason ___ 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
