How to decipher hex code for time data on an older serial port device
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 &amp; 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 &amp; 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 &amp; time packets.