Real-Time Flight Telemetry Monitoring with InfluxDB 3 Enterprise

By Heather Downing / Developer
Jul 29, 2025

Navigate to:

When Microsoft Flight Simulator 2024 generates telemetry data at 30-60 FPS, capturing and processing that stream in real-time becomes a fascinating engineering challenge. We built a complete telemetry pipeline that reads over 90 flight parameters through FSUIPC, streams them to InfluxDB 3 Enterprise, and displays them in real-time dashboards that respond in under 5 milliseconds.

This isn’t just about gaming (although it IS fun)—it’s a blueprint for building enterprise-grade aviation telemetry systems that can scale from flight training simulators to operational aircraft monitoring.

The architecture: streaming aerospace telemetry

Our data pipeline uses aerospace simulator data in a realistic testbed for enterprise telemetry systems.

Key Components

Microsoft Flight Simulator 2024: Where the flight telemetry data points originate from

FSUIPC7: Interface to flight simulator memory using the simulator’s SimConnect API

C# Data Bridge: Processes batches of memory block reading with FSUIPC Client DLL for .NET

InfluxDB 3 Enterprise: Time series database with last n-value caching and compaction

Next.js Dashboard: Dual-mode visual app of real-time instruments and historical analysis

Reading flight telemetry data efficiently

Microsoft Flight Simulator exposes hundreds of data points through FSUIPC7 offsets. Reading each individually creates additional overhead of 90+ separate API calls every 16-33 milliseconds.

Solution: Memory Block Strategy

Instead of individual reads, we organized related metrics into logical memory blocks using the FSUPIC Client DLL for .NET:

_memoryBlocks = new Dictionary"string, MemoryBlock"
{    // Position, attitude, altitude
    { "FlightData", new MemoryBlock(0x0560, 48) },
    { "Engine1", new MemoryBlock(0x088C, 64) },
    { "Engine2", new MemoryBlock(0x0924, 64) },    // Flight controls, trim       
    { "Controls", new MemoryBlock(0x0BC0, 44) },
    { "Autopilot", new MemoryBlock(0x07BC, 96) },    // VOR, ILS, navigation
    { "Navigation", new MemoryBlock(0x085C, 32) },
    { "Fuel", new MemoryBlock(0x0B74, 24) },    // Callsign, tail number
    { "AircraftData", new MemoryBlock(0x3130, 72) }
};

Performance Impact:

  • Before: 90+ individual FSUIPC calls per frame = 2,700-5,400 calls/second
  • After: 8 memory block reads per frame = 240-480 calls/second

Each memory block read fetches multiple related parameters in a single operation, dramatically reducing the communication overhead with the flight simulator.

Writing to the database without bottlenecks

Writing individual telemetry points to a database would create a network bottleneck. At 60 FPS with 90+ fields, that’s thousands of individual database writes per second.

Solution: Intelligent Batching

// Batching configuration
MaxBatchSize: 100
MaxBatchAgeMs: 100 milliseconds

The system buffers telemetry points and flushes when either condition is met:

  • Size trigger: 100 rows of line protocol, each row consisting of 91 data points as fields/tags
  • Time trigger: 100 ms elapsed since last flush

Real-World Performance

  • Average write latency: 1.3 ms per row
  • Sustained throughput: Easily handles thousands of metrics per second
  • Data consistency: Reliable data collection during extended testing

This approach captures approximately six complete flight data snapshots per database write operation, maintaining near real-time performance while minimizing database overhead.

Monitoring data visually in real-time

Traditional time series queries for “current” values are expensive. Consider this typical query:

SELECT * FROM flight_data 
WHERE time >= now() - INTERVAL '1 minute' 
ORDER BY time DESC LIMIT 1

This scans recent data, sorts by time, and returns the latest point. This may be acceptable for historical analysis, but too slow for real-time cockpit displays.

Solution: Last Value Cache (LVC)

Data from InfluxDB 3’s built-in Last Value Cache (LVC) drives the Cockpit tab on the dashboard, which displays only the most recent data point. This is good for the current heading, attitude, GPS location, altitude, airspeed, vertical speed, etc.

Using SQL to query the LVC:

SELECT * FROM last_cache('flight_data', 'flightsim_flight_data_lvc')

LVC is an in-memory cache that maintains the most recent values for each metric (at the time of the last WAL flush), enabling instant access without a storage layer round-trip.

LVC Configuration for Flight Data:

influxdb3 create last_cache \
  --database flightsim \
  --table flight_data \
  --key-columns aircraft_tailnumber \
  --value-columns flight_altitude,speed_true_airspeed,flight_heading_magnetic,flight_latitude,flight_longitude \
  --count 1 \
  --ttl 10s \
  flightsim_flight_data_lvc

Performance Transformation:

The LVC enables cockpit displays that update at 5 FPS (200 ms intervals) while users experience them as instantaneous. The database typically returns the LVC row in less than 10 milliseconds.

Optimizing storage for streaming data

High-frequency telemetry creates storage challenges. At 90+ fields × 60 FPS, we generate thousands of data points per second, creating hundreds of small files that hurt query performance. It’s time to save some space and optimize our query performance!

Flight Sim Data Compaction Strategy

We set the following environment variables to configure our InfluxDB server:

# COMPACTION OPTIMIZATION
INFLUXDB3_GEN1_DURATION=5m
INFLUXDB3_ENTERPRISE_COMPACTION_GEN2_DURATION=5m
INFLUXDB3_ENTERPRISE_COMPACTION_MAX_NUM_FILES_PER_PLAN=100

# PERFORMANCE TUNING
INFLUXDB3_DATAFUSION_NUM_THREADS=16
INFLUXDB3_EXEC_MEM_POOL_BYTES=40%
INFLUXDB3_PARQUET_MEM_CACHE_SIZE=40%

# REAL-TIME DATA ACCESS
INFLUXDB3_WAL_FLUSH_INTERVAL=100ms
INFLUXDB3_WAL_MAX_WRITE_BUFFER_SIZE=200000

Why These Settings Work Together

Compaction Optimization breaks data into smaller 5-minute files instead of the default 10-minute files. This creates more frequent but smaller cleanup operations that don’t overwhelm the system (we ran this on a Windows gaming laptop that was also running Flight Simulator). We also limit how many files get processed at once (100 vs 500 default) to prevent performance spikes. (Learn more about InfluxDB 3’s generation-based compaction strategy.)

Performance Tuning allocates more memory resources for both query execution and Parquet file caching, improving read performance by keeping more data in memory and allowing more parallel query processing threads.

Real-Time Data Access reduces write-ahead log (WAL) flush interval from 1 second to 100 ms, making data available for queries much faster. The increased buffer size accommodates more writes before forcing a flush, balancing throughput with latency.

Measured Results:

  • 142 compaction events automatically triggered over a 24-hour period
  • 85% average reduction in the size of new data written since the previous compaction
  • File optimization: Significant reduction in file count (example: 127 small files → 18 optimized files)
  • Query performance: Faster historical data access due to fewer files and improved data organization

Our monitoring system polls the database directory size every 10 seconds. In the graph above, you can see decreases in disk usage, which indicate WAL file deletions after the snapshot, and compaction events that reorganize the data into Parquet files for faster querying. This is available to view on the Data tab of the dashboard.

Disk Usage Comparison: InfluxDB 3 Core vs Enterprise

In order to differentiate between disk space savings due to WAL file deletion and data compaction into the Parquet files, we compared the performance of InfluxDB 3 Core and Enterprise; compaction is an Enterprise-only feature. While Core registered a disk usage drop every 15 minutes, Enterprise did so more often. For a fair comparison, we compared both at the 15-minute mark and found:

  • Core dropped from around 500MB to 230MB due to WAL file deletion
  • Enterprise dropped from around 160MB to 30MB due to both WAL file deletion and compaction

Enterprise’s starting size was lower because it had already gone through previous deletion/compaction events, but we can determine from these numbers that without compaction or WAL file deletion, we would have 500MB of data. WAL file deletion reduces this by 54% to 230MB. Compaction then brings that 230MB down to 30MB—an 87% reduction from compaction, for a 94% total reduction overall.

NOTE: These percentages represent savings of new data written since the directory size last dropped and are sequential, not compounding.

Two-tier dashboard architecture

The Next.js dashboard demonstrates two patterns for different use cases:

Cockpit Tab: Real-Time Instruments

Uses LVC for instant current values, perfect for simulating aircraft instruments:

// Based on an LVC of the `flight_data` measurements in the
// `flightsim` bucket  called `flightsim_flight_data_lvc`
// with a key column of `aircraft_tailnumber` and the fields
// `flight_altitude`, `speed_true_airspeed`,
// `flight_heading_magnetic`, `flight_latitude`,
// `flight_longitude`, `speed_vertical`,
// `autopilot_heading_target`, `autopilot_master`,
// `autopilot_altitude_target`, `flight_bank`, `flight_pitch`,
// `aircraft_airline`, `aircraft_callsign`, and `aircraft_type`
const q = ```
  SELECT * FROM last_cache(
    'flight_data', 'flightsim_flight_data_lvc')`;

// Send the query to the InfluxDB server REST endpoint
const dataResponse =
  await fetch(`${endpointUrl}api/v3/query_sql`, {...});

Displays:

  • Current heading
  • Altitude
  • Airspeed
  • GPS coordinates
  • Attitude
  • Autopilot settings

Performance: Sub-10 ms database response enables smooth 5 FPS updates that feel real-time to the person monitoring visually.

Uses traditional SQL queries for historical analysis and system monitoring:

SELECT * FROM flight_data 
WHERE time >= now() - INTERVAL '1 minute' 
ORDER BY time DESC LIMIT 20

Features:

  • Recent measurements table with metric filtering
  • Database size monitoring over time
  • Compaction effectiveness tracking
  • Historical trend analysis

Update frequency: 1-second refresh cycle, appropriate for trend analysis without overwhelming the interface.

NOTE: For a single-client read scenario like ours, reading data directly from object storage is quite performant. However, if your use case requires multiple users or systems to read simultaneously, consider how a Distinct Value Cache (DVC) can add efficiency.

Real-world applications

This project, while a fun challenge and excellent testbed, offers a blueprint for going beyond simulation into operational aviation systems:

Flight Training Organizations

  • Real-time instructor oversight: Monitor student performance during simulator sessions
  • Objective assessment: Data-driven evaluation of flying skills and decision-making
  • Scenario replay: Historical analysis for post-flight debriefing sessions

Aircraft Manufacturers

  • System validation: Test avionics behavior in controlled environments
  • Performance modeling: Compare simulated vs actual aircraft characteristics
  • Pilot training programs: Develop type-specific training curricula

Research and Development

  • Human factors research: Study pilot workload and performance patterns
  • Safety analysis: Investigate scenarios and incidents in controlled settings
  • Technology integration: Test new systems before expensive flight testing

Getting started: complete implementation guide

Ready to build your own real-time flight monitoring system? The complete source code, configuration examples, and setup scripts demonstrate how. Whether you’re developing training systems, research platforms, or just enjoy MSFS, this example provides a good foundation.

Prerequisites

Repository Structure

Hardware Requirements

This demo was developed and tested on a 2025 Alienware 16 Aurora Gaming Laptop running Windows (the only way MSFS is playable) with:

  • Intel Core i7-240H (10-core processor)
  • 64GB DDR5 RAM
  • 2TB NVMe SSD
  • NVIDIA GeForce RTX 5060 (8GB)

The memory-intensive nature of real-time telemetry processing, InfluxDB’s in-memory caching, and Microsoft Flight Simulator 2024’s requirements make adequate RAM the most critical component for smooth operation. While high-end specs aren’t strictly required, we recommend:

  • Minimum: 16GB RAM, quad-core processor, SSD storage
  • Recommended: 32GB+ RAM for optimal InfluxDB 3 Enterprise performance with large datasets
  • Storage: SSD recommended for database performance and flight simulator load times

Results may vary based on hardware configuration and system specifications.

Key Technical Achievements

  • LVC enables true real-time cockpit displays with consistent sub-10 ms query performance.
  • Automated compaction makes continuous telemetry economically viable, which results in an average of 87% storage savings.
  • Memory block reading strategy significantly reduces FSUIPC overhead while maintaining data fidelity.
  • Intelligent batching delivers enterprise reliability with stable operation during extended testing.
  • Microsoft Flight Simulator provides a realistic testbed equivalent to real aircraft telemetry streams.

From gaming to enterprise monitoring, the principles remain the same: efficient collection, smart caching, and automated optimization enable real-time insights at any scale.