Hardware, Instruments and Connectivity

This chapter covers the hardware layer of the Mikrofab semiconductor/TFT/PV measurement and analysis software from the user's perspective: which instruments are supported, how devices are discovered and connected, how the switch matrix relay board is managed, how roles are assigned to instruments, the instrument console, firmware updates, device profiles, simulation (mock) mode and safe-connection principles. The goal is for you to be able to start without connecting any hardware (simulation), and then use the exact same interface once you move to a real bench.

1. Two Connection Surfaces

The software accesses the hardware through two complementary interfaces:

Both surfaces use the same driver and discovery infrastructure; only the presentation differs. In this chapter we first detail the supported devices and discovery, then the features of the two surfaces.

2. Supported Devices and Model Matching

The hardware layer is built on a multi-vendor instrument registry (instrument_registry). If a device is defined in the registry, it is recognized automatically from its *IDN? response and assigned the correct protocol and channel count.

2.1 SMU (Source-Measure Unit) Families

SMUs are the software's primary measurement instruments (source + measure + 4-wire Kelvin support). The following models are registered:

2.2 Extended Inventory (PSU, LCR, AWG, Lock-In, Temperature)

Devices beyond the SMU are registered for discovery and raw control; some also bind to measurement slots:

2.3 Protocol Support

2.4 Model Matching (*IDN? Parsing)

When a VISA resource is opened, an *IDN? query is issued. Per IEEE 488.2 the response is in the form VENDOR,MODEL,SERIAL,FIRMWARE. Matching follows this logic:

• The vendor token is searched in the response. For Keysight the AGILENT token is automatically added, and for R&S the ROHDE, SCHWARZ and R&S tokens.
• The model token is searched with word/number boundaries (so that 2612A does not accidentally subsume 2612); the longest (most specific) match is preferred.
• If no match is found, the device is not labeled "UNKNOWN" but listed by its own raw identity (e.g. "B&K Precision 894" or the *IDN? model field); this way you can always see every device on the bus.

2.5 Driver Backend Selection and Autorange

The driver for a model is selected according to the mock/real distinction:

• Simulation (mock): the canonical physics-mock MockSMUDriver — no real I/O; diode/Schottky/solar-cell/transistor physics.
• Real I/O:
  1. If the model has an external driver (e.g. R&S → RsNgxSMUAdapter) and it can be resolved, it is used.
  2. Otherwise the QCoDeS community driver (QCoDeSSMUDriver) is used.

Autorange capability. The autorange checkbox in the UI is enabled only if the driver family of the selected model implements real source/measure autorange. The single source of truth is family_supports_autorange:

That is, at present only the TSP family (Keithley 2600) implements real autorange; the checkbox is disabled for the SCPI 2400/2450, Keysight, dc_supply and R&S families. In a dual-SMU setup, if both sub-drivers do not support it, the checkbox stays disabled (no misleading option is offered).

3. VISA Resources and Device Discovery

3.1 VISA Interface Types and Resource Naming

The software automatically derives the interface type from the prefix of the resource name (interface_type):

If a string does not look like a valid VISA resource (empty, unknown scheme, does not contain ::), the software does not pass it to open_resource; this avoids the cryptic VI_ERROR_INV_RSRC_NAME (Parsing error). The sim://... and MOCK... resources are treated as valid (simulated).

3.2 Automatic Discovery (*IDN? open-query-close)

Discovery (Scan) enumerates connected instruments and maps each one to a candidate device record. Key features:

• Discovery is read-only: it does not open a persistent measurement session. Each resource is opened, queried with *IDN? and closed.
• Each resource is probed with two attempts: (1) default settings (the proven path for USBTMC SMUs), (2) if empty, \n termination + a longer timeout (giving slow/serial devices a chance).
• Flow control is disabled on serial (ASRL/COM) resources; otherwise a non-responding board (e.g. a CH340 switch matrix) could block indefinitely waiting for CTS.

Timeout protections (device-communication rule #1):

Serial ports are also enumerated via pyserial; if one of the tokens CH340, USB Serial, USB-SERIAL, USB-UART, CP210 appears in the description/manufacturer/hardware ID, the device is flagged as a Switch Matrix candidate.

3.3 Manual Resource Entry

If a device cannot be found automatically, you can enter its address by hand:

• Classic panel: when you select the Connection type in the relevant SMU field, the correct prefix is written automatically into the address field; you complete the rest. With Find you can scan and dump the list to the log.
• Hardware page — RS-232 manual add: in the Add Device dialog you enter the port (COM3 / /dev/ttyUSB0), baud, parity and stop bits and probe with Send *IDN?. If a response arrives, the IDN field is filled and with Add the device is added to the inventory in the NEEDS_SETUP state.

3.4 Connection Test, Latency and Back-off

When you Test a device or click Reconnect, a read-only *IDN? probe is performed and the latency is measured:

• Input: *IDN? round-trip time (monotonic clock) · Output: latency_ms (ms). On a failed probe the latency is meaningless and is not recorded.
• Simulated devices always return (True, "<simulated>", None) — no I/O is performed.

Periodic background polling (~2 s): the Hardware page continuously re-polls reachable devices. A device that remains unreachable is tried less and less often via exponential back-off:

That is: 1st failure → 5 s, 2nd → 10 s, 3rd → 20 s, … up to 5 minutes at most. A successful probe resets the counter. This prevents a single non-responding device from monopolizing the scan loop.

4. SMU Setup Modes

The measurement engine always sees a single SMUDriver interface; how many physical devices are behind it is determined by the setup mode. In the classic panel, three modes are selected with radio buttons.

4.1 Dual Channel (dual_channel)

A single native dual-channel device (e.g. Keithley 2614B) provides both the drain and gate channels. The Connect button sets up the model, calls connect(resource), validates with *IDN? and hands the active driver to the measurement engine.

4.2 Single Channel Pair (single_channel_pair)

Two separate single-channel SMUs are presented as a single dual-channel driver through a DualSMUAdapter:

• channel="a" → drain SMU (SMU1), channel="b" → gate SMU (SMU2).
• Each sub-driver connects independently with its own VISA resource (connect_each(res1, res2)); you enter two separate addresses.
• Autorange capability is reported only if both sub-drivers support it.
• In mock mode, the gate (b) voltage is reflected to the gate reference of the drain sub-driver, so that Ids(Vds, Vgs) is computed correctly (valid only in simulation; on real hardware each SMU reads its own value).

4.3 Single Channel Diode (single_channel_diode)

Only the a channel is used; ideal for two-terminal devices (diode, Schottky, solar cell). A single address is sufficient.

5. Switch Matrix / Relay Board

The Switch Matrix is a 16-channel low-trigger relay board (Mikrofab TFT switch matrix). It routes DUTs (e.g. TFTs arranged on a substrate) to the SMU in turn.

5.1 Hardware and Protocol

• The board runs the Arduino-based tft_switchmatrix firmware (v3.0.0) and is driven over a COM port via PySerial.
• Expected device model: TFT-SWITCHMATRIX-16 (identity verification looks for this).
• There are two command layers:
  • Legacy token protocol — "<pin><a|b>..." (e.g. "3b16b6b8b") and "a" (all-off). Relay selection and PV maps use this.
  • SCPI / IEEE-488.2 query layer — *IDN?, STATE?, SYST:ERR? (for closed-loop verification).

Relay pins: the board's relay pins are 2…17 (16 channels total).

5.2 COM Port, Baud and Port Discovery

The Find button scans serial ports; a port whose description contains Switch Matrix, Mega, CH340, USB Serial or USB-SERIAL is selected as a candidate.

5.3 TFT Mapping Table and Token Syntax

Each logical TFT ID is mapped to a relay command string (tft_mapping). The default mapping:

Token syntax: a line starting with a digit is break-before-make (all relays are opened first, then applied). Each token is a <pin><action> pair:

• b (or B) → close the pin
• a (or A) → open the pin

Example: 3b16b6b8b → closes pins 3, 16, 6 and 8 (the rest open). Only pins 2–17 are valid.

5.4 Open All Relays (a)

The All Off button (or the safe-state flow) sends the single-letter a command to the board; this opens all relays (disconnecting the DUT from the SMU). This command is the second step of the safe-state sequence (output OFF → relays OFF → close connection).

5.5 Reading Relay State and Route Verification

The professional closed-loop helpers verify before SMU biases are applied that the routing has actually taken place:

• read_state() / closed_channels() — reads back the 16 channels via STATE? (mirrored in mock).
• verify_route(expected_closed) — reads back, and if there is a mismatch or a record in the firmware error queue it raises SwitchMatrixError (errors are never swallowed — device-communication rule #4).
• drain_errors() — drains the SYST:ERR? queue (at most 32 iterations); stops when +0,"No error" is seen.

5.6 Newline Append Setting

Some firmware versions expect a line ending at the end of a command. When the newline append option on the Settings tab is on, a \n is appended to every send_command output (off by default). Raw paths such as Van der Pauw / Probe-IV (send_raw) always append \n regardless of this setting.

6. Device Roles and Assignment

The software solves the question of "which device does which job" with the role abstraction. There are two vocabularies.

6.1 Capability Roles (11 Canonical Roles)

The card-based Hardware page uses fine-grained 11 capability roles:

An SMU automatically provides the SOURCE + METER + FOUR_WIRE capabilities; the relay board provides SWITCH; the thermometer provides TEMPERATURE.

6.2 Legacy Device Roles

Measurement modules and the RoleBinding also use coarse device-level roles: SMU, RELAY_CONTROLLER, THERMOMETER, LOCK_IN, TEMPERATURE_CONTROLLER, DMM, DAQ, OSCILLOSCOPE. Each one expands into a capability set (e.g. SMU → {SOURCE, METER, FOUR_WIRE}).

6.3 Role Mapping (Role Mapping Tab)

In the Role Mapping tab of the Hardware page you assign a device from the inventory to each capability role. The assignment is saved instantly and the "N / 11" coverage indicator is updated. When a device is deleted, all roles pointing to that device are cleared automatically (so the resolver does not reference a missing device ID).

6.4 RoleBinding

When a measurement is started, the assignments are resolved into a single RoleBinding object: the primary fields smu, relay, thermometer + a capability access map. If a module cannot find a role it needs, a clear warning is raised with MissingHwRoleError (missing role).

7. Card-Based Hardware Page

The Hardware page shows the inventory as device cards and offers three tabs: Overview (cards + summary), Role Mapping, Profiles.

7.1 Device Cards and Status Badges

Each card shows the device's identity, capability chips and a status badge (status pill):

From the card action menu: Open panel (instrument console), Diagnose / Test, Self-test, Configure, Update firmware, Delete, Troubleshoot options are offered (depending on the device type).

7.2 Simulated Device Badge

Simulated devices carry a white SIM badge on a purple background on their cards. This badge is in a filled-pill form for contrast (WCAG AA). A simulated device is not a real connection: even if the instrument console is opened, the session_opened signal is not emitted and the card is never misleadingly painted as CONNECTED.

Adding simulated devices: the Add simulated button in the Add Device dialog adds a fixed set of mock devices that cover the bound capability roles (SMU 2614B, Switch Matrix, thermometer, DC supply, LCR, PV multiplexer, MFLI, Eurotherm, Sun EC10, K2000) — without any I/O.

7.3 Device Adding Paths

• Scan: a read-only discovery runs in the background; found candidates are checked and added.
• Add simulated: zero-I/O mock devices.
• RS-232 manual: port/baud/parity/stop + *IDN? probe (§3.3).

During the scan an animated bar and an elapsed-time counter are shown; when the scan finishes, a "{n} devices found · {s} s" summary is written.

7.4 Save/Load Profile (Station Profiles)

The Profiles tab saves/loads the current inventory + role assignment as a named station profile (config + .yml export/import). When restoring a profile the devices are re-polled; expected devices that are unreachable are flagged as NEEDS_SETUP (not an error — they are simply not on the bus right now) and the missing devices are summarized by name.

8. Device Configuration (Configure)

A device's Configure dialog shows the identity read-only and offers editable connection fields. It performs no hardware I/O; on OK the owner (the Hardware page) applies the setting.

Dynamic schema form: if there is a live QCoDeS driver for the device, per-parameter fields are generated from the driver's parameter schema (get_parameter_schema()) (each with min/max bound validation). If there is no live driver, the basic form above is shown. All validation errors are shown inline (red label) and OK stays disabled until they are all cleared.

9. Instrument Console

The instrument console is a separate top-level window per device, in the style of the NI-MAX "VISA Test Panel". You can send commands to one device while it is IDLE while a measurement continues on another device. All I/O runs off the GUI thread.

9.1 Generic Command Console

Options row:

9.2 Session Lifecycle and Busy Protection

• When the window opens, a held session is opened (if the device is not busy). When a measurement starts using that device, the session is released, the body is disabled, and it is automatically reopened once the device is free again (~1 s busy polling).
• When a session against a real device is opened successfully, session_opened is emitted and the card on the Hardware page is painted CONNECTED (a successful open is positive proof of liveness). In a simulated session this is not emitted.

9.3 Switch Matrix (TFT Board) Console Body

A special body for the Switch Matrix adds TFT selection buttons on top of the full command console. Clicking a TFT: (1) sets the host's active TFT (the measurement reads this), (2) writes that TFT's relay command (None → "a") through the console and logs it. The SCPI quick-actions (Identify/STB/Clear Device) are hidden for the Switch Matrix because they are meaningless there (*IDN? would be parsed like a relay command).

10. Firmware Update

The Switch Matrix board's Arduino firmware is updated through a device card (the port locked to that card's bus). This way an unrelated Arduino Mega board cannot be flashed by mistake.

10.1 Flow

1. At startup the board's *IDN? identity is read:
   • Matches the expected model → green note, Flash enabled.
   • Different (non-empty) model → Flash is blocked (wrong board on this port).
   • No response (empty/old firmware) → Flash allowed (first/recovery flash).
2. avrdude writes the shipped pre-compiled .hex to the board (no Arduino tool needed on the target), with a live log streaming.
3. After the flash it is re-validated with *IDN?.

10.2 Board and Tool Parameters

avrdude is searched for in this order: the MIKROFAB_AVRDUDE environment variable → the tools/avrdude/win/ shipped with the product → the Arduino15 package → PATH. Every real flash is bounded by a timeout (default 120 s). In mock mode no subprocess/serial I/O runs; a short synthetic log streams and success is reported.

11. Device Profiles (Catalog)

The identity (*IDN?) can be read from the device; however the accuracy class and device class cannot be queried via SCPI. These come from a catalog, keyed by model, that is built at import time from a machine-readable registry (specs/device_specs.json). The resolver scores candidate devices for a slot with the following inputs:

• Capabilities (fine leaves) — hard filter.
• Device class + class priority (ordering by the precision / constant / fast preference).
• Source/measure envelopes (v_max, i_max, resolution) — range filtering + quality scoring.

An unknown model falls back to a safe default built from the capabilities reported by the inventory; values measured via SCPI at connection time are overlaid on the catalog (apply_probe). None of these numeric values are safety limits — safety limits live in the device_safety layer.

12. Mock (Simulation) Mode

Simulation mode is for hardware-free development, demos and testing. The backend is the canonical physics-mock MockSMUDriver.

12.1 Behavior

• The driver always reports "connected" (connected == True) and returns a valid IDN: MOCK,<vendor>, <model>,0,0.1.
• A single-channel model raises ValueError when channel="b" is requested; a dual-channel model supports both a and b.
• send_raw produces reasonable fake responses (*IDN? → mock IDN; other queries → MOCK:0); the console/soft-panel is fully functional in mock.
• run_self_test returns PASS instantly (there is nothing real to test).

12.2 Mock Physics Profiles

The mock measurement physics is driven by a profile:

12.3 Simulated Badge

All simulated devices/sessions are explicitly labeled as SIM in the interface (§7.2) and do not behave like a real connection. When switching from mock to real you only clear the Simulation checkbox and enter a valid address; the interface is the same.

13. Safe Connection, Timeout and Safe State

All code that talks to the hardware obeys immutable safety rules (the device-communication standard):

13.1 Timeout Mandatory

Every read/write/query going to a device is made with a bounded timeout; there is no infinite/blocking wait. Key limits:

13.2 Safe State Preserved

On error, cancel or shutdown the outputs/biases are brought to a safe value. The sequence:

1. SMU output OFF (output_all_off),
2. Switch Matrix opens all relays (a),
3. Safe closing of the connections.

This sequence runs not only in the Qt closeEvent but also at interpreter exit (atexit) and on an uncaught exception (excepthook); this way abnormal terminations are also covered.

13.3 Mock Mode Not Broken

Every path that adds real I/O preserves its mock counterpart; the tests pass without hardware.

13.4 Error Checking

After SCPI/TSP operations the device error/status queue is checked; errors are not swallowed but surfaced meaningfully (e.g. read_error_queue, Switch Matrix drain_errors).

Summary

In this chapter we covered: multi-vendor device support and *IDN? model matching; VISA interfaces, automatic/periodic discovery and timeout protections; the three SMU setup modes; the Switch Matrix relay board (token + SCPI, all-off a, route verification); device roles and assignment; card-based inventory, status badges and the simulated badge; device configuration; the instrument console; firmware update; device profiles/catalog; the mock physics mode; and the safe-state/timeout principles. All these features can be used first in simulation, then on a real bench with the same interface.