Settings, Troubleshooting, FAQ and Glossary

This section is like the "back of the user manual": you look here for what a setting does and its factory value, what to do when an error appears, and what the abbreviations you encounter (Vth, FF, EQE…) mean. It is the first place to look when something does not work as you expect; think of it as the thick reference booklet that comes in the instrument's box — instead of reading it cover to cover, you open it when you need it.

• Why it is done: to configure the software safely, quickly resolve where you got stuck, and learn the technical terms.
• What it teaches / measures: the meaning of each setting + its factory default, step-by-step solutions for common problems, FAQ and a technical glossary.
• Where it is used: first-time setup, changing settings, troubleshooting errors/faults, and looking up terms while reading reports/results.

The Settings Center does not write your changes to disk immediately; it first accumulates them in a draft and commits them when you press Save. This way you do not accidentally make a wrong value permanent — it is like reviewing a form before pressing "Submit". Theme/font/language are the exception: they are previewed instantly, but are still not written to disk until you Save.

• Why it is done: to prevent hardware-sensitive settings from being changed silently or by accident.
• What it teaches / measures: which change is "pending" (dirty ●), which is a live preview, and how to undo it.
• Where it is used: on every settings change; especially for critical settings such as Simulation Mode that alter device behavior.

The General tab determines the most fundamental behaviors of the software: where results will be saved, whether you will work with a real device or with mock (simulation) devices, and how much detail will be written to the log. This is the first place a new user visits; in particular Simulation Mode is the switch that must be turned off when moving to real measurements.

• Why it is done: to set up the software for your lab layout and choose the real/trial operating mode.
• What it teaches / measures: basic keys such as the output folder, mock_mode, Switch Matrix line-ending and log level.
• Where it is used: first-time setup and the transition from simulation to real hardware.

The Appearance tab sets how the interface looks and which language it is in: light/dark theme, font, application and help language, plus interface complexity by role. These do not change the measurement result, they only improve your working comfort — it is like adjusting the seat and mirrors to suit yourself while driving the same car.

• Why it is done: to make the interface comfortable to work with, suited to your eyes and language.
• What it teaches / measures: theme, font, language/guide language, user mode and plot grid.
• Where it is used: personal preference; training/presentation (simple mode) or advanced use (expert/developer mode).

The Measurement tab determines the default behavior of the measurement panels: how numbers are displayed, which SMU channel is connected to drain/gate, and which current/voltage/time values new measurements start with. If you define the correct "starting values" once here, you avoid entering the same settings by hand for every new measurement.

• Why it is done: to set up recurring measurements consistently and quickly; to predetermine the noise/speed balance.
• What it teaches / measures: number format, channel mapping and central SMU defaults (compliance limit, NPLC, settling time…).
• Where it is used: setting up the lab's standard measurement recipe once and spreading it to all panels.

This panel shows the absolute voltage/current/power ceilings the measurement engine will never exceed; it exists to reject a request that could burn the sample or the instrument before it is even sent. It is read-only so it cannot be changed by accident — think of it like a fuse in a circuit: normally invisible, but it cuts the circuit if something goes too far.

• Why it is done: to prevent sample and instrument damage and dangerous overload.
• What it teaches / measures: the highest allowed absolute voltage, current compliance and power limits.
• Where it is used: setup safety; the factory values are effectively unlimited and should be tightened from the configuration file in a real lab.

This setting determines which file types are produced when a measurement is saved (CSV, TXT, Excel, HDF5). You choose based on which program you will process the results with — xlsx if your colleague uses Excel, csv if you will process it with your own script; you can select more than one at the same time.

• Why it is done: to export results in a format compatible with the tools you will use.
• What it teaches / measures: the active export formats (export_formats) and the default selection.
• Where it is used: data sharing, archiving and external analysis workflows.

The Analysis workspace extracts metrics (e.g. temporal-response times) from the measurement files you have saved; this tab sets that workspace's defaults — which module comes pre-selected, where files are imported from, and at what percentages the temporal-response thresholds are. If you make the analysis type you use most the default, you start with a single click on every launch.

• Why it is done: to speed up repeated analyses and work with consistent thresholds.
• What it teaches / measures: the default analysis module, the import folder and the lower/upper threshold percentages (10%/90%).
• Where it is used: extracting metrics from loaded data; the routine analysis flow.

The Hardware tab defines how the software talks to real instruments: the VISA address to connect to, the connection timeout, and calibration tracking. Here you tell the computer which instrument to find and where — like saving the instrument's number in a contact list.

• Why it is done: to connect correctly and reliably to devices such as the SMU and relay board.
• What it teaches / measures: the VISA resource/timeout, SMU setup mode, switch port and calibration reminder.
• Where it is used: real hardware setup and troubleshooting connection problems.

This feature shows the outdoor weather in a small badge based on the location of the lab you work in. It does not directly affect the measurement; but in sensitive measurements where ambient conditions such as temperature/humidity can influence the results, it is a practical reminder to keep the conditions at the time of recording in mind.

• Why it is done: to keep ambient conditions in mind and for daily working comfort.
• What it teaches / measures: weather-badge settings such as location, latitude/longitude and refresh interval.
• Where it is used: context in environment-sensitive measurements; an optional convenience.

This panel shows the software's license status and is where you activate it: you copy the Machine ID and send it to the vendor, then paste and activate the license key you receive. Without a license, real-device measurements are limited; simulation mode, on the other hand, is always unlimited.

• Why it is done: to unlock/authorize the full version of the software for real measurements.
• What it teaches / measures: the Machine ID, license status (Active/Unlicensed) and remaining trial allowance.
• Where it is used: first purchase/activation and license renewal.

This tab manages the software's two limited contacts with the outside world: anonymous usage telemetry and new-version checking. Telemetry sends only anonymous events such as "which setting changed"; raw measurement data, values or serial numbers are never sent — you can turn it off with a single click if you wish.

• Why it is done: to make an anonymous contribution to the software's improvement and stay up to date; you decide the privacy preference.
• What it teaches / measures: the on/off state of telemetry and update checking (and the related JSON keys).
• Where it is used: turning off telemetry for privacy; stopping update checks on offline/air-gapped networks.

This form lets you send a suggestion, bug or question that occurs to you while using the software directly to the developers — without leaving the application, optionally attaching a file such as a screenshot. The user who experiences a bug describes it best; that is why the feedback that comes from here plays a direct role in improving the software.

• Why it is done: to record problems and requests and deliver them to the developers.
• What it teaches / measures: the category, rating, message, contact and attachment fields.
• Where it is used: bug reporting, feature requests and sharing general opinions.

The registry gathers all the instruments in your lab into a single inventory: you define each instrument once with an understandable name, and measurements refer to it by that name. If an instrument's address changes, you update only here and all measurements adapt automatically — like the contact list on your phone: when a number changes you update the contact, you do not retype the number on every call.

• Why it is done: to manage device addresses from one place and abstract measurements away from hardware detail.
• What it teaches / measures: the device's type, model, VISA address and connection form; connection testing with *IDN?.
• Where it is used: multi-instrument setups, address changes and connection verification.