How a Centralized Architecture Breaks the Radar Edge Processing Bottleneck

Automotive radar is running into a compute wall at the sensor. Conventional radar modules carry a microcontroller that processes its own data locally, and that microcontroller now sets the ceiling on what radar can perceive. As OEMs push from L2 toward L3 and L4 autonomy, channel counts rise and raw data volume rises with them, raising an architectural question: what happens when you move signal processing off the sensor node entirely?

Why Edge Processing Is the Bottleneck

In current vehicle designs, radar signal processing is decentralized, with each module handling its own data at the edge using a specialized microcontroller that balances high performance against low cost and power. Dedicated hardware accelerators execute the range, Doppler, and angle fast Fourier transforms (FFTs), after which higher-level algorithms handle object detection, classification, and tracking. What leaves the module is an object list or limited point cloud, transmitted to the ADAS ECU over a low-bandwidth interface such as CAN-FD or 100 Mb/s Ethernet.

Figure 1. Edge-based sensor delivering object list information. Image used courtesy of Infineon

However, the imbalance sits between what the MMIC can capture and what the microcontroller behind it can process. Frequency-modulated continuous wave (FMCW) radar monolithic microwave integrated circuits (MMICs) are the standard for digitizing environmental data, but edge MCUs, balanced across speed, memory, and power, have become the bottleneck for generating rich, high-definition point clouds. Running advanced model-based processing on them, including AI or machine learning, requires performance exceeding several tera-operations per second (TOPS) that prohibitively increases the module's power consumption and cost.

Furthermore, because manufacturers standardize on suites of multiple radar sensors, even small per-unit cost reductions can affect the final vehicle price. At the same time, modules that draw more power increase the vampire drain on the main battery, working against the range targets that influence electric vehicle adoption.

Another limitation is architectural. Because each radar unit processes independently and emits an abstracted object list, true sensor fusion is precluded before the data reaches the ECU. The result is a performance plateau dictated by strict cost and thermal envelopes, one in which radar point clouds lack the density and precision found in LiDAR or vision-based systems.

Figure 2. Point cloud density on the same simulated scenario: edge processing (left) versus central processing (right). Image used courtesy of Infineon

How Centralized Raw ADC Architecture Works

The alternative is to strip the radar sensor down and move the compute. High-speed signal processing can be offloaded entirely by using a centralized raw analog-to-digital converter (ADC) architecture, leaving the edge node with a millimeter-wave (mmWave) MMIC for RF transmission and reception, a lightweight housekeeping MCU for configuration, health monitoring, and basic control, a PMIC, and, where necessary, optional non-volatile memory that can hold calibration data and device-specific parameters.

Figure 3. Centralized radar architecture block diagram. Image used courtesy of Infineon

Raw ADC samples stream from the satellite sensor to the central ADAS ECU over a high-speed asymmetric link, using either of two options: SERDES, already a high-volume standard in automotive cameras, or asymmetric Ethernet, now being standardized and adopted. This low-power approach carries power and data over a single coaxial or Ethernet cable. Power-over-Coax or Power-over-Ethernet delivery is managed by a dedicated PMIC that ensures stable voltage regulation and electromagnetic compliance, reducing wiring harness complexity and vehicle weight. At the receiving end, a deserializer or asymmetric Ethernet interface based on the emerging IEEE 802.3dm asymmetrical automotive Ethernet standard reconstructs the stream for the central processor, while control commands and configuration updates flow bidirectionally across the same link, supporting over-the-air (OTA) updates and calibration.

The power arithmetic is what makes the topology viable. Taking a four-transmit, four-receive (4Tx4Rx) radar sensor as an example, removing the high-performance MCU from the radar head brings typical module power consumption down to approximately 2.5 W. Overall, the centralized approach reduces total power consumption per module by 20% to 40%. That lower dissipation relaxes thermal design constraints, simplifies housing, and improves long-term reliability.

At the other end of the link, the signal chain runs on a central system-on-chip (SoC) exceeding 1,000 TOPS with expansive shared memory. But what resolves the apparent paradox is not the raw number, but where the silicon is located. Several TOPS replicated inside every radar module is prohibitive on cost and thermals, whereas a single SoC already serving the camera and LiDAR pipelines absorbs the radar workload as shared (rather than duplicated) compute. Range FFT, Doppler FFT, detection thresholding, angle finding and direction of arrival, tracking, and classification all execute there, with sufficient headroom for the model-based and machine-learning algorithms an edge MCU cannot host within its cost and thermal budget.

It should be noted that the difference is what reaches the processor. An edge module sends roughly 100 Mb/s of detections it has already reduced from the raw signal, while a raw ADC satellite streams around 2.5 Gb/s for a 4Tx4Rx sensor and around 5 Gb/s for an eight-transmit, eight-receive (8Tx8Rx) sensor. That 25- to 50-fold jump is the price of the architecture, and it is why the high-speed asymmetric link is a design constraint in its own right.

Infineon's CTRX8191F is a four-transmit, four-receive radar MMIC with an integrated Digital-PLL that delivers low phase noise. Combined with its highly linear receiver, it achieves a best-in-class signal-to-noise ratio. It also provides integrated launchers (antenna-feed-in-package), allowing the use of cost-efficient standard PCB material such as FR4. The CTRX8191F is AEC-Q100 qualified and has been in mass production since 2025. The CTRX8188F, which entered mass production in June 2026 as the industry's first 8Tx8Rx radar transceiver, extends this to eight transmit and eight receive channels and is designed to support the latest L2 regulation for China.

To help engineers prototype centralized systems, Infineon offers the CARKIT 8T8R CENTR, a vehicle-ready 77 GHz 8Tx8Rx radar module built for centralized architecture development. Instead of producing an on-sensor point cloud, it streams full raw ADC data at 5 Gb/s over coax cables up to 15 m long to a central compute unit, using either a MIPI A-PHY or a GMSL2 serializer, with power over coax. For teams that keep processing at the sensor, the companion CARKIT 8T8R EDGE runs radar signal processing on an AURIX microcontroller and outputs a processed point cloud over CAN or Ethernet.

Figure 4. Infineon Carkit supports the centralized radar processing approach. Image used courtesy of Infineon

Perception and System Benefits

Denser Point Clouds

Working from the complete raw data set, the central processor separates objects that edge nodes merge into a single blob, such as two vehicles side by side, a pedestrian beside a parked car, a cyclist overtaking traffic, or a guardrail that must be told apart from a stopped vehicle. The higher angular and range resolution behind that separation also reduces target ambiguity and minimizes ghost detections in urban environments and dense highway traffic.

VRU Classification

Dense radar point clouds capture fine motion signatures, including micro-Doppler effects and detailed spatial contours, giving a central ADAS processor enough to execute high-order feature extraction, micro-Doppler analysis, and deep neural network models. The payoff is differentiating pedestrians from cyclists and motorcyclists, recognizing limb movement patterns, and detecting partially occluded vulnerable road users.

Deep Fusion

Consolidating raw radar, camera, and LiDAR data at a single compute node improves time synchronization and cross-sensor correlation, enabling tighter fusion loops than independently generated object lists allow. Radar and camera features can be fused early rather than stitched together after each sensor has discarded most of its measurement, reducing false positives and negatives and improving confidence in complex urban scenarios.

Global Tracking

Rather than each radar tracking locally and forwarding object lists, data from multiple radar nodes is aggregated into a unified framework, providing high track continuity across sensor boundaries, better handling of occlusions, and consistent object IDs across vehicle perimeters.

Latency

Removing distributed processing layers and redundant abstraction also shortens the path from sample to decision. Radar data travels straight to the central compute unit, where perception algorithms run in parallel with other sensor streams. Those faster cycles help improve emergency braking response times, which translates directly into shorter stopping distances.

Free Space Estimation

Processed centrally, radar occupancy grids and reflectivity maps can be merged with camera-derived semantic segmentation in real time, enabling reliable drivable area detection in low-visibility conditions and accurate boundary estimation in construction zones and complex urban layouts. Since all perception modules share synchronized timing and spatial alignment, the free space model stays consistent across sensors, reducing uncertainty in path planning.

SDV Alignment

Because perception algorithms reside centrally within the ADAS compute platform, additional classification classes, denser tracking models, and higher-resolution mapping can be deployed through software updates without modifying edge hardware. Validation, cybersecurity management, and feature deployment happen in one unified environment rather than across fragmented firmware stacks.

Rethinking Radar Processing

Beyond optimizing hardware efficiency, centralized radar architecture changes what radar can do as a perception sensor, elevating it from a supportive ranging device to a primary contributor to the environmental model. The architectural lesson is that when the bottleneck is compute, move the compute. So, the radar front end did not need to become more capable. The processing behind it needed somewhere else to run.