Feature: Stanford Research Systems SR830 driver

[Rubenknex]

Changes proposed in this pull request:

• Contains most commonly used features

I was in doubt about the time constant and sensitivity settings. These could be set and get using the string representations as they are right now, or a number in SI base units.

@giulioungaretti @alexcjohnson

[alexcjohnson]

Would this (and similarly for time_constant and filter_slope) be more useful as numbers, ie 2e-9: '0\n' with units='V'?

Then you could use the value (param.get() or param.get_latest()) in calculations.

[MerlinSmiles]

I was just thinking the same, but actually the numbers have different meanings,
500 mV is equal to 500 nA depending if the input is in voltage or current mode

[alexcjohnson]

Is that what input_config is about? So then 1 MOhm means 500 mV turns into 500 nA, but 100 MOhm means the same 500 mV turns into 5 nA? I suppose we could make the parameters reflect what's going on behind the scenes... leave this parameter as it is because somewhere inside there really is a voltage digitization step with sensitivity of 500 mV... but in front of that there may be a 1 or 100 MOhm load resistor.

But @MerlinSmiles you're right that that may not be the most useful from a user perspective, ideally we'd change the val_mapping to reflect the actual current sensitivity ala #92 - I was hoping we could do it just with units, and that would work sort of for 1 MOhm (units=uA) but it's ugly for 100 MOhm (units=10nA?)

[MerlinSmiles]

I think the driver should reflect the user-perspective.
The actual input configuration is:

• A (meaning voltage measurement)
• A-B(voltage too)
• I (10^6) (Meaning current measurement, with an amplification)
• I (10^8) (the same thing)

If I remember correctly the user doesnt have to care about the actual amplification as the instrument returns the value in amps, is that right @Rubenknex ?

And the user shouldnt have to think about the internal way how the amplification works.

[alexcjohnson]

Yes, I agree (the good physicist would still need to know somewhat, as there's a difference between 1 pA sensitivity into a 1 MOhm load and into a 100 MOhm load... but that doesn't change the fact that even the good physicist doesn't need to divide by 1e6 or 1e8 all the time just to set the correct current sensitivity).

However, unless we want to write a bunch of complicated stuff now just to rip out later when we implement #92 I would suggest leaving this as is right now, based just on volts, and update it when we can do so cleanly.

[alexcjohnson]

what happens with the 100 MOhm setting then? Does 17 mean 1 nA in both the 1 MOhm and 100 MOhm cases, or does it mean 10 pA in the 100 MOhm case?

[Rubenknex]

I think it is the same sensitivity for both 1 and 100 MOhm, otherwise it would be quite confusing. I have to check the manual to be sure though.

[MerlinSmiles]

I'd propose a different way of handling this.
The units are only V and A, and the sensitivity is just a number to that unit. So I'd like put .set(1e-6) no matter of volts or amps. Or is that something you wont like @Rubenknex ?

Since this is not a setting that has to be super fast, we can make a parser that checks the input config and then allows to get or set the sensitivity in the right units?

I'll fiddle around with this. It would be nicer to have it not change in a month or two.

[alexcjohnson]

Sure, it won't be hard to make that happen, make setter and getter functions for input_config that after changing itself, change units and val_mapping for this param (hmm, need a new method to change val_mapping, that's in __init__ right now) and get it too. Then when we abstract this concept we can simplify this without breaking changes.

[Rubenknex]

So it would be

lockin.input_config('1 mohm')
lockin.sensitivity('50 uv/pa')
vs.
lockin.sensitivity(50e-12)

I agree using a number looks cleaner. The implementation however is a bit more difficult.

[MerlinSmiles]

@Rubenknex This looks nice!

@alexcjohnson we have a situation here again where units depend on the currently enabled mode of the instrument, depending on the input mode the X,Y,R (i think) are in amps or volts...

[spauka]

Looks like there ended up being too pull requests for the SRS830 (see #139) ... There don't seem to be significant differences between the two approaches though.

Regarding the issue of sensitives, the solution I implemented awhile ago (but only just pushed) is sort of similar to what @MerlinSmiles suggests, having a parser which checks what mode you are in and interprets the result accordingly. My plan was to have a separate parameter that gives direct access to the numeric code the lock-in returns if necessary for programming (i.e. to change the sensitivity by one level easily). There may also be a nicer way of doing this once #92 is resolved.

[Rubenknex]

@spauka Oh well, I had a feeling this would happen haha. Being new to working with git in a team I only noticed your branch after I wrote my version of the driver. Maybe we can mix the best of both in some way, although both are indeed quite similar.

[Rubenknex]

Merged functionality with #139.