# Set inputs by hand

Give a part the value it measures, such as a bus voltage, a current or a temperature, and see what your firmware does with it. No scenario needed.

## For a run

1. In **Runs**, choose **New run** and pick the system. The **Inputs** card lists every input of every part, in its unit, with the range the part can read, for example _Bus voltage, V: the part reads 0 to 81.9188 V_.
2. Type a value. It holds for the whole run. Leave a field empty to keep the part’s reset value.
3. Start the run. The run page lists the inputs you set, and **Run again** fills them in for you.

A value outside the range is clamped to the nearest one the part can report. An input that has no unit takes the part’s raw code, a whole number in its range.

If the run’s scenario already drives an input, the card says _The scenario sets this one_ instead of showing a field: the scenario’s next sample would replace your value, so it could not hold. Run without the scenario to set it yourself.

## Live in the Proving Ground

In a running session, pick a part in the world outliner. The Inspector shows its **Inputs**: type a value and choose **Set**. The value applies from the next sync point, the Inspector says when, and it is recorded with the session, so **Save as test** replays it. Inputs that take only raw codes are set in a run, not live. See [Proving Ground](https://circuittwin.ai/docs/proving-ground).

## Check what the firmware read

Under **Values at stop**, add a **Device register** check named `device.0xOFFSET` with the value you expect. It is read when the run stops, and the result shows the value found. For example, an INA226 named `u5` with its bus voltage set to 12.6 V reads `0x2760` at `u5.0x02` (12.6 V at 1.25 mV per bit); with nothing set it reads `0x0`.

## From the API

`POST /api/v1/runs` takes the same inputs as `stimulus`, one stream per input, with the value in the input’s unit (`si`) or as a raw code (`raw`):

POST https://app.circuittwin.ai/api/v1/runs

```
{
  "boardId": "my-board",
  "firmwareId": "<firmware id>",
  "assertions": [
    { "kind": "oracle" },
    { "kind": "device_register", "device": "u5", "offset": 2, "expected": 10080 }
  ],
  "stimulus": [
    {
      "target": { "device": "u5", "port": "voltage.bus_voltage" },
      "interpolation": "hold",
      "samples": [{ "tNs": 0, "value": { "si": 12.6 } }]
    }
  ]
}
```

A run whose scenario drives the same input is refused with `422 input_set_by_scenario`.

## Test failures

Error handling is hard to test on a bench. With `twinConfig` on the same request you can take a part off the bus, or force a register after reset, such as a wrong chip ID, and check that your firmware notices:

twinConfig

```
"twinConfig": {
  "overrides": [
    { "device": "imu", "disconnected": true },
    { "device": "u5", "registers": { "0xFE": 4660 } }
  ]
}
```

Registers are named by offset (`"0xFE"`) or by name (`"MANUFACTURER_ID"`).

> **What an input is**
>
> An input is what the part’s twin reports to your firmware: the value lands in the registers the chip documents. It is not an electrical simulation of the signal the chip measures.