What is MURC?

MURC is the Multi-Resonator Controller. It consists of both hardware and software with the simple goal of allowing very fast, dynamic control of a set of frequency-multiplexed resonances.

What does it do?

We designed MURC for high-speed (kHz+ bandwidth) measurements of resonators’ resonant frequencies, utilizing an array of digitally-implemented phase-locked loops (PLLs). More specifically, it is designed for oscillating arrays of resonances (from single or multiple resonators) utilizing a single-input single-output structure – that is, there is a single physical channel for actuating many resonances, and a single physical channel that detects the superposition of the state from many resonators.

But beyond that, it is flexible! It can be a lock-in amplifier, a phase-shifter or an amplifier, a mixer, a frequency counter or a frequency generator, or a phase-locked loop. If you’re interested in probing properties of kHz to MHz-range (LF-HF) resonators, chances are MURC may be useful to you.

How is it structured?

A general block diagram of the system setup is shown below. The core of MURC is a number of modules we call SmrDrivers (since our resonators are called SMRs). Each SmrDriver can perform many different functions, including acting as a phase-locked loop, a feedback line, a delay line, a frequency generator, and a lock-in amplifier.

System_block_diagram

But like, physically, what is it?

MURC consists of both hardware and software. The hardware consists of essentially three components.

  1. The first is an FPGA development board from Terasic. We use one of two boards – the DE2-115 ($300 for academic use, $700 non-academic) or the DE4-530 ($8000).
  2. These boards also require high-speed analog-to-digital (A/D) and digital-to-analog (D/A) converters, which we get from a second board from Terasic, the Data Conversion Card (DCC).
  3. The final bit of hardware is an oven-controlled crystal oscillator (OCXO),  since the onboard clock is not temperature controlled, and therefore not terribly precise (blow on it to see how changes in temperature affect your frequency measurement!) We use an Abracon AOCJY2 OCXO at 100 MHz.

The software is the bit we developed ourselves. The software also comes in three flavors:

  1. The FPGA code itself that decides how the FPGA behaves. This is in verilog, and all the signal processing code (PLL implementations and such) is there.
  2. The C code that runs on a ‘soft’ CPU implemented on the FPGA – this code is wholly concerned with making sure the signal processing code has a way to communicate with the outside world. For example, the signal processing code can measure frequency, but if there’s no way to get these frequency measurements off of the FPGA and to a PC, how do we do anything with them?
  3. The Labview code that runs on a PC. This code basically does two things. 1) It saves whatever data the FPGA might send it (e.g. your frequency measurements from your resonator array), and 2) allows you to easily change the FPGA signal processing parameters  on the fly. For example, one resonator starts behaving strangely – turn it off to ensure it doesn’t couple to any of the other resonators, or change the data rate, or change the measurement bandwidth, etc.

 

Leave a Reply