Re: [time-nuts] GPSDO recovery from holdover
As usual I cannot refrain to make my mistake: seconds for minutes... yes, it is 13 minutes not 13 hours. On Sun, Dec 2, 2012 at 3:54 AM, Bob Camp li...@rtty.us wrote: Hi On Dec 1, 2012, at 8:13 PM, saidj...@aol.com wrote: Hi Magnus, yup, at the levels we are interested in, a prefix or two sometimes doesn't make any real difference :) Most of the time typical GPSDO's won't ever drift out of a say +/-100ns window. If they do, then the antenna must have been shot off by someone, or something else must have gone horribly wrong. Just for fun I attached two phase correction examples from a FireFly-IIA, and a CSAC GPSDO. Both were essentially brand new and not yet calibrated when turned on, and thus you can see a large EFC variation over the first 15 minutes or so as the frequency stabilized. Then you can see the phase stabilize slowly, this takes about 1.2 hours for the FF-IIA with a much more aggressive loop setting, and about 3 hours for the CSAC GPSDO. The most perplexing fact for me is that while you can clearly see the exact point at which the phase has stabilized, you cannot really see any corresponding change in EFC behavior at that time. You can see a large EFC voltage change initially as the frequency stabilizes after power-on, but then it goes into the noise floor. This shows that the EFC corrections for phase error are essentially smaller than the proportional noise floor of the loop! Driving an integrator is never an easy thing. Watching EFC and looking at phase indeed watching the loop drive an integrator. The maximum phase error in these plots was about 100ns for the CSAC, and 230ns for the FF-IIA. Here we can see that the FF-IIA has a much more aggressive loop approach (~5x more gain on the phase correction). Since the CSAC is an atomic clock we can increase the time constant quite a bit and make the loop much less aggressive. bye, Said Bob In a message dated 12/1/2012 14:39:58 Pacific Standard Time, mag...@rubidium.dyndns.org writes: One can also wonder if the limit is relevant, as you are about to resolve a rather catastrophic situation where you already cause interference, so moving out of it quickly should be first priority and only when back to reasonable time-error would it be relevant to obey frequency error limits. The transmitters and the recievers would be able to follow, as they have large enough bandwidth for it. But if you set the loop parameters more aggressively to 1ns/s as in your example, it would take less than 20 minutes to correct 1us.. Not 12hrs. Unless you meant to say ms? What's a off by one prefix among friends? But still, one has to be careful. Cheers, Magnus phase_corrections.zip___ 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.
Re: [time-nuts] Using a frequency synthesizer replacement for motherboard oscillator
Hi Maybe I'm just shopping in the right places. I have yet to build up a desktop machine that does *not* have at least one COM port on the motherboard. That's been true all the way from simple little Atom based ITX boards right through monster boards with all sorts of crazy stuff on them. Yes, it's not out the back, but that's very easy to take care of if you need the port. Laptops are a bit different. They seem to die of some sort of display issue long before a desktop. I don't use them in test setups. Bob On Dec 1, 2012, at 11:37 PM, David davidwh...@gmail.com wrote: On Sat, 01 Dec 2012 19:10:54 -0800, Hal Murray hmur...@megapathdsl.net wrote: davidwh...@gmail.com said: One of my favorite tricks back when the ISA bus was still available was to use a custom expansion board I built and an oscilloscope to measure the interrupt latency. You can do the same trick without special hardware. Use the printer port. Of course, that assumes your PC/Laptop still has a printer port. I almost always end up installing a PCI/PCIe serial and parallel expansion card into my systems even now. I have a laptop with a printer port on the thing Dell calls a MediaBase. It's an extender/fattener that includes a CD drive with connectors for printer port and serial port. It plugs into a big connector on the bottom of the laptop. Many laptops plug into docking stations for use at a desk. Sometimes/often they have printer ports and/or serial ports. You could probably do it with just a serial port by flapping one of the output modem control signals. I could not always depend on having access to built in serial or parallel ports. These days of course both are pretty much deprecated in favor of USB which is useless for this type of work. If you don't have a printer port or serial port, how are you getting the interrupt into your box? Since this was back in the ISA days, I had access to the whole ISA bus including the interrupts. I never built a version for PCI but I did consider it. The card I built had a pair of 8254 timers, hexadecimal display, keypad, a bunch of auxiliary I/O, and all of the decoding to use it. I usually end up building something similar for microcontroller projects that operates via SPI although serial to a PC running a terminal program is often better. Many years ago, I helped a friend with this sort of thing. We were working for DEC back in the days before Intel had captured everything and workstations still needed lots of chips and chips had big pins so you could get a scope probe on them. My part was to connect scope probes to the interrupt line from the ethernet chip and the chip select for the MAC address ROM. He patched the driver's interrupt routine to read the ROM. I have also done that on occasion and sometimes still do. Usually I solder a little grab point for the probe into place. Sometimes I will just add a resistor or transistor buffer depending on impedance issues and an RG-316 pigtail. The funny part is that back then, I was using one of the early Tektronix series TDS oscilloscopes. Now I do the same thing with an older Tektronix 2230, 2232, or 2440 series oscilloscope and I have a word recognizer for my 2440 which works surprisingly well. At some point, I need to pick up a DSO that supports variable and infinite persistence. ___ 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] EES RC 1454 100DB MSF/GPS clock
In a message dated 30/11/2012 18:25:52 GMT Standard Time, robert8...@yahoo.co.uk writes: Hi Nigel, Connect did have some recently by this came from another? seller who is from the same town. WoodsGroup are also selling them (item 390489973647 ) but at excessive prices and without the antenna. --- Hi Robert I obviously missed more than I realised, the only one I found at first was the one from Woods Group and must admit I was surprised at the price, but think I've just found yours which looks to be a much more reasonable investment:-) --- The GPS mod seems to replace the PLL board and loops the LF signal through. The GPS antenna unit also has an LF antenna input. - The EES100s are sitting in their wooden transit cases right now and, as is not unusual, I can see them but can't immediately get to them:-) It's been a couple of years or so since I last did anything with these so will have to try and dig one out during the week and refresh my memory. I have got one of the antenna modules in front of me, a diecast box with a Motorola ANT62301A2 GPS antenna mounted on top that looks much the same as yours and very much like something intended to be portable and sited alongside the EES100 at the operating position rather than up a pole somewhere. The Oncore on this is a UTplus from late 2000 but the chip date codes on the EES manufactured interface/CPU board range from 1993 to 96 so the Oncore may have been replaced at some time. Either way this module strikes me as being a bit more recent than I would expect the EES100s to be so, in this case anyway, I'm wondering if this was an upgrade to older MSF units already deployed, although they might have needed to be returned for modification too. - I traced the power (+5V +12V) connections and hooked it up to a bench supply without the antenna unit. The supply only has 500mA capability on the 12V and went into current limit. Tried a bigger supply and got smoke :-( A pot core inductor on the PLL board was cooking. A bit of tracing and it's in series with thr 12V supply and antenna connector. The was a short on the MCx to BNC lead. It disappaered when I moved it so I'll leave it be for now. I get a red power LED, green loop lock and 1PPS LEDs but no display. I've got the GPS ant on a windowsill so I'll let it seet and see if anything comes up. - Sorry to hear about the smoke and hope there's no lasting damage. Despite being in a supposedly sealed enclosure there's deposits on the CPU PCB and Oncore in this module that look to be damp related corrosion, not too bad but looking like electrolytic action between some of the IC pins and/or the soldering, so I'll need to go over it very carefully before applying power. More later. Regards Nigel GM8PZR -- Robert G8RPI. From: gandal...@aol.com gandal...@aol.com To: time-nuts@febo.com Sent: Thursday, 29 November 2012, 19:45 Subject: Re: [time-nuts] EES RC 1454 100DB MSF/GPS clock Hi Robert For some reason I missed these until you mentioned them but have just taken a look and am reminded very much of the similarly modified and boxed EES 100s that Connect Distribution were selling around 5 years ago. Whilst this looks to be a much later unit both EES and Radiocode clocks do seem to have survived for an awful long time without too many significant revisions to their hardware, internal hardware anyway:-) I've seen a similar connector on one version of the RC060s but even that mainly used conventional D connectors. From what I remember of the antenna modules on the EES 100s I got the impression that the interface processor board extracted the timing information from the GPS signal and converted it into an MSF compatible signal to feed the EES 100. I'm sure they didn't frequency convert from L band to 60KHz but just took the GPS data and started from fresh to generate their own MSF compatible signal using that data. I never tried to use one of the modified units straight from MSF but will dig one out and try it, I don't think there was very much of a modification to the MSF receiver other than whatever was required to accept another 60KHz signal. I suspect all the hard work was done in the antenna module and the MSF unit was just used as decoder and display for the converted signal. I may have missed something, nothing unusual there then:-), but it always struck me as a rather odd way of accessing and displaying GPS timing data, unless initially there was some pressure to find a quick fix utilising existing approved equipment. Regards Nigel GM8PZR In a message dated 29/11/2012 18:58:47 GMT Standard Time, robert8...@yahoo.co.uk writes: Hi all, I recently gave in and bought one of the EES (european electronic systems) RC1454 Radio Clock units
[time-nuts] [Fwd: [hp_agilent_equipment] Blue Feather File Archive Updated]
FYI, this is an archive of ROM EPROM dumps for various test gear. -John == Original Message Subject: [hp_agilent_equipment] Blue Feather File Archive Updated From:Bruce Lane kyr...@bluefeathertech.com Date:Sat, December 1, 2012 11:16 pm To: teksco...@yahoogroups.com Cc: hp_agilent_equipm...@yahoogroups.com -- Fellow techies, I've taken a cue from Didier, in that I've done some work to make the Blue Feather FTP site easier to work with. I've added a web-based file sharing program, and made it accessible from our main page. When you hit up www.bluefeathertech.com, look in the lower left part of the table for the link 'Blue Feather File Archive.' One simple click takes you to the root directory of the 'public' tree, and you can take off and browse from there. Better yet: Uploading is now possible! Like Didier's site, any files you upload will not be immediately available until I can take a look and make a spot for them. I've made the access instructions the same as Didier's site: If you click on 'Upload,' you'll be prompted for a user name and password. Both are 'manuals' (without the quotes). I would ask any files uploaded, especially firmware or EPROM dumps, be turned into a ZIP or RAR archive and include a descriptive 'readme' file. Good info to have includes version number, manufacturer's part number (if known, if any), type of PROM/EPROM used, and Checksum-16 value. My preferred EPROM file format is Absolute Binary (Data I/O #16), but .HEX is OK as well. Also, once you upload, please drop me an E-mail about it. Thanks much, happy tweaking! -=-=-=-=-=-=-=-=-=-=-=- Bruce Lane, Owner Head Hardware Heavy, Blue Feather Technologies -- http://www.bluefeathertech.com kyrrin (at) bluefeathertech do/t c=o=m Quid Malmborg in Plano... Fellow techies, I've taken a cue from Didier, in that I've done some work to make the Blue Feather FTP site easier to work with. I've added a web-based file sharing program, and made it accessible from our main page. When you hit up www.bluefeathertech.com, look in the lower left part of the table for the link 'Blue Feather File Archive.' One simple click takes you to the root directory of the 'public' tree, and you can take off and browse from there. Better yet: Uploading is now possible! Like Didier's site, any files you upload will not be immediately available until I can take a look and make a spot for them. I've made the access instructions the same as Didier's site: If you click on 'Upload,' you'll be prompted for a user name and password. Both are 'manuals' (without the quotes). I would ask any files uploaded, especially firmware or EPROM dumps, be turned into a ZIP or RAR archive and include a descriptive 'readme' file. Good info to have includes version number, manufacturer's part number (if known, if any), type of PROM/EPROM used, and Checksum-16 value. My preferred EPROM file format is Absolute Binary (Data I/O #16), but .HEX is OK as well. Also, once you upload, please drop me an E-mail about it. Thanks much, happy tweaking! -=-=-=-=-=-=-=-=-=-=-=- Bruce Lane, Owner Head Hardware Heavy, Blue Feather Technologies -- [1]http://www.bluefeathertech.com kyrrin (at) bluefeathertech do/t c=o=m Quid Malmborg in Plano... __._,_.___ [2]Reply via web post [3]Reply to sender [4]Reply to group [5]Start a New Topic [6]Messages in this topic (1) Recent Activity: * [7]New Members 11 * [8]New Links 1 [9]Visit Your Group [10]Yahoo! Groups Switch to: [11]Text-Only, [12]Daily Digest o [13]Unsubscribe o [14]Terms of Use o [15]Send us Feedback . [nc3=3848642] __,_._,___ References 1. http://www.bluefeathertech.com/ 2. http://groups.yahoo.com/group/hp_agilent_equipment/post;_ylc=X3oDMTJyb29jaGVnBF9TAzk3MzU5NzE0BGdycElkAzEwOTI5MzMzBGdycHNwSWQDMTcwNTA4MzY2MwRtc2dJZAM0ODAxNwRzZWMDZnRyBHNsawNycGx5BHN0aW1lAzEzNTQ0MzI2MzI-?act=replymessageNum=48017 3. mailto:kyr...@bluefeathertech.com?subject=Re%3A%20Blue%20Feather%20File%20Archive%20Updated 4. mailto:hp_agilent_equipm...@yahoogroups.com?subject=Re%3A%20Blue%20Feather%20File%20Archive%20Updated 5. http://groups.yahoo.com/group/hp_agilent_equipment/post;_ylc=X3oDMTJmb2pycm5nBF9TAzk3MzU5NzE0BGdycElkAzEwOTI5MzMzBGdycHNwSWQDMTcwNTA4MzY2MwRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEzNTQ0MzI2MzI- 6. http://groups.yahoo.com/group/hp_agilent_equipment/message/48017;_ylc=X3oDMTM3bjRpOWhkBF9TAzk3MzU5NzE0BGdycElkAzEwOTI5MzMzBGdycHNwSWQDMTcwNTA4MzY2MwRtc2dJZAM0ODAxNwRzZWMDZnRyBHNsawN2dHBjBHN0aW1lAzEzNTQ0MzI2MzIEdHBjSWQDNDgwMTc- 7.
Re: [time-nuts] [Fwd: [hp_agilent_equipment] Blue Feather File Archive Updated]
did try the ftp site it not operational On Sun, Dec 2, 2012 at 11:30 AM, J. Forster j...@quikus.com wrote: FYI, this is an archive of ROM EPROM dumps for various test gear. -John == Original Message Subject: [hp_agilent_equipment] Blue Feather File Archive Updated From:Bruce Lane kyr...@bluefeathertech.com Date:Sat, December 1, 2012 11:16 pm To: teksco...@yahoogroups.com Cc: hp_agilent_equipm...@yahoogroups.com -- Fellow techies, I've taken a cue from Didier, in that I've done some work to make the Blue Feather FTP site easier to work with. I've added a web-based file sharing program, and made it accessible from our main page. When you hit up www.bluefeathertech.com, look in the lower left part of the table for the link 'Blue Feather File Archive.' One simple click takes you to the root directory of the 'public' tree, and you can take off and browse from there. Better yet: Uploading is now possible! Like Didier's site, any files you upload will not be immediately available until I can take a look and make a spot for them. I've made the access instructions the same as Didier's site: If you click on 'Upload,' you'll be prompted for a user name and password. Both are 'manuals' (without the quotes). I would ask any files uploaded, especially firmware or EPROM dumps, be turned into a ZIP or RAR archive and include a descriptive 'readme' file. Good info to have includes version number, manufacturer's part number (if known, if any), type of PROM/EPROM used, and Checksum-16 value. My preferred EPROM file format is Absolute Binary (Data I/O #16), but .HEX is OK as well. Also, once you upload, please drop me an E-mail about it. Thanks much, happy tweaking! -=-=-=-=-=-=-=-=-=-=-=- Bruce Lane, Owner Head Hardware Heavy, Blue Feather Technologies -- http://www.bluefeathertech.com kyrrin (at) bluefeathertech do/t c=o=m Quid Malmborg in Plano... ___ 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] Using a frequency synthesizer replacement for motherboard oscillator
On Sun, 2 Dec 2012 08:43:39 -0500, Bob Camp li...@rtty.us wrote: Hi Maybe I'm just shopping in the right places. I have yet to build up a desktop machine that does *not* have at least one COM port on the motherboard. That's been true all the way from simple little Atom based ITX boards right through monster boards with all sorts of crazy stuff on them. Yes, it's not out the back, but that's very easy to take care of if you need the port. Laptops are a bit different. They seem to die of some sort of display issue long before a desktop. I don't use them in test setups. Bob When I built my most recent workstation a couple years ago, I specifically looked for motherboards that included a COM port and thought I had found one but when it arrived, I discovered that they left off everything except the UART which was integrated. Instead of trying to figure out what level translator they used, I just bought a PCI serial card instead. None of the USB serial dongles I tried worked well. I have stopped using laptops as well. They are too fragile even when just sitting in one place. I have seen a lot of old used working ones for sale at HAM swap meets though that are inexpensive. ___ 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] Using a frequency synthesizer replacement for motherboard oscillator
Hi Strange - I must indeed have been lucky on the last dozen or so systems I built up. Bob On Dec 2, 2012, at 1:14 PM, David davidwh...@gmail.com wrote: On Sun, 2 Dec 2012 08:43:39 -0500, Bob Camp li...@rtty.us wrote: Hi Maybe I'm just shopping in the right places. I have yet to build up a desktop machine that does *not* have at least one COM port on the motherboard. That's been true all the way from simple little Atom based ITX boards right through monster boards with all sorts of crazy stuff on them. Yes, it's not out the back, but that's very easy to take care of if you need the port. Laptops are a bit different. They seem to die of some sort of display issue long before a desktop. I don't use them in test setups. Bob When I built my most recent workstation a couple years ago, I specifically looked for motherboards that included a COM port and thought I had found one but when it arrived, I discovered that they left off everything except the UART which was integrated. Instead of trying to figure out what level translator they used, I just bought a PCI serial card instead. None of the USB serial dongles I tried worked well. I have stopped using laptops as well. They are too fragile even when just sitting in one place. I have seen a lot of old used working ones for sale at HAM swap meets though that are inexpensive. ___ 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] [Fwd: [hp_agilent_equipment] Blue Feather File Archive Updated]
Oops. It seems that Bruce's announcement is premature. Best, -John FYI, this is an archive of ROM EPROM dumps for various test gear. -John == Original Message Subject: [hp_agilent_equipment] Blue Feather File Archive Updated From:Bruce Lane kyr...@bluefeathertech.com Date:Sat, December 1, 2012 11:16 pm To: teksco...@yahoogroups.com Cc: hp_agilent_equipm...@yahoogroups.com -- Fellow techies, I've taken a cue from Didier, in that I've done some work to make the Blue Feather FTP site easier to work with. I've added a web-based file sharing program, and made it accessible from our main page. When you hit up www.bluefeathertech.com, look in the lower left part of the table for the link 'Blue Feather File Archive.' One simple click takes you to the root directory of the 'public' tree, and you can take off and browse from there. Better yet: Uploading is now possible! Like Didier's site, any files you upload will not be immediately available until I can take a look and make a spot for them. I've made the access instructions the same as Didier's site: If you click on 'Upload,' you'll be prompted for a user name and password. Both are 'manuals' (without the quotes). I would ask any files uploaded, especially firmware or EPROM dumps, be turned into a ZIP or RAR archive and include a descriptive 'readme' file. Good info to have includes version number, manufacturer's part number (if known, if any), type of PROM/EPROM used, and Checksum-16 value. My preferred EPROM file format is Absolute Binary (Data I/O #16), but .HEX is OK as well. Also, once you upload, please drop me an E-mail about it. Thanks much, happy tweaking! -=-=-=-=-=-=-=-=-=-=-=- Bruce Lane, Owner Head Hardware Heavy, Blue Feather Technologies -- http://www.bluefeathertech.com kyrrin (at) bluefeathertech do/t c=o=m Quid Malmborg in Plano... Fellow techies, I've taken a cue from Didier, in that I've done some work to make the Blue Feather FTP site easier to work with. I've added a web-based file sharing program, and made it accessible from our main page. When you hit up www.bluefeathertech.com, look in the lower left part of the table for the link 'Blue Feather File Archive.' One simple click takes you to the root directory of the 'public' tree, and you can take off and browse from there. Better yet: Uploading is now possible! Like Didier's site, any files you upload will not be immediately available until I can take a look and make a spot for them. I've made the access instructions the same as Didier's site: If you click on 'Upload,' you'll be prompted for a user name and password. Both are 'manuals' (without the quotes). I would ask any files uploaded, especially firmware or EPROM dumps, be turned into a ZIP or RAR archive and include a descriptive 'readme' file. Good info to have includes version number, manufacturer's part number (if known, if any), type of PROM/EPROM used, and Checksum-16 value. My preferred EPROM file format is Absolute Binary (Data I/O #16), but .HEX is OK as well. Also, once you upload, please drop me an E-mail about it. Thanks much, happy tweaking! -=-=-=-=-=-=-=-=-=-=-=- Bruce Lane, Owner Head Hardware Heavy, Blue Feather Technologies -- [1]http://www.bluefeathertech.com kyrrin (at) bluefeathertech do/t c=o=m Quid Malmborg in Plano... __._,_.___ [2]Reply via web post [3]Reply to sender [4]Reply to group [5]Start a New Topic [6]Messages in this topic (1) Recent Activity: * [7]New Members 11 * [8]New Links 1 [9]Visit Your Group [10]Yahoo! Groups Switch to: [11]Text-Only, [12]Daily Digest o [13]Unsubscribe o [14]Terms of Use o [15]Send us Feedback . [nc3=3848642] __,_._,___ References 1. http://www.bluefeathertech.com/ 2. http://groups.yahoo.com/group/hp_agilent_equipment/post;_ylc=X3oDMTJyb29jaGVnBF9TAzk3MzU5NzE0BGdycElkAzEwOTI5MzMzBGdycHNwSWQDMTcwNTA4MzY2MwRtc2dJZAM0ODAxNwRzZWMDZnRyBHNsawNycGx5BHN0aW1lAzEzNTQ0MzI2MzI-?act=replymessageNum=48017 3. mailto:kyr...@bluefeathertech.com?subject=Re%3A%20Blue%20Feather%20File%20Archive%20Updated 4. mailto:hp_agilent_equipm...@yahoogroups.com?subject=Re%3A%20Blue%20Feather%20File%20Archive%20Updated 5. http://groups.yahoo.com/group/hp_agilent_equipment/post;_ylc=X3oDMTJmb2pycm5nBF9TAzk3MzU5NzE0BGdycElkAzEwOTI5MzMzBGdycHNwSWQDMTcwNTA4MzY2MwRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEzNTQ0MzI2MzI- 6. http://groups.yahoo.com/group/hp_agilent_equipment/message/48017;_ylc=X3oDMTM3bjRpOWhkBF9TAzk3MzU5NzE0BGdycElkAzEwOTI5MzMzBGdycHNwSWQDMTcwNTA4MzY2MwRtc2dJZAM0ODAxNwRzZWMDZnRyBHNsawN2dHBjBHN0aW1lAzEzNTQ0MzI2MzIEdHBjSWQDNDgwMTc- 7.
Re: [time-nuts] [Fwd: [hp_agilent_equipment] Blue Feather File Archive Updated]
In message 1632.12.6.201.52.1354475256.squir...@popaccts.quikus.com, J. Fors ter writes: Oops. It seems that Bruce's announcement is premature. Not really, but he has used his internal (RFC1918) address for the filestore so it's not reachable from the outside. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | 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 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Considerations When Using The SR620
All, The following comment appeared on this list recently and it scared me a little: Though the SR620 TIC is a great instrument when hunting the pico seconds we have to realize, that it's a thermal design desaster (I have to apologize to all sr620 friends). I have to run it for at least 12 hoursif not 24 to be shure, that every single part is at a more or less stationary thermal state. Some (NERC) say ...never switch it off. I assume this instability is due to the instability of the internal frequency standard. There are two options for the SR620: the standard oscillator and an ovenized oscillator. In fact, in our measurements, we plan to use a Cesium frequency standard as the timebase to our SR620. Does this anecdotal warning apply generally to the instrument or mainly to the use of the internal standard oscillator? We are using the SR620 to measure the interval between 1PPS signals from two clocks. One is the Septentrio PolaRx4 GPS receiver and the other is a Rubidium clock. Many Thanks, Paul -- Paul DeStefano ___ 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] Using a frequency synthesizer replacement for motherboard oscillator
Jonathan, My research group has had some good experiences using products from Endace ( http://www.endace.com/) for network timing measurement at the ethernet level. I don't have a pointer immediately to the work, but if there is interest can ask tomorrow at work. The gist of it though was to understand precise timing characteristics of network switches for better simulation. Examining the time in switch for various packets at the microsecond level was needed to understand various delay curves for different network loads, with an ultimate goal of proper statistical modeling reflecting reality as close as possible. I personally have also used endace products to measure packet timings for research, but I didn't need so much precision for that work - however I can say they have a good API and decent tech support for interacting with their cards and products. HTH. Regards, Erich On Sat, Dec 1, 2012 at 2:35 PM, Jonatan Walck jwa...@netnod.se wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric, your experiences here is of great interest to me too, I've been exploring external clocking of Ethernet controllers as of late but have not dived into it yet. I'm more interested in your how, but of course also in your why. // jwalck PS. Hey everyone, new to this list since two days joining after attending my first PTTI. Working with time and frequency distribution in Sweden and with time getting deeper into the field both on and off work. On 12/01/2012 01:15 AM, Eric Garner wrote: I've never done it using to the RTC crystal, but I do it quite frequently in my Day Job to Ethernet controllers on those same pc mother boards. -Eric On Fri, Nov 30, 2012 at 4:10 PM, Sarah White kuze...@gmail.com wrote: On 11/30/2012 6:30 PM, Eric Garner wrote: the actual RTC on modern (Intel based) PC's is driven from a standard 32,768 Hz crystal attached to the PCH. some of them are in incredibly small packages now instead of the old tuning fork-in-a-can ones. peeling off the load caps and crystal from the board would allow you plenty of spaces to tack down a lead from an external synthesizer. Yeah, the one on the (Soekis) example was pretty small. So far none of of the replies have indicated that anyone on here has experience beyond an embedded system. Mostly I started this thread because there have been a few with people discussing implementing NTP on embedded microcontrollers, arduino, etc. and I was thinking of doing it from the other side (turning a nice-ish server into a rock-solid timekeeper) Thanks so far everyone. Really impressed that I already managed to get 4x replies so quickly :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQumoZAAoJEFwg9i9GDX+nF10P/jRTK9oCZrPz9e4++FoO9NvN +THbxwsGpGq8c1OdDDo+1ewbzmRi9SehVPngzq0Lc6rfpEwYCIqnfiM9kWokhJDW vgRwc4Re/ensYLDpGG+fMxqkKucpNS2UfsqND0xyCK4BGxDMqWbfwyukKGlKAGn+ oFoPX0+QGkgTq8tLs6HxhuSyi1Y1vc3reuZZpFDLqI+7OwwGlTFsTlSzcz2sF9/A 6TV1hcYLOnxwfNPKbSURqz5s2/3rCZf3KnlcTzxr3LLWNKJYcrW795WHpvMIYbC9 me+Oq+24EyJ69Io1ruClxMdi6vU9UC8bU8wy2J27ume4oD2E5JWPr4uY6xXlvYx6 ddkRb+p8K+NwyswNXNa3q+XFwAgsCImOusq9eOL7jc0J7M/NIrJj9GpCgn91/VGd /ZUpH7nZA7I7Um3uMgXe6zsoKHToyzYu5CtfRkS8INPS/vWfo0X+Ysos1FlfFhQS kFq306FgBpX5DRhD1e0uKSqMPuGM+Pv5uqB7DeuuY0qJS1H1RvCBatnvt1KAiVSA vh0z2s3I3Z1FnZE0/LeDSXZS3lDPfT39CdDpKqiEN4P2ifBzJI78v/3IUSykSKor aC6XHVI2eRbXjop59wcWT2gGt3a1u1uRCSv2MaQ0To8kb/+QMlxUqupqNToYHMFt UsPHLL5m4bg5+l6669VR =gybO -END PGP SIGNATURE- ___ 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] Introducing myself
HI If you haven't already discovered it, there are a number of papers out of NIST going into a variety of issues with timing security. Bob On Dec 2, 2012, at 3:06 PM, Erich Heine sophac...@gmail.com wrote: Hi everyone. I just wanted to introduce myself to the list. My name is Erich Heine, I'm a researcher at the University of Illinois. I am a programmer attached to a couple of projects, but the one relevant here is called TCIP (Trustworthy Cyber-Infrastructure for the Power Grid - url: tcipg.org). Our group does computer security research relevant the the US power grid infrastructure (and when relevant to all power delivery :) ). Recently we've had researchers looking at GPS spoofing, and are beginning to examine secure time synchronization more broadly. It's fascinating to discover just how much havoc can be caused by assuming the time signal is good enough when it may not be. (This seems to be the way of computer security - assume something is good or good enough, then someone comes along an breaks everything because the assumption was bad. Then everyone scrambles to get better solutions, and other areas become assumed good enough. Repeat ad-nauseam). I was pointed here by Magnus a month or two ago, after a fascinating discussion of just how deep this time and timing rabbit-hole goes. I'm quite impressed with this community - both in terms of deep knowledge and overall friendliness. It's been a pleasure just lurking and soaking up some knowledge since then. Anyway, I just wanted to say Hi all before I start posting questions, comments, etc. :) Regards, Erich ___ 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] Considerations When Using The SR620
Hi Some of the problem comes from the OCXO. Some of it also comes from the stability of the internal circuitry. They do some interesting things with delay lines and the like in the SR620. Best bet is to let it warm up for a while before you need it to perform at it's top level of performance. Bob On Dec 2, 2012, at 2:45 PM, Paul DeStefano paul.destef...@willamettealumni.com wrote: All, The following comment appeared on this list recently and it scared me a little: Though the SR620 TIC is a great instrument when hunting the pico seconds we have to realize, that it's a thermal design desaster (I have to apologize to all sr620 friends). I have to run it for at least 12 hoursif not 24 to be shure, that every single part is at a more or less stationary thermal state. Some (NERC) say ...never switch it off. I assume this instability is due to the instability of the internal frequency standard. There are two options for the SR620: the standard oscillator and an ovenized oscillator. In fact, in our measurements, we plan to use a Cesium frequency standard as the timebase to our SR620. Does this anecdotal warning apply generally to the instrument or mainly to the use of the internal standard oscillator? We are using the SR620 to measure the interval between 1PPS signals from two clocks. One is the Septentrio PolaRx4 GPS receiver and the other is a Rubidium clock. Many Thanks, Paul -- Paul DeStefano ___ 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] Introducing myself
Welcome aboard. Michel / K7HIL On Sun, Dec 2, 2012 at 1:06 PM, Erich Heine sophac...@gmail.com wrote: Hi everyone. I just wanted to introduce myself to the list. My name is Erich Heine, I'm a researcher at the University of Illinois. I am a programmer attached to a couple of projects, but the one relevant here is called TCIP (Trustworthy Cyber-Infrastructure for the Power Grid - url: tcipg.org). Our group does computer security research relevant the the US power grid infrastructure (and when relevant to all power delivery :) ). Recently we've had researchers looking at GPS spoofing, and are beginning to examine secure time synchronization more broadly. It's fascinating to discover just how much havoc can be caused by assuming the time signal is good enough when it may not be. (This seems to be the way of computer security - assume something is good or good enough, then someone comes along an breaks everything because the assumption was bad. Then everyone scrambles to get better solutions, and other areas become assumed good enough. Repeat ad-nauseam). I was pointed here by Magnus a month or two ago, after a fascinating discussion of just how deep this time and timing rabbit-hole goes. I'm quite impressed with this community - both in terms of deep knowledge and overall friendliness. It's been a pleasure just lurking and soaking up some knowledge since then. Anyway, I just wanted to say Hi all before I start posting questions, comments, etc. :) Regards, Erich ___ 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] Introducing myself
Dear Erich, Welcome to this fine, friendly and knowledgeable group. You just can't imagine how much I have grown in the field with the invaluable support from every member here. After a couple of months of being active, I can attest both the human and technical quality that reign among all the people here who have offered help to me in every possible way. Bob is right at pointing out NIST vast online archive on the subject. You should definitely take a look at it. I have gathered a good amount of papers and information on time security and if you need something specific I will certainly be more than glad to share and help to the best of my abilities. My research has an emphasis on ISO27001 and I have to convince in terms of IT timing security and traceability. Please feel free to contact me at your convenience if you find my offer useful. I will take advantage of the present to send best regards to every Time Nut member on the list. Thank you all. Kind regards, Edgardo Molina On Dec 2, 2012, at 2:09 PM, Bob Camp li...@rtty.us wrote: HI If you haven't already discovered it, there are a number of papers out of NIST going into a variety of issues with timing security. Bob On Dec 2, 2012, at 3:06 PM, Erich Heine sophac...@gmail.com wrote: Hi everyone. I just wanted to introduce myself to the list. My name is Erich Heine, I'm a researcher at the University of Illinois. I am a programmer attached to a couple of projects, but the one relevant here is called TCIP (Trustworthy Cyber-Infrastructure for the Power Grid - url: tcipg.org). Our group does computer security research relevant the the US power grid infrastructure (and when relevant to all power delivery :) ). Recently we've had researchers looking at GPS spoofing, and are beginning to examine secure time synchronization more broadly. It's fascinating to discover just how much havoc can be caused by assuming the time signal is good enough when it may not be. (This seems to be the way of computer security - assume something is good or good enough, then someone comes along an breaks everything because the assumption was bad. Then everyone scrambles to get better solutions, and other areas become assumed good enough. Repeat ad-nauseam). I was pointed here by Magnus a month or two ago, after a fascinating discussion of just how deep this time and timing rabbit-hole goes. I'm quite impressed with this community - both in terms of deep knowledge and overall friendliness. It's been a pleasure just lurking and soaking up some knowledge since then. Anyway, I just wanted to say Hi all before I start posting questions, comments, etc. :) Regards, Erich ___ 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.
Re: [time-nuts] Using a frequency synthesizer replacement for motherboard oscillator
Erich, On 12/02/2012 08:54 PM, Erich Heine wrote: Jonathan, My research group has had some good experiences using products from Endace ( http://www.endace.com/) for network timing measurement at the ethernet level. I don't have a pointer immediately to the work, but if there is interest can ask tomorrow at work. The gist of it though was to understand precise timing characteristics of network switches for better simulation. Examining the time in switch for various packets at the microsecond level was needed to understand various delay curves for different network loads, with an ultimate goal of proper statistical modeling reflecting reality as close as possible. This is a bold challenge, it's a difficult task (clear speak: there is a reason for this to be a research field, industry never *really* got it under control). I personally have also used endace products to measure packet timings for research, but I didn't need so much precision for that work - however I can say they have a good API and decent tech support for interacting with their cards and products. Is there native support with Linux kernels? It would be very nice to have the support using SO_TIMESTAMP and friends. 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] Considerations When Using The SR620
Paul wrote: The following comment appeared on this list recently and it scared me a little: Though the SR620 TIC is a great instrument when hunting the pico seconds we have to realize, that it's a thermal design desaster (I have to apologize to all sr620 friends). I have to run it for at least 12 hoursif not 24 to be shure, that every single part is at a more or less stationary thermal state. Some (NERC) say ...never switch it off. I assume this instability is due to the instability of the internal frequency standard. * * * In fact, in our measurements, we plan to use a Cesium frequency standard as the timebase to our SR620. Does this anecdotal warning apply generally to the instrument or mainly to the use of the internal standard oscillator? I concur with the comment above that the thermal design of the 620 could have been better -- the sensing thermistor is in an exhaust stack between the fan (which is blowing out) and the rear enclosure wall. This means that, instead of trying to maintain the internal instrument temerature at a constant level, it tries to maintain the exhaust stack temperature constant with a viciously fast response time that leads to instability at startup. I have more than once considered moving the thermistor to a location near the TCXO, but since the fans always run up to full speed rather quickly at room temperature anyway, I have never bothered to try to improve the fan circuit. Additionally. the TCXO remains powered during standby, but not exactly on frequency because the DAC that adjusts it during operation is not powered. So, there is some settling from that adding to the temperature drift. Note also that the DAC steps are not very fine, so you cannot expect to get the internal oscillator trimmed to better than e-9 or so. SR apparently thought that most users would connect 620s to external standards, so there was no reason to make them pay for a high-precision internal standard they would not use. IME -- operating with an external reference that is better than the specified accuracy of the 620 -- they meet SR's specifications within a few minutes at most after switching on from room temperature storage. (The trigger circuitry may drift a bit as it warms up, so you may want to check the trigger drift if your application involves slowish sine waves. I have not investigated this.) Ideally, you would let the instrument warm up for at least an hour and then perform an internal calibration before starting your measurements. All that said, the only way you will know for sure how your particular instrument and standard will perform is to characterize them before you start your mobile measurements. In doing so, you should observe a protocol that resembles the actual travel between measurements, at least with respect to time and temperature. I strongly urge you to do this so you can have confidence in your measurements. Best regards, Charles ___ 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] Considerations When Using The SR620
On 12/02/2012 10:25 PM, Charles P. Steinmetz wrote: Paul wrote: The following comment appeared on this list recently and it scared me a little: Though the SR620 TIC is a great instrument when hunting the pico seconds we have to realize, that it's a thermal design desaster (I have to apologize to all sr620 friends). I have to run it for at least 12 hoursif not 24 to be shure, that every single part is at a more or less stationary thermal state. Some (NERC) say ...never switch it off. I assume this instability is due to the instability of the internal frequency standard. * * * In fact, in our measurements, we plan to use a Cesium frequency standard as the timebase to our SR620. Does this anecdotal warning apply generally to the instrument or mainly to the use of the internal standard oscillator? I concur with the comment above that the thermal design of the 620 could have been better -- the sensing thermistor is in an exhaust stack between the fan (which is blowing out) and the rear enclosure wall. This means that, instead of trying to maintain the internal instrument temerature at a constant level, it tries to maintain the exhaust stack temperature constant with a viciously fast response time that leads to instability at startup. I have more than once considered moving the thermistor to a location near the TCXO, but since the fans always run up to full speed rather quickly at room temperature anyway, I have never bothered to try to improve the fan circuit. Never thought about that part, other than the fact that the fan is annoying like hell. Additionally. the TCXO remains powered during standby, but not exactly on frequency because the DAC that adjusts it during operation is not powered. So, there is some settling from that adding to the temperature drift. Note also that the DAC steps are not very fine, so you cannot expect to get the internal oscillator trimmed to better than e-9 or so. SR apparently thought that most users would connect 620s to external standards, so there was no reason to make them pay for a high-precision internal standard they would not use. Which is why a high stability reference is an option, like most. In contrast it is interesting to note that the HP5370 had a lower stability oscillator as option, so removing the 10811 was thus using a negative option. IME -- operating with an external reference that is better than the specified accuracy of the 620 -- they meet SR's specifications within a few minutes at most after switching on from room temperature storage. (The trigger circuitry may drift a bit as it warms up, so you may want to check the trigger drift if your application involves slowish sine waves. I have not investigated this.) Ideally, you would let the instrument warm up for at least an hour and then perform an internal calibration before starting your measurements. Another source of temperature dependence is the analogue interpolator. All that said, the only way you will know for sure how your particular instrument and standard will perform is to characterize them before you start your mobile measurements. In doing so, you should observe a protocol that resembles the actual travel between measurements, at least with respect to time and temperature. I strongly urge you to do this so you can have confidence in your measurements. This is good advice. Consider what you need to do. You might want to consider having a rubidium doing your hold-over. for instance. A PRS-10 would be an interesting option for instance. 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] Introducing myself
Hi Erich, On 12/02/2012 09:06 PM, Erich Heine wrote: Hi everyone. I just wanted to introduce myself to the list. My name is Erich Heine, I'm a researcher at the University of Illinois. I am a programmer attached to a couple of projects, but the one relevant here is called TCIP (Trustworthy Cyber-Infrastructure for the Power Grid - url: tcipg.org). Our group does computer security research relevant the the US power grid infrastructure (and when relevant to all power delivery :) ). Recently we've had researchers looking at GPS spoofing, and are beginning to examine secure time synchronization more broadly. It's fascinating to discover just how much havoc can be caused by assuming the time signal is good enough when it may not be. (This seems to be the way of computer security - assume something is good or good enough, then someone comes along an breaks everything because the assumption was bad. Then everyone scrambles to get better solutions, and other areas become assumed good enough. Repeat ad-nauseam). I strongly advice you and anyone caring about computer security to read up on NTP in the forms of Prof. Dave Mills book, as well as the many online resources. He spent good time on figuring out ways to suspect everyone and then find methods of handling this situation. You can do a lot with a standard NTP if you only care to read up on it. I was pointed here by Magnus a month or two ago, after a fascinating discussion of just how deep this time and timing rabbit-hole goes. Hehehe... hope I didn't scare you too much :) I'm quite impressed with this community - both in terms of deep knowledge and overall friendliness. It's been a pleasure just lurking and soaking up some knowledge since then. Which is exactly what I was hoping for. I recommended this list as there is no better way to pick up on all the odd bits and pieces that involve the concept of time that we think we understand, but most doesn't. Anyway, I just wanted to say Hi all before I start posting questions, comments, etc. :) Feel welcome! I have been waiting for you to de-lurk yourself and start participate. I hope your questions and comments triggers the interest of many, and we get a good debate. 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] Introducing myself
Welcome, Erich! (By the way, are you from Germany?) Volker Am 02.12.2012 21:06, schrieb Erich Heine: Hi everyone. I just wanted to introduce myself to the list. My name is Erich Heine, I'm a researcher at the University of Illinois. I am a programmer attached to a couple of projects, but the one relevant here is called TCIP (Trustworthy Cyber-Infrastructure for the Power Grid - url: tcipg.org). Our group does computer security research relevant the the US power grid infrastructure (and when relevant to all power delivery :) ). Recently we've had researchers looking at GPS spoofing, and are beginning to examine secure time synchronization more broadly. It's fascinating to discover just how much havoc can be caused by assuming the time signal is good enough when it may not be. (This seems to be the way of computer security - assume something is good or good enough, then someone comes along an breaks everything because the assumption was bad. Then everyone scrambles to get better solutions, and other areas become assumed good enough. Repeat ad-nauseam). I was pointed here by Magnus a month or two ago, after a fascinating discussion of just how deep this time and timing rabbit-hole goes. I'm quite impressed with this community - both in terms of deep knowledge and overall friendliness. It's been a pleasure just lurking and soaking up some knowledge since then. Anyway, I just wanted to say Hi all before I start posting questions, comments, etc. :) Regards, Erich ___ 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] Introducing myself
Erich, Edgardo, On 12/02/2012 09:27 PM, Edgardo Molina wrote: Dear Erich, Welcome to this fine, friendly and knowledgeable group. You just can't imagine how much I have grown in the field with the invaluable support from every member here. After a couple of months of being active, I can attest both the human and technical quality that reign among all the people here who have offered help to me in every possible way. Bob is right at pointing out NIST vast online archive on the subject. You should definitely take a look at it. NIST online archive in this context means their Time and Frequency group online archive, with a search engine here: http://www.tf.nist.gov/timefreq/general/publications.htm Recommended authors to search for is Allan, Lombardi, Levine, Nelson, Howe to name a few. Since NIST is a govrement agency (part of Department of Commerce), copyright does not apply, and they are free to put all their published papers online. Make sure to use them well. There are tons of goodies in there. 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] Using a frequency synthesizer replacement for motherboard oscillator
Date: Sun, 02 Dec 2012 22:16:52 +0100 From: Magnus Danielson mag...@rubidium.dyndns.org On 12/02/2012 08:54 PM, Erich Heine wrote: Examining the time in switch for various packets at the microsecond level was needed to understand various delay curves for different network loads, with an ultimate goal of proper statistical modeling reflecting reality as close as possible. This is a bold challenge, it's a difficult task (clear speak: there is a reason for this to be a research field, industry never *really* got it under control). I agree with Magus, but measuring in-host (or in-switch) timing is still possible. The research team I am with presented a paper at ISPCS this year on the measuring of in-host latencies and looking at where packet timestamps take place, such as SO_TIMESTAMP as Magnus mentions below. I will point you to a link to our docs, email me off the list if you do not have access to the IEEE online journals. The paper is mainly focused on BSD systems; however, BSD is not unheard of in the switch world so maybe it can give you a few tricks for what you want to accomplish regarding your in-switch timing. Paper: Probing the Latencies of Software Timestamping http://www.synclab.org/docs/ I personally have also used endace products to measure packet timings for research, but I didn't need so much precision for that work - however I can say they have a good API and decent tech support for interacting with their cards and products. Is there native support with Linux kernels? It would be very nice to have the support using SO_TIMESTAMP and friends. Our team also uses Endace. But we only host the Endcace DAG cards on our BSD boxes. -Matt ___ 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] Measuring GPS noise floor (sort of)
Hi The GPSDO vs GPSDO should be pounding pretty hard against the 1.0 x 10^-14 line out around a day. You should see a bit of a hump at 24 sidereal hours. Bob On Dec 2, 2012, at 5:37 PM, Mark Spencer mspencer12...@yahoo.ca wrote: I'm wondering how useful it is to compare two different GPS receivers to a single Rb to get a sense of the GPS noise floor. I've been collecting some data for the last week or so seem be making some headway with this. Not having a cesium or an Hmaser I elected to compare two different GPSDO's to a single Rb and then assuming the data seemed sane, I thought I would then compute the Adev between the two GPSDO's. My assumption is that by comparing the two GPSDO's to the Rb it should be possible to detect when one GPSDO is mis behaving or possibly when the Rb mis behaves. So far other than a bit of a glitch at the start of the process things seem to be proceeding as I expected. I hope to collect another two weeks or so of data if all goes according to plan. I'm really only interested in the longer term numbers and I wouldn't put to much trust in the shorter term results. Comments would be welcome especially if there is a fundamental flaw with this process. Looking at the data gave me something to do this afternoon during some down time on a business trip (: I reazlize this approach is probably not how the pros would do this. Regards Mark Spencer Fury vs Z3805 vs PRS10 phase.gifFury vs Z3805 vs PRS10 Adev.gif___ 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] Measuring GPS noise floor (sort of)
On 12/02/2012 11:37 PM, Mark Spencer wrote: I'm wondering how useful it is to compare two different GPS receivers to a single Rb to get a sense of the GPS noise floor. I've been collecting some data for the last week or so seem be making some headway with this. Not having a cesium or an Hmaser I elected to compare two different GPSDO's to a single Rb and then assuming the data seemed sane, I thought I would then compute the Adev between the two GPSDO's. My assumption is that by comparing the two GPSDO's to the Rb it should be possible to detect when one GPSDO is mis behaving or possibly when the Rb mis behaves. So far other than a bit of a glitch at the start of the process things seem to be proceeding as I expected. I hope to collect another two weeks or so of data if all goes according to plan. I'm really only interested in the longer term numbers and I wouldn't put to much trust in the shorter term results. Comments would be welcome especially if there is a fundamental flaw with this process. Looking at the data gave me something to do this afternoon during some down time on a business trip (: I reazlize this approach is probably not how the pros would do this. You do realize that several issues with the GPSDOs will be common mode, such as the errors of the ionspheric model and actual ionspheric effect and that of multipath. The rubidium will to some degree aid to illustrate these shifts, but it will be accounted for on the rubidium deviation from the common. If you look at the CRIT paper we discussed yesterday, they did exactly what you proposes. For most stuff the 5 recievers they used didn't show much differences. If you increase the resolution you might get out more. You might have use for additional local references, in order to separate out other effects. For instance, with three rubidiums measured, you could single out which of them has an error, and any common mode effects of the GPSDOs could be fairly well separated out from the local performance of your rubidiums. 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] Introducing myself
On 12/2/2012 4:45 PM, Magnus Danielson wrote: Erich, Edgardo, On 12/02/2012 09:27 PM, Edgardo Molina wrote: Dear Erich, Welcome to this fine, friendly and knowledgeable group. You just can't imagine how much I have grown in the field with the invaluable support from every member here. After a couple of months of being active, I can attest both the human and technical quality that reign among all the people here who have offered help to me in every possible way. Bob is right at pointing out NIST vast online archive on the subject. You should definitely take a look at it. NIST online archive in this context means their Time and Frequency group online archive, with a search engine here: http://www.tf.nist.gov/timefreq/general/publications.htm Recommended authors to search for is Allan, Lombardi, Levine, Nelson, Howe to name a few. Since NIST is a govrement agency (part of Department of Commerce), copyright does not apply, and they are free to put all their published papers online. Make sure to use them well. There are tons of goodies in there. Cheers, Magnus Don't forget that you can browse the publications by just leaving the search boxes blank and hitting the 'submit' button. I noticed a few new papers with Time-Nuts potential on the new WWVB and a couple on an Ultra-Low-Noise Regenerative Frequency Divider based on the 2NA Double Balanced Mixer. Ed ___ 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] Using a frequency synthesizer replacement for motherboard oscillator
Matt, On 12/02/2012 11:51 PM, Matt Davis wrote: Date: Sun, 02 Dec 2012 22:16:52 +0100 From: Magnus Danielsonmag...@rubidium.dyndns.org On 12/02/2012 08:54 PM, Erich Heine wrote: Examining the time in switch for various packets at the microsecond level was needed to understand various delay curves for different network loads, with an ultimate goal of proper statistical modeling reflecting reality as close as possible. This is a bold challenge, it's a difficult task (clear speak: there is a reason for this to be a research field, industry never *really* got it under control). I agree with Magus, but measuring in-host (or in-switch) timing is still possible. Indeed. It is possible to measure, but difficult to fully model and characterize. A friend of me did his PhD on the fractal behaviour of network trafic. Then, even he didn't nailed it in a good way. The research team I am with presented a paper at ISPCS this year on the measuring of in-host latencies and looking at where packet timestamps take place, such as SO_TIMESTAMP as Magnus mentions below. I will point you to a link to our docs, email me off the list if you do not have access to the IEEE online journals. The paper is mainly focused on BSD systems; however, BSD is not unheard of in the switch world so maybe it can give you a few tricks for what you want to accomplish regarding your in-switch timing. Paper: Probing the Latencies of Software Timestamping http://www.synclab.org/docs/ People should dive into that link, there is a few goodies there it seems from just pulling one paper. Thanks for providing the pointer, Matt! 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] Introducing myself
On 12/03/2012 12:22 AM, Ed Palmer wrote: Don't forget that you can browse the publications by just leaving the search boxes blank and hitting the 'submit' button. I noticed a few new papers with Time-Nuts potential on the new WWVB and a couple on an Ultra-Low-Noise Regenerative Frequency Divider based on the 2NA Double Balanced Mixer. Indeed. It's just that with way over 2000 documents there, it is easy to not find what you want, so I wanted to give some search terms to get started and not completely loose onceself in the noise. There is a lot of interesting papers on optical clocks, etc. You can get seriously side-tracked there. :) 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] Considerations When Using The SR620
Volker, On 12/02/2012 11:36 PM, Volker Esper wrote: Hi, I was the one who wrote those nasty things about a fantastic instrument. I bought such a counter a few weeks ago. When I first peeked into it (because the fan was running at top speed after a few minutes) I noticed, that the arrangement of the components was anything but optimal. Examples: The osc is only one or two inches away from the linear voltage regulators. These are cooled by a 1mm iron sheet. The iron sheet has some cooling slots where the air can flow through, but these slots are miles away from the regulators. The sheet gets so hot that you won't touch it voluntarily. If at least the air could flow directly along the regulators - but they sit in a corner and the air flows diagonally through the case, avoiding contact with the regulators. I am also not very impressed with the location of the linear regulators. This forms a nice interesting relationship between line voltage and room temperature. As line voltage shifts, the rectified voltage varies, and then the voltage that the linear regulator needs to burn off varies, and thus their heat contribution varies with the line voltage. Now, the ambient temperature then controls how easy we get rid of this excess heat. The way the airflow goes, this cooling makes sure it couples very well with the electronics, so fan speed amongst other things depend on ambient temperature... and line voltage. All this assist to give us an interesting temperature dependence. In contrast, I was impressed by how the HP10811A was located in a turbolence free corner of the HP5070A/B assembly. While itself also not particularly well designed in heat context, at least the heat of the linear regulators was supposed to mostly affect an external self-convection stream. Forces convection (fan) to stabilize the temperature of the heat sink would be a good thing there. 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] 3120A Phase Noise Test Probe
Thanks, guys! Sorry about the price increase, that wasn't my doing. :) -- john, KE5FX -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts- boun...@febo.com] On Behalf Of Tom Knox Sent: Saturday, December 01, 2012 4:33 PM To: Time-Nuts Subject: Re: [time-nuts] 3120A Phase Noise Test Probe Great to hear John. Thomas Knox Date: Sat, 1 Dec 2012 13:24:35 -0700 From: ke...@rosenberg.net To: time-nuts@febo.com Subject: Re: [time-nuts] 3120A Phase Noise Test Probe Magnus Danielson wrote: Congratulation John! Good work! Truly well-deserved, John! Kevin ___ 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.
