Connecting a simulator or sensor

A connector is whatever carries data from a simulator, a sensor or another tool into HEAT. HEAT has no single connector product. It has several documented paths, and you choose one by what the source can produce.

Every path ends the same way. The data lands on the input node of a Session, and the session template takes over from there. HEAT does not change the source system. It reads what the source writes, sends or broadcasts.

This page does not cover the storage locations HEAT calls data sources. Those are where data is kept after it arrives.

Choosing a path

Choose the first row that fits. Each step down the table gives richer, time-stamped data and costs more integration work.

File upload

Any software that can make an HTTP request can send data to HEAT. It creates a session from a session template and uploads raw bytes to an input node. The APIs page walks through the calls from creating the session to downloading the results.

An ingest removes even that work. An operator creates a managed upload URL that is bound to a Project, a session template and an input node. The sender posts a file to the URL and needs no knowledge of the API.

HEAT does not require a schema for uploaded files. The session template decides how a file is read. See Tabular and JSON pipelines for CSV, TSV and JSON.

HEAT Capture

HEAT Capture is the Windows application that records live data during a training run and streams it to HEAT. It stamps everything it receives on one clock, so data from a simulator, an eye tracker and a microphone line up on a common timeline. See HEAT Capture for installation and operation.

A capture module reads one kind of source. The module catalogue lists the published modules, which cover eye trackers, heart rate and other wearables, game controllers, microphones, flight simulators and network protocols. Each module has a data page that says what it publishes and an interface control document (ICD).

A capture plugin runs inside a third-party simulator and publishes frames to HEAT Capture. Plugins are published for MACE, Unreal Engine and VBS4. See Capture plugins.

Two modules need no vendor software at all. The folder upload module publishes every file that appears in a watched folder. The Open DIS module listens for DIS PDUs and records them as they arrive.

A custom publisher

When no module or plugin fits, write a small program that publishes to HEAT Capture directly. This path is fully documented. It needs a running HEAT Capture and the ProtoLib package for your language.

1. Build your messages with HEAT ProtoLib. It defines the simulation data model as Protocol Buffers schemas and provides builder libraries for C#, C++, Python and Rust. See Consume the packages and the message reference.
2. Open the frame publish WebSocket of HEAT Capture and send each message as one binary WebSocket message. The contract is interface IF-CAPTUREAPP-02 in the HEAT Capture ICD.
3. Run a capture session. HEAT Capture stamps each message, stores it and streams it to HEAT with everything else in the session.

The ICD states the limits that matter to a publisher. A user must be signed in to HEAT Capture, a message may be up to 10 MiB, and a message sent while no session is running is discarded.

Open standards in use

After the data arrives

A connector only delivers data. What HEAT does with it is set by the session template.

• Capture session templates covers protobuf streams from HEAT Capture.
• Tabular and JSON pipelines covers uploaded files.
• Build your first data flow takes one small CSV from upload to dashboard.

Related

• APIs
• Capture for developers
• Offline tokens for capture machines that cannot sign in each time
• Ingests

HEAT documentation team. Last updated 2 October 2026.