远远看去，一台 GNSS 接收机像是位置 API。贴近硬件之后，它其实是一个稀缺的设备文件，按自己的节奏吐出报告：内容可以是 NMEA 语句、厂商二进制数据包，也可以是经串口、USB、蓝牙、TCP 或其他传输方式送来的导航与状态消息混合流。一个应用可以直接打开这股数据流。第二个应用若要使用同一接收机，只能共享这条流、借助代理转发，或者失去访问机会。

gpsd 在接收机专属字节与位置感知程序之间设置一层持久的服务分界，解决接收机数据接入与分发问题。它识别数据包，选择用户空间驱动，积累每台设备的状态，再把与设备无关的报告发布给多个客户端。这套架构把三个经常混在一起的事项清楚分开：接收机说了什么、客户端此刻能够知道什么，以及高精度的每秒一脉冲（PPS）边沿怎样成为时钟输入。[1][2][3]

封面照片说明这层间接关系为何值得保留。两台面向测绘的 Navcom 接收机摆在 Garmin 手持机旁，其中一台 Navcom 接着蓝牙串口适配器。[8] 这些设备各有特性；gpsd 让物理链路或接收机方言的变化止步于服务层，下游软件仍沿用同一套客户端解析逻辑。

从线端到客户端，要经过四个阶段

当前的 Hacker's Guide 把 gpsd 分成四部分：包嗅探器、驱动、核心库和多路复用器。[2] 沿着一个字节在这四部分中的行程看下去，比罗列功能更能说明系统怎样运作。

第一层，包嗅探器从输入字节流中找出符合分帧规则且校验和有效的数据包。识别工作贯穿整个会话，最先识别出的包类型只代表当时状态。接收机可以在 NMEA 与厂商二进制模式之间切换；AIS 设备也可以在同一条线路上发出多种协议。把识别当作持续运转的状态机任务，才能跟上这些变化，传输探测也由此留在应用代码之外。[2]

第二层，驱动解读已经识别的载荷。驱动掌握芯片组或协议细节：怎样把一条语句或一段二进制数据转换成时间、位置、速度字段，以及状态、卫星观测或设备信息。客户端套接字由其他层管理。这道分工让 gpsd 可以支持 NMEA 变体，以及 Garmin、Navcom、SiRF、Trimble、u-blox 等厂商的二进制格式；协议集合集中维护一份，使用数据的应用不再各自携带同样的解析代码。[2][6]

第三层，核心库管理设备会话。它打开设备路径，在需要时探测波特率和串口帧格式，向嗅探器查询收到的内容，选定相应驱动，并维护会话状态。会话按设备分别建立。连接两台接收机时，gpsd 会分别给报告标注设备来源；所谓合成的“最佳”位置，不在这一层发生。[2][4]

最后，多路复用器管理客户端会话、watch 策略、热插拔通知和报告分发。默认套接字服务监听 TCP 端口 2947，通常只绑定回环地址。客户端连接后先收到一个 VERSION 对象，再用 ?WATCH={"enable":true,"json":true} 这样的命令请求流式报告。多个程序于是可以同时观察一台接收机，免去争抢 /dev/ttyUSB0 所有权的局面。[1][3][6]

这种分工也让功耗行为一目了然。gpsd 可以把打开接收机的时刻推迟到客户端请求 watch；有些硬件只要串口没有持续打开，就会进入低功耗状态，这一点很重要。授时部署采取相反策略：-n 让 gpsd 从启动起持续访问接收机，因为即使没有位置应用连接，时钟输入也必须保持连续。[3][5][6]

JSON 把缺失也写进契约

客户端启用 watcher 模式后，gpsd 发出由不同 JSON 对象组成的流，按照类别分别交付报告，完整程度随当时可用的数据而变。TPV 包含时间、位置和速度；SKY 包含可见卫星信息；DEVICE 描述数据源；在客户端提出请求且数据可用时，PPS 和 TOFF 表示定时事件。每个对象都有 class 字段，消费方可直接按含义分派，省去从字段形状猜测类别的过程。[4]

协议中最重要的选择之一，是怎样表达缺失数据。gpsd 会省略可选属性，未知值保持缺席，安慰性的 0 与 JSON null 都不会拿来补位。TPV.mode 区分未知、无定位、二维定位和三维定位；海拔、速度或误差估计等单项字段仍以实际可用性为准。规范还提醒读者，接收机给出的许多误差估计没有说明所用置信度约定，因此 gpsd 仅仅统一字段名称，也无法把这些数据变成证明力更强的证据。[4]

这项契约要求客户端理解状态。使用纬度、海拔、时间或不确定度之前，它必须检查定位模式和字段有效性，也必须记住每份报告来自哪个 device。客户端库的一部分作用，是吸收协议演变并把对象流转换成程序所用的原生类型。协议转换到此为止：缺失的定位依旧缺失，陈旧的累计状态也不会变成当前状态。[3][4]

协议还有一条更底层的故障界线。按当前协议，一条 JSON 响应的上限为 10,240 个字符；超长响应可被截断，结果成为无效 JSON。读取迟缓的 watcher 若逐渐塞满自己的套接字缓冲区，连接会被断开。在通常的 GNSS 报告速率下，这些情况很少出现，但它们仍然说明客户端应怎样处理这条流：持续读取，把每个对象视为长度有上限的消息，在条件合适时采用客户端库，并为断线制定清楚的重连策略。套接字是会失效的外部连接，不能假定为永驻内存的变量。[3][4]

语句标明是哪一秒，脉冲标出它的边沿

导航时间与精密授时都从同一台接收机进入系统，却沿着两条性质不同的信号路径。

带内的 NMEA 或二进制报告可以写明一次定位对应的 UTC 时间。它的送达时刻相对粗糙：接收机完成计算、缓存，再成批发送语句；串口分帧、USB 轮询、内核调度和接收机自身行为都会增加长度不定的延迟。gpsd 授时指南指出，定位消息与实际测量之间可相差数百毫秒，延迟也会发生变化。这类消息适合识别具体是哪一秒，用它标记两秒之间的精确交界则误差太大。[5]

支持 PPS 的接收机每秒额外输出一个独立电气边沿。Linux 内核启用 PPS 支持后——通常是 CONFIG_PPS，再加上 CONFIG_PPS_CLIENT_LDISC 之类的相应客户端或 GPIO PPS 客户端——内核可以在更靠近中断的位置给边沿打时间戳，比用户空间线程更贴近中断发生时刻。授时指南记载，在合适的硬件和负载下可达到微秒量级；USB 轮询、线缆接法、驱动支持与主机延迟均可扩大误差预算。[5]

因此，两路输入互相补足。串口报文说明接收机指的是哪一秒；PPS 则用低得多的抖动说明这一秒的边沿落在哪里。单独的 PPS 没有完整 UTC 标签；解析得再漂亮的时间戳，也不会自动拥有精密脉冲的边沿精度。

gpsd 的职责在一次有意划出的交接处结束。它可以经共享内存或 chrony 套接字导出带内时间与 PPS 定时，例如 /run/chrony.ttyS0.sock 和 /run/chrony.pps0.sock。随后由 chronyd 或 ntpd 评估参考源并校正系统时钟。gpsd 担任接收机翻译器并供给定时事件；时钟控制算法由另一个守护进程负责。[5][6]

这道分工也改变了排障顺序。如果 cgps 没有显示有效的三维定位，问题仍落在接收机、天线、天空可见度或导航数据解码层。导航报告已经抵达，而 gpsmon 或 ppscheck 看不到 PPS 时，应检查接收机能力、控制线接法、/dev/pps0、内核配置、权限，以及串口或 USB 驱动。如果两路信号都到达 gpsd，而 chronyc sources 没有选中该参考源，余下的问题属于 chrony 配置和信源比较。“GPS 时间坏了”把诊断说得过于粗略；分层之后，每一步都有可以证伪的检查项。[5]

零配置是一项设计取舍，其承诺止于特定范围

gpsd 针对一项特定取舍设计：插入受支持的接收机，让热插拔与协议探测处理常规工作，再向多个应用提供稳定的时间与位置服务。项目文档明确偏爱自动波特率探测和自配置；如果某类棘手硬件要求削弱数据包校验或增加设备专属启动开关，项目宁可放弃支持。[1][2]

这个取舍很适合移动 Linux 主机、船载计算机、现场记录器、机器人平台或小型天文台，在这些设备上，一台接收机往往要供多个只读客户端使用。到了配置现代 GNSS 硬件全部高级功能的工作，这套方案覆盖的范围会收窄。James Clark 在 2026 年将 gpsd 与 SatPulse 作了独立比较，准确指出了这条分界：gpsd 为接收机的周期数据提供与设备无关的模型，但与设备无关的配置能力有限；厂商专属任务可以转交给 ubxtool 等工具。[7]

包装脚本也无法自动补上这道职责缺口。一台授时设备若要设置天线延迟、脉冲宽度、固定位置授时模式、星座、RTK 行为或接收机非易失状态，就需要明确的配置负责人。把这些写操作混入零配置读取服务，会让启动顺序和恢复责任变得模糊。当核心诉求是归一化与共享时，可以采用 gpsd；当产品本身包含接收机编程时，应评估以配置为中心的设计。[7]

网络暴露也需要同样清楚的责任划分。默认配置只监听回环地址。-G 会把监听器改为所有地址，gpsd 手册警告，这会向网络可达的客户端披露当前位置。[6] 远程数据源在可信的仪器网络中很有用，但它应被明确设为服务分界，并接受防火墙配置和隐私审查。仅为解决另一台机器打不开串口而顺手加上这个选项，会绕过这些责任。

除了良好定位，也要演练出故障的那一分钟

一个有用的试点可以由一台 Linux 主机、一台受支持的接收机和两个有意选择为不同类型的客户端组成。先让守护进程与硬件位于同一台主机，确认物理设备路径，再用 gpsmon 查看原始数据包识别和驱动选择。用 cgps 查看归一化的定位与天空状态。随后运行第二个客户端，例如一段小型 libgps 程序或 gpspipe，确认两者可以同时消费接收机数据，也都不直接占用串口设备。[1][2][3]

接下来录制一小段原始数据包日志，再用 gpsfake 回放。硬件归一化若是服务价值所在，测试就应摆脱等待相同卫星几何和现场条件重现的限制。需要逐项断言无定位、二维定位、三维定位、海拔缺失、设备断开、重新连接，以及接收机开始报告后才启动客户端时的行为。检查重点应放在 device 字段和有效性状态上，纬度是否出现只是其中一项。[2][4]

授时用途应在导航路径已经理解之后再加入 PPS。分别在内核层和 gpsd 层验证脉冲，在 chronyc sources 或相应的 NTP 工具中确认带内信源与 PPS 信源彼此独立，并在试用期间保留独立的网络时间源。随后遮挡天线，或将接收机断开足够长的时间，以观察失去参考后的守时（holdover）与信源拒绝。天空开阔时的一盏绿灯，证明力不及参考源消失时的一次干净切换。[5]

初始采用的门槛不高。当操作系统、接收机型号和消费方都已知时，一名工程师就能负责现场设备上的 gpsd。到了设备群，还要补上更多条件：稳定的 /dev/serial/by-id/ 命名、软件包版本控制、用于回归分析的原始日志采集、定位和 PPS 丢失告警、端口 2947 的隐私规范，以及一台用同一套日志与客户端测试套件验证过的替换接收机。无法观测这些状态的团队，不宜把一次成功的 cgps 画面直接升级为定位或授时服务。

gpsd 延续至今的核心思想，是把硬件差异限制在明确范围内；让导航硬件变得整齐划一，从来不在它的承诺之中。接收机字节仍是接收机字节；驱动负责翻译；JSON 报告呈现已知内容并省略未知内容；PPS 与为它标注秒数的报文保持独立；校正时钟则归另一个守护进程负责。这样的分工已经足以让一个棘手的串口设备成为可靠的共享基础设施，同时尊重物理世界远比 API 更凌乱的事实。

来源

1. GPSD 项目，“GPSd — Put your GPS on the net!”——共享传感器访问、客户端库、热插拔行为和接收机自动检测。
2. GPSD 项目，“Hacker's Guide to GPSD”——当前的包嗅探器、驱动、核心库、多路复用器、自配置和回归测试分界。
3. GPSD 项目，“GPSD Client HOWTO”——异步接收机行为、端口 2947、WATCH、客户端库、设备状态和慢速读取方处理。
4. GPSD 项目，gpsd_json(5)——JSON 类别、可选字段语义、TPV 定位模式、watch 策略、定时对象和消息长度限制。
5. Gary E. Miller 与 Eric S. Raymond，“GPSD Time Service HOWTO”——带内定时延迟、PPS 与内核 PPS、向 chrony/NTP 的交接、诊断和故障模式。
6. GPSD 项目，gpsd(8)——受支持的接收机协议、-n、默认回环套接字行为、-G 隐私分界和 PPS 导出。
7. James Clark，“Design of SatPulse compared with GPSd”，2026 年 4 月 11 日——对 gpsd 服务、零配置、接收机共享和配置分界的独立比较。
8. Wsx2，“Navcom GPS Receivers”，Wikimedia Commons——2006 年拍摄的两台 Navcom 接收机、一台 Garmin 12XL 和一个蓝牙串口适配器。