1. 为什么我要自己搭一个RTK基准站去年做一台厘米级定位的自主导航小车时我算了一笔账买一台商用RTK基准站便宜的也要大几千好一点的上万。而我的需求其实很简单——在自家楼顶或者院子里架一个固定的基准站通过局域网或者NTRIP把差分数据推给移动端覆盖半径两三公里就够了。这个需求用一块ESP32加一个UM980模块成本能压到千元以内。RTK的核心逻辑其实不复杂。普通GPS定位误差在米级是因为卫星信号穿过电离层、对流层时会产生延迟卫星钟差、轨道误差也会叠加进来。RTK的做法是在一个已知精确坐标的位置放一台接收机基准站它把自己算出来的位置和已知坐标做差得到这个区域的综合误差修正量然后通过数据链路实时发给移动站。移动站用这个修正量去校正自己的观测值就能把定位精度拉到厘米级。这里面的关键点有三个基准站要能稳定接收卫星信号并输出原始观测数据数据链路要足够可靠且延迟可控移动端要能正确解析差分数据。ESP32负责的是第二件事——把UM980输出的差分数据打包通过WiFi或者以太网推送到NTRIP服务器或者直接广播给移动站。听起来简单但实际搭起来从硬件选型到网络配置坑是一个接一个。这篇内容适合两类人一是想低成本入门RTK定位的开发者二是有ESP32开发经验但没接触过GNSS领域的朋友。我会把整个搭建过程拆开重点讲清楚每个环节为什么这么做以及我踩过的那些坑。2. 硬件选型UM980加ESP32的组合逻辑2.1 为什么选UM980而不是更便宜的模块市面上能输出RTK差分数据的GNSS模块不少从几十块的单频模块到上千块的多频模块都有。我选UM980的原因很直接它支持全星座全频点包括GPS的L1/L2/L5、北斗的B1I/B2I/B3I、GLONASS的L1/L2、Galileo的E1/E5b等。频点越多能用的卫星越多固定解的速度和稳定性就越好。更便宜的方案比如某些单频模块只支持L1频段在开阔环境下也能用但一旦有遮挡或者电离层活跃固定解就很容易掉。UM980的价格在几百块左右比单频模块贵一些但比商用整机便宜太多性价比很合适。UM980的另一个好处是它原生支持输出RTCM差分数据。你不需要自己从原始观测值去编码RTCM模块内部直接就能输出标准的RTCM 3.x格式数据。这对ESP32来说太重要了因为ESP32的计算能力有限让它去做RTCM编码不现实。2.2 ESP32的选型不是随便一块都行ESP32系列有很多型号ESP32、ESP32-S3、ESP32-C3等等。我一开始用的是手头的一块ESP32 DevKit V1结果发现串口数量不够用。UM980需要一路串口接收数据如果还要留一路串口做调试输出再加上以太网模块的SPI接口引脚就非常紧张了。后来换成了ESP32-S3它的优势在于第一串口数量多有3个UART第二PSRAM可选如果要做数据缓冲很有用第三USB OTG支持可以直接通过USB虚拟串口调试省掉一个硬件串口。如果你手头只有普通ESP32也够用但建议选引脚引出比较全的版本比如ESP32-WROOM-32E。还有一个细节ESP32的WiFi和蓝牙可以同时用但在RTK基准站场景下我建议只开WiFi。蓝牙虽然方便配置但会占用射频资源可能影响WiFi的稳定性。配置阶段可以用蓝牙正式运行时就关掉。2.3 网络方案WiFi还是以太网这是很多人纠结的地方。WiFi方便不需要额外布线但稳定性受环境影响大。以太网稳定延迟低但需要额外模块比如LAN8720。我的建议是如果你只是做实验或者临时用WiFi就够了。但如果是长期固定运行的基准站强烈建议用以太网。原因很简单——RTK差分数据对延迟和丢包很敏感。WiFi在2.4GHz频段周围路由器、蓝牙设备、微波炉都在这个频段干扰不可避免。一旦丢包移动端的固定解就可能掉。用LAN8720的话接线是个坑。ESP32和LAN8720之间通过RMII接口通信需要连接TXD0、TXD1、TX_EN、RXD0、RXD1、CRS_DV、REF_CLK等信号线还要注意时钟方向。我见过太多人接错线导致PHY初始化失败。具体的接线方式我在后面会详细说。2.4 天线和馈线容易被忽视的关键天线的重要性怎么强调都不过分。GNSS天线分有源和无源两种RTK基准站必须用有源天线因为要补偿馈线损耗。天线的安装位置要尽量开阔远离金属物体和电磁干扰源。馈线也不能随便用。普通RG58馈线在1.5GHz频段的衰减大约是每米0.5dB如果馈线太长信号衰减会很严重。建议馈线长度控制在5米以内超过的话要考虑加一级LNA低噪声放大器。天线的供电一般由接收机模块提供UM980支持天线馈电但要注意电压和电流是否匹配。3. UM980与ESP32的串口通信配置3.1 串口参数与数据格式UM980默认的串口波特率是115200但RTCM数据量比较大建议提高到460800甚至921600。我实测下来460800在大多数场景下够用921600更稳但有些USB转串口芯片可能不支持。数据格式是8N1没有流控。UM980的串口输出可以通过命令配置默认会输出NMEA语句和原始观测数据。如果你只需要RTCM差分数据可以关掉NMEA输出减少数据量。配置UM980需要用它的专有命令通过串口发送。比如设置串口波特率的命令大概是这样的格式$CFGSERIAL,1,460800,8,0,1*XX这里的XX是校验和需要根据前面的内容计算。UM980的命令集比较丰富建议先用手册把常用命令整理出来做成一个配置脚本。3.2 ESP32端的串口接收代码ESP32用Arduino框架的话串口接收很简单。但要注意一点UM980输出的数据是连续的如果ESP32处理不过来串口缓冲区会溢出。所以接收和转发要分开用一个环形缓冲区做中转。#include HardwareSerial.h HardwareSerial um980Serial(1); RingBufferuint8_t, 4096 rtcmBuffer; void setup() { um980Serial.begin(460800, SERIAL_8N1, 16, 17); } void loop() { while (um980Serial.available()) { uint8_t byte um980Serial.read(); rtcmBuffer.push(byte); } // 转发逻辑在另一个任务中处理 }这里用到了ESP32的双核特性一个核心负责串口接收另一个核心负责网络转发。如果用Arduino框架可以用FreeRTOS的xTaskCreatePinnedToCore来创建任务。3.3 数据完整性校验RTCM数据是二进制格式每帧有固定的头部和CRC校验。在转发之前最好做一次帧完整性检查避免把不完整的数据推给移动端。RTCM 3.x的帧头是0xD3后面跟着保留位和长度信息。你可以根据长度字段来判断一帧是否接收完整。我一开始没做这个检查结果移动端经常收到半截数据导致解析失败。后来加了一个简单的状态机来同步帧头问题就解决了。4. 网络配置从WiFi到NTRIP的完整链路4.1 WiFi连接与稳定性优化ESP32连WiFi的代码很简单但稳定性优化有几个要点。第一关闭省电模式用WiFi.setSleep(false)否则WiFi会在空闲时进入休眠导致延迟增加。第二设置静态IP避免DHCP租约到期时重新协商。第三如果信号弱可以适当降低WiFi带宽比如用WiFi.setBandwidth(WIFI_IF_STA, WIFI_BW_HT20)20MHz带宽比40MHz更抗干扰。还有一点ESP32的WiFi和蓝牙共用射频如果同时开启WiFi吞吐量会下降。在基准站场景下建议配置完成后就关闭蓝牙。4.2 NTRIP客户端与服务器NTRIP是RTK差分数据传输的标准协议分客户端和服务器两种角色。基准站通常作为NTRIP服务器或者通过NTRIP客户端把数据推送到一个公共的CORS服务器。如果你只是自己用可以让ESP32直接做NTRIP服务器移动端作为客户端来连接。NTRIP的通信流程是客户端先发送一个HTTP GET请求带上挂载点名称和认证信息服务器返回200 OK后就开始持续推送RTCM数据。ESP32上实现NTRIP服务器需要处理HTTP请求解析和后续的数据流推送。WiFiServer ntripServer(2101); void handleNtripClient(WiFiClient client) { // 读取HTTP请求头 String request client.readStringUntil(\n); // 解析挂载点和认证 // 返回200 OK client.println(HTTP/1.1 200 OK); client.println(Content-Type: gnss/data); client.println(Connection: close); client.println(); // 持续推送RTCM数据 while (client.connected()) { if (rtcmBuffer.available()) { uint8_t buf[512]; size_t len rtcmBuffer.pop(buf, sizeof(buf)); client.write(buf, len); } } }4.3 差分龄期的计算与影响差分龄期是指移动端收到的最新差分数据的时间戳与当前时间之差。这个值越大说明差分数据越旧定位精度就越差。一般来说差分龄期在5秒以内固定解比较稳定超过10秒可能就会掉到浮点解。差分龄期的计算需要基准站和移动端的时间同步。基准站可以在RTCM数据中插入时间戳或者移动端根据数据到达时间估算。ESP32上可以用NTP对时保证时间戳的准确性。我在实际测试中发现WiFi链路的差分龄期波动比较大有时候会跳到3-4秒。用以太网的话基本能稳定在1秒以内。这也是我推荐以太网的原因之一。5. 以太网模块LAN8720的接线与避坑5.1 RMII接口的引脚映射LAN8720和ESP32之间通过RMII接口通信需要连接以下信号ESP32引脚LAN8720引脚说明GPIO0nRST复位低有效GPIO19TXD0发送数据0GPIO21TX_EN发送使能GPIO22TXD1发送数据1GPIO25RXD0接收数据0GPIO26RXD1接收数据1GPIO27CRS_DV载波检测GPIO17REF_CLK参考时钟GPIO23MDC管理时钟GPIO18MDIO管理数据这里最容易出错的是REF_CLK的方向。LAN8720可以输出50MHz时钟给ESP32也可以由ESP32提供时钟。如果用LAN8720输出时钟需要把REF_CLK接到ESP32的GPIO0同时配置ESP32的时钟源为外部输入。如果用ESP32输出时钟需要把GPIO17配置为时钟输出。我建议用LAN8720输出时钟的方式因为ESP32的时钟输出精度不如LAN8720的晶振。但这样GPIO0就被占用了而GPIO0是ESP32的启动模式引脚上电时不能拉低。所以LAN8720的nRST不能接GPIO0要换一个引脚。5.2 常见问题一PHY初始化失败PHY初始化失败是最常见的问题表现是esp_eth_driver_install返回错误或者PHY ID读出来是0xFFFF。原因通常有三个一是REF_CLK没有正确连接二是MDIO/MDC通信有问题三是电源不稳定。排查方法先用示波器测REF_CLK是否有50MHz时钟输出。如果没有检查LAN8720的晶振是否起振。如果有时钟但PHY ID读不到检查MDIO和MDC的上拉电阻LAN8720需要在这两根线上各接一个4.7kΩ的上拉电阻到3.3V。5.3 常见问题二网络连接不稳定网络能连上但经常丢包原因可能是RMII时序不满足。ESP32的RMII接口对时序要求比较严格PCB走线要尽量等长尤其是TXD0/TXD1和RXD0/RXD1这四根线。如果走线长度差异太大数据采样就会出错。另一个原因是电源噪声。LAN8720的模拟电源和数字电源要分开滤波建议用磁珠隔离并在每个电源引脚附近放0.1μF的去耦电容。5.4 常见问题三发热严重LAN8720发热是正常的但如果烫手就不正常了。通常是因为内部LDO在耗散功率。LAN8720有两种供电方式用内部LDO从3.3V降到1.2V或者直接用外部1.2V供电。用内部LDO的话芯片会明显发热。如果条件允许建议用外部1.2V供电能显著降低发热。6. 实测中的那些坑与解决思路6.1 串口数据丢包我一开始用115200波特率发现RTCM数据经常丢包。后来提高到460800丢包率明显下降。但即使这样如果ESP32同时处理WiFi和串口还是会有偶发丢包。解决办法是用双核任务串口接收和网络转发分别跑在不同的核心上中间用环形缓冲区解耦。6.2 WiFi断连重连ESP32的WiFi在信号弱的时候会断连重连后IP地址可能变化。如果移动端是直接连ESP32的NTRIP服务器IP变化就会导致连接失败。解决办法是设置静态IP并且在WiFi断开时自动重连重连后重新启动NTRIP服务器。6.3 差分数据格式不匹配不同品牌的移动端对RTCM版本的支持不一样。UM980默认输出RTCM 3.2有些老设备只支持3.0。如果移动端解析不了可以尝试降低RTCM版本或者只输出特定的消息类型。UM980支持配置输出哪些RTCM消息比如1005、1074、1084、1094、1124等。6.4 天线馈电问题UM980的天线馈电电压可以通过命令配置默认是3.3V。但有些有源天线需要5V供电。如果天线不工作先检查馈电电压是否匹配。另外天线接口的阻抗是50Ω馈线也要用50Ω的否则会有反射损耗。7. 长期运行的稳定性建议基准站如果要长期运行有几个地方需要特别注意。第一散热。ESP32和UM980都会发热尤其是夏天户外建议加一个小风扇或者散热片。第二电源。用质量好的电源适配器电压波动会导致模块工作异常。第三看门狗。ESP32内置看门狗但建议再加一个外部看门狗防止程序跑飞。还有一点定期检查差分数据的质量。可以在ESP32上做一个简单的统计记录每秒转发的RTCM字节数和丢包数通过串口或者网络输出。这样一旦出现问题能快速定位。我在实际使用中发现ESP32的WiFi在连续运行几天后偶尔会出现吞吐量下降的情况。重启后恢复正常。如果对稳定性要求极高建议用以太网并且加一个定时重启机制比如每天凌晨重启一次。最后分享一个小技巧UM980的配置命令可以通过串口发送但如果你经常需要重新配置可以写一个配置脚本把常用命令做成一个数组上电时自动发送。这样即使模块被复位也能快速恢复到工作状态。