Hey! Want to learn some cool radio history to impress your friends? Go to:

Robert’s Beginner Guide on Decoding Your Packet!

ok class gather round. . .

-Robert R,

6/17/26

How do we actually read the data that comes in the packets.hex file when recording packets?

There's a few things we need to know first:

Data from a packet is sent in the hexadecimal numbering system. Hexadecimal is a numbering system that uses sixteen distinct symbols to represent values (hence “Base-16”). Unlike the standard decimal system (base-10) which uses 0–9, hex uses the numbers 0 through 9, followed by the letters A, B, C, D, E, and F. For reference, decimal is the 1, 2, 3, 4, 5, and so on numbering system we all know and were taught in pre school. It may be confusing that it's called decimal, because not all “numbers” have decimals, but still, the number “1” can also be written as “1.0”

But I digress. . .

Two characters in hexadecimal are called a byte. So, if your string of numbers in hexadecimal has 8 characters, then it has 4 bytes. Additionally, a byte is equivalent to eight (8) bits, but that will become relevant later. From hexadecimal, we will need to convert to binary. The binary number system is a base-2 numeral system that represents numbers using only two digits: 0 and 1. In addition to converting the numbers in our data packet to binary, we will need to convert them to standard decimal as well.

Okay, now to get on to the actual work:

Take this packet for example:

4900113300B5A8D968670204955EF780

This is from CP DS013 West Leyden.

This is in hexadecimal. I'll save you the time of counting, there are 32 characters in that packet, so that means 16 bytes. “49” is byte one. Byte one is an identifier for the ITC protocol. Byte two and three are irrelevant currently, and four is the packet type, and bytes six through ten are the address. So, we can actually test this here. Find a hexadecimal to decimal calculator, me and Robert like this one. Get bytes six through ten, (the 11th through 20th characters) and feed them into the calculator. Now we have the WIU’s ID! It is noted that bytes 6-10 are ALWAYS the WIU, that never changes.

4900113300B5A8D968670204955EF780

(Bytes 10-9)

Converting bytes 6-10 from hexadecimal to decimal using RapidTables

B5A8D96867 (hexadecimal) -> 780221900903 (decimal)

And, it matches in ITCMon!

WIU ID seen in ITCMon matches result achieved above in RapidTables

Alright now that we have decoded the WIU ID, lets move onto everything after byte 13. (But, what’s in bytes 11-13 you say! Well, after lengthy discussion, nobody has any idea what 11 is, byte 12 is MTime [still debating what that is], and byte 13 is Sequence, which is actually pretty cool. You can read about it in the footnote.) Okay, so the rest of the data (switch and signal status) )is going to be converted into binary.

Bytes 14-16

5EF780

So, now go back to your calculator, this time change the conversion setting from hexadecimal to binary.

4900113300B5A8D968670204955EF780

(Bytes 14-16)

5EF780 (hexadecimal) -> 010111101111011110000000 (binary)

Note that you get the exact same numbers that ITCMon shows in the “data” entry!

Binary in ITCMon matches binary result from RapidTables

The first two numbers in the output are the switch. Switches are easy. for this CP at least, 01 is normal and 10 is reversed. So, this packet shows the switch as normal (010111. . .). Signals are represented by five bits. This CP has three signals, so you'll see three sets of five bits.

01 | 01111 | 01111| 01111| 0000000

The trailing zeros don’t mean anything, so ignore them. Signal 01 is 01111, and so are signals 02 and 03. Now we will convert them into the regular decimal system, so we can map them to an aspect. Go back to your calculator, this time setting it to convert from Binary to Decimal. Take one of the signals, (in our case, it doesn’t matter, since all three are the same, but in your case it may be different.) Input 01111 (or whatever is applicable for your packet) to the calculator, and you will get the number of the aspect as it corresponds to the rrdata.json file! As you can see, 01111 is 15, and 15 for most railroads is Stop.

01111 in binary is the equivelant of 15 in decimal, so we know that that signal is showing 15, according to the rrinfo.json file (Right) in the ITCMon files.

Congratulations, you have (nearly) fully decoded a packet.

Footnote: Sequence is really cool, because you can check the reliability of your monitoring. Seq in subsequent messages might go 1, 2, 3, 4, but if the next one you receive is 6 then you know you have missed a packet.

All credit goes to Robert Romaine, he's awesome! Want to see more of his works? Go check out his GitHub!

View this guide in Google Document form

Maintained and compiled by Ron.

Page updated

Google Sites

Report abuse