CJ/T-188 冷热量表协议解析2

本文具体阐述JY公司冷热量表(记热量)传输协议,并以此说明CJ/T-188协议在厂家具体应用时,并不一致。本文及后续文章将对这些不同点予以总结(文中所述协议与日志“CJ/T-188
冷热量表协议解析1”http://user.qzone.qq.com/2756567163/blog/1437462157的不同之处,将用红色予以标识)。以下数据未经特殊说明,均指十六进制。

数据发送:

FE FE FE FE 68 20 32 41 31 40 00 00 00 01 03 90 1F 01 20 16

说明如下:

FE FE FE FE:协议头(1-4组)。

68:帧起始符。

20:仪表类型,此实例指热量表(记热量)。

32 41 31 40 00:倒序为0040314132(以BCD码形式看待),表示表号。

00 00:倒序为0000(以BCD码形式看待),表示厂家代码。

01:控制码表示读表计数据,后面跟固定数据域长度、数据标识和序列号。

03:数据域长度(固定)。

90 1F 01:数据标识和序列号(固定)。

20:累加和,从协议头68至序列号01累加之和。

16;结束符。

回复数据:

FE FE FE FE 68 20 32 41 31 40 00 00 00 81 2E 90 1F 01

00 01 02 03 04 05 06 07 08 09 10 11 12 13

08 02 00 00 00

14 15 16 17 18

08 02 00 00 00

19 20 21 22 23

17 00 00 00 00

24 25 26 27 28 
                                                                 35 00 00 00 00

29 30 31 32
33                                                         2C 34 10 00 00

34 35 36 37
38

35 25 00

39 40
41

66 25 00

42 43
44

00 00 00

45 46 47  
                                                                     53 00 12 10 07 15 20

48 49 50 51 52 53 54                                                                       00 00 31 16

55 56 57 58

说明如下:

FE FE FE FE:协议头(1-4组)。

68:帧起始符。

20:仪表类型。

32 41 31 40 00:倒序为0040314132(以BCD码形式看待),表示表号。

00 00:倒序为0000(以BCD码形式看待),表示厂家代码。

81:实际为控制码+80,我们可以简单认为只有81正确,非81均为异常,不进行解析。

2E:数据域长度,为十进制46,表示后面有46个有效数据。

1F 90 01:数据标识和序列号(固定)。

80 02 00 00 00:结算日热量(0.02-mwh),英文:settlement,序号:14-17。

80 02 00 00 00:当前热量(0.02-mwh),英文:nowheat,序号:19-22。

17 00 00 00 00:热功率(0.00-kw),英文:thermal,序号:24-27。

35 00 00 00 00:瞬时热量(0.00-mmm/h)英文:transient,序号:29-32。

2c 34 10 00 00:当前累计流量(10.34-mmm),英文:accumulate,序号:34-37。

35 25 00:供水温度(25.35-0C),英文:supply,序号:39-41。 (注1)

66 25 00:回水温度(25.66-0C),英文:return,序号:42-44。 (注1)

00 00 00:仪表累计工作时间(000000-h),英文:atime,序号:45-47。

53 00 12 10 07 15 20:实时时间,2015-07-10 12:00:53,英文:mtime,序号:48-54。

00 00:状态,两个字节,00 00表示正常,01 00表示欠压,英文:st,序号55-56。

31:累加和,从协议头68至状态字00累加之和。

16:结束符。

注1:此处为摄氏度符号,为了防止混淆,本文所有数值和单位之间加“-”,予以分隔。

注2:单位符号可查看日志:http://user.qzone.qq.com/2756567163/blog/1436472675

注3:为程序开发便捷,提供英文注解和序号标注。

注4:与日志“CJ/T-188 冷热量表协议解析1”http://user.qzone.qq.com/2756567163/blog/1437462157的不同之处,用红色予以标识。

原创性文章,转载请注明出处 http://user.qzone.qq.com/2756567163

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-11-12 16:15:56

CJ/T-188 冷热量表协议解析2的相关文章

经常使用传感器协议3:CJ/T-188 冷热量表协议解析2

????本文详细阐述JY公司冷热量表(记热量)传输协议.并以此说明CJ/T-188协议在厂家详细应用时,并不一致. 本文及兴许文章将对这些不同点予以总结(文中所述协议与日志"CJ/T-188 冷热量表协议解析1"http://user.qzone.qq.com/2756567163/blog/1437462157的不同之处,将用红色予以标识).下面数据未经特殊说明.均指十六进制. ????数据发送: ????????FE FE FE FE?68 20 32 41 31 40 00 00

CJ/T-188 冷热量表协议解析

本文以实例说明CJ/T-188水表协议的解析过程,以下数据未经特殊说明,均指十六进制. 数据发送: FE FE FE FE 68 20 44 33 22 11 00 33 78 01 03 1F 90 01 91 16 说明如下: FE FE FE FE:协议头(1-4组). 68:帧起始符. 20:仪表类型,此实例指冷水水表,还可定义为: 10:冷水水表 11:生活热水水表 12:直饮水水表 13:中水水表 20:热量表(记热量) 21:热量表(记冷量) 30:燃气表 40:电度表 44 33

经常使用传感器协议1:CJ/T-188 水表协议解析1

本文以实例说明CJ/T-188水表协议的解析过程,下面数据未经特殊说明,均指十六进制. 数据发送: FE FE FE FE 68 10 44 33 22 11 00 33 78 01 03 1F 90 00 80 16 说明例如以下: FE FE FE FE:协议头(1-4组). 68:帧起始符. 10:仪表类型,此实例指冷水水表.还可定义为: 10:冷水水表 11:生活热水水表 12:直饮水水表 13:中水水表 20:热量表(记热量) 21:热量表(记冷量) 30:燃气表 40:电度表 44

CJ/T-188 水表协议解析

本文以实例说明CJ/T-188水表协议的解析过程,以下数据未经特殊说明,均指十六进制. 数据发送: FE FE FE FE 68 10 44 33 22 11 00 33 78 01 03 1F 90 00 80 16 说明如下: FE FE FE FE:协议头(1-4组). 68:帧起始符. 10:仪表类型,此实例指冷水水表,还可定义为: 10:冷水水表 11:生活热水水表 12:直饮水水表 13:中水水表 20:热量表(记热量) 21:热量表(记冷量) 30:燃气表 40:电度表 44 33

twemproxyRedis协议解析探索——剖析twemproxy代码正编

这篇文章会对twemproxyRedis协议解析代码部分进行一番简单的分析,同时给出twemproxy目前支持的所有Redis命令.在这篇文章开始前,我想大家去简单地理解一下有限状态机,当然不理解也是没有问题的,有限状态机仅仅能帮助我们更好地理解twemproxyRedis协议解析代码部分. redis 协议 这边我们首先需要简单介绍一下redis协议.参考自https://redis.io/topics/protocol redis协议即RESP 的数据类型有5类,简单字符串.错误.整数.大字

SOCKS5 协议解析

意图 SOCKS5 是一个代理协议,旨在为位于 Intranet 防火墙后的用户提供访问 Internet 的代理服务(Intranet,你没听错,这是个有一定年头的协议,其 RFC 提案的时间比 HTTP 1.0 还要早两个月). 代理 根据 HTTP 1.1 的定义,proxy 是: An intermediary program which acts as both a server and a client for the purpose of making requests on be

视音频数据处理入门:UDP-RTP协议解析

===================================================== 视音频数据处理入门系列文章: 视音频数据处理入门:RGB.YUV像素数据处理 视音频数据处理入门:PCM音频采样数据处理 视音频数据处理入门:H.264视频码流解析 视音频数据处理入门:AAC音频码流解析 视音频数据处理入门:FLV封装格式解析 视音频数据处理入门:UDP-RTP协议解析 ===================================================

【wireshark】协议解析

1. 普通解析 Wireshark启动时,所有解析器进行初始化和注册.要注册的信息包括协议名称.各个字段的信息.过滤用的关键字.要关联的下层协议与端口(handoff)等.在解析过程,每个解析器负责解析自己的协议部分, 然后把上层封装数据传递给后续协议解析器,这样就构成一个完整的协议解析链条. 解析链条的最上端是Frame解析器,它负责解析pcap帧头.后续该调用哪个解析器,是通过上层协议注册handoff信息时写在当前协议的hash表来查找的. 例如,考虑ipv4解析器有一个hash表,里面存

通用轻量级二进制格式协议解析器

在通信协议中,经常碰到使用私有协议的场景,报文内容是肉眼无法直接看明白的二进制格式.由于协议的私有性质,即使大名鼎鼎的 Wireshark,要解析其内容,也无能为力. 面对这种情况,开发人员通常有两个办法:第一,对照报文内容和协议规范进行人工分析(假设内容没有经过加密.压缩):第二,编程实现协议报文的解析(源于程序员的懒惰 ^_^). 很明显,第二条道路是主流.目前比较常见的实现方式是开发对应的 Wireshark 插件,包括 C.Lua 等插件.当然,插件完成后需要运行 Wireshark 才