Sometimes you open a freshly created Hackaday.io project and discover more than you expect. A moment of idle curiosity turns into a lengthy read involving several projects you wonder how you managed to miss the first time around. So it was this morning, with [Yann Guidon]’s documentation of his eBay-purchased rubidium frequency standard. In itself an interesting write-up, with details of reverse engineering the various different internal clock signals to derive more than just the standard 1-second pulses, and touching on the thermal issues affecting frequency lock.
It is when you look at his intended use for the standard that you’ll see the reason for the lengthy read. He has a couple of discrete component clock projects on the go. His first, a low-powered MOSFET design, promises to break the mold of boring silicon bipolar transistors with hefty power consumption. It is his second, a design based on germanium transistors and associated vintage components, that really stands apart. Not a Nixie tube in sight, but do browse the project logs for a fascinating descent into the world of sourcing vintage semiconductors in 2016.
Neither clock project is finished, but both show significant progress and they’ll certainly keep time now that they’ll be locked to a rubidium standard. Take a look, and keep an eye on progress, we’re sure there will be more to come.
We’ve featured a couple of rubidium standards here in the past. This rather impressive clock has one, and here’s one assembled into a piece of bench equipment. They’re readily available as surplus items for the curious constructor, we’re sure that more will feature here in the future.
I’m ashamed to admit that the unit fried…
So ashamed I haven’t even “logged” it yet.
I’ve left it running for a while, one the desk, then after an hour I smelled something like burned resistors.
The PSU was showing >2.6A, sign that something is clearly wrong (2A more than expected).
Maybe I misunderstood the thermal management and it’s something I am learning the expensive way :-(
I doubt I can repair it so I’ll have to buy another, hopefully helping me to cross-compare the parts and find the burned ones.
Any help, including discussion of thermal care, are welcome !
Thanks again
Check the two big orange tantalum capacitors in the power supply. My “working” unit from the ‘bay started smelling soon after power on, and i knew something fried but it still worked, only took a long time to lock. Fixable.
Thank you Steve ! I’ll look at these orange things :-)
I hope it’s only them. If they are dead, the easiest solution would be to disconnect the other jumper and power the 5V with the external connector (a regression of features but if that makes it work…)
For now I put my efforts in the ” SPDT16: 16-bits arithmetic unit with relays ”
https://hackaday.io/project/10889
Pro work is knocking and I gotta hurry, I want to finish something before my time is totally taken…
> ” they’ll certainly keep time now that they’ll be locked to a rubidium standard.”
Actually… As long as the drift has not been measured, I speculate it’s very optimistic :-)
Parameters such as temperature and voltage variations will certainly wreak havoc. I have NO IDEA of the type of cut of the crystal so the tempco is to be determined experimentally.
Worse, the Ge transistors are VERY temperature-sensitive and this might be the biggest cause of drift. The Rb is intended to quantify the (in)accuracy.
For long-term stability, I’m evaluating different approaches, in the following project : https://hackaday.io/project/11107-1ppd-midnight-reset
PS: thanks to Alexander/Shaos for featuring his pictures on this project too :-)
FWIW, I’m really close to a completed GPS discipline module for the FE-5680A. By itself, the 5680 is very stable, but not necessarily accurate.
https://hackaday.io/project/6872-gps-disciplined-xcxo
This is one of the projects I looked at, before deciding to buy my own unit :-)
Since I can’t receive GPS where I am, I have decided to rely on Rb, for a “sufficiently precise” reference to tune my clocks…
What you might do is Take it somewhere else and GPS discipline it long enough for the trim value to be stable (watch the diagnostic port for a while to see), then take the trim value GPS lands on and write that into EEPROM on the unit. It’s stable enough that that value should count as a calibration.
Oh, I should have looked at the links first.
The GPS Discipline module requires a 5680A with 10 MHz output, tunable via binary serial commands. Looking at the mods made to get 10 MHz out of your PPS unit, it’s unclear whether the serial commands will work even if the unit’s firmware supported them.
Scullcom[1] did a 10 MHz that didn’t require a Stanford Research module/Rb/Cesium standard. For ~50 USD, I can’t complain, but I don’t really have any metrology grade equipment to compare against. (If it loses comm with a sufficient number of sat’s the resolution drops to a 1 MHz, which is a quite nice feature, but it still keeps time). I believe in RF comms, Siemens uses the same technique in order to tune their transcievers.
https://www.youtube.com/watch?v=lbns-FvpzK4
Hello,
Yes I have a B model, no success has been reported yet with the serial port.
Furthermore I’m probably going to use the 20MHz signal and feed it to a doubling PLL for extra filtering.and better precision as a frequency meter source (25ns resolution).
Disciplining with a GPS will be pretty tricky, though I’ve ordered a cheap GPS receiver with integrated antenna. I tried to use a Trimble module but the type of antenna and coax were not specified so it was pretty useless :-(
Thank you for all the remarks !
Yup, one should be on its way soon.
Hint: High tech versus low tech, had an expensive meter that developed bad tantalums and even saw this “syndrome” on some burglar alarm modules where they had been replaced because the “indestructible” Gunn diode had apparently failed.