![]() ![]() RailCom Identifier: The first four bits of a datagram define its content. Example: Identifier 0011 introduces a short datagram (8 bit data field) for the speed report in km/h Identifier 0110 indicates a datagram with a 16 bit data field for a position report (number of a track section, an electronic milepost, etc.) Identifier 1111 is at the beginning of a CV message, a response to a DCC CV readout command.RailCom Datagram: data word which consists of a RailCom Identifier (4 bits) and the data field of the datagram (8, 20, or 32 bits) There are three lengths for datagrams with a total of 12, 24, or 36 bits (Identifier and Data field together).RailCom Message: A message which a RailCom-capable decoder sends out in the RailCom-specified procedure. Consists of at least one, often several RailCom Datagrams i.e.: Four short (12 bit), or one short and one long (36 bit) datagram. Error detection 4:3 bits sent.RailCom Cutout: A gap in the DCC transmission, created by a RailCom Cutout unit, of approximately 500µs, for the decoder to send RailCom Messages.Train number detection: With RailCom compatible detection modules the multifunction decoder can transmit their presence in a block along with the address, or direction.Railcom can transmit CV values without a programming track, as well as provide confirmation of changes to a CV. Although it is a blind programming method: a CV value changes, but the multifunction decoder cannot confirm it nor easily read existing CV values. Ops Mode or Program On Main is supported my many multifunction decoders and command stations. Multifunction decoders supporting Railcom can communicate back to the command station its status. The command station sends commands, and the multifunction decoder supposedly acts on it. Under Digital Command Control, multifunction decoders do not communicate back to the command station. Zimo introduced a technology, Zugnummernimpulse or ZACK (Train Number Impulse), supported by DCC in 1998, which is similar to RailCom. There were opinions expressed that the inclusion of a patented and proprietary technology in the DCC Standard was a problem, one that could lead to the owners using their IP against other manufacturers. Their stated reason for declining RailComPlus was related to the licensing and approval conditions demanded by Lenz and ESU, which these manufacturers found to be unacceptable, in that they prohibited the free exchange of ideas which would impede development and technical progress of digital control for model railways. In addition to Zimo, a number of DCC decoder manufacturers, as well as model railway manufacturers, declined to support RailComPlus in their manufactures. ![]() Zimo continues to make decoders which support RailCom only. In 2011 Zimo exited the agreement when Lenz terminated their licence. Work on the protocol began in 2006, with some decoders from 2005 already supporting RailCom. LENZ, KUHN, TAMS and ZIMO formed the RailCom Working Group to further develop "bidirectional communication" based on NMRA Draft RP's 9.3.1& 9.3.2. RailCom is completely backwards compatible with Digital Command Control. It has been incorporated into an NMRA RP for Two-Way communications between the command station and multifunction decoders on the track. Lenz demonstrated the RailCom concept at a DCC Working Group meeting in the spring of 2000. ![]() Examples include speed, motor load, contents of any CV, and its address. RailCom can read data transmitted by a multi-function decoder. RailCom is a bi-directional data communications technology developed by Lenz, and found in NMRA Recommended Practices RP 9.3.1 and 9.3.2. RailCom® and RailComPlus® are registered trademarks of Lenz.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |