搜索
bottom↓
回复: 21

提醒:ESP8266模块AT命令网络传输会丢包

[复制链接]

出0入0汤圆

发表于 2016-10-22 16:02:46 | 显示全部楼层 |阅读模式
最近在做个产品,打算有线无线都支持,所以板上集成了ESP-12模块,有线用的W5500。
在办公室测试一切OK,上周去现场测试了一把,发现PC这端收到的数据有大量缺失。
回来折腾了一周,最后发现ESP模块丢掉了一些数据。

情况是这样:
有一台PC作为服务器端,我用Java写了个TCP服务器。
有5块板子上面有ESP12模块,STM32主控,连接WIFI路由器后,通过AT命令连接PC上的TCP服务器,然后把要发的数据通过建立好的TCP连接发给PC。
要发的数据一个包大约有53Bytes,最初是一个包一个包的发,后来发现速度跟不上,因为AT命令需要等待ESP模块返回OK之类的信息,STM32里面等的时候比较久,数据多了速度就跟不上了。
后来我改为一次发多个包,因为ESP模块手册说一次最多可以发2048个Bytes,所以我一次发10个包,大约530Bytes。
在办公室测试的时候没发现问题,因为我开发用的电脑速度够快。

到现场后,用的x200笔记本电脑,速度比较慢,然后就发现有些数据没收到。

回来折腾一周,最后发现有些包,ESP给STM32返回信息是发送OK,但是实际上PC这端没有收到。不知道是不是ESP模块内部的程序有bug,总之没收到。之前因为觉得无线的系统部署方便,所以有线部分的通讯程序没写,昨天把有线通讯的程序写了之后,最后换成有线,还是通过TCP连接发数据,一切OK。
顺便说一下,STM32这端使用了队列来缓冲数据,并确认全部数据包都已被ESP发出,ESP返回OK;PC端加了各种else和异常捕捉,确保有出错时被发现。所以,看上去通讯过程完全正确,但就是丢包了。我发的数据包有序列号,统计了一下,大约会有一半的数据包丢了。

因为时间紧,这个版本估计最能用有线了。过段时间折腾下ESP的开发,自己写个固件来配合STM32

提醒一下大家,使用ESP模块做产品时,注意一下丢包的事。

出100入101汤圆

发表于 2016-10-22 16:12:51 | 显示全部楼层
”有一半的数据丢了”,真这样的话,显然没法商用。

出0入0汤圆

发表于 2016-10-22 16:26:21 | 显示全部楼层
>>提醒一下大家,使用ESP模块做产品时,注意一下丢包的事。

普遍这个样子的话,问题很严重。

出0入0汤圆

发表于 2016-10-22 16:28:58 | 显示全部楼层
是TCP还不是 UDP ,那还玩什么?????

出0入0汤圆

发表于 2016-10-22 16:33:48 | 显示全部楼层
丢失一半数据,不会这么差的。

出0入0汤圆

发表于 2016-10-22 16:36:29 | 显示全部楼层
我还想用,听你这样说,我就不敢用了

出0入0汤圆

发表于 2016-10-22 16:48:02 | 显示全部楼层
无线wifi,感觉并不是很稳定的。其它wifi的干扰,同一wifi下客户端过多的问题,所以,工业现场尽量别用wifi,个人观点

出0入0汤圆

发表于 2016-10-22 17:02:32 | 显示全部楼层
之前用的是透传模式,为了避免数据丢失,发一大堆数据后等待服务器给的反馈,再接着发

出0入0汤圆

 楼主| 发表于 2016-10-22 17:19:40 | 显示全部楼层
再补充说明一下。
我发的数据包的序列号是1Byte,从0-255。数据包是其他系统生成的,STM32这边收到的时候本来也不一定完整,所以开始的时候PC端收到数据不是连号的,我也没有在意。数据包大饼200ms有一个,正常情况下1s会有5个,但是偶尔少一点也没关系。
开发用的电脑速度很快,丢得不多,我以为是STM32收到就不完整,所以之前一直没有注意。

到现场后,发现缺失太多,系统基本没办法工作。回办公室研究,才发现是esp搞丢的。
为了测试,还写了一个TCP客户端在电脑上,模拟STM32发tcp数据给服务器。测试时服务器我用vmware跑win7执行java写的tcp服务器。用模拟的客户端发数据时一切正常,因为是本机的pc与vmware通讯,这就排除了tcp服务器速度慢而导致的可能。
换成板子通过esp发数据给vmware上的服务器时,就丢包了。

出0入147汤圆

发表于 2016-10-22 17:23:54 来自手机 | 显示全部楼层
也在用8266,没发现这个问题,很可靠。多说一句,如果是8266的问题,那就跟你用什么电脑没关系,不会出现有的电脑丢得多,有的电脑丢得少的情况。

出0入14汤圆

发表于 2016-10-22 20:55:04 | 显示全部楼层
等待后续,我现在也准备用

出0入0汤圆

发表于 2016-10-22 21:52:05 | 显示全部楼层
换换网卡 路由器 可能挑网卡  
这种不如用数传

出0入0汤圆

发表于 2016-10-22 21:52:37 | 显示全部楼层
楼主有时间可以检查一下什么问题吗?我觉得如果是这样严重的bug,ESP8266 不会那么火啊

出0入0汤圆

发表于 2016-10-22 22:22:28 来自手机 | 显示全部楼层
我没用过这个芯片不评论,我只是想问,楼主搞通信难道没有应答、校验、重发等机制吗?

出0入0汤圆

 楼主| 发表于 2016-10-23 00:07:41 | 显示全部楼层
pazulin 发表于 2016-10-22 21:52
楼主有时间可以检查一下什么问题吗?我觉得如果是这样严重的bug,ESP8266 不会那么火啊 ...

产品等着交货,近期估计没时间查。接下来会查查原因的,我觉得esp8266是个不错的芯片,我这个产品上想接着用它
我觉得可能是AT固件的问题。我估计会直接用esp的sdk开发个固件来跟stm32接口,不用at命令了

出0入0汤圆

 楼主| 发表于 2016-10-23 00:13:12 | 显示全部楼层
本帖最后由 BD8NCF 于 2016-10-23 00:14 编辑
dadatou 发表于 2016-10-22 22:22
我没用过这个芯片不评论,我只是想问,楼主搞通信难道没有应答、校验、重发等机制吗? ...


没有应答和重发机制,有校验。因为我要处理的数据包要求及时性高,即使丢一些包也没事,重发没有意义,应答耽误时间(本来AT命令的方式发,就要花费很多时间来做命令的交互)。有校验机制,保证收到的包是正确的就可以了。但是如果丢包太多,系统的效率就很低了。

出0入0汤圆

 楼主| 发表于 2016-10-23 00:23:45 | 显示全部楼层
dreampet 发表于 2016-10-22 17:23
也在用8266,没发现这个问题,很可靠。多说一句,如果是8266的问题,那就跟你用什么电脑没关系,不会出现有 ...

开始我也觉得不会是esp的问题,所以花了好几天时间在java的代码上,到周五才发现是esp的问题。
我不清楚esp的at固件的tcp部分是怎么处理的,所以无法证明它错在哪里,但是事实就是这样。
stm32控制发出的数据包,一轮(0-255)的数据包stm32大概会收到220个左右,发送的时候esp这么没有任何错误提示,都是OK。在vmware上的服务器侧统计,大约收到90多个,每轮丢掉的包数量不一样,服务器这边也没有任何错误发生。
看上去通讯一切正常,没有任何错误,但就是有些包没有收到。

如果有空,你也可以试验一下

出0入0汤圆

发表于 2019-7-12 14:37:01 | 显示全部楼层
这模块针不能用,丢数据非常严重,为什么还那么火就搞不懂了

出0入0汤圆

发表于 2019-7-31 09:42:49 | 显示全部楼层
tkcb8b 发表于 2019-7-12 14:37
这模块针不能用,丢数据非常严重,为什么还那么火就搞不懂了

楼主有没测试过WIFI天线信号强度 天线信号不好 影响非常大

出0入0汤圆

发表于 2019-8-8 13:44:22 | 显示全部楼层
ap0705307 发表于 2019-7-31 09:42
楼主有没测试过WIFI天线信号强度 天线信号不好 影响非常大

信号强度没问题,距离也就一米,外置天线。数据丢失严重,透传模式模块还会自己在前面加字节。

出90入4汤圆

发表于 2019-8-8 19:34:15 来自手机 | 显示全部楼层
暂时没有发现丢包,做AP笔记本电脑从路由切换会郁闷,有时联不上,有时获取不到IP.
头像被屏蔽

出0入0汤圆

发表于 2019-10-29 07:52:02 来自手机 | 显示全部楼层
提示: 作者被禁止或删除 内容自动屏蔽
回帖提示: 反政府言论将被立即封锁ID 在按“提交”前,请自问一下:我这样表达会给举报吗,会给自己惹麻烦吗? 另外:尽量不要使用Mark、顶等没有意义的回复。不得大量使用大字体和彩色字。【本论坛不允许直接上传手机拍摄图片,浪费大家下载带宽和论坛服务器空间,请压缩后(图片小于1兆)才上传。压缩方法可以在微信里面发给自己(不要勾选“原图),然后下载,就能得到压缩后的图片】。另外,手机版只能上传图片,要上传附件需要切换到电脑版(不需要使用电脑,手机上切换到电脑版就行,页面底部)。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

手机版|Archiver|amobbs.com 阿莫电子技术论坛 ( 粤ICP备2022115958号, 版权所有:东莞阿莫电子贸易商行 创办于2004年 (公安交互式论坛备案:44190002001997 ) )

GMT+8, 2024-4-19 01:16

© Since 2004 www.amobbs.com, 原www.ourdev.cn, 原www.ouravr.com

快速回复 返回顶部 返回列表