简介这是一份完整的基于STM32F103与OneNet平台的GPS定位器项目源码包面向物联网嵌入式开发者与电子设计爱好者适用于车辆、宠物、物资等实时追踪场景解决设备端采集经纬度并通过ESP8266经HTTP协议上云的问题。随着移动物联网应用普及GPS定位器需同时兼顾实时、低功耗与稳定性本包正是围绕该需求整理的可复刻方案。包内共156个文件涵盖C/H源码、Keil工程文件uvprojx、编译产物hex/axf、设计文档docx/pdf以及辅助配置说明等既可直接烧录验证也可导入工程逐步调试方便对照学习或二次开发。压缩包整体34.41MB目录结构清晰便于按功能模块快速定位。目前已有1049人浏览学习。项目提供完整源码与设计文档并附带演示视频能够帮助读者快速复刻从GPS数据解析、ESP8266联网到OneNet平台可视化展示的完整链路同时包含常见排错思路与工程配置说明是一份可操作性很强的实战参考资料。 这套项目一眼看过去就是典型的物联网毕业设计/工程实训题目但架构非常经典STM32负责主控和数据解析GPS模块提供经纬度ESP8266通过HTTP协议把数据送上OneNet云平台最终能在网页或App上看到设备位置。做这个项目的人通常卡在三个地方GPS输出的NMEA字符串不知道怎么解析、ESP8266的AT指令调用顺序模糊、OneNet的数据格式和API Key配置混乱。这篇就把整条链路完整拆开讲从硬件接线到平台配置再到最后一台电脑能看到的定位点适合正在做毕设、准备电子设计竞赛或者想自己动手做个车辆/物品追踪器的人参考。1. 这套定位器的整体架构为什么是STM32ESP8266HTTP1.1 系统组成与数据流整套系统硬件上只需要四块核心部件一块STM32最常见的是STM32F103C8T6便宜、资料多、引脚够用、一块GPS模块NEO-6M或者ATK-S1216都行、一块ESP8266模块ESP-01S或者NodeMCU开发板都可以、以及一个5V电源供电。数据链路是这样的GPS模块上电后持续通过串口输出NMEA 0183协议格式的定位语句STM32用USART1接收这些字符串从中解析出经纬度、速度、定位状态等信息接着STM32通过USART2把解析好的经纬度以AT指令的方式发给ESP8266ESP8266连接WiFi后向OneNet平台的HTTP接口发起POST请求把数据包提交上去最后在OneNet控制台的“应用管理”里创建一个地图组件或者数据流可视化就能看到实时定位点了。整个流程里有几个容易忽略的点需要一开始就建立概念。GPS模块和ESP8266都走串口通信但两者不能挂在同一路USART上否则会互相干扰所以STM32至少需要两路空闲串口。还有ESP8266上电后会往串口打印一堆乱码一样的启动日志这是正常现象不要误以为是数据损坏。1.2 选型逻辑HTTP比MQTT更适合这个项目起步很多人在做这个题目时会问为什么不用MQTTMQTT在OneNet上确实也是主流接入方式尤其适合需要下行控制、设备数量大、网络不稳定的场景。但对于一个以“定时上报位置”为主的定位器来说HTTP反而更直观原因有几点。第一调试链路短。HTTP的POST请求是纯文本我们完全可以在PC上用串口助手手动模拟把请求头和数据体粘贴给ESP8266发出去立刻就能判断是网络问题还是数据问题。MQTT则需要先理解topic、clientId、username、password全套认证逻辑出问题时排查面更广。第二OneNet的HTTP接入采用的是“设备ID api-key”这种固定凭据比MQTT的三元组好理解平台文档里也大量使用HTTP作为示例。第三定位器本身没有复杂的双向通信需求HTTP单向上报足够用。如果后续想扩展远程控制、命令下发之类的功能再平滑迁移到MQTT不迟代码里把数据拼装的逻辑抽象出来换协议时只需要改传输层。所以我的建议是入门和毕设优先走HTTP把整条链路跑通后再考虑MQTT进阶。2. GPS模块串口数据解析NMEA协议是第一个坑2.1 认识NMEA语句GPRMC里藏着经纬度GPS模块上电后串口输出的是NMEA 0183国际标准协议文本典型输出长这样$GNGGA,064036.491,2833.4278,N,11557.4781,E,1,05,2.8,74.1,M,-2.5,M,,*5E $GNRMC,064036.491,A,2833.4278,N,11557.4781,E,0.08,272.77,161224,,,A,V*35很多新手拿到这串数据的第一反应是懵。不要被长句子吓到整个协议里有用的核心语句就那么几条对我们做定位器来说最推荐解析的是$GPRMC推荐最小定位信息它一次给出了定位状态、经纬度、速度、航向、日期足够满足定位器的基本功能。以$GPRMC为例各字段用逗号分隔顺序是语句头、UTC时间hhmmss.sss、定位状态A有效V无效、纬度度分格式、纬度半球N/S、经度度分格式、经度半球E/W、地速、航向、日期、磁偏角等。其中最容易出错的是经纬度格式GPS模块输出的是“ddmm.mmmm”这种度分混合格式比如2833.4278表示28度33.4278分需要把它转换成十进制小数28 33.4278 / 60 28.55713这样才能被OneNet地图组件直接使用。2.2 STM32中断接收与GPRMC解析实现既然串口是一行一行输出文本STM32这边最稳妥的做法是串口中断逐字节接收把收到的字符累积到缓冲区遇到\n就认为一帧结束然后调用解析函数处理这一行。核心解析代码大致是这样#include stdio.h #include string.h #include stdlib.h // 度分格式转十进制度dir是半球字符 N/S/E/W float convert_coordinate(const char *coord, char dir) { float raw atof(coord); int degrees (int)(raw / 100); float minutes raw - degrees * 100; float result degrees minutes / 60.0; if (dir S || dir W) { result -result; } return result; } // 解析一行GPRMC成功返回0定位无效返回-2 int parse_gprmc(const char *line, float *lat, float *lng) { char buf[128]; char *field[16]; int count 0; if (strncmp(line, $GPRMC, 6) ! 0) { return -1; } strncpy(buf, line, sizeof(buf) - 1); buf[sizeof(buf) - 1] \0; field[count] strtok(buf, ,); while (count 16 (field[count] strtok(NULL, ,)) ! NULL); if (count 10) return -1; // field[2] 是定位状态A 表示有效 if (field[2][0] ! A) { return -2; } *lat convert_coordinate(field[3], field[4][0]); *lng convert_coordinate(field[5], field[6][0]); return 0; }这段代码看起来简单但有一个非常关键的操作判断field[2][0] ! A。如果不判断定位状态直接把无效定位时的经纬度发上云平台地图上就会看到位置乱跳。很多项目跑起来“定位飘得离谱”问题往往就出在这里。坐标转换函数里也留了个细节南纬和西经要转成负数。OneNet的地图组件默认用经纬度浮点数纬度南半球为负、经度西半球为负如果不做这个处理一旦设备跨过赤道或本初子午线坐标点就会跑到地球对面去。2.3 GPS模块的物理接线与上电注意事项GPS模块的接线相对简单NEO-6M这类模块自带稳压VCC可以直接接5VTX输出3.3V TTL电平接到STM32 USART1的RX引脚即可。注意GPS模块和STM32要共地否则串口数据会时好时坏。最大的坑是定位时间。GPS模块在空旷环境下的冷启动定位时间短则三四十秒长则几分钟在室内基本无法定位。测试时一定要把模块放到窗边或室外不要拿手捂着人体对卫星信号有遮挡。模块上的PPS小灯一秒闪一次表示已经定位成功这时候再去查看串口数据里是不是全是A状态。3. ESP8266接入OneNetAT指令序列与HTTP请求拼装3.1 硬件接线与ESP8266固件准备ESP8266这块建议直接使用出厂自带的串口AT固件不需要自己烧录SDK除非你想让ESP8266直接解析GPS数据但这个项目架构里ESP8266只负责透传AT固件完全够用。接线方面以ESP-01S为例VCC接3.3VGND共地CH_PDEN必须接3.3V使能悬空的话模块不工作GPIO0悬空或接3.3V保持运行模式TX接STM32 USART2的RXRX接STM32 USART2的TX这里重点提醒ESP8266是3.3V逻辑电平绝对不能把它的RX直接接在5V单片机的TX上长期会烧模块。STM32的TX如果兼容5V中间最好加电平转换或者用电阻分压。还有一个常被忽略的操作老款ESP-01S默认串口波特率是115200而多数人的调试习惯是9600。上电后先发一条AT确认模块响应如果全是乱码先发ATUART_DEF9600,8,1,0,0把固定波特率改成9600再继续后续调试。注意ATUART是掉电失效的临时设置ATUART_DEF才会持久保存。3.2 建立WiFi连接与TCP链路ESP8266连接OneNet的第一步是先联网。AT指令的顺序不能乱典型序列如下AT ATCWMODE1 ATCWJAP你的WiFi名,你的WiFi密码 ATCIPSTARTTCP,183.230.40.39,80其中ATCWMODE1是station模式让ESP8266作为终端去连路由器。ATCWJAP返回WIFI CONNECTED之后还要等几秒返回WIFI GOT IP不要看到第一条就急着发下一步。TCP连接这一步是个重要决策点。OneNet的HTTP接入域名是api.heclouds.comESP8266的AT固件对域名解析支持不太好很多版本的固件ATCIPSTART只能填IP。所以我做这个项目时的做法是在PC上ping api.heclouds.com把返回的IP地址目前常见的是183.230.40.39这个网段直接写进程序。就算以后IP变了当场ping一下替换就行比在固件里折腾域名解析要省事得多。3.3 HTTP POST请求的拼装与数据格式TCP链路建好之后重点来了拼HTTP请求。OneNet的HTTP上传数据点接口格式比较固定完整的请求长这样POST /devices/你的设备ID/datapoints?type3 HTTP/1.1 Host: api.heclouds.com api-key: 你的APIKey Content-Length: 数据体字节数 {datastreams:[{id:location,datapoints:[{value:{lon:116.397128,lat:39.916527}}]}]}有几个细节必须注意。type3表示数据体是JSON格式这个参数漏了或者写错平台可能返回格式错误。api-key就是OneNet控制台里复制的那一串注意不要带引号不要带api-key:之外的空格。请求头和数据体之间一定有一个空行也就是两个\r\n没有这个空行服务器会一直等待请求体表现为“数据发送了但平台没收到”。Content-Length是数据体也就是最后那个JSON字符串的字节数不是整个请求的长度而且必须是精确字节数多一个少一个都会导致HTTP解析失败。我在代码里直接用sprintf拼出一个字符数组body[]然后用strlen(body)计算长度这样最不容易出错。下面是STM32向ESP8266发送指令的流程骨架// 假设body已经拼好len是body长度 // 1. 发送CIPSEND指定总发送长度 uart2_send_str(ATCIPSEND); uart2_send_int(strlen(body) strlen(request_head)); uart2_send_str(\r\n); // 2. 等待ESP8266返回 提示符 // 3. 一次性发送 request_head body uart2_send_str(request_head); uart2_send_str(body); // 4. 收到 SEND OK 后关闭连接 uart2_send_str(ATCIPCLOSE\r\n);注意ATCIPSEND后面的数字是“请求头长度 数据体长度”的总和因为ESP8266发送的是整个TCP流。而且每次上报数据需要重新建立TCP连接再关闭OneNet的HTTP接口本身就要求“一请求一连接”不用刻意做长连接保持省得维护麻烦。上报数据后返回的未读数据里如果出现了HTTP/1.1 200 OK和{errno:0,error:succ}就表示平台成功接收了。调试阶段完全可以不接STM32用USB转TTL串口助手直接给ESP8266发AT指令手动粘贴上面的HTTP报文先把平台通路的成功率验证到100%再去调STM32的程序这样分模块调试能省下大量时间。4. OneNet平台侧配置设备ID、API Key与地图数据流4.1 控制台创建产品与设备OneNet平台侧的配置很多人第一次操作时会找不到入口这里把步骤捋一遍。登录OneNet物联网开放平台控制台不是旧版的M2M控制台新版入口是“多协议接入”那一套先创建产品联网方式选择WiFi协议选择HTTP。产品创建完成后在产品下添加设备会得到一个数字类型的“设备ID”这个ID和后面生成的API Key一起拼进HTTP请求里。设备创建后在设备详情页能看到“API Key”通常是一串很长的十六进制字符串这就是HTTP请求头里api-key字段的值。如果找不到可以在产品的“API Key管理”里单独生成然后关联到对应设备。这里涉及一个权限层级产品级API Key可以操作该产品下所有设备设备级API Key只能操作单台设备。个人调试建议直接用产品级API Key少一次权限判断的出错机会。4.2 数据流模板与地图组件HTTP上报数据时不强制要求预先创建数据流平台会在收到新数据流ID时自动创建。但为了让“location”数据流被正确识别为GPS类型最好在平台上手动创建数据流模板类型选为GPS或经纬度类型。这样在应用管理里添加地图组件时就能直接下拉选中这个数据流否则组件里看不到或者地图打点异常。OneNet的地图组件支持“location”格式的数据流数据点的value必须是JSON对象形式{ lon: 116.397128, lat: 39.916527 }创建好地图组件后把数据流绑定上去组件会以红点标记位置。如果希望看到历史轨迹还可以在同一数据流上配置折线图组件平台会自动按时间顺序把经纬度连成轨迹线。这一步配置完整条链路就算打通了接下来就是反复测试稳定性的阶段。5. 实测调试链路与高频故障排查5.1 分层调试先把PC端通路跑通再交给STM32这个项目最忌讳的是“全部接好线再上电”一旦不工作根本不知道是GPS没定位、ESP8266没联网、还是HTTP报文格式错了。我的做法是严格分三层验证。第一层用USB转TTL接GPS模块电脑串口助手看NMEA输出确认模块能定位、能看到$GPRMC且状态位为A。第二层用USB转TTL接ESP8266手动发AT指令连WiFi、连TCP、粘贴HTTP报文确认OneNet平台能收到数据这一步通常能排查掉80%的问题。第三层把所有模块接到STM32上用串口调试打印分别观察GPS解析结果和ESP8266发送的指令内容最后再综合测试。STM32固件里建议加两个调试打印点一个在GPS解析完成后打印lat和lng另一个在发完ATCIPSEND后打印返回值。这两个打印点能快速定位问题到底出在上行链路还是下行链路。5.2 高频故障速查表现象可能原因排查方向ESP8266连不上路由器模块供电不稳、WiFi密码错误检查3.3V电流能力CH_PD是否拉高密码是否正确WiFi已连接但TCP连不上OneNetIP地址填错、端口不是80PC上重新ping域名换IP确认TCP端口是80数据发出但平台无新增数据点Content-Length不匹配、缺空行、api-key错误、type参数缺失用串口助手手动发送精确报文逐字节核对请求头平台有数据但地图不定位数据流不是location格式、经纬度未转十进制或转成负数检查value里的lon/lat标签核对度分转换公式208三个字里显示但没有errno设备ID或api-key与产品不匹配控制台核对设备ID重新生成API KeyGPS长时间无法定位室内测试、天线朝向不对、模块冷启动移到窗外等待PPS灯稳定闪烁ESP8266频繁复位供电不足峰值电流拉低电压换稳压能力更强的3.3V模块或单独供电其中“数据发出但平台无新增数据点”是最常见的几乎都是HTTP请求头细节问题。这里分享一个高效验证技巧不要让STM32参与直接用串口助手向ESP8266发送完整的报文文本如果这样能成功说明问题出在STM32的代码逻辑如果这样也失败那就是报文格式问题对照上面的表格逐项核对。5.3 代码层面的健壮性细节最后补充几个写代码时值得注意的细节这些都会直接影响项目能不能长时间稳定运行。第一缓冲区大小要给足。sprintf拼HTTP请求时请求头加上JSON数据体总共可能超过200字节如果缓冲区只分配了64字节数据会被截断Content-Length算出来和实际发送不一致平台就会拒收。建议请求缓冲区至少256字节GPS解析缓冲区128字节以上。第二上报频率不要太高。OneNet单设备的数据点上报频率有限制定位器每秒上报一次完全没必要还容易触发限流。实测5到10秒一次足够既能看到实时轨迹又不会给WiFi模块和云平台造成压力。第三GPS解析要考虑模块输出的语句差异。有的模块输出的是$GNRMC而不是$GPRMC只匹配$GPRMC就会一直解析失败。稳妥的做法是匹配GPRMC时用strstr而不是strncmp或者同时兼容$GPRMC和$GNRMC两种开头。第四经纬度的精度至少保留6位小数。一位小数约等于11公里三位小数约等于110米五位小数约1米多一点做定位器最少也要保留5位以上。sprintf格式化时用%.6f输出最保险。我在实际测试中还发现一个装逼但很实用的细节上报数据里可以带时间戳字段格式形如timestamp:2024-01-01 12:00:00不填的话平台会默认用接收时刻。如果你做的定位器需要回放历史轨迹建议在GPS解析时把UTC时间转成北京时间一并拼进去这样OneNet折线图的时间轴就是设备真实时间而不是平台接收时间后续分析轨迹会有用得多。不过这个属于锦上添花先把基础链路跑通再考虑扩展就好。本文还有配套的精品资源点击获取
