IoT模组使用笔记（二）：EC21、EC200指令流程、设置休眠、升级模组、切换运营商等_移远休眠

5.1 EC20和5.2 BC20是最开始接触4G模组的使用记录，参考意义不是很大。后来新工作转做Iot，开始慢慢扩充这篇笔记。

5.1 EC20

5.1.1 注册网络失败。

如下图所示：

将APN修改为SIM卡对应的运行商，多次发送AT+QICSGP=1,1,“CTNET”,“”,“”,0指令，然后复位开发板即可。如下图所示：

5.1.2 TCP连接指令流程：

EC20模块AT命令讲解
EC20 TCP/IP指令例程
移远M26，三分钟打通TCP流程，AT指令详解

在linux端操作：
移远EC20 4G模块Linux驱动移植和测试

5.2 BC20

5.2.1 上电指令流程

AT\r\n
AT+QSCLK=0\r\n	;禁用休眠模式
AT+CPIN?\r\n	;检查是否需要密码
AT+CFUN=0\r\n	;设置为最小功能
AT+QBAND=0\r\n	;设置为所有工作频段
AT+QCSEARFCN\r\n;清除 NB-IoT 存储的 EARFCN 列表
AT+CFUN=1\r\n	;设置为全功能
AT+CGATT=1\r\n	;附着网络，要多等一会
AT+CSQ\r\n		;上报信号质量
AT+CEREG?\r\n	;查询网络注册状态
AT+CGATT?\r\n	;查询
AT+CGPADDR?\r\n	;
1
2
3
4
5
6
7
8
9
10
11
12

5.3 EC21-KL

5.3.1 休眠异常

遇到了两个问题：

1. 第一次休眠，功耗异常，13mA，之后再次休眠6mA。
2. 唤醒后不能正常响应指令。经常出现无返回，多次尝试错误后，应用程序对4G模组进行重启。查看log，也不是完全不回。第一次publish能够回复，之后QMTRECV指令开始不回复，如下：
   
   这两个问题很有意思，正好手里有块焊接了EC25-EUX的板子，测试发现这两个问题都不会出现。那是模组问题吗？
3. 第一个问题，从现象看是有什么外设上电初始化没有配置好，唤醒后的配置使其恢复了正常。但是又无法解释EC25为什么正常。最终确定是因为使用rtthread，第一次睡眠，初始化线程没有来得及发送AT+QSCLK休眠指令。EC25可能执行较快，所以没有出现问题。通过改变进入休眠的时间解决。或者将AT+QSCLK休眠指令放在初始化也可以，不过祖传代码嘛，还是少动为妙。
4. 第二个查看模组VDD_EXT电压正常1.8V，模组正常启动了。DTR唤醒后正常拉低。在RX管脚使用示波器查看，直接用示波器解码，可以看到MCU发出了AT+QMTRECV=0指令。模组确实没有回复。
   和移远沟通，需要抓取log。但是模组休眠后，抓log工具会检测到idle自动断开。通过修改MCU程序，空闲线程唤醒后直接while(1)原地循环，然后使用串口助手通过USB给模组发送指令，发现能够复现问题。这样在唤醒后，打开抓log工具，用串口助手发送AT指令即可。最终得到回复：判断是mqtt配置成 recv/mode 为1情况下，执行QMTRECV，模块com口死掉。是一个已知问题，通过升级模组固件解决。

5.3.2 模组软件升级

1. 确认主串口。在资源管理器查看端口如下：
   
   升级使用主串口COM26。
2. 打开QFlash升级工具，选择升级文件。注意这里不要选择压缩包（是否直接选择压缩包可以和移远技术支持咨询，不同模组应该不一样的）：
   
   选择一个文件后，会自动加载所有的文件。注意文件不要有中文路径，选择正确的波特率：
   
   滑到软件底部，选择Start即可。升级成功则忽略以下步骤，重启模组查看版本号是否一致。
3. 我这里发现升级失败：
   
   此时再查看资源管理器，只有一个端口：
   
   这是模组进入了强制下载模式。如果这时重启模组，会恢复为初始的三个端口。但是我们再次选择COM26升级，则会显示端口不正确：
   
   这时需要在MCU程序中，上电后使用while(1)循环，不再发送指令。将模组的BOOT管脚拉高到1.8V，我的如下图：
   
   我这里短接R27即可。短接后重新上电模组，进入强制下载，恢复为一个端口COM27。选择COM27，继续升级。
   我这里持续失败，最终确定是模组的驱动比较旧（Quectel_LTE_Windows_USB_Driver_V1.0），虽然能抓log，但升级出现了问题。更新模组驱动后（Quectel_LTE&5G_Windows_USB_Driver_V2.2.4），直接升级成功。升级成功后，发现我的MCU程序持续复位，最终定位到新的模组固件，版本号变得更长了，导致溢出。。。。

5.4 EC200N-CN和EC200S-EU

EC200N-CN是国内使用的模组，EC200S-EU是欧洲设备上使用的模组。MCU程序是通用的。

5.4.1 设置模组休眠

1. 模组进入休眠，有三个条件：

   AT+QSCLK=1 //不必每次发送，初始化一次就可以
   network_apready_ctrl(0); 		/* 通知模组不要送出数据 */
   network_dtr_ctrl(1);		  	/* 拉高DTR进入4G的低功耗 */  
   1
   2
   3

   

2. 确定模组进入休眠状态？
   DTR拉高之后串口不通，另外耗流降到个位数mA。模组进休眠很快的，预估2s左右。
   也可以通过测量模组管脚电平，比如EC25，结合以下指令，测量管脚号3：
   

3. MCU主动唤醒模组
   休眠后，MCU主动发送数据，需要先唤醒4G模组：

       network_apready_ctrl(1); 		/* 通知模组可以送出数据 */
       network_dtr_ctrl(0);		  	/* 拉低DTR退出4G的低功耗 */ 
   1
   2

   这时不要立即发送数据，因为4G模组退出低功耗也是需要时间的。可以持续发送AT，直到返回OK。或者直接增加延时（“先留1S吧”）。

5.4.2 ping谷歌

此部分单独写成一篇：使用移远EC200N-CN模组PING谷歌。

5.4.3 手动切换运营商

5.4.3.1 运营商代码 - IMSI和QSPN

在初识NB-IoT的机卡绑定一文中提到IMSI的前5位可以识别运营商：

中国移动运营商：
46000, “CHINA MOBILE”, “CN” 中国移动
46001, “CHN-CUGSM”, “CN” 中国联通
46002, “CHINA MOBILE”, “CN” 中国移动

更多运营商名称的列表，可以点击查看：添加链接描述。

00> AT+QSPN
00> …
00> +QSPN: “CHN-UNICOM”,“UNICOM”,“”,
00> 0,“46001”…
00> …
00> OK…
00> 01-01 23:50:32 I/at.dev.ec20 tbox_tcp: e0 device currnet PLMN: 46001

5.4.3.2 为什么要切换运营商

iotbox默认自动选择运营商。在使用过程中，可能出现以下情况：

1. iotbox自动选择的运营商出现网络故障；
2. iotbox自动选择的运营商在车辆行驶的区域内并不支持。
   出现这些情况时，iotbox就会因注册网络失败而重启4G模组。若重启后又自动选择了该运营商，则iotbox再次因注册网络失败进行重启，这样iotbox就会进入死循环。为了解决这个问题，iotbox增加手动切换运营商机制。在自动选择运营商持续注网失败一定次数后，iotbox进入手动切换运营商模式：检索当前SIM卡支持的运营商，依次进行尝试，直至注网成功。

5.4.4 抓取TCP的log

在前面硬件连接 - - USB中提到了抓取模组log。不同平台的模组可能稍有区别。TCP连接过程中，模组上报+QIURC: "closed",0..导致异常。抓取模组log，从模组端分析下原因。

1. 抓取LOG时需要进行AT+CFUN=0，AT+CFUN=1，操作，记录完整通信流程日志。
2. 为了抓取TCP/IP数据包，记录LOG日志前，执行如下AT指令操作：
   IPv4 发送指令at+qdbgcfg=“iptrace”,0,20
   IPv6 发送指令at+qdbgcfg=“iptrace”,1,20

在程序模组初始化中添加以下三条AT指令：