RailCom™ Uses
How RailCom™ Works
RailCom™ is a technique whereby a RailCom™ enabled decoder transmits various pieces of information onto the tracks. Obviously while the command station or booster is putting a DCC signal onto the tracks, this is not possible. The solution was to create a short ‘cutout’ in the DCC signal lasting a mere 448µs during which time both track outputs are effectively wired together. This cutout is short enough to be ignored by all NMRA compliant non RailCom™ enabled devices.
During this time period a RailCom™ enabled decoder transmits a short message (usually two or four bytes long). To do this it outputs a sequence of ones and zeros where a zero is encoded as a ±30mA pulse and a one is encoded as a 0mA pulse to the tracks. A RailCom™ Reader is required to recognise a pulse of greater than 10mA as a zero and a pulse of less than 6mA as a one. Consequently RailCom™ is unaffected by other resistive loads (e.g. tungsten bulbs) on the tracks despite the myths to this effect which have arisen on the internet.
To prove this consider that in order for coach lighting to break RailCom™ it would need to cause a one to be read as a zero or vice versa. As coach lighting draws power rather than provides it the only possibility is to convert a zero to a one by drawing enough power to drop the 30mA signal to less than 10mA. In order to read the RailCom™ signal a RailCom™ Reader uses a small resistor. Based on the values dictated by the RailCom™ specification the largest usable resistor is 1.5Ω. Given that 10mA is one third of 30mA and the coach lighting is in essence a resistor in parallel with the resistor in the RailCom™ Reader, the resistance of the coach lighting has to be less than 0.75Ω. Now consider the effect of a 0.75Ω load on the tracks when the cutout is over and the booster is again supplying ±18V across the tracks. A 0.75Ω load at 18V will draw 24A! Even at 12V, as used in Z scale, a 0.75Ω load will draw 16A. As a load this massive would trip the short circuit protection even with the most powerful boosters currently on the market it can safely be concluded that it is physically impossible to put enough lit coaches on a layout to harm a RailCom™ signal. This proof is equally valid for everything else which may reasonably be found on a layout.
Detecting Multiple RailCom™ Decoders In A Zone
There are several circumstances which can lead to more than one decoder being present in a single RailCom™ zone (most commonly consisting) and we feel that it is essential for a RailCom™ Reader to be able to cope with this scenario. Fortunately the developers of RailCom™ thought so too, as there are specific provisions in the specifications which are obviously designed to support multiple decoders in a zone. The remainder of this section outlines the mechanism by which this is achieved and the limitations of the technique.
RailCom™ transmissions are divided into two time slots (called ‘channels’ in the RailCom™ specifications). These time slots exist to permit two decoders to transmit information simultaneously provided that certain rules are obeyed.
Normally a decoder will only transmit RailCom™ information in the cutout that occurs after a DCC packet addressed to that decoder. As only one decoder can be addressed at any one time (assuming no two decoders have the same address) it is guaranteed that two RailCom™ decoders will not be trying to transmit at the same time. The problem with this technique is that, if you are not currently sending DCC commands to a decoder, then you can't detect it using RailCom™.
The solution to this problem is called Address Broadcast. Address Broadcast permits a decoder to transmit a select subset of the RailCom™ data even when not explicitly addressed. The only RailCom™ transmissions permissible in this way are those which communicate the address of the decoder. All other information (CVs, Speed, Temperature, etc.) may only be transmitted when explicitly addressed. This permits detecting a locomotive which is not currently active, but creates a new problem in that it is now possible for two decoders to both broadcast an address at the same time in the same zone. Much as if two people attempt to talk at the same time, neither is intelligible.
The solution to this problem refers back to the time slots mentioned at the start of this section. If a decoder is configured (in CV 28) to enable Address Broadcast, then it will reserve the first time slot solely for broadcasting addresses. In this way if two decoders are transmitting in a single zone, and neither is addressed by a DCC packet, then both will transmit at once. However, when next either of the decoders is addressed by a DCC packet, it will transmit its RailCom™ response in the second time slot. As the second time slot may not be used for broadcasting, only one decoder will be transmitting in it and the RailCom™ data will be received correctly. The same applies in reverse when the other decoder is addressed by a DCC packet. Additionally, when a decoder transmits in the second time slot instead of the first, the first will become free permitting the other decoder's broadcast packet to be received correctly.
A natural consequence is that, provided the control system driving the layout is aware of which decoders are active on the layout, there is no limit on the number of decoders which can be detected in a single zone. If a new locomotive, with a decoder which is not yet known to the control system is placed in a zone which already has another decoder, then, provided the other decoder is known to the control system, the new decoder can be detected after which it will also be known to the control system. As such, the only circumstance which can cause problems, is if two decoders enter a zone at exactly the same time, neither of which are known to the control system. The only time this could reasonably happen is when first switching on a layout. Under these circumstances most command stations will not be able to detect both decoders until a user takes control of at least one. By contrast, a computer control system will be able to detect that there are two decoders in a zone (by the large number of corrupt packets being received from that zone) and automatically test all the decoders in its locomotive database until it finds the correct ones. At this time there is no software available which has support for multiple decoders in a RailCom™ zone but it is likely that upgrades adding this feature will be released in the near future.
Block Control
One of the principal areas of automation in existing layouts is block control (i.e. making locomotives brake when they are about to cause a crash). Block control is necessary to permit running a large number of locomotives without requiring someone to be in control of each one (usually only possible in clubs) and as such people have invested significant time and effort into creating reliable block control mechanisms. These designs usually involve a combination of occupancy and braking sections which require large numbers of cuts being made to the track. Depending on whether you're making an occupancy or a braking section different arrangements of cuts are necessary.
For a braking generator or reverse DC braking, both rails must be cut in two places to create a ‘landing zone’ for the bogeys. If this isn't done then a bogey crossing the join will create an electrical conduction between the track on both sides of the cut.
For ABC braking two cuts are still required however only to a single track. ABC braking is particularly susceptible to the effect noted above as the bogey will switch the ABC braking module out of the circuit allowing the locomotive to accelerate again. Worst is that with constant braking distance enabled it will reset the braking distance leading to the well known ‘creeping’ phenomenon.
Occupancy and RailCom™ sections only require one cut to a single track.
When using RailCom™ based block control, all the different hardware required for traditional block control disappears and are replaced by RailCom™ Readers (which have the same wiring requirements as occupancy sections). This greatly reduces the number of cuts a layout requires as well as the complexity of the wiring. Additionally RailCom™ enables accurate braking under circumstances which cannot be handled otherwise, without introducing limitations to the running of the layout. A common example of this is a track section between two points (turnouts) which needs to brake trains approaching either point depending on direction of travel and the current state of the point. If this track section is large enough two separate braking sections could be used but if not then a single braking section needs to permit braking in either or both directions. This can almost be achieved with two ABC braking modules: one switched in by the first point and the other (wired the other way round) switched in by the second point. This will brake correctly when either point is set against an oncoming train but will fail if both points switch in their ABC module. In this instance the two modules will cancel each other out and result in no braking. RailCom™ can cope with this scenario easily. RailCom™ can also brake a train which is reversing when the guard's van enters the zone because the software knows that the guard's van represents part of the same train and can send the stop command to the locomotive even though it is physically in a different zone. In short RailCom™ based block control is both simpler to wire and also copes with situations which would otherwise be very difficult to resolve. It is no longer necessary to arbitrarily restrict the manner in which the layout is run (e.g. only allowing trains to run in one direction) to compensate for limitations of the block control system.
Scripted Behaviour
Aside from permitting block control to be performed properly, RailCom™ enables
many other actions to be triggered by a locomotive entering or leaving a zone.
For example a script could switch the lights on automatically whenever a train
enters a tunnel or make only passenger trains stop in front of station platforms
and not goods trains. With function control, and knowledge about which
locomotive the command is going to, it becomes possible to script things such
as: when a train arrives in section Tunnel 1, switch Lights On and Blow Horn. Then if a particular locomotive has the horn on F5 this will be
interpreted as an “F5 on, wait, F5 off” command but if another locomotive has
cab lighting on F5 and the horn on F2 it will send the command to F2 instead.
Obviously if a train doesn't have a horn then it will just switch the lights on
and ignore the horn command. There is no need for all locomotives to have the
same function assignments.
As a further example, imagine that you have a water pump for topping up steam engines and you want to have steam locomotives stop there but other locomotives go straight past.
Assume that you have named the zone next to the water pump Beside Water Pump
and the preceeding zone Before Water Pump. The water pump arm is connected to
an accessory decoder named Water Pump Arm which supports two states called
In and Out. When a locomotive enters the zone Before Water Pump that
locomotive is set as the Current Locomotive and its profile checked to see
whether it has the keyword Steam assigned to it. If so then the speed step is
saved before slowing down to a fixed speed. When the locomotive reaches Beside Water Pump a speed step 0 is sent which stops the locomotive. Provided the
boundary between the two zones is positioned correctly, the locomotive will stop
in precisely the correct position. After stopping the arm is rotated out for ten
seconds before being rotated in again, the water level CV is set to full and the
locomotive accelerates back to its saved speed. Such a script might look
something like this:
If Before Water Pump Is Occupied
And Current Locomotive Is Steam
Save Current Locomotive Speed
Set Current Locomotive Speed to 10
If Beside Water Pump Is Occupied
And Current Locomotive Is Steam
Set Current Locomotive Speed to 0
Set Accessory Water Pump Arm to Out
Wait 10 seconds
Set Accessory Water Pump Arm to In
Set Current Locomotive CV 895 to 254
Restore Current Locomotive Speed
The non-indented sections describe the event conditions and the indented sections describe the actions to take should the event occur. It is worth pointing out that the power of scripting isn't so much the ability to make things happen (the indented section) as that can already be done, but to determine when, where and to whom things should happen (the event). The ability to say that something should happen whenever any locomotive of a particular class (e.g. “electric with catenary”) or with a specific identity enters a particular zone permits you to stop focusing on the complex rules your layout dictates to you and just have fun.