官方的开发人员在论坛里吗？我想请教下CDC升级时，每128字节后面跟的3字节数据是啥

duro***

官方的开发小哥哥小姐姐们，您们好啊！
我想请教一下cdc升级时，每发三个包（也就是128字节数据），后面跟了3个字节的校验码。

我想问下那3个字节的校验码是如何计算的呢？ 我看着像crc24，可是用crc24试了一下，发现计算出来的不对。
难道那3个字节不是crc24吗？

---------------------------------------------------
第1个包是 46b96a008b02 + 地址 + 5aa5 + 54字节数据
第2个包是64字节数据
第3个包是10字节数据 + 3字节校验码。（这里的3字节校验码是咋算出来的呢？）

duro***

还有最后的那个46b96a003304 命令和 46b96a0007ff 命令后面是啥数据呢？
46b96a0007ff后面是不是直接是3字节的校验码？

乘风***

你说的应该是这个吧

duro***

乘风*** 发表于 2024-9-3 09:41
你说的应该是这个吧

是这个。但是为啥用示例代码也计算出来也是不对的呢？ 那个示例里的算法提取出来应该是这样啊，但实测不对。
//46b96a00（4字节命令头） + 8b（1字节数据包长度）+ 02 （1字节命令字节）+ 命令参数 + 数据包校验和（2字节）+ 16（1字节）
46b96a008b02 + 0000 + 5aa5 + 数据 + 数据包校验和（2字节）+ 16（1字节）
uint16_t sum16(uint8_t* data, uint32_t size)
{
    uint32_t i;
    uint32_t sum = size + 6 + 0x6a;
    for (i=0; i<size; i++)
    {
        sum += data;
    }
    return (uint16_t)(sum & 0xffff);
}

duro***

hex的8行数据
1 020284cad8ca797d7374f87e70301202
2 6b74f87e708012026b1202c66cdd74fa
3 cab87af1827ae183e4937c7bdab81202
4 6b0b740bd0bed01078e474f87e709012
5 026b1202c66cdd74facab87af1827ae1
6 83e4937c7bdab812026b0b740bd0bed0
7 1078e474f87e708812026b1202c66cdd
8 74facab87af1827ae183e4937c7bdab8

拼接在一起是：

020284cad8ca797d7374f87e703012026b74f87e708012026b1202c66cdd74facab87af1827ae183e4937c7bdab812026b0b740bd0bed01078e474f87e709012026b1202c66cdd74facab87af1827ae183e4937c7bdab812026b0b740bd0bed01078e474f87e708812026b1202c66cdd74facab87af1827ae183e4937c7bdab8
去掉46b9 ，总共长度是272.
msg(272):6a008b0200005aa5020284cad8ca797d7374f87e703012026b74f87e708012026b1202c66cdd74facab87af1827ae183e4937c7bdab812026b0b740bd0bed01078e474f87e709012026b1202c66cdd74facab87af1827ae183e4937c7bdab812026b0b740bd0bed01078e474f87e708812026b1202c66cdd74facab87af1827ae183e4937c7bdab8
传给 uint16_t sum16(uint8_t* data, uint32_t size) 计算出来是 4A40，正确的值应该是 43bf  。

--------------------------
如果把这272字节的字符串转成136字节的ascii码，用uint16_t sum16(uint8_t* data, uint32_t size) 计算出来是44B7。  和43bf 也没关系啊，貌似。

长度是 32*8=256 + 16=272 也没错啊。

这是咋回事呢？算法更新了？文档没同步？

乘风***

duro*** 发表于 2024-9-3 16:50
hex的8行数据
1 020284cad8ca797d7374f87e70301202
2 6b74f87e708012026b1202c66cdd74fa

你提供的数据看起来还不够完整，看看前面截图的规格书通信协议。
46 B9 6A 00 后面跟随的是数据包长度，你提供的数据里面是“8B”也就是除去46 B9应该还有139字节数据，以 16H 结尾。

duro***

:10000000020284CAD8CA797D7374F87E70301202F5
:100010006B74F87E708012026B1202C66CDD74FA8B
:10002000CAB87AF1827AE183E4937C7BDAB812026F
:100030006B0B740BD0BED01078E474F87E70901205
:10004000026B1202C66CDD74FACAB87AF1827AE1E8
:1000500083E4937C7BDAB812026B0B740BD0BED0B6
:100060001078E474F87E708812026B1202C66CDDA0
:1000700074FACAB87AF1827AE183E4937C7BDAB8C5

dump_data91 DATA : 136
6A008B0200005AA5
020284CAD8CA797D7374F87E70301202
6B74F87E708012026B1202C66CDD74FA
CAB87AF1827AE183E4937C7BDAB81202
6B0B740BD0BED01078E474F87E709012
026B1202C66CDD74FACAB87AF1827AE1
83E4937C7BDAB812026B0B740BD0BED0
1078E474F87E708812026B1202C66CDD
74FACAB87AF1827AE183E4937C7BDAB8
dump_data
44B7
其实正确的是不是44B7，而是43bf。

其实并没有少数据，

    data.push_back("46b96a008b0200005aa5020284cad8ca797d7374f87e703012026b74f87e708012026b1202c66cdd74facab87af1827ae183e4937c7bdab812026b0b740bd0be");
    data.push_back("d01078e474f87e709012026b1202c66cdd74facab87af1827ae183e4937c7bdab812026b0b740bd0bed01078e474f87e708812026b1202c66cdd74facab87af1");
    data.push_back("827ae183e4937c7bdab843bf16000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000");


我自己构造的包是可以升级成功的。

duro***

乘风*** 发表于 2024-9-3 17:46
你提供的数据看起来还不够完整，看看前面截图的规格书通信协议。
46 B9 6A 00 后面跟随的是数据包长度， ...

   哦，发送包的流程我搞定了。
   文档我反复看了又看，还是没看懂最后这个包是做啥的呢？

   bin文件数据包发送完后，正常情况下，后面还发了一个包，这个包是做啥的呢？ 有很多ff，但是又不全是ff。
    46b96a00330400005aa5ffffff00ffff00ffffffffffffffffffffffffffffff00ff016e3600462001ffffff3e3fbfaff7001d76160000000000000000000000
    46b96a0007ff01701600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

duro***

duro*** 发表于 2024-9-3 22:22
哦，发送包的流程我搞定了。
   文档我反复看了又看，还是没看懂最后这个包是做啥的呢？

目前我怀疑这个包是让设备重启的。不过这个应该也是有部分数据是动态变化的，也就是说hex的内容有一定关系。具体的还没弄清楚。其实不发这个应该也是可以的。只是发完数据后，需要手动重启。