2.1 PPS 与 GPRMC 怎样配对#

GPRMC 是 NMEA RMC 报文的一种形式，包含 UTC 时间、日期、定位状态等字段。普通 GNSS 接收机的授时来自卫星导航系统，并不是先通过 NTP 获取时间再填入 GPRMC；NTP 可以用于后续向其他主机分发时间。u-blox RMC 与时间输出说明

下面假设设备手册已经确认：每个 PPS 之后输出的 RMC，描述刚刚发生的这个秒边沿。图中时间间隔用于说明先后关系，不按比例绘制。

实现时先缓存每个 PPS 的序号和捕获值，再按接收机的报文时序建立关联。检查 RMC 日期与秒编号是否连续，同时记录串口延迟范围。若报文可能跨过下一个 PPS，不能直接把它绑定到“最近一次 PPS”；应按协议和已保存的事件匹配，无法确定时保持未锁定状态。

2.2 串口传输延迟为什么不能忽略#

对于 8N1 串口，一个字节占用 1 个起始位、8 个数据位和 1 个停止位，即 10 bit。假设一条报文含终止符共 80 字节，波特率为 9600：

1
传输时间 = 80 × 10 / 9600 s ≈ 83.3 ms
2
PPS 至解析完成的时间
3
    = PPS 至开始发送的等待时间 + 串口传输时间 + 接收与解析延迟

这个计算说明，RMC 描述的时刻与“收到完整 RMC 的时刻”可以相差几十毫秒。提高波特率可以缩短传输，但不会自动消除内部等待，也不能代替 PPS 对应关系的确认。

RMC 解析至少要检查报文边界、校验和、字段完整性、UTC 时间和日期，以及相关有效状态。RMC 的日期字段通常为 ddmmyy，两位年份需要明确的世纪解释规则；时间字段可以包含小数秒，不应直接丢弃。定位状态也不能代替接收机专用的时间有效或 UTC 有效标志。u-blox RMC 字段与有效性说明

多星座设备可能输出 GNRMC。GD32 解析器可根据设备协议兼容不同 talker ID，但雷达是否接受该报文头需单独确认；转换报文内容后必须重新计算校验和。内部统一保存 UTC 或约定的时间尺度，界面显示北京时间时再做 UTC+8 转换，避免给雷达发送带时区偏移的错误秒编号。

4.1 用输入捕获记录 PPS#

定时器输入捕获的关键是：有效边沿到来时，硬件将计数器值锁存到捕获寄存器，中断稍后读取这个值。读取捕获值与进入中断后读取当前计数器，是两个不同的时刻。GD32F30x 用户手册：TIMER 输入捕获

设计时需要核对具体芯片的定时器位宽、通道引脚、时钟来源、滤波器、DMA 请求和定时器互联能力。GD32 系列之间存在差异，不能把某款芯片的 TIMER 编号和引脚复用直接套到另一款上。

下面以计数频率 10 MHz 为例：

1
一个 tick = 100 ns
2
一秒约有 10,000,000 个 tick
3
16 位计数器约每 6.5536 ms 回绕一次
4
32 位计数器约每 429.497 s 回绕一次

100 ns 是计数分辨率，并不代表整个系统达到 100 ns 同步精度。输入同步、滤波、电平转换、线缆和传感器内部延迟仍然存在。

尽量保留自由运行的单调计数器。在计数器位宽不够时，需要可靠的扩展计数：处理溢出与捕获同时发生的顺序，并保证不会漏记溢出；不能只靠两次 16 位捕获值相减来测量一秒。

4.2 建立 tick 到统一时间的映射#

设某个有效 PPS 的扩展计数为 Ck，该边沿对应的统一时间为 Tk，每秒计数的估计值为 f_est。附近事件的时间可以估算为：

1
T_event = Tk + (C_event - Ck) / f_est

例如：

1
Tk      = 2026-08-20 12:00:00 UTC
2
Ck      = 100,000,000
3
C_event = 102,500,000
4
f_est   = 10,000,000 tick/s
5

6
事件时间 = 12:00:00.250000 UTC

实际计数频率会随晶振误差和温度变化。连续两个有效 PPS 之间的计数差可以估计一秒内的频率，多个周期可用于滤波。异常 PPS、漏脉冲或重复脉冲应先排除，再更新估计值。

在线生成触发时，只能使用此前已知的频率估计；离线处理中，则可以用前后两个已确认的 PPS 对该秒内事件插值。更新映射时还要保证时间输出连续，避免每秒更新参数造成时间戳跳变。

统一时间建议保存为 int64 纳秒或“整数秒 + 子秒”，本地计数使用足够宽的整数。不要用 float 保存 Unix 秒级时间再期待微秒精度。

4.3 GPRMC 解析完成后，怎样得到当前时间#

参考资料常把从 PPS 到解析完成的经过时间写作 tx。在 GD32 中，可以直接用同一自由运行计数器计算它，而不必猜测 UART 和软件分别延迟了多少。

假设 RMC 已确认描述 12:00:00 UTC 的 PPS，读取当前计数的时刻得到：

1
PPS 捕获值 Ck       = 100,000,000
2
当前扩展计数 C_now  = 100,923,000
3
估计计数频率 f_est  = 10,000,000 tick/s
4

5
tx = (C_now - Ck) / f_est = 92.3 ms
6
读取 C_now 时的时间 = 12:00:00.092300 UTC

tx 已包含该 PPS 至当前读取时刻的全部经过时间，不能再叠加一次 83.3 ms 的串口传输补偿。也不要将解析得到的整秒时间直接设置为“现在”，否则会把已经经过的 92.3 ms 丢掉。

解析期间可能已经发生相机触发或 IMU 数据事件。先保留这些事件的原始 tick，待 Tk ↔ Ck 配对确认后，再计算各自的时间戳。例如 C_event = 100,500,000 的事件对应 12:00:00.050000 UTC，不会因为时间报文在 92.3 ms 后才解析好而改变。

5.1 一个便于理解的频率组合#

假设设备支持以下工作频率：

相机触发可放在每秒的 0、50、100……950 ms，IMU 同步事件可放在 0、5、10……995 ms。如果硬件允许，这两组输出应共享定时基准，避免独立定时器自由运行导致相位逐渐漂移。

对于不整除计数频率的周期，可交替安排相邻整数 tick 间隔，将舍入误差分散。例如 10 MHz 下的 30 Hz 周期不能永远固定为同一个整数 tick，否则长期平均频率会有偏差。

5.2 输出比较与脉宽#

可以按芯片能力选用输出比较、PWM、定时器主从触发或 DMA 更新比较值，在硬件上产生边沿。输出比较匹配的是计数器与比较寄存器，具体输出动作取决于配置的比较模式。GD32F30x 用户手册：TIMER 输出比较

输出信号必须同时满足设备要求的周期、最小高低电平时间和触发极性。对需要独立脉宽的触发，分别调度上升沿和下降沿，或使用合适的 PWM/单脉冲配置。

若由软件更新下一次比较值，要保证写入时目标值仍在未来，并检测错过比较窗口。涉及多个定时器时，应核实内部触发路由及它们的相位关系。

不要每到 PPS 就直接重置正在输出触发的计数器：这样可能让边界附近出现重复脉冲、漏脉冲或异常短周期。更稳妥的思路是使用连续计数和绝对比较目标，平滑校正后续事件；需要重新建立相位时，明确暂停、重启边界与状态。

10.1 工控机接入 PPS 与时间报文#

对于支持 RS-232 调制解调器信号的工控机串口，PPS 可由 DCD 输入捕获，时间报文通过 RX 接收。标准 DB9 DTE 的常见定义为 1 脚 DCD、2 脚 RX、5 脚信号地；实际仍以设备手册和线缆连接为准，尤其要检查 DCD 是否真的接出。GD32 的逻辑电平不能未经转换直接接到 RS-232 接口。LinuxPPS 接入说明、GPSD 接线排查

物理端口标签 COM1 不保证一定对应 /dev/ttyS0；PCIe 扩展串口和 USB 串口的命名可能不同。USB 转串口能接收 RMC，也不代表支持 DCD 的 PPS 捕获，即使支持还需评估 USB 引入的延迟和抖动。LinuxPPS 的 USB 限制

若主机有可用 GPIO，也可采用 pps-gpio。这一方式需要正确配置内核驱动、引脚复用和设备树，不能仅把 PPS 接到任意引脚就期待出现 /dev/pps0。

10.2 从接线到系统时钟，逐层检查#

以下是排查命令示例，实际设备编号按本机替换。它们属于主机验证流程，不是 GD32 固件配置。

1
# 若发行版提供该内核配置文件，检查 PPS 与对应客户端支持。
2
rg '^CONFIG_PPS' "/boot/config-$(uname -r)"
3

4
# 检查已注册的 PPS 源，并确认其实际名称与关联路径。
5
ls /sys/class/pps/
6
cat /sys/class/pps/pps0/name
7
cat /sys/class/pps/pps0/path
8

9
# 安装 pps-tools 后，观察捕获事件。
10
sudo ppstest /dev/pps0
11

12
# 配置好授时程序后，观察时间源与系统时钟状态。
13
chronyc sources -v
14
chronyc tracking

串口 DCD 路径需要 CONFIG_PPS 与 CONFIG_PPS_CLIENT_LDISC；GPIO 路径需要相应的 CONFIG_PPS_CLIENT_GPIO。值为 y 表示内置，为 m 表示模块。加载 pps_ldisc 只提供驱动，还需要由支持它的程序将 PPS 行规程绑定到正确串口；使用 gpsd 时检查其配置和日志，避免另一个程序重复占用端口。GPSD 内核与行规程说明、ldattach 手册

串口调试工具应按 GNSS 手册设置波特率、数据位、校验位、停止位和流控。检查结束后释放端口，再交给 gpsd。setserial 中的 baud_base 是波特率计算基准，不是当前通信速率；不要照搬参考文章中的 I/O 地址、IRQ 或修改它来切换 9600 baud。low_latency 是否有效取决于驱动，应测量后决定。setserial 参数说明

10.3 chrony 中如何组合完整时间与 PPS#

一种实现方式是：gpsd 提供基于串口报文的完整时间，chrony 直接读取 LinuxPPS 的高精度边沿，再将两者配对。下面以支持报文时间 SOCK 输出的 gpsd 3.25 及以上版本、/dev/ttyS0 和 /dev/pps0 为示例，加入现有 chrony 配置：

1
refclock SOCK /var/run/chrony.clk.ttyS0.sock refid NMEA noselect
2
refclock PPS /dev/pps0 lock NMEA refid PPS

NMEA 是这里自定义的参考源标识；noselect 让粗时间源不直接参与系统时钟选择，lock NMEA 则用该源的原始样本补全 PPS 的完整时间。SOCK 路径需要与 gpsd 的设备名和运行配置一致，chronyd 应先创建套接字，再启动 gpsd；gpsd 的 -n 模式可使其在没有客户端时也持续读取设备。chrony SOCK 与 PPS 配置、GPSD 运行方式

这两行只展示时间源关联，不能替代完整部署。要核实报文时间源的延迟是否影响正确秒的判定；需要固定偏差补偿时，按测量结果配置 offset，不要复制其他设备的数值。即使 chronyc tracking 显示残差很小，也要检查绝对日期与整秒是否正确，因为错配一整秒同样可能呈现稳定的子秒残差。

11.1 接线前核对接口#

GD32 的逻辑引脚、工业相机的隔离输入、雷达的同步口和 GNSS 的 UART 未必采用相同电平。先确认电压、输入阈值、驱动电流、极性、隔离方式与共地要求，再选择缓冲、转换或隔离电路。

长线和多个负载会改变边沿质量。需要按布线条件考虑差分传输、端接、屏蔽及接收端整形；加入滤波或隔离器后，还要测量它们造成的延迟。不能只在 GD32 输出脚看到方波，就认为传感器输入端也满足要求。

PPS 能带多少节点不能只看设备数量，要按输出驱动能力、输入电容、线长和所需边沿速度评估。节点增加时，可让原始 PPS 经过专用缓冲或分配电路形成独立支路，再核对各支路的延迟差，避免一根逻辑输出直接拖动所有设备。

UART 协议与 RS-232 电气接口也需要分开理解。一个逻辑 UART TX 是否可以扇出，要按负载和缓冲设计判断；RS-232 链路不能直接当作多节点总线。只有输入端电气兼容、负载可接受且各设备不会反向驱动时，才考虑单向分发，复杂接线宜使用独立驱动支路。

11.2 分辨率、固定偏差和抖动分别评估#

能测量的固定延迟可以校准；随机抖动需要从硬件和调度链路减少。只有在误差近似独立时，才适合用平方和开根号估计综合随机误差；需要保证上界时，应分别给出各项界限并作保守估算。

13.1 先验证硬件时序#

用示波器或逻辑分析仪同时观察 PPS、相机触发、IMU 同步和可用的反馈信号，测量周期、脉宽、相位、输入到输出的延迟及其变化。特别检查整秒边界、长时间运行、计数器回绕和丢 PPS 后恢复的行为。

仅比较同一 GD32 生成的两个输出，可以验证相对时序；验证绝对授时精度还需要独立参考时间源。

13.2 再验证事件与数据的对应#

统计 GD32 触发计数、相机实际帧数、IMU 样本序号与雷达同步状态。人为制造丢帧、读取延迟和设备重启，检查事件对应关系是否仍正确，是否能检测并恢复断点。

13.3 最后做动态实验#

让传感器共同观察受控运动，比较图像变化、点云变化和 IMU 信号对应的时间。可利用可见运动靶、转台或其他重复运动进行验证，记录残余时间偏移的均值、分布和随时间的漂移。

静止场景往往无法暴露时间错位。动态实验也需要控制空间外参、曝光和传感器滤波影响，避免把其他误差全部解释成时间同步问题。