Electronic – How to decipher hex code for time data on an older serial port device

hexreverse-engineeringserial

I’m using an old Draeger PAC III sensor to measure gas concentrations, with the goal of remotely transmitting the data via Arduino. Accordingly, I cannot use the proprietary software to output the system information/data. Even though the system has been “retired” by the company and is no longer sold/distributed, their technicians will not provide the datasheet for communication on the device.

To circumvent this, I’m attempting to use a serial port monitor to read the com between the device and PC. The PC communicates through a RS-232 port, but uses only ground and a combined Tx/Rx line to get data from the device. To activate communications, all written data starts with a high (01). All read data duplicates the written data, then tacks on device data. The first command is always 'initiate communications by identification' aka the first 4 chunks of data. I can only assume the remaining data communicates time, but I don’t understand how to decipher it. If endian is used/needed, how can I do this? Thank you in advance!

According to the proprietary program’s reported values:

  • Time (probably 24 hr clock): 1:13
  • Date (mm/dd/yyyy): 4/9/2008
  • Serial Number: ERXL-0162
  • Part Number: 4530011
  • Software Version: v3.50
[03/08/2019 16:44:22] Written data (COM4)   
    01 01 01 02 00 05                                          ......           
[03/08/2019 16:44:22] Read data (COM4)  
    01 01 01 02 00 05 01 01 01 26 02 34 35 33 30 30     .........&.45300    
    31 31 20 20 20 45 52 58 4c 2d 30 31 36 32 20 20     11   ERXL-0162      
    20 20 34 35 33 30 32 37 30 76 33 2e 35 30 07 3b         4530270v3.50.;  
[03/08/2019 16:44:23] Written data (COM4)   
    01 01 01 02 00 05                                             ......            
[03/08/2019 16:44:23] Read data (COM4)  
    01 01 01 02 00 05 01 01 01 26 02 34 35 33 30 30     .........&.45300    
    31 31 20 20 20 45 52 58 4c 2d 30 31 36 32 20 20     11   ERXL-0162      
    20 20 34 35 33 30 32 37 30 76 33 2e 35 30 07 3b         4530270v3.50.;  
[03/08/2019 16:44:23] Written data (COM4)   
    01 01 02 02 00 06                                       ......              
[03/08/2019 16:44:23] Read data (COM4)  
    01 01 02 02 00 06 01 01 02 07 89 28 01 0d 38 01     ..........‰(..8.    
    02                                                  .                   
[03/08/2019 16:44:23] - Close port COM4

Edit: Two more time stamps as requested

Time: 1:02 4/9/2008
[03/08/2019 20:04:30] Read data (COM4)  
    01 01 02 02 00 06 01 01 02 07 89 28 01 02 28 00   ..........‰(..(.  
    e7                                                ç                 
Time: 1:04 4/9/2008
[03/08/2019 20:05:50] Read data (COM4)  
    01 01 02 02 00 06 01 01 02 07 89 28 01 04 00 00   ..........‰(....  
    c1                                                Á

Best Answer

Here's a hypothesis of the time part of the data:

  • From the original data capture: 01 0d 38 01 02

    We know the time was shown as 01:13. That's the 01 0d and I believe the next byte 38 is likely the seconds value, but that is not displayed.

    I am considering that the last 2 bytes on each "packet" sent from the device may be a checksum (it's a common approach). That explains why the last 2 bytes of the first two packets are the same (07 3b) - since the data in both packets is the same. Then the next packet (the first data & time example) has different values for the last 2 bytes.

  • From one of the additional date/time captures: 01 02 28 00 e7

    Following from my first interpretation above, knowing the displayed time is 01:02, that's (not surprisingly) the 01 02 and also 40 seconds (hex 28) with an 00 e7 checksum for the whole "packet".

Here's a higher-level hypothesis of the packet decoding:

Using the original date/time packet as an example:

01 01 02 02 00 06 01 01 02 07 89 28 01 0d 38 01 02

The original command is the leading 01 01 02 02 00 06 where the actual command is 01 01 02, then the number of bytes following (including checksum) is 02 and then there is a checksum for that "command" - 00 06.

The response starts with the next bytes: 01 01 02 (perhaps tells us what command this is a response to, for sanity checking by the master/PC). Then there are 07 following bytes (including checksum) - 89 28 01 0d 38 01 02.

As I already suggested, I suspect that the 01 0d 38 is hh mm ss values in hex. The trailing 01 02 is a checksum.

That means that the actual date can only be encoded in the two remaining bytes 89 28 in that data packet.

My hypothesis at this stage, is that those two bytes 89 28 might be a little-endian day counter value, meaning it might really be 28 89 (hex) i.e. 10377 (decimal) days. If that was true, then 9th April 2008 - 10377 days seems to be 11 November 1979. Not an unreasonable "epoch".

(That's much more reasonable than if I treat the bytes as big-endian, convert 89 28 hex to decimal (35112) and subtract that many days from 9th April 2008, which seems to suggest a day counter start (epoch) of 21 February 1912 - that's much less sensible for a piece of modern equipment.)

If you can wait for the date (i.e. the day) to change on the devices internal clock, then we can see if the date value does indeed change in those response bytes from 89 28 to 8a 28, which would confirm that it is a little-endian day counter value sent from the device, and interpreted to become a display date in normal format, by the PC software.

Or you could try to feed a modified set of data to the PC software and change those two bytes which I believe encode the date, and see what the PC software displays. The problem is the (what I believe to be) checksum on each packet. That makes it difficult (likely impossible) to feed modified data to the PC software, until you have the checksum algorithm, and can correctly modify the checksum bytes, when you modify the data bytes.

Finding the checksum algorithm proved easier than I expected.

  • The last 2 bytes in each packet, both the 6 byte "sent" data packets, and the longer "received" data packets (but only the real "received" data, which starts with the 7th byte in that mixed sent + received data capture) are indeed a checksum.

  • It is literally the sum of all the the bytes (but excluding the checksum itself, obviously) in big-endian (i.e. MSB then LSB) format.

    (All examples below are in hex.)

  • For example, in the sent data packets, it is easy to see this:

    01 01 01 02 00 05 => 01 + 01 + 01 + 02 = 0005
    01 01 02 02 00 06 => 01 + 01 + 02 + 02 = 0006

    In the first date & time packet (ignoring the 6 bytes of "sent data" at the start):

    01 01 02 07 89 28 01 0d 38 01 02 => 01 + 01 + 02 + 07 + 89 + 28 + 01 + 0d + 38 = 0102

With this information, it is now possible for you to build a modified data packet and send it to the PC software, with a valid checksum, to see how that data is displayed. As mentioned before, the bytes to concentrate on changing (to help you understand their meaning, and confirm or deny my hypothesis of them being a day counter) are those containing 89 28 in the real date & time packets.

Related Topic