EEVblog Electronics Community Forum

Electronics => Open Source Hardware => Topic started by: wergor on October 31, 2021, 04:06:17 pm

Title: LibreTimeBase: A Controller & Distribution Amplifier for Rubidium Frequency Stds
Post by: wergor on October 31, 2021, 04:06:17 pm
I'd like to introduce my Project:
LibreTimeBase (https://bitbucket.org/christandlg/libretimebase) - an OSHW Controller and Distribution Amplifier for Rubidium Frequency Standards (and OCXOs).

This Project is my first step into timenuttery and "RF" stuff. The goal is to create a device that can interface with a wide range of Rubidium Frequency Standards and provide additional functionality:

The device (WIP!) here shown with an Accubeat AR-133:
(https://bitbucket.org/christandlg/libretimebase/raw/7f9001a917f0fabb3aa90f7e56b84ce5863096ab/LibreTimeBase_AR133.png)
PDF Schematic (also WIP!): https://bitbucket.org/christandlg/libretimebase/src/dev/pcb/LibreTimeBase/schematic.pdf (https://bitbucket.org/christandlg/libretimebase/src/dev/pcb/LibreTimeBase/schematic.pdf)

Rubidium Frequency Standards will be mounted onto or over the board (depending on size) and will interface to the device via a riser card. The riser card will contain components specific to the Standard (attenuators, voltage dividers, ...) and bulk capacitors. I'm trying to use the center of the board, which will be covered by a RFS anyway, as a space to put the riser cards so that users can just break away and populate the riser card they need. Riser cards use Samtec MEC8 edge connectors, the pinout is chosen to prevent damage in case of reverse insertion.
The Standard's reference output will be filtered by a 5th order elliptic filter before being buffered by a pair of LT6550 triple video amps. 5 of the 6 video amp outputs are isolated with TC1-1T transformers and feed the device's 5 Reference Frequency outputs. Video amp output 6 feeds a LTC6957 clock generator which in turn feeds a 74HCT driver for the 5V TTL clock output. An AD5689R 16-bit DAC is used for EFC, a MAX3232 supports RS-232 communication with supporting Standards. An AD8213 measures the Standard's supply current.
Finally, a STM32F072 controls and monitors everything. The STM32's clock is also driven by the LTC6957 and feeds the 74HCT driver for the 5V 1PPS output signal.
The Supply Voltage is filtered and reverse polarity protected. No DC-DC converter is present, so the Standard is driven directly off the Supply Voltage. The STM32 monitors both Supply Voltage and Current and can switch off the Standard's Supply in fault conditions. The device can operate from 9V to 32V (Abs. Max. 36V), depending on the Standard's requirements.

After an extensive market research (https://www.ebay.com/sch/i.html?_nkw=rubidium+frequency+standard) I have identified the following Rubidium Frequency Standards as candidates for support:
OCXOs will also be supported, like the Trimble 65256.
These Standards have different characteristics (mechanical dimensions, supply requirements, output power, analog / digital interfaces, ...) which define the requirements for the device, e.g. the wide Supply Voltage Range.

The device is designed to be used either as a module for the Envox EEZ BB3 (https://www.envox.eu/eez-bench-box-3/) or as a standalone device. When used as a BB3 module, functionality will be exposed via the BB3 User Interface and SCPI via the BB3's remote interfaces. Unfortunately, with most types of Rubidium Frequency Standard installed the device will take up more than 1 slot of the BB3.
When used as a standalone device a SCPI interface will be exposed via USB. The PCB is 100mm wide, so the device can be housed in common extruded aluminum cases for 100mm PCBs.
Title: Re: LibreTimeBase: A Controller & Distribution Amplifier for Rubidium Frequency Stds
Post by: wergor on February 06, 2022, 10:21:50 pm
The first batch of prototype boards arrived a few weeks ago:
(https://www.eevblog.com/forum/oshw/libretimebase-a-controller-distribution-amplifier-for-rubidium-frequency-stds/?action=dlattach;attach=1403033)
shiny!

I decided to assemble one board by hand soldering, testing it along the way, to catch errors early. A good idea, as it turned out, when I learned that the 1117 voltage regulators in SOT223 package come in 2 different pinouts, and I did not order the pinout I used in the design :palm: At least this problem is easy to fix.
(https://www.eevblog.com/forum/oshw/libretimebase-a-controller-distribution-amplifier-for-rubidium-frequency-stds/?action=dlattach;attach=1402988)
its not pretty but it works.

Working my way through the RF section of the board, everything seemed fine until I installed the transformers for the isolated reference sine outputs. After that, power consumption increased substantially, the amplifiers got too hot to touch and the output signal was distorted, indicating that the amplifiers were no longer operating in their linear regime.
(https://www.eevblog.com/forum/oshw/libretimebase-a-controller-distribution-amplifier-for-rubidium-frequency-stds/?action=dlattach;attach=1402994)
2.6W seems to be a bit much.

Installing the transformers revealed the first error in my design (at least the first one i didn't know already): I forgot to add DC blocking capacitors to the buffer amplifier outputs |O The input of the amplifiers are biased to ~1.15 V, with a fixed gain of 2 producing 2.3 V DC at the output at all times.
(https://www.eevblog.com/forum/oshw/libretimebase-a-controller-distribution-amplifier-for-rubidium-frequency-stds/?action=dlattach;attach=1403000)
all part of the learning process.

With only R3 limiting the current, this pushed the amplifiers close to their short circuit currents, not leaving much headroom for an AC signal on top. Additionally, there are 5 amplifiers with transformers in parallel, their combined current draw partially tripped their supply rail's polyfuse, bringing the rail down, further reducing the headroom, which ultimately had them working in a nonlinear fashion. All that could have been avoided had I just implemented these amplifiers as shown on the last page of the datasheeet (https://www.analog.com/media/en/technical-documentation/data-sheets/65501fa.pdf) :palm:
But again, this was not too hard to fix:
(https://www.eevblog.com/forum/oshw/libretimebase-a-controller-distribution-amplifier-for-rubidium-frequency-stds/?action=dlattach;attach=1403006)
also not pretty. also works.

After fixing this, I used a NanoVNA V2 to test the 5th order elliptic filter. For a 10MHz reference, it is designed to have notches at 20 MHz and 30 MHz. I did not get the exact value capacitors and inductors I needed for the filter, but simulation results (https://www.eevblog.com/forum/oshw/libretimebase-a-controller-distribution-amplifier-for-rubidium-frequency-stds/?action=dlattach;attach=1403057) suggested the chosen values should be good enough, even taking tolerance into account. Measurements show the filter is not tuned properly, reducing its performance. I assume I have misplaced a capacitor or two. Still, 2.2 dB attenuation is something I could live with. The LTC6957 clock generator works fine, but I'll still have to find the correct settings for its internal filters.
(https://www.eevblog.com/forum/oshw/libretimebase-a-controller-distribution-amplifier-for-rubidium-frequency-stds/?action=dlattach;attach=1403012)
Mistuned filter. The adapter board I used has a 6dB attenuator built in.

(https://www.eevblog.com/forum/oshw/libretimebase-a-controller-distribution-amplifier-for-rubidium-frequency-stds/?action=dlattach;attach=1403018)
Filter test setup

Thanks to the current supply chain problems the microcontroller (STM32F072RB) is still not available at a reasonable price. After looking up my usual parts sources unsuccessfully, I decided to bite the bullet and order a few Nucleo-F072RB development kits and desolder the microcontrollers :-/O seems wasteful at first, but on the other hand, I now have a debugger for each of my prototypes  :D
(https://www.eevblog.com/forum/oshw/libretimebase-a-controller-distribution-amplifier-for-rubidium-frequency-stds/?action=dlattach;attach=1403024)
FREE debugger with every microcontroller! only while supplies last.

Most other tests require features implemented in the microcontroller, which is what I'll be working from now on. I also found a few minor issues with the board (components to close to mounting holes, one adapter board being a bit too short, ...) which I'll fix before ordering the next batch.