Re: [Discuss-gnuradio] GNU Radio and Magnetic Resonance Force Microscopy (MRFM)

[Eric Blossom]

On Fri, Jan 28, 2005 at 09:02:58AM -0800, Jonathan Jacky wrote:
> 
> I joined this list recently so I thought I should describe my project.
> 
> I'm looking into using GNU Radio for signal processing in Magnetic
> Resonance Force Microscopy (MRFM).  MRFM has some similarities with
> atomic force microscopy (AFM) and scanning tunneling microscopy (STM)
> but MRFM can form a 3D image of the sample below the surface (not just
> on the surface like AFM and STM).  MRFM uses a tiny cantilever with a
> permanent magnet attached.  Its raw data are cantilever deflections
> caused by the magnetic forces exerted by electron or nuclear spins in
> the sample.  From this raw data, the positions of the spins in the
> sample can be inferred.  We hope eventually to obtain atomic-scale
> resolution 3D images of proteins and other interesting structures.

Thanks for the explanation of what you're up to.  Very cool!

> Our RF controller now runs a monolithic signal processing program.  I
> had already started work on a more flexible signal processing
> framework when I ran across GNU Radio --- which had already
> anticipated much of what we planned to do.  We're also intrigued by
> the USRP hardware.
> 
> I've only recently gotten GNU Radio (mostly) working on our favorite
> platform, Mac OS X.  Haven't made any firm decisions yet.  One
> alternative might be to dispense with all the special VME stuff and
> just use the USRP.  Maybe we could do the entire control signal path
> in the FPGAs on the board, only using the USB to load the FPGA program
> and/or retune the filters.  Or we might mix down/up on the USRP and
> control the mixed-down signals on the Mac.  We might even stick with
> the VME stuff, run GNU Radio there, and use the onboard down/up mixers
> as sources and sinks.  Our selection among these alternatives
> (including whether to use GNU Radio at all) will depend on
> performance (especially latency), correctness, robustness and
> stability, and ease of programming.

I think all of those are possible. 

The latency seen by a GNU Radio application is mostly a function of
the i/o path and drivers below GNU Radio.  You can indirectly control
the latency through GNU Radio by controlling the amount of data that
your sources produce at one time.  The ALSA audio driver currently
does this.  For example, if your source produces 100 samples each time
it's called, those 100 samples will be walked through the flow graph.
There's an obvious trade off between latency and overhead, but if
you've got the MIPS, there's no reason you couldn't reduce it to a
single sample.  At that point your latency would be the group delay of
the signal processing path, plus whatever your driver added.

> Jon Jacky, University of Washington
> 
> PS - "we" includes John Sidles, Joe Garbini, Tom Kriewall, and several 
> students and others who have moved on.

Thanks again for all the great info!

Eric