Introduction and Background

About mid-2001, hobbyists, using the Association of American Railroads public specification for Automatic Train Control System (ATCS), developed Windows-based software to monitor Radio Code Line (RCL). This software allows decodes radio signals and then displays the Control and Indication codes. Additional software allows these codes to be graphically displayed in the format of a dispatcher's panel, which is continuously updated from the incoming data stream. Both of these pieces of software are designed to be receive-only and have no provision to generate code for a message or transmit it. The software is written in Visual Basic and C++ for use on Windows 95 and above. No support is provided for any other operating systems. The software is an outgrowth of MDTmon, a software package designed to monitor Mobile Data Terminals. The software is optimized for use with the data stream entering the PC via the sound card. While some people have been accustomed to using data slicers (ATCSmon can accommodate them) with earlier DOS data programs, you should retire your data slicer because the software is optimized for use with the sound card.

Radio Code Line (RCL) Protocols and History

The railroads began installing the original (non-radio) code lines in the late 1930's to support their original CTC installations. These systems were large, heavy mechanical monsters that were constantly making mechanical noise. They were typically precision-timed mechanical units. They did not transmit data continuously. In fact, because the equipment was mechanical, railroads were rather skimpy about how much data they transmitted and how often they did it. The field units only spoke when field conditions changed; even then they typically only told you what had changed since the last update, not the whole datagram of all of the indications that we are familiar with today. You had to listen for a long while in order to collect all of the indications from a given location. Codeline manufactures even tried to make their messages as small as possible, in order to extend the longevity of the mechanical components of the system. Even today, UP uses this older coding style on Genisys at some of their locations, at 300 baud. This system of meager control and indication codes has worked very well over the years, and railroad management has been happy with the level and quality of the data. Today, while more sophisticated information could be conveyed, modern electronic equipment continues to pump out the old code.

Modern code line protocols, which where typically installed in the 1970's and 1980's, usually started life as a wire line protocol that had the capability to utilize radio transmission. Typically, the office unit (BCP), as they were known, 'polls' the field units (MCP), typically with a one byte word that contains the field unit number. If the field unit has anything new to report, it will respond by sending that data. When the exchange is complete, the office unit continues polling. The polling bytes are usually a precision timed transmission and when heard over the air will usually sound like buzzing sound that occasionally stops while a field unit responds with data. Upon receipt of that data, and acknowledgement by the office unit, the polling continues. Systems can be set up in two ways. The first, and older, style sends just the newly changed indications. The second, and newer, style sends all current indications whenever any indication changes. The field units must be polled in order for indications to be sent. We are not aware of any protocols of this style, where the office unit echoes the field units' transmissions. However, in some cases the field units will echo the control indications. Changes in indications can be delayed by the amount of time it takes for the office unit to sequentially poll up to the field units' ID number. You will need to monitor both transmissions to get the full picture. More often than not, these protocols are transmitted at 300 baud. Occasionally, however, they are sent at 1200 baud. Some of these polled protocols are known as: Harmon MCS-1, MCS-2, HP-1 (Harmon Protocol), HDP-1 & HDP-2, GRS D-1, D-2, E-1, E-2, DataTrain 4 & 8, US&S Flexicode 549 & 550, and Safetran SCS-128. They will usually be found on 952/928 or 941/932 frequency pairs. They can certainly also appear in the 160 and 450 mhz ranges as well. These transmissions usually will not be found on the six ATCS frequency pairs, however GTW and UP has been known to use them in large metropolitan areas. These protocols usually use a check sum method to validate a message; no handshaking or error correction occurs. Messages are simply resent when the check sum values do not match.

New style radio code line protocols include ATCS, ARES, Genisys and ATCS-Genisys. These protocols were developed for use with data radios. In these protocols, the MCP plays an active part in transmitting status changes as soon as they occur. If no changes occur, they will still send their full current status, frequently at one-minute intervals. ARES is an exception, with a typical unprompted interval of over 20 minutes; the office usually requests status updates at shorter intervals. In one configuration, the BCP will echo the indications sent by the MCP in the process of acknowledging the MCP. In this case you will obtain all of the information by monitoring just the BCP. In the other configuration, the BCP does not echo the MCP transmissions in the process of acknowledging. In this case, it will be necessary to monitor both frequencies in order to obtain all of the information. These protocols all have handshaking and error correction. ATCS and ATCS-Genisys are transmitted at 4800 baud. ARES is transmitted at 2400 baud. Genisys is usually transmitted at either 300 or 1200 baud. ATCS can be found on all portions of CSX, the ex-N&W portions of NS, the ex-ATSF portions of BNSF, on UP typically in terminal areas, the Canadian Pacific from coast to coast, Canadian National in lower Ontario and on an assortment of other smaller railroads and transit systems. ARES is found exclusively on the ex-BN portions of BNSF. Genisys can be found on the GTW and portions of UP. Genisys via ATCS is in use on the Wisconsin Central in Illinois and on the CSX at Willard OH. ATCS and Genisys via ATCS transmissions occur exclusively on the six pairs of assigned frequencies. ARES transmissions are always on 160 mHz frequencies. Genisys transmissions usually occur on 952/928 mHz and 941/932 mHz frequency pairs.

Industry Use of ATCS Monitor

Some signal maintainers have found this software to be helpful on the job, sometimes as a source of information and other times as a trouble shooting aid. User-definable rules within the software allow users to play a variety of wave (.wav) files when a certain sequence of events occur. These sounds can include a simple bell sound, a verbal announcement of a train passing a location, or announce that a control point has just lit the maintainer call light. Maintainers typically will use ATCSmon by itself, without the aid of a layout file. A recent occurrence placed ATCSmon in the hands of a hearing officer after a train crew was found to have run by a signal and through a switch.

A number of railroad signal manufacturers and venders, including Wabtec and GETS, use this software to test their own programing efforts and field installations prior to system cut-over.

Where To Listen

Official ATCS Radio Frequencies allocated in the USA & Canada

MCP TX	BCP TX	Ch	Users
896.8875	935.8875	1	CN, UP, GTW
896.9375	935.9375	2	CP, CSX
896.9875	935.9875	3	Los Angeles MetroLink, Shared Use, KCS, GTW
897.8875	936.8875	4	BNSF
897.9375	936.9375	5	NS, GTW
897.9875	936.9875	6	CP, SP, Metra

Note: The Canadian railroads use all six channel pairs in Canada.

Occasionally you will find other protocols using the ATCS frequencies. Both UP and GTW are known to do this, and Genisys is usually what will be found (300 baud for UP and 1200 baud for GTW). By the same token, railroads can occasionally be found to be operating on an ATCS frequency other than their own.

The commercial pairs that are used for Genisys, SCS-128, MCS-1, DataTrain 4 and even Harmon's HP-1 are typically in the 928 mHz and 952 mHz bands, or the 931 mHz and 942 mHz bands. The MAS band of 928/952 mHz is all 6.25 kHz spacing, and can be half duplex or full duplex. These frequencies are typically used by power, gas and pipeline companies and irrigation, municipal sewer and water utilities, along with with other industrial users (including railroads) to monitor their systems (such as providing flow rates and pressures at various locations). On rare occasion, they can even be found in the normal railroad 160 mHz audio communication channels. These protocols are known to be used by UP, IC, GTW & SOO. Occasionally you will find railroad protocols on these frequencies that ATCSmon will not decode. When this occurs, post the information to the Yahoo Group and make a recording. Recording Audio should be done directly from the discriminator tap of the radio. The computer should be set to 44.1k, mono and 8 bits. Keep the squelch open and record at least one minute of good signal. This will generate about a 2.5 MB wave file.

If you find yourself in a situation where you can't easily decode what you've heard, it most likely is not SCS-128. Even though you may see some partially decoded packets, SCS-128 will synch up on almost any junk it hears when you have the box unchecked to ignore non-datagram packets, since it is looking for one byte as a poll response.

In the old Burlington Northern territory, you will find a considerable amount of ARES in use. This always will be found on the normal VHF 160 mHz frequencies.

Frequencies in the 953-959 mHz ranges are occasionally used for code line replacement. These frequencies can only be licensed as point-to-point microwave links. They have 50 kHz channel spacings and can carry one to four channels of information. ATCSMon will not decode any of the protocols found on these frequencies.

Finding the Frequency

So many of the North American railroads have already been discovered and documented, so check the ATCS Monitor Yahoo group files area and the master database before searching too hard. You might stumble on the rare case where something is not documented yet, so how do you go about figuring out what frequency a railroad is using?

History

In most cases a railroad will have standardized on a single protocol and single frequency (if ATCS). Sometimes railroad acquisition legacy preempts this. For example, almost without exception, CSX is on ATCS Channel 2. UP, on the other hand, has at least 5 different flavors of protocols, some ATCS, some not. Non-ATCS is almost always in non-ATCS channels.

FCC Listings

The [[1][FCC website] has a search tool which can help you locate a US frequency based on a radius of the location in question. That can be helpful for non-ATCS frequencies. For ATCS frequencies, however, this is no longer possible, since the ARR has been designated as RibbonLicensee for US railroads, nationwide, when the frequency is used near the tracks.

Frequency Counter

You can sometimes use a standard frequency counter, but the transmissions may be too brief or weak for that to be useful. There are counters made specifically for data transmissions, though, which work better (and cost more).

Antenna Size

If you're a good antenna spotter, you may be able to guess the frequency based on the height and type of antenna. There are many variations on this, though, so unless you've got some experience, it might be a tough call. If you can grab a photograph, preferably with some sort of size reference, and ask the ATCS Monitor group, someone may be able to help.

Protocol Support

What other protocols are supported besides ATCS?

Future Protocol Support

What protocols are going to be supported in the future?

RailroadsAndTechnology

Contents