做带定位功能的产品之前最标准的做法基本就是“MCU GPS芯片 4G模组”三件套拼在一起软件上还要同时处理两路串口、两套电源时序和定位数据转发。这几年中低速物联网市场里很多 Cat.1 模组直接把 GNSS 集成进去了比如我手上的 ML302 就是一侧提供 LTE Cat.1 通信另一侧直接带一路 GPS/北斗接收通道。这种整合给硬件省了不少事也让被 GPS 模块天线调试折磨过的人松了一口气。这篇文章不打算抄一遍芯片手册而是把我从零把这块模组的 GNSS 跑通的过程整理成一条可复用的链路硬件上天线和电源怎么预留AT 指令怎么把定位功能点亮串口吐出来的 NMEA 怎么解析和过滤以及调试中比较容易误导人的“假定位”现象和定位功耗的处理办法。准备做共享两轮车、宠物项圈、冷链物流箱、工业手持终端这类设备的朋友可以直接按这条链路走。1. 为什么把定位功能直接压在Cat.1模组里而不是外挂GPS芯片1.1 中低速定位产品的真实需求做定位类产品的人都知道绝大多数应用并不是要每秒传一条厘米级轨迹而是“隔一段时间上报一个经纬度”数据包很小频率不高电池还得撑得住。这种业务对下行带宽要求很低对模组成本和部署灵活性要求却很高Cat.1 正好卡在这个档位能跑存量 4G 网络速度也够用成本又比普通 Cat.4 模组低一截。对共享两轮车、资产追踪器、儿童防丢设备来说这是很典型的组合。如果在这个基础上再外挂一颗独立 GPS 模块就得重新走一遍射频调试流程GPS 模块的 LNA 供电要加滤波天线馈点要做 50 欧匹配模块和主控之间还要自己定一套交互协议。这颗 GPS 器件虽然单价不高但硬件上要留位置软件上要多写一层驱动产线上又多一个需要校准和测试的工位。算下来其实不省心。模组内置 GNSS 之后定位通道和通信通道在同一个固件体系里主控只需要通过 AT 指令去控制它很多底层细节模组厂商已经处理好了。从整机设计角度讲相当于把“两套系统”压缩成“两个引脚、两根天线、一套指令”整个硬件复杂度和调试工作量都会明显下降。1.2 内置GNSS的定位质量到底能不能信很多人觉得 GNSS 接收机集成在通信模组里定位效果一定比不过独立芯片。这个想法我看是过度担心了。GNSS 定位质量主要由三件事决定射频前端灵敏度、天线设计和底层定位算法封装在哪颗芯片上反而没那么关键。ML302 的 GNSS 支持 GPS/北斗等多系统室外开阔环境能稳定收到 9 到 12 颗星水平定位精度在 3 到 5 米是常见水平对共享两轮车、物流箱、宠物追踪这类场景完全够用。真正会影响体验的不是“内置”还是“外置”而是天线有没有放好、有没有被金属遮挡、电源纹波大不大。这些在第二章展开说。1.3 我最终选定的整体结构这次项目的整体架构是这样的ML302 负责 LTE 通信和 GNSS 定位外部接一根 LTE 主天线、一根 GNSS 天线SIM 卡正常插在模组卡座上另外用一颗低功耗 MCU 做主控。MCU 不直接处理射频只负责业务协议、电源调度和上报逻辑。这样做的好处是职责清楚需要定位时MCU 通过串口向 ML302 下发 AT 指令模组回传 NMEA 数据MCU 解析成业务字段再走网络上报。如果后续产品想再省一颗主控也可以直接用模组的内部处理能力去跑简单业务逻辑但量产稳定性上我倾向于让主控独立因为定位、通信、业务三者混在一个环境里出了 bug 不好定位。2. ML302 GNSS硬件设计和天线预留这几处不处理好后面全是白调2.1 最小系统怎么接才能保证后续能在线调试拿到模组先别急着写软件把最小系统搭正确是第一优先级。ML302 的关键引脚主要包括VBAT 主供电、GND、PWRKEY 开机引脚、复位引脚、主串口 TXD/RXD、LTE 天线引脚和 GNSS 天线引脚。电源电压要按规格书来通常标称 3.8V 左右供电回路靠近模组引脚的地方要放足够容量的滤波电容防止通信发射时电压跌落导致模组重启。PWRKEY 这个脚很值得留意。不同平台的极性不完全一样有的是拉高开机有的是拉低开机而且要求脉冲宽度也不同。我调试时就在这个地方耽误过半天反复按开机没反应。建议拿到板子先看模组规格书里 PWRKEY 的时序图确认是拉高还是拉低、维持多少毫秒再用示波器或者逻辑分析仪抓一下波形避免一上电就卡在开机阶段。串口方面主串口用来跑 AT 指令。调试时如果用 USB 转 TTL记得共地否则串口可能出现乱码。默认波特率一般为 115200具体看模组默认配置。接线完成之后串口工具发一个“AT”回车能收到 OK 就说明最小系统没问题了后面才有得谈。2.2 天线和净空GNSS归根到底是在“看天”GNSS 信号到地面的时候非常微弱比普通移动通信信号还要弱得多所以GNSS天线摆放的优先级在整机结构里相当高。我的经验是GNSS 天线必须尽量靠近设备边缘或外壳上部保证天线半球有良好的天空视野。如果把天线压在电池、金属支架或者大面积覆铜下面搜星能力会直线下降表现出来就是长时间定位失败或者明明在室外也只有一个很差的定位。常见的天线选择有两种。无源陶瓷贴片天线体积小、成本低适合外壳开孔位置理想、周围环境相对空旷的产品有源天线内部带了一级低噪声放大器LNA抗干扰能力更强适合车载、外壳内部有遮挡、天线被拉远到线缆末端的场景。ML302 的 GNSS 通路一般支持直接连接有源天线具体看模组引脚定义里有没有 GNSS_ANT_VCC 这类供电引脚。两条天线在 PCB 上的相对位置也要注意。LTE 天线在通信时发射功率不低如果离 GNSS 天线太近会直接影响 GNSS 接收灵敏度表现是“一上网就定位慢断网就定位快”。我在项目里把 LTE 天线放在板子右侧GNSS 天线放在左上角实测间距拉到 5 厘米以上后并发场景下的定位稳定性明显变好。如果是软板天线还要注意天线馈线尽量短别绕圈。2.3 有源天线供电和功耗这层关系很多人会漏掉有源天线必须供电才能工作但供电时机不是一直供电。有些板子设计成模组一上电就给 GNSS LNA 供电即便你根本没开定位功能这颗有源天线也在持续耗电。别小看这个电流有源天线里的 LNA 通常要吃掉十几毫安。对电池类产品来说待机功耗在这边漏掉是不应该的。我后来在硬件上加了一颗低功耗场效应管来控制 GNSS 天线的供电MCU 通过一个 GPIO 去控制它需要定位前再打开。这样既能让 GNSS 接收机在冷启动时有干净电源也能在报文间隙直接把天线供电断掉。软件上还要和模组的 GNSS 电源控制配合好不然会出现“天线还开着模组已经关了定位通道”的情况。3. AT指令把“GPS电源”点亮一次完整的搜星到出坐标流程3.1 先确认模组在线再谈定位做定位调试之前先把模组的基本状态确认一遍。串口工具里依次发几条基础指令检查射频功能是否正常、SIM 卡是否识别、网络是否注册成功。虽然 GNSS 定位本身不依赖运营商网络辅助定位功能除外但网络注册成功后后续如果要走 AGNSS 辅助星历、要上报数据都会顺畅很多。这一步经常被跳过导致后面排查时把问题搞混以为是 GNSS 天线不行实际是模组压根没正常注册网络整个系统处于半睡半醒状态。我的习惯是调试脚本第一步就查询模组状态确保一切正常之后再打开 GNSS。3.2 打开GNSS电源、设置模式、让NMEA数据吐出来ASR 这类 Cat.1 平台上GNSS 相关命令一般以 CGPS 开头。不同固件版本的具体子命令会有差异但整体流程是一致的先打开模组内部 GNSS 电源再设置工作模式然后决定数据是用指令主动读取还是模组主动往串口推。我在这颗 ML302 上实际跑通的流程大致是这样ATCGPSPWR1 OK ATCGPSMODE2 OK ATCGPSNMEA1 OK简单解释一下ATCGPSPWR1的作用是打开 GNSS 接收机电源这是整个定位功能的总开关。关掉它后面所有定位指令都不会有意义。ATCGPSMODE2用来设置定位模式。有些固件里 2 表示连续定位适合需要持续输出轨迹的产品有些固件则用 1 表示单次定位。这里没有统一标准务必对照你手上固件的 AT 命令手册。ATCGPSNMEA1是让模组把 NMEA 数据输出到串口。也有的平台上要单独开 RMC、GGA 的输出或者用专门的读数据命令主动拉取。命令的返回不一定是立即成功。GNSS 模块冷启动时需要自己初始化偶尔会遇到返回 ERROR再发一次往往就正常了。刚开始调试时别急着下车多发两次确认一下。3.3 冷启动的前90秒看起来像“没反应”其实在搜星第一次拿到模组GNSS 接收机里既没有星历也没有概略位置它得从广播信号中慢慢收集卫星信息这个过程叫冷启动。冷启动的典型表现是指令发出去了AT 层返回 OK但串口一直没有 NMEA 数据或者偶尔收到一句但状态不是有效定位。这个阶段最容易让人误判以为模组坏了或者天线没接。实际上只要射频通路没问题它就是在等卫星广播数据。我实测时习惯把终端光纤移到窗边固定一个不遮挡天线的姿势然后读秒等 60 到 90 秒。第一次出有效定位之后模组会把星历缓存下来以后断电重开就是热启动速度会快很多一般 5 到 15 秒就能恢复。串口上如果能看到类似下面这样的数据说明 GNSS 已经开始工作了$GNRMC,061200.00,A,3039.58332,N,10403.42560,E,0.50,45.60,180125,,,A*66这里的 A 就代表有效定位。第一次出现 A 状态说明模组已经从“搜星”进入“定位”阶段。4. 从$GNRMC到平台经纬度NMEA解析与数据上报链路4.1 NMEA不是“坐标格式”是串口报文格式很多刚接触定位的同学看到$GNRMC,061200.00,A,...这一串就直接懵了觉得像乱码。其实 NMEA 就是一套文本协议每个句子以$开头以\r\n结尾中间用逗号把不同字段隔开。它最早是航海电子设备之间交换数据的标准现在 GNSS 接收机也普遍用它来输出定位结果。理解它的正确姿势是“按逗号拆字段”而不是整句硬背。每句第一个字段表示类型比如 RMC 是推荐最小定位信息GGA 是定位质量信息GSV 是可见卫星信息。后面的字段根据类型各有各的含义按位置取就行。4.2 最常用的两个句子RMC和GGA实际业务里我用得最多的是$GNRMC和$GNGGA。RMC 包含了经纬度、速度、航向、日期是平台落库最常用的一条GGA 则多了定位质量、卫星数量、HDOP 和海拔用来判断“这个点能不能信”。拿这条数据来拆解$GNRMC,121500.00,A,3039.58332,N,10403.42560,E,0.50,45.60,180125,,,A*66字段顺序依次是UTC 时间 12:15:00、定位状态 A有效、纬度3039.58332N、经度10403.42560E、速度 0.50 节、航向 45.6 度、日期 2025年1月18日。注意纬度格式是“度分”格式30 度 39.58332 分并不是 30.395 度。经度同理104 度 03.42560 分。这点看错坐标会偏到离谱。再看 GGA 示例$GNGGA,121500.00,3039.58332,N,10403.42560,E,1,9,1.2,500.9,M,,,,这里的1表示定位质量1 是普通 GPS 定位9是正在用的卫星数1.2是水平精度因子 HDOP500.9是海拔。判断一个点是否可靠基本就看状态字段、卫星数和 HDOP。4.3 坐标转换代码按这个写基本不出错把3039.58332转成十进制度方法很简单小数点前两位是度后面是分分除以 60 加进度。注意南纬和西经要取负数。参考代码def nmea_to_decimal(coord, direction): coord float(coord) degrees int(coord / 100) minutes coord - degrees * 100 decimal degrees minutes / 60.0 if direction in (S, W): decimal -decimal return round(decimal, 6)解析过程中最容易踩的坑是空字段。NMEA 里会因为接收机未收敛而出现连续两个逗号比如,,对应字段是空字符串。直接把空字符串转 float 必然报错。正确做法是先把整句按照逗号split再判断每个关键字段是否为空为空就跳过宁可丢这一帧也不要上报一个错点。fields line.split(,) if fields[2] ! A: return None # 非有效定位我这里拿 RMC 举例实际解析中状态字段的判断要放最前面。如果状态不是 A经纬度即使有值也不能用否则后台上看到的轨迹就是乱飘的点。4.4 校验函数和最小上报数据NMEA 每一句末尾还有一个*加两位十六进制数这是整句的异或校验。收到数据后先做校验能过滤掉很大一部分串口丢包和脏数据。校验逻辑很固定把$之后、*之前的每个字符做异或结果和*后面的十六进制比较即可。def nmea_checksum_ok(line: str) - bool: line line.strip() if not line.startswith($): return False star line.find(*) if star -1: return False payload line[1:star] checksum 0 for ch in payload: checksum ^ ord(ch) received int(line[star 1:star 3], 16) return checksum received解析完成后上报到平台的数据我习惯整理成一段 JSON把有效字段全部带上{ imei: 869620040123456, lat: 30.659722, lng: 104.057093, fix: A, satellites: 9, hdop: 1.2, speed_kn: 0.5, timestamp: 2025-01-18T12:15:00Z }这里有一个容易忽略的点NMEA 里的时间是 UTC 时间平台展示如果要转本地时间应该在服务器端做不要在模组里手动加时区。模组端手动加减会造成夏令时或者跨时区场景下时间混乱而且一旦定位时间不准轨迹排序直接废掉。5. 实测中最容易“假定位”的六个坑我按这个顺序排查5.1 现象一CGPS 开了但串口永远没有 NMEA 数据这个现象最容易引起恐慌因为指令返回 OK看起来一切正常就是没有数据。我的排查顺序是先确认模组没有处于飞行模式不管定位还是通信先把射频功能打开然后重新执行一遍 NMEA 输出使能命令因为有的固件在模组重启后不会自动保留该配置再检查模组是不是把 GNSS 数据输出到了独立串口而不是主 AT 串口。我就在这个坑里栽过主串口上 AT 指令正常但我以为 GNSS 数据也会从同一个口出来结果发现模组 GNSS 输出是走另一个数据口的调了半天才发现。协议文档千万别跳着看。5.2 现象二能看到 GSV 卫星列表但 RMC/GGA 一直是 VGSV 能看到卫星说明天线和接收通路基本正常问题在于卫星信号还不够强接收机还没有达到定位条件。GSV 里每个卫星后面有一组信噪比C/N0单位是 dBHz。如果绝大多数卫星的信噪比都在 25 以下说明天线附近有遮挡或反射最常见的是金属外壳、电池靠近天线、显示屏排线横穿天线区。解决办法就是把设备拿到窗边或者室外重新测试。正常情况下搜到 4 颗以上卫星且信噪比稳定在 30 以上后状态就会从 V 变成 A。如果开了三分多钟还在 V先怀疑天线位置再怀疑天线本身。5.3 现象三室内“能定位”但坐标到处乱跳GNSS 信号在室内并不完全消失而是经墙体、金属家具反射后形成多径信号。接收机有时能靠这些反射信号算出一个“貌似合理”的坐标但稳定性极差HDOP 通常会大于 2.5点位会在房间内好几个位置之间跳。这类假定位比完全搜不到星更难发现因为软件上看确实是 A 状态。硬件方案能做的调整是换更好的天线、把天线尽量贴近外壳无遮挡面。软件上则要加一个质量门槛卫星数必须大于等于 4 且 HDOP 小于等于 2.5 才允许上报。宁可少上报一次也不要上报一个完全没有意义的位置。另外静止时位置小幅漂移是单点定位的正常现象需要在应用层做防漂移过滤。5.4 现象四第二段定位正常第三段突然丢了或者点位跳到几百米外这通常是运动过程的偶然丢星和重新收敛造成的。设备从开阔路面走进高架桥下、隧道、大型金属仓库时卫星信号被遮挡接收机会尝试用剩余卫星计算位置结果可能计算出一个漂移很大的点。解决思路有三个一是软件层做合理性判断比如相邻两点之间速度超过 30 节就认为点不可靠丢弃或者标记二是在产品上同时启用基站定位作为兜底信号弱时切到基站粗略定位保证轨迹不中断三是给模组配置“运动检测”相关的定位策略静止时不更新点位运动时才输出新位置。后面两种在 ML302 上都可行按产品需求选一种部署。5.5 现象五LTE 一通讯GPS 就出点慢甚至数据停顿这是非常典型的射频自干扰问题。LTE 天线发射瞬间功率较高如果 GNSS 天线离它太近LTE 信号会压缩 GNSS 接收机的前端动态范围导致灵敏度下降。现象就是平时定位正常一旦模组开始传数据NMEA 数据流就会出现停顿或者将至无效。硬件上处理方式是拉开两天线间距、在 GNSS 天线通路里增加 SAW 滤波器来抑制带外干扰。我后来在样机上加了一颗 SAW效果比较明显高并发场景下定位输出稳定了很多。软件上也可以在业务层错开 LTE 数据发送和 GNSS 收敛窗口尽量避免两者同时处于峰值状态。5.6 现象六ATCGPS 系列指令直接返回 ERROR这种问题通常是固件版本和命令集不匹配。模组在不同批次、不同固件里GNSS 功能可能存在差异有的旧固件甚至没有开放完整命令。不要在产品软件里写死一套指令最靠谱的做法是先统一固件版本然后针对该版本做一次完整的 AT 命令验证清单产线上跑一遍“开电源、等定位、读状态、关电源”的自动化脚本有问题直接返修不在软件层反复试。5.7 我总结的排查链路按照“电源 - 天线 - 卫星 - 协议 - 软件”的顺序来基本能覆盖九成问题。先确认 GNSS 电源确实打开再确认天线物理位置没问题再看 GSV 里卫星数量有没有稳定增长再看输出协议有没有启用最后才怀疑自己的解析代码。多数情况下问题出在天线位置和配置命令上而不是接收机本身。6. 从能出点到定位得准冷热启动、辅助定位和功耗取舍6.1 冷启动、热启动、温启动模组到底在忙什么冷启动是模组没有任何星历缓存的状态它要从卫星广播里把轨道参数慢慢读齐所以速度慢。热启动是指模组断电前已经缓存过星历重新上电后直接按已知星历搜索卫星速度快得多。温启动介于两者之间模组知道大概星空分布但没有准确的时间和位置参考收敛时间也居中。对电池类产品来说这个区别直接影响用户体验。如果每次定位都是冷启动用户按一次定位按钮要等一分多钟体验很差。所以模组断电方案不能把 GNSS 相关工艺电压完全切断至少要让 GNSS 接收机保留备份供电和 RTC这样下次开机才有热启动条件。有项目为了省那一点待机电流把 GNSS 供电一刀切结果每次定位都要重来反而更亏。6.2 AGNSS辅助定位首次定位能快多少AGNSS辅助GNSS的核心思路是通过蜂窝网络先给模组下发当前可见卫星的星历和大概位置接收机不用再从零开始搜索。这样在基站信号正常的环境下冷启动时间能压到二十秒以内有时候更快。对开机就要定位的产品来说这个速度很关键。ML302 平台一般会提供 AGNSS 相关接口和服务器地址配置。使用前先把服务器参数配置好然后再触发定位流程模组会自动下载星历数据。需要注意AGNSS 会带来少量网络流量而且依赖网络的可用性。如果设备部署在完全没有信号的环境里AGNSS 帮不上忙还得回归纯卫星定位加冷启动的策略。6.3 低功耗的上报节奏不要一直开着GNSS定位功能的功耗大头往往不是接收机本身而是“长期开着定位通道等待结果”。对周期性上报的产品不要用“一直开着 GPS定时取一次数据”这种偷懒方案而应该用“唤醒、开电源、等定位、上报、关电源、休眠”的严格时序。我实测下来同样的硬件周期定位加休眠和持续定位相比电量消耗差别非常明显。这里有一个细节模组上电后 GNSS 电源是否默认打开不同固件配置不一样。如果默认打开即使你不发定位指令接收机也在耗电。量产软件要主动把 GNSS 电源状态管理好或者在硬件上用可控开关。另外运动检测也值得做。设备静止时位置本来就不该变没必要周期开定位检测到移动事件后再唤醒定位流程能省下大量无效定位。两轮车停车后一晚上不触发定位和每隔五分钟开一次 GPS续航差异能到数倍。6.4 离线缓存与补报比你想的更关键信号差的地方最怕“当下定不了位数据也丢了”。我建议定位设备设计一个简单可靠的策略每次有效定位先缓存在模组外挂 Flash 或主控 Flash 里等到蜂窝网络恢复、或者模组重新注册成功再按时间顺序补报。缓存里带 UTC 时间戳就行不要用本地时间否则排序会乱。补报数据量一般很小每条几十字节批量上报也不会浪费太多流量。唯一要注意的是补报顺序和去重避免平台收到乱序轨迹。很多看起来“轨迹绕弯”的问题其实就是补报时间戳排序没做好。说实话把这个功能完整跑通并不神秘难点基本都在细节上天线净空够不够、电源时序对不对、NMEA 校验做没做、无效定位有没有过滤、冷启动方案有没有配合。把这些点按我上面说的链路过一遍ML302 的 GNSS 基本就能稳定输出可靠坐标了。你手头项目如果正好在做定位类场景不妨直接照这个顺序试遇到具体问题再回来对号入座排查。