This is a project I’ve been working on intermittently for 4 or 5 years. Many of you probably know that railfans listen for the audible bursts of data from the EOT and HOT (end-of-train, head-of-train) transceivers to get advanced warning of a coming train. Several years ago, a guy named Matt Shelburne created a Windows program called SoftEOT to decode the transmissions. I have no interest in running Windows, and wanted to build a handheld decoder, so I started reverse engineering the protocol. It took a LOOOOONG time. AREMA does NOT want you know how this stuff works.

Last summer, I finally pulled the pieces together and developed a Python program that can generate arbitrary packets, including the BCH encoding and (very light) encryption. Once I had a packet generator, I could start working on receiving/demodulating/slicing/decoding/validating packets. I got distracted, but finally circled back this week, and got it working!

In the video below, I’m looping a wave file (recorded from a scanner) though a GNU Radio flow that demodulates the AFSK signal and slices it into a bitstream. The bitstream is fed to a TCP port. In the terminal window, I’m running a Python script that monitors the bitstream. When it sees the sync word, it grabs the packet that follows, decodes and validates it, and prints some of the interesting data to the screen.

My vision is to have a fleet of Raspberry Pis with RTL-SDR dongles along the rail line, feeding data to central server.

Eric,

That’s pretty cool, but I’m not really sure what data you are going to see. The FRED’s (EOT) just report brake pipe prrssure, and if they are moving. They are pretty dumb.

Have you heard of ATCS Monitoring? If I had the tech knowledge I would be focusing on that. ATCS Monitoring is listening and decoding the data stream between signals, track occupancy and the dispatcher. There is a Yahoo group dedicated to this.

http://www.atcsmon.com

We don’t have ATCS here, so I’ve never cared much about it. However, developing a low-cost EOT monitor that can be deployed to railfans could provide interesting crowdsourced train movement data for short lines.

One of the reasons that I took on this project, though, was to confirm my suspicion that there is a gaping security hole in the EOT/HOT system. The HOT has the ability to instruct the EOT to vent the brake line in an emergency braking event. This stops the train more quickly. However, this instruction is transmitted with absolutely no encryption (oddly, the EOT is encrypted (kind of), but not the HOT). All you need to know is the ID of the EOT, which it happily broadcasts every minute.

Cool. Way over my head, but cool.

I’ve put together a python script which utilizes your decoder. It’s source is RTL_FM to avoid the big GNU radio build, and uses SoX for conversion and MultiModem (a specific fork) to provide binary output from the FSK demodulator. That is all piped together within a python script, including your decoder library for output. russinnes/EOTDecode: Python-based railway EOT decoder (github.com)