尧图建网站 尧图建网站 YAOTU WEB BUILD 免费咨询
ARTICLE DETAIL

资讯详情

深耕网站建设与建站编程的一线实战洞察。

026、多摄同步的硬件触发机制——高通Spectra与联发科Imagiq的帧同步误差对比与量产校准

026、多摄同步的硬件触发机制——高通Spectra与联发科Imagiq的帧同步误差对比与量产校准 026、多摄同步的硬件触发机制——高通Spectra与联发科Imagiq的帧同步误差对比与量产校准去年在某个旗舰项目上客户拿着三颗摄像头模组拍出来的慢动作视频指着画面里那辆从左侧切入的白色轿车问我为什么车轮看起来像在“拧麻花”。那台机器用的是高通骁龙8 Gen1三摄分别是IMX766主摄、OV08A10超广角和一颗长焦。我盯着那帧画面看了半天心里清楚这不是算法能救回来的问题——这是硬件触发时序的锅。后来我们抓了示波器把三路VSYNC信号拉出来一对比主摄和超广角之间差了将近1.2毫秒长焦更是离谱差了2.8毫秒。这个数字在静态场景下你根本感知不到但一旦物体运动速度超过30公里每小时果冻效应和帧错位就会让整个画面像被撕裂了一样。多摄同步这事说起来简单——让所有摄像头在同一时刻曝光同一时刻读出。但做起来每个芯片平台的实现路径和坑位都不一样。高通Spectra和联发科Imagiq这两大阵营在硬件触发机制上走了完全不同的两条路而这两条路各自埋着不同的雷。先看高通Spectra。高通的方案核心是MCLK主时钟和VSYNC的相位对齐它有一个专门的硬件模块叫CCICamera Control Interface负责向所有摄像头广播同步信号。在Spectra ISP内部有一个全局的frame sync generator可以输出多路同步脉冲每一路对应一颗摄像头。这个设计思路是“集中式调度”——所有摄像头都听ISP的指挥ISP说什么时候曝光就什么时候曝光。理论上这个方案的同步精度可以做到纳秒级因为所有信号都源自同一个时钟源。但问题出在传感器端。高通这个同步信号是走CCI总线广播的而CCI总线的传输延迟在不同模组之间是有差异的。你用的排线长度不一样FPC走线阻抗不一样甚至模组厂在贴片时焊点的大小不一样都会导致同步信号到达传感器的时间有微小偏差。这个偏差在单颗摄像头上看不出来但多颗摄像头一对比就是那1毫秒级别的误差。更麻烦的是高通这个同步机制要求所有传感器必须支持“external sync mode”也就是外部触发模式。如果你用的传感器不支持这个模式那对不起你只能靠软件对齐精度直接掉一个数量级。联发科Imagiq的思路完全不同。它走的是“分布式协商”路线——每颗摄像头都有自己的独立时钟域但通过一个叫MIPI CSI-2的同步包机制来对齐。具体来说Imagiq允许你在CSI-2数据流里插入一个特殊的同步标记sync packet每颗摄像头在曝光开始时打一个时间戳然后ISP端根据这些时间戳做重排。这个方案的优点是灵活性高不依赖传感器的外部触发能力任何支持CSI-2的传感器都能用。但代价是同步精度受限于MIPI链路的传输延迟而且这个延迟不是固定的——它跟帧率、分辨率、数据通道数都有关系。我在实验室里做过一个对比测试用同一批IMX586传感器分别接到高通骁龙778G和联发科天玑1200的平台上测三摄同步误差。高通的方案在理想条件下短排线、同批次模组能做到±200微秒以内但一旦换成长排线或者混用不同批次模组误差直接飙到±800微秒。联发科那边初始误差大概在±500微秒左右但它的优势在于一致性——不管你怎么换模组误差都稳定在这个范围内不会出现高通那种“时好时坏”的情况。量产的时候这个差异会带来完全不同的校准策略。高通平台你必须在产线上做“per-unit”校准也就是每一台机器都要单独测同步误差然后写进校准参数里。这个校准过程很痛苦因为你需要一个专门的测试工位用示波器或者专用的同步测试卡来抓VSYNC信号。而且校准参数是跟模组绑定的一旦用户换了摄像头模组比如售后维修校准参数就失效了同步误差会回到未校准状态。联发科平台就省事多了因为它的误差是统计稳定的你只需要在研发阶段做一次“design-level”校准确定一个固定的补偿值然后所有量产机都用这个补偿值就行。但联发科也有坑——它的同步包机制在低帧率比如15fps以下或者高分辨率比如4K60fps时MIPI链路的带宽压力会增大同步包的传输延迟会变得不稳定这时候误差会突然增大。我们当时在某个项目上就遇到过1080P30fps时同步误差稳定在±300微秒一调到4K60fps误差直接跳到±1.5毫秒整个画面都在抖。这里踩过一个大坑必须提醒你。高通的CCI同步信号在传感器初始化阶段有一个“lock-in”过程——你必须确保所有摄像头在同一个MCLK周期内完成初始化否则同步信号会错位。这个错位不会报错但会导致同步误差变成固定偏差而且这个偏差是随机的每台机器都不一样。我们当时排查了很久最后发现是模组厂的初始化序列里多了一个I2C写操作导致其中一颗摄像头的初始化时间比其他摄像头晚了几个MCLK周期。解决办法是在驱动里加一个barrier等所有摄像头都进入ready状态后再启动同步信号。联发科那边也有类似的坑但表现形式不同。它的同步包机制要求所有摄像头必须使用相同的MIPI lane配置和相同的data rate否则同步包到达ISP的时间会不一致。我们曾经在某个项目上主摄用了4 lane超广角用了2 lane结果同步误差直接翻倍。后来统一改成4 lane问题就消失了。再说说量产校准的具体操作。高通平台我们用的是“VSYNC phase measurement”方法——在产线上用一个高速相机对着一个LED阵列LED阵列以已知频率闪烁然后同时触发三颗摄像头拍照通过分析照片里LED的亮暗位置来反推每颗摄像头的曝光时刻。这个方法精度能到±50微秒但需要专门的测试设备和算法产线节拍会受影响。联发科平台我们用的是“timestamp correlation”方法——直接读每颗摄像头在曝光时刻打的时间戳然后做差值。这个方法简单但精度受限于传感器时间戳的分辨率一般只能到±200微秒。最后给你一个个人经验这个经验在多个项目上验证过比任何芯片平台的参考设计都管用——不要迷信芯片平台的同步机制一定要在项目早期就做“同步误差预算分析”。具体来说列出所有影响同步误差的因素传感器外部触发响应时间、MIPI链路传输延迟、ISP内部处理延迟、模组FPC走线长度、甚至电源纹波对传感器内部PLL的影响。每一项都要有实测数据然后加起来看总误差是否在你的应用容忍范围内。如果超了别指望后期调优能救回来要么换传感器要么改硬件设计要么降低应用对同步精度的要求。多摄同步这事本质上是一个系统工程问题芯片平台只是给你提供了一个工具怎么用、用得好不好全看你对整个链路每个环节的理解深度。高通和联发科各有各的脾气摸透了它们的脾气你才能在量产线上睡个安稳觉。
返回列表