Map simulator data to displays and outputs correctly

Make the complete chain visible

Write down five separate steps: source → received value → meaningful conversion → output rule → physical or visible result. Add what you can observe at each step. This reveals whether a fault already exists in the raw value or appears only during formatting.

Start with one clearly observable function in a repeatable simulator situation. Avoid changing several controls and operating states together. A local LED test proves the output hardware; a plausible raw value does not prove the whole mapping. Comparing every stage connects those separate pieces of evidence.

Distinguish inputs, states and events

An input requests an action. Telemetry reports what the simulator actually exposes. An indicator should therefore follow a confirmed state where possible, rather than simply the last button command sent. A command may have no effect or a different meaning in the current situation.

A state persists until it changes or becomes invalid. An event describes one occurrence. A numeric value also needs a unit and range. Do not treat them identically: a continuously true state must not accidentally trigger a fresh keypress for every packet, while a one-off event must not become a permanent on state without an explicit rule.

Keep a complete record for each mapping

Invented field names are useful in a design only when labelled as your own terms. Do not copy a DCS identifier, BMS bit mask or another simulator’s variable because its name sounds appropriate. Meaning can depend on aircraft, adapter and version.

A conceptual example with checkable numbers

Assume a confirmed source supplies speed in metres per second and the display needs kilometres per hour. Then km/h = m/s × 3.6. A controlled input of 25 m/s must produce 90 km/h; 0 m/s must produce 0 km/h. This is an illustrative calculation, not a statement about the unit of a particular Cockpit Suite field.

If a graphical scale maps 0–180 km/h to 0–100 percent, 90 / 180 × 100 gives 50 percent. Check minimum, midpoint and maximum separately. Explicitly decide what happens outside the range: mark it, limit the output or choose another range. Clamping a pointer should not silently conceal an invalid input.

Round at the presentation stage where possible. A double unit conversion or lost sign can look convincing at a few values, so one ordinary operating value is not a strong test. The telemetry guide helps establish the source before choosing a formula.

In your own Arduino firmware, the data type also matters: map() uses integer arithmetic, truncates fractional parts and does not automatically clamp the result to the target range. Check these properties of the function you use; this does not describe Cockpit Suite’s internal implementation.

Define conditions and thresholds deliberately

A warning may require both a measurement and a confirmed operating state. Write the rule in ordinary language before implementing it: “Activate the indicator when the value meets its limit and the relevant system is active.” First check whether the source already provides the warning state; recreating it is not automatically more accurate.

In a purely conceptual example, an indicator could turn on as a value rises to 80 and turn off as it falls below 78. Those different thresholds provide hysteresis against repeated switching near one boundary. They are not real vehicle or warning-system values. Define the initial state and exact-boundary behaviour too. Delays or smoothing must not silently remove transitions you need to see.

Treat zero, missing and stale data separately

Zero can be a valid value. Missing data means you cannot make a reliable statement, while the last valid value may now be stale. Define separate start-up, pause, disconnection and recovery behaviour. A neutral message or visibly invalid state is often clearer than an apparently current number.

Choose a suitable age criterion when timestamps are available. One universal timeout cannot suit every source. Record whether updates continue during pause and whether their meaning remains unchanged. Reconnection must not inadvertently replay an old button command; display states should instead be rebuilt from current information.

Use the right simulator and profile combination

Shared software reduces repeated work but does not replace a suitable source. Cockpit Suite supports available Falcon BMS and DCS F-16C integrations; War Thunder, ETS2 and ATS are in beta, and LS25 is in development. MSFS and X-Plane adapters are not available. Examples from other projects do not establish additional Cockpit Suite support.

Name profiles by simulator, vehicle or aircraft and purpose. Check a mapping before transferring it to another model. Similar-looking cockpits may expose different data. Separate profiles and traceable sources let several simulators share one software environment while preserving their distinct meanings.

Check expected and actual values

1. Test the output locally using a fixed pattern and label the intended target.
2. Observe the confirmed raw value without conversion and compare its meaning with the documentation.
3. Pass controlled minimum, middle, maximum and invalid inputs through your conversion.
4. Test conditions separately and together, including exact thresholds and direction changes.
5. Change the same function deliberately in the simulator and compare raw value, result and output.
6. Check start, pause, disconnection, recovery and profile changes; record expected/actual results and versions.

This is a test plan, not a claim that hardware testing has already taken place. If one stage fails, examine that stage’s inputs and outputs first. Do not change firmware, formula and profile at the same time.

Trace typical faults to their cause

A constant factor suggests a unit or scaling mismatch. A shifted value may indicate an offset. An inverted lamp requires separate checks of logical meaning and electrical output polarity. An unstable threshold needs examination of the data, rule and intended response. A frozen display first calls for an update check, not more brightness.

The first mapping is ready when its source is verified, its formula is understandable and planned normal and failure cases produce clear states. In the forum, share raw input, expected result, actual output and versions. We aim to help on the same day where possible. Such traceable examples from Europe and the wider community show what works and where this young project can progress together.

Explore the next layer