the bias voltage sweep of the MFIA works perfect in the range between -1 and 1 V, but for voltages of higher magnitude than 1 V there is a strange behaviour: First, such higher voltages are not applied, neither during the sweep nor when I manually enter the bias (checked with an LED element). Furthermore, in the saved measurement file they are all recorded as -1 resp. 1 V, and the corresponding Cp value is off. I use 2 terminal measurement Cp || Rp.
Note that I modified the current driver code as follows:
I allowed version mismatch in self.daq = ziP.ziDAQServer(cpars[‘serveraddress’], cpars[‘serverport’], cpars[‘apilevel’], allow_version_mismatch=True)
I changed [‘/%s/imps/0/enable/’ % (self.devID), 1] by removing the “on” after “enable”.
I added a command for enabling bias voltage [‘/%s/imps/0/bias/enable/’ % (self.devID), 1]
thanks for pointing this out. I downloaded the newest driver and had to make similar changes as previously (remove the ‘on’ after ‘enable’; and allow version mismatch; but enable bias was not necessary with this new driver). Still I have the same issue. 2-Terminal mode allows for bias up to 10 V, and even 4-terminal allows more than 1 V, so I am puzzled where this restriction comes from.
Setting the output range on the MFIA is a bit tricky, since it has to cover drive amplitude plus bias. As you noticed, the driver didn’t correctly enable the output range, so the instrument stayed in the ±1 V range and clipped the bias to ±1 V without any error. That is why nothing above 1 V reached your LED and why the file shows ±1 V.
I have changed the driver to set the output range automatically and enable it. It also checks the bias the instrument actually applies and stops the run if the instrument limited it.
The new version is uploaded as a testing version with today’s date that should show up in the version manager, if you are logged in with your own e-mail address.
Please check whether bias voltage works with the new driver and let me know. If yes, I’ll set it live for everybody.
thank you, now it works! There might be one bug left: In the bias-sweeper, I used number of points (lin.) for defining the measurement points.When instead using voltage steps in the sweeper, I got a range error (could not go beyond -0.1 V).
great, thank you for testing and reporting back!
It’s a bit difficult to pin down the bug with the “number of points” definition from remote, but I hope I figured it out. There is a new driver for you online to test. Please update via the Version Manager as before.
I hope we got everything fixed now.
thx, I can check this beginning of next week. In the meantime I would like to ask a ‘soft’ question: When doing the bias sweep, I hear during the measurement a lot of clicking in the MFIA, as if there were new initialisations of the connection in-between the measurement points. Also it takes somewhat longer (I can check how much longer exactly) than with the regular Zurich instruments web interface. Any idea about if this is normal or how it could be avoided?
the clicking is most likely the input range relays, not a new connection. In the adapt() phase, the SweepMe! driver starts a one-shot autoranging of the current and voltage inputs at every measurement point. The instrument searches for the best ranges, which you hear as clicks, and the driver waits until it has finished. After that, it waits 16 time constants for the values to settle. Both add time per point compared to the LabOne sweeper.
The driver also enables automatic input ranging in configure(), so the instrument adjusts its ranges by itself whenever the signal requires it. This is probably the same autoranging that LabOne relies on.
The extra autoranging per point only makes sure that any range change has finished before a point is measured. That matters when the current jumps a lot between two points, for example in frequency sweeps over several decades or when the light on the sample changes during the run. In a C-V sweep with small bias steps, the current changes only slightly from point to point, so the extra autoranging should not be needed.
Could you do a quick test? After updating to the new driver, please create a custom version of the driver (using the VersionManager) and comment out the extra autoranging:
In adapt(), please comment out the block that sets currins/.../autorange and sigins/.../autorange and the waiting loop after it.
If my theory is correct, this should stop most of the clicking and speed up the measurement.
We could then add an option to the driver to enable/disable the extra autoranging. It is probably not needed in most applications.
yes, without this whole block “1.” this clicking is mostly (except for the first points of the measurement) gone while preserving (in my sample measurement) an accurate curve. Funnily, when working with the currently online driver version, the clicking in the low capacitance region is heavily reduced when inverting the bias-V scanning direction (such that it goes from higher to smaller parallel capacitance). Also for a frequency scan it worked well. Therefore, I still use the driver version that is currently online.
Thank you very much for the quick and detailed help!
