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

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                                          ......
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                                             ......
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                                       ......
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
01 01 02 02 00 06 01 01 02 07 89 28 01 02 28 00   ..........‰(..(.
e7                                                ç
Time: 1:04 4/9/2008
01 01 02 02 00 06 01 01 02 07 89 28 01 04 00 00   ..........‰(....
c1                                                Á

• I'm a little confused by the question, endianness is always used (in communications greater than 8 bit). The question should be "how to determine which endianness is used?" right? – Ron Beyer Aug 3 at 22:12
• Such a thing as "combined TX/RX RS232" does not exist. What kind of monitor cable do you use? There are those which let the host's TX side "bleed" into the host's RX side and I think that's what we are seeing here. It works somehow if the communication is always ever half-duplex but it adds an extra complication when analyzing the protocol. Use a proper RS232 monitor featuring two monitor cables, one for each TX. – Janka Aug 3 at 22:26
• The question in more general sense is, how do I get a time stamp that matches the reported value out of this line "01 01 02 02 00 06 01 01 02 07 89 28 01 0d 38 01". I don't know much about how the device is communicating so anything to help that goal would be appreciated! – Research8472 Aug 3 at 22:34
• What makes you think the embedded device has any knowledge of date or time? And why do you care? Where are the actual gas concentration readings? If you really think a meaningful timestamp is encoded capture two exchanges where it differs and see how the data is different... – Chris Stratton Aug 3 at 22:35
• Update your question with data for two timestamps and show the printed timestamps corresponding. Is your data really from 2008 or did it rollover, possibly giving a clue to encoding? Also consider building a fake version with an Arduino or Port emulator or API hook/debugger and changing a byte or two to see what that does. – Chris Stratton Aug 3 at 23:37

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.

• Indeed. But now we really need to see another date. As the present values don't seem to make sense broken down or as total days from a logical starting point either big or little endian. Ideally another year. Or to start feeding the program bogus values with the previous bytes changed by one count. Load the data into an Arduino and substitute that? Or just connect to another PC or port? Probably doesn't even need to have the goofy half duplex serial as long as it looks the same in software. – Chris Stratton Aug 4 at 0:33
• Chris - I think having date & time from a different day would be almost as helpful as waiting another year, but we'll see what data we can get from the OP. I've now confirmed and reverse-engineered the 2-byte checksum (it's literally a sum). So as you say, using an Arduino or similar to send substitute data to the PC is now an option, since the correct checksum for the manipulated data can be calculated and sent. P.S. Thanks for asking the OP for the extra examples of the date & time info - that helped to identify which bytes didn't change, suggesting those could be the date-related bytes. – SamGibson Aug 4 at 2:00
• Thank you! Yes you are correct on every account. The time is exactly as you say with the check sum being the last 2 bytes. You were also right on the money for the bytes containing data related to the date. I figured it out with a lot of fiddling but the simple answer is 89 (137) is the day with mod32 applied. The year is divided into 'sub years' so an increase of 2 for every 1 year. Thank you all for your help I really appreciate it! I'll keep you posted with any quandaries for the other data. – Research8472 Aug 5 at 0:00
• @Research8472 - You're very welcome! Thanks for the update and for progressing the interpretation of those two "date bytes". Good luck with the project! – SamGibson Aug 5 at 0:14