Implementing a VITA 49 (VRT) streaming option requires transitioning the simulator from a batch-processing file-output model to a real-time network-output model. This transition necessitates architectural modifications across several areas of the codebase.
1. Real-Time Synchronization
The SimulationEngine currently processes the event queue without wall-clock constraints, advancing simulated time as rapidly as CPU resources allow. Hardware emulation requires a pacing mechanism to throttle data output to match real-time. This requires a synchronization layer to buffer or delay output when computation outpaces real-time. Additionally, a mitigation strategy (such as packet dropping or error generation) must be defined for scenarios where computational load causes the simulation to fall behind real-time.
2. Continuous Wave (CW) and FMCW Data Processing
In the current architecture, SimulationEngine::processStreamingPhysics calculates and stores all CW and FMCW I/Q samples in a single pre-allocated buffer (_streaming_iq_data), which is processed and written to disk only during the shutdown() phase. Network streaming requires refactoring this pipeline to process and dispatch data in discrete, time-bounded chunks during the active simulation loop, rather than aggregating the entire dataset in memory.
3. Pulsed Mode Finalization Pipeline
Pulsed mode currently utilizes a chunked processing model where closed receive windows generate a RenderingJob processed by runPulsedFinalizer. To support network output, the processing::pipeline requires an abstraction layer for the output destination. This layer will route finalized I/Q buffers to either the existing HDF5 file writers or a new network dispatcher.
4. VITA 49 Protocol and Network Transport
A new network module must be introduced to handle VITA 49 Radio Transport (VRT) formatting and UDP transmission. This module will encapsulate finalized I/Q buffers with VRT headers, timestamps, sequence numbers, and trailers. To prevent network I/O latency from blocking the physics engine, this transmitter must operate on a dedicated thread, consuming data from the finalizer threads via a thread-safe queue or ring buffer.
5. Configuration and Schema Modifications
The XML schemas (fers-xml.xsd, fers-xml.dtd) and JSON parsers require updates to define network routing parameters. New attributes must be added to receiver definitions to specify output types, destination IP addresses, ports, and VRT stream IDs. The core::Config and params::Parameters structures must be expanded to propagate these settings to the output dispatchers.
6. Memory Projection and Indefinite Execution
The current memory projection logic (projectSimulationMemory) calculates the required footprint based on a fixed simulation duration (endTime). Supporting continuous, indefinite network streaming requires modifying this logic to calculate the steady-state memory footprint of the active ring buffers rather than the total aggregated data volume.
Summary of Primary Requirements
The implementation depends primarily on establishing a wall-clock synchronization mechanism, refactoring continuous-wave data into discrete processing chunks, and introducing an asynchronous network transport layer.
Implementing a VITA 49 (VRT) streaming option requires transitioning the simulator from a batch-processing file-output model to a real-time network-output model. This transition necessitates architectural modifications across several areas of the codebase.
1. Real-Time Synchronization
The
SimulationEnginecurrently processes the event queue without wall-clock constraints, advancing simulated time as rapidly as CPU resources allow. Hardware emulation requires a pacing mechanism to throttle data output to match real-time. This requires a synchronization layer to buffer or delay output when computation outpaces real-time. Additionally, a mitigation strategy (such as packet dropping or error generation) must be defined for scenarios where computational load causes the simulation to fall behind real-time.2. Continuous Wave (CW) and FMCW Data Processing
In the current architecture,
SimulationEngine::processStreamingPhysicscalculates and stores all CW and FMCW I/Q samples in a single pre-allocated buffer (_streaming_iq_data), which is processed and written to disk only during theshutdown()phase. Network streaming requires refactoring this pipeline to process and dispatch data in discrete, time-bounded chunks during the active simulation loop, rather than aggregating the entire dataset in memory.3. Pulsed Mode Finalization Pipeline
Pulsed mode currently utilizes a chunked processing model where closed receive windows generate a
RenderingJobprocessed byrunPulsedFinalizer. To support network output, theprocessing::pipelinerequires an abstraction layer for the output destination. This layer will route finalized I/Q buffers to either the existing HDF5 file writers or a new network dispatcher.4. VITA 49 Protocol and Network Transport
A new network module must be introduced to handle VITA 49 Radio Transport (VRT) formatting and UDP transmission. This module will encapsulate finalized I/Q buffers with VRT headers, timestamps, sequence numbers, and trailers. To prevent network I/O latency from blocking the physics engine, this transmitter must operate on a dedicated thread, consuming data from the finalizer threads via a thread-safe queue or ring buffer.
5. Configuration and Schema Modifications
The XML schemas (
fers-xml.xsd,fers-xml.dtd) and JSON parsers require updates to define network routing parameters. New attributes must be added to receiver definitions to specify output types, destination IP addresses, ports, and VRT stream IDs. Thecore::Configandparams::Parametersstructures must be expanded to propagate these settings to the output dispatchers.6. Memory Projection and Indefinite Execution
The current memory projection logic (
projectSimulationMemory) calculates the required footprint based on a fixed simulation duration (endTime). Supporting continuous, indefinite network streaming requires modifying this logic to calculate the steady-state memory footprint of the active ring buffers rather than the total aggregated data volume.Summary of Primary Requirements
The implementation depends primarily on establishing a wall-clock synchronization mechanism, refactoring continuous-wave data into discrete processing chunks, and introducing an asynchronous network transport layer.