简介：面向工业相机与图像采集卡开发、调试人员，这份文档围绕Camera Link的Base、Medium、Full三种接口配置展开，适合需要理解相机输出模式、线缆与采集卡匹配关系的中初级工程师查漏补缺。文档先从Camera Link标准的产生背景与Channel Link多路复用技术讲起，说明LVDS差分传输在抗噪、速率和线缆简化上的优势，再逐一对比三种配置所对应的Channel Link收发器数量、LVDS控制与串行通信线对，以及28位、56位、84位并行视频数据的传输能力。文中还涉及端口A至H的定义与分配、标准电缆使用差异等细节，可帮助读者建立从协议原理到接口选型的完整认识。资源包内为1个doc文档，大小约168KB，结构紧凑，便于按章节检索Camera Link关键概念。目前已有2116人学习与下载，适合作为相机接口选型、采集系统联调时的参考资料。
1. 三条线缆的错觉：Base、Medium、Full 真正的分界线是 24/48/64 位像素
CameraLink 的 Base、Medium、Full 三种配置，很多人第一反应是“三档速率”，把完整模式当成简单叠加。把三者的端口账本摆在一起看，最反直觉的一点是：从 Base 到 Medium，并行像素位从 24 位涨到 48 位，正好翻倍；从 Medium 到 Full，却只涨到 64 位，边际收益掉到三分之一。原因藏在标准的端口分配里——Full 模式的第三对 Channel Link 驱动器只挂了 G、H 两个端口，剩下 8 个输入引脚空着没分配。相机和采集卡之间这组只有几对差分线的点对点连接，带宽并不是线性堆出来的，它是一套被连接器引脚数、芯片通道数和电缆对数同时约束的账本。把这个账本算清楚，再看“为什么我的 Full 相机接上去只出一部分画面”这类问题，答案就比较直接了。
2. Channel Link 的并串转换：28 位并行怎么被摊进 5 对差分线
2.1 4 路数据加 1 路时钟：每对线上的位流账本
Camera Link 的物理层不自己造轮子，它整体建立在 Channel Link 之上。一颗 Channel Link 收发器对的输入侧是 28 根单端并行数据线加 1 根并行时钟线，输出侧是 5 对 LVDS 差分线：4 对走数据，1 对专门走时钟。发送端把 28 位并行信号按位切开，串行化后排到 4 条数据通道上，每条通道每个周期承担 7 位。
28 能被 4 整除这一点不是巧合，而是设计的硬性前提。如果每对线分到的位数不相等，4 条通道的位率就会不同，接收端用同一路随路时钟去采样时，通道之间会累积无法消除的相位差。7 位对齐让 4 条通道的位流长度完全一致，接收端只需要一个统一的位边界，就能把 28 位重新拼回来。
把位率和带宽算一遍，三种模式的差距就一目了然：
# Channel Link 单芯片的位流账本：28 位并行怎么摊到 4 对差分线上 PIXEL_CLK_MHZ = 85.0 # 发送端并行时钟，标准里最高的一档 LANES = 4 # 4 路 LVDS 数据对，第 5 对专走随路时钟 BITS_TOTAL = 28 # 每个周期串行化的总位数 bits_per_lane = BITS_TOTAL // LANES # 7 位/对，必须整除，否则通道间位率失配 lane_rate = PIXEL_CLK_MHZ * bits_per_lane print(f"每对数据线速率: {lane_rate:.1f} Mbps") # 595.0 print(f"4 对合计: {lane_rate * LANES:.0f} Mbps") # 2380 print(f"换算成字节: {lane_rate * LANES / 8:.1f} MB/s") # 297.5 # 三种模式各自用了几颗 Channel Link、占几个端口 for name, chips, ports in [("Base", 1, 3), ("Medium", 2, 6), ("Full", 3, 8)]: raw = chips * BITS_TOTAL # 标准宣称的"并行视频数据位宽" pixel = ports * 8 # 真正能装像素的位数 print(f"{name:<7} 宣称{raw:>3}位 有效像素{pixel:>3}位 " f"每周期{ports}像素 有效带宽{pixel / BITS_TOTAL * lane_rate * LANES * chips / 8:.1f} MB/s")跑出来的结果是：Base 宣称 28 位、有效 24 位、每周期 3 个 8 位像素、约 255 MB/s；Medium 宣称 56 位、有效 48 位、6 个像素、约 510 MB/s；Full 宣称 84 位、有效 64 位、8 个像素、约 680 MB/s。所谓“84 位视频数据”是芯片引脚的总数，不是像素位的总数，两者差的那 20 位里，12 位是三颗芯片各自的 FVAL、LVAL、DVAL、Spare，另外 8 位是第三颗芯片上空着的引脚。相机厂商宣传页上的数字和实际能塞进去的像素量，差的就是这一截。
2.2 从 TTL 到 LVDS：为什么用电流模式差分而不是单端
标准诞生的直接动因很朴素：相机制造商和采集卡制造商各自选连接器，线缆没法统一生产，用户整合一套系统要花大量时间在“哪根线配哪个针”上。要解决这个问题，光统一机械接口不够，电气层也必须收敛到一种能覆盖高数据率、又能用便宜器件实现的方案。LVDS 胜出的理由是三条：摆幅只有 350mV 左右、跳变快、差分结构对共模噪声不敏感。
真正让线缆数量掉下来的，是多路复用。用传统差分方案传 28 位数据，线缆上要铺 56 只终端电阻；换成 Channel Link，终端电阻只要 11 只，也就是 4 对数据线、1 对时钟线，再加至多一个地。线缆变细的直接后果是可以用更小体积的连接器，屏蔽要求也跟着降低——26 针的 MDR 连接器就能把整套信号装下，这在过去是不可想象的。
| 对比项 | 单端并行传输 | Channel Link（LVDS 串行） |
|---|---|---|
| 传 28 位所需线对 | 28 根数据 + 时钟 + 地 | 4 对数据 + 1 对时钟 |
| 终端电阻 | 56 只 | 11 只 |
| 电压摆幅 | 满摆幅（3.3V/5V） | 约 350mV 差分 |
| 连接器 | 体积大、针数多 | 26 针 MDR 即可 |
| 抗噪方式 | 提高摆幅、加屏蔽 | 差分共模抑制 |
还有一个容易被忽略的机制点：Channel Link 是源同步（source-synchronous）接口，时钟跟数据一起从发送端出发，接收端不做时钟数据恢复，也不做 8b/10b 编码。这意味着链路里没有任何“训练”环节，插上就能跑，延迟是固定且可预测的。代价是发送端时钟与数据线之间的偏斜必须始终小于一个位周期，85MHz 下每对线 595Mbps，位周期约 1.68ns。这个窗口窄到必须靠线对内严格等长的双绞结构来保证，随便找一根排线替代，翻车是迟早的事。
3. 端口 A~H 的位分配：为什么引脚映射不是顺序排的
3.1 28 位的真实构成：24 位像素加 4 位限定信号
Camera Link 把每个端口定义成一个 8 位字，最低位是 bit0，最高位是 bit7，一共 8 个端口，标号 A 到 H。但端口只是逻辑概念，它最终要落到芯片的 28 个物理引脚上。这一层映射是整份规范里最容易看走眼的地方，因为端口内的位序和引脚编号完全不对应。
把完整映射摊开看，A6 落在 TX27、A7 落在 TX5、B3 落在 TX12、C1 落在 TX18，而 TX24 到 TX26 三个引脚被 LVAL、FVAL、DVAL 占掉，TX23 留给 Spare。24 位像素加 4 位限定信号，正好 28 位，一位不多一位不少。
# 一颗 Channel Link 的 28 个引脚占用：端口位与引脚号不是顺序对应的 pinmap = { "TX0": "A0", "TX1": "A1", "TX2": "A2", "TX3": "A3", "TX4": "A4", "TX6": "A5", "TX27": "A6", "TX5": "A7", "TX7": "B0", "TX8": "B1", "TX9": "B2", "TX12": "B3", "TX13": "B4", "TX14": "B5", "TX10": "B6", "TX11": "B7", "TX15": "C0", "TX18": "C1", "TX19": "C2", "TX20": "C3", "TX21": "C4", "TX22": "C5", "TX16": "C6", "TX17": "C7", "TX24": "LVAL", "TX25": "FVAL", "TX26": "DVAL", "TX23": "SPARE", } assert len(pinmap) == 28 assert sorted(pinmap) == sorted(f"TX{i}" for i in range(28)) # 无跳号、无重复占用 pixels = [v for v in pinmap.values() if v[0] in "ABC"] print("像素位数量:", len(pixels)) # 24 print("限定/杂项:", [v for v in pinmap.values() if v[0] not in "ABC"]) # LVAL FVAL DVAL SPARE这两条断言值得单独说一句。第二条断言实际是在验证“28 个引脚被 28 个信号恰好填满”，任何一颗芯片只要有一个引脚没分配或者被重复分配，硬件设计阶段就该停下来。很多自制采集卡在调试阶段出现“某些像素永远是 0”的现象，追到底就是某个端口位接到了错误的引脚上，软件侧无论怎么调都补不回来。
3.2 三组 Channel Link 的端口划分与引脚映射设计
为什么要把位序打散？核心动机在表 2 里那句看似平淡的描述：TX0 这一个引脚，在三种模式下分别承载 A0、D0、G0。也就是说，物理引脚号是固定的，逻辑端口名是随模式变的。标准这么做，是为了让 26 针连接器的引脚定义在三种配置下完全一致——Base 模式的相机和 Full 模式的相机，插的是同一种连接器，用的是同一套针脚定义，只是针脚上跑的内容不同。
这个解耦带来两个直接后果。第一，同一块采集卡硬件可以在固件层面切换支持哪种模式，不用改板。第二，端口 D、E、F 的器件连接方式与 A、B、C 完全相同，端口 G、H 与 A、B 相同，端口 F 与 C 相同，硬件设计可以复用同一套走线规则，不需要为每个端口单独设计。代价是引脚映射变复杂了，人眼不容易校验，必须靠工具比对。
另一个不那么显性、但业内普遍认同的原因是板级布线。把同一端口的 8 位打散到不同位置，走线时可以把它们分摊到连接器两侧的不同差分对上，避免 8 根线全挤在一起造成串扰。这个解释没有写进规范，但从映射的规律性看，确实不像随手排的。
三种模式下的芯片与连接器用量也需要对齐看：
| 配置模式 | 占用端口 | Channel Link 芯片数 | 标准电缆根数 |
|---|---|---|---|
| Base | A、B、C | 1 | 1 |
| Medium | A~F | 2 | 2 |
| Full | A~H | 3 | 2 |
Full 模式三颗芯片只用两根电缆：第一根承载 A~F 两组，第二根承载 G、H 那一组，同时把相机控制和串行通信也一并带过去。这也是“只插一根线为什么图像出来一半、参数还改不了”的根源。
3.3 每周期输出几个像素，端口就占几个
端口占用规则本身很简单：相机每个周期输出 1 个像素就用 A，输出 2 个用 A、B，输出 3 个用 A、B、C，一直到 8 个像素占满 A~H。麻烦的是位深——8 位像素一个端口装得下，10 位、12 位、14 位、16 位像素在标准里的处理方式是两个端口装一个像素，低 8 位放第一个端口，高位放第二个端口，中间的空位闲置。
这就导致 10 位像素的相机在 Base 模式下只能跑 1 个 tap，因为 2 个端口已经被一个像素吃掉了，第三个端口凑不出第二个完整像素。很多选型阶段的误判就发生在这里：按 8 位算绰绰有余的配置，换成 10 位直接不够用。
PORTS = [("Base", 3), ("Medium", 6), ("Full", 8)] def pick_config(taps, bpp, clk_mhz=85.0): """taps: 每周期并行输出的像素数；bpp: 单像素位深""" ports_per_tap = 1 if bpp <= 8 else 2 # 10/12/14/16 位统一占 2 个端口 need = taps * ports_per_tap for name, avail in PORTS: if need <= avail: mpx = taps * clk_mhz # 百万像素/秒 mbs = mpx * bpp / 8 # 有效像素带宽 MB/s waste = (avail - need) * 8 # 每周期闲置的位数 return name, need, avail, mpx, mbs, waste raise ValueError(f"{taps} tap x {bpp} bit 已超出 Full 模式的端口上限") for taps, bpp in [(1, 8), (3, 8), (2, 10), (4, 10), (8, 8)]: name, need, avail, mpx, mbs, waste = pick_config(taps, bpp) print(f"{taps}tap/{bpp}bit -> {name:<6} 占用{need}/{avail}端口 " f"{mpx:.0f} Mpix/s {mbs:.1f} MB/s 闲置{waste}位")四组结果很能说明问题：3tap/8bit 用满 Base 的 3 个端口，255 Mpix/s；2tap/10bit 要占 4 个端口，直接跳到 Medium，只跑出 170 Mpix/s，还闲置 16 位；4tap/10bit 用满 Full 的 8 个端口，340 Mpix/s。位深从 8 涨到 10，像素吞吐不升反降，这不是带宽不够，是端口粒度和位深不匹配造成的结构性浪费。
4. 非图像信号：CC1~CC4 与 SerTC/SerTFG 是怎么挤进同一根电缆的
4.1 四路相机控制信号的电气定义与时序语义
三种配置模式下，都固定有 4 对 RS-644 LVDS 线用于相机控制，方向始终是采集卡输出、相机输入，信号名固定为 CC1 到 CC4。标准在这里只规定了电气特性和方向，语义完全留给相机制造商自定义，只给出一个“通常这么用”的参考：CC1 做外同步 EXSYNC，下降沿触发；CC2 做像素重置 PRIN，低电平有效；CC3 做扫描方向 FORWARD，高电平有效、低电平翻转；CC4 不定义。
这个“电气定死、语义放开”的设计是标准里少见的留白。好处是给了厂商足够的灵活性去实现差异化功能，代价是互换性在控制层被打了个折扣——同样是 CC1，A 厂用它做触发，B 厂可能用它做曝光门控。做系统集成时，如果只对着“Camera Link 标准”这四个字去接线，很可能遇到“图像正常但触发不响应”这种看起来毫无道理的现象。
这一段建议在选型阶段就把四路控制信号的语义从厂商文档里抄出来，做成一张对照表存进项目仓库，后续换型或替换采集卡时能省掉大量排查时间。
4.2 串行通信的帧格式与 API 边界
串行通信走两对差分线：SerTC 从采集卡发往相机，SerTFG 从相机发往采集卡，方向固定。协议沿用异步串行格式，也就是 RS-232 那一套：1 位起始位、8 位数据位、1 位停止位、无握手、无奇偶校验。标准规定的最小波特率是 9600，这是下限而非上限，厂商可以在自己的实现里支持更高档位。
标准在这里还额外规定了一条软件层的要求：采集卡制造商必须提供一个 API，用户通过动态链接库管理串行通信，并且要提供一个至少能收发字符串或几个字节的终端程序。这条要求的分量比看起来重——它把“串口怎么访问”从硬件细节抬到了接口契约层面，让上层软件不必关心底下是哪个厂商的卡。
import serial # 这个串口句柄通常由采集卡驱动虚拟出来，不是主板原生串口 link = serial.Serial( port="COM3", baudrate=9600, # 标准规定的下限，高速档位属于厂商扩展 bytesize=serial.EIGHTBITS, # 8 位数据位 parity=serial.PARITY_NONE, # 无校验 stopbits=serial.STOPBITS_ONE, # 1 位停止位 timeout=0.2, # 相机不应答时必须能超时返回 ) # 注意：下面这帧的字节内容由相机厂商私有协议定义，不能跨品牌照抄 link.write(b"\x01\x00\x00") resp = link.read(4) if len(resp) < 4: print("相机无应答：先查 SerTC 差分极性，再查波特率")这里有两个参数值得单独拎出来。timeout 不是可选项，采集线程里如果用一个没有超时的阻塞读去等相机回应，一旦相机断电或者线缆接触不良，整个采集流程会挂死在那一行，现象是“软件卡住但没有任何报错”，属于典型的黑匣子故障。另外一个容易忽略的点是差分极性：SerTC 的 P/N 如果接反，接收端看到的是持续的反相电平，物理层看起来“有信号”，协议层却一个字节都收不到，用回环测试还测不出来。
4.3 FVAL、LVAL、DVAL 的限定逻辑与线阵相机的特殊处理
图像数据本身没有帧边界信息，边界是靠三根限定信号划出来的。FVAL 在帧有效期间保持高电平，LVAL 在行有效期间保持高电平，DVAL 表示数据有效。标准里对 DVAL 有一句关键说明：相机的数据率低时用它做门控，数据率高时直接接高电平。也就是说 DVAL 是为低速相机准备的兼容手段，高速链路里它通常被拉高，实际起门控作用的是 LVAL。
线阵相机是个特例：它没有“帧”的概念，只有连续的行，所以 FVAL 直接接高电平，采集卡靠 LVAL 的个数来累计行号，靠外部的编码器信号或者 CC1 来决定什么时候算一“帧”。这个差异在做软件适配时必须显式处理，把线阵相机当成面阵去等 FVAL 下降沿，等到的只会是超时。
采集卡侧的还原逻辑大致是这样：FVAL 上升沿清零行计数器，LVAL 上升沿把行计数器加一，每个像素时钟在 LVAL 为高时把端口上的 8 位（或者多端口拼起来的更多位）锁进行缓冲。这里有个隐含前提——LVAL 的跳变必须与像素时钟同步，且抖动小于一个像素周期。一旦抖动超限，行计数器就会在错误的时刻加一，表现出来的现象是图像整体错位若干行，而且错位的行数每次上电都不一样，非常像玄学问题。
5. 避坑与排查：模式选错、线序对不上、丢帧错行的典型现场
5.1 模式与物理连接类故障
现象一：Full 模式的相机接上采集卡，只出画面左上角一块，其余区域全黑或者重复。
原因基本可以确定在采集卡侧。采集卡如果只实现了一组 Channel Link 接收器，它只能解析第一根电缆上的 A~F 端口，第二根电缆上的 G、H 数据根本没被读进来，行缓冲里剩下的位置保持初始值。反过来，把 Base 相机接到 Full 采集卡上一般不会出问题，因为采集卡只是空等 G、H 的数据，A~C 照常解析。
解决办法是先确认采集卡规格书里写的是哪种配置，再决定是改相机输出模式还是换卡。有些采集卡支持固件级切换，但需要显式配置，不会自动识别。
现象二：Medium 或 Full 配置下，图像能出来，但所有参数都改不了，串口发命令毫无响应。
原因在电缆数量。Full 模式的第二根电缆不仅承载 G、H 那一组 Channel Link，还承载 CC1~CC4 和 SerTC、SerTFG。只插第一根线，像素数据齐了，控制通道却是断的。这个现象很有迷惑性，因为“图像正常”会让人下意识排除硬件连接问题。
解决办法是逐根确认电缆连接状态，并在软件启动时加一条串口探活：发一条读版本号的命令，超时未响应就直接报错退出，而不是带着半瘫的链路继续跑。
现象三：3 米线一切正常，换成 10 米线后开始随机丢帧，帧率越高越严重。
原因通常是电缆不达标。Camera Link 对线缆的要求不只是“双绞屏蔽”，还要求线对之间和线对内部的偏斜严格受控。85MHz 下位周期约 1.68ns，非标准线缆的对内偏斜很容易超过这个值，接收端采样点漂移到数据跳变沿上，误码率随距离和速率一起上升。10 米是标准给出的上限，不是所有 10 米线都能跑满 85MHz。
解决办法是核对电缆的型号规格，确认它是为高速差分应用设计的集成电缆；临时排查可以把像素时钟降一档，如果降频后误码消失，基本可以锁定线缆问题。
5.2 时序与数据完整性类故障
现象四：图像偶发整体错位一到两行，重启后错位行数变化，重复上电现象不一致。
原因多半在 LVAL 或 FVAL 的极性配置上。有的相机 LVAL 高有效，有的低有效，采集卡侧如果配反了，行计数器会在错误的边沿加一。另一种可能是 LVAL 与像素时钟的建立保持时间不足，跨时钟域时偶尔采到跳变中的电平。
解决办法是先用固定的测试图案（比如棋盘格）观察错位是否与行号有规律关联，再逐一核对相机与采集卡的极性配置。用示波器同时抓 LVAL 和像素时钟，看边沿关系是否稳定，比在软件层反复试参数高效得多。
现象五：相机能正常出图，但串口只能发不能收，或者完全无响应，回环测试却通过。
原因是 SerTC 或 SerTFG 的差分极性接反。差分对反接后，接收端看到的是一对反相信号，电平判据始终落在阈值之外，物理层测得到波形，协议层一个字节都解析不出来。回环测试测的是本地收发器，绕过了线缆和相机，所以测不出这个问题。
解决办法是对照引脚定义表逐个核对差分对的 P/N 顺序，特别是自制的转接板或者第三方线缆。这个坑值得记一笔：它属于典型的“硬件问题伪装成软件问题”，在软件层查波特率、查协议格式可以耗掉一整天。
6. 设计取舍：为什么标准停在 85MHz、10 米和三档配置
把这三个数字放在一起看，会发现它们不是各自独立拍脑袋定的，而是同一条约束链上的三个截面。
85MHz 是并行时钟的上限，再往上走，随路时钟与 4 条数据线之间的偏斜会吃掉采样窗口。源同步接口没有时钟恢复电路，也没有编码带来的直流平衡，它能容忍的偏斜就是一个位周期。595Mbps 下单对线的位周期是 1.68ns，这个量级已经逼近普通双绞线在 10 米长度上的偏斜控制极限。想再快，就得换掉整个物理层架构，加时钟恢复、加编码、加链路训练——那已经不是 Camera Link 了。
10 米同理。标准给出的有效长度是 1 到 10 米，常用的是 3 米。这个数字背后是衰减和偏斜的联合约束，不是随便写的推荐值。工程上把它当硬指标，不要试图用“更好的线”去突破，因为瓶颈往往不在铜线上，而在连接器与 PCB 过孔的阻抗一致性上。
三档配置的取舍更微妙一些。Full 模式相比 Medium，端口从 6 个涨到 8 个，有效像素位从 48 涨到 64，只多了三分之一，代价是多一颗 Channel Link 芯片、多一组差分对、多一根电缆。标准仍然保留这一档，是因为在某些高分辨率线扫描或者多 tap 面阵场景下，这三分之一恰好是够与不够的分界线。换句话说，Full 模式不是为“更快”设计的，是为“刚好够”设计的。
这套设计还有一个隐性的取舍：Camera Link 没有速率协商，没有链路训练，插上是什么模式就是什么模式，配错了不会自动降级。这带来的好处是延迟确定、启动快、协议栈极薄，坏处是错误没有任何后悔药——模式不匹配就是不出图，极性接反就是一个字节都收不到，而且这些错误大多不会给出明确报错。我一般会把“带宽账、端口账、极性账”这三本账在项目启动阶段就算一遍，把结果写进硬件接口文档里，而不是等调试阶段靠示波器一处处试。
从那以后我每次接手一个新的相机加采集卡组合，都强制先跑一遍端口占用和有效带宽的计算，再核对一遍差分对极性表，最后才通电。这个习惯救过我很多次，也希望帮到你。这套规范本身不复杂，复杂的是那些散落在引脚表、配置模式和电气参数之间的对应关系，把它们整理成一份能随时查的资料，比反复翻手册要省事得多。
本文还有配套的精品资源，点击获取
