Choose one observable quantity
Select a value that you can change gradually and compare with an existing indicator in the simulator. RPM, altitude or a clear on/off state may be suitable, depending on the supported adapter. Write down what should change and what you expect when the session stops. Do not select a field solely because its name sounds familiar.
Telemetry here means information coming from the simulator. An input command travels in the other direction. An LED, motor or external instrument additionally requires its own output integration. These routes can work together, but each needs separate evidence. Start with a visible software value before involving physical outputs.
An official SDK may contain several interfaces. SCS documents telemetry and also basic input-device support in its SDK. That does not mean that each telemetry value can also be used as a command to change the simulated vehicle.
Break the route into observable stages
Follow the value from simulator state to documented source, matching adapter, received value and presentation. A network client adds another stage when a second computer is involved. A second screen connected to the same PC does not, by itself, create a network requirement.
You need an observation at every boundary. A “connected” label may describe only a program connection, without establishing that the simulator is providing fresh, valid data. Use the table to decide what to verify before moving downstream.
| Stage | Useful evidence | What it does not establish |
|---|---|---|
| Source | The expected quantity is provided by the simulator. | Correct receipt by the adapter. |
| Adapter | A received value changes as expected. | Correct units and scaling in the display. |
| Presentation | The value and label agree with the simulator. | Operation of a real LED or motor. |
| Hardware output | The particular output has been checked separately. | Compatibility of other devices or profiles. |
Record meaning, units and validity
Before the first attempt, record the simulator and Cockpit Suite versions, module, profile and computers involved. Preserve working settings through the supported backup facilities. Give the test configuration its own name and change one thing at a time. The record should identify the state you actually checked; “latest version” is not precise enough later. Establish what the existing setup does before introducing another component.
Create a small reference entry for the chosen value: documented name, meaning, unit, expected range and conditions under which it is valid. Zero might represent a real state or appear when data is unavailable; the particular source must explain which applies. The same care is needed for percentages, normalised values and timestamps.
Follow the matching adapter’s instructions. An active cockpit session may be required while a menu does not yet provide useful flight data. Do not import an export file from a different simulator version. Existing DCS exports need backups and documented coexistence; replacing an entire Export.lua is not a general installation method.
Inspect the received value before styling it
Start a suitable simulator session and open the provided data view. Find the selected value and observe it before adding extra conversion. Change the quantity gradually, hold a state briefly and return towards the starting point. Record both the simulator state and the received value. This makes a wrong unit or a frozen signal easier to recognise.
Only then assign the value to an instrument. Check its label, unit and meaningful display range. If conversion is needed, record the input quantity, calculation and output unit. A smoothly moving needle is not evidence that its indication is correct.
For an additional computer, verify the same known value locally first and then on the client. Add hardware output after that comparison. Each extension then has a clear starting point, so you can identify which new stage introduced a problem rather than changing the whole installation.
Example: prove RPM on screen first
Suppose you eventually want an RPM LED strip for ETS2. Begin with a software RPM indicator and a supported beta configuration. Compare three distinct states, such as engine stopped, idle and a modest RPM change in an appropriate game situation. The reference is the simulator, not a numerical range copied from somebody else’s video.
Once the value is understood, decide which thresholds an indicator should use. State whether each threshold means actual revolutions per minute or a normalised proportion. A later LED output needs a supported output device and separate configuration. Receiving telemetry does not operate an arbitrary controller board.
An English forum question about obtaining DCS motion data illustrates the earlier problem of finding the source before building a receiver. It does not document a current universal export recipe. When changing simulator, repeat the source and adapter check rather than assuming that similarly named values share an interface.
Check change, interruption and recovery
Compare several states rather than accepting one plausible number. Verify that the display follows changes in the correct direction and returns to a sensible reading. Then observe what happens when leaving the session and entering again. A retained last value must not quietly be mistaken for a fresh measurement.
Document the intended behaviour when data is missing, within the capabilities of the actual software: for example, a visible interruption or neutral presentation. Do not invent an update frequency or a real-time guarantee. A smooth visual impression cannot establish a fixed latency without an appropriate measurement.
At this point you have accepted only the observed value in the tested configuration. Other quantities may have different units, validity conditions or availability. Apply the same short procedure before using them to populate a complete instrument group or to influence an output device.
Distinguish missing, stale and incorrectly scaled data
If all values are absent, check the session, selected adapter and its documented setup. If a received value changes but the instrument does not, inspect the assignment and presentation. If the display changes by the wrong factor, examine units and conversion. If the software display works but an LED does not, begin with the separate output route.
When several export tools are installed, inspect their documented coexistence and the configuration actually in use. Preserve existing files instead of replacing them with a complete example from elsewhere. Explanations about restricted or unavailable data must apply to your particular session and version.
An old forum answer is a useful lead, not evidence of the current cause. Identify the last stage that definitely works and continue from there. Avoid changing the adapter, display, network and output configuration in a single attempt.
Reuse a value whose meaning is known
Save the reference entry with the tested configuration. A later second display or documented hardware output can then use the same quantity without guessing its meaning again. A detached instrument or a clearly bounded output module is a sensible next step after this small check.
Cockpit Suite aims to bring many cockpit tasks into one software environment. The actual scope depends on the simulator: Falcon BMS and DCS F-16C are available; War Thunder, ETS2 and ATS are in beta; LS25 is in development without GIANTS approval in place. There are currently no available MSFS or X-Plane adapters. Check the compatibility overview before building around a particular feature.
For a forum question, a clear expected result, the first failing step and the relevant versions are more useful than a large, unstructured collection of files. We aim to help the same day where possible; late or complex questions may take longer. Cockpit Suite is a young project with existing software. Clear experiences from the European and wider international community help us document further combinations. Even a small result is valuable when someone else can understand how it was obtained.
Sources and documentation
The steps and acceptance checks are our own recommendations. Community posts document particular questions, not universal fixes. Technical statements refer to the listed documentation; check its version before making changes. Sources accessed 18 October 2026.
- Can I get telemetry data from DCS?Local discussion; historical details and suggested fixes require separate verification.
- SCS: Telemetry SDKEnglish; primary technical documentation. It does not establish general Cockpit Suite compatibility.