Re: [time-nuts] A little tail about using the time-nuts tricks at work
In message <5335f5af.5000...@rubidium.dyndns.org>, Magnus Danielson writes: >I hope this little tail will encourage you to use the tools, learn to >investigate them and learn the various ways of displaying data, so it >can help you to pin-point the problems you are having. And you don't even need to have time & frequency direclty involved: The Allan Variance is an incredible useful way to identify periodic issues, almost no matter what the dataset is about. -- 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.
Re: [time-nuts] Another Arduino GPSDO
Hi Since the output of your GPS (short term and long term) is likely much better than your ability to measure (using your setup), why not just drive the clock with the GPS? You would use far less power and have far fewer problems. Bob On Mar 28, 2014, at 5:55 PM, Eric Williams wrote: > I just saw Lars' postings on his design and thought I'd throw mine in since > I've been working on a similar low-end goal but doing it a different way. > Not really an Arduino, either, but it's based on an AVR processor and > should be portable to an Arduino. Right now it's still on a solderless > breadboard but it seems to be working. > > I have a 5MHz OCXO feeding counter/timer 1 on a ATmega644, the 16-bit > counter is set to count modulo 5000 and the 1PPS from the GPS (uBlox NEO > 6M) triggers a capture of the counter, and also a capture interrupt. If > the OCXO is exactly right you should get the same capture value every > second. If the value changes, the frequency is off. > > Obviously this only tells you if the OCXO drifts off from the 1PPS by one > cycle or more, so that's only 200ns resolution. To get below that I count > the number of 1PPS ticks before a second cycle is dropped, then use the > inverse of the time interval to correct the DAC on the OCXO. (The shorter > the period, the larger the correction.) I was lucky enough to snag a > Symetricom OCXO with a built-in DAC, so that's a simple matter of clocking > a 16-bit value into it. > > Typically the thing runs at an interval of 2000 seconds or so between > corrections, so that's about 1 part in 10^10. The code is pretty ad-hoc, > but once it thinks it has the frequency pretty close it starts nudging the > phase in a direction to where the capture count converges on zero. The > object of the thing is to make a ridiculously accurate table clock, and the > clock code is driven by the 1ms counter overflow interrupt, so this make > the interrupt line up with the 1PPS from the GPS. > > I'm sure the short-term stability isn't as good as a PLL, but averaging the > errors over such a long period does have the advantage of making the > sawtooth error pretty much irrelevant. > > I also have a 1-Wire thermometer stuck to the OCXO case and record the DAC > values by temperature in the AVR's EEPROM, they can be retrieved for use in > holdover conditions. The DAC values that produce longer transition periods > take precedence over those with shorter ones for the same temperature. > -- > Eric Williams WD6CMU > ___ > 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] Another Arduino GPSDO
Right, I should be able to get that from the TIM-TP message, but then what do I do with it? Not sure how I can apply a picosecond correction in this configuration short of adding a programmable delay line chip that would cost more than the GPS receiver did. -- eric On Fri, Mar 28, 2014 at 6:40 PM, Chris Albertson wrote: > On Fri, Mar 28, 2014 at 5:15 PM, Eric Williams wrote: > > > OK, now I understand the reference, but not the significance in this > > context. The sawtooth error is below the resolution of the counter here. > > > I think you are right. It hardly matters for your application. I think > you said this was going to drive a wall clock? > > But on the other hand using sawtooth is free and does not add to the parts > count. All you do is read some serial data. > > -- > > Chris Albertson > Redondo Beach, California > ___ > 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] Japan / Time-Nuts
Tom, If you have time - you may visit New Japan Radio: http://www.njr.com/ 3-10, Nihonbashi Yokoyama-cho,Chuo-ku, Tokyo 103-8456, Japan TEL: + 81-3-5642-8222 / FAX: + 81-3-5642-8220 I believe there are people there that also deal or know those that know about vintage equipment in the area. Regards, John W. On Fri, Mar 28, 2014 at 1:25 PM, Tom Van Baak wrote: > I might be in Tokyo in late May (2014) with hopefully a spare day or two. > > Are there any geek & technology or precise time & frequency locations / > activities / events / people I should seek out while I'm there? Are there > any high-precision clock or time-nuts or vintage-electronics collectors in > Japan that I should meet? > > Replies to the list, or off-list email is ok: t...@leapsecond.com > > Thanks, > /tvb > www.LeapSecond.com > ___ > 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] Another Arduino GPSDO
On Fri, Mar 28, 2014 at 5:15 PM, Eric Williams wrote: > OK, now I understand the reference, but not the significance in this > context. The sawtooth error is below the resolution of the counter here. I think you are right. It hardly matters for your application. I think you said this was going to drive a wall clock? But on the other hand using sawtooth is free and does not add to the parts count. All you do is read some serial data. -- Chris Albertson Redondo Beach, California ___ 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] Another Arduino GPSDO
Hi The problem is that it can / might / could / will create a “dc bias” in the noise. When you filter it, you get a bump rather than zero. If your GPSDO has a 47 ns wide sawtooth, that could be a pretty big bump. There’s no way to know if the bridge is seconds, minutes, or hours wide. You can make a good guess that hours are a *lot* less common than seconds…. If you are after 0.01 ppb (parts per billion), then a 47 ns offset would need to be averaged for about 10,000 seconds if it’s narrow. If it sticks around for 100 seconds you might need to average for quite a bit longer …. Bob On Mar 28, 2014, at 8:15 PM, Eric Williams wrote: > OK, now I understand the reference, but not the significance in this > context. The sawtooth error is below the resolution of the counter here. > It does produce noise on the transition between capture counts that I am > filtering out, but it should average out over the long-term integration > that I'm using, right? > -- > eric > > > On Fri, Mar 28, 2014 at 4:41 PM, Hal Murray wrote: > >> >> wd6...@gmail.com said: >>> I'm sorry, I don't recognize the reference to "hanging bridges". >> >> I guess it was a good thing I mentioned it. Sometimes I feel like a broken >> record. It gets discussed here occasionally. There will be lots of >> comments >> in the archives. >> >> Starter version: >> tvb: Motorola GPS M12+ Sawtooth >> http://www.leapsecond.com/pages/m12/sawtooth.htm >> >> Long version, very good: >> Tom Clark and Rick Hambly: Timing for VLBI >> http://gpstime.com/files/tow-time2009.pdf >> >> >> -- >> These are my opinions. I hate spam. >> >> >> >> ___ >> 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] Another Arduino GPSDO
OK, now I understand the reference, but not the significance in this context. The sawtooth error is below the resolution of the counter here. It does produce noise on the transition between capture counts that I am filtering out, but it should average out over the long-term integration that I'm using, right? -- eric On Fri, Mar 28, 2014 at 4:41 PM, Hal Murray wrote: > > wd6...@gmail.com said: > > I'm sorry, I don't recognize the reference to "hanging bridges". > > I guess it was a good thing I mentioned it. Sometimes I feel like a broken > record. It gets discussed here occasionally. There will be lots of > comments > in the archives. > > Starter version: > tvb: Motorola GPS M12+ Sawtooth > http://www.leapsecond.com/pages/m12/sawtooth.htm > > Long version, very good: > Tom Clark and Rick Hambly: Timing for VLBI > http://gpstime.com/files/tow-time2009.pdf > > > -- > These are my opinions. I hate spam. > > > > ___ > 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] Another Arduino GPSDO
wd6...@gmail.com said: > I'm sorry, I don't recognize the reference to "hanging bridges". I guess it was a good thing I mentioned it. Sometimes I feel like a broken record. It gets discussed here occasionally. There will be lots of comments in the archives. Starter version: tvb: Motorola GPS M12+ Sawtooth http://www.leapsecond.com/pages/m12/sawtooth.htm Long version, very good: Tom Clark and Rick Hambly: Timing for VLBI http://gpstime.com/files/tow-time2009.pdf -- These are my opinions. I hate spam. ___ 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] Another Arduino GPSDO
I'm sorry, I don't recognize the reference to "hanging bridges". I don't consider it a PLL because I have no way to measure phase differences within a cycle. I have some serial debugging output to see what the code's doing, but I'll have to think about how to organize it into graphs that would be meaningful. -- eric On Fri, Mar 28, 2014 at 3:43 PM, Hal Murray wrote: > > [Nice description. Thanks.] > > wd6...@gmail.com said: > > I'm sure the short-term stability isn't as good as a PLL, but averaging > the > > errors over such a long period does have the advantage of making the > > sawtooth error pretty much irrelevant. > > You don't believe in hanging bridges? > > What do you mean by PLL and/or why isn't what you described a PLL? > > Are you logging any data? It would be neat to see some graphs. > > > -- > These are my opinions. I hate spam. > > > > ___ > 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] Another Arduino GPSDO
[Nice description. Thanks.] wd6...@gmail.com said: > I'm sure the short-term stability isn't as good as a PLL, but averaging the > errors over such a long period does have the advantage of making the > sawtooth error pretty much irrelevant. You don't believe in hanging bridges? What do you mean by PLL and/or why isn't what you described a PLL? Are you logging any data? It would be neat to see some graphs. -- These are my opinions. I hate spam. ___ 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] A little tail about using the time-nuts tricks at work
Fellow time-nuts, Every now and then, a customer runs into trouble. You end up in these meetings where vendor and customers discuss troubles. I heard about this one and invited myself along. Turns out my friends at the customer was attending. Troubles involved dropouts and blips on a transmission. They have had one problem with a cyclic error, but it reduced after finding out they had forgot to enable a sync input. The remaining problem was erratic and showing up only for some locations and not correlating to anything obvious. One of the techs had tried out to see what an external sync-box was doing, and he had found it to do strange things, but it was not conclusive. We then realized that it might be that handling of the box could be different for each occasion they where running, because on side is a travelling setup, so it depends on the wiring and power-up order. So, we had a nice candidate. Our boxes have nice logging, but you loose much of the data if you do not pull it out before power-down, so we had no real detailed logs from when real hits occurred, so we where blinded. Not really a clear picture, but we had a good meeting. As we where over at their place, I asked if I could borrow one of those boxes as I can measure things better. They showed me what they did with an oscilloscope, and well, it did move around a little, but it wasn't very clear what was going on. As I got back to my lab-bench at work, I hooked it up with sync signal and then measured the frequency, and sure enough, it showed frequency errors similar to what we had seen before. Then I turned over to TIC measurements, meaning a HP5335A, a GPS as PPS and 10 MHz source and a laptop with GPIB and TimeLab. We do have better counters, but I get to use the 5335A without people stealing it and besides I like it better than the 53132A. Just doing basic operations as turning it on, providing sync and watching the phase and frequency, I could see *much* better what this box is doing, and the hunch that my customer had was completely confirmed. A quick report on email caused them to book a visit, and they sat down and could see it for themselves. The 5335A and TimeLab with a GPS turned out to be a valuable tool for this exercise, clearing up the issue in a few hours of play-time. Flipping between phase and frequency view, zooming in etc. all helped to illustrate what was going on. I will assist my customer in reporting on the issue to the sync-box vendor, providing measurements and explanations. I hope this little tail will encourage you to use the tools, learn to investigate them and learn the various ways of displaying data, so it can help you to pin-point the problems you are having. Oh, I had fun doing it! :-) PS. I will help a friend to get his PM6654C up and running, and try using it with TimeLab. With it's 2 ns resolution, it would still be sufficient for this exercise. 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] Another Arduino GPSDO
I just saw Lars' postings on his design and thought I'd throw mine in since I've been working on a similar low-end goal but doing it a different way. Not really an Arduino, either, but it's based on an AVR processor and should be portable to an Arduino. Right now it's still on a solderless breadboard but it seems to be working. I have a 5MHz OCXO feeding counter/timer 1 on a ATmega644, the 16-bit counter is set to count modulo 5000 and the 1PPS from the GPS (uBlox NEO 6M) triggers a capture of the counter, and also a capture interrupt. If the OCXO is exactly right you should get the same capture value every second. If the value changes, the frequency is off. Obviously this only tells you if the OCXO drifts off from the 1PPS by one cycle or more, so that's only 200ns resolution. To get below that I count the number of 1PPS ticks before a second cycle is dropped, then use the inverse of the time interval to correct the DAC on the OCXO. (The shorter the period, the larger the correction.) I was lucky enough to snag a Symetricom OCXO with a built-in DAC, so that's a simple matter of clocking a 16-bit value into it. Typically the thing runs at an interval of 2000 seconds or so between corrections, so that's about 1 part in 10^10. The code is pretty ad-hoc, but once it thinks it has the frequency pretty close it starts nudging the phase in a direction to where the capture count converges on zero. The object of the thing is to make a ridiculously accurate table clock, and the clock code is driven by the 1ms counter overflow interrupt, so this make the interrupt line up with the 1PPS from the GPS. I'm sure the short-term stability isn't as good as a PLL, but averaging the errors over such a long period does have the advantage of making the sawtooth error pretty much irrelevant. I also have a 1-Wire thermometer stuck to the OCXO case and record the DAC values by temperature in the AVR's EEPROM, they can be retrieved for use in holdover conditions. The DAC values that produce longer transition periods take precedence over those with shorter ones for the same temperature. -- Eric Williams WD6CMU ___ 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 GPS to Fine Tune a Rubidium Frequency Standard.
The QEX unit is a spin off of the Shera, how ever the DAC is only 12 bits covering the full tuning range of the Rb. Shera does it better with 18 bits and has additional features. I would not spend the money to get a copy. Bert Kehren In a message dated 3/28/2014 2:42:55 P.M. Eastern Daylight Time, mgeo...@tuffmail.us writes: Anders: I am a QEX subscriber and have that issue but I haven't built the circuit. The author referenced Brooks Shera as the basis for his work. He uses a Trimble Resolution T GPS for a PPS reference and an LPRO-101 Rubidium oscillator for the 10MHz. His circuit divides the 10MHz output from Rb by 100 and compares the phase of the 100kHz against the PPS. A PIC16 MCU is the controller and uses the phase data to control an external DAC to drive the Rb frequency control pin. There were a couple of other time & frequency related articles in 2013 if you decide to get the CD. Mike On 3/21/2014 09:20, Anders Time wrote: > Does anyone have a copy of the QEX 2013 november article(Bill Kaune) "Using > GPS to Fine Tune a Rubidium Frequency Standard"? > > I´m really interested in this subject, but I can´t find this magazine in > Sweden. I have contacted QEX, but it is very difficult to buy back-issues. > > Have any one built this frequency standard and can tell me more about the > project? > You can access the source code for the project here: > http://www.arrl.org/files/file/QEX%20Binaries/2013/November_13/11x13_Kaune_PIC_Code.zip > > /Anders > ___ > 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] Japan / Time-Nuts
I might be in Tokyo in late May (2014) with hopefully a spare day or two. Are there any geek & technology or precise time & frequency locations / activities / events / people I should seek out while I'm there? Are there any high-precision clock or time-nuts or vintage-electronics collectors in Japan that I should meet? Replies to the list, or off-list email is ok: t...@leapsecond.com Thanks, /tvb www.LeapSecond.com ___ 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] Beaglebone NTP server
On Wed, Mar 26, 2014 at 5:51 PM, Henry Hallam wrote: > I have a Z3805A and a Beaglebone, and would like to set up an NTP > server for the lab. Any kernel drivers and/or setup hints would be > appreciated :) I've managed (almost by accident) to run my dev boards and related GPS off the same power until this one. In the BBB instance having two power supplies added a fatal level of noise to GPIO input. On Thu, Mar 27, 2014 at 12:01 AM, nuts wrote: > Much appreciated. I have that GPS. Turns out this thread points out an issue which will need to checked: https://groups.google.com/forum/#!msg/beagleboard/emMCqt_mllI/bf7jL_ahPjYJ I'm currently not able to simultaneously read the serial output and the PPS. Some minor issue I'm sure. ___ 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 GPS to Fine Tune a Rubidium Frequency Standard.
Hi Anders, please contact me offline and I will send you a copy of the QEX article. Rgds Ernie. -Original Message- From: Mike George To: time-nuts Sent: Fri, Mar 28, 2014 7:43 pm Subject: Re: [time-nuts] Using GPS to Fine Tune a Rubidium Frequency Standard. Anders: I am a QEX subscriber and have that issue but I haven't built he circuit. The author referenced Brooks Shera as the basis for his work. He uses a Trimble Resolution T GPS for a PPS reference and an PRO-101 Rubidium oscillator for the 10MHz. is circuit divides the 10MHz output from Rb by 100 and ompares the phase of the 100kHz against the PPS. PIC16 MCU is the controller and uses the phase data to control n external DAC to drive the Rb frequency control pin. There were a couple of other time & frequency related articles in 2013 f you decide to get the CD. Mike On 3/21/2014 09:20, Anders Time wrote: Does anyone have a copy of the QEX 2013 november article(Bill Kaune) "Using GPS to Fine Tune a Rubidium Frequency Standard"? I´m really interested in this subject, but I can´t find this magazine in Sweden. I have contacted QEX, but it is very difficult to buy back-issues. Have any one built this frequency standard and can tell me more about the project? You can access the source code for the project here: http://www.arrl.org/files/file/QEX%20Binaries/2013/November_13/11x13_Kaune_PIC_Code.zip /Anders ___ 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. ___ ime-nuts mailing list -- time-nuts@febo.com o unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts nd 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 GPS to Fine Tune a Rubidium Frequency Standard.
Anders: I am a QEX subscriber and have that issue but I haven't built the circuit. The author referenced Brooks Shera as the basis for his work. He uses a Trimble Resolution T GPS for a PPS reference and an LPRO-101 Rubidium oscillator for the 10MHz. His circuit divides the 10MHz output from Rb by 100 and compares the phase of the 100kHz against the PPS. A PIC16 MCU is the controller and uses the phase data to control an external DAC to drive the Rb frequency control pin. There were a couple of other time & frequency related articles in 2013 if you decide to get the CD. Mike On 3/21/2014 09:20, Anders Time wrote: Does anyone have a copy of the QEX 2013 november article(Bill Kaune) "Using GPS to Fine Tune a Rubidium Frequency Standard"? I´m really interested in this subject, but I can´t find this magazine in Sweden. I have contacted QEX, but it is very difficult to buy back-issues. Have any one built this frequency standard and can tell me more about the project? You can access the source code for the project here: http://www.arrl.org/files/file/QEX%20Binaries/2013/November_13/11x13_Kaune_PIC_Code.zip /Anders ___ 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] FEI-5660 Rubidium Oscillator
All Rb's have XO's and with the exception of the HP5065C all Rb's influence long term stability only the only exception is the HP which uses a TC below 0.1.sec, and as Corbe demonstrated ADEV is controlled below 1 sec. by the cell. The same can not be said with other Rb's. Bert Kehren In a message dated 3/28/2014 7:33:45 A.M. Eastern Daylight Time, li...@rtty.us writes: Hi Crystals are susceptible to vibration. That’s pretty well documented. They have resonances in the mount structure. They have a 2G tip sensitivity. Audio when it “impacts” an oscillator induces vibration. If your noise source is a rocket engine, then the vibration is “non trivial”. You do indeed see phase noise on the oscillator from audio … Bob On Mar 27, 2014, at 11:42 PM, Tom Van Baak wrote: >> More seriously, I'm assuming you're advocating rock for the thermal mass >> and/or mechanical. What about a 100 pound box of sand? > > Mechanical. I figured a OCXO might be susceptible to microphonics, especially in a recording studio. But if it's down to the level of 1 lsb of the digital sampling, then no worries. > > Has anyone on the list ever measured this effect, even on a cheap crystal? > > /tvb > > ___ > 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] GPSDO simulation tool
On 26/03/14 22:42, Tom Van Baak wrote: Did some home-work on third-degree PLL parameters, so now I know why I failed, as I never tried to do it right. One thing that Tom's simulator isn't doing is calculating the parameters for the PID for you, or backwards what characteristics you will get. Cheers, Magnus Magnus, et al, Still hoping some of you process control & PID experts will contribute a couple lines of C code to the simulator. The gpsim1 ver=N parameter will select any one of many different algorithms. I believe no one algorithm is "correct"; the goal is simply to include as many as you can contribute so we can all play with them. Yes, now as the weekend finally reached me I can look at it again. I have looked at third degree PLLs again and if you know where you're poles should be going, then setting it up is trivial and stability can be guaranteed. Cheers, Magnus 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] HP 5065A with Patek Philippe analog clock coming up for sale
Thought I'd give a "heads up" concerning a nice HP 5065A that I will be offering for sale in the near future. It has the Patek Philippe analog clock and is in pretty good condition. Fully checked out and aligned! Plot against a Hydrogen Maser looks great and beats the original HP specs handily. Comes with a full 90 day warranty. Contact me off-list and I can provide the plot and some PIX to interested parties. SN prefix is 1320A and includes the power cord and rack ears. Price is $4150.00 which includes shipping in the CONUS. Cheers! Corby Dawson ___ 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] FEI-5660 Rubidium Oscillator
What about the other side of audio-phoolery: audio FFT? I'm thinking more along the lines of an ARRL FMT. > > From: Tom Van Baak >To: Discussion of precise time and frequency measurement >Sent: Thursday, March 27, 2014 6:10 PM >Subject: Re: [time-nuts] FEI-5660 Rubidium Oscillator > > >> Recently I happened across an eBay listing for an Antelope Audio Isochrome, >> a device that apparently packages an SRI-PRS10 rubidium oscillator and >> distribution amplifier in a box and sells to audiophiles for a price in the > >Bruce, > >There have been threads about this on time-nuts every few years. The consensus >is that audio companies that use atomic clocks are naive. It makes good >marketing, though. > >Then again, speaking from experience, many of us make the same mistake: first >thinking that precise time is the goal, then thinking that precise frequency >is what counts, and later thinking that stability is what really matters, and >only eventually realizing that all of these metrics are functions of tau, and >that tau ranges from MHz/microseconds to years. Phase noise plots along with >log-log ADEV plots start to tell the whole story. > >In the case of digital music, as far as I know, L(f) phase noise in the audio >band and ADEV(tau) frequency stability from microseconds to seconds is far >more important to the fidelity of digital recording and playback than absolute >SI-accurate frequency or long-term timekeeping. Consequently, most atomic >frequency standards are actually a poor choice as a sampling reference clock >-- because their jitter (short-term noise) is no where near as good as a >free-running, undisciplined, high-end OCXO. > >True, the PRS10 is a better choice than other cheap telecom rubidium's but >none of these comes close to the performance of a premium OCXO. For the >ultimate audio reference clock you want to avoid Rb, or GPSDO, or Cs for that >matter. Instead pick a 1e-12 or 1e-13 stable OCXO, strap it to a 100 pound >block of granite, and leave it alone. > >/tvb > > ___ 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] Sound impact Was FEI-5660 Rubidium Oscillator
Back in 1997 when working on a car project I saw several failures of AD595 Thermocouple converter chips due to sound. In all cases the bond wire to pin 8 of the CERDIP package failed, presumably due to resonance (I took the top of the chips to check) A blob of non acid cure RTV silicone rubber on the chip seemed to cure it. The box with the AD595s was mounted in the rear of the car between the exhaust plumes of two 20,000lb thrust re-heated jet engines so the sound level was quite high :-) The box is in the open wheel compartment seen here http://upload.wikimedia.org/wikipedia/commons/4/41/ThrustSSC_back.jpg Robert G8RPI. From: Bob Camp To: Tom Van Baak ; Discussion of precise time and frequency measurement Sent: Friday, 28 March 2014, 11:33 Subject: Re: [time-nuts] FEI-5660 Rubidium Oscillator Hi Crystals are susceptible to vibration. That’s pretty well documented. They have resonances in the mount structure. They have a 2G tip sensitivity. Audio when it “impacts” an oscillator induces vibration. If your noise source is a rocket engine, then the vibration is “non trivial”. You do indeed see phase noise on the oscillator from audio … Bob On Mar 27, 2014, at 11:42 PM, Tom Van Baak wrote: >> More seriously, I'm assuming you're advocating rock for the thermal mass >> and/or mechanical. What about a 100 pound box of sand? > > Mechanical. I figured a OCXO might be susceptible to microphonics, especially > in a recording studio. But if it's down to the level of 1 lsb of the digital > sampling, then no worries. > > Has anyone on the list ever measured this effect, even on a cheap crystal? > > /tvb > > ___ > 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] FEI-5660 Rubidium Oscillator
Hi Crystals are susceptible to vibration. That’s pretty well documented. They have resonances in the mount structure. They have a 2G tip sensitivity. Audio when it “impacts” an oscillator induces vibration. If your noise source is a rocket engine, then the vibration is “non trivial”. You do indeed see phase noise on the oscillator from audio … Bob On Mar 27, 2014, at 11:42 PM, Tom Van Baak wrote: >> More seriously, I'm assuming you're advocating rock for the thermal mass >> and/or mechanical. What about a 100 pound box of sand? > > Mechanical. I figured a OCXO might be susceptible to microphonics, especially > in a recording studio. But if it's down to the level of 1 lsb of the digital > sampling, then no worries. > > Has anyone on the list ever measured this effect, even on a cheap crystal? > > /tvb > > ___ > 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.