2、硬件同步方案概览：硬件触发线、时钟同步、网络同步的对比
各位同学，咱们今天聊点硬核的。多摄像头同步，说白了就是让几个摄像头“同时按下快门”。但实际做起来，你会发现这里面门道很深。我个人习惯把同步方案分成三大类：硬件触发线、时钟同步、网络同步。嗯，咱们一个一个来看。
2.1 硬件触发线（GPIO/Trigger）
这是最直接、最暴力的方法。你想想看，用一根物理导线，把主控芯片的GPIO口和所有摄像头的Trigger引脚连起来。主控发一个脉冲，所有摄像头同时响应。我在项目中遇到过用这种方式做双目视觉，效果非常稳定。
核心原理：主控通过GPIO输出一个上升沿或下降沿信号，所有摄像头在检测到该边沿后立即开始曝光。
优点：
- 延迟极低，通常在微秒级别
- 实现简单，不需要复杂的协议栈
- 可靠性高，不受网络拥塞影响
缺点：
- 布线麻烦，摄像头多了线束会非常粗
- 距离受限，一般不超过几米
- 扩展性差，增加摄像头需要重新布线
我的经验：如果你做的是固定安装的工业检测设备，比如流水线上的产品外观检测，硬件触发线是最优解。我曾经在一个项目中，用GPIO触发4个500fps的高速相机，同步误差控制在1微秒以内，效果非常理想。
2.2 时钟同步（PPS/Genlock）
这个方法稍微高级一点。它不直接告诉摄像头“什么时候拍”，而是让所有摄像头的内部时钟保持同步。PPS（Pulse Per Second）是秒脉冲，Genlock是广播电视领域用的同步锁相技术。
为什么会这样？因为很多摄像头内部有自己的时钟源，时间长了会漂移。PPS信号就像一个“校准器”，每秒校准一次，让所有摄像头的时间基准保持一致。
// PPS同步的典型时序
// 主控每秒发送一个高精度脉冲
// 摄像头在脉冲上升沿重置内部计数器
// 所有摄像头基于同一个时间基准工作
// 伪代码示例
void pps_interrupt_handler() {
camera1.reset_timestamp();
camera2.reset_timestamp();
camera3.reset_timestamp();
// 所有摄像头时间戳归零
}适用场景：
- 分布式部署的摄像头系统
- 需要长时间连续采集的场景
- 对时间戳精度要求高的应用
注意：PPS同步只能保证时间基准一致，不能保证曝光时刻完全对齐。如果你需要微秒级的曝光同步，还得配合硬件触发线。我曾经踩过这个坑，以为PPS就够了，结果发现两个摄像头的时间戳虽然一致，但实际曝光时刻差了十几微秒。
2.3 网络同步（PTP/1588）
这是目前最流行的方案，特别是对于IP摄像头。PTP（Precision Time Protocol）是IEEE 1588标准定义的网络时钟同步协议。说白了，就是通过网络报文来同步各个设备的时钟。
你想想看，不用额外布线，只用一根网线就能搞定同步，多方便。PTP的精度可以达到亚微秒级别，但前提是你的网络设备要支持硬件时间戳。
| 特性 | 硬件触发线 | 时钟同步 | 网络同步 |
|---|---|---|---|
| 同步精度 | 纳秒级 | 微秒级 | 亚微秒级 |
| 布线复杂度 | 高 | 中 | 低 |
| 扩展性 | 差 | 中 | 好 |
| 成本 | 低 | 中 | 高 |
| 典型应用 | 工业检测 | 广播电视 | 自动驾驶 |
关键点：PTP的精度取决于网络设备的硬件支持。普通交换机只能做到毫秒级，支持1588的交换机才能达到微秒级。我个人建议，如果预算允许，尽量选用支持硬件时间戳的网卡和交换机。
2.4 三种方案的选型建议
好了，三种方案都讲完了。怎么选？我给大家一个简单的判断逻辑：
- 摄像头数量少（≤4个）且距离近：用硬件触发线，简单可靠
- 摄像头数量多且分布广：用PTP网络同步，灵活扩展
- 需要长时间连续采集：用PPS时钟同步，防止时间漂移
- 对同步精度要求极高（纳秒级）：硬件触发线是唯一选择
避坑指南：我曾经在一个项目中，为了省成本用了普通交换机做PTP同步，结果同步误差达到了几十毫秒。后来换成支持1588的工业交换机，误差直接降到1微秒以内。嗯，有些钱真的不能省。
最后说一句，实际项目中往往不是只用一种方案。比如，你可以用PTP做时钟同步，再用硬件触发线做精确曝光控制。这种混合方案在高端应用中很常见。好了，这一章就到这里，下一章咱们深入讲讲硬件触发线的具体实现细节。