1. 项目整体设计与方案取舍做 GPS 导航这类小系统最容易被低估的不是写代码而是把一堆“看起来都能用”的器件凑到一起之后的稳定性问题。我前后做过几个基于 STM32 微控制器的 GPS 导航系统设计与实现版本从最初只能把经纬度打印到串口到后来能在地图上画出轨迹、计算里程、记录到 SD 卡中间踩过的坑基本都和选型、供电、天线、数据过滤有关反而是 NMEA 解析本身没花多少时间。这篇文章就按我实际做下来的一套方案展开把每个环节为什么这么选、参数怎么算、问题怎么查讲清楚适合刚上手嵌入式定位设备的同学也适合已经能把数据显示出来但定位老是飘、老是丢点的人。这套系统的核心目标很朴素MCU 通过串口接收 GNSS 模块输出的定位数据解析出经纬度、速度、航向、时间、卫星数、定位质量等字段做有效性过滤和坐标转换然后在本地屏幕上显示当前位置与行驶信息同时把轨迹写入存储介质必要时还能通过无线模块把位置回传。它解决的是一类很实际的诉求——在成本可控、功耗可控、体积可控的前提下让一个嵌入式设备“知道自己在哪里、以多快的速度往哪里走”。对初学者来说这是一个非常好的综合练习串口、定时器、中断、DMA、文件系统、显示驱动、浮点运算与定点运算的取舍全都能练到。1.1 先把需求拆成可执行的功能块很多人一上来就写代码写到一半发现需求没想清楚到底要不要显示地图要不要离线存储要不要做坐标系纠偏这些决定了主控资源、存储方案和软件复杂度的上限。我在动手前习惯先列一张功能清单把它分成“必须”“最好有”“以后再说”三档这个方法在资源有限的 MCU 项目里非常管用。必选部分是串口稳定接收 GNSS 数据、解析关键语句、判定定位是否有效、计算出可用于显示的本地坐标、屏幕刷新显示、按键切换页面。可选部分是轨迹记录到存储卡、里程与最高速度统计、航向指示、卫星信噪比柱状图。以后再说的是离线地图渲染、路径规划、语音播报这些对 RAM 和算力的要求会直接跨一个量级。为什么要把离线地图往后排原因很直接一张哪怕只覆盖一个城市的栅格地图分辨率稍高就是几十兆字节STM32 的片上 Flash 和 RAM 根本放不下必须外挂存储、做瓦片索引、做坐标变换和渲染缓冲工作量比前面所有模块加起来还大。把这部分砍掉整套系统在 64KB RAM 的芯片上就能跑得很舒服这是我在第一次尝试失败后得到的教训——当时把地图位图直接转成 C 数组编译进程序链接阶段就爆了。注意功能清单一定要和硬件资源一起过一遍尤其是 RAM。GNSS 的接收缓冲、NMEA 解析用的临时字符串、屏幕显存、文件系统缓存这几块加起来很吃内存64KB 的芯片在做 128×64 单色屏时比较宽裕换成 320×240 彩色屏就会很紧张。1.2 主控芯片怎么选F103 还是 F407主控这块我实际用过两类一类是 STM32F103 系列这类 Cortex-M3 内核、主频 72MHz、带 64KB Flash 和 20KB RAM 的经典型号另一类是 STM32F407 系列这类 Cortex-M4F 内核、主频 168MHz、带浮点单元和更大 RAM 的型号。选哪个取决于你的界面复杂度和是否需要做姿态融合。只做串口收数、NMEA 解析、字符屏或小尺寸单色屏显示、存储卡记录F103 完全够用成本也低。但有两个地方会明显吃力一是浮点运算M3 没有硬件 FPU所有的 float 运算都靠软件库模拟一次除法几百个时钟周期1Hz 的数据量还能忍一旦要做高频滤波或者大量三角函数就会拖慢主循环二是刷彩屏SPI 刷 320×240 的整屏数据时间开销相当可观。如果预算允许并且后面想接惯性传感器做融合、或者要上彩屏和更丰富的界面直接上带 FPU 的 M4 型号更省心浮点运算快一个数量级做三角函数、开方、滤波都不会成为瓶颈。我后来的版本统一换成了 M4 平台代码结构没变只是把软件浮点换成硬件浮点刷新率和滤波迭代次数立刻宽松了很多。还有一个折中方案主控仍用 F103但把所有浮点运算改成定点数运算。经纬度用 1e-7 度的整数表示速度用 0.01 km/h 的整数表示三角函数用查表加线性插值。这个做法我在一个功耗敏感的项目里用过效果不错代价是代码可读性下降调试时脑内要一直做单位换算。对比项M3 平台72MHz无 FPUM4F 平台168MHz带 FPUNMEA 解析完全够用注意别用 sscanf 解浮点轻松余量充足浮点滤波软件模拟需控制调用频率硬件浮点可提高迭代频率显示方案单色 OLED / 小尺寸字符屏彩色 SPI 屏也扛得住存储卡记录够用注意缓冲区大小从容成本与功耗更低略高1.3 GNSS 模块与天线精度、成本与体积的平衡模块选型主要看三件事支持的星座数量、冷启动首次定位时间、是否有备份电源引脚。市面上常见的低成本模块以单 GPS 或 GPS北斗双模为主默认串口波特率多为 9600输出标准 NMEA 语句3.3V TTL 电平接口简单到只需要 VCC、GND、TX、RX 四根线就能出数据。多模模块在城市环境里的可见卫星数更多定位稳定性会好一些但价格和功耗也略高。这里有个很多人忽略的点模块标称的定位精度通常是开阔地、水平面、静态条件下的统计值实际在楼宇之间、树下、车内误差可能从几米涨到几十米。这不是模块坏了是信号被反射和遮挡导致的多径效应。指望靠换更贵的模块解决城市峡谷问题并不现实正确做法是在软件上做数据过滤把质量差的点剔除掉。天线部分常见两类陶瓷贴片天线和有源天线。贴片天线体积小、成本低但增益有限通常要配合良好的地平面有源天线内部带低噪声放大需要模块或主板提供馈电灵敏度明显更好适合设备外壳内空间较大的场景。我用过的一个失败案例是把贴片天线贴在金属外壳内侧结果冷启动三分钟都定不下来换成外置有源天线后十几秒就锁星了。天线类型优点局限适用场景陶瓷贴片体积小、免馈电、成本低对地平面敏感遮挡下表现差小型手持设备、塑料外壳有源天线灵敏度高、锁星快需要馈电体积大车载、户外设备、金属外壳外置磁吸摆放灵活可远离干扰源走线长需注意屏蔽车载临时安装2. 硬件电路与电磁兼容细节硬件部分是这套系统最容易翻车的地方而且症状往往很迷惑代码明明没改换个板子就搜不到星数据偶尔乱码查半天发现是电源纹波。我在第一版硬件上吃了不少亏后来总结出一条经验——GNSS 模块对电源干净程度和射频环境的要求比它对代码的要求高得多。2.1 供电与电流峰值GPS 模块的隐藏脾气GNSS 模块的平均电流通常在二三十毫安这个量级但它在启动瞬间和周期性捕获阶段会有明显的电流波动如果供电走线细、去耦不足电压就会被拉低表现是模块反复重启或者输出数据中断。我的做法是给模块单独一路低压差线性稳压器输入输出各配 10 微法加 0.1 微法的组合走线尽量短而宽绝不和电机、蜂鸣器、无线发射模块共用一条细线。为什么强调用线性稳压器而不是开关电源原因在于开关电源的开关频率及其谐波可能落在 GNSS 接收频段附近形成宽带噪声直接抬高接收机的噪声底表现为信噪比下降、可见星数变少。如果系统里必须用开关电源比如电池供电需要升压那就把开关频率选得远离接收频段做好电感和输出滤波并且把电源部分物理上远离天线。还有一个容易忽略的细节模块的备份电源引脚。这个引脚接一颗小容量电池或超级电容用于在主电源断开后维持星历和实时时钟从而实现热启动。热启动首次定位时间通常在一秒量级冷启动则可能要三十秒以上。如果你的设备是“用完就关”的便携设备这颗备份电池带来的体验差异非常明显。我第一次做的时候把这脚悬空了结果每次开机都要在户外站半分钟等定位用户直觉上会认为设备坏了。注意备份电池的功耗非常低但要确认模块手册里对备份电压范围的要求直接接主电源会失去备份意义接错电压可能损坏模块。2.2 串口连线、电平与备份电池串口连接本身很简单模块的发送接 MCU 的接收模块的接收接 MCU 的发送两边共地。这里有两个高频错误一是忘了共地只连了信号线数据时有时无二是把发送接收接反了现象是完全没有数据。判断方法很朴素用逻辑分析仪或者示波器看模块的发送脚如果有规律的数据波形说明模块在工作问题是 MCU 侧的配置或连线。电平方面绝大多数模块输出 3.3V TTL与 3.3V 的 MCU 直接相连即可。如果你的主控是 5V 系统必须做电平转换不能靠串电阻硬扛长期工作在超限电压下引脚寿命会受影响。反过来如果 MCU 是 3.3V 而模块是 5V 输出同样需要转换否则可能打坏 MCU 的输入引脚。配置串口时的参数是固定套路波特率与模块默认值一致常见 9600也有出厂 38400 或 115200 的8 位数据位1 位停止位无校验。为什么不用校验位因为 NMEA 语句本身就带异或校验和链路层再加校验意义不大还会让部分模块的配置模式失灵。2.3 PCB 布局天线附近不能出现的几样东西射频这块我不算专家但踩过的坑足够写出几条硬规矩。天线要尽量靠近板边或者外壳开口处正上方和正下方不要有覆铜、电池、屏蔽罩晶振、开关电源电感、高速数字走线要远离天线区域至少保持十几毫米以上的距离如果天线是通过馈线连接的馈线要走阻抗受控的走线并在模块端做好匹配。地平面是贴片天线的“另一半”很多人只关注天线本身忘了给天线下方铺一块完整的地。地平面尺寸太小天线的谐振点会偏移增益下降地平面被走线割裂效果同样打折。我一般保证天线下方地平面连续并且和主地通过多个过孔连接避免形成细长的回流路径。还有一个特别隐蔽的问题屏幕排线和存储卡座。SPI 时钟频率高的时候排线就是一根天线辐射出去会干扰接收。我的处理是把屏幕排线尽量短、加地线伴行必要时在排线上套铁氧体磁环或者在软件上降低 SPI 时钟频率试试看定位是否变好——如果降频后搜星明显改善那就基本锁定是数字噪声干扰。3. 软件架构从串口字节流到定位数据软件部分我倾向于把整条链路切成四层字节接收层、语句切分层、字段解析层、业务应用层。这样切的好处是每一层单独可测出问题能快速定位是哪一层。比如屏幕上坐标不动可能是接收层没收到数据也可能是解析层字段错位还可能是应用层的过滤条件把所有点都判为无效分层之后调试效率会高很多。3.1 DMA 空闲中断的接收框架用轮询或者单字节中断接收都可以但在 9600 波特率下每秒大约 960 字节模块还可能同时输出多条语句单字节中断会让 CPU 频繁进出中断影响其他任务。更稳妥的方式是用 DMA 把串口数据搬到缓冲区再用串口空闲中断来判断“一帧数据收完了”。空闲中断的原理是串口在接收完一个字节后如果超过一个字符时间没有新数据到来硬件会置位空闲标志。利用这个特性可以把不定长的 NMEA 语句按帧切开避免在软件里逐字节判断换行符。下面是我常用的骨架代码基于 HAL 库的接收空闲 DMA 接口#define GNSS_BUF_SIZE 512 static uint8_t gnss_buf[GNSS_BUF_SIZE]; static volatile uint16_t gnss_len 0; static volatile uint8_t gnss_ready 0; void GNSS_Start(void) { HAL_UARTEx_ReceiveToIdle_DMA(huart2, gnss_buf, GNSS_BUF_SIZE); __HAL_DMA_DISABLE_IT(hdma_usart2_rx, DMA_IT_HT); } /* 回调里只做搬运标记不做解析 */ void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart-Instance USART2) { gnss_len Size; gnss_ready 1; HAL_UARTEx_ReceiveToIdle_DMA(huart2, gnss_buf, GNSS_BUF_SIZE); __HAL_DMA_DISABLE_IT(hdma_usart2_rx, DMA_IT_HT); } }这段代码的关键点在于“回调里不解析”。很多新手直接在中断回调里跑字符串处理一旦数据量大或者解析里带浮点运算就会挤占中断时间导致后续数据丢失。正确做法是把长度和标志置位主循环检测到标志后再处理处理完清标志。缓冲区建议给到 512 字节以上因为模块一次可能连续输出五六条语句总长度接近四百字节。提示关闭 DMA 的半传输中断是必要的否则一次接收会触发两次回调第二次拿到的是半截数据解析必然失败。这个坑我踩过一次现象是每隔一帧就解析失败一帧。3.2 NMEA 协议逐字段拆解与解析实现NMEA 语句的通用格式是以美元符号开头逗号分隔字段星号后面跟两位十六进制校验和最后是回车换行。校验和是美元符号与星号之间所有字符的异或值。解析时先验证校验和再按逗号切分这一步能把绝大多数噪声和半截数据挡在外面。真正需要的关键语句其实不多。定位信息主要来自推荐最小定位信息语句和定位质量语句前者给出时间、经纬度、速度、航向、日期后者给出定位质量因子、使用卫星数、水平精度因子、海拔。卫星信噪比语句只在做信号强度显示时才需要如果只是记录轨迹完全可以把它关掉以减少数据量。下面这条是典型的推荐最小定位信息语句结构$GNRMC,083559.00,A,2237.4621,N,11402.8891,E,0.004,,241120,,,A*6C字段含义依次是UTC 时间、状态A 有效 / V 无效、纬度度分格式、南北半球、经度、东西半球、地面速度节、航向度、UTC 日期、磁偏角、磁偏方向、模式指示。这里最容易出错的是经纬度的“度分”格式——2237.4621 表示 22 度 37.4621 分需要拆成整数度和小数分再换算/* 输入 ddmm.mmmm 形式的字符串输出十进制度 */ double nmea_to_deg(const char *s) { double raw atof(s); int deg (int)(raw / 100.0); double min raw - deg * 100.0; return deg min / 60.0; }为什么不用 sscanf 一口气把整条语句拆完因为 sscanf 处理浮点会引入较大的代码体积和较慢的执行速度在没有硬件浮点的平台上代价更明显。用指针手动扫描逗号位置再按字段类型分别转换速度更快也更可控。我一般的做法是先扫描一遍把所有逗号的偏移记到数组里然后按索引取字段这样代码可读性和效率都不错。还有一点值得提醒不同模块输出的语句前缀不一样单 GPS 模块是 GP 开头双模模块可能输出 GN、GB、BD 等多种前缀。解析时不要硬编码判断“GP”直接判断语句标识符部分逗号前的最后三个字符更稳妥或者干脆只按语句类型关键字匹配。3.3 数据有效性过滤把脏点挡在门外原始定位数据里混着大量不可直接使用的点。我见过的最夸张的一次设备静止放在窗台上轨迹图上却出现了一条横跨半个城市的直线原因就是某个时刻模块输出了一组跳变坐标。如果不做过滤这种点会污染里程统计和轨迹记录。过滤分几层。第一层看状态位状态为无效的直接丢弃这是最基本的。第二层看定位质量因子单点定位、差分定位、固定解的可信度差别很大如果项目要求较高可以把质量因子低于某个阈值的点剔除。第三层看水平精度因子这个值反映卫星几何分布的好坏数值越大定位越不可信我一般设一个门槛超过就标记为低质量。第四层做运动学一致性检查用相邻两点的时间和距离算隐含速度如果超过合理上限比如每小时二百公里就判定为跳点丢弃。过滤层级判据典型阈值作用状态位有效标志仅接受有效拦截无效解质量因子定位解类型单点及以上排除未定位精度因子水平精度因子小于 5.0排除几何差卫星数参与解算卫星数大于等于 4排除欠定解速度一致性隐含速度小于 200 km/h拦截跳变点速度一致性检查的具体算法是用两点的经纬度算球面距离除以时间差得到速度与阈值比较。这里不用太精确的公式用等距圆柱近似就够了误差在百分之一以内对过滤来说完全够用。真正需要注意的是时间戳一定要用 UTC 时间算差值不要用本地毫秒计数否则跨整秒的时候会出现负值。4. 坐标转换、里程计算与显示存储数据从模块出来是 WGS84 坐标直接显示给用户会有个问题在某些地图上叠加会有几百米的偏移。这不是模块的错是坐标系本身不同。如果只是自己记录轨迹、在自绘的网格上显示那用原始坐标完全没问题如果要叠加到常见的在线地图上就必须做转换。4.1 WGS84 到本地平面坐标的换算转换分两步走。第一步是球面坐标到平面坐标的投影常用的做法是以某个参考点为原点用等距圆柱近似或者墨卡托投影把经纬度差换算成米/* 以 ref 为原点的局部平面坐标单位米适用于几公里范围 */ void wgs84_to_local(double lat, double lon, double ref_lat, double ref_lon, double *x, double *y) { const double M_PER_DEG_LAT 111320.0; *y (lat - ref_lat) * M_PER_DEG_LAT; *x (lon - ref_lon) * M_PER_DEG_LAT * cos(ref_lat * M_PI / 180.0); }为什么用这个近似而不是完整的大地测量公式因为在小范围内几公里误差只有厘米到分米级而计算量小得多。参考点的选择也影响精度一般选第一次有效定位的点或者选设备常用区域的中心点。如果设备活动范围超过几十公里就要考虑用更严谨的投影否则横向误差会随距离增长。第二步是坐标系纠偏如果目标地图使用非 WGS84 的坐标体系需要套用公开的偏移算法。这部分我不建议自己从头推导用现成的公开算法实现即可注意算法里有迭代逼近的过程调用频率不要太高1Hz 完全没问题。我一般只在需要显示到地图上时才做转换内部存储和里程计算仍然用原始坐标这样逻辑更清晰也便于以后切换到其他地图。4.2 速度、航向与里程的平滑处理模块直接给出的速度和航向抖动比较明显尤其是低速状态下静止时航向可能随机跳变。直接显示会让人觉得设备“不靠谱”所以要做平滑。最简单的一阶低通滤波就够用/* alpha 越小越平滑代价是响应变慢实测 0.2~0.3 比较均衡 */ speed_filt speed_filt * (1.0f - alpha) speed_raw * alpha;航向的平滑要特殊处理因为它是个环形量359 度和 1 度实际只差 2 度直接做算术平均会算出 180 度。正确做法是先把角度转成单位向量对两个分量分别滤波再反算角度。这个细节我在第一版里没注意结果设备直行时航向显示在 0 度和 360 度之间乱跳。里程计算用相邻有效点的距离累加。要注意的是静止时模块输出的坐标会有米级抖动如果每个点都累加一晚上能“走”出好几公里。解决办法是设一个最小位移阈值比如位移小于三米就不累加同时速度低于某个值时不更新最大速度。这些细节看起来琐碎但直接决定最终数据是否可信。还有一个经验里程统计要区分“累计里程”和“本次行程”并且提供手动清零的入口。我最早做的版本只能累计测试时想让数据归零只能重启非常别扭。4.3 屏幕刷新与SD卡轨迹记录显示部分我用过单色 OLED 和彩色 SPI 屏两种。单色屏刷新快、代码简单、占用 RAM 少适合只显示数字和简单图标的场景彩色屏视觉效果好但整屏刷新耗时明显需要做局部刷新或者限制刷新区域。不管哪种刷新频率都不要跟着数据频率走1Hz 的定位数据配 5Hz 的界面刷新比较舒服太快了人眼也看不出差别还白占 CPU。界面布局我一般分三页主页显示经纬度、速度、航向、卫星数轨迹页显示一个以当前位置为中心的简易网格和最近若干点的连线状态页显示定位质量、精度因子、海拔、UTC 时间和设备运行时长。按键用两个就够一个翻页一个清零长按短按区分功能。存储卡记录这块如果用文件系统建议先打开文件后保持打开状态间隔写入不要每条数据都开关文件否则写入耗时和卡寿命都不划算。写入频率 1Hz 即可每条记录包含时间戳、经纬度、速度、航向、卫星数、质量因子用逗号分隔的文本格式方便事后用表格软件打开分析。缓冲区攒够一定条数再统一写入能显著降低卡的操作次数。注意拔卡前一定要先停止写入并关闭文件否则最后一段数据大概率丢失严重时文件系统会损坏。这个坑我在测试阶段踩过不止一次。5. 搜星慢、漂移、乱码排查实录调试阶段遇到的问题八成集中在“收不到数据”“数据乱码”“定位不准”这三类。我习惯按链路顺序排查先确认硬件有没有在工作再看数据有没有到 MCU再看解析对不对最后看应用逻辑有没有把它过滤掉。这个顺序能避免在错误的层面上瞎折腾。5.1 定位问题排查树搜不到星是最常见的问题。第一步确认天线把设备拿到室外空旷处天线面朝上等待时间给足冷启动至少留两分钟。如果在室内窗边测试很可能一颗星都搜不到这不是设备问题。第二步看数据里有没有卫星数信息如果能看到卫星但定位状态一直是无效说明信号弱或者几何分布差需要换位置再试。第三步看备份电池如果每次上电都是冷启动首次定位时间会很长接上备份电源后改善明显。定位漂移分两种情况。静止漂移是正常的单点定位在开阔地的水平误差几米很常见设备放在桌上坐标小幅跳动不必大惊小怪。运动中的漂移要看是不是跳点用前面说的速度一致性检查基本能过滤掉。还有一种漂移是坐标系问题轨迹整体偏移几百米但形状正确那就是没做坐标转换跟模块精度无关。现象可能原因排查动作完全没有数据接线反、未共地、波特率不符示波器看模块发送脚波形有数据但全是无效解天线被遮挡、室内测试移到室外空旷处重新上电冷启动极慢备份电源缺失、天线增益低检查备份脚电压换有源天线轨迹整体偏移未做坐标系转换核对目标地图坐标系偶发跳点多径、信号瞬时劣化加精度因子与速度一致性过滤数据间歇性乱码电源纹波、地线干扰、缓冲区溢出查电源纹波加大缓冲降 SPI 频率5.2 串口数据问题乱码是另一大类。先看波特率模块出厂默认值不一定和你配置的一致尤其是一些可配置模块可能被上一次的配置改过。用示波器量一下一个位的宽度反推波特率是最快的确认方式。再看缓冲区如果缓冲区小于一帧数据的长度长语句会被截断解析自然失败。还有一种隐蔽的乱码来自中断优先级。如果串口接收和屏幕刷新的优先级配置不当高优先级任务长时间占用 CPU串口硬件溢出标志置位数据就丢了。我的做法是把串口 DMA 接收设为较高优先级屏幕刷新放在主循环里做中间用状态机衔接避免长时间阻塞。数据解析错误也常被误认为乱码。比如字段索引算错一位纬度读到了经度或者半球标志没处理导致南纬变成北纬。这类问题的特点是数据“看起来合理但位置不对”调试时把原始语句和解析结果并排打印出来对照一眼就能看出来。5.3 问题速查表排查项检查方法期望结果不满足时的处理模块供电万用表测模块电源脚稳定在标称值附近换独立稳压加去耦串口波形示波器看发送脚有规律数据帧检查模块是否上电、天线是否接波特率量位宽反推与配置一致逐一试常见波特率校验和打印原始语句与计算结果两者一致检查缓冲区截断、帧边界定位状态打印状态字段有效移到室外等待冷启动精度因子打印该字段小于阈值换位置或提高过滤门槛坐标转换与已知点对比偏差在预期内检查转换算法与参考点6. 可继续扩展的方向这套系统跑通之后往下扩展的空间其实挺大而且每个方向都有明确的实用价值不是纯粹为了炫技。我在几个不同需求的版本里分别做过下面的尝试有的收益很大有的纯属折腾。6.1 秒脉冲授时与时间同步很多 GNSS 模块除了串口还会引出一路秒脉冲输出上升沿与世界时整秒对齐精度在几十纳秒量级。用它配合 MCU 的定时器捕获功能可以做一个相当准的本地时钟串口给出整秒对应的日期时间脉冲给出精确的秒边界两者结合就能把本地时间误差压到毫秒以内还能顺便校准 MCU 内部低速时钟的偏差。实现起来不难把脉冲引脚接到定时器的输入捕获通道捕获中断里记录计数值同时读取串口刚解析出的时间。要注意的是串口语句到达时间和脉冲之间有几毫秒到几十毫秒的延迟需要做补偿补偿量可以通过多次测量取平均得到。这个功能在需要给多设备打统一时间戳的场景里非常有用。6.2 低成本惯导融合GNSS 在隧道、地下车库、密集楼宇之间会失锁短则几秒长则几分钟。如果设备同时装了加速度计和陀螺仪失锁期间可以靠航位推算短时维持位置估计等信号恢复后再做校正。我做过一个简化版本只用陀螺仪积分航向、用上次有效速度积分位移失锁十秒内位置误差还能接受再长就飘得没法看了。真要做扎实得上互补滤波或者扩展卡尔曼滤波把 GNSS 位置速度作为观测量惯性数据作为预测这个工作量不小但效果提升明显。对于只想练手的同学建议先做最简单的航位推算把数据链路和状态切换逻辑跑通再考虑上滤波算法。6.3 低功耗与周期性唤醒电池供电的设备功耗是大问题。GNSS 模块连续工作时的电流对小型电池来说压力不小常见的优化是周期性开关定位成功后记录位置然后让模块进入待机或者直接断电MCU 进入低功耗模式定时器唤醒后再上电定位。因为有备份电源维持星历热启动通常一两秒就能重新定位整体平均功耗能降一个量级。这里的取舍在于定位的实时性。如果设备是放在背包里做轨迹记录每隔几十秒定位一次完全够用轨迹照样连贯如果是要做实时导航那就不能频繁断电。我在一个长期部署的记录设备上用了这个策略采样间隔设成三十秒一节小容量电池能撑好几天代价是轨迹在转弯处会显得比较生硬。我自己在这套系统上花时间最多的其实不是写代码而是反复拿着设备到不同环境里跑看它在树下、天桥下、楼宇之间到底表现如何然后回头调过滤阈值和天线位置。软件能把数据变好看但真正决定定位质量的还是天线摆在哪、电源干不干净、测试环境够不够真实。