企业官网建设流程全解析

如果你在调试飞控、机器人或者导航板卡时打开串口，看到的不是每秒一次的$GNRMC、$GNGGA，而是满屏的$GNTXT，那大概率可以判断：手里的 u-blox 模块正处在“想说但说不出来”的尴尬状态。这个现象在 NEO-M8N、NEO-M9N、F9P 等模块上非常典型，我最早是在给无人机飞控排查日志时遇到的，串口工具疯狂输出$GxTXT，定位数据却一条都没有，第一反应是模块坏了，后来才发现问题其实出在一堆“看似正常”的细节上。

这篇文章就围绕“ublox 无法定位、一直输出 $GxTXT”这个现象，从协议层面的解释、硬件排查、u-center 实操，到配置恢复和避坑经验，完整走一遍。适合正在用 u-blox 做定位、导航、测量相关项目，以及被串口日志刷屏刷到怀疑人生的朋友参考。

1. 先搞懂：一直输出 $GxTXT 到底在表达什么

1.1 $GxTXT 不是“报错”，是 NMEA 协议里的文本消息通道

$GxTXT是 NMEA 4.10 协议里定义的文本传输语句，全称是 Transmitted Text。Gx里的x是通配符，根据当前启用的星座不同，实际输出可能是GP（GPS）、GL（GLONASS）、GA（Galileo）、GB（北斗），多星座模式下最常见的是GN。

这个语句的作用很简单：接收机想告诉外部处理器一些“非定位信息”，比如启动状态、天线状态、干扰检测结果、配置警告等。它的帧结构长这样：

$GNTXT,01,01,02,u-blox GNSS receiver started*5D

字段依次是：总语句数、当前语句序号、文本类型、文本内容、校验和。文本内容是一个可读字符串，u-blox 模块会用它在 NMEA 协议模式下上报一些内部提示——正常启动时会发一条类似u-blox GNSS receiver started的文本；如果天线短路、开路了，也会用 TXT 消息把异常状态透传出来。

所以“一直输出 $GxTXT”本身并不代表模块损坏，它更像是一个“提示灯”：模块还活着，正在尝试跟你对话，只是它认为当前没有可用的定位结果可以输出。理解这一点，后面排查的方向就不会跑偏。

1.2 为什么会“只有 TXT、没有定位语句”

正常工作的 u-blox 模块，在 NMEA 模式下每秒或每设定周期会输出一组定位语句，最常见的是$GxGGA（定位信息）、$GxRMC（推荐最小定位信息）、$GxGSA（精度因子与卫星编号）、$GxGSV（可见卫星）等。只要其中$GxGGA和$GxRMC里的定位状态字段不是 0，就说明定位有效。

而“一直输出 $GxTXT”的情况，本质上是：文本消息在持续产生，但定位相关语句没有输出，或者输出了但状态一直是“未定位”。常见的有四种表现：

• 模块还没完成定位，卫星信号不足或天线有问题，此时它有文本要报，但没有有效定位数据可以输出；
• 模块已经定位，但输出语句被配置关闭了，比如上一次调试时有人把GGA、RMC的发送开关关了，只留了 TXT；
• 模块配置被“污染”，比如误开了某些只在 UBX 协议下可用的功能，导致 NMEA 输出异常；
• 模块进入了异常启动模式，比如固件损坏、上电时序不对，导致一直上报启动失败类文本。

这四种情况在日志层面看起来都一样，但排查方法完全不同。所以第一步不是急着改配置，而是先把“模块当前到底处于什么状态”搞清楚。

1.3 常见根因地图

我把实际项目中遇到过的问题归成四类，先给你一个整体框架，后面逐条展开：

遇到“一直输出 $GxTXT”，我的建议永远是：先查天线，再查配置，最后才怀疑模块本身。因为天线和配置的问题占到了绝大多数，而模块本身损坏的情况很少。

2. 动手前必读：硬件连线与串口诊断基础

2.1 模块类型与引脚回顾

u-blox 的定位模块里，NEO-M8N、NEO-M9N、NEO-F9P 是大家用得最多的三款。它们虽然功能有差异，但硬件接口逻辑非常相似：VCC、GND、TX1、RX1、天线座、V_ANT（天线馈电）和保留引脚。

连接时最容易犯的错有两个。

第一，电平问题。u-blox 模块的串口是 3.3V TTL 电平，不能直接接电脑的 RS232 串口，也不能接 5V 单片机的 TX 而没有任何电平转换。我见过不止一个朋友把模块 TX 直接接到 Arduino 的 5V RX 上，结果模块工作异常或者 USB 转串口工具烧掉。正确做法是使用 3.3V 电平的 USB 转 TTL 工具，或者确保单片机/开发板 IO 电平兼容。

第二，供电问题。NEO 系列模块正常工作电流大约在 20~60mA 之间，但如果接了有源天线，天线耗电可能额外增加 10~30mA。用劣质 USB 转 TTL 工具直接供电时，电压跌落会比较明显，模块会反复重启，日志表现就是“启动一次、报一段 TXT、重启、再报一次”。这种问题非常隐蔽，排查时最好用万用表实测一下 VCC 引脚电压，模块运行期间要稳定维持在 3.0V 以上，推荐 3.3V。

2.2 天线：有源无源、馈电和开路短路

天线问题是 u-blox 无法定位的头号原因，尤其是带陶瓷 patch 的贴片天线和棒状有源天线。

有源天线内部带一个 LNA 放大器，需要外部给它供电。u-blox 模块的 V_ANT 引脚就是干这个的，默认配置下模块会开启天线检测功能，实时监测天线端口的电压和电流状态。当天线短路或者开路时，监测值会异常，模块会把状态通过$GxTXT和 UBX 协议里的UBX-MON-HW消息上报出来。

我遇到过最典型的情况：用了一根 SMA 接口的棒状天线，但转接线内部芯线断了，模块开机后一直报ANTARCTICA（这是开玩笑，别当真），实际报的是类似Antenna short或者Antenna open的文本提示。这种问题用万用表一测就能确认：正常天线的 SMA 中心针对外壳电阻，有源天线通常是一个二极管压降值（几百到一千多欧姆），无源天线则接近 0 欧姆或者直接短路。

如果模块上接了无源天线，也就是那种没有放大器的陶瓷天线，需要确保模块的天线馈电配置正确，且天线朝向天空、远离金属遮挡。无源天线的信号增益低，室内基本收不到星，这一点别硬扛，把模块拿到窗边或者室外测试是最快的。

2.3 连接串口并抓取原始数据

排查工具上，我强烈建议直接使用 u-blox 官方免费软件 u-center，而不是普通的串口助手。原因后面详细说，但至少你在最开始连接时，就用 u-center 打开对应串口，能省掉很多弯路。

连接步骤：

1. 确认设备管理器里 USB 转 TTL 工具的 COM 口号；
2. 打开 u-center，点击右上角连接图标（或者菜单 Receiver -> Port），选择 COM 口号和波特率；
3. u-blox 模块默认波特率通常是 9600，但很多商家发货前会把模块配置成 38400、115200 甚至更高，所以如果 9600 下看不到数据，就逐个试试常见波特率；
4. 如果采用 USB 直连模块（比如某些开发板集成 USB 接口），则不需要 USB 转 TTL，直接选择对应 COM 口即可。

连接成功后会看到 u-center 顶部数据接收计数在跳动。此时无论收到的是$GxTXT还是$GxRMC，都不要急着下结论，先切到 UBX 协议视图，查看模块真实状态——这是定位问题的分水岭。

3. 核心解决流程：u-center 与 UBX 协议实操

3.1 为什么推荐 u-center 而不是串口助手

普通串口助手只能显示 ASCII 字符，处理$GxTXT这种文本绰绰有余，但它看不到 u-blox 模块内部的大量状态信息，尤其是 UBX 二进制协议消息。u-blox 模块底层默认同时支持 NMEA 和 UBX 两种协议，NMEA 只是给外部用的“翻译结果”，UBX 才是模块的“母语”，包含了更详细的硬件状态、卫星状态、配置信息和错误提示。

当模块“一直输出 $GxTXT”时，TXT 只是表象。真正的诊断信息要通过 UBX 消息读取，比如：

• UBX-MON-HW：硬件监视，包括天线状态、电压、噪声水平；
• UBX-MON-VER：固件版本和协议版本；
• UBX-MON-GNSS：当前启用的星座和接收通道数；
• UBX-INF-NOTICE：非 NMEA 模式下的文本通知，内容比$GxTXT更详细；
• UBX-NAV-STATUS、UBX-NAV-PVT：定位状态和具体定位数据。

这些消息在串口助手里没法解析，但 u-center 里一目了然。所以我的建议是：凡是 u-blox 模块出现定位异常，一律用 u-center 做第一轮诊断，效率能翻好几倍。

3.2 用 UBX 模式确认天线、电源和启动状态

打开 u-center 并连接好模块后，按以下步骤检查：

第一步，在菜单栏选择 View -> Messages View，展开左侧消息树。如果没有看到 UBX 相关消息，说明当前模块配置的协议输出没有打开 UBX，但没关系，u-center 可以通过右下角的 console 窗口直接发送 UBX 命令，不需要依赖模块主动输出。

第二步，点击 UBX -> MON -> HW，观察里面的关键字段：

• A_STATUS：天线状态。常见值是INIT（初始化）、DONTKNOW（未知）、OK（正常）、SHORT（短路）、OPEN（开路）。如果这里不是 OK，那问题基本就锁定了——天线链路有故障。
• A_POWER：天线馈电开关状态。
• VCC、V_ANT：当前电压值，单位是毫伏。V_ANT 应该在有源天线接入时保持在一个稳定值，如果波动大，说明馈电不稳。

第三步，查看 UBX -> MON -> VER，确认固件版本和协议版本。有些老模块或者山寨模块存在协议差异，比如部分 M8N 固件对 NMEA 4.10 的 TXT 支持不完整，也会导致异常输出。确认固件版本正常，能排除一大半“模块本身有问题”的疑虑。

第四步，如果 TXT 里出现了类似干扰检测、防欺骗之类的词汇，需要在 UBX -> CFG -> ITFM 里检查干扰检测配置。这里有个大坑：干扰检测功能只在 UBX 协议下可以正常配置，如果你之前是用普通串口助手通过 NMEA 命令去改配置，很可能没改对地方。

3.3 恢复出厂与冷启动的正确姿势

如果天线状态正常、固件版本正常，但仍然没有定位输出，下一步就是恢复出厂设置并冷启动。这一步能解决绝大多数配置污染类问题。

在 u-center 里有两个操作路径。

路径一：菜单操作。点击 Tools -> Receiver Configuration，在弹出的窗口里选择恢复默认配置，然后再执行冷启动命令。

路径二：直接发送 UBX 命令。在 u-center 的 Message View 左侧找到 UBX -> CFG -> CFG，也可以直接在控制台输入命令。恢复出厂设置的 UBX 消息是CFG-CFG，核心字段是clearMask，要清除 BBR（备份 RAM）、Flash、EEPROM 等存储区时，把对应 mask 位拉高。最省事的方式是点击 u-center 工具栏里的“恢复默认配置”按钮。

冷启动命令用的是CFG-RST，导航复位和启动模式组合起来：

• 冷启动（Cold Start）：navBbrMask=0xFFFF，startMode=0x00，模块会丢弃所有星历、时间、位置信息，从头开始搜星；
• 温启动（Warm Start）：清空星历但保留时间和位置，启动速度更快；
• 热启动（Hot Start）：保留全部有效数据，适合信号中断后恢复。

实际排查中，我习惯直接冷启动。冷启动后如果天线上方有开阔天空，模块通常会在 30 秒到几分钟内完成定位。如果几分钟后UBX-NAV-PVT里的fixType还是 3 以下的数值（0=无定位，1=推算定位，2=2D 定位，3=3D 定位），那就要继续排查天线位置和信号环境。

执行完冷启动后，还有一个关键动作：保存配置。很多朋友在 u-center 里调好了，拔电重启后又回到老样子，就是因为没保存。保存配置的操作用CFG-CFG的saveMask，把当前配置写入 BBR 或者 Flash。在 u-center 里，菜单 Receiver -> Edit -> Save Configuration 也可以完成同样的事。

3.4 重新配置定位消息输出

恢复出厂后，模块默认会输出一组 NMEA 消息，正常情况下应该能看到$GxGGA、$GxGSA、$GxRMC、$GxGSV等。如果你发现恢复出厂后依然没有这些数据，就要手动配置消息输出。

配置消息输出的入口在 UBX -> CFG -> MSG 或 PRT。以 NEO-M9N 为例，需要检查以下配置项：

• 串口协议：在 CFG-PRT 里确认端口 1 的协议输入输出都包含 NMEA 和 UBX；
• 消息开关：在 CFG-MSG 里把GxGGA、GxRMC、GxGSA、GxGSV的发送频率设为 1（即每 1 个导航周期输出一次），同时确认TXT的输出频率，如果不希望它刷屏，可以把 TXT 频率降到 0 或者不配置输出；
• GNSS 星座：在 CFG-GNSS 里确认 GPS 和 GLONASS 或北斗的启用状态。默认配置通常已经启用多星座，但如果模块之前被配置成只启用某一个星座且该星座当前不可见，也会导致长时间无法定位；
• 更新率：在 CFG-RATE 里设置测量周期和导航周期，常用配置是 1Hz、5Hz、10Hz。更新率越高，CPU 负载和功耗越大，对于低速运动场景 5Hz 足够，没必要盲目拉高。

这些配置项修改后，同样需要保存配置，否则上电重启后会丢失。

4. 经典场景与问题排查实录

4.1 从日志看问题：几种典型输出对比

实际调试中，不同问题对应的$GxTXT日志特征是不一样的。我整理几个典型场景给你参考。

场景一：模块启动正常，但天线无信号。

串口输出类似：

$GNTXT,01,01,02,u-blox GNSS receiver started*5D $GNTXT,01,01,02,Antenna OK*XX $GNTXT,01,01,02,No satellites*XX

Antenna OK说明天线检测通过，No satellites说明模块当前没有收到任何卫星信号。这种大概率是环境问题——室内、窗口角落、天线被金属遮挡。解决办法是把模块移到开阔地，冷启动等几分钟。

场景二：天线开路或短路。

$GNTXT,01,01,02,u-blox GNSS receiver started*5D $GNTXT,01,01,02,Antenna open*XX [重复]

Antenna open或者Antenna short就是天线链路异常。用万用表确认天线本体和馈线，不要只看接头是否拧紧。我遇到过 SMA 转 IPEX 的转接线内芯断裂，外观完全看不出来。

场景三：配置被污染，模块反复启动但不出定位。

$GNTXT,01,01,02,Configuration error*XX $GNTXT,01,01,02,Please check config*XX

这种就需要进 u-center，恢复出厂设置，然后重新配置输出消息和保存配置。之前有个朋友开发无人机地面站，模块在某种配置组合下会反复报Configuration error，后来发现是误开启了 UBX 协议里的干扰检测功能，而这个功能在某些固件版本上并不稳定，恢复出厂后重新配置才解决。

4.2 高频故障对照表

我把这些年遇到的高频故障按“症状 -> 可能原因 -> 处置动作”整理成了表格，方便你现场快速对照：

4.3 踩坑提醒：搜索“无法定位”时别被误导

调试这个问题时，很多人会上网搜索“无法定位”，但大概率会搜出一堆无关结果，比如“无法定位软件包 ros-noetic-desktop-full”“无法定位程序输入点 qt5core.dll”“无法定位序数 1 于动态链接库 sqlunirl.dll”等等。这些其实是 ROS 安装、Windows 动态链接库加载、Qt 运行库缺失导致的系统级报错，和 u-blox 接收机完全不是一回事。

搜资料的时候要带上具体关键词，比如“ublox $GxTXT”“u-blox no fix NMEA”“u-center antenna open”，这样命中率会高很多。不要因为搜到“无法定位软件包”就以为要在系统里装什么包、装什么运行库，方向错了会浪费大量时间。

4.4 一个容易忽略的细节：TXT 输出可能被错误解读为“定位状态”

很多人在串口助手看到$GxTXT就认为模块没有在工作，其实模块可能正在正常搜星，只是还没达到定位条件。此时 TXT 只是告诉你启动和自检状态，不是定位失败的原因。

判断模块是否真正在工作，看两个信号：

• 有没有周期性的$GxGSV，如果有，说明模块已经收到卫星信号，正在解析；
• 打开 u-center 的卫星视图，看实际捕获了多少颗卫星，信噪比分布如何。

如果能看到 5 颗以上信噪比在 30dBHz 以上的卫星，那模块本身没问题，纯粹是定位精度还达不到输出标准，等一会儿就有结果了。如果连$GxGSV都没有，那才需要回到天线、供电、配置层面重查。

5. 几个实际项目里的操作心得

模块在飞控上无法定位这个问题，我前前后后排查过七八次，印象最深的一次是在室外空旷场地，飞控日志里全是$GNTXT，折腾了一下午，最后发现是供电线太长导致电压降到 2.8V，模块频繁重启。从那以后我所有的 u-blox 模块接线都遵循一个原则：电源线尽量短，且直接并联一个 100uF 左右的电容到 VCC 和 GND 之间，实测能滤掉不少启动瞬间的电压跌落。

另一个心得是：如果模块不是全新采购，拿到手第一件事先恢复出厂设置，不要用别人给你的现成配置。很多“一直输出 $GxTXT”的案例，根源都是模块在上一任手里被配置成了只有 UBX 输出、关闭了 NMEA、改过波特率、甚至打开了奇怪的测试模式。第一次上电之前，先用 u-center 恢复默认，再按自己的需求配置，能避开很多莫名其妙的坑。

最后，模块正常定位后，建议把配置保存到 Flash，然后重新上电测试一遍，确认冷启动后能直接产出$GxGGA和$GxRMC。这样才算真正完成了一次 u-blox 无法定位问题的排查闭环。整个过程看起来步骤不少，但按“硬件 -> 配置 -> 环境 -> 固件”这条线走下来，大部分问题半小时内都能定位到根因。