BYD's 'Divine Eye' system recently implemented a sensor satellite architecture, improving LiDAR angular resolution by 1.6x, extending 4D millimeter-wave radar detection range to 400 meters, and increasing ultrasonic radar point cloud density by 10x.

Behind this architecture, control over sensor algorithms is systematically shifting from Tier-1 suppliers to automakers.

Part 1: What is the Sensor Satellite Architecture for Assisted Driving?

The name 'satellite architecture' is apt. Just as satellites orbit the Earth, radar sensors are distributed around the vehicle body, performing only basic signal preprocessing before transmitting near-raw data via high-speed SerDes links to a central computing unit. The central 'brain' runs perception algorithms, performs multi-sensor fusion, and outputs decisions.

This represents a significant departure from current practices—or rather, it follows the example set by cameras, with other perception sensors now adopting similar architectures.

Current millimeter-wave and LiDAR architectures treat each radar sensor as a complete 'mini-brain.'

Take millimeter-wave radar as an example: signal acquisition, FFT processing, target detection, classification, and tracking are all handled internally within the sensor. Ultimately, it outputs only a few conclusions like 'N targets detected' via the bus, with a pitifully small data volume.

Smart radars transmit 'conclusions,' while satellite radars transmit 'evidence.' Each radar operates independently, seeing only fragments. One radar reports 'obstacle 50 meters ahead,' another reports 'pedestrian 30 meters left,' and the central processor receives a fragmented target list.

It's like receiving an edited duty report instead of raw surveillance footage—information is permanently lost during compression.

Transmitting raw data changes everything. All sensors' raw data—distance FFT spectra, LiDAR RAW point clouds, ultrasonic full waveforms—converge at the central brain. Algorithms can perform cross-sensor fusion at the pixel level.

Consider a concrete example: in rain or fog, LiDAR points scatter due to water droplets, obscuring distant targets. However, millimeter-wave radar signals persist—their longer wavelengths penetrate fog much better.

Under a smart radar architecture, you'd receive contradictory reports: 'millimeter-wave radar detects no obstacle, LiDAR visibility impaired.'

But with a satellite architecture, the two raw data streams align to a common coordinate system. Algorithms can complement millimeter-wave radar's strong reflections with LiDAR's sparse echoes—not choosing 'which to believe,' but 'seeing together.'

Not 1+1=2, but 1+1 could equal 5.

Part 2: Why Now?—The Power Shift in Radar Algorithms

Cameras have long operated this way. Front-facing cameras handle only photoelectric conversion, transmitting RAW data via GMSL links to domain controllers, where ISP and perception algorithms run on SoCs. This approach has been mature for nearly a decade.

So why are millimeter-wave and LiDAR radars only catching up now? Because Tier-1 suppliers have long controlled their radar signal processing algorithms.

For millimeter-wave radar, Tier-1s like Bosch, Continental, and Aptiv encapsulation (Note: ' encapsulation ' means 'encapsulate' or 'package' in technical contexts—here, it refers to how core radar signal processing know-how is embedded in firmware and delivered as a black box) the core know-how of millimeter-wave radar signal processing—how to extract targets from FFT spectra, suppress sidelobe noise, and perform multi-target tracking—within radar processor firmware, delivered as black boxes. It's like dining at Michelin-starred restaurants: the food is excellent, but you never know how it's prepared in the kitchen.

Satellite architecture aims to 'demolish the kitchen.' Sensors handle only 'ingredient sourcing and washing'—MMIC for RF transceiver, ADC for analog-to-digital conversion, at most adding a 1D FFT—while 'cooking' moves to the central kitchen (domain control SoC).

Multiple factors drive this shift, primarily collusion between automakers and chipmakers.

NXP introduced dedicated radar bridging chips (Radar Bridge) to encapsulate data links between MMIC and SerDes, while integrating radar signal processor IP (RSP IP) directly into ADAS SoCs. Automakers no longer need to build algorithms from scratch—they can directly invoke mature acceleration IP on domain control chips.

TI follows a similar path, with its AWR series millimeter-wave radar chips natively supporting RAW data stream output.

L3/L4 autonomous driving demands a new level of sensor fusion. Fragmented target lists no longer suffice. You need raw range-Doppler spectra for micro-Doppler feature analysis to distinguish pedestrians from bicycles. You need raw point clouds to judge whether oddly shaped obstacles are plastic bags or stones.

Previously, running FFT and CFAR for 12 radar channels on domain control SoCs strained chips. Now, SoC capabilities have improved.

Future intelligent and satellite radars will coexist long-term; the key is 'who leads.' If automakers choose satellite routes, they dominate; if they choose smart radar routes, Tier-1s remain in charge.

In short: architecture equals power.

Part 3: Same 'Satellite,' Three Sensors, Three Paths

Though all called 'satellite architecture,' LiDAR, millimeter-wave radar, and ultrasonic radar face vastly different technical challenges.

● Millimeter-Wave Radar: Most Mature, Yet Most Challenging

Where is it mature? 4D imaging radar's multi-chip architecture is already commercialized. The market currently follows two parallel paths. China pursues cost-effectiveness, with mainstream '1 SoC + 2 MMIC' configurations for 6T8R, upgrading to 8T8R next while maintaining cost advantages.

The Europe and America (Note: ' Europe and America ' means 'European and American') market prioritizes performance, with mainstream '1 SoC + 4 MMIC' configurations for 12T16R. The U.S. advances toward 16T16R, while Europe plans even more aggressive 24T24R deployments.

By 2028, these 8T8R and 24T24R routes will further diverge, reflecting fundamentally different cost models and application scenario judgments.

However, satellite millimeter-wave radar's challenges lie not in hardware but in the algorithm ecosystem. Three hurdles emerge:

◎ First, who can access mature radar algorithm IP? Algorithms are Tier-1s' moats—they won't sell easily.

◎ Second, even with IP, who can perform cross-platform porting and validation? Migrating from radar processors to domain control SoCs involves massive adaptation work.

◎ Third, SoC MIPI interfaces are designed for cameras. Radar data organization—such as 2D matrices of range and Doppler dimensions—differs completely from camera frame structures. Can DSP accelerators handle this efficiently? That remains uncertain.

Yet every hurdle is being overcome. NXP's strategy of opening RSP IP to domain control SoCs essentially uses chipmakers' neutrality to dismantle algorithmic walls.

● LiDAR: The Primary Motive is Cost Reduction

LiDAR's drive toward satellite architecture stems from a simple incentive: cost savings. Within LiDAR systems, FPGAs and signal processors account for significant cost shares. If algorithms can migrate to domain controllers—similar to front-facing cameras—leaving only laser emission, SPAD reception, and basic TDC timing at the sensor end, hardware costs could drop substantially.

Feasibility is improving. Modern automotive LiDAR receivers extensively use SPAD arrays with built-in digital circuits for photon counting and histogram statistics, outputting via MIPI interfaces. This resembles CMOS image sensors, providing a physical foundation for satellite integration.

However, LiDAR faces two unique difficulties:

◎ Bandwidth: A typical 192-line LiDAR with 10Hz frame rate, 120° horizontal FOV, and 0.1° resolution generates approximately 3.6Gbps of data per second (including timestamps, distances, reflectivity, and echo counts). GMSL2's 6Gbps barely suffices—equivalent to streaming an HD movie every second. If precision demands double the data volume, bandwidth becomes insufficient.

◎ SoC Adaptation: LiDAR's data structure differs completely from cameras. Cameras organize pixels into frames, with ISP pipelines tailored for them. LiDAR organizes data by angular slots—1,200 slots per frame, each containing multi-echo, multi-parameter data. Feeding LiDAR data directly into MIPI processing units designed for cameras may render most DSP acceleration useless, forcing reliance on CPU/GPU brute-force computation with plummeting efficiency.

● Ultrasonic Radar: Deceptively Simple, Yet Challenging at Scale

Ultrasonic radar satellite integration is algorithmically the simplest. It requires no complex signal processing—just time-of-flight ranging. Under satellite architecture, transmitting full echo waveforms to the central ECU reduces latency by 20% and increases point cloud density by 10x, as the central processor applies finer matched-filter algorithms to extract more information.

The issue with ultrasonic radar is quantity. A vehicle typically deploys 12 sensors. Routing each through independent SerDes links is unsustainable in terms of wiring costs and interface counts.

A more practical route is 'local centralization + zone gateways.' For example, placing a zone processor on the front and rear bumpers to aggregate data from six sensors before uploading. This balances centralized processing benefits without creating wiring spaghetti.

BYD's ultrasonic upgrade data—20% latency reduction, 20% detection improvement, 10x point cloud density increase—comes at the cost of introducing zone processors as an intermediate layer between full centralization and full distribution.

Summary

What Chinese automakers truly seek is a complete sensor data pipeline—from raw signals to final decisions, with no black boxes.

Only with this pipeline can data feed algorithm evolution, enabling sustained technological gaps. After camera data, as more sensors emerge, this lays the groundwork for iterating from L2 to L3 autonomous driving.