RF Codeline Protocol Reference
ATCS addresses break down into the general structures of:
- T-RRR-CCC-AAA-XXXX (for a 7-series address such as 71253230040202)
- T-RRR-XX-AAAA (for a 5-series address such as 5125023234)
- 0101 Diagnostic control of Vital Logic Controller. These packets contain MCP command and control information. They do not contain information useful for displaying track and signal information.
- 0102 A location with a radio and a protocol converter, transmitting ATCS or ATCS-Genisys packets, from a location that has a native Genisys or SCS-128 interlocker controller, OR, a location without a radio, fed by wire code line, polled and broadcast from another location where a protocol converter and radio are located.
- 0202 A location with a radio, and a native ATCS Vital Logic Controller, transmitting ATCS packets. This location can also be fed by a wire code line and use a protocol converter to poll other MCPs attached to the wire. If this is happening, normally the resident address for this location will end in 0202, and those addresses
Address StructureARES addresses break down into the general structure of:
- T-RRR-CCC-AAA (for a 5-series address such as 5076386432)
It seems useful to classify commonly monitored protocols into to major categories, Random Access and Polled. I've made up these terms, so I'm not sure if there's an industry-standard set of terms. In networking, the parallels are non-deterministic versus deterministic.
Random Access Protocols
Random Access protocols include those whose MCPs transmit their status whenever they feel like it, normally when an event occurs causing and indication change, or at a predetermined interval. The office may choose to poll, if it needs a more recent update than what it had last received, but a poll is not required for the MCP to transmit.
Random Access protocols include:
Contention for frequency time on ARES, the only simplex (single frequency for both Tx and Rx) protocol, is handled using CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) type mechanism. In this scheme, the MCP checks the frequency before it transmits. If it hears another transmission, it waits till the frequency is clear and selects a slight random delay before it tries again (in an effort to avoid all other waiting MCPs from transmitting at the same time). Since it might not hear a neighbor transmitting, it may step on another's transmission, in which case the MCP will resend for lack of an ACK (acknowledgement) from the BCP.
Contention for frequency time on other random access protocols operating as half-duplex (separate frequencies for Tx from RX) is chaotic, that is, an MCP cannot hear other MCPs so it transmits when it wants to. So it may step on another's transmission, in which case the MCP will resend for lack of an ACK (acknowledgement) from the BCP.
Polled protocols include those whose MCPs wait until they hear their address transmitted by the BCP before they speak. The BCP will run down its list of addresses, in order, giving an opportunity for an MCP to tell its story. So if an MCP has an event such as an indication change, it waits till it is asked before responding with its status.
- Genisys (all flavors)
- Data Train
The polling method avoids frequency contention entirely, but delays reporting by some fraction of the time it takes to poll all addresses in a PollingCycle.
Addresses used by polled protocols are generally only 2-3 digits long, so are therefore not globally unique (they are duplicated around the railroad). Therefore, we apply a prefix to the address as shown in the Protocol tab of Configure->Options in ATCS Monitor. Polled protocols will start with the 1st digit as number 8. So a polled protocol address looks like 8+RRR+ZZZZZ+S+AAA, where RRR is the railroad number (as with ATCS), ZZZZZ is the arbitrary zip code we applied according to the postal zip code of the BCP serving the lowest MCP address in the Polling Cycle, S is an abitrary suffix we apply just in case there is more than one BCP per zip code (normally zero), and AAA is the address actually sent by the polled protocol.
When monitoring by server, the entire address structure is preserved from the server, so adjusting these parameters is not necessary. When monitoring by radio, it's important to set these parameters so that the addresses heard by radio match up with those in the database. You can determine appropriate parameters by breaking down the address structure of the addresses in the database into its components as shown above, if the territory custodian has not already done so for you in kit notes.
Genisys, SCS-128, Data Train and a few other non-ATCS protocols allow their MCPs to only respond when asked (polled). In some cases, the addresses heard polled by a BCP extend beyond just the MCPs it is in range of. Why? Sometimes BCPs are connected to back to the office via a sort of party line that we refer to as a Polling Cycle. So the office actually does the polling, but the BCPs on the Polling Cycle all send out polling information, as well as Controls. This is handy, since you can often see trains getting lined up far beyond the reach of the single BCP.
We try to leverage this in ATCS Monitor by using a single BCP Zip Code for all of the BCPs on the Polling Cycle. That way we can see all of the traffic for a single layout (assuming all on the same party line), without having to switch ATCS Monitor profiles. We try to use the BCP Zip Code of the BCP sending controls to the lowest MCP address in the cycle. So if you find address 002 polled, this will be the BCP to use for the Zip Code.
Here's a table representation of how the addresses in a couple polling cycles might look. (Requires Excel or equivalent.)
-- Main.GaryHahn - 31 Aug 2008
- GenisysBCP.xls: Representation of a Genisys (or other polled protocol) Polling Cycle (party line)