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.

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.

LED Status Indicators#

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.