For us, control means damping. The controller is a filter.

Cantilever has large Q for big excursions and narrow bandwidth.

BUT imaging experiments demand that we reduce Q.

• Reduce motion amplitude (for resolution)
• Damp out ringing quickly (as we move to new voxel)
• Broaden resonant peak (to track changing cantilever frequency)

This can be done without reducing SNR.

Motivation: all of the information is within a few hundred Hz of cantilever resonant frequency.

Technique: "mix down" input signal to near DC, by multipling with reference frequency near resonance.

Advantages:

• Sample and process the mixed-down signal at much lower frequency (especially for RF)
• RF, acoustic cantilevers can use same program (just change reference frequency)
• Mixer also detects MRFM signal (it's a lock-in amplifier)
• Mixers are commodity hardware

Technology experiences

Commercial "software radio" products (VME boards, RTOS). Emulated heterodyne control at RF -- BUT

• Poorly suited for closed-loop control (high frequency, but long latency)
• Complex, exotic hardware and cross-development software (difficult to program)
• Expensive (more than $100K entry cost)

GNU Radio

• Technology stack from GUI to volts programmable at all levels
• Complex, but familiar and ubiquitous programming environment
• Open source --- including the hardware! (about $1k entry cost)

GNU Radio technology stack

Integrated design from volts to GUI.

Each layer depends on the one below, well-defined interface to each.

Each layer could be substituted (different technology, but same interface).

Developers are encouraged to program several layers (optimize across the whole stack).

GNU Radio hardware

Universal Sofware Radio Peripheral (USRP)

• 2 x AD9862 codec: each 2 A/D 12 bit, 64 Megasamples/sec; 2 D/A, 14 bit, 128 Ms/sec
• FPGA: Altera Cyclone EP1C12, 64 MHz, 12,060 LEs, 239,616 RAM bits
• USB 2.0, Cypress FX2
• 4 x daughterboards for signal conditioning

FPGA programming

FPGA: sea of logic gates and flipflops, your program connects them.

Design your own special-purpose computer (DSP or ...)

• Program in Verilog (C-like syntax)
• Free development system from FPGA vendor
• Store program on host, load into FPGA under program control
• Highly parallel, all variables can update simultaneously (on each clock tick)
• No operating system (no resource sharing)

Limitations of our FPGA program

FPGA is almost full!

Limitations: latency, also 16-bit integer signal and filter coefficients.

Latency is about 12 -- 14 samples, at mixed-down sampling period:
about 400 usec at 31.25 kHz sampling frequency, 50 usec at 250 kHz.

• Low latency ---> High sampling frequency to compensate
• High sampling frequency ---> Small filter coefficients, poor resolution/accuracy
• Poor filter coefficients resolution/accuracy ---> Scale up signal
• Scale up signal ---> small dynamic range

Maybe heterodyne control not such a good idea for acoustic cantilever after all.
To get acceptable latency, sampling frequency is much greater than reference frequency!

Try it anyway!

Filter characteristics I

Sampling frequency 31.5 kHz, appreciable phase shift caused by 400 usec latency.

Filter characteristics II

Sampling frequency 250 kHz, little phase shift caused by 50 usec latency, but notice error in amplitude.

Revising the FPGA program

Experiments planned:

• Remove one of two biquad filter stages, reduce latency?
• Remove one of two CIC decimation/interpolation stages, ditto
• Remove mixers, try a "flat" (non-heterodyne) filter, ditto
• More bits for filter coefficients, expect more dynamic range

We can have several (many) FPGA programs that make different tradeoffs. Could select a different one for each voxel.

For this, we need to program the FPGA ourselves.

GNU Radio development

Process optimized for rich functionality, high performance, rapid progress and distribution

• Key developers set project direction by producing code and hardware
• All users are developers too (must build from source)
• Most developers fill in functionality, port to new platforms, find/fix bugs
• Work-in-progress is available on the net
• Active mailing list with high signal-to-noise
• Much code comes with tests
• The code and tests are the documentation, mostly
• Other documentation describes key examples, not intended to be comprehensive
• Open source, GPL
• Financed via users (research grants etc.)

For example: