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:

00113300B5A8D968670204955EF780

This is from CP DS013 West Leyden.

This is in hexadecimal. I'll save you the time of counting, there are 30 characters in that packet, so that means 15 bytes. “00” is byte one. Byte one and two are irrelevant currently, and three is the packet type, and bytes five through nine are the address. So, we can actually test this here. Find a hexadecimal to decimal calculator, me and Robert like this one. Get bytes five through nine, (the 9th through 18th characters) and feed them into the calculator. Now we have the WIU’s ID! It is noted that bytes 5-9 are ALWAYS the WIU, that never changes.

00113300B5A8D968670204955EF780

(Bytes 5-9)

Converting bytes 5-9 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 12. (But, what’s in bytes 10-12 you say! Well, after lengthy discussion, nobody has any idea what 10 is, byte 11 is MTime [still debating what that is], and byte 12 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 13-15

5EF780

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

00113300B5A8D968670204955EF780

(Bytes 13-15)

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