Differences

This shows you the differences between two versions of the page.

--- glossary:glossary_r [2023/12/11 11:06] – [RailCom] michael_smith
+++ glossary:glossary_r [2025/09/19 08:47] (current) – [RailCommunity] michael_smith
@@ Line 6: / Line 6: @@
 ===== RailCom ======
-A relatively new DCC standard to implement return messages from a train/decoder.  It was originally developed by Lenz, and is now a RailCommunity standard.  Further development is in progress by European companies, and this extension is called RailComPlus.
+RailCom is the bidrectional (return) element of DCC, although not released at the same time as the main elements of DCC the bidirectional side was introduced in 2011. The susbsystem enables selected CV data held within the loco or accessory decoder to be transmitted back the the command station or in the case of loco DCC address to a local block detector. It was originally developed by Lenz the creates of DCC, and is now a RailCommunity standard RCN-217).  Further development is in progress by European companies, and this extension is called RailComPlus (Auto-logon).
-RailCom works by having the command-station/booster stop driving the rails between DCC packets and placing a short circuit across the track for approx. 470uS, during the inter-message idle packets and is known as the "cutout", then the decoder generates a 30 mA serial encoded signal on to the track. The data output by the decoder can be in either Channel 1 or Channel 2 or both, Channel 1 is for the loco addresses that the decoder will respond to. Channel 1 data is unsolicited data 2 (6 bit) bytes in size called datagrams, that is to say the data is sent out without being requested and is received and decoded by "local" detectors around the layout in track "blocks". Channel 2 data can be up to 6 (6 bit) bytes and is only transmitted out by the decoder in response to a command sent by the command station. this data is received and decoded by only one "global" detector on the layout. Therefore the maximum data transmitted in the DCC cutout period for CH1 and CH2 is 8 bytes (datagrams).
+RailCom works by having the command-station/booster stop driving the rails between DCC packets and placing a short circuit across the track for approx. 470uS, during the inter-message idle packet and is known as the "cutout", then the decoder generates a 30 mA serial encoded signal on to the track. The data output by the decoder can be in either Channel 1 or Channel 2 or both, Channel 1 is for the loco addresses that the decoder will respond to. Channel 1 data is unsolicited data 2 (6 bit) bytes in size called datagrams, that is to say the data is sent out without being requested and is received and decoded by "local" detectors around the layout in track "blocks". Channel 2 data can be up to 6 bytes of 6 bit bytes and is only transmitted out by the decoder in response to a command sent to the decoder by the command station. This data is received and decoded by only one "global" detector on the system layout. Therefore the maximum data transmitted in the DCC cutout period for CH1 and CH2 is 8 bytes (datagrams).
 An example of RailCom Channel 1 detectors are shown here [[projects:railcom]].
@@ Line 14: / Line 14: @@
 RailCom/Plus allows: the identification of unknown trains; block occupancy; transmission of train information, such as its actual speed; and more efficient 'on-the-main' programming.  See: [[https://www.merg.org.uk/merg_wiki/lib/exe/fetch.php?media=dcc:specs:rcn-217.pdf|RailCommunity standard]] and [[http://www.esu.eu/en/support/white-papers/railcomplusr/|ESU RailCom Plus]].
+===== RailCommunity ======
+RailCommunity is a German organisation made up of primarily DCC decoder manufactures. Due to the fact that the NMRA (original custodians of the Lenz DCC standards) were not passing on the enhancements being made to the DCC system, then making their way into the documented standards at the rate required by decoder manufactures.
+Although the NMRA DCC standards are still active the RailCommunity orginisation was formed to bring the system enhancements and developments quicker so manufactures and customers alike were quicker informed.
+Today the current standards are published by RailCommunity with close involvement with the NMRA, MOROP and BDEF.
+One slight disadvantage is that although the RailCommunity documents are always up to-date they are only published in the German language. Fortunately, Merg has these German documents translated into English and available for members to view here: [[dcc:specs:start|DCC Standards]]
 ===== Raspberry Pi =====