API and Communications#
All Qblox instruments, excluding the Mainframe, are controlled over Ethernet. They also all use a Python driver based on QCoDeS. Consequently, We recommend using this driver as it provides easy and clear access to all functionality of the instrument; even if you use a different lab framework as the overhead of QCoDeS is minimal.
SCPI Standard#
Underneath the QCoDeS driver layer, the control software is built upon the SCPI standard, as also reflected in API Reference.
This means that all communication with the instrument happens using the master/slave paradigm, where the host PC is the master and is always responsible for initiating communication by issuing SCPI commands to the instrument.
Of course, all of this is abstracted away at the driver level, so you don’t have to have in-depth knowledge of the standard. However, if you are familiar with it, you will have access to all the default SCPI functionality that you are used to, like qblox_instruments.native.Cluster.get_idn() (*IDN?), qblox_instruments.Cluster.reset() (*RST) and qblox_instruments.scpi.Cluster.clear() (*CLS), albeit with a slightly more readable name.
Tip
We advise resetting the instrument before starting your experiment to get the instrument into a well-defined state, thereby improving the reproducibility of the experiment.
Resetting the instrument is easily achieved by calling qblox_instruments.Cluster.reset(). This will reset the instrument status and configuration to the default values.
It will reset all SCPI registers, including any reported error. It will also clear all stored Q1ASM programs, waveforms, and acquisitions.
There are many use cases where you want to store the instrument’s settings before resetting, for instance, to be able to easily reproduce an experiment. For this, we advise using the snapshot feature of QCoDeS.
Errors#
Instrument errors are reported using SCPI’s system error registers, which can be read using qblox_instruments.scpi.Cluster.get_num_system_error() (SYSTem:ERRor:COUNt?) and qblox_instruments.scpi.Cluster.get_system_error() (SYSTem:ERRor:NEXT?).
However, as mentioned before, this is all abstracted away at the driver level. This means that the errors are automatically read and reported to you using exceptions.
Any driver function can throw these exceptions and you need to make sure these are handled appropriately, for instance by using try statements.
Status & Flags#
The status of the instrument conveys the general operational condition of the instrument.
This is derived from multiple internal components, like PLLs and temperature sensors.
The instrument’s status is updated every millisecond and stored in the standard SCPI registers.
It can be queried through these registers [e.g. through
get_status_byte() (*STB?)],
but a more convenient way of reading out the general instrument status is calling
get_system_status().
The instrument status is persistent through the state critical, so a way to reset it is required. This can be simply done by calling the clear() to clear the state or by
completely resetting the instrument by calling reset().
Status#
BOOTING— Instrument is booting.OKAY— Instrument is operational.CRITICAL— Instrument has encountered an error (see flags below), but it has been corrected.ERROR— Instrument has encountered an error (see flags below), which needs to be fixed urgently.
Flags#
CARRIER PLL UNLOCKED— No reference clock found.FPGA PLL UNLOCKED— No reference clock found.LO PLL UNLOCKED— No reference clock found (only for RF modules).FPGA TEMPERATURE OUT-OF-RANGE— FPGA temperature has surpassed 80 °C.CARRIER TEMPERATURE OUT-OF-RANGE— Carrier board temperature has surpassed 100 °C.AFE TEMPERATURE OUT-OF-RANGE— Analog frontend board temperature has surpassed 100 °C.LO TEMPERATURE OUT-OF-RANGE— Local oscillator board temperature has surpassed 100 °C.BACKPLANE TEMPERATURE OUT-OF-RANGE— Backplane board temperature has surpassed 100 °C (only for Cluster).
Frontpanel LEDs#
The LEDs on the front panel of the Qblox instruments are used as a visual indication of the Status & Flags of the instrument.
Indicator |
Color |
Meaning |
|---|---|---|
S |
White |
Okay and idle (no connections). |
Green |
Okay. |
|
Yellow |
Booting (other LEDs are off). |
|
Orange |
Critical. |
|
Red |
Error. |
|
R |
Green |
External reference clock selected. |
Blue |
Internal reference clock selected. |
|
Red |
No reference clock found. |
|
I/O |
Green |
Channel idle. |
Purple |
Sequencer connected to channel is armed. |
|
Blue |
Sequencer connected to channel is running. |
|
Red |
Sequencer connected to channel failed. |
|
Orange |
Output values are clipping. |