Supported Sensors

Delphi ESR 2.5 Ethernet


Supported hardware versions

The driver interface communicates with the sensor over Ethernet and uses the XCP communication protocol.

Manufacturer Delphi
Hardware ID ESR 2.5 Ethernet
Hardware model L2C0051TR
XCP document version 021213_rev1
TCP header version 11
DAQ definition version 2
DSP software version 4.165.11

Sensor background and requirements

Delphi’s multimode ESR combines a wide field of view at mid-range with long-range coverage to provide two measurement modes simultaneously.

While earlier forward looking radar systems used multiple beam radars with mechanical scanning or several fixed, overlapping beams to attain the view required for systems like adaptive cruise control, Delphi’s multimode ESR provides wide coverage at mid range and high-resolution long-range coverage using a single radar.

Wide, mid-range coverage not only allows vehicles cutting in from adjacent lanes to be detected but also identifies vehicles and pedestrians across the width of the equipped vehicle. Long-range coverage provides accurate range and speed data with powerful object discrimination that can identify up to 64 targets in the vehicle’s path.

Hardware requirements

  • 12V power supply
  • Gigabit Ethernet connection to an ECU, or network switch
    • It’s strongly recommended to provide a direct connection from the RADAR to the ECU
  • CAN interface to an ECU
  • ECU with PolySync Core installed

Sensor notes

  • The default sensor IP address is and default port 5555
  • The sensor requires that the radiate command is sent over the CAN interface before it begins publishing data to the Ethernet or CAN interfaces
    • The Core driver for the CAN-based ESR 2.5 is able to send the radiate command
    • The ESR may be configured manually with OEM tools to continuously radiate, and remove the extra interface dependency
  • The data is provided in the sensor-local coordinate frame, and does not use a transform
  • The sensor outputs an XCP message every 25 milliseconds
  • Each message provided by the sensor contains up to 64 target reports
  • All data is provided as-is from the sensor; there are no invalid field macros defined by Delphi

Configuring the ECU

Linux network set up

The Ethernet network must be properly configured before PolySync can communicate with the sensor on the target ECU.

It’s highly recommended to use point-to-point Ethernet communication between the sensor and the ECU to lower the latency. You may connect the sensor to a switch but may be prone to high latency.

Setting the ECUs static IP address

Once the sensors IP address is known, set a static IP address for the ECUs NIC in the same IP subnet range as the RADAR.

For example if the sensors IP address is, it’s said to be on the 169.254.145.X subnet, and the ECU should be configured with IP address 169.254.145.X.

Configuring the PolySync driver

The default PolySync Configurator configuration has shown to work out of the box on most systems.

Adding the sensor to the SDF

Using the Configurator tool, add a sensor node to the SDF.

The Delphi ESR 2.5 Ethernet ‘Node Interface’ name is delphi-esr-ethernet.

Validating the sensor is properly configured

If you’re approaching a new PolySync system or need to validate an existing configuration you can use the following check to ensure the sensor is properly configured.

Set up checklist

If the sensor passes this checklist then the PolySync dynamic driver will likely be able to communicate with the sensor.

  1. Ensure you can ping the sensor at the static IP address
    • Get the IP address from the Configurator node entry and ping the device
      • $ ping
      • 64 bytes from icmp_seq=1 ttl=64 time=0.030 ms
      • ...

Starting the Core driver

The configuration set in the Configurator is loaded from the SDF when the dynamic driver starts. It connects to the sensor through the serial port, requests the data, and waits for confirmation that the sensor configuration is valid.

When the dynamic driver receives the first packet of data, it begins processing and abstracting the data from the OEM data structure in a high-level hardware agnostic message type. In this case the data is placed in a esr_eth_msg_xcp message.

  1. Power the sensor and ECU on
  2. Optionally follow the set up checklist
  3. Start the PolySync Core manager
    • $ sudo service polysync-core-manager start
  4. Start the dynamic driver process

Starting the node manually on the command line

To start a dynamic driver node on the command line, the node must first be defined in the SDF using the Configurator application.

Each node defined in the Configurator has a unique node ID which points to the nodes configuration. This article explains how to find the node ID.

Command line flags and usage

Once the node ID is known (substitute for X), the dynamic driver node for the supported sensor can be started with the base command:

$ polysync-core-dynamic-driver -n X

Each sensor supports an array of command line arguments. To see a full list of command line arguments, pass the -h help flag:

$ polysync-core-dynamic-driver -n X -h  |  less

There’s a lot of output so we recommend you pipe the output to less, but it’s not required.

Flag Description
-h show this help message [optional]
-o reserved [optional]
-w disable the hardware interface(s), allowing the node to run without hardware connected (also known as replay mode) [optional]
-n SDF node configuration identifier for the node [required]
-i use provided PAL interface file instead of what is stored in the SDF [optional]
-e export a JSON support string describing the interface, used by the SDF configuration tool [optional]
-u allow updates to the SDF configuration during the normal runtime if needed (does not exit) [optional]
-p use provided logfile in Record and Replay operations instead of the default [optional]
-s use provided SDF instead of the default [optional]
-U update the node SDF configuration and exit [optional]
-O check the node SDF configuration for required updates and exit option (returns exit status zero if no change required) [optional]
-d enable additional debugging output [optional]
-t perform a validation test on the interface [optional]

Accessing sensor data

When the dynamic driver node is operating in an OK state then data is being published to the global PolySync bus, and any node can subscribe to the high-level message type(s) output by the dynamic driver node.

There are several tools that PolySync provides to quickly validate that data exists on the bus.

Access sensor data with PolySync nodes that subscribe to the sensor’s output message types.

Input / output message types

The Delphi ESR 2.5 Ethernet dynamic driver node outputs the following message types to the bus.

Message Notes
Publishes ps_radar_targets_msg Sensor Data Model
Publishes esr_eth_msg_xcp TBLinked…
Publishes ps_byte_array_msg Not published to the bus by default

RADAR target message fields

The ps_radar_targets_msg message.

Data type Name Description Message field populated by this sensor
ps_msg_header header PolySync message header Yes
ps_sensor_descriptor sensor_descriptor sensor descriptor identifying the publisher Yes
sequence< ps_radar_target > targets Up to 64 targets populated by the ESR Yes

The ps_radar_target structure.

Data type Name Description Message field populated by this sensor
ps_identifier id The track identifier in the sequence of 64 potential tracks reported by the ESR Yes
ps_timestamp timestamp UTC timestamp when this target was received by PolySync Yes
DDS_double position Position of target. Value PSYNC_POSITION_NOT_AVAILABLE means given axis component not available. [xyz meters] Yes
DDS_double size Size of target. Value PSYNC_SIZE_NOT_AVAILABLE means given axis component not available. [xyz meters] No
DDS_double velocity Velocity of target. Value PSYNC_VELOCITY_NOT_AVAILABLE means given axis component not available. [xyz meters/second] No
DDS_double range_rate Range rate (or sometimes the Doppler velocity) of target. Value PSYNC_VELOCITY_NOT_AVAILABLE means not available. [meters/second] Yes
ps_track_status_kind track_status If this target is a track, this provides its status if supported. Value TRACK_STATUS_RAW_TARGET means this is a raw target/measurement and not a track. Yes
ps_range_kind range_type Target range type. Yes
ps_zone_kind zone_type Target zone type. No
ps_quality_kind quality Target quality. No
DDS_double amplitude Target amplitude. Value PSYNC_AMPLITUDE_NOT_AVAILABLE means not available. [decibels] Yes
DDS_double magnitude Target magnitude. Value PSYNC_MAGNITUDE_NOT_AVAILABLE means not available. [decibels] No
DDS_double alias Target range rate alias (or sometimes the Doppler alias) of target relative to the parent coordinate frame. Value PSYNC_VELOCITY_ALIAS_NOT_AVAILABLE means not available. [meters/second] No
DDS_double cross_section Target radar cross section. Value PSYNC_RADAR_CROSS_SECTION_NOT_AVAILABLE means not available. [meters^2] No
DDS_unsigned_long scan_index Target scan index. Value zero means unknown or not available. Yes

XCP message fields

The sensor populates all fields in the esr_eth_msg_xcp message.

Data type Name Description
ps_msg_header header PolySync message header.
ps_sensor_descriptor sensor_descriptor Sensor descriptor.
ps_timestamp timestamp Image timestamp.
esr_eth_xcp_version xcp_version XCP format version.
unsigned short scan_index The scan index.
unsigned short tcp_size The size of the XCP TCP data.
esr_eth_xcp_scan_type xcp_scan_type XCP scan type.
unsigned short look_index The look index.
unsigned short can_mmr_scan_index The CAN MMR scan index.
short target_report_host_speed The host vehicle speed. [1128 meters/second]
short target_report_host_yaw_rate The host vehicle yaw rate. [1128 degrees/second]
unsigned long xcp_timestamp The XCP timestamp.
octet release_revision DSP software version #1
octet promote_revision DSP software version #2
octet field_revision DSP software version #3
unsigned short target_report_count Number of target reports.
sequence<esr_eth_target_report> target_reports The target reports.

Filtering incoming data for this sensor

An application that subscribes to a given message type is able to see data from more than one sensor or source.

Applications can filter for specific sensors and data sources in the message callback in C applications, or the messageEvent in C++ applications.

Filter incoming messages for this sensor with ps_sensor_kind value 132.

You can find all sensor descriptor values in this article.