简介这份文档是博世第一代中距离雷达MRR1-Plus平台的硬件功能技术客户文档TCD面向汽车ADAS领域的雷达算法、硬件与测试工程师以及从事毫米波雷达开发的研究人员。内容围绕76.0-77.0 GHz频段的调频连续波FMCW雷达展开讲解相对速度、距离与方位角的测量原理并覆盖HDI、ACC base、EBA、AEB等系统应用背景。资源包为1个PDF文件约1.17MB属于单文件技术规格书便于直接查阅与归档。文档第一部分重点说明硬件功能与功能状态工作模式及功能特性参数涉及频率调制策略与带宽、接收机灵敏度与动态范围、天线增益与波束设计以及速度、距离、角度测量误差等性能指标并附有版本控制与多部门审核流程说明。目前已有327人学习下载适合需要深入理解博世毫米波雷达硬件规格与工作模式的读者参考。1. 从一份雷达硬件功能文档说起MRR1 Plus 到底在定义什么拿到《中距离雷达硬件CA D101—第 1 部分硬件功能》这类文档的人通常不是要读故事而是要回答一个很具体的问题这块 MRR1 Plus 中距离雷达板子对外到底承诺了哪些硬件能力边界在哪。它属于毫米波车载雷达的硬件功能规格层覆盖射频前端、天线通道、供电、时钟、接口和自检这些可被下游 ECU 或域控制器直接依赖的部分。做感知算法、域控集成、台架测试的人都需要先把这份硬件功能清单吃透否则后面标定、点云解析、故障诊断全是空中楼阁。CA D101 这种编号一般对应企业内部或客户侧的硬件需求基线Part1 只讲硬件功能不讲信号处理链路所以阅读时要把注意力放在“电气与机械接口”和“功能可用性”上而不是去文档里找目标跟踪算法。适合谁看刚接手雷达硬件集成的工程师、需要写 DVP 的测试人员以及要把雷达接入整车网络架构的架构师。2. MRR1 Plus 硬件功能拆解射频通道、供电与接口2.1 中距离雷达的射频前端与天线通道定义中距离雷达MRR和长距离雷达LRR在硬件功能上的核心差别是天线通道数和波形带宽的取舍。MRR1 Plus 这类硬件通常采用多收多发MIMO虚拟孔径方案用较少的物理通道换取可用的角分辨率。硬件功能文档里会明确每个发射通道和接收通道的编号、极化方式、以及对应的基带 IQ 数据在帧结构中的位置。理解这一点直接决定你后面解析原始 ADC 数据时怎么排布维度。常见做法是先确认发射通道数 Tx 和接收通道数 Rx虚拟通道数就是 Tx×Rx。比如 3T4R 就是 12 个虚拟通道。这个数字不是拿来炫的它决定了角度 FFT 的输入矩阵形状。如果你在代码里把通道顺序搞错测出来的方位角会整体偏移甚至镜像。# 假设从硬件接口读到一帧原始数据形状为 (chirp, sample, virtual_channel) import numpy as np TX 3 # 发射通道数来自硬件功能文档 RX 4 # 接收通道数 VIRTUAL TX * RX # 硬件文档中常见的通道排列先遍历 Rx再遍历 Tx def reshape_frame(raw, chirps, samples): # raw 按 [chirp][sample][virtual] 线性存放 data np.array(raw, dtypenp.complex64).reshape(chirps, samples, VIRTUAL) return data frame reshape_frame(raw_bytes, chirps128, samples256) print(frame.shape) # (128, 256, 12)逻辑说明这段代码只做一件事把硬件送来的线性缓冲区还原成雷达信号处理需要的三维张量。参数chirps是一帧内的调频脉冲数samples是每个 chirp 的采样点数VIRTUAL必须和硬件功能文档里的 Tx×Rx 一致。如果文档写的是 4T4R这里就要改成 16否则 reshape 会直接报错或者静默错位。提示通道顺序在硬件功能文档里通常以表格形式给出不要凭经验猜。不同批次的板子如果天线布局改了顺序可能变。2.2 供电、时钟与硬件保护服务的功能边界硬件功能部分一定会写清楚供电范围和上电时序。MRR1 Plus 这类雷达模组常见的是 12V 标称供电但内部射频和数字部分需要多路低压轨。文档里会给出每路电源的典型值、最大纹波和上电顺序。上电顺序错了轻则射频芯片不启动重则闩锁。做台架测试时我一般会用可编程电源按文档时序逐路上电而不是直接插 12V 就完事。时钟方面中距离雷达对参考时钟的相位噪声有要求。硬件功能文档会写明外部晶振频率和允许的偏差范围比如 40MHz ±20ppm。如果你用信号发生器替代板载晶振做测试频率稳定度不够会直接体现在距离谱展宽上。硬件保护服务hardware protection service在这个语境下不是软件服务而是硬件层面的过压、过流、过温保护机制。文档会说明哪些故障会触发射频关断哪些只是上报诊断。集成时要确认这些保护状态能不能通过 CAN 或以太网读到否则整车诊断会缺一块。功能项典型参数集成关注点供电电压12V 标称9~16V 工作上电时序、反接保护参考时钟40MHz±20ppm相位噪声、起振时间过温保护结温 150°C 关断诊断上报延迟射频通道3T4R 虚拟 12 通道通道顺序、IQ 不平衡2.3 硬件接口与诊断功能的落地检查硬件功能文档的接口章节会列出所有对外连接器电源、CAN FD、以太网或 LVDS 高速数据口。做集成时第一步不是写代码而是拿万用表确认连接器定义和文档一致。我见过因为线束厂把 CAN_H 和 CAN_L 接反导致雷达一直进总线关闭状态的案例。诊断功能方面文档会定义故障码的触发条件和恢复条件。比如射频 PLL 失锁是立即上报还是连续 N 个周期后上报。这些参数直接影响你写诊断栈时的去抖逻辑。常见做法是在 MCU 侧维护一个故障计数器连续超过文档规定的阈值才置位 DTC。// 简化的 PLL 失锁去抖逻辑阈值来自硬件功能文档 #define PLL_UNLOCK_THRESHOLD 5 static uint8_t pll_unlock_cnt 0; static bool pll_fault_active false; void check_pll_status(bool pll_locked) { if (!pll_locked) { if (pll_unlock_cnt PLL_UNLOCK_THRESHOLD) { pll_unlock_cnt; } if (pll_unlock_cnt PLL_UNLOCK_THRESHOLD) { pll_fault_active true; // 置位 DTC } } else { pll_unlock_cnt 0; pll_fault_active false; } }逻辑说明PLL_UNLOCK_THRESHOLD必须从硬件功能文档里抄不能自己拍。参数pll_locked来自射频芯片的状态寄存器。这段代码只处理去抖不处理 DTC 存储和上报那部分属于诊断栈的事。3. 用 MRR1 Plus 硬件功能做台架验证从配置到数据采集3.1 台架环境搭建与最小可运行配置台架验证的目标是确认硬件功能文档里写的每一项都能在实际板子上复现。最小配置包括可编程电源、雷达板、接口转换板、主机和采集软件。我一般会先不接射频只上电读版本号和温度确认数字部分活着。然后再逐步开射频。配置步骤按文档时序上电测量每路电源纹波。通过 CAN 或以太网读取硬件版本、序列号和温度。发送雷达配置帧设置 chirp 参数和帧周期。确认射频使能后电流上升到文档标称值。采集原始数据检查通道数和采样点数是否匹配。# 以 SocketCAN 为例配置 CAN 接口并发送雷达使能帧 sudo ip link set can0 up type can bitrate 500000 cansend can0 123#0102030405060708 candump can0逻辑说明bitrate必须和硬件功能文档里的总线速率一致MRR1 Plus 常见的是 500kbps 或 CAN FD 的 2Mbps 数据段。cansend的帧 ID 和数据内容来自文档的通信矩阵。candump用来确认雷达有回复。注意射频使能前确保天线口接了匹配负载或暗室空口辐射在台架上可能干扰其他设备。3.2 原始数据采集与通道校验的代码实现采集到原始数据后第一件事是校验虚拟通道数。如果文档写 12 通道你采到 8 通道要么是配置错了要么是硬件降级版本。校验方法很简单看数据长度能不能被 chirps×samples 整除。def validate_frame(raw, chirps, samples, expected_virtual): total len(raw) if total % (chirps * samples) ! 0: raise ValueError(数据长度与 chirp/sample 不匹配) virtual total // (chirps * samples) if virtual ! expected_virtual: raise ValueError(f虚拟通道数 {virtual}期望 {expected_virtual}) return True逻辑说明expected_virtual来自硬件功能文档。这个校验放在采集流程最前面能避免后面所有处理都基于错误维度。参数chirps和samples来自你下发的配置帧不是猜的。3.3 硬件功能验证中的常见失败模式最常见的失败是射频不使能。原因通常有三类上电时序不对、配置帧校验失败、过温或过流保护触发。排查顺序应该是先读状态寄存器再看电源最后看配置。不要一上来就怀疑芯片坏了。第二常见的是数据错位。表现是距离谱上出现对称的假目标。这通常是 IQ 通道顺序或虚实部搞反了。硬件功能文档里会写明 IQ 的排列方式按文档改就行。第三是时钟偏差导致测距不准。如果你发现固定距离的目标测出来总是偏几米先查参考时钟频率是不是准。用频率计测板载晶振输出和文档标称值对比。失败现象可能原因排查手段射频不使能上电时序、配置校验读状态寄存器、示波器看电源假目标对称IQ 顺序错误对照文档改通道映射测距固定偏差参考时钟偏差频率计测晶振随机丢帧接口带宽不足查以太网或 LVDS 速率4. 从硬件功能到系统集成MRR1 Plus 的进阶用法4.1 用硬件功能文档反推诊断阈值硬件功能文档里的保护阈值不是只给硬件看的。做系统集成时这些阈值直接决定诊断策略。比如过温关断是 150°C但你可能希望在 130°C 就降功率给整车留缓冲。这时候就要在应用层加一级预警而不是等硬件自己关。常见做法是把硬件文档里的绝对阈值抄进诊断配置再根据整车热模型设一个更早的预警阈值。两个阈值都通过 CAN 上报诊断仪就能区分“预警”和“已关断”。4.2 多雷达组网时的硬件功能一致性检查一辆车上可能装多个 MRR1 Plus。如果批次不同硬件功能可能有细微差别比如通道顺序或时钟精度。组网前必须做一致性检查。我一般会写一个脚本把每个雷达的硬件版本、通道数、时钟偏差读出来对比。radars [front_left, front_right, rear_left, rear_right] profiles {} for r in radars: profiles[r] read_hw_profile(r) # 返回版本、通道数、时钟偏差 ref profiles[radars[0]] for r in radars[1:]: if profiles[r][virtual_channels] ! ref[virtual_channels]: print(f{r} 通道数不一致) if abs(profiles[r][clock_ppm]) 20: print(f{r} 时钟偏差超限)逻辑说明read_hw_profile是伪函数实际通过 CAN 或以太网读取。clock_ppm的 20 来自硬件功能文档的时钟章节。这个检查放在装车前的产线工位做比装车后返工便宜得多。4.3 硬件功能变更后的回归验证清单硬件功能文档一旦升版比如从 Part1 的某个修订到下一个修订必须做回归验证。清单包括供电范围、时钟频率、通道数、保护阈值、接口速率。每一项都要在台架上重新测一遍不能只看文档说“无影响”。提示回归验证时保留旧版文档的测试数据方便对比。硬件功能的变化有时很隐蔽比如纹波要求从 50mV 收紧到 30mV不测就发现不了。最后落到一个具体技巧把硬件功能文档里的每一项参数做成一个 CSV 检查表每行包含参数名、文档值、实测值、是否通过。台架测试时逐行填填完即完成验证。这个表还能直接作为 DVP 报告的附件省去二次整理。本文还有配套的精品资源点击获取 MRR1 Plus中距离雷达硬件功能解析与台架验证实战
简介这份文档是博世第一代中距离雷达MRR1-Plus平台的硬件功能技术客户文档TCD面向汽车ADAS领域的雷达算法、硬件与测试工程师以及从事毫米波雷达开发的研究人员。内容围绕76.0-77.0 GHz频段的调频连续波FMCW雷达展开讲解相对速度、距离与方位角的测量原理并覆盖HDI、ACC base、EBA、AEB等系统应用背景。资源包为1个PDF文件约1.17MB属于单文件技术规格书便于直接查阅与归档。文档第一部分重点说明硬件功能与功能状态工作模式及功能特性参数涉及频率调制策略与带宽、接收机灵敏度与动态范围、天线增益与波束设计以及速度、距离、角度测量误差等性能指标并附有版本控制与多部门审核流程说明。目前已有327人学习下载适合需要深入理解博世毫米波雷达硬件规格与工作模式的读者参考。1. 从一份雷达硬件功能文档说起MRR1 Plus 到底在定义什么拿到《中距离雷达硬件CA D101—第 1 部分硬件功能》这类文档的人通常不是要读故事而是要回答一个很具体的问题这块 MRR1 Plus 中距离雷达板子对外到底承诺了哪些硬件能力边界在哪。它属于毫米波车载雷达的硬件功能规格层覆盖射频前端、天线通道、供电、时钟、接口和自检这些可被下游 ECU 或域控制器直接依赖的部分。做感知算法、域控集成、台架测试的人都需要先把这份硬件功能清单吃透否则后面标定、点云解析、故障诊断全是空中楼阁。CA D101 这种编号一般对应企业内部或客户侧的硬件需求基线Part1 只讲硬件功能不讲信号处理链路所以阅读时要把注意力放在“电气与机械接口”和“功能可用性”上而不是去文档里找目标跟踪算法。适合谁看刚接手雷达硬件集成的工程师、需要写 DVP 的测试人员以及要把雷达接入整车网络架构的架构师。2. MRR1 Plus 硬件功能拆解射频通道、供电与接口2.1 中距离雷达的射频前端与天线通道定义中距离雷达MRR和长距离雷达LRR在硬件功能上的核心差别是天线通道数和波形带宽的取舍。MRR1 Plus 这类硬件通常采用多收多发MIMO虚拟孔径方案用较少的物理通道换取可用的角分辨率。硬件功能文档里会明确每个发射通道和接收通道的编号、极化方式、以及对应的基带 IQ 数据在帧结构中的位置。理解这一点直接决定你后面解析原始 ADC 数据时怎么排布维度。常见做法是先确认发射通道数 Tx 和接收通道数 Rx虚拟通道数就是 Tx×Rx。比如 3T4R 就是 12 个虚拟通道。这个数字不是拿来炫的它决定了角度 FFT 的输入矩阵形状。如果你在代码里把通道顺序搞错测出来的方位角会整体偏移甚至镜像。# 假设从硬件接口读到一帧原始数据形状为 (chirp, sample, virtual_channel) import numpy as np TX 3 # 发射通道数来自硬件功能文档 RX 4 # 接收通道数 VIRTUAL TX * RX # 硬件文档中常见的通道排列先遍历 Rx再遍历 Tx def reshape_frame(raw, chirps, samples): # raw 按 [chirp][sample][virtual] 线性存放 data np.array(raw, dtypenp.complex64).reshape(chirps, samples, VIRTUAL) return data frame reshape_frame(raw_bytes, chirps128, samples256) print(frame.shape) # (128, 256, 12)逻辑说明这段代码只做一件事把硬件送来的线性缓冲区还原成雷达信号处理需要的三维张量。参数chirps是一帧内的调频脉冲数samples是每个 chirp 的采样点数VIRTUAL必须和硬件功能文档里的 Tx×Rx 一致。如果文档写的是 4T4R这里就要改成 16否则 reshape 会直接报错或者静默错位。提示通道顺序在硬件功能文档里通常以表格形式给出不要凭经验猜。不同批次的板子如果天线布局改了顺序可能变。2.2 供电、时钟与硬件保护服务的功能边界硬件功能部分一定会写清楚供电范围和上电时序。MRR1 Plus 这类雷达模组常见的是 12V 标称供电但内部射频和数字部分需要多路低压轨。文档里会给出每路电源的典型值、最大纹波和上电顺序。上电顺序错了轻则射频芯片不启动重则闩锁。做台架测试时我一般会用可编程电源按文档时序逐路上电而不是直接插 12V 就完事。时钟方面中距离雷达对参考时钟的相位噪声有要求。硬件功能文档会写明外部晶振频率和允许的偏差范围比如 40MHz ±20ppm。如果你用信号发生器替代板载晶振做测试频率稳定度不够会直接体现在距离谱展宽上。硬件保护服务hardware protection service在这个语境下不是软件服务而是硬件层面的过压、过流、过温保护机制。文档会说明哪些故障会触发射频关断哪些只是上报诊断。集成时要确认这些保护状态能不能通过 CAN 或以太网读到否则整车诊断会缺一块。功能项典型参数集成关注点供电电压12V 标称9~16V 工作上电时序、反接保护参考时钟40MHz±20ppm相位噪声、起振时间过温保护结温 150°C 关断诊断上报延迟射频通道3T4R 虚拟 12 通道通道顺序、IQ 不平衡2.3 硬件接口与诊断功能的落地检查硬件功能文档的接口章节会列出所有对外连接器电源、CAN FD、以太网或 LVDS 高速数据口。做集成时第一步不是写代码而是拿万用表确认连接器定义和文档一致。我见过因为线束厂把 CAN_H 和 CAN_L 接反导致雷达一直进总线关闭状态的案例。诊断功能方面文档会定义故障码的触发条件和恢复条件。比如射频 PLL 失锁是立即上报还是连续 N 个周期后上报。这些参数直接影响你写诊断栈时的去抖逻辑。常见做法是在 MCU 侧维护一个故障计数器连续超过文档规定的阈值才置位 DTC。// 简化的 PLL 失锁去抖逻辑阈值来自硬件功能文档 #define PLL_UNLOCK_THRESHOLD 5 static uint8_t pll_unlock_cnt 0; static bool pll_fault_active false; void check_pll_status(bool pll_locked) { if (!pll_locked) { if (pll_unlock_cnt PLL_UNLOCK_THRESHOLD) { pll_unlock_cnt; } if (pll_unlock_cnt PLL_UNLOCK_THRESHOLD) { pll_fault_active true; // 置位 DTC } } else { pll_unlock_cnt 0; pll_fault_active false; } }逻辑说明PLL_UNLOCK_THRESHOLD必须从硬件功能文档里抄不能自己拍。参数pll_locked来自射频芯片的状态寄存器。这段代码只处理去抖不处理 DTC 存储和上报那部分属于诊断栈的事。3. 用 MRR1 Plus 硬件功能做台架验证从配置到数据采集3.1 台架环境搭建与最小可运行配置台架验证的目标是确认硬件功能文档里写的每一项都能在实际板子上复现。最小配置包括可编程电源、雷达板、接口转换板、主机和采集软件。我一般会先不接射频只上电读版本号和温度确认数字部分活着。然后再逐步开射频。配置步骤按文档时序上电测量每路电源纹波。通过 CAN 或以太网读取硬件版本、序列号和温度。发送雷达配置帧设置 chirp 参数和帧周期。确认射频使能后电流上升到文档标称值。采集原始数据检查通道数和采样点数是否匹配。# 以 SocketCAN 为例配置 CAN 接口并发送雷达使能帧 sudo ip link set can0 up type can bitrate 500000 cansend can0 123#0102030405060708 candump can0逻辑说明bitrate必须和硬件功能文档里的总线速率一致MRR1 Plus 常见的是 500kbps 或 CAN FD 的 2Mbps 数据段。cansend的帧 ID 和数据内容来自文档的通信矩阵。candump用来确认雷达有回复。注意射频使能前确保天线口接了匹配负载或暗室空口辐射在台架上可能干扰其他设备。3.2 原始数据采集与通道校验的代码实现采集到原始数据后第一件事是校验虚拟通道数。如果文档写 12 通道你采到 8 通道要么是配置错了要么是硬件降级版本。校验方法很简单看数据长度能不能被 chirps×samples 整除。def validate_frame(raw, chirps, samples, expected_virtual): total len(raw) if total % (chirps * samples) ! 0: raise ValueError(数据长度与 chirp/sample 不匹配) virtual total // (chirps * samples) if virtual ! expected_virtual: raise ValueError(f虚拟通道数 {virtual}期望 {expected_virtual}) return True逻辑说明expected_virtual来自硬件功能文档。这个校验放在采集流程最前面能避免后面所有处理都基于错误维度。参数chirps和samples来自你下发的配置帧不是猜的。3.3 硬件功能验证中的常见失败模式最常见的失败是射频不使能。原因通常有三类上电时序不对、配置帧校验失败、过温或过流保护触发。排查顺序应该是先读状态寄存器再看电源最后看配置。不要一上来就怀疑芯片坏了。第二常见的是数据错位。表现是距离谱上出现对称的假目标。这通常是 IQ 通道顺序或虚实部搞反了。硬件功能文档里会写明 IQ 的排列方式按文档改就行。第三是时钟偏差导致测距不准。如果你发现固定距离的目标测出来总是偏几米先查参考时钟频率是不是准。用频率计测板载晶振输出和文档标称值对比。失败现象可能原因排查手段射频不使能上电时序、配置校验读状态寄存器、示波器看电源假目标对称IQ 顺序错误对照文档改通道映射测距固定偏差参考时钟偏差频率计测晶振随机丢帧接口带宽不足查以太网或 LVDS 速率4. 从硬件功能到系统集成MRR1 Plus 的进阶用法4.1 用硬件功能文档反推诊断阈值硬件功能文档里的保护阈值不是只给硬件看的。做系统集成时这些阈值直接决定诊断策略。比如过温关断是 150°C但你可能希望在 130°C 就降功率给整车留缓冲。这时候就要在应用层加一级预警而不是等硬件自己关。常见做法是把硬件文档里的绝对阈值抄进诊断配置再根据整车热模型设一个更早的预警阈值。两个阈值都通过 CAN 上报诊断仪就能区分“预警”和“已关断”。4.2 多雷达组网时的硬件功能一致性检查一辆车上可能装多个 MRR1 Plus。如果批次不同硬件功能可能有细微差别比如通道顺序或时钟精度。组网前必须做一致性检查。我一般会写一个脚本把每个雷达的硬件版本、通道数、时钟偏差读出来对比。radars [front_left, front_right, rear_left, rear_right] profiles {} for r in radars: profiles[r] read_hw_profile(r) # 返回版本、通道数、时钟偏差 ref profiles[radars[0]] for r in radars[1:]: if profiles[r][virtual_channels] ! ref[virtual_channels]: print(f{r} 通道数不一致) if abs(profiles[r][clock_ppm]) 20: print(f{r} 时钟偏差超限)逻辑说明read_hw_profile是伪函数实际通过 CAN 或以太网读取。clock_ppm的 20 来自硬件功能文档的时钟章节。这个检查放在装车前的产线工位做比装车后返工便宜得多。4.3 硬件功能变更后的回归验证清单硬件功能文档一旦升版比如从 Part1 的某个修订到下一个修订必须做回归验证。清单包括供电范围、时钟频率、通道数、保护阈值、接口速率。每一项都要在台架上重新测一遍不能只看文档说“无影响”。提示回归验证时保留旧版文档的测试数据方便对比。硬件功能的变化有时很隐蔽比如纹波要求从 50mV 收紧到 30mV不测就发现不了。最后落到一个具体技巧把硬件功能文档里的每一项参数做成一个 CSV 检查表每行包含参数名、文档值、实测值、是否通过。台架测试时逐行填填完即完成验证。这个表还能直接作为 DVP 报告的附件省去二次整理。本文还有配套的精品资源点击获取