Add paramp parameters to qubit sequencer

[jwenner]

It would be useful to add the paramp parameters to the qubit sequencer. This might enable more automatic paramp bringup and is also a prerequisite for adding the paramp parameters to pyle (see martinisgroup/pyle#152).

[JulianSKelly]

I just want to note here that we may want to consider some type of check that makes sure that people running simultaneous data taking don't have different parameters. The paramp is typically set with a slow bias and switching back and forth could lead to unexpected results.

[DanielSank]

+1

[pomalley]

I wonder if it would be good to come up with a generic(-ish) way to store and pass-through parameters--not everyone who uses the sequencer will necessarily be using the paramp. Of course, the sequencer is already rather specific to our needs so it may not be worth trying to do this now.

[DanielSank]

@pomalley just make some channels optional. If I set a paramp channel I set a paramp channel. If I don't, well just just continue on our merry little ways, eh?

[jwenner]

+1 for the optional channels, as I'm not currently using the paramp on my qubits.

[pomalley]

Oh, sure, that's a must, but I could imagine other groups (e.g. us in the future) might have other hardware they want to use, and a generic "pass these parameters through to this server if they've changed since last time" might be useful.

[maffoo]

@pomalley, we already have such a mechanism. You can add your own setup packets to a sequence and they behave in exactly the way you describe.

[maffoo]

https://github.com/martinisgroup/servers/blob/master/QubitServer/src/main/scala/org/labrad/qubits/QubitContext.scala#L289

[pomalley]

Ah, so that explains that sense of deja vu that I was getting. So perhaps this is a change for pyle rather than the qubit sequencer, then? Unless we want to handle Julian's case, in which case (I think) we need the whole scheduling thing we've been talking about for a while.

[maffoo]

I think it makes sense to prototype support for this in pyle by just building the appropriate setup packets and using the existing mechanism for ad hoc control of other servers. In parallel we can figure out the right way to support this in a nice way.

[JulianSKelly]

How do we prototype this? Sorry I have no idea how to put in these special setup packets.

[ejeffrey]

Arbitrary setup packets are great for custom or one-off scans, and I think
we should do more to make this usable from pylabrad, it is pretty ugly
right now. Long term, I think it is best to add new channel types, because
that lets the qubit sequencer keep track of wiring and conflicts.

In the case of the paramp, you don't have to do anything for the bias, you
can just add Z or fastbias/slowbias channels to the readout device. We do
need a "channel" for a microwave source not connected to a DAC board.

On Wed, Feb 24, 2016 at 10:50 AM, Matthew Neeley notifications@github.com
wrote:

I think it makes sense to prototype support for this in pyle by just
building the appropriate setup packets and using the existing mechanism for
ad hoc control of other servers. In parallel we can figure out the right
way to support this in a nice way.

—
Reply to this email directly or view it on GitHub
#322 (comment)
.