Skip to content

XML Receiver Loading

David Young edited this page Apr 30, 2025 · 1 revision

Description

This functionality parses the <receiver> element within a FERS XML configuration file. It extracts the receiver's name, references to its associated antenna and timing models, and specific parameters like noise temperature, output window settings (length, PRF, skip samples), and simulation flags (e.g., disabling direct path calculation, disabling propagation loss effects).

Based on the parsed information, it performs the following actions:

  1. Creates a Receiver object instance.
  2. Looks up the specified Antenna and Timing objects by name within the simulation World.
  3. Assigns the found dependencies (Antenna, Timing) to the Receiver object.
  4. Sets various properties on the Receiver object based on the child elements found in the XML (noise temperature, window parameters, flags).
  5. Adds the fully configured Receiver object to the simulation World.

Assumptions

  • Assumes the input XML file contains a structurally valid <receiver> element according to the expected FERS schema/DTD.
  • Assumes the Platform object (representing the receiver's physical location/motion) and the World object passed into the parsing function are valid and correctly initialized.
  • Assumes the Antenna and Timing objects referenced by name within the <receiver> element have already been defined earlier in the XML and successfully added to the World.
  • Assumes the World::findAntenna and World::findTiming methods will successfully return valid pointers to the requested objects based on the provided names.
  • Assumes helper functions (like get_child_real_type, get_child_bool) correctly parse the text content of child elements into the appropriate C++ data types (e.g., double, bool).
  • Assumes the <noise_temp> child element is optional; parsing logic correctly handles its absence (e.g., using a try-catch block or default value).
  • Assumes the boolean flags (<nodirect>, <nopropagationloss>) default to false if the corresponding XML child elements are missing.
  • Assumes the Timing::initializeModel method, called during setup, works correctly based on the referenced timing configuration.

Limitations

  • Dependency Name Matching: Relies solely on exact string name matching to find associated Antenna and Timing objects within the World. This is brittle and prone to errors from typos in the XML configuration.
  • Dependency Lookup Handling: The parseReceiver function itself doesn't explicitly check if World::find* returns null pointers before attempting to use them (although the downstream setter methods like Receiver::setAntenna might perform checks and throw exceptions).
  • Parameter Range Validation: No validation of the numerical ranges for parameters like <window_length>, <prf>, or <window_skip> occurs during the XML parsing stage. Invalid values might only be caught later during simulation setup (e.g., quantization in Receiver::setWindowProperties) or potentially lead to runtime errors or unexpected behavior.
  • XML Order Dependency: The corresponding Antenna and Timing objects must be defined before the <receiver> element that references them within the XML file structure for the name lookup to succeed during parsing.

Related Components

  • Core Classes: Receiver, World, Antenna, Timing, Platform
  • Parsing Logic: xml_parser::parseReceiver (in xml_parser.cpp)
  • Object Creation: Receiver constructor
  • Dependency Lookup: World::findAntenna, World::findTiming
  • Property Setting: Receiver::setAntenna, Receiver::setTiming, Receiver::setNoiseTemperature, Receiver::setWindowProperties, Receiver::setFlag
  • World Integration: World::addReceiver (or similar method in World to store the created receiver)
  • XML Element: <receiver> and its child elements (<antenna>, <timing>, <noise_temp>, <window_length>, <prf>, <window_skip>, <nodirect>, <nopropagationloss>)

Validation Status

  • Needs Verification: Yes. While basic scenarios likely exercise this code, specific validation focusing solely on the parsing logic and edge cases is needed.
  • Key Areas for Validation:
    • Correct parsing of all specified attributes and child elements.
    • Robust handling of optional elements (e.g., <noise_temp>).
    • Correct application of default values for missing boolean flags (<nodirect>, <nopropagationloss>).
    • Error handling when referenced Antenna or Timing names are not found in the World.
    • Behavior when numerical values in child elements are invalid or out of expected ranges (though explicit range validation is noted as a limitation).
    • Verification that the Receiver object added to the World has all properties set correctly according to the XML input.
  • Priority: Medium (Core setup functionality, but potential issues are often caught downstream or lead to obvious configuration errors).

Clone this wiki locally