企业官网建设流程全解析

简介：面向GPS原始数据获取与基础解析的入门工程包，适合嵌入式、物联网及导航应用初学者。内容覆盖NMEA协议常见语句（GPGGA/GPRMC等）的含义解析、三维定位解算思路、速度方向计算、信号质量与GDOP评估，并基于单片机驱动LCD显示，串口读取到屏幕输出的完整处理流程可直接对照。压缩包共32个文件，约91KB，以C源码、头文件、工程配置及hex烧录文件为核心，另附GPS原始数据与处理结果文本，方便逐步验证采集和解析逻辑；包中还包含LCD驱动、主程序、工程备份等文件，目录结构适合直接打开工程学习。还可了解高楼遮挡、多路径效应及WAAS/EGNOS等增强定位方式，对实际应用中的误差来源有直观认识。已有665人学习下载，可作为GPS数据解析、串口数据处理或定位相关课程设计、项目起步的参考。

1. GPS 原始数据捕获与简单分析：串口里到底有什么值得看

GPS 原始数据捕获是很多硬件调试与地理定位项目的第一步，也是最容易被低估的一步。市面上绝大多数 GPS 模块上电之后都会持续从串口吐出 NMEA 0183 格式的文本行，里面有经纬度、速度、卫星编号、信噪比和定位状态。很多人以为把这些文本行存下来就算"捕获"了，真正做起来才发现：日志缺秒、坐标跳变、时间戳对不上、甚至采了一晚上数据回来解析出几万个完全相同的点。这篇文章围绕 GPS 原始数据的捕获与简单分析，讲清楚从串口接线到落盘、解析、验证的完整路径，适合刚接触 GPS 数据采集的嵌入式开发者、做车辆轨迹分析的从业者，以及想用低成本模块验证定位算法的同学。读完你会知道链路怎么选、脚本怎么写、哪些参数决定日志质量，更重要的是知道哪些坑我替你踩过了。

2. GPS 捕获前的链路选型：NMEA 与 UBX、波特率与日志模型

2.1 GPS 原始数据长什么样：NMEA 与其他私有协议的取舍

GPS 原始数据在各家模块上并不是统一格式。最常见的是 NMEA 0183 文本协议，每一条以$开头，以\r\n结尾，字段之间用逗号分隔。比如$GNRMC存的是推荐最小定位信息，$GNGGA存的是固定定位数据，$GPGSV存的是可见卫星详情。这类文本的好处是肉眼可读、工具链成熟，坏处是信息密度低，而且不同厂商对同一字段的填充习惯有差异。另一类是私有二进制协议，比如某厂商模块的 UBX 协议，它直接输出卫星历书、原始伪距、载波相位和信噪比，这些是真正意义上的"原始观测量"，适合做高精度定位解算。对大多数做轨迹记录、速度统计、定位质量评估的人来说，NMEA 已经够用；只有当你需要自己写定位解算器、做载波平滑或者 RTK 相关实验时，才有必要切换到私有协议输出。我的建议是第一次做捕获，先老老实实读 NMEA，跑通全链路后再考虑二进制协议。

NMEA 句子的具体细节也值得提前看清楚。以$GNGGA为例，完整的句子大致长这样：

$GNGGA,123519.00,3112.4567,N,12123.4567,E,1,08,0.9,12.3,M,5.6,M,,*47

其中第二个字段是 UTC 时间，第三个和第四个字段是纬度及南北半球标志，第五个和第六个字段是经度及东西半球标志，第七个字段是定位质量指示（0 表示无效，1 表示单点定位，2 表示差分定位），第八个字段是参与解算的卫星数量，第九个字段是 HDOP 水平精度因子，第十个和第十一个字段是海拔高度及单位。注意经纬度用的是ddmm.mmmm格式，也就是度和分混在一起写，解析时必须先分离再换算，直接当浮点数除以 60 一定翻车。详细信息放在第 4 章里拆解，这里你只需要建立两个认知：GPS 原始数据里最核心的信息不是经纬度，而是定位质量、参与解算的卫星数和精度因子；这三个字段直接决定一条记录是否值得进入后续分析流程。

2.2 捕获前的三件事：串口参数、连接线材与日志模型

选好协议格式之后，捕获链路其实只有三段：GPS 模块天线 → 串口电平转换 → 主机串口。多数民用 GPS 模块出的是 TTL 电平，也就是 3.3V 或 5V 的 UART 信号，不能直接插电脑的 RS232 串口，需要一块 USB 转 TTL 的板子。这里有个高频翻车点：部分 USB 转 TTL 板子用的是盗版芯片方案，驱动装上后串口会间歇性丢数据，表现是日志里每隔几分钟少一条句子。我第一次做 GPS 捕获时没在意这件事，把问题一路追到解析代码，最后才发现是转换器的问题。所以线材和转换器不要省钱，优先选带正规方案芯片的型号，同时注意模块和转换器的电平是否匹配，3.3V 模块接 5V 供电的转换器可能烧接口。

波特率也是链路选型里最容易被忽略的参数。NMEA 在多数模块上默认是 9600bps，少数模块支持 115200bps 输出 UBX 或高频 NMEA。手头模块如果默认配置被改过，捕获端还在用 9600 读，就会看到每行中间缺字节，整条句子拼不完整。建议上电后先用模块厂商的评估工具或示波器确认实际输出波特率，再进入采集阶段。另外要注意 GPS 模块的冷启动时间，首次上电在开阔环境下可能需要 30 秒到几分钟才能输出有效定位，很多人以为模块坏了，其实是搜星还没完成。日志模型方面，我一般会在捕获开始前就规定好文件名规则、是否带时间戳、按天还是按小时轮转，避免采完几十 GB 原始日志后不知道哪段对应哪次实验。

2.3 数据捕获与分析的最小闭环：先定标准再动手

在写任何采集脚本之前，建议先画清楚"捕获 → 解析 → 分析"的最小闭环。捕获端只负责把串口字节流完整地落到磁盘，不做过多的解析；解析端负责把文本句子里需要的字段提取出来，转成结构化表格；分析端基于结构化数据做统计和判断。这个分层看起来多此一举，实际能省很多事。因为 GPS 原始日志常常要用于回放实验，比如同一段路用不同解析器各跑一遍，或者把某个时间窗口的数据单独拎出来核对。如果捕获端就把解析做掉了，原始日志里的信息会丢失，比如信噪比、卫星号这些字段可能被你认为"没用"而抛弃，后面想补就没了。所以捕获脚本只做一件事：把每一行串口数据连同到达主机的时间一并写进文件，解析和分析全部放到离线阶段。

文件命名也应该在动手前定好。我常用的规则是城市缩写_日期_实验批次_gps.log，比如simcity_20250101_a1_gps.log，日志第一行写一行元信息：模块型号、波特率、采样地点、天线朝向。这些信息不起眼，但在数据出问题时能帮你快速排除变量。另外一个容易被忽略的点是时区。NMEA 里的时间字段是 UTC，你本机系统时间可能是 UTC+8，如果混用，后续和轨迹数据对齐时会产生整小时的偏差。建议所有日志里的时间统一用 UTC，采集脚本打的主机时间戳也强制转成 UTC 再写入，避免后续分析时反复换算搞混。

3. 捕获 GPS 原始数据：从串口到带时间戳的落盘脚本

3.1 用命令行在两分钟内跑通 GPS 捕获

正式写脚本之前，先用命令行验证链路是否通，是最快的排错方式。Linux 下常见的串口设备节点是/dev/ttyUSB0或/dev/ttyACM0，你可以用下面的命令确认设备存在并且权限可用：

ls -l /dev/ttyUSB* dmesg | tail -20

dmesg里能看到设备接入时内核打印的厂商信息和设备节点名。如果没有出现ttyUSB设备，优先检查 USB 转 TTL 板子是否被识别、驱动是否加载、线是否插紧。确认设备节点存在后，用stty配置串口参数并直接读取：

stty -F /dev/ttyUSB0 9600 raw -echo cat /dev/ttyUSB0

raw表示原始模式，不做行编辑和信号处理，这是读二进制或长文本行的关键参数；-echo禁止回显，避免把发送端的数据原样打印出来干扰判断。执行cat后如果链路正常，终端会持续滚出$GN开头的文本行。如果等了几分钟还是没有输出，先确认 GPS 模块有没有上电、天线有没有放在窗边，再检查波特率是否匹配。这个命令本身不做时间戳，不适合直接当采集工具，但用来验证链路有效性非常方便，两分钟内就能判断是硬件问题还是配置问题。

Windows 上也可以用类似思路，常见的做法是用串口调试工具先连上看有没有字符输出，但我更推荐直接装一个 Python 环境，用下一小节的脚本做连通性测试。原因是串口调试工具往往自带行尾处理和显示编码，和实际采集环境有差异，容易造成"调试工具能收到、脚本收不到"的假象。命令行验证通过后，下一步就是给数据加时间戳落盘。

3.2 给 GPS 原始数据打时间戳：一个可靠的最小采集脚本

GPS 原始数据分析里最值钱的是时间。NMEA 句子内的时间字段来自卫星时钟，精度很高，但缺少接收时刻的上下文；本机时间戳能记录数据到达主机的时刻，两者对齐后可以计算延迟、校验丢帧、关联其他传感器数据。下面的 Python 脚本是常见做法里最简单稳妥的一版：

import serial import time port = '/dev/ttyUSB0' baud = 9600 log_path = 'simcity_20250101_a1_gps.log' with serial.Serial(port, baud, timeout=1) as ser: with open(log_path, 'a', encoding='utf-8') as f: while True: line = ser.readline() if not line: continue ts = time.time() f.write(f"[{ts:.6f}] ".encode().decode() + line.decode(errors='replace') + '\n') f.flush()

这段代码的逻辑很直接：串口对象在with块里自动管理开关，循环每次读取一行，把主机当前时间戳放在行首，再连同原始句子一起追加写入日志文件。timeout=1表示每次读操作最多阻塞一秒，防止没有数据时程序死等；errors='replace'处理个别字节解码失败的情况，避免整个程序因为一个坏字节退出。注意这里没有做任何 GPS 字段解析，捕获层只管存，解析留给后续步骤，这是刻意为之。

这段脚本有两个参数最值得调。第一个是波特率baud，必须与模块实际输出一致，9600 对多数 NMEA 模块是安全的默认值；如果你之前确认过模块输出频率大于 10Hz，波特率可能已经被人为调高，要按实际值改。第二个是文件打开方式，我用'a'追加模式而不是'w'覆盖模式，防止脚本意外重启后抹掉已有日志。很多人会在这一步把flush()去掉，觉得写入文件有操作系统缓冲就够了，但在野外长时间采集时，断电或脚本崩溃会丢掉缓冲里的全部数据，所以每行都flush是必要的——代价是增加一点磁盘写入频率，对文本日志来说完全可接受。

3.3 长时间采集的两个进阶设置：文件轮转与温湿度影响

长时间采集时，单个日志文件会变得非常庞大，不利于后续解析和归档。常见的做法是按小时或按文件大小轮转。按时间轮转更适合与实验阶段对齐，比如每小时一个文件，文件名带小时；按大小轮转则更适合磁盘空间有限的情形。我这里给出按时间轮转的最小改动方案：

import serial import time from datetime import datetime, timezone port = '/dev/ttyUSB0' baud = 9600 def current_log_path(): now = datetime.now(timezone.utc) return f"gps_{now.strftime('%Y%m%d_%H')}_utc.log" ser = serial.Serial(port, baud, timeout=1) current_file = None while True: line = ser.readline() if not line: continue path = current_log_path() if current_file is None or current_file.name != path: if current_file: current_file.close() current_file = open(path, 'a', encoding='utf-8') ts = time.time() current_file.write(f"[{ts:.6f}] ".encode().decode() + line.decode(errors='replace') + '\n') current_file.flush()

注意这里做了两件事：用 UTC 生成文件名，保证文件名里的小时和 NMEA 时间字段是同一个时区基准；每次写入前检查当前小时是否变化，变化就关闭旧文件、打开新文件。name属性返回打开文件时传入的路径字符串，拿它做对比足够可靠。实际采集时我还会在脚本外面套一层nohup或把进程注册成系统服务，防止终端退出导致采集中断。另外天线位置和供电稳定性对长时间采集的影响远大于脚本本身，GPS 模块天线放在室内窗边和放在室外开阔处，捕获到的卫星数和定位质量会有数量级差异，这些属于物理层的玄学，代码再稳也救不回来。

4. 解析 GPS 原始数据：GGA/RMC 字段拆解与坐标换算

4.1 从 GPS 原始数据到结构化经纬度：GGA 解析的最小实现

捕获日志攒够之后，解析是所有分析的地基。第一步是先把 GGA 句子拆成字段，因为 GGA 包含了定位质量、卫星数、HDOP、海拔这些后续分析必然用到的核心指标。这一段代码从一个日志文件里读取所有行，过滤出 GGA 句子并解析成字典：

import re GGA_FIELDS = [ 'type', 'time_utc', 'lat_raw', 'lat_dir', 'lon_raw', 'lon_dir', 'quality', 'num_sats', 'hdop', 'alt', 'alt_unit', 'geoid', 'geoid_unit', 'empty', 'checksum' ] def parse_gga(line): if not line.startswith('$GPGGA') and not line.startswith('$GNGGA'): return None body = line.strip() body = body[body.find('$') + 1:] if '*' in body: body = body.split('*')[0] parts = body.split(',') if len(parts) != len(GGA_FIELDS): return None return dict(zip(GGA_FIELDS, parts)) with open('simcity_20250101_a1_gps.log', 'r', encoding='utf-8') as f: for raw_line in f: # 去掉本机时间戳前缀 line = raw_line.split('] ', 1)[-1].strip() data = parse_gga(line) if data and data['quality'] in ('1', '2'): # 这里只打印一条样例，实际分析时收集到列表里 print(data)

解析的逻辑并不复杂：先按句首类型过滤，再把句子里$到*之间的有效部分按逗号切分，最后和字段列表一一对应。这里有一个隐藏细节：日志行里有我们加的本机时间戳前缀[1714654321.123456]，解析前必须剥离，否则第一个字段会变成[1714654321.123456] $GPGGA，导致整行解析失败。我用split('] ', 1)[-1]处理，只要时间戳格式固定就不会出错。quality字段的过滤同样关键：值为0表示定位无效，值为1表示单点定位，值为2表示差分定位，如果不过滤，后面统计平均坐标时会把无效的0也带进去，直接污染结果。

坐标换算这一步是解析里最容易写错的地方。GGA 里的lat_raw是ddmm.mmmm格式，例如3112.4567表示 31 度 12.4567 分，转换成十进制度数的公式是度部分不变、分部分除以 60：

def convert_dm_to_dd(value, direction): value = float(value) deg = int(value / 100) minutes = value - deg * 100 dd = deg + minutes / 60.0 if direction in ('S', 'W'): dd = -dd return dd

int(value / 100)从3112.4567里取出整数部分 31 作为度，value - deg * 100得到 12.4567 作为分，除以 60 后加上度，就是十进制的 31.2076 度。S和W方向要取负值，这是经纬度换算的通用约定。很多解析翻车案例都出在int截断和数值精度上，比如有人直接把3112.4567 / 60得到 51.87，那完全是另一回事。为了验证解析结果，我会拿一个已知位置的坐标做基准，通常模块天线放在楼顶固定位置时，单点定位的经纬度在几十米内波动，如果换算后跳到几百公里外，一定是度分换算写错了。

4.2 校验 RMC 句子的校验和：别信每一行数据

NMEA 句子每条末尾*后面有两个十六进制字符，叫校验和，是$到*之间所有字符的按位异或结果。解析时做校验和能过滤掉串口传输中被干扰的坏行，这些坏行在原始日志里并不少见，尤其当 USB 转 TTL 链路质量差或者波特率不匹配时。校验和的实现很紧凑：

def checksum_ok(line): star = line.find('*') if star == -1: return False payload = line[1:star] expected = line[star + 1:star + 3] calc = 0 for ch in payload: calc ^= ord(ch) return f"{calc:02X}" == expected.upper()

payload是不包含$和*的中间部分，逐字节异或后格式化成两位大写十六进制，和句子自带的校验值比较。我在解析流程里对每条 GGA 和 RMC 都先做校验和检查，通过才进入字段拆解。这样做的一个实际好处是能统计坏行比例——如果坏行占比超过 1%，说明捕获链路有问题，需要回头查线材和波特率，而不是在解析层打补丁。RMC 句子相比 GGA 多了有效标志位和速度、航向信息，格式如下：

$GNRMC,123519.00,A,3112.4567,N,12123.4567,E,0.0,0.0,250125,,,D*5A

字段A表示定位有效，V表示无效，速度单位是节，航向单位是度。RMC 里最容易忽略的是日期字段，它的年份只有两位，而且位于句子后半段，很多人解析 GGA 时顺便想取日期却发现 GGA 里根本没有。如果需要把时间和日期合成完整的时间戳，必须同时解析 RMC 的日期段和 GGA 的时间段，两个句子之间相差不超过一秒，可以安全合并。

4.3 从原始流里提取统计视图：卫星数、HDOP 与信噪比

除了单条句子的解析，GPS 原始数据捕获后第二步通常是做质量统计，这就要从 GSV 和 GSA 句子里拿数据。GSV 句子格式比较特殊，一条完整的可见卫星信息可能被拆成多条，每条带 4 颗星的编号、仰角、方位角和信噪比。下面是一个摘取 C/N0 的片段：

def parse_gsv(line): if not line.startswith('$GPGSV') and not line.startswith('$GNGSV'): return [] body = line.split('*')[0] parts = body.split(',') # 字段分布: 总条数, 当前条, 可见星数, 然后每4颗星一组 sat_count = int(parts[2]) sats = [] for i in range(4): base = 4 + i * 4 if base + 3 >= len(parts) - 1: break try: sv = int(parts[base]) snr = int(parts[base + 3]) except ValueError: continue sats.append((sv, snr)) return sats

这里按每 4 颗星一组循环，字段偏移是固定的：从下标 4 开始，每颗星占 4 个字段（卫星号、仰角、方位、C/N0）。注意一条 GSV 最多 4 颗星，如果可见星超过 4 颗，模块会发多条 GSV，统计时需要把同一时刻的多条拼起来。信噪比数据对捕获质量评估很有价值，后面第 6 章的十分钟体检会直接用这个字段。GSA 句子则提供 DOP 值，它比单独看卫星数更能反映定位几何的优劣：卫星数多但都挤在天顶附近，HDOP 反而会很大，定位精度并不好；卫星分布均匀时，HDOP 才会比较小。用这个维度去评价一次 GPS 捕获的质量，比单纯数卫星数可靠得多。

5. GPS 捕获与分析避坑：丢帧、时间戳漂移与坐标跳变

5.1 现象：串口读到乱码、行内容残缺，每秒只出来几行

问题出现时日志里的 NMEA 句子尾部缺字符，或者一整行里夹杂不可见字符，更严重的时候一分钟只有零星几行。原因通常有两个：第一是波特率不匹配，模块实际输出 115200，采集端按 9600 读，字节错位自然产生乱码；第二是 USB 转 TTL 板子的芯片方案不靠谱，数据在操作系统驱动层就丢了。解决方法是先用硬件方案确认波特率，再用第 3 章的cat命令逐行观察输出是否稳定。如果确认波特率无误但丢行依旧，换一块转换器再测，这一步不要省钱。我见过有人在解析代码里加各种容错逻辑来对抗乱码行，这完全搞反了方向，源头不干净，解析层再怎么补也是白费功夫。

5.2 现象：日志里的本机时间戳和 NMEA 里的 UTC 时间差了整小时

这是最常见也最容易自查的问题。NMEA 时间字段是 UTC，你本机打时间戳用的是中国标准时间，两者相差 8 小时。如果采集脚本不做时区转换，本机时间戳就比 NMEA 时间快 8 小时，后续跟其他数据源对齐时会出现系统性偏移。解决方法是采集脚本里用time.time()拿 Unix 时间戳，它本身是绝对的，不涉及时区，只是你打印成可读格式时选了本地时区。更稳妥的做法是日志里只存 Unix 时间戳，分析时再手动转成目标时区；如果一定要存可读时间，显式调用datetime.now(timezone.utc)而不是datetime.now()。注意 NMEA 字段里有时区不涉及，因为它给的 UTC 时间，但闰秒会造成最多 18 秒的偏差，这个属于正常现象，不是日志错了。

5.3 现象：解析出的坐标每隔几分钟跳一次，幅度几百米

坐标跳动在单点定位模式下很常见，尤其在城市峡谷或树荫下。原因包括可见卫星数量和几何分布变化、多路径效应导致伪距偏大，以及定位解算在固定解和浮点解之间切换。具体到日志层面，你会发现每次跳变前quality字段可能短暂变成0，或者参与解算的卫星数突然下降。解决方法是分析时不要把连续时间段内所有点都当有效点，先按quality过滤，再按 HDOP 设置阈值，比如只保留 HDOP 小于 2.0 的点。如果跳变点是你关注的核心数据，需要引入额外的平滑滤波，那就超出"简单分析"的范围了，一般我会先检查天线周围环境再考虑算法滤波。天线位置固定但旁边有金属护栏时，反射信号会稳定地让坐标偏在某个方向，这种偏差靠过滤去不掉，只能挪天线。

5.4 现象：采集到中途数据流彻底中断，重新插拔模块后才能恢复

这是长时间采集中最磨人的问题。原因大概率是 USB 转 TTL 链路被系统挂起或者驱动缓冲溢出，尤其当采集脚本处理不过来或者 USB 总线繁忙时。日志上的表现是最后一条 NMEA 之后突然没有数据，但进程还活着、文件还在增长（只是没有新行）。解决方式分两层：硬件上避免把 GPS 模块和高速设备挂在同一 USB HUB 上，优先直连主机 USB 口；软件上给采集脚本加一个超时看门狗，比如连续 30 秒没读到完整行就记录一条告警，便于事后定位中断时刻。更硬核的做法是给模块加硬件流控或切换到二进制协议降低数据量，但对 NMEA 文本日志来说，先保证链路简单、直连，能解决大部分问题。如果是野外长周期采集，考虑用带掉电自动重启功能的采集板，比在脚本层面硬扛更靠谱。

5.5 现象：经纬度解析出来数值对，但画在地图上点位全在海上

这个坑出在度分格式换算上。3112.4567里的 31 是度，12.4567 是分，正确结果是 31 度 + 12.4567/60 度，约 31.2076 度。有人图省事直接float("3112.4567") / 60，得到 51.87 度，偏差足以让点跑到千里之外。还有人在做南北纬判断时把正值和负值搞反，或者忽略S和W需要取负，造成点落在完全对称的镜像位置上。排查方法很简单：拿一条定位质量好、已知位置的日志，解析后画图对比，如果明显异常，先看换算函数，再看方向标志处理。我习惯把换算结果和模块厂商工具输出的十进制坐标做对比，这个参照物比任何调试话术都可靠。

6. 前十分钟体检：用 HDOP 与可见星数验证这次捕获值不值得用

捕获和解析都跑通后，拿到一批新日志，先别急着做深度分析，花十分钟做一次质量体检，能避免后面所有统计结论建立在一份坏数据上。体检的核心指标是两个：GSA 句子里的 HDOP 和 GSV 句子里的 C/N0 分布。HDOP 小于 2 说明定位几何良好，2 到 5 属于一般，大于 5 基本只能当参考轨迹；C/N0 大于 35 的卫星才是有效解算卫星，小于 20 的通常是被遮挡的弱信号。我常用一个极简脚本批量统计这段日志里的指标分布：

from collections import Counter hdop_list = [] cno_counter = Counter() with open('simcity_20250101_a1_gps.log', 'r', encoding='utf-8') as f: for raw_line in f: line = raw_line.split('] ', 1)[-1].strip() if line.startswith('$GNGSA') or line.startswith('$GPGSA'): parts = line.split('*')[0].split(',') # PDOP, HDOP, VDOP 在第13到15个字段 try: hdop = float(parts[14]) hdop_list.append(hdop) except (IndexError, ValueError): pass elif line.startswith('$GNGSV') or line.startswith('$GPGSV'): for sv, snr in parse_gsv(line): cno_counter[snr] += 1 if hdop_list: print(f"HDOP 中位数: {sorted(hdop_list)[len(hdop_list)//2]:.1f}") print(f"HDOP 大于5的占比: {sum(1 for x in hdop_list if x > 5) / len(hdop_list):.1%}") valid_cno = sum(c for c, n in cno_counter.items() if c >= 35) print(f"C/N0>=35 的卫星观测量占比: {valid_cno / sum(cno_counter.values()):.1%}")

这个脚本的核心思路是用两个计数器覆盖整段日志的时间跨度，最终得到的比值比单看某一秒的数据更有说服力。如果 HDOP 中位数大于 3 或者高信噪比卫星占比低于一半，说明这次捕获的定位质量堪忧，不值得做精细分析，建议直接回去挪天线、改采集时间。反过来，如果指标漂亮，后续的轨迹分析、速度统计、定位精度评估才有意义。我自己最早做 GPS 捕获的时候，以为日志里有经纬度就是成功的，后来连续几天的实验结论都被场地里一棵树带着跑，直到把 C/N0 和 HDOP 纳入体检标准，才真正学会在动手分析前先信任数据。那一次的教训让我养成了习惯：任何 GPS 原始数据采集任务，落盘之后先跑十分钟体检脚本，合格才继续往下走。希望这篇笔记里的链路选型、采集脚本和避坑经验，能帮你少走这段弯路。

本文还有配套的精品资源，点击获取