Hello,
Newbie in this forum, I need some help with expert of protocol decoding frames.
Attached file is a Frame capture with a Saleae logic analyser. Some part of the Frame is clearly identified but
a CRC is calculated.
I try to fing how this CRC is calculated. I have tried the known CRC calculation but it is a homemade CRC formula.
If somebody has a genious idea even if there is thousand of solutions ....
The files is with different frames.
Thank you very much
THR_FORUM.zip (118 KB)
You need to post the files seperatly, most people wont take the risk of downloading ZIP files from an uknown source.
following
I guess you are trying to reverse-engineer the network protocol of some undocumented device, right?
Do you have any background context on the device at all? Is it communicating with a known peer, or with some proprietary software? What's the device doing? Maybe it's using a standard-ish protocol for the type of thing it's doing.
In terms of your work so far, you have marked up some of the packet as a header, a byte as CRC, and the remainder as data. How have you come to that conclusion? Any thoughts on the purpose of the byte after the consistent bytes in the header and before the byte highlighted as CRC? What CRC algorithms have you tried so far? Tried them on just the payload, or the payload + header?
Lots of questions 
but it'll help to give a bit more context I think.
Post text that can be cut and paste, not a picture of text.
The open source program RevEng works very well to reverse engineer CRC algorithms. You will need to give it three or four intact messages (after removing headers and start / stop markers) and tell it the size of the CRC checksum.
Hi,
Thank you for your interest for this Topic.
This frame is a part of many frames on a single wire serial communication for a RC turbine.
Many frames are identified to manage the all datas for the turbine but this is the only one which interest us because this is the telemetry datas. I know from the factory that the end of the frame are the datas and the length. So I have identified the header checking all frames. So one or two bytes could be the CRC. But all datas are also coded but to decode, I need first to find the CRC.
I will check the RevEng SW.
Thanks
THR_FORUM.txt (2.81 KB)
I suspect your CRC is actually 16 bits long and is column E and F together.
Paul
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.
