Choose input and output boards for the functions your cockpit needs

Controls and feedback do different jobs

An input board reads a pressed button or an axis position. An output board controls a load, such as a status LED. An interface may provide both, but that does not mean it supports every signal type. A connector labelled I/O is not a promise of encoder support, analogue measurement or high-current outputs.

Count the contact and lamp of an illuminated switch separately. The contact reports your action; the LED might display a confirmed simulator state. Lighting the label continuously is a different requirement. For each component, write down what needs to be read and what needs to be driven. The guide to switches, encoders and axes develops these distinctions.

Compare boards by the signal you need

Compare alternatives doing the same job. A basic USB button interface may be entirely adequate for buttons but unsuitable for feedback. A more capable I/O board only saves work if its firmware and your software support the specific functions you need. Check the exact revision: similarly named boards can contain different hardware.

Count a real panel before buying

Consider direct wiring: eight buttons need eight digital inputs. Two quadrature encoders use two signal connections each, and their two push buttons add another two. That gives 8 + 4 + 2 = 14 digital signal connections. Two potentiometers add two analogue inputs. Six individual status LEDs need a separately planned output path.

This is a requirements calculation, not a pinout. Firmware may require specific encoder pairs, while buses, serial communication and displays can reserve pins. Shared ground wires are not extra logical inputs. A matrix or expansion board changes the wiring and interpretation. Only then compare your list with the channels actually available. Record spare channels by capability rather than as a single total.

Include supply and signal levels in the decision

For every board, record its supply, permitted signal levels and load limits. A 5 V supply does not mean all inputs tolerate 5 V. The number of outputs says nothing about their combined current limit. LED planning must include drivers, resistors or constant-current regulation, and the combined load.

An output may supply current or sink it to ground; the required connection is different. Use the diagram for the exact product. Plan connectors, strain relief and labels so that a board can be replaced later. See power supplies and signal levels for a closer look at these requirements.

USB detection is only one check

USB first describes a connection. A device might appear as a game controller, a keyboard or a serial port. Its hardware and firmware determine the functions available. Arduino documents native USB capabilities for the Micro; that does not make every Arduino model an automatic game controller.

A serial device needs a PC-side receiver that understands its message format. A game controller can report inputs without offering individually controllable LED outputs. Check recognition, visible input, simulator assignment, incoming feedback and output control separately. A power LED alone proves none of those complete paths.

Shared software still needs supported hardware

Cockpit Suite brings supported devices and simulator functions into a common environment. Use the compatibility overview to check the specific device and firmware. A generic HID device and a board using a particular serial protocol require different connection paths.

Prepared firmware or a suitable profile can save work. Establish exactly what is already configured and what wiring, assignment or calibration remains. Our 4SB Input Card 128 and 4SB LED Output Board 64 are development products; pricing and availability have not been established. They are intended for different jobs, and their names do not imply universal interchangeability or immediate availability.

Start with one channel

1. Save the documentation, board revision and firmware version. Draw a connection plan and resolve unidentified pins before connecting them.
2. Test one documented input in the device tool. Rest, press and release should be distinguishable.
3. Assign a suitable simulator function and remove unwanted duplicate bindings.
4. Test one output separately using a documented test value. Only then connect the actual simulator state.
5. Check application restart and reconnection. Record both the expected state and the observed result.

This sequence separates the electrical build, device behaviour and simulator connection. Otherwise an assignment error can look like a faulty board. Use the manufacturer’s diagnostic method for prepared hardware; a first check does not require replacing its firmware with your own.

Use symptoms to narrow the problem

If no input responds, check the device type, configuration and documented connection of the single button first. If an encoder reports only one direction or misses movement, compare its type, connection order, decoding settings and slow-turn behaviour. More channels will not fix an unsuitable decoder.

If a button works but its LED stays dark, part of the input path is established; the output still needs its own check. If a channel works alone but fails in the complete panel, investigate supply limits, reserved pins and conflicting settings. Change one possible cause at a time and record the result. Continue with systematic troubleshooting when necessary.

An expandable panel needs records

Keep a list of component, board connection, logical function and profile. Record which pins each expansion occupies and the matching firmware version. A small, clearly labelled installation is usually easier to extend than a large panel with unexplained wiring.

If you are unsure about a choice, share your channel list in the forum. We aim to help on the same day where possible; questions arriving late may receive a later reply. The board name, intended function and last successful check give us a useful starting point for finding the next step together.

Plan the next step for your board