7265 Lock In Amplifier

[jhenderson0107]

There is surprisingly little discussion of lock-in amplifiers on this forum.  I recently added a 7265 LIA to my bench and developed a control program https://share.elkengineering.net/!BiUDeVafB8 for it. 

The 7265 integrates high-gain bipolar and FET input stages, allowing measurement of current or differential voltage sources with sensitivity down to 2 nA/2 nV at frequencies from .001 Hz to 200 kHz.  The 2 nV/√Hz @ 1 khZ input stage can be used independently, increasing the utility of the instrument.

Like many instruments released in the 1990’s, the device may be remote-controlled via GPIB or RS232.  The vendor’s Acquire software is capable, but incompatible with the Agilent 82357B USB-GPIB interface used to communicate with legacy gear in my lab.

So, I rolled my own applet to control this instrument.  The application was developed using GNU C++ atop my cross-platform libraries, which include a convenient wrapper for the VISA instrument control libraries.  While some complain about bloat of the VISA libraries supplied by Keysight and NI, its use is justified in my opinion.

The VISA control library abstracts the physical connection to instruments, providing a consistent software interface to all attached instruments, from any vendor, connected via GPIB, USB, ethernet, PCI/PCIe or RS232.  It also contains a handy trace log facility to allow inspection of commands sent to/from instruments during code development.

My electronics lab instrumentation is attached to a PC, which is configured with numerous specialized applications and instrument control programs.  Consequently, development tool-chains are not installed or actively maintained on that platform.  The development PC is located in more comfortable environs and it contains modern distributions of CAD and software development tools.

Notably, modern VISA distributions include server software which runs on the lab PC and provide transparent access to to all lab instruments from the development PC in my office, irrespective of their particular host interface.  This is extremely convenient during the development cycle.

The applet was developed using the excellent QtCreator toolset.  Real-time graphics were implemented using the superb QCustomPlot graphics library.  Experimental data is stored to disk in real-time in GetData format, principally because that trivialized post-visualization of captured datasets using KST Plot.

Many drivers previously developed for instruments such as DVMs, signal generators, etc to perform automated tests did not require explicit multi-threading.  For example, the Agilent 34970 data acquisition unit is capable of executing relatively complex scans controlling multiple multiplexed devices for time periods spanning hours.  But the 34970 supports use of service requests (SRQ) to asynchronously notify the host application throughout sequence execution.   The driver’s SRQ routine is akin to a microprocessor interrupt handler and is sufficient to provide asynchronous data processing and host call-backs to maintain application responsiveness.

By contrast, the 7265 driver required careful use of helper threads to maintain responsive behavior.  While the 7265 is a relatively sophisticated instrument with an 68000 system management CPU and helper DSPs capable of performing phase locking of of  the carrier, down-conversion and low-pass filtering/measurements autonomously, host real-time data display and post-processing /transfer of captured “curve-buffer” data necessitated multi-threading.  Their hidden presence within the driver eliminates UI lag and mitigates latency in the post-processing of capture buffer data.

Any other LIA fans here?

[duak]

I don't have one but I did develop one as part of an electro-optical subsystem.  Beam flattening was initially performed by firmware and would take a few minutes because it had to average a number of samples to filter out noise.  With a Lock-in amp (synchronous detection) it took a few seconds and the ultimate accuracy was almost an order of magnitude better.  Its ability to accurately measure something ostensibly below the noise floor is amazing.

Cheers,

[maxwell3e10]

I've used a number of lock-in amplifiers. EG&G/Signal Recover/Amitek ones have always been somewhat awkward to operate compared with Stanford Research ones. SR865A is the new leader now for a modern lock-in.

Recently I picked up a mystery used lock-in amplifier DIOP ALA1010 to play around. It works pretty well, just need to think what kind of hobby project I can use it for.

[ElliotteWan]

 :)Hi there, the file from the dropbox is no longer available.

My lab recently got a 7265 ,so colud you please send me via email:elliottexiwan@gmail.com

thanks

[jhenderson0107]

File sent. 

[_Wim_]

Hi, I would be interested to test this om my 7260 unit. Could I receive these files also?

Many thanks,

[percypeng]

Hi This control program looks much better than official one, I have a 7265 and interested to play with this program on my unit, can you also share one to my mail? thanks
pengmingwei@gmail.com

[jhenderson0107]

Link to latest build is in the original post. 

[percypeng]

Thanks for the files, I seems not able to find my 7265 through 232 connection on this program,but the connection works well on Signal recovery acquire software, I check it in keysight IO libraries suite, the IDN? seems not work but connection is OK, any idea?

[jhenderson0107]

My control application relies on the NI or Agilent VISA libraries to communicate with the 7265.  I typically use an Agilent GPIB adapter connected to the 7265 to control the device.  But if you configure an RS232 serial port through NI MAX or the Agilent IO Connection Manager equivalent, you should gain access to the lock-in. 

The 7265 does not comply with the latest IEEE specs regarding command processing.  It uses "ID" rather than "IDN?" to send the identification string.  The resulting string is also non-compliant. 

[_Wim_]

Just gave it a quick try. It discovers my 7260 (connected via an Agilent 82357b GPIB adaptor). But when I try to open the device, I get time-out errors.

[_Wim_]

Maybe just a quick question, does it discover all instruments, or only specifically look for 726x instruments? I am also not sure how to interprete the discoveries. My 7260 is at GPIB 12, but all discoveries are listed as "0"...

Edit:
All devices are discovered, and the 7260 is the one indicated with all the zero's, as the 2 other names are 2 keithley devices on the bus. But as explained, when trying to connect, I get a time-out for some reason. 

[_Wim_]

I can connect via the same GPIB adaptor using the acquire software. I did have to reboot the 7260, as it was no longer detected by both your software or the Acquire software.

As you wrote you are using the same GPIB adaptor and could not connect via acquire, I suspect our adaptors are configured differently.

[_Wim_]

Just tried by enabling "488" modus, but this did not do the trick. I can still connect via acquire, but still get a time-out with your software.

[_Wim_]

Some additional info:

When I send ID via connection expert, I get '7260' back. This is also visible in the "comm test" menu of the 7260.

When I open your app, during the browsing of the devices I see the addition in the "comm test output" of [LF][EOI][LF][EOI]. When trying to opening the device, nothing additional is seen in the comm test window.

[jhenderson0107]

I haven't checked this app in a while.  I'll verify/debug and reply to this thread when a new executable is available. 

[jhenderson0107]

I just uploaded a new version which tests successfully here.  When invoked for the first time, it is necessary to click the Discover button and click the GPIB checkbox in the Instrument Discovery Options dialog shown so that the GPIB will be scanned.  Subsequently, the device should be discovered and begin scanning immediately. 

Here's the link:  https://www.dropbox.com/s/xcr7ioz8s3ugvgx/LockIn.zip?dl=0

[percypeng]

Thanks for the update, I try this and change connection from 232 to Keysight 82357B USB-GPIB, unfortunately the 7265 still can't be found in the program, below is some err report from IO monitor

[percypeng]

Now I get it running OK with the program, all I do is remove 232 cable and reboot 7265 as well as PC, then open the program, it seems the unit was locked to 232 connection if it was used at first time, to using GPIB, you have to reboot the system.

[_Wim_]

I just uploaded a new version which tests successfully here.  When invoked for the first time, it is necessary to click the Discover button and click the GPIB checkbox in the Instrument Discovery Options dialog shown so that the GPIB will be scanned.  Subsequently, the device should be discovered and begin scanning immediately. 

Here's the link:  https://www.dropbox.com/s/xcr7ioz8s3ugvgx/LockIn.zip?dl=0

Super! That was fast. 

Now it worked immediately. Instrument browsing was also a lot faster. I still get a few time-out messages right after the connection is established, but is does not seem to affect anything.

I can now browse through all screens without any issues, and they are updated immediately.

[_Wim_]

Now I get it running OK with the program, all I do is remove 232 cable and reboot 7265 as well as PC, then open the program, it seems the unit was locked to 232 connection if it was used at first time, to using GPIB, you have to reboot the system.

It indeed seems the firmware of the 726x is sensitive to lock-up the communication. I have this in the past also even using the official acquire software.

[i3v]

I just uploaded a new version which tests successfully here.  When invoked for the first time, it is necessary to click the Discover button and click the GPIB checkbox in the Instrument Discovery Options dialog shown so that the GPIB will be scanned.  Subsequently, the device should be discovered and begin scanning immediately. 

Here's the link:  https://www.dropbox.com/s/xcr7ioz8s3ugvgx/LockIn.zip?dl=0

It's a pity that this link is dead again...

[jhenderson0107]

I've updated the link in the original post. 

[rubidium]

Just noticed this post. I became a big fan of lock-in amplifiers a few years ago when designing a sensor for measuring the electrical conductivity (EC) of aqueous liquids that can sustain continuous immersion for long periods. Typical EC sensors use 2 immersed electrodes and measure the resistance between them to infer EC. Unfortunately, these electrodes are subject to degradation by corrosion or other fouling if left immersed for too long a period. My approach was to immerse 2 small back-to-back toroids, drive one with a square wave and measure the magnitude of the induced signal in the other. Without a closed conducting path linking the cores of the 2 toroids, the induced signal should be zero, if the toroids are assembled properly (i.e. with bifilar windings) and thus exhibit no external magnetic fields. With a closed conducting path passing through both toroids, the signal will be linearly proportional to the conductivity of that path. The issue I encountered with this approach was a very low signal to noise ratio. For sufficiently low EC levels, the SNR was less than 0 - sometimes a lot less. That's when I thought of a lock-in amplifier. Since I had a square wave driving one of the toroids, I used that same signal to switch the gain of an opamp between +1 and -1 synchronously, and then integrate. With a couple of pre-amplification stages, this worked like a charm, even though a square wave might not be the optimum waveform in light of its harmonics for taking the most advantage of that simple trig identity that underlies the concept. In any event, I became forever sold on the lock-in amplifier.

I suppose one can do what I did in digital form by appropriately sampling a signal with a microcontroller's ADC and then adding up the measurements with appropriate sign flips that are synchronous with the drive signal (probably by having the drive signal also trigger an MCU pin change interrupt.

[Kleinstein]

One can do the lock in amplifier digital with a µC. However the dynamic range is limited by the ADC. So when there is a strong interfering signal (e.g. mains hum) considerably larger than the signal of interest one may run into the limits of the µC internal ADCs with usually 10 or 12 bit resolution. The modern lock-in amplifiers generally use higher resolution ADCs (like 16 to 24 bits) to allow for a lower dynamic range.

The square wave demodulation is not that bad a choice. It is relatively simple and can be done low dift in the analog form. Analog multiplication with a sine wave is tricky. Depending on the actual signal the square wave can also use the additional harmonics part, provided there is not extra phase shift and the modulation is also more square wave. In those cases with a square wave signal the square wave demodulation is actually the better choice.  Even some of the analog LIs use square wave demodulation and filter out the harmoics of the signal up-front, because the square wave demodulation is easier and lower drift than analog multiplication.