GPRS模块做通信协议时，数据类型的选择？

lklhzu · 发表于 2014-1-16 17:58:55

本帖最后由 lklhzu 于 2014-1-16 18:14 编辑

大家在用GPRS模块做通信发送接收数据时，协议的数据帧大家一般是用字符串还是十六进制？
用字符串的话，一般取特殊字符作为帧头、帧尾。用十六进制的话，一般采用多个字节作为引导码和结尾。
哪种更方便些？

solojimes · 发表于 2014-1-16 18:12:37

我觉得 hex比较好否则你服务器端解码还是挺麻烦的

lklhzu · 发表于 2014-1-16 18:45:18

本帖最后由 lklhzu 于 2014-1-16 18:49 编辑

solojimes 发表于 2014-1-16 18:12
我觉得 hex比较好否则你服务器端解码还是挺麻烦的

当数据包里面既有字符串数据，又有十进制数据时，转换成十六进制后有可能和帧头、帧尾重复，单片机里面按照帧头和帧尾接收数据时，可能会误判，感觉不如字符串的灵活。

solojimes · 发表于 2014-1-16 18:52:05

那是你协议的问题我用的协议不会存在这种问题

奮闘ing · 发表于 2014-1-16 19:34:08

十六进制方便，规定好协议后，直接发送和接收即可

fcgmqty · 发表于 2014-1-16 19:34:24

建议用多个头一个尾，十六进制，如0xAA,0X55,0XE7,0X18,作头 ……数据区……，+校验位作尾，这样中间多少数据也没问题，我一直用合计50个字节的。

dreampet · 发表于 2014-1-16 19:36:14

lklhzu 发表于 2014-1-16 18:45
当数据包里面既有字符串数据，又有十进制数据时，转换成十六进制后有可能和帧头、帧尾重复，单片机里面按 ...

这个是协议没定好，最简单的处理就是做下转义。

dadongleilei · 发表于 2014-1-17 08:54:14

还是十六进制好，而且也节约传输的数据流量，具体的协议标准可以参考电力上的一些规约，帧头、长度、控制字、数据、校验、帧尾，这样几帧连在一起也可以正常解析

windboy · 发表于 2014-1-17 08:57:39

你那根本就不叫协议，你的什么头，尾，如果数据区里有你一样的数据呢？

你根本没有明白什么叫协议

lklhzu · 发表于 2014-1-17 17:33:43

dadongleilei 发表于 2014-1-17 08:54
还是十六进制好，而且也节约传输的数据流量，具体的协议标准可以参考电力上的一些规约，帧头、长度、控制字 ...

能否给个例子，你的数据里面不会出现和帧头、帧尾重复的字节吗?你是根据帧尾来判断一帧数据接收完毕吗？

lklhzu · 发表于 2014-1-17 17:34:18

fcgmqty 发表于 2014-1-16 19:34
建议用多个头一个尾，十六进制，如0xAA,0X55,0XE7,0X18,作头 ……数据区……，+校验位作尾，这样中间多 ...

能否给个例子，你的数据里面不会出现和帧头、帧尾重复的字节吗?你是根据帧尾来判断一帧数据接收完毕吗？

lklhzu · 发表于 2014-1-17 17:37:14

windboy 发表于 2014-1-17 08:57
你那根本就不叫协议，你的什么头，尾，如果数据区里有你一样的数据呢？

你根本没有明白什么叫协议

请详细讲解下怎么定制协议可以吗？看到大部分设备都是规定好帧头、帧尾，中间是数据的啊！

rcdny123 · 发表于 2014-1-17 19:05:46

mark

windboy · 发表于 2014-1-17 20:48:04

lklhzu 发表于 2014-1-17 17:33
能否给个例子，你的数据里面不会出现和帧头、帧尾重复的字节吗?你是根据帧尾来判断一帧数据接收完毕吗？ ...

比如格式：
帧头指令数据长度状态数据区校验帧尾

其中要有转议码，将除帧头帧尾的数据进行转义，防止数据区中出现帧头帧尾

ludikn · 发表于 2014-1-17 20:54:59

最好用十六进制，可以传输的数据量比字符多，当然，字符直观些。包头包尾未必需要，当然有最好，方便服务器解析，且不怕网络连包。没有固定包头包尾的，要约定好格式，注意网络连包的情况。

xukai871105 · 发表于 2014-1-17 23:55:15

我觉得如果是GPRS向固定IP的服务器上传数据的话，我觉得可以选择字符协议
使用TCP通信，GPRS端就当HTTPClient，向服务器端发送请求，可以是POST请求（插入数据）或者是GET请求获得数据
资源的描述可以采用符合RESTFul风格的URI，例如example.com/sensor/{sensor_id}

请求或推送的格式可以这样设计
POST /example.com/sensor/{sensor_id} HTTP/1.1
Host: example.com
Accept: */*
Content-Length: XX
Content-Type: application/x-www-form-urlencoded

{"value":12.3}

表面上看上去真的是够复杂的，多啰嗦啊。

但是在WEB侧或者说服务器侧，有很多的框架来处理这个提交的内容，例如PHP的Slim，python的Flask。
web服务器，例如apache会帮你处理所有的HTTP请求，简单方便。
相对于协议来说，基于RESTFul，内容参考JSON格式，解析起来也方便，可利用PHP或者python的库
至于协议的帧头和协议内容长度等，全部有TCP协议规定，你根本就不需要管。

如果是一个HEX协议的话，WEB侧的程序员会疯的。（你自己定义的协议，一定会被各路大神改来该去，最后只能重构了，但是JSON描述就灵活一些）
如果是一个RESTFul+JSON的协议的话，或者大家都会感动的流泪。

给你写建议你可以参考一下。

AWEN2000 · 发表于 2014-1-18 07:34:38

8楼：
数据区当然可能出现与包头字节一样的数据，但不会有影响的。
一般协议会定义包数据区长度，校校验，这些配合起来就可以排除误判
字符传输太费字节了，服务器端也不见得方便。
gprs数据采集应用，服务器端不可能用web直接解析数据的。
一般会有一个数据处理程序或任务专门解析，16进制、字符都一样，16进制更方便不需要转来转去

dadongleilei · 发表于 2014-1-18 10:57:18

给你看个国家电网的一个帧格式
帧格式
　　帧是传送信息的基本单元。帧格式如图 8 所示。
说明代码
帧起始符 68H
地址域 A0
A1
A2
A3
A4
A5
帧起始符 68H
控制码 C
数据域长度 L
数据域 DATA
校验码 CS
结束符 16H
帧格式

fcgmqty · 发表于 2014-1-18 15:39:28

帧头一定要有，以确定开始接收。以尾来确定结束，但如果协议长度是一个固定的  则可以没有尾  按个数来确定结束。
例子：空调内外机通信协议：
室内机发时  0xaa+发送者地址）0xFF+0x01接收者地址+16个字节的数据+校验位（数据加和或者CRC校验）
室外机回时  0Xaa+发送者地址0x01+0XFF接收者地址+16个字节的数据+校验位（数据加和或者CRC校验）

看两个地址就知道哪个发给哪个的，根据头来确定开始收，根据尾来确定结束。
16个数据内容分别是  运行模式  设定温度当前温度等

fcgmqty · 发表于 2014-1-18 15:44:17

可以找一下GPS通信协议：

GPS 数据格式
GPRMC（建议使用最小GPS数据格式）

$GPRMC,<1>,<2>,<3>,<4>,<5>,<6>,<7>,<8>,<9>,<10>,<11><CR><LF>
1) 标准定位时间（UTC time）格式：时时分分秒秒.秒秒秒（hhmmss.sss）。
2) 定位状态，A = 数据可用，V = 数据不可用。
3) 纬度，格式：度度分分.分分分分（ddmm.mmmm）。
4) 纬度区分，北半球（N）或南半球（S）。
5) 经度，格式：度度分分.分分分分。
6) 经度区分，东（E）半球或西（W）半球。
7) 相对位移速度， 0.0 至 1851.8 knots
8) 相对位移方向，000.0 至 359.9度。实际值。
9) 日期，格式：日日月月年年（ddmmyy）。
10) 磁极变量，000.0 至180.0。
11) 度数。
12) Checksum.(检查位)

lklhzu · 发表于 2014-1-22 10:57:02

windboy 发表于 2014-1-17 20:48
比如格式：
帧头指令数据长度状态数据区校验帧尾

好的，谢谢你。之前用过一个设备，他帧里面会指定命令类型和数据长度，没做转义，一直用，没出过问题，正在借鉴它的。

lklhzu · 发表于 2014-1-22 10:57:49

ludikn 发表于 2014-1-17 20:54
最好用十六进制，可以传输的数据量比字符多，当然，字符直观些。包头包尾未必需要，当然有最好，方便服务器 ...

好的，谢谢啦。

lklhzu · 发表于 2014-1-22 10:59:18

dadongleilei 发表于 2014-1-18 10:57
给你看个国家电网的一个帧格式
帧格式
　　帧是传送信息的基本单元。帧格式如图 8 所示。

谢谢啦，国电的帧头就一个啊。我看有的用到了多个字节帧头，这样是不是更可靠。

lklhzu · 发表于 2014-1-22 11:02:26

fcgmqty 发表于 2014-1-18 15:39
帧头一定要有，以确定开始接收。以尾来确定结束，但如果协议长度是一个固定的则可以没有尾按个数来 ...

谢谢你，空调的、GPS的，你懂得真多啊！帧头一般在串口中断里面判断？还是串口中断只负责往接收缓冲丢数据，在主函数里面判断？

lklhzu · 发表于 2014-1-22 11:22:10

http://bbs.21ic.com/icview-335189-1-1.html
这个帖子写的不错，大家可以参考下。

lklhzu · 发表于 2014-1-22 11:29:29

1、帧头+地址+命令字+数据长度+数据区+校验+帧尾
2、帧头+数据长度+命令字+数据区（含地址）+校验+帧尾
3、帧头+命令字+数据长度+数据区（含地址）+校验+帧尾
整理了几种数据帧类型，让大家参考！

unifax001 · 发表于 2014-1-22 15:38:09

帧头+目的地址+本机地址+第一参数+第二数据长度+第二参数+校验+帧尾

其中帧头（3个字节）是为了同步用的大家收到后都会进行判断下一自己开始的数据是不是自己的地址，然后进行处理
目的地址有三种类型（2个字节），第一是本机地址：通常来自eeprom或者拨码开关，一般设置2个字节，高字节固定是一类设备相同，低字节地址来自拨码开关或者eeprom
第二是组播地址：一般是本机地址|0x00ff得来也就说说高字节相同，低字节为0xff的，往这种地址里发数据同类设备都会接收到的，一般用于同类设备集体操作，省的轮询
第三是广播地址：定为0xffff，往这地址发数据总线上所有的都能收到，一般用于集体操作，比如复位
本机地址实际是源地址，目标收到数据会知道是谁发给他的。在多机自由通讯里面很用用处
后面的不说了，大概就是这样，应用多年，没出啥问题的

lklhzu · 发表于 2014-1-22 16:21:45

unifax001 发表于 2014-1-22 15:38
帧头+目的地址+本机地址+第一参数+第二数据长度+第二参数+校验+帧尾

其中帧头（3个字节）是为了同步用的 ...

说的很详细，多谢了！

xukai871105 · 发表于 2014-1-22 22:00:00

跟踪了这个帖子有段时间了，我也认真看了各位的回复。
红外我没有做过，不清楚。智能电表做过，GPS做过，modbus-rtu精通，modbus-tcp熟悉。

对于楼主的应用，通过GPRS传输数据，自然涉及到传输协议。我想你一定借助GPRS模块内部的TCP或者UDP部分。

所谓自己定义的协议，无外乎，数据包开头，数据包长度，源地址和目标地址，校验和等，请问TCP和UDP首部哪一个没有定义好的。

如果是串口协议，楼上各位的方案没的说。但是楼主借助了GPRS模块，借助了TCP或者UDP，数据包在公网中走了一圈。
就可以有效的利用这些“设备”（TCP协议）完成你的工作，而不用再去想数据包开头或者数据包长度等内容。

如何描述资源可以设计漂亮的URI，数据包的内容可采用JSON格式。

服务器侧接收到数据包，根据URI定位资源，JSON序列化之后，一切都容易搞定。你会发现这些多可靠灵活的框架可以使用，这么多的库完成了自己写的重复代码。

个人意见，仅供参考。

lklhzu · 发表于 2014-1-23 08:43:17

xukai871105 发表于 2014-1-22 22:00
跟踪了这个帖子有段时间了，我也认真看了各位的回复。
红外我没有做过，不清楚。智能电表做过，GPS做过，mo ...

看了你的回复，有很多词不明白，感觉你主要是做上位机的吧，我主要做硬件。之前我用字符串做数据传输，取特殊字符（例如：$、%、#等）做帧头和帧尾。现在把协议改为HEX，数据中有可能会出现和帧头、帧尾相同的字节，看了大家的回复，总结了下当出现这种问题时要么做转义处理，要么在包里指定数据长度，根据长度接收。特定的数据帧格式（即协议）有必要制定的，方便硬件接收上位机发来的数据，也方便服务器解析硬件发去的数据。

AWEN2000 · 发表于 2014-1-23 09:00:46

本帖最后由 AWEN2000 于 2014-1-23 09:04 编辑

lklhzu 发表于 2014-1-23 08:43
看了你的回复，有很多词不明白，感觉你主要是做上位机的吧，我主要做硬件。之前我用字符串做数据传输，取 ...

不需要指定长度的，协议最好做变长度的

一般协议结构差不多
包头+地址+命令字+数据长度+数据区+校验字+包尾
包头可以是多字节的

数据区很可能会出现与包头一样的数据，这个没关系的。

数据长度、校验字、包尾足以判断是否是完整的、正确的数据帧，不会出现误判的。
如果包头采用多字节，特定的数据比如 AA 55 AA 55 AA 55之类，数据区出现包头的概率很低很低

服务器程序对数据缓冲区进行不断的查找包头，找到包头再判断数据长度、包尾、校验，如果不符合，指针移动下再重复查找

如果采用字符方式，转义字会让上位机解析很痛苦的。

lklhzu · 发表于 2014-1-23 09:09:15

AWEN2000 发表于 2014-1-23 09:00
不需要指定长度的，协议最好做变长度的

一般协议结构差不多

请教你下：
1、对帧头的判断是在串口接收中断中？还是在主函数中？
2、一帧数据的接收完成，是通过超时判断？还是根据数据长度和帧尾判断？

AWEN2000 · 发表于 2014-1-23 09:18:09

本帖最后由 AWEN2000 于 2014-1-23 09:27 编辑

lklhzu 发表于 2014-1-23 09:09
请教你下：
1、对帧头的判断是在串口接收中断中？还是在主函数中？
2、一帧数据的接收完成，是通过超时判 ...

在单片机里
1、数据处理当然是在主函数里
串口中断里怎么可以去处理呢？中断服务时间越短越好，免得影响其他中断。
串口接收中断接收任务就是把接收到的数据放到通讯缓冲区，其他不用干
主函数或者任务里对缓冲区进行处理，来得及的。
2、串口通讯，一幁数据接收完成判断。有很多办法的。
简单一点就借用MODBUS的方式，串口中断空闲一定时间（几个字节的传输时间）就认为上位机发送完毕。因为上位机发送数据帧肯定是连续发的。
也可以不用管他有没有发送完毕，定期解析数据区（设大）。解析到完整数据帧清掉这幁数据继续处理。这样的好处是，当通讯任务被延迟了，不影响接收处理

服务器接收GPRS的数据，也是先把数据放到缓冲区里。数据处理任务慢慢处理，这样的好处是不会丢数据。
如果边接收边处理，有可能会丢数据的

3、不要在中断里判断包头、长度，很容易出差错的
先把数据接收下来慢慢处理。整个一串数据来综合判断

lklhzu · 发表于 2014-1-23 09:35:34

嗯，谢谢你详细的解答。我现在用单片机和GPRS模块通信，既要检测模块的AT指令返回值（字符串格式），又要检测服务器通过GPRS模块发来的数据（HEX类型的数据帧格式），相当于一个串口判断两种协议，有点无从下手的感觉。

lklhzu · 发表于 2014-1-23 09:36:34

AWEN2000 发表于 2014-1-23 09:18
在单片机里
1、数据处理当然是在主函数里
串口中断里怎么可以去处理呢？中断服务时间越短越好，免得影响 ...

嗯，谢谢你详细的解答。我现在用单片机和GPRS模块通信，既要检测模块的AT指令返回值（字符串格式），又要检测服务器通过GPRS模块发来的数据（HEX类型的数据帧格式），相当于一个串口判断两种协议，有点无从下手的感觉。

AWEN2000 · 发表于 2014-1-23 09:41:07

检测AT指令和HEX数据肯定是切换的
检测AT时，切换到命令模式

要不你不用透明传输，服务器发过来的数据也是AT方式的（SIMCOM模块）

lklhzu · 发表于 2014-1-23 09:49:53

AWEN2000 发表于 2014-1-23 09:41
检测AT指令和HEX数据肯定是切换的
检测AT时，切换到命令模式

我现在没有切换，又没用透传，而是设置指令“AT+CIPHEAD=1”，这样服务器发来数据时，模块会返回+IPD,XX:XXXX，通过检测“+IPD”来判断数据类型。请问你说的切换是要制定两种解析协议吗，来不同的数据时，用不同的协议解析？

AWEN2000 · 发表于 2014-1-23 09:52:53

我也跟你一样的，没有切换到透明
在数据缓冲区查找+IPD,XX 把数据取出来，转换成HEX再解析

lklhzu · 发表于 2014-1-23 09:59:13

AWEN2000 发表于 2014-1-23 09:52
我也跟你一样的，没有切换到透明
在数据缓冲区查找+IPD,XX 把数据取出来，转换成HEX再解析 ...

，可否加下我企鹅：2531597244，以后有问题向你请教。

xukai871105 · 发表于 2014-1-24 08:40:26

lklhzu 发表于 2014-1-23 08:43
看了你的回复，有很多词不明白，感觉你主要是做上位机的吧，我主要做硬件。之前我用字符串做数据传输，取 ...

呵呵，我是做嵌入式的，确切的说是嵌入式软件。

以前我也不明白，后来认真分析了URI，RESTFUL之后我明白了

在github上翻阅了很多代码，很有感触。
在编程技巧上面，国内和国外几乎没有差距，但是在协议和框架理解上面，国内和国外差距很大。
这些“软”的东西其实也是不可忽略的部分。

呵呵，不多啰嗦了！我自己明白就好了，以后大家都会明白的！

yayagepei · 发表于 2014-1-24 09:09:41

标记一下，最近会用到这个

macaroni · 发表于 2014-1-24 10:01:52

ASCII!!!!!!!!!!

chencc8 · 发表于 2014-4-1 12:03:00

之前使用在下位机使用HTTP协议通过GPRS模块在HTTP头后将HEX数据发送到服务器上，结果服务器上解析出来的数据大于7F的数据都被解析成0x3F
没办法只好用字符串了

zhcj66 · 发表于 2015-5-4 21:19:11

windboy 发表于 2014-1-17 20:48
比如格式：
帧头指令数据长度状态数据区校验帧尾

最近在研究，网络这块，学习了，mark

dz46316740 · 发表于 2015-5-10 18:25:53

应该是ASCII码；

大概能理解楼主的意思，因为如果用AT命令来操作的话，存在一个问题，就是命令返回的状态，以及从远端传来的数据都是ASCII码，就是从接收串口收到的串可能是一个命令返回状态（这种情况比较好处理，但是如果是一个异常状态，它和收到数据的情况没有太大不同，要自己做检测来区分）或者是数据，比较混乱；

自己发送数据时有两种方式，ASCII码，和hex，但实际上hex并不能发送所有的数据，因为有一些特殊字符是用作模块的控制字符，这些控制字符你就没法发送，比如结束符，所以hex发送数据不能是任意的数据，如果你能确定你发送的数据不包含特定的控制字符，那么你可以用这种方式，但是我相信大部分场合你都不能确定要发送什么样的数据，或者说数据可能是任意的，这种方式就不行，所以hex这种模式是缺乏通用性的；

ascii码并不会降低GPRS速度，它只是降低了串口速度而以，除非你的模块无线端的数据速度大于模块的接口（通常是串口）速度，那确实ascii码要比hex慢一倍；

如果用PPP拨号应该就不存在这种问题了；不过这时使用的TCPIP协议栈就不是模块的了，而要在MCU这边实现；

chenxujiaoyang · 发表于 2015-5-10 18:29:42

无非就是字符流（文本格式）或者字节流（二进制格式）两种区别，所谓的十进制、十六进制那都是你在程序中的表现形式而已！

meirenai · 发表于 2015-5-10 23:40:22

本帖最后由 meirenai 于 2015-5-10 23:44 编辑

完全可以封装成一个http请求，通过url和json直接来处理请求，前提是楼主的数据量比较小不要超过一帧http协议，太长的话就要考虑分包问题啦，这样，上下位机编程都比较方便。

meirenai · 发表于 2015-5-10 23:46:03

xukai871105 发表于 2014-1-24 08:40
呵呵，我是做嵌入式的，确切的说是嵌入式软件。

以前我也不明白，后来认真分析了URI，RESTFUL之后我明白 ...

我也答了一下，博主看看我理解的对不。

xukai871105 · 发表于 2015-5-12 08:34:25

meirenai 发表于 2015-5-10 23:40
完全可以封装成一个http请求，通过url和json直接来处理请求，前提是楼主的数据量比较小不要超过一帧http协 ...

主要是大家还没有在嵌入式领域使用过HTTP，虽然论坛里面的电工每时每刻都在使用Http，但是却不太清楚在嵌入式设备中如何使用。

如果想利用效率更高一点的话，可以使用CoAP协议，那么协议的header部分可以节约不少。
如果觉得JSON格式比较啰嗦的话，可以尝试二进制JSON格式，CBOR。

youkebing · 发表于 2015-5-12 08:42:57

xukai871105 发表于 2015-5-12 08:34
主要是大家还没有在嵌入式领域使用过HTTP，虽然论坛里面的电工每时每刻都在使用Http，但是却不太清楚在嵌 ...

个人觉得http是相对最好的一个方式，如果觉得耗费资源较多，那么可以采用TLV的方式编码，这个也是非常好的

kevin_me · 发表于 2015-5-12 10:17:47

本帖最后由 kevin_me 于 2015-5-12 10:22 编辑

xukai871105 发表于 2015-5-12 08:34
主要是大家还没有在嵌入式领域使用过HTTP，虽然论坛里面的电工每时每刻都在使用Http，但是却不太清楚在嵌 ...

你说的JOSN我怎么听都没听说过?

你这些知识从哪里获取的？指点一下。

我最近也在用SIM908基于GPRS做无线远传，还要使用北斗。现在也到了定协议的时候。

添加：

我软件同事，使用google ProtoBuf，这个用来做协议怎么样？

xukai871105 · 发表于 2015-5-13 12:58:16

kevin_me 发表于 2015-5-12 10:17
你说的JOSN我怎么听都没听说过?

你这些知识从哪里获取的？指点一下。

JSON格式
这些东西慢慢积累就可以了，最近可能会花点时间研究一下CBOR（二进制JSON格式）

ProtoBuf 倒真没有使用过！

casn · 发表于 2017-11-4 23:53:07

xukai871105 发表于 2015-5-13 12:58
JSON格式
这些东西慢慢积累就可以了，最近可能会花点时间研究一下CBOR（二进制JSON格式）

你好！你说的一些协议是建立在嵌入式设备能上公网的前提下的吧？说直接点，就是这些设备都带有LAN口，它可以嵌入TCP/IP的简易版，在此之上应用CoAP（udp），或者MQTT（tcp）等等，可以这样理解吗？如果是这样的，那么服务端只要有对应的服务解析处理，就能够无损的得到嵌入式传上来的数据了。

但是，楼主说的和你说的情况有区别吧，通过gprs模块传上来的是裸数据，这些裸数据不管是通过tcp还是udp传上来的，它包含了从各种工业设备中采集上来的数据，要解析出这些数据，肯定是要自己定义帧结构的，这里面就涉及到了帧头帧尾等等信息和转义概念，没有标准可以借鉴。说白了，如果按照CoAP还是MQTT协议规则自己写一个变种，也一样能把数据传到服务端。主要还是服务端怎么能够更方便地解析出数据，你说到的json的二进制方式，倒是可以考虑一下。

GPRS模块做通信协议时，数据类型的选择？

阿莫论坛20周年了！感谢大家的支持与爱护！！