Target Configuration

All targets must be configured at the same time. If only one target requires updated settings, the other targets must be provided for by a copy of their current settings, which will be applied at the same time as the updated target.

Target Configuration Modes

Send configurations to the RTG in the following ways:

  • Live Mode—Sends a single configuration to the RTG.
    • Can be used repeatedly to send a single target configuration to the system multiple times.
    • Supports sending configurations up to 1 kHz update rate.
    • Useful when interfacing with external hardware, such as a scenario generator.
    • Useful when using the soft front panels for performing manual verifications.
  • List Mode—Provides configurations to the RTG through CSV file(s). The RTG reads the files and loads them into the system.
    • Useful when a large group of configurations is known ahead of time.
    • Configurations can be broken into multiple files to keep file size manageable.
    Note The RTG system memory is limited. If the number of configurations is too large, the RTG software continually monitors and adds more configurations as space becomes available until all configurations are loaded. The RTG system has been verified to support at least 10 million configurations with an update rate of 15 kHz.
  • Target Motion Mode—Configures the RTG to create a linear ramp for any delay, attenuation, or frequency shift though a configurable scenario length.
    • Configurations are sent to the RTG system at a user-configurable fixed update rate (up to 15 kHz).
    • Provides a simple way to create dynamic scenarios.

    • Configuration Synchronization

    The target configurations must be applied at the correct time. There are six supported methods to specify configuration synchronization. Each configuration can use its own synchronization method.

    Figure 1. RTG Triggers


  • Software Trigger—This synchronization method waits until the RTG system receives the software trigger command from the user.
  • External Trigger—The RTG supports triggers from the VST’s PFI0 line or through the PXI backplane triggers. Configure the external trigger in the API as a hardware trigger source and in the INI file as pxi_trigger_input.
  • Relative to Pulse Rising Edge—The RTG system detects the rising edge of an input radar pulse. A configuration can be applied a configurable amount of time after this detected edge. This method can help reduce making changes to a target configuration while a target is actively being generated.
  • Relative to Pulse Falling Edge—The RTG system detects the falling edge of an input radar pulse. A configuration can be applied a configurable amount of time after this detected edge. This method can help reduce making changes to a target configuration while a target is actively being generated.
  • Relative to First Trigger—Schedules a trigger at a fixed time after the first trigger of a scenario. This is useful when having a configuration update at a fixed interval relative to an initial alignment trigger. You can also use this method to send a configuration that is applied immediately. By setting the time offset for this synchronization to 0—which means 0 seconds after the first trigger—the configuration is applied immediately because the scenario will already be more than 0 seconds after the initial configuration update.
  • Relative to Last Trigger—Schedules a trigger at a fixed time after the last trigger of a scenario. Use this method to create a fixed update rate.

    • Selecting Target Attenuation and Delay

    When configuring the RTG, you should choose target configuration values that reflect the attenuation and timing of the fully operational radar and real targets in the field. RTG software has methods to configure external attenuation and delay so that a single configuration file can be used in every connection setup. This allows changing the connections and while still using the same pre-build target configuration CSV files.

    Figure 1. Target Attenuation and Delay


    For example, for a given instance, a target produces a return 110 dB of attenuation. This is a function of free-space path loss (FSPL), radar cross-section (RCS), and environmental conditions. A single configuration can replicate that condition regardless of how the RTG is connected to the DUT. Possible connection options include:

  • Over-the-air—Where the entire radar assembly is being tested. This would involve an air gap and antennas to collect/transmit RF. Some important factors to consider:
    • Tx and Rx antenna gain of the antennas connected to RTG
    • Distance of air gap
    • Any estimate of atmospheric attenuation in that air gap
    • Any additional attenuation between the antennas and RTG
  • Cabled to the antenna interface ports—In this case, only the physical antenna is being bypassed.
    • Effects from radar Tx/Rx antenna gain
    • Any required external attenuation to protect the VST input
  • Cabled at the radar's RF front end—Bypassing level control. Similar to above but compensating for removal of level control.

    • Through calibration and external attenuation and delay settings, the RTG has knowledge of all losses in the system. It can then adjust the RTG-provided settings to compensate for the different connection options to provide a consistent loss and delay.