Introduction
With Tacview Advanced and above, you can stream telemetry data in real time using the public protocol described in this documentation. This feature is extremely useful to monitor a battle taking place in a flight simulator in real time, and will later be extended to real aviation so you can watch a flight currently in progress using smartphones and/or low-cost data recorders.
Just like the acmi format 2.x, Tacview real-time telemetry protocol has been designed to be very easy to use. It is a pure UTF-8 text protocol that can be implemented using most programming languages, including scripting languages such as Lua. After a simple handshake (connection) with Tacview, the data stream will be continuous, compact, and reliable, thanks to TCP/IP.
Real-time Telemetry Protocol 101
Simply put, the real-time telemetry protocol uses a TCP/IP socket to transmit sequential uncompressed ACMI 2.x data.
The third-party application is the host of the session and Tacview is a client. In other words, the third-party application hosts a session waiting for one or more Tacview clients to join and review the data in real time. For example, multiple remote and local Tacview clients can connect simultaneously to exporters written for DCS World, FSX, and X-Plane.
The first part of the communication is called handshaking. It is an exchange of data used to ensure that both the host and Tacview speak the same protocol. It includes each party’s username and the password hash required to join a protected session. The username can contain any UTF-8 character except control characters such as \n.
If any party is not satisfied with the handshake data, it can close the connection with a clean socket shutdown.
As soon as both parties agree on the protocol and password hash, telemetry transmission can start. Here is an example of data exchanged between the host and a client:
Handshake data sent by the Host (data generator such as DCS2ACMI)
XtraLib.Stream.0␊
Tacview.RealTimeTelemetry.0␊
Host username␊
␀After establishing a socket connection, the host sends the low-level protocol and version XtraLib.Stream.0 followed by the high-level protocol Tacview.RealTimeTelemetry.0. The next line contains the host username for display, and the final line is empty because the host does not send the session password hash.
Each line (except the last) ends with a \n character. The handshake packet ends with a terminal \0. Tacview exporters or clients will drop the connection if the handshake takes too long.
Handshake data sent by the Client (data receiver such as Tacview.exe)
XtraLib.Stream.0␊
Tacview.RealTimeTelemetry.0␊
Client username␊
0␀Once connected, the client sends similar data — including the password hash if required. If no password is needed, the hash is ignored. If it is required but mismatched, the socket is closed. The password hash uses CRC-64-ECMA of the UTF-16 password (excluding '\0').
Neither the host nor the client explicitly communicates the rejection reason. They may close the socket at any time. Once the host approves the connection, it immediately starts sending data — no keep-alive or request packets are required.
Incoming data from the host (header)
FileType=text/acmi/tacview␊
FileVersion=2.2␊This corresponds to Tacview acmi format 2.x. The transmitted data matches the uncompressed ACMI file content.
Incoming data from the host (metadata)
0,ReferenceTime=2017-05-01T05:27:00Z␊
0,RecordingTime=2017-03-09T16:17:49Z␊
0,Title=test simple aircraft␊
0,DataRecorder=DCS2ACMI 1.6.0␊
0,DataSource=DCS 1.5.6.1938␊
0,Author=AuthorName␊
0,ReferenceLongitude=37␊
0,ReferenceLatitude=37␊
40000001,T=4.6789343|5.1865487|2000|617414|-291014,Type=Navaid+Bullseye,Color=Blue,Coalition=Enemies␊
40000002,T=1.987465|8.0833075|2000|371700|11557,Type=Navaid+Bullseye,Color=Red,Coalition=Allies␊To reduce lag, the host should flush a new packet of data every frame so Tacview can replay the data live as it is recorded.
Incoming Data (samples)
#114.76␊
0,Category=CAP␊
101,T=4.8502002|4.9274637|20.26||-0.2|75.9|634576.06|-318348.25|69.9,Type=Air+FixedWing,Name=Su-27,Pilot=Vyrtuoz,Color=Red,Coalition=Allies,Country=ru,Debug=wsType[1.1.1.3],Importance=1,IAS=0,Throttle=0.72,Afterburner=0,AirBrakes=0,Flaps=1,LandingGear=1,Tailhook=0,HDM=63.28␊Tacview automatically adjusts playback timing to maintain smooth performance and synchronization.
Incoming Data (samples continued)
#114.87␊
101,T=4.8502023|4.9274641|||-0.3||634576.25|-318348.19|,HDM=63.29␊Tacview will not drop the connection if the host pauses the stream temporarily — there is no timeout during transmission.
Data Size Optimization
Data Size Optimization
Use \n instead of \r\n to save 1 byte per line.
Avoid redundant data
Avoid redundant data
Use longitude and latitude offsets
If your data fits within a 10x10° sector, use ReferenceLongitude and ReferenceLatitude to reduce coordinate sizes.
Tweak your samples resolution
Export only meaningful digits to reduce bandwidth. Custom printf() functions can avoid useless trailing zeros.
Recommended resolutions:
| Property | Suggested resolution |
|---|---|
| # (frame time) | 0.01 s |
| T (longitude/latitude) | 0.0000001° |
| T (altitude) | 0.01 m |
| T (roll/pitch/yaw) | 0.1° |
| T (flat coordinates) | 0.01 m |
| AGL | 0.01 m |
| HDG | 0.1° |
| IAS | 0.1 m/s |
Optimize export frequency per object type to balance size and latency.
Optimize export frequency per object type to balance size and latency.
| Object Type | Frequency |
|---|---|
| Player aircraft | 10 Hz (up to 16 Hz when remote) |
| Weapon | 8 Hz |
| Air objects | 5 Hz |
| Projectile / Bomb / Decoy / Ground | 2 Hz |
| Other objects | 1 Hz |