Our Products

The 16 Zone Local RailCom™ Reader Device

Our RailCom™ Reader device, unlike some others on the market, can cope with more than one RailCom™ enabled locomotive in a single zone, and it can distinguish between Short addresses, Long addresses and Consist addresses, as well as cope with Consist Membership. It can also interleave multiple CV requests simultaneously. Software could use acknowledgements to retire successfully transmitted DCC packets and so reduce unnecessary retransmissions in order to optimise bandwidth usage which may be important on large layouts with many locomotives. It can also differentiate between the 6 different types of acknowledgement codes generated by RailCom™ decoders. Unlike some other available systems, ours will detect simple occupancy by non-RailCom™ enabled decoders, lit coaches or resistive wheel-sets. Furthermore, it will also detect the orientation of RailCom™-equipped locomotives on the tracks and, coupled with the DCC commands, this can then be used to infer direction of travel even before the locomotives have started moving. We are also able to receive values for actual speed, load, fuel, water and temperature and are already capable of implementing any further packet types that may be introduced in the future without requiring any firmware alteration. As an additional measure to guard against data corruption our RailCom™ Reader samples each RailCom bit 5 times, reducing the effect of noise on the RailCom signal significantly.

As the content of RailCom™ packets is still subject to change we decided to avoid depending too heavily on processing the RailCom™ data in hardware and defer as much as possible to the computer. To this end our device supports two methods of transferring RailCom™ data. The first is a raw encoding which transfers everything verbatim. The second provides a degree of preprocessing in hardware and is intended solely for use by the Railroad & Co. / Rocrail compatibility layer.

Our RailCom™ implementation allows a maximum 4096 zones per USB port as opposed to the 1024 from Lenz or 239 from Tams. We believe that ESU and Viessmann will be using an implementation similar to that from Lenz.

The Local RailCom™ Reader


The Omnibus

As most currently available bus systems in use in the Model Railway arena are not fast or powerful enough to manage the data volumes and speeds required by our RailCom™ device, we decided to design a new bus protocol. We intended this bus to be as near universally accessible as possible, hence Omnibus. (Lenz produced their 1Mbit per second RailComBus — probably for these same reasons, but to date have not published their protocol.)

When designing our bus system we first considered, and rejected, various of the other busses already in widespread use. This was primarily because none of the available busses were capable of delivering the 3.6Mbit/s bandwidth required if fully loaded. One bus system which has become fairly popular lately is CANbus, a bus system originally designed for use in the automotive industry. This is the bus system used by Zimo, MERG and the new NMRA standard cab bus. Being one of the few bus systems which are extensible to support RailCom™ we gave it significant consideration before deciding that certain aspects of its design made it unsuitable. Specifically the bus has too much overhead per packet and the fixed priority scheme is in danger of causing starvation of high numbered devices. Consequently we felt we had no choice but to design our own bus system from the ground up.

Our system communicates at variable speeds depending on the devices attached. It will be possible (via adaptors) to attach slower components such as those using s88 or Xpressnet (62.5Kbit/s) alongside fast devices such as our RailCom™ Readers. For now we will run the bus up to 6Mbit/s but the specification is open ended and so may be extended almost indefinitely should it prove desirable (e.g. when fiberoptics become more affordable).

Whereas twisted pair shielded cable (as illustrated below) represents the ideal Omnibus cabling suitable for large layouts, for more modest layouts whatever cable is convenient can be used.

We have made the bus protocol available in the downloads section free of charge so anyone wishing to make compatible devices can.

Omnibus Cabling

The Computer Interface Device

Our bus is controlled by our Computer Interface Device (CID) which, somewhat like a traffic policeman on point duty, recognises the various devices connected to the Omnibus at any one time and gives each a turn to deliver their information before packaging this up for the PC. It also receives instructions from the PC which it can communicate to the various occupants and so arbitrate the traffic on the bus.

As part of the Omnibus specification includes a standard method of downloading new firmware to Omnibus devices, the Computer Interface Device supports downloading new firmware both to itself and to all connected Omnibus devices. Additionally the firmware update indicates which devices it is intended to support meaning there is no requirement to disconnect other devices when downloading firmware or to manually download the firmware to one device at a time. Instead if three RailCom™ Reader devices and one DCC Output device are all attached to a Computer Interface Device and a RailCom™ Reader firmware update is performed then all three RailCom™ Reader devices will be updated but both the DCC Output device and the Computer Interface Device will remain untouched. Unlike with certain other manufacturers there is no need for specialised hardware to perform this function.

The Computer Interface Device

A potential problem when downloading firmware to a device can occur should the process not complete successfully. This can be caused in many ways e.g. power failure, cables being stepped on causing them to be unplugged, etc. This usually results in the hardware being unusable and requiring repair by the manufacturer. In recognition of this we have designed all our Omnibus equipment to include a button which can restore the firmware to out-of-box condition should a firmware upgrade fail. It works as follows: disconnect power, then hold down the button and reconnect power. After ten seconds the LED will begin to flash red slowly for up to five seconds. If the button is released during this time, then it will flash red quickly before turning green indicating a successful restoration of the firmware to out-of-box condition.

The Standalone Cutout Device

The initial design brief for this circuit was to produce a fully spec compliant DCC cutout so as to allow non-RailCom-enabled hardware to function in a RailCom-enabled environment.

The Standalone Cutout Device


For more information see the Cutout Device Manual in the Downloads section.