Re: [time-nuts] WWVB New Modulation scheme...
On 10/26/2012 08:26 PM, Peter Gottlieb wrote: I've used the HP 3586 for measuring AM carrier frequencies as well as my Tek 495P (both referenced to Rb) for higher frequencies such as air band. Some carriers are dead nuts on while others are quite far off (at least to my mind) although I've never found one outside of its required tolerance. It seems possible to measure pretty accurately with these instruments, at least on AM or CW signals, but not sure the best way for FM. I've played with the HP 53310A but haven't set it up for precise measurements yet, or really studied what all it is capable of. Peter On 10/26/2012 11:10 PM, Orin Eman wrote: Looks like they _might_ have been 30 _Hz_ out... I had to tune to 1188.97 to get a 1kHz beat in upper sideband mode a few minutes ago but they are within 10Hz of where they are supposed to be now - according to my radio anyway (I just checked the radio against WWV at 5MHz and it was less than 10Hz out). Orin, KJ7HQ. On Fri, Oct 26, 2012 at 7:41 PM, Bob Camp li...@rtty.us wrote: Hi Not to mention attention from the guy who *should* be 3 channels over … Bob On Oct 26, 2012, at 10:31 PM, Peter Gottlieb n...@verizon.net wrote: It would attract a lot of attention from people not finding it at the right place on the dial. On 10/26/2012 10:09 PM, Max Robinson wrote: The frequency of 1190 indicates an AM station. I assume you mean 30 Hz. An error of 30 KHz would attract a lot of attention from Charley. Regards. Max. K 4 O DS. Email: m...@maxsmusicplace.com Transistor site http://www.funwithtransistors.net Vacuum tube site: http://www.funwithtubes.net Woodworking site http://www.angelfire.com/electronic/funwithtubes/Woodworking/wwindex.html Music site: http://www.maxsmusicplace.com To subscribe to the fun with transistors group send an email to. funwithtransistors-subscr...@yahoogroups.com To subscribe to the fun with tubes group send an email to, funwithtubes-subscr...@yahoogroups.com To subscribe to the fun with wood group send a blank email to funwithwood-subscr...@yahoogroups.com - Original Message - From: Chuck Forsberg WA7KGX N2469R c...@omen.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Friday, October 26, 2012 12:14 AM Subject: Re: [time-nuts] WWVB New Modulation scheme... I have my 3586b slaved to my Thunderbolt along with a Flex-1500 radio, Racal-Dana counter, Advantest Spectrum analyzer and Gigatronics signal generator. You might be interested to know KEX 1190 in Portland is about 30 kHz low. At least they aren't spewing IBOC lately. -- Chuck Forsberg WA7KGX N2469R c...@omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc The High Reliability Software 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 ___ 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. ___ 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. - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1427 / Virus Database: 2441/5355 - Release Date: 10/26/12 ___ 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. ___ 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. ___ 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. - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1427 / Virus Database: 2441/5355 - Release Date: 10/26/12 1189.9698 30 Hz low. I was confused by Bush's 500 trillion tax cut. WWV on 5 reads correct within 0.1 Hz on my CPS locked 3586b+ ___ 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. -- Chuck Forsberg WA7KGX N2469R c...@omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc The High Reliability Software 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 ___ 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
Re: [time-nuts] Timing performance of servers
Dear Edgardo, On 10/25/2012 02:04 AM, Edgardo Molina wrote: Dear Mangus, I will allow myself to share a comment on your thread. Timing on windows servers is not one of their plausible strengths. This comes as no surprise, but I wanted some hard fact to assist in raising the awareness. The reason I raised it here is that I didn't have the hard facts at hand when I needed it, and I trust the time-nuts to have a diversity of facts laying around. :) It was clearly pointed out during the SIM conference last week at CENAM. In fact there was an interesting discussion about the drawbacks when using NTP Windows based servers and all kind of NTP appliances compared to full size Linux based NTP servers. Is there a presentation or even a paper to illustrate this? The example of what NIST is using nationwide for their servers set an example of good server hardware and linux to provide the nation's NTP pulse. Interesting. I have however pointed out that a downside to their strategy is that wide-spread set of servers assist to keep network effects down. In Sweden SP (NMI) and NETNOD operates redundant servers in 4 different locations, at SP and at the three main internet exchange-points. I haven't done any experiments with Windows for NTP services, still it could be interesting as to set a benchmark while comparing it to the Linux boxes. My gut feeling says that an undisciplined Windows can be anywhere, configuring a server for the SNTP brings it into decent shape for most workstation usages, shifting over to NTP is needed for many applications but even that won't compete with a Linux or BSD box. Being able to show that in a paper is better than arm-waving, even if most people here most probably would believe me without much fact. I am currently trying out the Domain Time II NTP client from Symmetricom for the thesis. I have to come back to Symmetricom's Miguel García to decide on purchasing a Domain Time II NTP client kit. How is the Mainberg NTP client different from the Symmetricom version? Have you tried both? I haven't tried either, as I rarely operate a Windows box. If not I will be more than glad to help comparing both if you can help me pointing out the source for a demo version of Mainberg's software. Meinberg's NTP is available in fullblown version from their website: http://www.meinberg.de/german/sw/ntp.htm (the link to that page is available on their front page under the dubious and hard to grasp title NTP Software Sownload) What they have done is essentially port the ntp.org NTP to Windows and gift-wrapped it a little in terms of installation. Maybe then an objective review of both clients will be in order, I will be more than glad to do it or to test them against Windows NTP services, appliances and/or Linux NTP boxes. I have at least an example of those at the office. Actually, doing this kind of measurement could be illustrative that your time may be quite dispersed. It helps to raise the question of what time is it really, how could I improve it and can there be an approval mark on the time I have. -13 Just my 2x10 cents. That's a large frequency deviation among time-nuts. :) Regards to you and the group, Many thanks! Cheers, Magnus ___ 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.
Re: [time-nuts] Timing performance of servers
David, On 10/25/2012 07:03 AM, David J Taylor wrote: Magnus, If it helps, I have my own measurements of the Meinberg NTP port and later versions running on Windows here: http://www.satsignal.eu/mrtg/performance_ntp.php Strategy: 1 - have one FreeBSD (not Linux) server, although this is now not essential, but it's nice as a confirmation that the rest is working OK. 2 - Configure some Windows PCs as stratum-1 servers fed from GPS. On the plots above, PCs Alta, Bacchus, Feenix and Stamsund are acting as stratum-1 servers. These all have serial port connections, and cover the OS range Windows 2000, XP, Win-7/32 and Win-7/64. All are using the kernel-mode serial port driver patch developed by Dave Hart. PC Pixie is the FreeBSD box. 3 - For the client PCs, use a fixed 32-second polling interval to the local stratum-1 servers, with Internet servers as a backup polled at 1024 seconds, resulting in a configuration file something like: ___ # Use drift file driftfile C:\Tools\NTP\etc\ntp.drift # Use specific local NTP servers server 192.168.0.3 iburst minpoll 5 maxpoll 5 prefer # Pixie server 192.168.0.2 iburst minpoll 5 maxpoll 5 # Feenix server 192.168.0.7 iburst minpoll 5 maxpoll 5 # Stamsund # Use pool NTP servers pool uk.pool.ntp.org iburst minpoll 10 ___ The client performance varies, with some of the best results being on a Windows-8 Wi-Fi connected PC which seems to have very good drivers (PC Bergen). Jitter is 40 - 110 microseconds. Windows XP also shows low jitter, but greater offset (within 250 microseconds). Windows Vista was the worst performer I had, but that PC has now been retired. There are discussions in progress at the moment about improving Windows-Vista and Windows-7 as a Windows time interval setting and reporting bug has been discovered, particularly affecting NTP. Lovely! I'm impressed. What's the reasons for the offsets? Can't your tool handle negative values? It would be good to have min, max, max-min, avg, std.dev values without offsets to help illustrate worst-case behaviour as well as average performance and noise energy. The more advanced plotter would show MADEV, TDEV and MTIE plots. Ah well. Would it be possible to set up so you could measure deviation on SNTP and undisciplined machines? PS. Have my summerhouse not to far away from the town Ystad. Cheers, Magnus ___ 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.
Re: [time-nuts] time-nuts Digest, Vol 99, Issue 111
Dear Jacques, On 10/25/2012 11:17 AM, Jacques Tiete wrote: Hello Magnus, I know what you're talking about, I'm working for a company specialized in broadcasting (from studio's to stations to satellites...) and in this world correct timing is paramount, we live by the 1/25 second rythm and even less if you have to sync on a line in the image ;-). Some time ago we were instaling a complete TV station and had huge problems with image stability and also especially the correct starting time of a clip or transmission. Nobody wants to start his newsreel at eg. 20:00:05;23... it must be 20:00:00;00 We were looking into this and noticed that the customers servers (Win!) where synced by SNTP, this is plain c..p! Have a look @ http://technet.microsoft.com/en-us/library/cc773013(WS.10).aspx Especially where it says: */Important The W32Time service is not a full-featured NTP solution that meets time-sensitive /* */application needs and is NOT SUPPORTED by Microsoft as such. For more information, /* */see Microsoft Knowledge Base article 939322, Support boundary to configure the /* */Windows Time service for high-accuracy environments./* Also have a look @ http://support.microsoft.com/kb/939322 It says: */We do not guarantee and we do not support the accuracy of the W32Time service /* */between nodes on a network. The W32Time service is not a full-featured NTP solution/* */that meets time-sensitive application needs. The W32Time service is primarily /* */designed to do the following:/* */Make the Kerberos version 5 authentication protocol work. Provide loose sync time for client computers. The W32Time service cannot reliably maintain sync time to the range of 1 to 2 seconds. /* */Such tolerances are outside the design specification of the W32Time service./* So it is... 1 to 2 seconds These are very valuable references, many thanks for bringing them to my attention. Our video playout servers are decent super stable units that use heaps of Xilinx FPGA's for coding/decoding videostreams supervised by a mil-spec VXworks OS, it uses the so-called LTC for synchronising the playout, implemented mostly in hardware so I did not suspect our machines. I did install a new TCG (TimeCode Generator) where I also had heaps of problems with, I did debug the stuff together with the manufacturer's RD and finally got a perfectly synced station AND a Stratum-1 NTP (everything in double with automatic failover, a requirement for a TV-station). (Thanks to lurking for years as a genetically predispositioned Time-Nut, my father was a watchmaker...So I knew more or less what a was talking about and could prove things thanks to my TBolt etc.) Then I did install Meinberg NTP-client on every Win machine and all was suddenly perfectly running, everybody happy! This also solved some frequent file versioning problems for storing different versions of videoclips especially in a mixed Win/Lin environment where Linux proved to be the more logical/strict way of implementation. This is a valuable experience to share. Many thanks! Another thing, being considered as the local video timenut a colleague called me from Saudi Arabia where he was having timing problems on two locations spaced 700km. apart where he had funny image jumps at the exact same time, both stations were synced by each the same TCG with GPS option (same as above), could the americans jam the GPS signals over there, somebody heard about this? It could be a real problem for us, we may need to use another method for station timing (Rb maybe, with some regular syncing etc.) There are geographical areas where you have higher risk of being the indirect target, yes. Sorry for my long message but I don't often send timenut mail and this is a good example of some real-life timenutting ;-) Then you should share me of your experience. :) This was a very nice post. I also have here a nice BeagleBone mini Linux board resting, where I would want to install a FreeBSD image on and implement a NTP with a promising GPS board from Adafruit, something for the long and cosy winter evenings... :-) So many nice projects. :) Have a BeagleBone lying around here somewhere. Putting a GPS onto it would be a great project. :) Cheers, Magnus ___ 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.
Re: [time-nuts] Timing performance of servers
On 10/25/2012 01:17 PM, Bob Camp wrote: Hi Judah Levine (probably spelled his name wrong) from NIST has a series of papers on this. They go back into the 90's. For once you got his name right :) I will go back to his papers (NIST has 106 papers with his name on it) as there is surely a lot of things that he written that can be useful. However, I wonder if he ever bothered to illustrate the issues that I wanted to educate folks with. Judah showed the NIST time clock labs for us. They are now up to 386 based machines to maintain the NIST time-scales. They only do work every 12 min anyway, so it doesn't really care if they can cut time from 4 s to 0,4 s. Cheers, Magnus ___ 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.
Re: [time-nuts] Timing performance of servers
Sarah, On 10/25/2012 06:44 PM, Sarah White wrote: 1) Thanks magnus. This is something I'm quite interested in: I'm not the only one doing testing for Microsoft NT 5.x and higher against NTP-type synchronization. It's actually high enough quality such that a Windows server running NTP with a refclock provides significantly better time than the public NTP servers. Here are a few writeups I've been using for reference, and I've been testing and duplicating some of the listed configurations, hoping for my own writeups: http://www.satsignal.eu/ntp/NTP-on-Windows-Vista.html (basic timing) http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html (connected to refclock, timing was better than 50 microseconds jitter, averaging less than 10 microseconds) Am actively in the process of getting everything to replace my own navigation GPS refclock with a timing mode one. At this point I just need to find a good antenna... That's a whole lot of information there. Many thanks for those links. Cheers, Magnus ___ 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.
Re: [time-nuts] time-nuts Digest, Vol 99, Issue 120
There are two ways to measure the carrier frequency using a Spectrum analyzer. 1) have bandwidth sufficient to capture all the sidebands produced by the FM signal. 2) Have your bandwidth set very narrow, 10Hz or so and tune it directly on the carrier frequency. The carrier frequency should stand out at the wide bandwidth and then zoom in on it when using the spectrum analyzer. There are situations with PSK signals where the carrier is always canceled out. As there are certain modulation indexes when a pure tone is being used where the carrier goes to zero. But with music or voice modulation this will not be a problem. I have notices that only one digital TV station here in Lexington KY is right on. Some are hundreds of Hz off. 73 Bill wa4lav At 12:00 PM 10/27/2012 +, you wrote: From: Peter Gottlieb n...@verizon.net I've used the HP 3586 for measuring AM carrier frequencies as well as my Tek 495P (both referenced to Rb) for higher frequencies such as air band. Some carriers are dead nuts on while others are quite far off (at least to my mind) although I've never found one outside of its required tolerance. It seems possible to measure pretty accurately with these instruments, at least on AM or CW signals, but not sure the best way for FM. I've played with the HP 53310A but haven't set it up for precise measurements yet, or really studied what all it is capable of. ___ 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.
Re: [time-nuts] Timing performance of servers
David, [] Lovely! I'm impressed. What's the reasons for the offsets? Can't your tool handle negative values? It would be good to have min, max, max-min, avg, std.dev values without offsets to help illustrate worst-case behaviour as well as average performance and noise energy. The more advanced plotter would show MADEV, TDEV and MTIE plots. Ah well. Would it be possible to set up so you could measure deviation on SNTP and undisciplined machines? PS. Have my summerhouse not to far away from the town Ystad. Cheers, Magnus ___ I'm glad the information was helpful, Magnus. Yes, the tool I use - MRTG - can't handle negative values, and I haven't yet had the need or enthusiasm to convert to RRDtool which likely can. I do also collect the normal NTP statistics on some PCs and wrote an NTP Plotter program to analyse those here: http://www.satsignal.eu/software/net.htm#NTPplotter Move your mouse over the list of plots below to see the different plots. It doesn't include the more advanced statistics which you mention. The plots in MRTG are from a Perl script which uses ntpq and interprets the output into the two numbers needed for an MRTG plot. Another tool I offer is my NTP Monitor program: http://www.satsignal.eu/software/net.htm#NTPmonitor This tries to use NTP or time protocol to determine the time on a remote PC, and plots it against a reference such as a local PC. It's a coarser tool than using the NTP statistics, and was designed when my own time keeping was much worse, and I had no local stratum-1 servers. You could possibly do something simialr in Perl and use that to feed MRTG. PS. We know Sweden and Norway from holiday visits, and Ystad from the excellent Wallander TV series (in Swedish)! A Northern Lights Norway trip is written up here: http://www.satsignal.eu/Hols/2010/NorthernNorway/index.html Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ 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.
[time-nuts] 5061B ops manual without missing pages?
Does anyone have a copy of the 5061B ops manual that does not have pages 3-7 and 3-8 missing? The copy at the Agilent site doesn't have those, and they are the basic start-up instructions. I am guessing that the steps are not much different than those in the 5061A manual (which I have), but it would be nice to have a complete manual. Thanks! John ___ 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.
Re: [time-nuts] 5061B ops manual without missing pages?
John, I have an original manual with the pages of interest. Would you like me to scan and send? Had K7MLR -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of John Ackermann N8UR Sent: Saturday, October 27, 2012 09:06 To: Discussion of precise time and frequency measurement Subject: [time-nuts] 5061B ops manual without missing pages? Does anyone have a copy of the 5061B ops manual that does not have pages 3-7 and 3-8 missing? The copy at the Agilent site doesn't have those, and they are the basic start-up instructions. I am guessing that the steps are not much different than those in the 5061A manual (which I have), but it would be nice to have a complete manual. Thanks! John ___ 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. ___ 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.
Re: [time-nuts] 5061B ops manual without missing pages?
That would be wonderful, Had. Thanks so much! John Had said the following on 10/27/2012 12:09 PM: John, I have an original manual with the pages of interest. Would you like me to scan and send? Had K7MLR -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of John Ackermann N8UR Sent: Saturday, October 27, 2012 09:06 To: Discussion of precise time and frequency measurement Subject: [time-nuts] 5061B ops manual without missing pages? Does anyone have a copy of the 5061B ops manual that does not have pages 3-7 and 3-8 missing? The copy at the Agilent site doesn't have those, and they are the basic start-up instructions. I am guessing that the steps are not much different than those in the 5061A manual (which I have), but it would be nice to have a complete manual. Thanks! John ___ 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. ___ 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. ___ 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.
[time-nuts] WWVB cheap chip saa6579 RDS decoder back to the chip
Hello to the group. I see the thread took a left turn a day or so ago so thought I would fire up a new one for the interested in the phillips saa6579 RDS chip. Several others have purchased this chip. Jameco electronics had them for 10 or 20 cents. I picked up 10. You had order that many as I recall. Its a costas loop but will say the documentations skimpy. My interest Restoring the old style frequency rcvrs to operation. Like the HP vlf117, tracor 599, fluke 207 A byproduct of accomplishing that is you can restore the old time rcvrs also like the spectracom 8170s. Lastly end up with the new wwvb code to do something with. Thats really low on my list of interests actually. Have tried many approaches to date. The doubling and dividing stuff. Fades and noise are a killer for this approach. So stopped work on those. One hack that works is a small fast uproc that detects phase flips using a spectracom 8163 VCO chain as the reference. When a flip occurs you flip an rf amplifier phase to invert it. Its a hack and you need a spectracom. But this voids a favorite requirement of mine KISS. So currently building a discreet costas loop using ad633s see how that works. To the saa6579 As mentioned in the other thread. Simple to hook up. Cheap Requires 1000uv or more so that ends up making things more complicated. But in my case simply did not really work at 57 or 60 Khz. As some someone pointed out you may have to take the clock and data to a flip flop to get the correct information. Regards Paul WB8TSL ___ 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.
Re: [time-nuts] Timing performance of servers
Dear Magnus, I do not have a reference for the performance of Windows as NTP server. This has been a busy week and long working nights. It is a logical workload after being absent for nearly two weeks : ) I will browse the web and NIST to find some solid references to this issue. I am still enthusiastic about doing the side by side comparison for measuring various parameters between a Windows and a Linux box running NTP. It will require time to set the test but the contribution could be interesting, specially if no work has been done previously. I will use my spare time this weekend to search for information on the subject. Regards, Edgardo Molina Dirección IPTEL www.iptel.net.mx T : 55 55 55202444 M : 04455 20501854 Piensa en Bits SA de CV Información anexa: CONFIDENCIALIDAD DE INFORMACION Este mensaje tiene carácter confidencial. Si usted no es el destinarario de este mensaje, le suplicamos se lo notifique al remitente mediante un correo electrónico y que borre el presente mensaje y sus anexos de su computadora sin retener una copia de los mismos. Queda estrictamente prohibido copiar este mensaje o hacer usode el para cualquier propósito o divulgar su en forma parcial o total su contenido. Gracias. NON-DISCLOSURE OF INFORMATION This email is strictly confidential and may also be privileged. If you are not the intended recipient please immediately advise the sender by replying to this e-mail and then deleting the message and its attachments from your computer without keeping a copy. It is strictly forbidden to copy it or use it for any purpose or disclose its contents to any third party. Thank you. On Oct 27, 2012, at 8:47 AM, Magnus Danielson mag...@rubidium.dyndns.org wrote: Dear Edgardo, On 10/25/2012 02:04 AM, Edgardo Molina wrote: Dear Mangus, I will allow myself to share a comment on your thread. Timing on windows servers is not one of their plausible strengths. This comes as no surprise, but I wanted some hard fact to assist in raising the awareness. The reason I raised it here is that I didn't have the hard facts at hand when I needed it, and I trust the time-nuts to have a diversity of facts laying around. :) It was clearly pointed out during the SIM conference last week at CENAM. In fact there was an interesting discussion about the drawbacks when using NTP Windows based servers and all kind of NTP appliances compared to full size Linux based NTP servers. Is there a presentation or even a paper to illustrate this? The example of what NIST is using nationwide for their servers set an example of good server hardware and linux to provide the nation's NTP pulse. Interesting. I have however pointed out that a downside to their strategy is that wide-spread set of servers assist to keep network effects down. In Sweden SP (NMI) and NETNOD operates redundant servers in 4 different locations, at SP and at the three main internet exchange-points. I haven't done any experiments with Windows for NTP services, still it could be interesting as to set a benchmark while comparing it to the Linux boxes. My gut feeling says that an undisciplined Windows can be anywhere, configuring a server for the SNTP brings it into decent shape for most workstation usages, shifting over to NTP is needed for many applications but even that won't compete with a Linux or BSD box. Being able to show that in a paper is better than arm-waving, even if most people here most probably would believe me without much fact. I am currently trying out the Domain Time II NTP client from Symmetricom for the thesis. I have to come back to Symmetricom's Miguel García to decide on purchasing a Domain Time II NTP client kit. How is the Mainberg NTP client different from the Symmetricom version? Have you tried both? I haven't tried either, as I rarely operate a Windows box. If not I will be more than glad to help comparing both if you can help me pointing out the source for a demo version of Mainberg's software. Meinberg's NTP is available in fullblown version from their website: http://www.meinberg.de/german/sw/ntp.htm (the link to that page is available on their front page under the dubious and hard to grasp title NTP Software Sownload) What they have done is essentially port the ntp.org NTP to Windows and gift-wrapped it a little in terms of installation. Maybe then an objective review of both clients will be in order, I will be more than glad to do it or to test them against Windows NTP services, appliances and/or Linux NTP boxes. I have at least an example of those at the office. Actually, doing this kind of measurement could be illustrative that your time may be quite dispersed. It helps to raise the question of what time is it really, how could I improve it and can there be an approval mark on the time I have. -13 Just my 2x10cents. That's a large frequency
Re: [time-nuts] Timing performance of servers
Dear Edgardo, On 10/27/2012 07:41 PM, Edgardo Molina wrote: Dear Magnus, I do not have a reference for the performance of Windows as NTP server. This has been a busy week and long working nights. It is a logical workload after being absent for nearly two weeks : ) I will browse the web and NIST to find some solid references to this issue. I am still enthusiastic about doing the side by side comparison for measuring various parameters between a Windows and a Linux box running NTP. It will require time to set the test but the contribution could be interesting, specially if no work has been done previously. I will use my spare time this weekend to search for information on the subject. A wealth of information has already been show in this thread. I'm sure there is more out there. I wonder to what degrees the different methods to illustrate errors have been used. Frequency stability for traditional white, flicker and random noises we illustrate with (modified) Allan Deviation, but it is maybe not the best method for illustrate temperature shift variants as well as the noise of packet networks. Similar for phase stability, where TDEV is being used. Typical way to illustrate time effect of systematic noises in telecom networks is the MTIE measure, which aids in showing the buffersizes and clock recovery PLL bandwidth needs, which also the traditional sinusoidal tolerance curves does. There are also new methods like MAFE for the packet world. What will happen on lost of reference and the hold over properties can also be of interest. Then systematics will surely dominate. Cheers, Magnus ___ 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.
Re: [time-nuts] Timing performance of servers
Hi If you are running a non-RTOS, one test parameter should be a significant variation in the workload on the server. Bob On Oct 27, 2012, at 2:34 PM, Magnus Danielson mag...@rubidium.dyndns.org wrote: Dear Edgardo, On 10/27/2012 07:41 PM, Edgardo Molina wrote: Dear Magnus, I do not have a reference for the performance of Windows as NTP server. This has been a busy week and long working nights. It is a logical workload after being absent for nearly two weeks : ) I will browse the web and NIST to find some solid references to this issue. I am still enthusiastic about doing the side by side comparison for measuring various parameters between a Windows and a Linux box running NTP. It will require time to set the test but the contribution could be interesting, specially if no work has been done previously. I will use my spare time this weekend to search for information on the subject. A wealth of information has already been show in this thread. I'm sure there is more out there. I wonder to what degrees the different methods to illustrate errors have been used. Frequency stability for traditional white, flicker and random noises we illustrate with (modified) Allan Deviation, but it is maybe not the best method for illustrate temperature shift variants as well as the noise of packet networks. Similar for phase stability, where TDEV is being used. Typical way to illustrate time effect of systematic noises in telecom networks is the MTIE measure, which aids in showing the buffersizes and clock recovery PLL bandwidth needs, which also the traditional sinusoidal tolerance curves does. There are also new methods like MAFE for the packet world. What will happen on lost of reference and the hold over properties can also be of interest. Then systematics will surely dominate. Cheers, Magnus ___ 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. ___ 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.
Re: [time-nuts] Timing performance of servers
On 10/27/2012 9:47 AM, Magnus Danielson wrote: Dear Edgardo, On 10/25/2012 02:04 AM, Edgardo Molina wrote: Dear Mangus, I will allow myself to share a comment on your thread. Timing on windows servers is not one of their plausible strengths. This comes as no surprise, but I wanted some hard fact to assist in raising the awareness. The reason I raised it here is that I didn't have the hard facts at hand when I needed it, and I trust the time-nuts to have a diversity of facts laying around. :) It was clearly pointed out during the SIM conference last week at CENAM. In fact there was an interesting discussion about the drawbacks when using NTP Windows based servers and all kind of NTP appliances compared to full size Linux based NTP servers. Is there a presentation or even a paper to illustrate this? The example of what NIST is using nationwide for their servers set an example of good server hardware and linux to provide the nation's NTP pulse. Interesting. I have however pointed out that a downside to their strategy is that wide-spread set of servers assist to keep network effects down. In Sweden SP (NMI) and NETNOD operates redundant servers in 4 different locations, at SP and at the three main internet exchange-points. I haven't done any experiments with Windows for NTP services, still it could be interesting as to set a benchmark while comparing it to the Linux boxes. My gut feeling says that an undisciplined Windows can be anywhere, configuring a server for the SNTP brings it into decent shape for most workstation usages, shifting over to NTP is needed for many applications but even that won't compete with a Linux or BSD box. Being able to show that in a paper is better than arm-waving, even if most people here most probably would believe me without much fact. I am currently trying out the Domain Time II NTP client from Symmetricom for the thesis. I have to come back to Symmetricom's Miguel García to decide on purchasing a Domain Time II NTP client kit. How is the Mainberg NTP client different from the Symmetricom version? Have you tried both? I haven't tried either, as I rarely operate a Windows box. If not I will be more than glad to help comparing both if you can help me pointing out the source for a demo version of Mainberg's software. Meinberg's NTP is available in fullblown version from their website: http://www.meinberg.de/german/sw/ntp.htm (the link to that page is available on their front page under the dubious and hard to grasp title NTP Software Sownload) What they have done is essentially port the ntp.org NTP to Windows and gift-wrapped it a little in terms of installation. Maybe then an objective review of both clients will be in order, I will be more than glad to do it or to test them against Windows NTP services, appliances and/or Linux NTP boxes. I have at least an example of those at the office. Actually, doing this kind of measurement could be illustrative that your time may be quite dispersed. It helps to raise the question of what time is it really, how could I improve it and can there be an approval mark on the time I have. -13 Just my 2x10cents. That's a large frequency deviation among time-nuts. :) Regards to you and the group, Many thanks! Cheers, Magnus 1) Meinberg technically hasn't done any porting, it's an installer for ntp binaries themselves, which are simply compiled for a target other than bsd / solaris / linux. There aren't any under the hood changes required. I could just as easily compile a windows binary using: 1a) The copy of gcc shipped by microsoft in the services for unix applications / SUA SDK. 1b) Or the one gentoo provides when using gentoo prefix (gentoo's own package manager can be run natively on windows via microsoft's compliant layer AKA interix) 1c) Or even bootstrap, compile my own windows-native posix-type gcc compiler (newer version or otherwise), and build ntp from source with my own compiler. 1d) alternatively, do what meinberg did, using a mingw gcc compile target (mingw gcc compiler adjusts dependencies slightly by basically just building against microsoft's C libraries and APIs which are already installed because so mucch of the windows OS already needs them to be in place) 1e) cygwin has been working well for many things for more than 10 years, providing their own 1f) potentially, the NTP source itself compiles unmodified on some version of microsoft's visual C compiler, or some other windows compiler 1x) In fact, other than compiling ntp from source, meinberg really only made things more convenient by providing an installer and a separate monitor tool. The underlying optimized code for synchronization of time via NTP protocol comes from the open-source code you can get from ntp.org. You can just as easily use meinberg's installer, and then drop-in a different binary provided by someone other than meinberg (or
[time-nuts] Zeeman frequency oddness
Since I recently got an HP Cs degausser (thanks, Stijn!), I though I'd go through the whole setup routine for my 5061B/004 and see how close the C-field-via-Zeeman setting would bring me to GPS-derived frequency. It turned out to be an interesting and puzzling exercise. This 5061 seems to be in perfect working order -- quick lock, good meter readings, and measurements indicate frequency within parts in e12. I don't have any reason to believe that it's not tuned or working properly, except for the Zeeman-setting results. The problem is that when I tune the audio source around 53.53 kHz, per both the manual and the sticker on the door, I don't see any change in Beam I at all. Nor do I see anything at the alternate frequency of 42.82 kHz. Instead, I see the expected three peaks -- primary with a smaller secondary on either side -- at about 48.21 kHz, which doesn't show up anywhere in the literature I've found. Below, I've cut and pasted a years-old message from TVB and Corby that explains the Zeeman frequencies. I've measured the synthesizer output and it's nominally 12.6317725 MHz, which per that message should correspond to a 53.53 Zeeman. Where 48.21 kHz comes from, I have no idea. I'm using a Rigol arbitrary function generator locked to an external reference as the audio source, in sine wave mode. I know that's not the cleanest device in the world, but the wave doesn't look too bad on my scope and a counter indicates the frequency is what the dial says. As I adjust the audio amplitude, the beam current responds, and I see a peak at around 500mV, which the 5061B manual says is correct. Any ideas why I might be seeing this very off-the-wall result? Could distortion in the audio source cause something like this? I'm more inclined to blame technique or gremlins than the 5061B -- again, external measurements indicate that the thing is tuned correctly and operating properly, just having this goofy Zeeman response. Thanks! John [time-nuts] Zeeman frequency and cesium tube interchange Tom Van Baak Fri Apr 22 13:32:35 EDT 2005 Hi Brian, The SI second is defined for mean sea level and no external fields. If there were no magnetic field, in theory, a cesium tube would show a resonance when its synthesizer generated exactly 9192.631770 MHz; the definition of the second. But in practice, a weak uniform magnetic field is necessary for the beam apparatus to operate; to isolate the center peak from the other peaks. This DC field also has the side-effect of slightly shifting the frequency of the center line. Fortunately the frequency shift is a calculatable amount (a function of magnetic field strength) so the trick is that the synthesizer must be designed to generate a slightly higher frequency to exactly compensate for the shift that will be induced by the field. Thus the synthesizer for a 5061A does not actually generate 9192 631 770 Hz as one might expect, but because of the nominal 61 milligauss C-field, the synthesizer must generate 9192 631 771.6 Hz in order to lock onto the Cs peak precisely. The Zeeman frequency for 61 mG is 42.82 kHz (info from an old 5061A manual). Other 5061A/B use a 76 mG field, corresponding to a 53.53 kHz Zeeman frequency, and require the synthesizer to generate 9192 631 772.5 Hz (info from a new 5061B manual). The short HP 5062C runs at 9192 631 774.3 Hz with a Zeeman of 70.40 kHz. Below is a great reply from Corby Dawson about the problems this can cause when mixing FTS 4050, 4060, HP 5060A, 5061A, 5061B parts. /tvb - Original Message - Tom, The zeeman frequency required depends on two things, the magnitude of the C-field current and the synthesizer frequency. HP 5061A and B units that have a synthesizer freq. of 12.6317725 Mhz are configured for a lower value of C-field current by selecting a higher value series resistor on the A15 board. In this case any tube installed (5061A/B 5060 4050 4060) will operate at the 53.53Khz zeeman frequency. HP 5061A and B units and 5060A units that have a synthesizer frequency of 12.6317716 Mhz are configured for a higher C-field current due to a lower value series resistor in the C-field circuit. In this case any installed tube will operate with a 42.82Khz zeeman frequency. Problems arise when synthesizer and or A15 modules are swapped around indiscriminantly leaving a unit with modules that do not match! Since the HP and FTS tubes C-field windings are designed to provide the same field for a given input they are interchangeable. You can operate any of these tubes at a 42.82 or 53.53Khz zeeman. I usually just stick with how the mainframe came configured. I don't remember what I ended up with as far as the zeeman freq. was concerned when I installed a Frequency Electronics tube into a 5061A, but do remember the line width was quite broad in keeping with the reduced accuracy spec. of the FE tubes. (Same spec. as the 5062C tube) I have installed FTS tubes
Re: [time-nuts] Timing performance of servers
On 10/27/2012 09:06 PM, Sarah White wrote: Sorry to post such a long thing on the subject. Most of the work I do with accurate time involves network synchronization. Really, the NTP / SNTP protocol isn't nearly as high performance as Precision time protocol --- PTP is the latest technology to come out of the network time foundation, and NTP protocol has simply been around longer and as such, it is better known: http://networktimefoundation.org/projects/ The reason for this thread was not to necessarily get the best possible time, but to get away from severely affected time that was causing the dataloss issues. The one flaw that NTP has that motivated PTP was lack of hardware time-stamps. There are those that have implemented hardware time-stamping to NTP. It's unfortunate to compare NTP and PTP when it should be comparing software time-stamping and hardware time-stamping. Cheers, Magnus ___ 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.
Re: [time-nuts] Zeeman frequency oddness
John Going from what you have here and the information below it would seem to me that there is some form of residual magnetism effecting the tube. I don't believe the waveform of the signal has a huge effect as long as its not a square wave. I think it can have distortion. Its been a while but since you have an accurate reference, I believe you can adjust the system to align to that and see what pip on the zeeman you end up on. Perhaps you are aligning to the wrong pip. Go to either of the lower ones and see if it works better or lines up. If it does then the math holds and refines the question. There was an old HP doc that evidently it was very easy to align to the wrong pip. It was quite a problem actually. Regards Paul WB8TSL On Sat, Oct 27, 2012 at 3:16 PM, John Ackermann N8UR j...@febo.com wrote: Since I recently got an HP Cs degausser (thanks, Stijn!), I though I'd go through the whole setup routine for my 5061B/004 and see how close the C-field-via-Zeeman setting would bring me to GPS-derived frequency. It turned out to be an interesting and puzzling exercise. This 5061 seems to be in perfect working order -- quick lock, good meter readings, and measurements indicate frequency within parts in e12. I don't have any reason to believe that it's not tuned or working properly, except for the Zeeman-setting results. The problem is that when I tune the audio source around 53.53 kHz, per both the manual and the sticker on the door, I don't see any change in Beam I at all. Nor do I see anything at the alternate frequency of 42.82 kHz. Instead, I see the expected three peaks -- primary with a smaller secondary on either side -- at about 48.21 kHz, which doesn't show up anywhere in the literature I've found. Below, I've cut and pasted a years-old message from TVB and Corby that explains the Zeeman frequencies. I've measured the synthesizer output and it's nominally 12.6317725 MHz, which per that message should correspond to a 53.53 Zeeman. Where 48.21 kHz comes from, I have no idea. I'm using a Rigol arbitrary function generator locked to an external reference as the audio source, in sine wave mode. I know that's not the cleanest device in the world, but the wave doesn't look too bad on my scope and a counter indicates the frequency is what the dial says. As I adjust the audio amplitude, the beam current responds, and I see a peak at around 500mV, which the 5061B manual says is correct. Any ideas why I might be seeing this very off-the-wall result? Could distortion in the audio source cause something like this? I'm more inclined to blame technique or gremlins than the 5061B -- again, external measurements indicate that the thing is tuned correctly and operating properly, just having this goofy Zeeman response. Thanks! John [time-nuts] Zeeman frequency and cesium tube interchange Tom Van Baak Fri Apr 22 13:32:35 EDT 2005 Hi Brian, The SI second is defined for mean sea level and no external fields. If there were no magnetic field, in theory, a cesium tube would show a resonance when its synthesizer generated exactly 9192.631770 MHz; the definition of the second. But in practice, a weak uniform magnetic field is necessary for the beam apparatus to operate; to isolate the center peak from the other peaks. This DC field also has the side-effect of slightly shifting the frequency of the center line. Fortunately the frequency shift is a calculatable amount (a function of magnetic field strength) so the trick is that the synthesizer must be designed to generate a slightly higher frequency to exactly compensate for the shift that will be induced by the field. Thus the synthesizer for a 5061A does not actually generate 9192 631 770 Hz as one might expect, but because of the nominal 61 milligauss C-field, the synthesizer must generate 9192 631 771.6 Hz in order to lock onto the Cs peak precisely. The Zeeman frequency for 61 mG is 42.82 kHz (info from an old 5061A manual). Other 5061A/B use a 76 mG field, corresponding to a 53.53 kHz Zeeman frequency, and require the synthesizer to generate 9192 631 772.5 Hz (info from a new 5061B manual). The short HP 5062C runs at 9192 631 774.3 Hz with a Zeeman of 70.40 kHz. Below is a great reply from Corby Dawson about the problems this can cause when mixing FTS 4050, 4060, HP 5060A, 5061A, 5061B parts. /tvb - Original Message - Tom, The zeeman frequency required depends on two things, the magnitude of the C-field current and the synthesizer frequency. HP 5061A and B units that have a synthesizer freq. of 12.6317725 Mhz are configured for a lower value of C-field current by selecting a higher value series resistor on the A15 board. In this case any tube installed (5061A/B 5060 4050 4060) will operate at the 53.53Khz zeeman frequency. HP 5061A and B units and 5060A units that have a synthesizer frequency of 12.6317716 Mhz are configured for a higher
Re: [time-nuts] Timing performance of servers
Hi Not to mention the issues with hardware time stamping over large scale / multi vendor networks. As soon as you cross your property line, things start to get messy…. Bob On Oct 27, 2012, at 4:37 PM, Magnus Danielson mag...@rubidium.dyndns.org wrote: On 10/27/2012 09:06 PM, Sarah White wrote: Sorry to post such a long thing on the subject. Most of the work I do with accurate time involves network synchronization. Really, the NTP / SNTP protocol isn't nearly as high performance as Precision time protocol --- PTP is the latest technology to come out of the network time foundation, and NTP protocol has simply been around longer and as such, it is better known: http://networktimefoundation.org/projects/ The reason for this thread was not to necessarily get the best possible time, but to get away from severely affected time that was causing the dataloss issues. The one flaw that NTP has that motivated PTP was lack of hardware time-stamps. There are those that have implemented hardware time-stamping to NTP. It's unfortunate to compare NTP and PTP when it should be comparing software time-stamping and hardware time-stamping. Cheers, Magnus ___ 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. ___ 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.
Re: [time-nuts] Zeeman frequency oddness
Hi John, Don't know if I address your real issues, but I want to add some more pieces to the puzzle. On 10/27/2012 09:16 PM, John Ackermann N8UR wrote: Since I recently got an HP Cs degausser (thanks, Stijn!), I though I'd go through the whole setup routine for my 5061B/004 and see how close the C-field-via-Zeeman setting would bring me to GPS-derived frequency. It turned out to be an interesting and puzzling exercise. This 5061 seems to be in perfect working order -- quick lock, good meter readings, and measurements indicate frequency within parts in e12. I don't have any reason to believe that it's not tuned or working properly, except for the Zeeman-setting results. The problem is that when I tune the audio source around 53.53 kHz, per both the manual and the sticker on the door, I don't see any change in Beam I at all. Nor do I see anything at the alternate frequency of 42.82 kHz. Instead, I see the expected three peaks -- primary with a smaller secondary on either side -- at about 48.21 kHz, which doesn't show up anywhere in the literature I've found. There are in total 7 peaks, you want the center peak of those. Tom has made measurements: http://leapsecond.com/images/cfield.gif I have done the same to one of my tubes, but I don't recall where I have that flimsy picture, so the above is a good start. Below, I've cut and pasted a years-old message from TVB and Corby that explains the Zeeman frequencies. I've measured the synthesizer output and it's nominally 12.6317725 MHz, which per that message should correspond to a 53.53 Zeeman. Where 48.21 kHz comes from, I have no idea. The separation of the peaks depends on the C-field value you have. For low C-field strength, the side-peaks separate my the square of the C-field (B), and the cluster shifts gently linear with the C-field. You want to spread the side-peaks out, such that they do not confuse your measures. Also, looking at the above you have the 7 Rabi distributions, and on top of those the Ramsay fringes, at which you want to lock onto the center one. It may be interesting to learn that certain systematics skews the shape of these, and thus causes a systematic miss-tuning, so great care is taken to reduce that effect when manufacturing the tube. Look at the above C-field plot again and you see how the side features move with different C-field settings. Modern digital caesium clocks measure the side-features in order to Servo the C-field into a stable value, and hence also stabilize C-field drift out of the equation first degree. I'm using a Rigol arbitrary function generator locked to an external reference as the audio source, in sine wave mode. I know that's not the cleanest device in the world, but the wave doesn't look too bad on my scope and a counter indicates the frequency is what the dial says. As I adjust the audio amplitude, the beam current responds, and I see a peak at around 500mV, which the 5061B manual says is correct. Any ideas why I might be seeing this very off-the-wall result? Could distortion in the audio source cause something like this? I'm more inclined to blame technique or gremlins than the 5061B -- again, external measurements indicate that the thing is tuned correctly and operating properly, just having this goofy Zeeman response. You want a clean source, as spurs or distortion would cause you to look at multiple points in the spectrum at the same time and you would get the combined result of those features. Still, the distortion values doesn't have to be stellar to get decent readings. Cheers, Magnus ___ 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.
Re: [time-nuts] Zeeman frequency oddness
Two things come to mind: 1) is this the high performance tube? Perhaps it has a different Zeeman frequency than the standard tube? 2) a non HP replacement tube? FTS Cs beam tubes are way different Zeeman frequencies than HP. -Chuck Harris John Ackermann N8UR wrote: Since I recently got an HP Cs degausser (thanks, Stijn!), I though I'd go through the whole setup routine for my 5061B/004 and see how close the C-field-via-Zeeman setting would bring me to GPS-derived frequency. It turned out to be an interesting and puzzling exercise. This 5061 seems to be in perfect working order -- quick lock, good meter readings, and measurements indicate frequency within parts in e12. I don't have any reason to believe that it's not tuned or working properly, except for the Zeeman-setting results. The problem is that when I tune the audio source around 53.53 kHz, per both the manual and the sticker on the door, I don't see any change in Beam I at all. Nor do I see anything at the alternate frequency of 42.82 kHz. Instead, I see the expected three peaks -- primary with a smaller secondary on either side -- at about 48.21 kHz, which doesn't show up anywhere in the literature I've found. Below, I've cut and pasted a years-old message from TVB and Corby that explains the Zeeman frequencies. I've measured the synthesizer output and it's nominally 12.6317725 MHz, which per that message should correspond to a 53.53 Zeeman. Where 48.21 kHz comes from, I have no idea. I'm using a Rigol arbitrary function generator locked to an external reference as the audio source, in sine wave mode. I know that's not the cleanest device in the world, but the wave doesn't look too bad on my scope and a counter indicates the frequency is what the dial says. As I adjust the audio amplitude, the beam current responds, and I see a peak at around 500mV, which the 5061B manual says is correct. Any ideas why I might be seeing this very off-the-wall result? Could distortion in the audio source cause something like this? I'm more inclined to blame technique or gremlins than the 5061B -- again, external measurements indicate that the thing is tuned correctly and operating properly, just having this goofy Zeeman response. Thanks! John [time-nuts] Zeeman frequency and cesium tube interchange Tom Van Baak Fri Apr 22 13:32:35 EDT 2005 Hi Brian, The SI second is defined for mean sea level and no external fields. If there were no magnetic field, in theory, a cesium tube would show a resonance when its synthesizer generated exactly 9192.631770 MHz; the definition of the second. But in practice, a weak uniform magnetic field is necessary for the beam apparatus to operate; to isolate the center peak from the other peaks. This DC field also has the side-effect of slightly shifting the frequency of the center line. Fortunately the frequency shift is a calculatable amount (a function of magnetic field strength) so the trick is that the synthesizer must be designed to generate a slightly higher frequency to exactly compensate for the shift that will be induced by the field. Thus the synthesizer for a 5061A does not actually generate 9192 631 770 Hz as one might expect, but because of the nominal 61 milligauss C-field, the synthesizer must generate 9192 631 771.6 Hz in order to lock onto the Cs peak precisely. The Zeeman frequency for 61 mG is 42.82 kHz (info from an old 5061A manual). Other 5061A/B use a 76 mG field, corresponding to a 53.53 kHz Zeeman frequency, and require the synthesizer to generate 9192 631 772.5 Hz (info from a new 5061B manual). The short HP 5062C runs at 9192 631 774.3 Hz with a Zeeman of 70.40 kHz. Below is a great reply from Corby Dawson about the problems this can cause when mixing FTS 4050, 4060, HP 5060A, 5061A, 5061B parts. /tvb - Original Message - Tom, The zeeman frequency required depends on two things, the magnitude of the C-field current and the synthesizer frequency. HP 5061A and B units that have a synthesizer freq. of 12.6317725 Mhz are configured for a lower value of C-field current by selecting a higher value series resistor on the A15 board. In this case any tube installed (5061A/B 5060 4050 4060) will operate at the 53.53Khz zeeman frequency. HP 5061A and B units and 5060A units that have a synthesizer frequency of 12.6317716 Mhz are configured for a higher C-field current due to a lower value series resistor in the C-field circuit. In this case any installed tube will operate with a 42.82Khz zeeman frequency. Problems arise when synthesizer and or A15 modules are swapped around indiscriminantly leaving a unit with modules that do not match! Since the HP and FTS tubes C-field windings are designed to provide the same field for a given input they are interchangeable. You can operate any of these tubes at a 42.82 or 53.53Khz zeeman. I usually just stick with how the mainframe came configured. I don't remember what
Re: [time-nuts] Zeeman frequency oddness
John, Did you do the Zeeman frequency adjustment before doing the 'degauss'? In other words, did you 'magnetize' rather than 'de-magnetize'? Have you checked the A15 board to make sure it has the correct resistor and current? I have a 5061B Service Manual if you need some sections or schematics. Good luck. Joe -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of John Ackermann N8UR Sent: Saturday, October 27, 2012 2:16 PM To: Discussion of precise time and frequency measurement Subject: [time-nuts] Zeeman frequency oddness Since I recently got an HP Cs degausser (thanks, Stijn!), I though I'd go through the whole setup routine for my 5061B/004 and see how close the C-field-via-Zeeman setting would bring me to GPS-derived frequency. It turned out to be an interesting and puzzling exercise. This 5061 seems to be in perfect working order -- quick lock, good meter readings, and measurements indicate frequency within parts in e12. I don't have any reason to believe that it's not tuned or working properly, except for the Zeeman-setting results. The problem is that when I tune the audio source around 53.53 kHz, per both the manual and the sticker on the door, I don't see any change in Beam I at all. Nor do I see anything at the alternate frequency of 42.82 kHz. Instead, I see the expected three peaks -- primary with a smaller secondary on either side -- at about 48.21 kHz, which doesn't show up anywhere in the literature I've found. Below, I've cut and pasted a years-old message from TVB and Corby that explains the Zeeman frequencies. I've measured the synthesizer output and it's nominally 12.6317725 MHz, which per that message should correspond to a 53.53 Zeeman. Where 48.21 kHz comes from, I have no idea. I'm using a Rigol arbitrary function generator locked to an external reference as the audio source, in sine wave mode. I know that's not the cleanest device in the world, but the wave doesn't look too bad on my scope and a counter indicates the frequency is what the dial says. As I adjust the audio amplitude, the beam current responds, and I see a peak at around 500mV, which the 5061B manual says is correct. Any ideas why I might be seeing this very off-the-wall result? Could distortion in the audio source cause something like this? I'm more inclined to blame technique or gremlins than the 5061B -- again, external measurements indicate that the thing is tuned correctly and operating properly, just having this goofy Zeeman response. Thanks! John [time-nuts] Zeeman frequency and cesium tube interchange Tom Van Baak Fri Apr 22 13:32:35 EDT 2005 Hi Brian, The SI second is defined for mean sea level and no external fields. If there were no magnetic field, in theory, a cesium tube would show a resonance when its synthesizer generated exactly 9192.631770 MHz; the definition of the second. But in practice, a weak uniform magnetic field is necessary for the beam apparatus to operate; to isolate the center peak from the other peaks. This DC field also has the side-effect of slightly shifting the frequency of the center line. Fortunately the frequency shift is a calculatable amount (a function of magnetic field strength) so the trick is that the synthesizer must be designed to generate a slightly higher frequency to exactly compensate for the shift that will be induced by the field. Thus the synthesizer for a 5061A does not actually generate 9192 631 770 Hz as one might expect, but because of the nominal 61 milligauss C-field, the synthesizer must generate 9192 631 771.6 Hz in order to lock onto the Cs peak precisely. The Zeeman frequency for 61 mG is 42.82 kHz (info from an old 5061A manual). Other 5061A/B use a 76 mG field, corresponding to a 53.53 kHz Zeeman frequency, and require the synthesizer to generate 9192 631 772.5 Hz (info from a new 5061B manual). The short HP 5062C runs at 9192 631 774.3 Hz with a Zeeman of 70.40 kHz. Below is a great reply from Corby Dawson about the problems this can cause when mixing FTS 4050, 4060, HP 5060A, 5061A, 5061B parts. /tvb - Original Message - Tom, The zeeman frequency required depends on two things, the magnitude of the C-field current and the synthesizer frequency. HP 5061A and B units that have a synthesizer freq. of 12.6317725 Mhz are configured for a lower value of C-field current by selecting a higher value series resistor on the A15 board. In this case any tube installed (5061A/B 5060 4050 4060) will operate at the 53.53Khz zeeman frequency. HP 5061A and B units and 5060A units that have a synthesizer frequency of 12.6317716 Mhz are configured for a higher C-field current due to a lower value series resistor in the C-field circuit. In this case any installed tube will operate with a 42.82Khz zeeman frequency. Problems arise when synthesizer and or A15 modules are swapped around indiscriminantly leaving a unit
Re: [time-nuts] Zeeman frequency oddness
On 10/28/2012 01:13 AM, Chuck Harris wrote: Two things come to mind: 1) is this the high performance tube? Perhaps it has a different Zeeman frequency than the standard tube? 2) a non HP replacement tube? FTS Cs beam tubes are way different Zeeman frequencies than HP. A high performance tube should give you better signal to noise. A non HP tube might give you a somewhat different C-field setting for same center lock-in. The physics of Cs-133 is still the same, and the RF-chain is still the same. If not, someone has to teach me something new, or at least inform me why the high performance tubes are so much different. Cheers, Magnus ___ 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.
Re: [time-nuts] Zeeman frequency oddness
Is there perhaps a hemisphere jumper for the sign of nulling fields? -John == On 10/28/2012 01:13 AM, Chuck Harris wrote: Two things come to mind: 1) is this the high performance tube? Perhaps it has a different Zeeman frequency than the standard tube? 2) a non HP replacement tube? FTS Cs beam tubes are way different Zeeman frequencies than HP. A high performance tube should give you better signal to noise. A non HP tube might give you a somewhat different C-field setting for same center lock-in. The physics of Cs-133 is still the same, and the RF-chain is still the same. If not, someone has to teach me something new, or at least inform me why the high performance tubes are so much different. Cheers, Magnus ___ 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. ___ 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.
Re: [time-nuts] 5061B ops manual without missing pages?
John, yes, I have a scan. It's the one from the Agilent site. There are just some pages mixed up. Nothing appears to be missing. The pages are in this sequence: 3-5, 3-6, 3-9, 3-10, 3-7, 3-8, 3-11, 3-12 etc. Adrian John Ackermann N8UR schrieb: Does anyone have a copy of the 5061B ops manual that does not have pages 3-7 and 3-8 missing? The copy at the Agilent site doesn't have those, and they are the basic start-up instructions. I am guessing that the steps are not much different than those in the 5061A manual (which I have), but it would be nice to have a complete manual. Thanks! John ___ 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. ___ 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.
Re: [time-nuts] Zeeman frequency oddness
Magnus Danielson wrote: On 10/28/2012 01:13 AM, Chuck Harris wrote: Two things come to mind: 1) is this the high performance tube? Perhaps it has a different Zeeman frequency than the standard tube? 2) a non HP replacement tube? FTS Cs beam tubes are way different Zeeman frequencies than HP. A high performance tube should give you better signal to noise. A non HP tube might give you a somewhat different C-field setting for same center lock-in. The FTS tubes in my 4050 have a Zeeman frequency of around 43KHz, which if my estimate is right is about 10KHz different from the HP Zeeman frequency of around 53KHz. And as I recall, the little HP submarine C-Beam has yet another Zeeman frequency, but I can't dig up its manual at the moment. AFAIK, the Zeeman frequency is very much dependent on the architecture of the particular physics package. -Chuck Harris The physics of Cs-133 is still the same, and the RF-chain is still the same. If not, someone has to teach me something new, or at least inform me why the high performance tubes are so much different. Cheers, Magnus ___ 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. ___ 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.
