0

I have an obsolete control system that I am trying to write an interface into our new control system. I have spent weeks capturing data and figuring out the addressing, polling commands, point addressing and payload. I have everything figured out except on how to calculate the checksum on the packets. Below is a small sample of the data - I believe the first 2 bytes are the checksum, bytes 3/4 - address, bytes 5/6 - command, remaining bytes are the payload:

0e00 0801 1280 //to controller

0e20 //from controller

0e10 0801 1200 8010d00d9b0a19120a27375f01010412071f0e0a0512aa10495349474854000000000000000000000000000000000000000000001400ff0e0e00000000 //from controller

0e40 //to controller

0f00 0801 1285 //to controller

0f20 //from controller

0f10 0801 1200 0000000000000000000000000000000001010a0512aa105f1400ff //from controller

0f40 //to controller

1000 0801 1285 //to controller

1020 //from controller

1010 0801 1200 0000000000000000000000000000000001010a0512aa105f1400ff //from controller

The checksum appears to be out of order when viewing the data captures, but that is the order that it was captured in.

I don't know if it matters or not, but I am writing the interface in Java.

I appreciate any help that can be provided ... many thanks in advance.

Improve this question
2
  • What is the "control program" run on? Can you take its ROM and reverse engineer the program?
    – user202729
    Nov 4 '18 at 12:09
  • Thanks for the response Ian. The program runs on a Windows pc and I am recreating what I need to read / write the point values in an embedded pc with a custom java program. I do not have enough experience with this to do anything with the ROM (I just started learning about packet sniffing a few months ago).
    – ddctech
    Nov 4 '18 at 16:50
2

The first byte starts as 0E is then 0F and then 10. This looks something like a sequential message id, not part of a checksum.

The second byte has a pattern to it too and, taking into account the message lengths, I'd interpret it as follows -

00 => request to controller
20 => acknowledgement from controller of the request 
10 => response from controller
40 => acknowledgement to controller of the response
Improve this answer
2
  • That is a very interesting observation! The documentation states that a transaction consists of (4) data packets: Transmission packet, Acknowledge packet, Response packet and Response-Acknowledge packet.
    – ddctech
    Nov 4 '18 at 16:36
  • I broke down some previous captures along with new captures after restarting the database pc, and the pc appears to be managing those sequence numbers. Back in the early 90s, the manufacturer came out with a serial to tcp router that I am connecting to over tcp - I assumed that the 4 packets mentioned above were handled in the tcp message. I also made the assumption that they were encapsulating the original serial message in the tcp data packet (which they are), but it looks like I just have to sequence my response and not worry about the checksum! Thanks for your help!
    – ddctech
    Nov 4 '18 at 16:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.