我有一个电动自行车,它由一个调节电动机功率的控制器和一个智能LCD组成,该LCD可以调节最大速度,功率输出,踏板辅助灵敏度等,并显示当前的电池电压,电动机功率使用量(Watts)和电动机速度。
LCD和控制器通过5v rx / tx线连接。我在串行线路的中间串联了一个arduino mega。控制器rx / tx到arduino serial1 tx / rx,然后arduino serial2 tx / rx到LCD rx / tx。
代码当前正在将所有从控制器接收的数据直接传递到LCD,反之亦然,这非常有效,LCD值是的。

我希望分析该协议,但似乎无法找出其中的任何结构。目前专注于Controller-> LCD comms以提取电动机值。似乎所有命令都以02开头(AsciiTable中的文本开头),然后大多数都包含0E,我最初怀疑该长度是消息长度,但是从以下命令看来似乎不是这种情况:


02 0E 40 40 00 00 03 0B B8 00 00 35 C8
02 0E 01 00 40 00 00 03 0B 98 00 35 C8
02 4E 40 40 00 00 03 0B B8 88 54 42 F7
02 0E 41 00 0A 00 02 03 B8 00 00 35 C8
02 0E 01 00 50 00 D0 0B B8 00 00 05 FE

02 4E 40 40 00 00 03 0B B8 00 35 C8
02 4E 40 20 0A 00 03 0A B8 80 35 C8
02 4E 40 40 00 00 03 0B B8 88 54 42 F7
02 4E 40 08 01 00 03 0B DD 81 A0 93 FE FE FE



这里是运行约60秒的完整hexdump,消息不断传来:https://pastebin.com/iFFEWAFd
该转储将包含电池电压(45-52.4V),电动机功率使用(0-1000Watts,也可能是0-10Amps)以及车轮速度的值。可能还有其他一些参数。

命令


02 0E 01 00 40 00 00 03 0B B8 00 00 35 C8


是迄今为止最受欢迎的信息,占一半以上。
这里是没有该命令的同一粘贴,以便于阅读:https://pastebin.com/b5iQugaY

PDF LCD手册:www.pedecs.co .uk
至今尚未找到任何有关控制器的手册。

谢谢您提供的任何见解,我仍然对整个逆向工程有所了解。

更新: 。以前认为是心跳的命令实际上是速度0。这是自行车的转储,从19mph减速到0mph: 14正在改变。这些值并不直接对应于速度,而是更可能与RPM相关,因为当我手动更改期望的车轮尺寸值时,LCD会知道任何给定命令的车轮尺寸并显示速度变化。
字节9和10组合以输出0-3000之间的值。该值是车轮完全旋转之间的毫秒数,因此可以在已知周长的情况下计算速度。字节14似乎是某种形式的校验和,如果有人可以锻炼一下它的计算方式,它将很方便。

评论

您确定板上的MCU /闪存芯片了吗?重新安装固件可能会更容易

LCD是分段的还是位图/图形的?上面有任何标记吗?

@IgorSkochinsky进行了细分,在答案的末尾添加了指向手册的链接,您可以在其中查看布局。这是一个相当普通的中国液晶显示器。我假设我必须打开LCD机壳来识别闪存芯片?请稍等一下,但不确定在不破坏外壳的情况下能否进入

你有什么想法吗?如果您找到此传输方式转换为LCD的解码方式,请帮帮我吗?

#1 楼

我了解您的Arduino在控制器和LCD之间充当中继。您可以做些什么(不是很令人兴奋,但是您没有提到您是否已经进行了类似的实验,我希望我很好地了解了您的情况):


修改单个位。如果您目视观察显示并在Arduino上连接一个开关作为触发器,以在显示方向上修改一个或多个单个位,并观察哪个显示指示发生变化。
在相反方向上相同。观察自行车的行为是否发生变化。
抑制您的心跳电报并观察会发生什么情况。
一个简单的实验就是打开自行车的灯并观察电报中的变化。
添加时间戳记到您的电报。如果您在Arduino上安装了触发器,也要给它加上一个时间戳,以便在电报日志中有确切的更改时间。在自行车上或在电报或电报组中进行观察,并观察它是否为您提供有关内容的提示。和一些被动的嗅探器。我知道您信任您的解码器,因为一切都照常进行(两者之间没有Arduino)。但这可能仅是由于损坏的电报被丢弃的事实所致。

粗略检查您的日志显示不容易理解的属性。

示例:第133行和文件ebike_sw_hex_dump.txt中的#134(带有心跳的那个):

02 0E 01 00 40 00 00 03 0B B8 00 00 35 C8
02 0E 01 00 40 00 03 0B B8 00 00 35 C8


第二个电报与第一个电报相同,只是中间缺少零。特别是最后七个字节是相同的。如果我假设这两个电报的最后七个字节的逻辑内容相同,那么解释器应该如何得出这个结论?

“协议切换”可能是40之后的字节。但是,这与最后七个字节表示相同的假设相矛盾。

从此示例和其他奇怪的行中,例如对于那些以FE或FF结尾的文件,我建议对解码器进行独立的交叉检查,以确保您的日志显示正确的字节。与您所怀疑的类似,在这样的系统中,我也会期望恒定的电报长度。

当然,还有更多可以尝试的方法。这些只是想到的一些简单想法。

与您的实验类似的实验在https://endless-sphere.com/forums/viewtopic.php?f=2&t下发布在网上= 73471#p1109048,已附加解码协议,但是使用不同的控制器,并且与日志没有明显相似之处。但也许它也提供了一些提示。

无论如何,一个不错的研究!

评论


感谢您的建议,没有任何开关,但是可以尝试手动修改代码中的各个位。原来那些“心跳”消息实际上与速度有关,并在主要帖子中添加了更新。我将如何使用被动嗅探器执行交叉检查,这是否需要其他硬件?将不得不研究更多。至于消息的长度,我确实试图过滤掉出现时间太长的所有消息,但这只是导致LCD给出“无效的串行”错误代码。

–迈克
18年8月4日在17:06



校验和似乎是对所有先前字节的简单异或运算,从零开始。这适用于除第四个(校验和74)和第五个(校验和AE)以外的所有电报。您是否收到关于这些的错误消息?

–乔什
18年8月4日在21:44