一. 来自“M5310-A硬件设计手册V1.5”
-
DCE：Data Communication Equipment
DTE：Data Terminal Equipment
| 模式 |
描述 |
| Active |
模块处于活动状态；所有功能正常可用，可以进行数据发送和接收；模块在此模式下可切换到 Idle 模式或 PSM 模式。 |
| Idle |
模块处于浅睡眠状态，网络保持连接状态，可接收寻呼消息； 模块在此模式下可切换至 Active 模式或者 PSM 模式。 |
| PSM |
模块只有 RTC 工作，网络处于非连接状态，不可接收寻呼消息； 当DTE（Data Terminal Equipment）主动发送数据或者定时器T3412（与周期性更新相关）超时后，模块将被唤醒。 |
- NB-IOT主要用到两种节电技术，分别是PSM（Power Saving Mode）和eDRX（Extended DRX）。
-
PSM：模块在PSM下的最大耗流为5uA。PSM 主要目的是降低模块功耗，延长电池的供电时间。
①模块进入PSM的过程如下：模块在与网络端建立连接或跟踪区更新（TAU）时，会在请求消息中申请进入PSM，网络端在应答消息中配置T3324 定时器数值返回给模块，并启动可达定时器。当 T3324 定时器超时后，模块进入PSM。
模块在针对紧急业务进行连网或进行公共数据网络初始化时，不能申请进入PSM。
②当模块处于PSM模式时，将关闭大部分连网活动，包括停止搜寻小区消息、小区重选等。但是T3412定时器（与周期性TAU更新相关）仍然继续工作。
③进入PSM后，网络端将不能寻呼模块，直到下次模块启动连网程序或TAU时，才能发起寻呼。
④模块有两种方式退出PSM，一种是DTE主动发送上行数据，模块退出PSM；另外一种是当T3412定时器超时后，TAU启动，模块退出PSM。
⑤注意区分两个定时器：T3324 定时器是定时进入PSM，T3412定时器是定时启动TAU。
-
eDRX（增强型不连续接收）技术：通过延长DRX时间，减少终端的DRX次数和频率，从而达到节电目的。
①eDRX可工作于空闲模式和连接模式。
②连接模式下，eDRX把接收间隔扩展至10.24秒。
③空闲模式下，eDRX将寻呼监测和TAU更新间隔扩展至超过40分钟。
④eDRX节电效果相比PSM差些，但它提高了下行通信链路的可到达性，较为适合保持长连接等的应用。
- 模块有两个串口：调试串口和主串口。
主串口：TXD（发送数据到DTE设备的RXD端）、RXD（从DTE设备TXD端接收数据）、RI（振铃提示）
调试串口：DBG_TXD（发送数据到DTE的串口）、DBG_RXD（从DTE的串口接收数据）
- 模块作为DCE，并按照传统的DCE-DTE方式连接。
- 主串口特点：
8个数据位，无奇偶校验，1停止位。
用于AT命令的发送。
支持波特率：9600、115200。
- 调试串口：
仅用于软件调试。
波特率为921600bps。
会自动向外面输出log信息。
log信息需要专门的软件抓取解析。
二. 来自“M5310-A AT使用流程实例”
- 模组上电初始化是模组进行正常数据通信业务之前的必须要步骤，在初始化中，模组将会完成网络搜索、驻网、附着等流程。
- 中移动模组上电初始化建议流程图：
- 目前M5310-A已支持Band3/Band5/Band8/Band20/Band28频段。模组本身支持自适应工作频段功能，也支持锁定频段功能。
锁频操作的串口指令（锁定 为 Band 5和 Band 8）：
AT+NBAND=5,8
- UDP连接测试：
AT+NSOCR="DGRAM",17,0,1 //创建一个socket（17是UDP的协议标号，0表示随机产生的本地socket编号）
AT+NSOST=0,183.230.40.158,5022,2,1024 //编号为0的socket向地址183.230.40.18的端口5022，发送2bytes数据，数据是1024
//创建socket时，最后一位设置为1时，模组会缓存接收到的数据。然后用下面命令，对socket 0中缓存区读4bytes数据
AT+NSORF=0,4
AT+NSOCL=0 //关闭socket 0
- TCP连接测试（失败）：
AT+NSOCR="STREAM",6,0,1 //创建一个socket（假设返回的是socket 0）
AT+NSOCO=0,183.230.40.158,5021 //连接到远程服务器（在这里失败，显示 +NSOCLI: 1，之后进行任何操作均为ERROR）
AT+NSOSD=0,2,3132 //发送数据
- 上面的查了一下，该返回值应该是说明该socket被关闭，需要重新开始流程。可能是连接错误或者超时。猜测应该是该开发板不支持TCP。（关系也不大，主要用的可能还是中移的OneNET平台，TCP可能不太用到）
三. 来自“M5310-A OneNET平台接入流程指导手册”
-
AT+MIPLCREATE
①作用：该指令用于在模组端（即M5310-A）创建一个通讯设备实体，同一时间一个终端只允许存在一个通讯设备主体。
②命令格式：AT+MIPLCREATE=<totalsize>,<config>,<index>,<currentsize>,<flag>
③参数解释：
a.totalsize：表示config 部分的长度，按ASCⅡ计数
b.config：具体的设备配置数据
c.index：配置数据分片参数
d.currentsize：当前分片部分数据长度
e.flag：配置数据流结束符
④使用例子：
AT+MIPLCREATE=49,130031F10003F2002304001100000000000000123138332E3233302E34302E34303A35363833000131F30008C000000000,0,49,0
（中间部分为注册码，所有同一类型的终端设备都可以使用同一个同一设备注册码进行配置）
⑤返回值：
（ref是设备实例ID，用于后续操作）
+MIPLCREAT:<ref>
OK
-
AT+MIPLDELETE
①作用：用于在模组端删除一个通讯设备实体
②命令格式：AT+MIPLCREATE=<ref>
-
AT+MIPLADDOBJ
①作用：用于在模组端添加一个待订阅的object及其所需的instance。
②命令格式：AT+MIPLADDOBJ=<ref>,<objid>,<inscount>,<bitmap>,<atts>,<acts>
③参数说明：
a. ref：设备实例ID
b. objid：Object ID
c. inscount：实例个数
d. bitmap：实例位图，字符串格式，每一个字符表示为一个实例，1表示可用，0表示不可用。
e. atts：属性个数，默认设置为0即可。
f. acts：操作个数，默认设置为0即可。
④使用例子：
AT+MIPLADDOBJ=0,3303,1,"1",1,0
AT+MIPLADDOBJ=0,3304,1,"1",1,0
-
AT+MIPLDELOBJ
①作用：用于删除一个已经订阅的object及其所属的instance。
②命令格式：AT+MIPLDELOBJ=<ref>,<objid>
-
AT+MIPLOPEN
①作用：用于在模组端向OneNET 平台发起注册登录请求。
②命令格式：AT+MIPLOPEN=<ref>,<lifetime>[,<timeout>]
③参数说明：
a. lifetime：本次注册平台的生命周期，单位是s
b. timeout：注册的超时时长，可选参数，默认为30，单位为s
④使用例子：
AT+MIPLOPEN=0,3000,30
-
AT+MIPLNOTIFY
①作用：用于在模组端向OneNET 平台上报指定资源的数据。
②命令格式：AT+MIPLNOTIFY=<ref>,<msgid>,<objid>,<insid>,<resid>,<type>,<len>,<value>,<index>,<flag>[,<ackid>]
③参数说明：
a. ref：设备实例ID
b. msgid：该resource所属的instance observe操作时下发的msgid
c. objid：Object ID
d. insid：Instance ID
e. resid：Resource ID
f. type：上报资源的数据类型（1-string，2-opaque，3-integer，4-float，5-bool，6-hex_str）
g. len：value值的长度
h. index：指令序号。可以发N条报文，从N-1到0降序编号，0表示本次Notify指令结束
i. value：上报数据。
j. flag：消息标识，指示第一条或中间或最后一条报文。
④使用例子：
AT+MIPLNOTIFY=0,0,3303,0,5700,4,4,"29.8",0,0
AT+MIPLNOTIFY=0,0,3304,0,5700,4,4,"29.8",0,0
-
AT+MIPLUPDATE
①作用：用于在模组端向OneNET平台发起设备存活时间更新请求。
②命令格式：AT+MIPLUPDATE=<ref>,<lifetime>,<withObjectFlag>
③参数说明：
a. ref：设备实例ID
b. lifetime：更新的lifetime值，单位是s
c. withObjectFlag：是否需要同时更新注册的Object对象
-
AT+MIPLCLOSE
①作用：用于在模组端向OneNET平台发起设备注销请求。
②命令格式：AT+MIPLCLOSE=<ref>
-
+MIPLREAD
①作用：（OneNET平台请求MCU读取消息）平台下发Read数据读取操作时，模组收到服务器请求后，将通过串口上报该消息到MCU。
②命令格式：+MIPLREAD=<ref>,<msgid>,<objid>,<insid>,<resid>
③参数说明：
a. ref：设备实例ID
b. msgid：消息ID
c. objid：Object ID
d. insid：Instance ID，-1时需要读取该Object下所有资源
e. resid：Resource ID，-1时需要读取该instance下的所有资源。
-
AT+MIPLREADRSP
①作用：MCU完成相应的Read操作后，向平台回复Read操作结果。
②命令格式：AT+MIPLREADRSP=<ref>,<msgid>,<result>[,<objid>,<insid>,<resid>,<type>,<len>,<value>,<index>,<flag>]
③参数说明：
a. result：1-读取操作正确完成；11-Bad Request；12-Unauthorized；13-Not Found；14-Method Not Allowed；15-Not Acceptable。
b. type：指定读取资源的数据类型，数字代表意义同上面的type。
c. len：value值的长度
-
+MIPLWRITE
①作用：（OneNET平台请求写数据到终端）模组收到平台下发的数据后，通过串口上报该消息。
②命令格式：+MIPLWRITE：<ref>,<msgid>,<objid>,<insid>,<resid>,<type>,<len>,<value>,<flag>,<index>
-
AT+MIPLWRITERSP
①作用：MCU完成相关Write操作后，向平台回复Write操作结果。
②命令格式：AT+MIPLWRITERSP=<ref>,<msgid>,<result>
-
+MIPLEXECUTE
①作用：平台下发Execute执行操作到模组，模组再通过串口上报给MCU。
②命令格式：+MIPLEXECUTE:<ref>,<msgid>,<objid>,<insid>,<resid>[,<len>,<cmd>]
③参数说明：
a. len：本次报文写入的命令长度
b. cmd：字符串类型，下发的命令
-
AT+MIPLEXECUTERSP
①作用：MCU执行完Execute操作后，向平台回复Execute操作结果。
②命令格式：AT+MIPLEXECUTERSP=<ref>,<msgid>,<result>
四. STM32控制测试
- 直接把命令发送到相应串口即可，使用比较方便。
- 注意可能存在一些命令如：AT+MIPLNOTIFY=0,0,3303,0,5700,4,4,"29.8",0,0
而串口函数一般也是传入字符串，这时候可能出现嵌套双引号问题。这种情况下，可以利用C语言的转义符，把里面一层的双引号前面加上\ 转义。
- 注意波特率、停止位、数据位的设置要和 M5310-A 一致，即波特率9600，停止位1，数据位8。
- 在测试时候，可以这样连线，方便调试：STM32的Tx -- M5310-A的Rx；M5310-A的Tx接电脑串口的Rx。
- 实际应用可能要把相应的操作封装为一个API，比较方便后续STM32的板上开发。
N. 杂七杂八的思考
- OneNET平台支持多种协议的接入，但实际上不管用什么协议，目的都是为了数据的传输，只是适用场景不同而已。如LWM2M（NB-IOT）、EDP、MQTT、HTTP、TCP等。
那么不管用什么协议，设备端和云端对数据做的无非还是类似于数据库的基本操作，增删查改，只是不同协议的API 存在一定差异。因此我要掌握的大概就是：硬件端怎么实现、应用端怎么实现这些增删查改的操作。
- 既然OneNET支持这么多种协议的接入，某种意义上好像就能实现所谓的统一，也和OneNET 的名称符合。但有个问题就是，采用OneNET的平台终究会存在一定的疑虑，例如中移物联网靠谱吗？相比起专门做云服务器的厂家来说稳定吗？
不过目前看来开发接入的便利性、和自由可控，两者好像只能选其一。要稳定、自由可控，可以选择类似阿里云、腾讯云的服务器，然后自己去完成相关的API编写，理论上也能实现“统一”，可如果仅仅以一人之力，现实吗？
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
