Re: [time-nuts] Reverse-engineering LPRO
Hi I think the truth of the matter is that these gizmos have been cheap enough (and complicated enough) that they don't get repaired a lot. Certainly the VCXO gets tweaked, and there are a couple of caps that explode / get replaced. Past that either they don't break, or they get replaced. Bob On Feb 18, 2013, at 1:52 AM, Magnus Danielson mag...@rubidium.dyndns.org wrote: On 02/18/2013 04:34 AM, Bob Camp wrote: Hi There *must* be an alignment procedure that sets these things up. They didn't put all those test points in there just for the fun of it. I'm sure that these units would work a bit better if we knew how to tweak them back to the original alignment specs. There is a document which gives some of it, but doing a reverse-engineering project is primarily so it can be properly understood for trimming and repair purposes in my mind. There is a 2x4 connectors which can connect in a test-rig while the 2x5 connector is hooked up. There is two different connectors inside that also should be relevant, and then is at least one jumper field which would be good to know how it works. Considering how common these are, I was surprised that more effort had not gone into them, compared to how the group (and hams) tend to deal with all this. Cheers, Magnus Bob On Feb 16, 2013, at 6:10 PM, Magnus Danielsonmag...@rubidium.dyndns.org wrote: Fellow time-nuts, Considering that LPROs is pretty popular, I am a bit surprised that I have not seen any major reverse-engineering effort on the LPROs. I have the self-compiled LPRO service document, which collects parts of schematics from patents, but still. My main reasons for asking is that I want to get a little better overview of how they work, how I can tune them up and what signals is available where. Naturally, always figuring if there is some interesting tweaks to be done. LRPO is just a traditional analogue rubidium, in compact format, sure, but never the less. I have noticed that different FPGAs have been used over time. Curious about the various jumpers and connectors in it. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ 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] Reverse-engineering LPRO
That was the intent. Break/toss / we get to buy'em after a pile stacks up. From what I have run into peaking may or may not be the right answer is my only real addition to the discussion. The RF oscillator on the bulb peak if even tunable. The hamonic multiplier. Peaking that could easily lead to the wrong multiple killing the unit. Not really but hard to find the right multiple without a spectrum analyzer. Its stuff like that which introduces risk. But hey when they are dead/weak to begin with all is fair. Thats how I learned at $25 a piece. Regards Paul On Mon, Feb 18, 2013 at 8:20 AM, Bob Camp li...@rtty.us wrote: Hi I think the truth of the matter is that these gizmos have been cheap enough (and complicated enough) that they don't get repaired a lot. Certainly the VCXO gets tweaked, and there are a couple of caps that explode / get replaced. Past that either they don't break, or they get replaced. Bob On Feb 18, 2013, at 1:52 AM, Magnus Danielson mag...@rubidium.dyndns.org wrote: On 02/18/2013 04:34 AM, Bob Camp wrote: Hi There *must* be an alignment procedure that sets these things up. They didn't put all those test points in there just for the fun of it. I'm sure that these units would work a bit better if we knew how to tweak them back to the original alignment specs. There is a document which gives some of it, but doing a reverse-engineering project is primarily so it can be properly understood for trimming and repair purposes in my mind. There is a 2x4 connectors which can connect in a test-rig while the 2x5 connector is hooked up. There is two different connectors inside that also should be relevant, and then is at least one jumper field which would be good to know how it works. Considering how common these are, I was surprised that more effort had not gone into them, compared to how the group (and hams) tend to deal with all this. Cheers, Magnus Bob On Feb 16, 2013, at 6:10 PM, Magnus Danielson mag...@rubidium.dyndns.org wrote: Fellow time-nuts, Considering that LPROs is pretty popular, I am a bit surprised that I have not seen any major reverse-engineering effort on the LPROs. I have the self-compiled LPRO service document, which collects parts of schematics from patents, but still. My main reasons for asking is that I want to get a little better overview of how they work, how I can tune them up and what signals is available where. Naturally, always figuring if there is some interesting tweaks to be done. LRPO is just a traditional analogue rubidium, in compact format, sure, but never the less. I have noticed that different FPGAs have been used over time. Curious about the various jumpers and connectors in it. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ 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] FRK-L Rubidium
Bob, Just wanted to let you know your advice to let the FRK run for a while was spot on. The lock voltage is down to 9.2 volts. I was able to get my thunderbolt with the bad oscillator oven working by heating the oscillator with a power resistor. After it locked I could see on an oscilloscope that it and the FRK were both exactly the same. I plan on putting the thunderbolt oscillator in an oven I'm building that will have proportional control and see how that works. Thanks for the help. Garren -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob Camp Sent: Saturday, February 09, 2013 10:14 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] FRK-L Rubidium Hi Let it run for a couple of days. If it's still up at 11V, I'd tweak it down a bit. Bob On Feb 9, 2013, at 12:38 PM, Garren Davis garren.da...@qlogic.com wrote: Found my problem with the FRK. R31 on the Osc board was burned and open. This was caused by a shorted C16. Replaced and it is now locked. The lock voltage is 12.7v. Is this good or should it be lower? Garren On Feb 9, 2013, at 6:10 AM, Bob Camp li...@rtty.us wrote: Hi How old is the FRK? Does it look like it's been run without a heat sink for very long? They tend to get flaky if run for a while (many months) without heat sinking. There's nothing mysterious about it. The MTBF of the parts gets noticeably worse as the unit heats up. Bob On Feb 9, 2013, at 1:09 AM, Garren Davis garren.da...@qlogic.com wrote: Well for some reason the 10 Mhz stopped working on the FRK. Don't know why. Started up the thunderbolt. It acquired satellites but then the DAC voltage went to -5 volts. It's been there for an hour. Will this change after the unit stabilizes? Going to bed. Will check it tomorrow. Garren On Feb 8, 2013, at 8:25 PM, Ed Palmer ed_pal...@sasktel.net wrote: Hi Garren, I suggest that you get the Thunderbolt working first. Without a known 10 MHz source to compare to, you're flying blind. Once the Tbolt is running, you should be able to check the frequency of the FRK by feeding both into your scope. Trigger on the Tbolt and watch what the FRK does. You should see the trace scrolling in one direction, then slow down, then stop, then scroll the other direction. The 'stop' point is at 10 MHz. The frequency sweeps a total of 20-30 Hz so it's easy to see. If you don't see the 'stop' point, the FRK isn't getting to 10 MHz. Now use the best frequency counter you've got to measure the Tbolt. Regardless of the calibration of your counter, the number your counter gives you becomes your 'new' 10 MHz. Now measure the FRK to see if it's running fast or slow. You should check the temperature of the lamp. It's easy to get at by removing the cover in the center of the heat sink. Probably best to remove the cover and then power down before you go poking around inside! The temperature of the cavity is also important, but getting to it is more of a hassle - don't go there if you don't have to. Of course, check for the normal things like internal power supply voltages, ripple, current drain (both initial and steady-state), etc. Regarding your second message, yes, the adjustment under the heat sink near the edge is the C-field. That won't help you at this point. The adjustment in the center of one side is the VCO. You could try adjusting it, but like I said, you're flying blind at this point. You won't know if you're adjusting closer to 10 MHz or further away. Good luck, Ed On 2/8/2013 6:12 PM, Garren Davis wrote: Been lurking on the list for a while and finally started playing with a FRK-L rubidium frequency standard. I've had this thing for a while and decided to power it up and see what it would do. I do not get a lock. What I see is the lamp voltage at 8.54 volts which I think is good but the xtal control voltage swings from 2 volts to 15 volts and back to 2 volts and keeps cycling like that. I don't have a good frequency counter but I have a 3 Ghz 40 G/sample scope and it shows that the 10 MHz signal is there. I just don't know how accurate it is. Has anyone seen a problem like this? Can anyone point me to a place to start debugging this? I have the schematics and test tools. I am a test engineer so I'm not afraid to poke around in the guts of this thing. Hopefully I can get this thing running. I also have a thunderbolt that I'll get running this weekend. I don't know how deep I'll get into this time-nuts thing but I have this nice scope and a Wavecrest sitting in my garage a n d I'd lik e to put them to use. Any help would be appreciated. Garren ___ 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] OCXO DC Current Question
I know that when making AC measurements on various OCXOs of the same type, you have to expect wide variations in the results. e.g. TVB's Allan Deviation measurements on a selection of 10811A oscillators at http://www.leapsecond.com/pages/z3801a-osc . But what about DC current measurements? How much variability should you expect? I recently bought 4 MTI 260 oscillators with thoughts of doing some 3-cornered hat experiments. I thought I'd use the best 3 of 4. One test I always do on an OCXO is to measure the DC current drain as it warms up. Nothing radical - I have an HP 6622A GPIB-equipped linear power supply. I just do GPIB queries as fast as I can and log the results. I get about 6 readings per second. More than enough for my needs. This time, I was surprised by the results of this test. The attached picture shows why. I've offset the traces horizontally and vertically for clarity so I deleted the axes. The horizontal lines are 200 ma apart, but the position of each trace is arbitrary. All four oscillators start at a current-limited value of ~1 Amp and have a steady-state current drain of ~230 mA. The length of the graph is ~20 minutes. Although the family resemblance is obvious, I was surprised by the different noise levels. I let one of the noisy units run for a day to see if it would settle down, but there was no improvement. Are these results reasonable, or do I have one oscillator with a good oven (blue trace), one marginal (purple), and two rather poor ones (red and green)? I'm thinking that the noise on the oven could affect the Allan Deviation due to either or both of the thermal inconsistencies or varying load on the power supply. Any thoughts? Thanks, Ed attachment: image001.png___ 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] Allan deviation and modified Allan deviation
Ok I've been plotting my oscillators for years using Allan Deviation. That way all my records can be compared easily. Is there any advantage to using Modified Allan Deviation? It seems to give a better stability plot but that just seems to be cheating! If I plot both ways what do the differences mean? Thanks, Corby ___ 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] OCXO DC Current Question
It's not really noise, the feedback loop is marginally stable. What you are seeing is how the stability changes due to minor differences in the parts used in the loop, and the thermal masses and insulation of the oven. -Chuck Harris Ed Palmer wrote: I know that when making AC measurements on various OCXOs of the same type, you have to expect wide variations in the results. e.g. TVB's Allan Deviation measurements on a selection of 10811A oscillators at http://www.leapsecond.com/pages/z3801a-osc . But what about DC current measurements? How much variability should you expect? I recently bought 4 MTI 260 oscillators with thoughts of doing some 3-cornered hat experiments. I thought I'd use the best 3 of 4. One test I always do on an OCXO is to measure the DC current drain as it warms up. Nothing radical - I have an HP 6622A GPIB-equipped linear power supply. I just do GPIB queries as fast as I can and log the results. I get about 6 readings per second. More than enough for my needs. This time, I was surprised by the results of this test. The attached picture shows why. I've offset the traces horizontally and vertically for clarity so I deleted the axes. The horizontal lines are 200 ma apart, but the position of each trace is arbitrary. All four oscillators start at a current-limited value of ~1 Amp and have a steady-state current drain of ~230 mA. The length of the graph is ~20 minutes. Although the family resemblance is obvious, I was surprised by the different noise levels. I let one of the noisy units run for a day to see if it would settle down, but there was no improvement. Are these results reasonable, or do I have one oscillator with a good oven (blue trace), one marginal (purple), and two rather poor ones (red and green)? I'm thinking that the noise on the oven could affect the Allan Deviation due to either or both of the thermal inconsistencies or varying load on the power supply. Any thoughts? Thanks, 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] OCXO DC Current Question
Hi Like any control loop, gain, bandwidth and noise are all related. In a DOCXO you have two control loops and they do interact. That said, there's nothing grossly wrong with the four OCXO's. The noisy parts have a bit more gain in the controller. The quiet parts have a bit less gain. The easy way to see this is the ringing after the current changes. Without ADEV numbers there's no way to know which one is good (or better) and which one is bad (or worse). The noisy parts may be responding to the ambient temperature rumble (thus correcting for it) and the quiet ones may be ignoring it (allowing it to hit the crystal). It's also possible that the noisy ones have an electrical issue in the loop that generates the noise. If all the ovens started from the same temperature, there is a variance in the oven set points. Some take longer to warm up than others. You don't mention if they started the same, so that may or may not be significant. To further complicate things, in a double oven, you can have a noisy outer oven that gets suppressed by the inner oven. Are your specific 260's double ovens? No way to be sure without tearing one open. The second step in the current plot could be an inner oven cutting back. Bob On Feb 18, 2013, at 2:40 PM, Ed Palmer ed_pal...@sasktel.net wrote: I know that when making AC measurements on various OCXOs of the same type, you have to expect wide variations in the results. e.g. TVB's Allan Deviation measurements on a selection of 10811A oscillators at http://www.leapsecond.com/pages/z3801a-osc . But what about DC current measurements? How much variability should you expect? I recently bought 4 MTI 260 oscillators with thoughts of doing some 3-cornered hat experiments. I thought I'd use the best 3 of 4. One test I always do on an OCXO is to measure the DC current drain as it warms up. Nothing radical - I have an HP 6622A GPIB-equipped linear power supply. I just do GPIB queries as fast as I can and log the results. I get about 6 readings per second. More than enough for my needs. This time, I was surprised by the results of this test. The attached picture shows why. I've offset the traces horizontally and vertically for clarity so I deleted the axes. The horizontal lines are 200 ma apart, but the position of each trace is arbitrary. All four oscillators start at a current-limited value of ~1 Amp and have a steady-state current drain of ~230 mA. The length of the graph is ~20 minutes. Although the family resemblance is obvious, I was surprised by the different noise levels. I let one of the noisy units run for a day to see if it would settle down, but there was no improvement. Are these results reasonable, or do I have one oscillator with a good oven (blue trace), one marginal (purple), and two rather poor ones (red and green)? I'm thinking that the noise on the oven could affect the Allan Deviation due to either or both of the thermal inconsistencies or varying load on the power supply. Any thoughts? Thanks, Ed image001.png___ 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] FE-5680A DDS Board/PIC Code
I'm new to the time-nuts community, so I simply start with a short info on how I got into this situation :) (skip forward to ONTOPIC if not interested) Not long ago, I decided to build a reasonably good frequency counter for my personal use and maybe if the result is simple and elegant, I'll publish the details so that everybody can build one ... It was clear to me, that it had to be able to count up to at least 1GHz and thus show at least nine, better ten significant digits, so a precise time base is required. After some online searches and investigations, my best options seemed to get a very stable oscillator and a high quality time reference to sync with, which in turn brought me to the idea to use a cheap rubidium normal and somehow tune/measure/sync it via GPS or DCF-77/MSF-60. Reading a lot of documentation and blogs from all over the world (sometimes in translation :) shed some light on the rubidium normal requirements, which I defined as: - has to have a 10MHz output not just the 1PPS - has to be programmable (i.e. can be tuned) - must be cheap I quickly found two different RB standard models, readily available on ebay for a reasonable price, namely the Efratom FRS-C and the FEI FE-5680A. I finally decided to go with the FE-5680A, mainly because I liked the package. A seller was quickly found offering something titled: 'FE-5680A Rubidium Atomic Frequency Standard Oscillator Transceivers 10Mhz Out' 'Programmable from 1Hz to 20MHz' Little did I know what that actually meant ... When the units (I ordered two of them) arrived, I couldn't wait to test if they actually work and get a lock, so I quickly wired them up (according to the pinout) and provided them with the advised 15V at up to 2A each. To my astonishment, they heated up rather quickly and got a lock in a little under two minutes, so I happily got my scope out to check the 10MHz signal, just to find that there is no such signal available on the 9pin D-sub connector. Measuring pins against ground (pin 2) and 15Vx (pin 1) I figured that neither pin 7 (10MHz) nor pin 8/9 (the rs232 interface for programming) was connected. and to my great disappointment, pin 6 (1PPS) didn't output much either (I later discovered that this was due to a defective unit, which is now being replaced) After contacting the seller, I opened up the units to investigate my options (and of course, because I wanted to take a look inside :), which in turn led to a number of high resolution scans and photos of all the bits and pieces. A (this time) more thorough search on the internet resulted in a deeper understanding of the various options the FE-5680A can have (or usually doesn't have) and the inner workings of the different FE-5680A models (of course, all labeled FE-5680A :) The DDS board, which actually can be programmed to output certain frequencies derived from the 'locked' 1:136 frequency of the rubidium 6.8GHz transition, caught my attention, as it has both, the '10Mhz' output and the programming interface, so I decided to analyze it further ... ONTOPIC The central part on this specific DDS board [1] is the AD9830A a Direct Digital Synthesizer (DDS) which basically produces a sine wave at a well defined multiple and phase of a given reference frequency. Besides some other components, this board also includes an RS-232C line driver (Sipex SP233A) a PIC16F84 microcontroller and two 74HC595 8bit shift registers, with buffered outputs. I read somewhere, that the blue buttons on that DDS board can be used to adjust the output frequency, this should be avoided, mainly because every button press is an update and will cause a write to the EEPROM data wearing it out. Now as I've played with PIC microcontrollers for a long time, I wanted to know what this specific controller is doing and how I could use that for my purposes ... The chip was quickly removed and the program as well as configuration memory retrieved (luckily FEI didn't utilize the code/data protection) and together with high resolution scans and photos, a documented and verified assembler listing [2] reverse engineered. Here are the (IMHO) quite interesting findings: - both FREQx registers can be adjusted - the PHASE0 register can be adjusted - none of the changes is permanent, unless you explicitely save the settings - there are only a few commands, without any plausibility checks and/or protection - and yes, the buttons increment/decrement the FREQx settings and trigger a write to the EEPROM after every update. - the serial interface is done in software - the DDS control words are shifted into the 74HC595, buffered and written ; SCR STATUS ; R=50255057.012932Hz F=2ABB5040 ; OK ; ; F=CRFREQxREG (set divider) ; OK ; ; G=CRPHASE (set phase register) ; OK ; ; R=YYCR RUBIDIUM (set calibrated freq) ; OK ; ;
Re: [time-nuts] FE-5680A DDS Board/PIC Code
Herbert Thanks for the assembly listing. Someone else on time-nuts had done quite the job of reverse engineering the schematics and other information. Seems like the two of you could collaborate. Sorry do not recall the name. Welcome to time-nuts. Regards Paul WB8TSL On Mon, Feb 18, 2013 at 4:32 PM, Herbert Poetzl herb...@13thfloor.atwrote: I'm new to the time-nuts community, so I simply start with a short info on how I got into this situation :) (skip forward to ONTOPIC if not interested) Not long ago, I decided to build a reasonably good frequency counter for my personal use and maybe if the result is simple and elegant, I'll publish the details so that everybody can build one ... It was clear to me, that it had to be able to count up to at least 1GHz and thus show at least nine, better ten significant digits, so a precise time base is required. After some online searches and investigations, my best options seemed to get a very stable oscillator and a high quality time reference to sync with, which in turn brought me to the idea to use a cheap rubidium normal and somehow tune/measure/sync it via GPS or DCF-77/MSF-60. Reading a lot of documentation and blogs from all over the world (sometimes in translation :) shed some light on the rubidium normal requirements, which I defined as: - has to have a 10MHz output not just the 1PPS - has to be programmable (i.e. can be tuned) - must be cheap I quickly found two different RB standard models, readily available on ebay for a reasonable price, namely the Efratom FRS-C and the FEI FE-5680A. I finally decided to go with the FE-5680A, mainly because I liked the package. A seller was quickly found offering something titled: 'FE-5680A Rubidium Atomic Frequency Standard Oscillator Transceivers 10Mhz Out' 'Programmable from 1Hz to 20MHz' Little did I know what that actually meant ... When the units (I ordered two of them) arrived, I couldn't wait to test if they actually work and get a lock, so I quickly wired them up (according to the pinout) and provided them with the advised 15V at up to 2A each. To my astonishment, they heated up rather quickly and got a lock in a little under two minutes, so I happily got my scope out to check the 10MHz signal, just to find that there is no such signal available on the 9pin D-sub connector. Measuring pins against ground (pin 2) and 15Vx (pin 1) I figured that neither pin 7 (10MHz) nor pin 8/9 (the rs232 interface for programming) was connected. and to my great disappointment, pin 6 (1PPS) didn't output much either (I later discovered that this was due to a defective unit, which is now being replaced) After contacting the seller, I opened up the units to investigate my options (and of course, because I wanted to take a look inside :), which in turn led to a number of high resolution scans and photos of all the bits and pieces. A (this time) more thorough search on the internet resulted in a deeper understanding of the various options the FE-5680A can have (or usually doesn't have) and the inner workings of the different FE-5680A models (of course, all labeled FE-5680A :) The DDS board, which actually can be programmed to output certain frequencies derived from the 'locked' 1:136 frequency of the rubidium 6.8GHz transition, caught my attention, as it has both, the '10Mhz' output and the programming interface, so I decided to analyze it further ... ONTOPIC The central part on this specific DDS board [1] is the AD9830A a Direct Digital Synthesizer (DDS) which basically produces a sine wave at a well defined multiple and phase of a given reference frequency. Besides some other components, this board also includes an RS-232C line driver (Sipex SP233A) a PIC16F84 microcontroller and two 74HC595 8bit shift registers, with buffered outputs. I read somewhere, that the blue buttons on that DDS board can be used to adjust the output frequency, this should be avoided, mainly because every button press is an update and will cause a write to the EEPROM data wearing it out. Now as I've played with PIC microcontrollers for a long time, I wanted to know what this specific controller is doing and how I could use that for my purposes ... The chip was quickly removed and the program as well as configuration memory retrieved (luckily FEI didn't utilize the code/data protection) and together with high resolution scans and photos, a documented and verified assembler listing [2] reverse engineered. Here are the (IMHO) quite interesting findings: - both FREQx registers can be adjusted - the PHASE0 register can be adjusted - none of the changes is permanent, unless you explicitely save the settings - there are only a few commands, without any plausibility checks and/or protection - and yes, the buttons increment/decrement the FREQx settings and trigger a write to the EEPROM after every update. - the serial
Re: [time-nuts] FE-5680A DDS Board/PIC Code
Hi There's quite a bit less in the PIC code than I would have expected. If that's everything that's there, the PIC does very little heavy lifting. Nice job on the dis-assembly. Many of the 10 MHz out FE Rb's are actually the 1 pps version that has been converted to 10 MHz after the fact. The 10 MHz is not very clean on the FE's in any case. Bob On Feb 18, 2013, at 4:32 PM, Herbert Poetzl herb...@13thfloor.at wrote: I'm new to the time-nuts community, so I simply start with a short info on how I got into this situation :) (skip forward to ONTOPIC if not interested) Not long ago, I decided to build a reasonably good frequency counter for my personal use and maybe if the result is simple and elegant, I'll publish the details so that everybody can build one ... It was clear to me, that it had to be able to count up to at least 1GHz and thus show at least nine, better ten significant digits, so a precise time base is required. After some online searches and investigations, my best options seemed to get a very stable oscillator and a high quality time reference to sync with, which in turn brought me to the idea to use a cheap rubidium normal and somehow tune/measure/sync it via GPS or DCF-77/MSF-60. Reading a lot of documentation and blogs from all over the world (sometimes in translation :) shed some light on the rubidium normal requirements, which I defined as: - has to have a 10MHz output not just the 1PPS - has to be programmable (i.e. can be tuned) - must be cheap I quickly found two different RB standard models, readily available on ebay for a reasonable price, namely the Efratom FRS-C and the FEI FE-5680A. I finally decided to go with the FE-5680A, mainly because I liked the package. A seller was quickly found offering something titled: 'FE-5680A Rubidium Atomic Frequency Standard Oscillator Transceivers 10Mhz Out' 'Programmable from 1Hz to 20MHz' Little did I know what that actually meant ... When the units (I ordered two of them) arrived, I couldn't wait to test if they actually work and get a lock, so I quickly wired them up (according to the pinout) and provided them with the advised 15V at up to 2A each. To my astonishment, they heated up rather quickly and got a lock in a little under two minutes, so I happily got my scope out to check the 10MHz signal, just to find that there is no such signal available on the 9pin D-sub connector. Measuring pins against ground (pin 2) and 15Vx (pin 1) I figured that neither pin 7 (10MHz) nor pin 8/9 (the rs232 interface for programming) was connected. and to my great disappointment, pin 6 (1PPS) didn't output much either (I later discovered that this was due to a defective unit, which is now being replaced) After contacting the seller, I opened up the units to investigate my options (and of course, because I wanted to take a look inside :), which in turn led to a number of high resolution scans and photos of all the bits and pieces. A (this time) more thorough search on the internet resulted in a deeper understanding of the various options the FE-5680A can have (or usually doesn't have) and the inner workings of the different FE-5680A models (of course, all labeled FE-5680A :) The DDS board, which actually can be programmed to output certain frequencies derived from the 'locked' 1:136 frequency of the rubidium 6.8GHz transition, caught my attention, as it has both, the '10Mhz' output and the programming interface, so I decided to analyze it further ... ONTOPIC The central part on this specific DDS board [1] is the AD9830A a Direct Digital Synthesizer (DDS) which basically produces a sine wave at a well defined multiple and phase of a given reference frequency. Besides some other components, this board also includes an RS-232C line driver (Sipex SP233A) a PIC16F84 microcontroller and two 74HC595 8bit shift registers, with buffered outputs. I read somewhere, that the blue buttons on that DDS board can be used to adjust the output frequency, this should be avoided, mainly because every button press is an update and will cause a write to the EEPROM data wearing it out. Now as I've played with PIC microcontrollers for a long time, I wanted to know what this specific controller is doing and how I could use that for my purposes ... The chip was quickly removed and the program as well as configuration memory retrieved (luckily FEI didn't utilize the code/data protection) and together with high resolution scans and photos, a documented and verified assembler listing [2] reverse engineered. Here are the (IMHO) quite interesting findings: - both FREQx registers can be adjusted - the PHASE0 register can be adjusted - none of the changes is permanent, unless you explicitely save the settings - there are only a few commands, without any plausibility checks and/or protection - and yes, the buttons
Re: [time-nuts] OCXO DC Current Question
Hi Bob, On 2/18/2013 2:42 PM, Bob Camp wrote: Hi Like any control loop, gain, bandwidth and noise are all related. In a DOCXO you have two control loops and they do interact. That said, there's nothing grossly wrong with the four OCXO's. The noisy parts have a bit more gain in the controller. The quiet parts have a bit less gain. The easy way to see this is the ringing after the current changes. Yes, when I zoom in on the ringing after the first step change, they all show a period of ~9 seconds. The blue trace (the quiet one) has a nice smooth damped sine wave while the other ones have varying amounts of noise superimposed on the sine wave. The amplitude of the ringing on the noisy ones is greater than the amplitude of the quiet one. In one case, more than twice as big. Without ADEV numbers there's no way to know which one is good (or better) and which one is bad (or worse). The noisy parts may be responding to the ambient temperature rumble (thus correcting for it) and the quiet ones may be ignoring it (allowing it to hit the crystal). I hadn't thought of that possibility. Thanks for that! It's also possible that the noisy ones have an electrical issue in the loop that generates the noise. I was thinking of maybe a dead filter capacitor - hence the noise. If all the ovens started from the same temperature, there is a variance in the oven set points. Some take longer to warm up than others. You don't mention if they started the same, so that may or may not be significant. They all started at the same temperature. Any apparent difference in warmup time is mostly due to the arbitrary offset of the traces. The offset was just so you could see all four traces clearly. However, isn't it also likely that each oscillator has had it's oven tweaked to match that particular crystal? To further complicate things, in a double oven, you can have a noisy outer oven that gets suppressed by the inner oven. Are your specific 260's double ovens? No way to be sure without tearing one open. The second step in the current plot could be an inner oven cutting back. I wondered about that second step. The period of the ringing on the second step is about 1 sec. longer than the ringing on the first step so it's apparently a different circuit. The 260 series datasheet does NOT say anything about it being a double oven. They talk about customizing the unit to suit the customer, but that seems a bit extreme. By the way, I purchased these oscillators from our favorite auction site. If anyone's interested, the 260 series includes both AT and SC crystals. Since these start out ~150 Hz low, they appear to be SC cut. The output is a 5 MHz sine wave @ ~+7 dBm into 50 ohms. They work fine with a 12V power supply. They have no mechanical frequency adjustment (unless it's under a suspicious spot of solder on the case) but my 4 were all adjustable to 5 MHz via EFC. They were apparently removed from Z3811 GPS receivers. They each have a sticker on the side that says Z3811-80010. There doesn't seem to be much info available on the Z3811. I have no relationship to the vendor - just a customer. So it sounds like the proper thing to do is file this information and carry on. After making some Allan Deviation measurements, review everything to see how, or if, oven 'noise' correlates to Allan Deviation results. Thanks Bob, Ed Bob On Feb 18, 2013, at 2:40 PM, Ed Palmer ed_pal...@sasktel.net wrote: I know that when making AC measurements on various OCXOs of the same type, you have to expect wide variations in the results. e.g. TVB's Allan Deviation measurements on a selection of 10811A oscillators at http://www.leapsecond.com/pages/z3801a-osc . But what about DC current measurements? How much variability should you expect? I recently bought 4 MTI 260 oscillators with thoughts of doing some 3-cornered hat experiments. I thought I'd use the best 3 of 4. One test I always do on an OCXO is to measure the DC current drain as it warms up. Nothing radical - I have an HP 6622A GPIB-equipped linear power supply. I just do GPIB queries as fast as I can and log the results. I get about 6 readings per second. More than enough for my needs. This time, I was surprised by the results of this test. The attached picture shows why. I've offset the traces horizontally and vertically for clarity so I deleted the axes. The horizontal lines are 200 ma apart, but the position of each trace is arbitrary. All four oscillators start at a current-limited value of ~1 Amp and have a steady-state current drain of ~230 mA. The length of the graph is ~20 minutes. Although the family resemblance is obvious, I was surprised by the different noise levels. I let one of the noisy units run for a day to see if it would settle down, but there was no improvement. Are these results reasonable, or do I have one oscillator with a good oven (blue trace), one marginal
Re: [time-nuts] FE-5680A DDS Board/PIC Code
In a message dated 18/02/2013 22:45:12 GMT Standard Time, paulsw...@gmail.com writes: Herbert Thanks for the assembly listing. Someone else on time-nuts had done quite the job of reverse engineering the schematics and other information. Seems like the two of you could collaborate. Sorry do not recall the name. Welcome to time-nuts. Regards Paul WB8TSL Was just thinking the same thing so checked through my archives. That was Elio, _eliocor@gmail.com_ (mailto:elio...@gmail.com) , messages posted here about a year ago. The messages will be in the list archives anyway but below is the text of two messages I saved. Regards Nigel GM8PZR -- From: elio...@gmail.com Reply-to: time-nuts@febo.com To: time-nuts@febo.com Sent: 15/02/2012 01:31:32 GMT Standard Time Subj: [time-nuts] FE-5680A Schematics (v0.1) at the following address: http://www.rhodiatoce.com/pics/time-nuts/FE-5680A/FE-5680A_schematics_v0.1.p df you will find the 0.1 release of the FE-5680A schematics. New additions: - pinout of the unpopulated (24 pin) connector (J9) behind the DB9 - connections between CPU/MAX3232 and the *TWO* serial ports!!! - component values of the 10MHz filter + option on PCB to output a square 10MHz wave on DB9 - connections between CPU and MAX1246 (A/D converter) - connections between XC9572 and MAX392 (quad analog switch) - unknown pins marked as '?' As you can see, it seems FE-5680A fully supports 2 serial ports: one on DB9 and the other one on the unpopulated connector (J9) behind DB9. Any comments/suggestions are welcome. . ciao _Elio. _ From: elio...@gmail.com Reply-to: time-nuts@febo.com To: time-nuts@febo.com Sent: 24/02/2012 01:03:56 GMT Standard Time Subj: [time-nuts] FE-5680A Schematics and scans Thanks to Ignacio (EB4APL) and the generosity of Mike Harrison, today I received a PCB of a disassembled FE5680A. I provided to make some scans of the board at 2400DPI resolution: the picture size is about 7700x11500 pixel (9MB) Top face (with and without ICs): http://www.rhodiatoce.com/pics/time-nuts/FE-5680A/FE-5680A_Top001.jpg http://www.rhodiatoce.com/pics/time-nuts/FE-5680A/FE-5680A_Top001_noIC.jpg Bottom face (with and without ICs): http://www.rhodiatoce.com/pics/time-nuts/FE-5680A/FE-5680A_Bottom001.jpg http://www.rhodiatoce.com/pics/time-nuts/FE-5680A/FE-5680A_Bottom001_noIC.jp g Being able to remove the ICs, I was able to correct some flaws in the previous schematics: http://www.rhodiatoce.com/pics/time-nuts/FE-5680A/FE-5680A_schematics_v0.2.p df During the next week I will continue to write down the logical part of the circuit and I hope will be able to dump the 8032 firmware _ Elio. _ ___ 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] Allan deviation and modified Allan deviation
I often plot both ADEV and MDEV, too. The difference between them indicates the amount of white phase noise there is in the measurement (the sum of DUT and REF and phase meter). You'll see for some standards, especially at longer tau, there is little or no difference. Right, MDEV is almost always less, since it artificially removes noise. Of course the noise is still there in the electrons, but it is not reported by this statistic. However, the sometimes legitimate reason for doing this is two-fold: First, an MDEV plot allows one to distinguish white from flicker phase noise types; something plain ADEV cannot do (both noise types show up as slope -1 with ADEV). As such, MDEV is a more powerful noise diagnostic than ADEV. But you can't necessarily treat the numbers as true, live performance. In order for MDEV to do its magic it must (mathematically) remove noise that you know is there. Second, there are some cases where the user plans to use the oscillator in a system that removes white noise by averaging against an equal or better standard. In this case it's nice to know ahead of time how much white noise there is to remove; so using MDEV is more informative than ADEV. For example, if you plan to compare two cesium time standards by collecting long-term data, then post-averaging, and plotting time stability once an hour or day, then MDEV is fair game. But if you plan to use the standard for any sort of real-time system then ADEV comes closer to representing the actual frequency stability that you will see. MDEV tells you how little instability you would have left after you squeeze out all the white noise. Every orange has juice inside, but to measure juice or pulp you destroy the original orange. Note a similar thing happens with ADEV and HDEV. If you plan to use an oscillator in a system that methodically removes linear frequency drift (like a smart GPSDO) then HDEV is a better (cheaper) indicator than ADEV. In summary, use the measurement statistic (and bandwidth) in the lab that best matches how the oscillator will actually be used in real life. I too would like to compare records made over many years. One problem is that phase meters can have different bandwidths and so, especially at short term, it's hard to know how much of the reported [in]stability is due to the DUT or REF or the filtering before, in, or after the phase detector itself. Most meters have a tau- or noise- dependent bias. /tvb (iPhone4) SF On Feb 18, 2013, at 11:59 AM, cdel...@juno.com wrote: Ok I've been plotting my oscillators for years using Allan Deviation. That way all my records can be compared easily. Is there any advantage to using Modified Allan Deviation? It seems to give a better stability plot but that just seems to be cheating! If I plot both ways what do the differences mean? Thanks, Corby ___ 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] OCXO DC Current Question
Hi The -Z3811 is indeed a part out of a HP GPSDO. HP is a big enough customer that the part they get *may* have little relation to the standard part. If they all started out at the same temperature, then the noisy ones finish warmup quicker than the quiet ones. Take a look at when the final glitch happens in the warmup process. It's definitely happening earlier on the noisy parts. If warmup finishes quicker - the part is running at a lower temperature. That of course is only the time between the cutback from full current to the glitch. It may not mean it's running cooler. Bob On Feb 18, 2013, at 5:32 PM, Ed Palmer ed_pal...@sasktel.net wrote: Hi Bob, On 2/18/2013 2:42 PM, Bob Camp wrote: Hi Like any control loop, gain, bandwidth and noise are all related. In a DOCXO you have two control loops and they do interact. That said, there's nothing grossly wrong with the four OCXO's. The noisy parts have a bit more gain in the controller. The quiet parts have a bit less gain. The easy way to see this is the ringing after the current changes. Yes, when I zoom in on the ringing after the first step change, they all show a period of ~9 seconds. The blue trace (the quiet one) has a nice smooth damped sine wave while the other ones have varying amounts of noise superimposed on the sine wave. The amplitude of the ringing on the noisy ones is greater than the amplitude of the quiet one. In one case, more than twice as big. Without ADEV numbers there's no way to know which one is good (or better) and which one is bad (or worse). The noisy parts may be responding to the ambient temperature rumble (thus correcting for it) and the quiet ones may be ignoring it (allowing it to hit the crystal). I hadn't thought of that possibility. Thanks for that! It's also possible that the noisy ones have an electrical issue in the loop that generates the noise. I was thinking of maybe a dead filter capacitor - hence the noise. If all the ovens started from the same temperature, there is a variance in the oven set points. Some take longer to warm up than others. You don't mention if they started the same, so that may or may not be significant. They all started at the same temperature. Any apparent difference in warmup time is mostly due to the arbitrary offset of the traces. The offset was just so you could see all four traces clearly. However, isn't it also likely that each oscillator has had it's oven tweaked to match that particular crystal? To further complicate things, in a double oven, you can have a noisy outer oven that gets suppressed by the inner oven. Are your specific 260's double ovens? No way to be sure without tearing one open. The second step in the current plot could be an inner oven cutting back. I wondered about that second step. The period of the ringing on the second step is about 1 sec. longer than the ringing on the first step so it's apparently a different circuit. The 260 series datasheet does NOT say anything about it being a double oven. They talk about customizing the unit to suit the customer, but that seems a bit extreme. By the way, I purchased these oscillators from our favorite auction site. If anyone's interested, the 260 series includes both AT and SC crystals. Since these start out ~150 Hz low, they appear to be SC cut. The output is a 5 MHz sine wave @ ~+7 dBm into 50 ohms. They work fine with a 12V power supply. They have no mechanical frequency adjustment (unless it's under a suspicious spot of solder on the case) but my 4 were all adjustable to 5 MHz via EFC. They were apparently removed from Z3811 GPS receivers. They each have a sticker on the side that says Z3811-80010. There doesn't seem to be much info available on the Z3811. I have no relationship to the vendor - just a customer. So it sounds like the proper thing to do is file this information and carry on. After making some Allan Deviation measurements, review everything to see how, or if, oven 'noise' correlates to Allan Deviation results. Thanks Bob, Ed Bob On Feb 18, 2013, at 2:40 PM, Ed Palmer ed_pal...@sasktel.net wrote: I know that when making AC measurements on various OCXOs of the same type, you have to expect wide variations in the results. e.g. TVB's Allan Deviation measurements on a selection of 10811A oscillators at http://www.leapsecond.com/pages/z3801a-osc . But what about DC current measurements? How much variability should you expect? I recently bought 4 MTI 260 oscillators with thoughts of doing some 3-cornered hat experiments. I thought I'd use the best 3 of 4. One test I always do on an OCXO is to measure the DC current drain as it warms up. Nothing radical - I have an HP 6622A GPIB-equipped linear power supply. I just do GPIB queries as fast as I can and log the results. I get about 6 readings per second. More than enough for my needs.
Re: [time-nuts] FE-5680A DDS Board/PIC Code
Hi Herbert, Nice work ! A few comments that may help you in your quest. There are two primary methodologies used in the FEI-5680A Rubidium. It appears, from your picture, what you have is the older style that is analog for control of the Rubidium frequency control loop. A VERY GOOD THING ! Why, because the analog C field pot is active in such a unit, permitting adjustment allowing you to put it right on the mark. This easily allows you to extend, externally, the C field control and be able to put it in an external loop with a GPS without much trouble. In the first methodology, the original designed was, totally, an analog control. The micro controller is used to talk to only the DDS which is outside of the Rubidium control loop. The Rubidium control loop starts with a 50.+ MHz oscillator frequency multiplied up to the Rubidium and the feedback from the photo multiplier is fed back to control the 50.+ MHz oscillator. This 50.+ MHz is the reference frequency for the DDS on the board in your picture. The second methodology is a bit more complicated because FEI switched to digital control of the Rubidium frequency loop. Here, an internal 60. MHz oscillator is used as a base signal. A DDS, whose reference is from the same 60 MHz oscillator generates the required offset and mixed with the 60 MHz to produced the final multiplied signal to the Rubidium filter. The photo multiplier is sensed and eventually runs a DAC to control the 60 MHz oscillator. The problem with this approach, due to the computerization and digital stepping, is you can get close but not necessarily right spot on for frequency. Depending upon your house standards, that may or may not be an issue. To put it in perspective, I think the adjustment process in the newer methodology is either parts in the 10E-12 or -13. The output frequencies that the customer sees are derived via circuitry outside the loop like the old method except they have switched to using either an ASIC or FPGA of some sort making it quite difficult to determine what is going on. Equally so is the fact that the ASIC/FPGA's are controlled by software. Of course, FEI is not going to be forthcoming on the internals, nor do they want to tell how to use their computer link to control the Rubidium unless you are a customer. As a hobbyist, you are left with a much harder unit to integrate into external control mechanisms. Even though the C field pot is still there it is not active in the unit. Someone or more have been investigating methods to find a proper point with which to inject an outside DC signal to attempt a C field like control. I do not know what their success has been. FEI's part number system is really two different processes. The FEI-5680A number is the generic case and layout style, etc. and another order number is attached that tells what is actually arranged inside. So, the upshot is the older arrangement is easier to play with. Hope this has been helpful, BillWB6BNQ Herbert Poetzl wrote: I'm new to the time-nuts community, so I simply start with a short info on how I got into this situation :) (skip forward to ONTOPIC if not interested) Not long ago, I decided to build a reasonably good frequency counter for my personal use and maybe if the result is simple and elegant, I'll publish the details so that everybody can build one ... It was clear to me, that it had to be able to count up to at least 1GHz and thus show at least nine, better ten significant digits, so a precise time base is required. After some online searches and investigations, my best options seemed to get a very stable oscillator and a high quality time reference to sync with, which in turn brought me to the idea to use a cheap rubidium normal and somehow tune/measure/sync it via GPS or DCF-77/MSF-60. Reading a lot of documentation and blogs from all over the world (sometimes in translation :) shed some light on the rubidium normal requirements, which I defined as: - has to have a 10MHz output not just the 1PPS - has to be programmable (i.e. can be tuned) - must be cheap I quickly found two different RB standard models, readily available on ebay for a reasonable price, namely the Efratom FRS-C and the FEI FE-5680A. I finally decided to go with the FE-5680A, mainly because I liked the package. A seller was quickly found offering something titled: 'FE-5680A Rubidium Atomic Frequency Standard Oscillator Transceivers 10Mhz Out' 'Programmable from 1Hz to 20MHz' Little did I know what that actually meant ... When the units (I ordered two of them) arrived, I couldn't wait to test if they actually work and get a lock, so I quickly wired them up (according to the pinout) and provided them with the advised 15V at up to 2A each. To my astonishment, they heated up rather quickly and got a lock in a little under two minutes, so I happily got my scope out to check the 10MHz signal, just to find that there is no such
Re: [time-nuts] FE-5680A DDS Board/PIC Code
Hi, Probably Elio will jump in and tell us more on this, but I must advice that the unit where he did his forensic examination was a FE-5680A of the 10 MHz fixed frequency output variety (not accounting for the small adjustment margin)and also has a fixed 1 PPS. This unit doesn't have the two blue buttons and is essentially different from the programmable units. Its DDS is used in a very different way and the PIC program should be totally different. Regards, Ignacio, EB4APL On 18/02/2013 23:54, gandal...@aol.com wrote: In a message dated 18/02/2013 22:45:12 GMT Standard Time, paulsw...@gmail.com writes: Herbert Thanks for the assembly listing. Someone else on time-nuts had done quite the job of reverse engineering the schematics and other information. Seems like the two of you could collaborate. Sorry do not recall the name. Welcome to time-nuts. Regards Paul WB8TSL Was just thinking the same thing so checked through my archives. That was Elio, _eliocor@gmail.com_ (mailto:elio...@gmail.com) , messages posted here about a year ago. The messages will be in the list archives anyway but below is the text of two messages I saved. Regards Nigel GM8PZR -- From: elio...@gmail.com Reply-to: time-nuts@febo.com To: time-nuts@febo.com Sent: 15/02/2012 01:31:32 GMT Standard Time Subj: [time-nuts] FE-5680A Schematics (v0.1) at the following address: http://www.rhodiatoce.com/pics/time-nuts/FE-5680A/FE-5680A_schematics_v0.1.p df you will find the 0.1 release of the FE-5680A schematics. New additions: - pinout of the unpopulated (24 pin) connector (J9) behind the DB9 - connections between CPU/MAX3232 and the *TWO* serial ports!!! - component values of the 10MHz filter + option on PCB to output a square 10MHz wave on DB9 - connections between CPU and MAX1246 (A/D converter) - connections between XC9572 and MAX392 (quad analog switch) - unknown pins marked as '?' As you can see, it seems FE-5680A fully supports 2 serial ports: one on DB9 and the other one on the unpopulated connector (J9) behind DB9. Any comments/suggestions are welcome. . ciao _Elio. _ From: elio...@gmail.com Reply-to: time-nuts@febo.com To: time-nuts@febo.com Sent: 24/02/2012 01:03:56 GMT Standard Time Subj: [time-nuts] FE-5680A Schematics and scans Thanks to Ignacio (EB4APL) and the generosity of Mike Harrison, today I received a PCB of a disassembled FE5680A. I provided to make some scans of the board at 2400DPI resolution: the picture size is about 7700x11500 pixel (9MB) Top face (with and without ICs): http://www.rhodiatoce.com/pics/time-nuts/FE-5680A/FE-5680A_Top001.jpg http://www.rhodiatoce.com/pics/time-nuts/FE-5680A/FE-5680A_Top001_noIC.jpg Bottom face (with and without ICs): http://www.rhodiatoce.com/pics/time-nuts/FE-5680A/FE-5680A_Bottom001.jpg http://www.rhodiatoce.com/pics/time-nuts/FE-5680A/FE-5680A_Bottom001_noIC.jp g Being able to remove the ICs, I was able to correct some flaws in the previous schematics: http://www.rhodiatoce.com/pics/time-nuts/FE-5680A/FE-5680A_schematics_v0.2.p df During the next week I will continue to write down the logical part of the circuit and I hope will be able to dump the 8032 firmware _ Elio. _ ___ 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] Future of UTC 2013
In late 2011 we held a meeting on the Future of UTC in Exton Pennsylvania. The 400 pages of proceedings from the presentations at that meeting have been published on paper and in electronic form. The sequel to that meeting is planned for late May of this year. Requirements for UTC and Civil Timekeeping on Earth A Colloquium Addressing a Continuous Time Standard to be held at the University of Virginia, Charlottesville, VA May 29-31, 2013. The subject of the meeting notes the ITU-R process regarding possible changes to radio broadcast time signals (and the associated internet equivalents). Full details of the upcoming meeting are available via http://futureofutc.org/ At that site are also links to the proceedings from the 2011 meeting. The co-chairs are P. Kenneth Seidelmann, John Seago, Rob Seaman and me. The period for submitting abstracts remains open until the end of this week. We invite contributions which address the issues described in the Call for Papers at the website. Folks on the time-nuts list know how time gets into operational systems. We would be glad to see some of that expertise at the meeting. -- Steve Allen s...@ucolick.orgWGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165Lat +36.99855 1156 High StreetVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ 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] OCXO DC Current Question
Hi Bob, On 2/18/2013 6:19 PM, Bob Camp wrote: Hi The -Z3811 is indeed a part out of a HP GPSDO. HP is a big enough customer that the part they get *may* have little relation to the standard part. True, but it doesn't look like there were many Z3811s made. The order wouldn't have been that large. Maybe there were enough other orders from HP that they wanted to keep them happy. If they all started out at the same temperature, then the noisy ones finish warmup quicker than the quiet ones. Take a look at when the final glitch happens in the warmup process. It's definitely happening earlier on the noisy parts. If warmup finishes quicker - the part is running at a lower temperature. That of course is only the time between the cutback from full current to the glitch. It may not mean it's running cooler. Between possible temperature differences due to crystal tuning and component tolerances that affect the internal voltage regulators ( and therefore affect the maximum current available to the oven ), I don't know what, if any, conclusions can be drawn for such a small number of samples. But when I rechecked the startup current, it looks like the noisy oscillators draw a few milliamps ( up to 10 ) more than the quiet one. That might allow them to warm up quicker. Thanks, Ed Bob On Feb 18, 2013, at 5:32 PM, Ed Palmer ed_pal...@sasktel.net wrote: Hi Bob, On 2/18/2013 2:42 PM, Bob Camp wrote: Hi Like any control loop, gain, bandwidth and noise are all related. In a DOCXO you have two control loops and they do interact. That said, there's nothing grossly wrong with the four OCXO's. The noisy parts have a bit more gain in the controller. The quiet parts have a bit less gain. The easy way to see this is the ringing after the current changes. Yes, when I zoom in on the ringing after the first step change, they all show a period of ~9 seconds. The blue trace (the quiet one) has a nice smooth damped sine wave while the other ones have varying amounts of noise superimposed on the sine wave. The amplitude of the ringing on the noisy ones is greater than the amplitude of the quiet one. In one case, more than twice as big. Without ADEV numbers there's no way to know which one is good (or better) and which one is bad (or worse). The noisy parts may be responding to the ambient temperature rumble (thus correcting for it) and the quiet ones may be ignoring it (allowing it to hit the crystal). I hadn't thought of that possibility. Thanks for that! It's also possible that the noisy ones have an electrical issue in the loop that generates the noise. I was thinking of maybe a dead filter capacitor - hence the noise. If all the ovens started from the same temperature, there is a variance in the oven set points. Some take longer to warm up than others. You don't mention if they started the same, so that may or may not be significant. They all started at the same temperature. Any apparent difference in warmup time is mostly due to the arbitrary offset of the traces. The offset was just so you could see all four traces clearly. However, isn't it also likely that each oscillator has had it's oven tweaked to match that particular crystal? To further complicate things, in a double oven, you can have a noisy outer oven that gets suppressed by the inner oven. Are your specific 260's double ovens? No way to be sure without tearing one open. The second step in the current plot could be an inner oven cutting back. I wondered about that second step. The period of the ringing on the second step is about 1 sec. longer than the ringing on the first step so it's apparently a different circuit. The 260 series datasheet does NOT say anything about it being a double oven. They talk about customizing the unit to suit the customer, but that seems a bit extreme. By the way, I purchased these oscillators from our favorite auction site. If anyone's interested, the 260 series includes both AT and SC crystals. Since these start out ~150 Hz low, they appear to be SC cut. The output is a 5 MHz sine wave @ ~+7 dBm into 50 ohms. They work fine with a 12V power supply. They have no mechanical frequency adjustment (unless it's under a suspicious spot of solder on the case) but my 4 were all adjustable to 5 MHz via EFC. They were apparently removed from Z3811 GPS receivers. They each have a sticker on the side that says Z3811-80010. There doesn't seem to be much info available on the Z3811. I have no relationship to the vendor - just a customer. So it sounds like the proper thing to do is file this information and carry on. After making some Allan Deviation measurements, review everything to see how, or if, oven 'noise' correlates to Allan Deviation results. Thanks Bob, Ed Bob On Feb 18, 2013, at 2:40 PM, Ed Palmer ed_pal...@sasktel.net wrote: I know that when making AC measurements on various OCXOs of the same type, you have to expect wide variations in
Re: [time-nuts] Allan deviation and modified Allan deviation
Corby, On 18/02/13 20:59, cdel...@juno.com wrote: Ok I've been plotting my oscillators for years using Allan Deviation. That way all my records can be compared easily. Is there any advantage to using Modified Allan Deviation? It seems to give a better stability plot but that just seems to be cheating! It's not. If I plot both ways what do the differences mean? When the Modified Allan Deviation was introduced, two things happen: 1) It fixes the bug in the Allan Deviation which can't make useful differentiation between white phase modulation and flicker phase modulation noises. This is achieved by using a tau-long averager prior to the Allan Deviation calculation. If you are in a region where these noises exist, use MDEV to separate them. Dave Allan himself is eager to push MDEV over ADEV. 2) The traditional (non-overlapping) Allan Deviation estimator has poor usage of the samples taken. The MDEV estimator given uses the overlapping strategy to increase (but not maximize) the use of samples, especially for longer taus. This gives improved confidence intervals. These steps improved the state of art processing significantly in the early 80thies. Since then have the total and Theo strategies for even further improved use of samples to achieve good confidence intervals. Using the traditional non-overlapping Allan deviation estimator for the Allan Deviation measure is throwing a lot of useful data in the trash and suffer by bad precision or long measurement-times. Allan Deviation is frequency drift limited in its upper end, where linear (and higher order) drift will obscure the output and hide the noise processes that Allan Deviation is meant to analyse. Drift is a systematic component that needs to be taken out of the data in order for the noise processes to be visible. The Allan Deviation has a cousin in the Hadamard Deviation, both is normalized to the same scale (i.e. same as RMS white frequency modulation noise). The Hadamard beats Allan for real-time processing, as it removes the first degree frequency drift. However, for post-processing a better drift model can be used, so drift removal on data prior to Allan Deviation is preferred. Then, both Allan and Hadamard Deviations can exist in their normal and modified variation, with the tau-long averager. For degrees of freedom treatment, you can do non-overlapping, overlapping, TOTAL and Theo processing, where TOTAL and Theo is the best. There is also FFT based methods to process data, but I need to refresh myself on that. So, it sounds like you can do a lot more with your data without cheating. Cheers, Magnus - from LA ___ 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] Future of UTC 2013
Love the graphic on the website. The use of a Foucault Pendulum with Earth as the bob is inspired... -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Steve Allen Sent: Monday, February 18, 2013 20:18 To: time-nuts@febo.com Subject: [time-nuts] Future of UTC 2013 In late 2011 we held a meeting on the Future of UTC in Exton Pennsylvania. The 400 pages of proceedings from the presentations at that meeting have been published on paper and in electronic form. The sequel to that meeting is planned for late May of this year. Requirements for UTC and Civil Timekeeping on Earth A Colloquium Addressing a Continuous Time Standard to be held at the University of Virginia, Charlottesville, VA May 29-31, 2013. The subject of the meeting notes the ITU-R process regarding possible changes to radio broadcast time signals (and the associated internet equivalents). Full details of the upcoming meeting are available via http://futureofutc.org/ At that site are also links to the proceedings from the 2011 meeting. The co-chairs are P. Kenneth Seidelmann, John Seago, Rob Seaman and me. The period for submitting abstracts remains open until the end of this week. We invite contributions which address the issues described in the Call for Papers at the website. Folks on the time-nuts list know how time gets into operational systems. We would be glad to see some of that expertise at the meeting. -- Steve Allen s...@ucolick.org WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High StreetVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ 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] repairing General Technology (Tracor) 304-B rubidium standard
Guys, I'm repairing a 1960's vintage lab-grade rubidium standard, General Technology Corporation model 304-B. Apparently Tracor bought GTC soon after this unit was made, because references to this as a Tracor 304-B seem to be more common. I've made some progress, but now it seems like time to consult the hive mind. The unit appears clean, but it doesn't lock. I've read through old comments on the list regarding this unit, and I've downloaded a copy of the manual and schematics available at *http://sundry.i2phd.com/ServiceManual_304b.pdf* That file seems to contain a complete copy of the manual text, but some schematics are missing. In particular, the schematics for the sweep/acquisition board (A8) and the three boards inside the physics package (the lamp oscillator (A13), the SRD driver (A12), and the photocell preamp (A11)) are not shown. Does anyone know where to find copies of those schematics? The main power supply voltage on my unit seems to have been deliberately adjusted lower than spec (18.54 V actual, versus 20 +/- 0.1V specified in the manual). Replacing a resistor on the regulator board (that had smoked from overload due to the low voltage) didn't change the voltage much. I had to crank the trimmer across half of its range to get the voltage back within spec. Nothing in the regulator circuitry seemed to have drifted enough to change the setpoint that much. Is there a reason why a tech would have deliberately set this voltage lower than spec, or did it just drift down over the years? A frequency counter (GPSDO reference) shows that the crystal oven warms up as expected. The output can be centered on 5 MHz and the sweep circuit covers a symmetrical range around 5 MHz as expected. The ovens for the lamp and filter cell appear to warm up properly as well, judging from test points available on the A1 oven controller board. The test point voltages don't quite match the ones in the PDF manual, but it looks like those readings were typed into each individual manual after being read off the particular unit that came with that manual. The test point on the A5 board shows that 155 Hz resonance detector modulation is within spec. The A6 filter-amplifier board test points show the system attempting (and failing) to detect 155 Hz and 310 Hz resonance signals coming back from the photocell. The manual says that the A7 RF pre-driver board (the x14 multiplier) should be supplying 70 MHz at +13 dBm to the SRD driver inside the physics package. That would be about 2.8Vpp, assuming a 50-ohm system. Instead, it's supplying a clean 70 MHz at about 100mV into a 50-ohm load. My best guess is that the final amplifier transistor on that board is blown, possibly from being operated with only a scope probe as a load (infinite VSWR). Replacement transistors are on order. Any other thoughts? Obviously, the box won't lock until the RF input is the right level. But it also requires the Rb lamp to light. Corby Dawson posted to the list back on 12 November 2009: Tracor bulbs fail with a different mechanism and last maybe 10 years. Anyone know what that different failure mechanism is? Is it repairable in an ordinary lab, like the heat-gun trick for LPRO bulbs? If not, is it feasible to build a Frankenstein replacement using something like an LPRO or FEI bulb? Is it possible to tell whether the lamp is lit without opening the physics package? If not, are there any tricks to opening the physics package? Any precautions to take before doing so? Any other comments on how to get this box working again? Cheers! --Stu Side note: This unit was built during the era of elastic seconds (roughly, the 1960's). It contains a board (A9) which digitally offsets the output frequency in increments of roughly 7E-10, without changing the rubidium resonance frequency or the C-field. There's also a note in the manual saying that annual changes to the definition of the second may require replacing the rubidium resonance cell in the physics package with a new cell calibrated for the new second in the new year. Leap seconds bring their own problems, but compared to dismantling your lab instruments every year, they're a breeze. ___ 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.
