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 22 11 00:倒序为0011223344(以BCD码形式看待),表示表号。

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

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

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

1F 90:数据标识(固定)。

01:序列号(固定)。

91:累加和,68+20+44+33+22+11+00+33+78+01+03+1F+90+01=91。

16;结束符。

回复数据:

FE FE FE FE 68 20 44 33 22 11 00 33 78 81 2E 1F 90 01 78 56 34 12 05 78 56 34 12 05 78

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

56 34 12 17 78 56 34 12 35 78 56 34 12 2C 56 34 12 56 34 12 56 34 12 20 14 03 18 12 56 59 00 

25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55

00 91 16

56 57 58

说明如下:

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

68:帧起始符。

20:仪表类型。

44 33 22 11 00:倒序为0011223344(以BCD码形式看待),表示表号。

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

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

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

1F 90:数据标识(固定)。

01:序列号(固定)。

78 56 34 12 05:结算日热量(123456.78-kwh)。

78 56 34 12 05:当前热量(123456.78-kwh)。

78 56 34 12 17:热功率(123456.78-kw)。

78 56 34 12 35:瞬时热量(123456.78-mmm/h)。

78 56 34 12 2C:当前累计流量(123456.78-mmm)。

56 34 12:供水温度(1234.56-0C)。 (注1)

56 34 12:回水温度(1234.56-0C)。 (注1)

56 34 12:仪表累计工作时间(123456-h)。

20 14 03 18 12 56 59:当前日期,2014-03-18 12:56:59

00 00:状态,两个字节,00 00表示正常,01 00表示欠压。

91:累加和,68+20+44+33+22+11+00+33+78+81+2E+1F+90+01+78+56+34+12+05+78+56+34+12+05+78+56+34+12+17+78+56+34+12+35+78+56+34+12+2C+56+34+12+56+34+12+56+34+12+20+14+03+18+12+56+59+00+00=06。

16:结束符。

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

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

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

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

时间: 2024-11-10 00:18:09

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

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 0

经常使用传感器协议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

经常使用传感器协议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 才