玩GPS模块这些年，最深的体会是：调通串口拿到数据只是开始，真正决定项目上限的，是你对协议本身的理解深度。前阵子帮朋友调一块无人机飞控的定位模块，默认配置下NMEA语句刷得飞快，但更新率提到5Hz以上后，串口带宽被冗余字符占掉大半，而且想改动态模型、开RTK，靠NMEA那套标准指令根本使不上劲。最后切到UBX协议重新配置，整个系统才算是活过来。这就是我写这篇东西的初衷——把NMEA 0183和UBX协议放在同一张工作台上对比着讲，讲清楚它们各自的通信机制、报文结构、解析要点和典型应用场景，顺便把我踩过的坑一并交代了。
无论你是刚接触GPS/北斗模块的嵌入式新手，还是要在无人机、车载终端、测量设备里集成高精度定位的老手，这篇指南都能帮你少走弯路。我会从两种协议的底层设计差异讲起，逐字段拆解报文格式，再给出可直接落地的串口解析代码和配置方法，最后用一整章专门讲那些文档里不会写的坑。
1. 两种协议的分工逻辑：为什么GPS模块要用两套“语言”输出
GPS模块（现在基本都是多模多频了，但叫法上还习惯说GPS）本质上是一个卫星接收机，它的核心任务有两部分：一是接收、解算卫星信号，得到位置、速度、时间；二是把这些结果通过串口、SPI或I2C等接口送给主控。这里的关键问题是：解算结果“长什么样”传给外部？这就要说到NMEA和UBX的定位差异了。
NMEA 0183是美国国家海洋电子协会制定的标准，一开始是为了航海电子设备互联用的。它定义的是“人可读的文本格式”——每条语句都是ASCII字符，以$开头，以\r\n结尾，字段之间用逗号分隔。这样的好处显而易见：任何设备、任何语言，只要会字符串处理就能解析；两个设备之间即使没有事先约定，也能通过串口调试工具直接看懂内容。坏处也同样明显：信息密度低，同样一个经纬度，文本方式比二进制方式多占用好几倍字节。打个比方，NMEA像是用自然语言聊天，信息都在句子里，但夹杂了大量标点、助词；UBX像是用填好的表单沟通，字段位置固定，机器处理效率极高。
UBX是u-blox公司定义的二进制协议，只在u-blox系列GNSS接收机（NEO-M8N、NEO-M8P、F9P这些经典型号）上使用。它把数据打包成紧凑的二进制帧，一个字节代表枚举值、四个字节代表float、八个字节代表double，解析时直接按偏移量取数，不需要做字符串转换，也没有逗号和单位字符的浪费。更重要的是，UBX不只是“输出数据”，它几乎可以配置接收机的所有行为：调整更新率、切换动态模型、设置端口参数、启用RTK、读写内部配置Flash，这些在NMEA下要么不支持、要么指令极其有限。
我见过不少新手拿到GPS模块，默认配置下串口输出的全是$GPGGA、$GPRMC、$GPGSV这些句子，觉得“能跑就行”。等到项目要求10Hz刷新率、要求厘米级RTK定位、要求接收机在无人机高动态场景下切换空中的动态模型时，才意识到NMEA层面的配置能力严重不足，必须深入到UBX的配置类消息里去。
所以我对两种协议的定位归纳是这样的：
| 维度 | NMEA 0183 | UBX |
|---|---|---|
| 格式 | ASCII文本行 | 二进制帧 |
| 可读性 | 人类可读，调试方便 | 需工具或代码解析 |
| 信息密度 | 低，单位/逗号占大量字节 | 高，载荷紧凑 |
| 配置能力 | 极弱，仅个别标准指令 | 全功能寄存器级配置 |
| 适用场景 | 通用设备互联、快速验证 | 高性能定位、量产设备、RTK |
| 厂商支持 | 几乎所有GPS/北斗模块 | 仅u-blox |
理解了这套分工，后续所有解析和配置代码的设计依据就都有了。你会清楚：调试阶段用NMEA看图，正式工程里优先用UBX抽数据、做配置。这两条线并不冲突，很多模块可以同时输出两种协议，只是要看你串口带宽和解析程序怎么处理。
2. NMEA 0183逐字段拆解：从原始字符串到可用的经纬度高程
NMEA语句虽然种类多，但对大多数应用来说，真正用得上的就是那么几条：$GPGGA、$GPRMC、$GPVTG、$GPGSV。其中GGA包含了位置、质量、卫星数和海拔，是解析优先级最高的一条。我先把GGA逐字段拆开讲，你就明白为什么“看起来简单”的文本行里处处是陷阱。
典型的GGA语句长这样：
$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47按逗号分割，字段含义如下：
| 字段 | 示例值 | 含义 |
|---|---|---|
| 0 | $GPGGA | 语句标识 |
| 1 | 123519 | UTC时间，时分秒（12:35:19） |
| 2 | 4807.038 | 纬度，度分格式 |
| 3 | N | 北纬/南纬 |
| 4 | 01131.000 | 经度，度分格式 |
| 5 | E | 东经/西经 |
| 6 | 1 | 定位质量（0=无效，1=单点，2=差分，4=RTK固定，5=RTK浮点） |
| 7 | 08 | 跟踪到的卫星数 |
| 8 | 0.9 | 水平精度因子HDOP |
| 9 | 545.4 | 海拔高度（椭球面起算，单位米） |
| 10 | M | 高度单位 |
| 11 | 46.9 | 大地水准面差距 |
| 12 | M | 单位 |
| 13 | （空） | 差分站ID等 |
这里最容易被坑的就是第2和第4字段的“度分格式”。4807.038不是十进制度数，而是“48度07.038分”。如果直接atof之后当小数用，误差会大得离谱。正确的转换方法是：
def nmea_dm_to_deg(dm_str): if not dm_str: return None dm = float(dm_str) degrees = int(dm / 100) # 取度 minutes = dm - degrees * 100 # 取分 return degrees + minutes / 60.0比如4807.038，度数是48，分是07.038，转换成十进制度就是48 + 7.038/60 = 48.1173。南纬和西经在计算时还要加上负号。这一步错，后面的所有距离、航向计算全错，而且往往是“看起来差一点点”，排查起来特别隐蔽。
再补充几个我在项目中总结的细节：
- 定位质量字段比
$GPRMC的A/V状态位更可靠。很多教程教你判断RMC里的A（有效）和V（无效），但实测中发现，刚上电后的短暂时间内，RMC可能因为HDOP、卫星数不稳定而跳变。GGA字段6的数值则是接收机内部定位模式的状态映射，区分度更高。判断条件建议用fix_quality >= 1，RTK场景下要专门判断== 4或== 5。 - 海拔单位不统一。GGA第9字段是“海拔高度”，但这个高度是基于WGS84椭球面的，不是海拔高度。如果要和气压计、地形图数据对比，还得结合第11字段的大地水准面差距做修正。真实的平均海平面高度约等于
椭球高 - 大地水准面差距。飞控里经常要做这个转换，漏掉的话误差可能有几十米。 - UTC时间是公历制，不带时区。中国地区应用一般要+8小时转成北京时间，还要注意跨天、跨月、跨年的边界问题。
$GPRMC里的地面速度单位是节（knot），不是公里/小时。转km/h要乘1.852，转m/s要乘0.5144。$GPVTG里的速度单位同样如此。- GSV语句是分多行发送的。每颗卫星的信噪比、仰角、方位角分散在若干条
$GPGSV里，如果你要做“搜星质量可视化”这类调试界面，必须把所有GSV句子收集齐再拼接，否则数据不完整。
初学者最容易出现的错误是：把GGA当成唯一数据源，却不理解里面字段的实时变化规律。举个实际案例，某次车载项目里，设备在隧道出口处恢复定位，GGA第一帧的质量字段为0，但位置值还是隧道内的旧坐标，上位机直接画图，轨迹出现一条几十米的“飞出”直线。后来我加了一个逻辑：只有当质量字段从0变为非0之后，才重置坐标缓冲区。这样就不会把无效位置点当作真实轨迹记录下来。
在解析层面，文本协议虽然简单，但也要注意串口缓冲的边界问题。串口接收是字节流，一帧NMEA可能被拆成两次到达，也可能两帧粘在一起。写解析器时不能直接假设readline()能拿到完整行，必须自己维护一个按行缓冲的状态机，遇到\n再交给解析函数。这部分在第四章里我会给出完整的状态机思路。
3. UBX二进制帧的构造逻辑、校验和算法与常用消息配置
如果说NMEA是“看得懂的对话”，那UBX就是“机器间的握手”。UBX帧结构非常规整，解析和构造的代码可以模板化。先看帧结构：
0xB5 0x62 [Class] [ID] [Length_L] [Length_H] [Payload...] [CK_A] [CK_B]两个固定同步字节0xB5 0x62是所有UBX帧的开头，相当于帧头标记。然后是消息类Class和消息ID，各占一个字节。紧跟其后的是载荷长度，低字节在前、高字节在后。载荷部分根据Class和ID的不同而变化。最后两个字节是校验和CK_A和CK_B。
校验和算法是整个UBX协议里最简单也最容易写错的地方。它的计算范围是从Class字节开始，一直到Payload的最后一个字节（不包含帧头两个同步字节），具体算法是：
uint8_t ck_a = 0, ck_b = 0; for (int i = 0; i < len; i++) { ck_a = ck_a + data[i]; ck_b = ck_b + ck_a; }注意两个细节：第一，ck_a和ck_b都必须是8位无符号整数，累加时自动溢出截断。如果用C语言的char（默认带符号），累加结果变成负数，校验和就永远对不上。这种问题在调试时非常让人崩溃，因为错误只会在特定字节组合下出现。第二，校验范围是Class + ID + Length + Payload，有人会误把同步字节也算进去，算出来当然错。我在STM32平台上验证过无数次，这个算法和u-blox官方文档一致，放心用。
UBX消息按Class分类，每一类下面有若干消息ID。我做项目时最常用的是这几条：
| 消息 | Class / ID | 用途 |
|---|---|---|
| UBX-NAV-PVT | 0x01 / 0x07 | 一次拿到经纬度、速度、时间、定位状态 |
| UBX-CFG-PRT | 0x06 / 0x00 | 配置串口波特率、协议输出 |
| UBX-CFG-RATE | 0x06 / 0x08 | 设置测量/导航更新率 |
| UBX-CFG-CFG | 0x06 / 0x09 | 保存配置到Flash |
| UBX-CFG-NAV5 | 0x06 / 0x24 | 设置动态模型、定位模式 |
拿NAV-PVT举例，它是一条信息量非常集中的消息。载荷长度是84字节（0x54），里面包含了iTOW（GPS毫秒时间）、年/月/日/时/分/秒、fixType、纬度（1e-7度，int32）、经度（1e-7度，int32）、高度、地速、航向角、位置精度等几十个字段。相比NMEA的字符串解析，直接用结构体强转或按偏移量取数快得多，而且不会出现字符串转float的精度损失。
以下是我在C工程里常用的NAV-PVT读取代码片段：
typedef struct { uint32_t iTOW; uint16_t year; uint8_t month; uint8_t day; uint8_t hour; uint8_t min; uint8_t sec; uint8_t valid; uint32_t tAcc; int32_t nano; uint8_t fixType; // ... 中间字段按协议文档补充 int32_t lat; // 1e-7 度 int32_t lon; int32_t height; int32_t hMSL; // ... } ubx_nav_pvt_t;解析时，从帧的Payload起始地址按偏移量直接读取即可。误差在于务必确认接收机是否是little-endian输出，以及你在MCU上用的编译器的字节序是否一致。ARM Cortex-M系列默认小端，现代主流平台基本都能对上。如果大小端搞反，读出来的经纬度数字完全不合理，而且很难一眼发现。
UBX配置类消息的使用体验，和NMEA那种“发一条指令然后看运气”完全不同。以修改串口波特率为例，你需要构造一条UBX-CFG-PRT消息，指定端口ID、目标波特率以及要启用的协议栈，然后发送给模块。模块收到后立即生效，并且你要同步把主控的串口波特率改成同一数值，否则后续通信全部乱码。
配置更新率也非常直观。把UBX-CFG-RATE的measRate设成100（表示每100ms测量一次），navRate设成1，timeRef设成0（UTC时间参考），模块就以10Hz输出定位数据。这一点比NMEA下“只能等固定1Hz输出”强太多。需要说明的是，10Hz甚至更高更新率下，每秒会生成大量定位数据，你要确认自己的主控处理和存储带宽跟得上，否则串口FIFO溢出丢帧会让数据出现“时间空洞”。
还有一条特别容易忽略的配置是UBX-CFG-CFG。当你调好了波特率、更新率、动态模型，如果不执行“保存配置”动作，模块重启后又会恢复出厂默认。保存配置的正确姿势是向0x06 0x09发送特定格式的掩码。很多工程师“明明改了配置，重启又丢了”，多半是没做这一步。不过也要注意，频繁擦写Flash会影响寿命，量产设备建议在出厂测试阶段统一配置好再发货，不要在运行时反复保存。
4. 串口读取的工程化处理：帧同步、缓冲管理和NMEA/UBX混流应对
真实的串口环境远没有文档里干净。数据会丢字节、会粘包、会拆包，甚至会在你切换协议后，串口里还残留着旧协议的半截数据。所以一个健壮的GPS数据读取模块，核心是帧同步和缓冲管理，而不是简单调用readline()。
我在STM32和Linux环境里都实现过这套逻辑，思路是一致的：维护一个环形缓冲区，串口中断或读取线程源源不断把字节塞进去；解析线程不断从缓冲区里取字节，跑一个有限状态机。以UBX帧为例，状态机大概是这样：
状态IDLE: 等待0xB5 收到0xB5，进入状态SYNC1 状态SYNC1: 等待0x62，收到则进入CLASS；否则回到IDLE 状态CLASS: 存Class，进入ID 状态ID: 存ID，进入LENGTH_L 状态LENGTH_L: 存低字节，进入LENGTH_H 状态LENGTH_H: 存高字节，得到payload_len，进入PAYLOAD 状态PAYLOAD: 逐个存payload，存满后进入CK_A 状态CK_A: 读入期望校验值，和实时计算的校验和比对，不相等则丢弃整帧回到IDLE 状态CK_B: 同样比对，成功后整帧完整，交给解析回调这个状态机的核心优势是单字节串行处理，不支持随机访问，天然抗粘包和拆包。就算一次中断里来了半帧，下一次中断继续喂字节，状态机照样能恢复。但如果发生丢字节导致状态错乱，你会一直被卡在某个中间状态，永远等不到想要的帧。解决办法是加一个超时计时器：当状态机处于非IDLE超过一定时间（比如100ms）还没有进入完成状态，强制重置回IDLE，重新同步。这个方法在处理UBX和NMEA混流时尤为重要。
NMEA的解析状态机相对简单，核心是按\n分行。我见过有人用strstr(buf, "\n")配合memmove来截行，但效率不高，而且容易在缓冲区边界出问题。更稳妥的办法是维护一个行缓冲区，逐个判断字节是否等于\n，遇到就回调处理，然后清空行缓冲区。解析时需要注意的是：每一行以\r\n结束，\r也要去掉，否则某些转换函数的解析会被干扰。
真正考验工程能力的是NMEA和UBX同时输出时的混流问题。某次项目里，我为了调试方便，同时开启了NMEA和UBX输出，结果主控解析器看到$G开头就按NMEA处理，看到0xB5就按UBX处理，逻辑上各自成立。但问题在于，串口到达的时序是乱的，上一帧UBX的一半可能被NMEA行挤占，下一半还在缓冲区里。解决方案很直接：解析器不能假设“BUFF里只有一种协议的数据”，必须每次从环形缓冲取一个字节，同时喂给NMEA状态机和UBX状态机，由各自的帧头来判断是否属于自己的帧。伪代码如下：
void process_byte(uint8_t byte) { nmea_fsm(byte); // 如果是 '$' 开头的行，内部自行处理 ubx_fsm(byte); // 如果是 0xB5 开头，内部自行处理 }两条状态机互不干扰，因为它们不会同时命中对方的帧头。实测下来，混流解析的错误率比分开解析要低得多。不过我还是建议正式产品里只开一种协议，把串口带宽全部留给目标协议。混流只是为了调试阶段的方便，长期跑会占用大量带宽，而且增加代码复杂度。
波特率匹配是另一个极容易出问题的点。模块出厂默认通常是9600，但你在代码里可能写的是115200，两边不一致时串口收到的全是乱码。这类问题有个特征：屏幕上能看到不断的十六进制字节，但不论怎么调解析逻辑都对不上。排查时先别急着改代码，用串口调试工具连上模块，确认它当前实际输出的波特率（很多模块可以通过拉低某个引脚或者发特定命令恢复默认波特率）。配置完模块后，记得把主控串口的具体波特率改到一致，两边要同步生效，不要一个改了另一个还蒙在鼓里。
更新率提高后，串口FIFO溢出也是常见问题。10Hz的NAV-PVT一帧大约90字节，每秒900字节，在115200波特率下带宽充足，但在9600波特率下（约960字节/秒）已经接近上限，还要跑NMEA的话就直接爆了。这种情况下要么提高波特率，要么降低输出频率，要么关掉不用的语句。u-blox模块支持通过CFG-PRT的协议输出掩码来关闭某类语句，只留你关心的数据。
调试过程中，逻辑分析仪和十六进制抓包工具是排查串口问题的利器。遇到“代码明明正确但数据不对”的情况，用逻辑分析仪抓一下TX/RX波形，对照波特率计算每个字节的起始位和数据位，能瞬间定位到是主控发错、模块没回，还是线路电平问题。GPS模块的电平一般是3.3V TTL，和5V的MCU引脚直连有风险，需要做电平转换或用开发板上自带的电平匹配电路。这个细节虽然算不上协议层面的内容，但实际项目中烧坏模块的案例大多是这里出了问题。
5. 实测中的高频坑位：从坐标格式到保存配置再到冷热启动
这一章专门用来“立碑”——把我这些年调GPS模块踩过的坑集中陈列一遍，每一条都是真金白银换来的教训，希望能帮你在遇到类似问题时少走几个来回。
坑一：经纬度格式转换错误。这个问题我在第二章已经详细讲过，为什么还要单独拿出来？因为它的出错率实在太高。很多人拿到NMEA数据后直接float(lat_str)，结果在地图上显示的坐标偏了几公里甚至几十公里，还以为是模块坏了。记住一个口诀：NMEA里的经纬度是“度分”格式，不是“度”格式，必须先拆分再转换。有不少开源库（比如Python的pynmea2、嵌入式端的minmea）都内置了这个转换逻辑，写代码前先查查有没有现成的库可用。
坑二：UBX校验和使用有符号类型。这就是我前面说的，char类型的累加溢出会导致负值，校验和永远不匹配。C语言工程里注意用uint8_t显式声明。这种bug特别隐蔽，因为它不是每次必现，而是取决于数据内容。如果某天你发现自己构造的UBX配置指令完全没生效，先检查校验和变量类型。
坑三：改完配置没保存，断电重启又回到解放前。u-blox模块的配置分RAM和Flash两级。发配置指令只改RAM，断电即失；必须通过CFG-CFG把配置写入Flash才能永久保存。但要注意，配置项改动频繁的话，Flash会磨损。量产设备我建议是在生产测试环节统一下发配置、统一保存，后续运行时只改RAM配置，不要频繁写Flash。
坑四：把“有时间输出”当成“已定位成功”。GPS模块上电后即使没有定位成功，也会持续输出GGA、RMC等语句，只是里面的经纬度是0或者上一次有效定位的残留值，质量字段是0。做产品逻辑时，必须显式判断质量字段或fixType，在未定位状态下直接把无效数据显示给用户，体验很差，也可能引发生态位判断错误。
坑五：冷启动搜星慢，被当成模块故障。刚刚出厂的模块，第一次上电时星历和历书都是空的，冷启动可能要花几十秒甚至数分钟才能完成首次定位。如果你在室内测试，那基本是永远定位不到的，这属于物理限制，不是模块坏了。判断模块是否“活着”，最直接的办法是看PPS（秒脉冲）引脚有没有周期性脉冲输出，有脉冲就说明接收机工作正常。
坑六：天线质量问题被严重低估。GPS信号非常微弱，有源天线的供电电压、增益、线缆屏蔽都对定位效果有直接影响。某次项目里客户反馈“定位漂移严重”，最后排查发现是天线馈线屏蔽层在弯曲处断裂，导致接收到的信号大量反射和多径干扰。建议在有条件的场合用带地平面的陶瓷天线，并保持天线区域尽量空旷，远离大电流导线和金属遮蔽物。
坑七：时间转换的边界条件。UBX-NAV-PVT里直接给出UTC的年月日时分秒，不容易出问题。但如果用NMEA的$GPZDA或者转换时间戳时涉及闰秒，就要小心了。GPS时（GPS Week Number/TOW）和UTC的转换涉及闰秒调整，没有经验的开发者直接拿整秒计算，秒级误差平时看不出来，某些时间敏感的应用里就会冒出来。一般情况下，直接用模块输出的UTC字段，不要自己去转换GPST到UTC。
坑八：动态模型配置错位。u-blox接收机内置多种动态模型：便携式、车载、机载、海上、静态等。不同模型对应的滤波器和加速度容限不同。把车载模型用到无人机上，位置输出会有明显滞后；把机载模型用到步行场景，噪声会变大。UBX-CFG-NAV5的dynModel字段要按实际使用场景配置，不要图省事一直用默认的便携模型。
| 症状 | 可能原因 | 排查手段 |
|---|---|---|
| 串口全是乱码 | 波特率不匹配 / TTL电平不兼容 | 串口工具确认实际波特率；测电平是否3.3V |
有数据但都是$开头，解析无内容 | 没开NMEA输出 / 输出被波特率带宽限制 | 检查CFG-PRT协议掩码；提高波特率 |
| 能收到GGA但位置为0 | 尚未定位成功 | 检查质量字段、PPS波形、天线状态 |
| 配置指令发出无效 | 校验和错误 / RAM未保存Flash | 用u-center复现指令；检查校验和代码 |
| 数据随机丢帧 | 波特率过高或主控处理不及时 | 降低更新率；加大串口FIFO；换DMA方式 |
排查这些坑，有一套标准打法。先把模块接到u-blox官方的u-center软件上，用它的“消息视图”图形化看数据，如果u-center下一切正常，说明模块本身没毛病，问题多半出在你的代码或接线；如果u-center下也异常，那就用逻辑分析仪从波形层查起。这套“u-center正常 → 查主控代码；u-center异常 → 查物理层”的二分法，能帮你最快收敛问题范围。
6. 协议选型建议：什么场景继续用NMEA，什么场景坚决切UBX
聊完协议细节和坑位，最后落到一个现实问题：我的项目到底该用哪种协议？这个问题没有标准答案，但有清晰的取舍逻辑。
优先用NMEA的场景：
- 快速原型验证，比如拿到模块第一步先看它能不能定位，串口线插上电脑直接用串口助手读，NMEA天然适合这种场景，不需要写任何解析代码就能肉眼确认数据在跳。
- 兼容多品牌模块。如果你的设备可能换用不同厂家的GPS/北斗模块（比如国产品牌的ATGM336H、中科微电子方案），它们对UBX协议不一定完全兼容，但NMEA 0183基本都支持，用NMEA做统一接口可以减少适配工作量。
- 需要把定位数据直接送给人读的场合，比如调试日志、上位机显示、简单的数据记录工具，NMEA的文本格式不用转换，打出来就能看。
优先用UBX的场景：
- 高更新率应用，比如无人机飞控、竞速车、机器人控制器需要10Hz甚至20Hz的位置刷新，NMEA的ASCII语句在串口带宽上比较吃力，UBX的紧凑帧能轻松扛住。
- 需要配置接收机行为的场景，比如切换动态模型、调整输出频率、启用RTK或SBAS、修改端口协议。这些在NMEA层面几乎没有标准指令，只能在UBX里完成。
- 定位精度和稳定性要求高的场景，UBX-NAV-PVT的原始字段精度更高，不需要经过字符串转换，也没有NMEA里某些字段可选导致的“某些语句没输出”的兼容性问题。
- 带宽受限的通信链路，比如用数传电台传输定位数据时，UBX帧比NMEA少一半以上字节，能有效节省无线信道资源。
实际项目中，很多设备最终选择的是“混合模式”：启动阶段用NMEA做调试输出，方便产线测试人员看到定位状态；正常运行后切到UBX，把高精度数据交给主控。u-blox模块的串口可以同时激活两种协议，只要通过CFG-PRT的协议掩码分别使能即可。切换协议时要注意接收机端和主控端的同步，切之前先让主控停止解析当前协议，等切换完成再启动新解析器，否则切换间隙的数据会让状态机懵掉。
还有一个容易被忽略的选型参考点：RTK和差分定位场景，UBX几乎是必选项。以NEO-M8P和F9P为例，RTK的配置、基准站数据注入、定位状态反馈，都需要通过UBX协议完成。如果你打算做厘米级定位，那从一开始就要按照“已经确认了RTK工作模式”来规划通信设计，不要等到硬件定型了才发现NMEA支持不了那么多RTCM数据流的对接。
我自己平时的习惯是：调试期用u-center + NMEA背景输出，进入代码工程阶段后立刻切UBX-NAV-PVT作为主数据源，只在遇到疑难问题时临时开NMEA做对照。这样既保证开发效率，又保证了最终代码的性能。你可以按这个思路定一套自己的协议策略，多测试几轮之后，自然会找到最适合你项目的平衡点。
