JMRI® is...
DecoderPro®
Advanced
Applications
By the community of JMRI.org:
Tools
JMRI tools for working with your layout:
Layout Automation
Use JMRI to automate parts of your layout and operations:
Supported hardware
JMRI supports a wide range of devices, DCC systems, command stations, networks, and protocols.
JMRI Setup and Installation
JMRI environments...

JMRI Help:

Contents Index
Glossary FAQ

Donate to JMRI.org

JMRI: DecoderPro User Guide

Creating A Custom Decoder File

This page provides information on how the decoder definition files for the DecoderPro Symbolic Programmer work and how to create a new one.

In this user guide, we walk you through the process of creating a file to describe a new decoder. You might benefit from reading the other sections of the DecoderPro user guide to get background information, especially the XML introduction and the section on Configuration Files contents.

The easiest way to create a configuration file is to modify an existing one. In this section, we walk you through doing this.

Make a copy of a similar file.

Although you can call this new file anything you like, it will work best if you use the same convention as the provided files. That's "manufacturer name"_"decoder family".xml, for example: Digitrax_1x2.xml and Atlas_DualMode.xml

For the provided files, we use the same capitalization, etc, that the decoder manufacturer uses in their documentation.

This new file should go in the xml/decoders subdirectory in the JMRI User Files Location so that the program can find it. You may have to create this directory (including the xml/ directory above it) if it hasn't already been created. You can select "File Locations" from the JMRI Help menu to find (and open) the User Files Location. (See the configuration files page for further details about how to find that directory and its contents)

If you're modifying a decoder definition, it is best to start with the most recent version, which can always be found here on the JMRI website at https://www.jmri.org/xml/decoders/. That way, it won't be hard to merge your changes with ones that might have come before. Please don't do any more reformatting than you have to. If you change the tech stuff in the top 5 or 10 lines, or reformat the contents, it gets very hard to tell what's changed and what has not.

Edit the new file

Open the new file with your favorite text editor.

File contents: XML Header

You'll see something like this at the top of the file (the examples are from the 0NMRA.xml file):

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="../XSLT/decoder.xsl"?>
<!-- Copyright (C) JMRI 2001, 2005, 2007, 2-009, 2010 All rights reserved -->
...
<decoder-config xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://jmri.org/xml/schema/decoder.xsd">

Don't mess with these lines; they describe the format of the file.

File contents: Author

The next element describes the author and version of this decoder file:

<version author="jake@physics.berkeley.edu"
version="1" lastUpdated="20011201"/>

These attributes are only read by people, not the program, so their exact format isn't critical. But we encourage you to insert your email address in files you create or change, so that if anybody has any questions they can find you. The version and lastUpdated attributes provide a way of telling different versions of a decoder definition apart, so we'd also like you to update those. For a new file, set the version back to "1", and if you're modifying an existing file, increment the version attribute to the next number.

File contents: Decoder Family and Model
The next lines identify the "family" of decoders that this file describes:

<decoder>
<family name="Digitrax 1x2" mfg="Digitrax"
lowVersionID="240" highVersionID="242"
comment="Digitrax DH142, etc" >
<model model="DH142" numOuts="4" numFns="2"/>
<model model="DN142" numOuts="4" numFns="2"/>
<model model="DH083" numOuts="5" numFns="2"/>
</family>

The spacing is not important, but it is useful to indent the file like this to make it more readable. XML uses "elements" and "attributes" to carry information. The <model> things are elements; attributes like numOuts are set to specific values within elements. In the 2nd through 4th lines above

<family name="Digitrax 1x2" mfg="Digitrax"
lowVersionID="240" highVersionID="242"
comment="Digitrax DH142, etc" >

the element is 'family', with attributes 'name', 'mfg', 'lowVersionID', 'highVersionID', and 'comment'. An attribute is given a value with an equals sign and a value in quotes (the quotes are required). The order of the attributes is not important, and you can break them across lines if that makes the file easier to read. Note that all of the attributes must be inside the angle brackets, and after the name of the element.

In this element, change the attributes to match your new decoder:

  • name - the name of the decoder family. It's best if you use the same name here as you used in the filename.
  • mfg - the manufacturer of the decoder. It's best if you use the same manufacturer name here as you used in the filename.
  • lowVersionID, highVersionID - The manufacturer can load a version number into CV 7 of a decoder. Not all manufacturers do this, but if one is available the programmer can check if this file is being used with the expected decoder type. If only one specific value is valid, define the both lowVersionID and highVersionID with the same value, e.g. lowVersionID="123" highVersionID="123" If the decoder type can have any one of a range of numbers, for example because the manufacturer has made some updates, define both attributes to cover the range: lowVersionID="21" highVersionID="42" If you don't know the version number, don't define either of these attributes; just leave them off. lowVersionID defaults to 0, highVersionID defaults to 255, so together the defaults mean "any value".
  • comment - this is optional. You might want to include your name, or other info about the changes in the file.

The following lines:

<model model="DH142" numOuts="4" numFns="2"/>
<model model="DN142" numOuts="4" numFns="2"/>
<model model="DH083" numOuts="5" numFns="2"/>

allow you to list a number of different decoder models that can use this file. For a single decoder, remove all but one of the "model" elements, and give it the model name of the decoder. The numOuts and numFns are described later, but for now you can just delete them, leaving something like:

<model model="DH142" />

The model element can also contain lowVersionID and/or highVersionID attributes, which apply to just that model. If one doesn't appear, the value from the family element (or its default) will be used.

It is important to note that the 'family'+'model' combination must be unique. This is the only information that can be used to match a decoder definition to an existing roster entry.

  • There can be multiple instances of model 'x' but they must reside in different families.
  • There can be multiple definitions of family 'y' (in different decoder files) but model 'x' can only appear within one of these.
  • The 'family'+'model' uniqueness restriction applies irrespective of manufacturer.
File contents: Programming Modes

The next element defines what programming modes the decoder can understand:

<programming direct="byteOnly" paged="yes"
register="yes" ops="yes"></programming>

Paged, register and ops can be set to either "yes" or "no". Direct can be set to "no", "bitOnly", "byteOnly", or "yes". The programmer uses this information to select the programming mode to use when working with a decoder.

File contents: Variable names

The next part of the file consists of a set of 'variable' elements defining specific variables, nested inside a 'variables' (note the extra "s") element. An example:

  <variables>
    <variable CV="1" item="Primary Address" default="03">
      <decVal min="1" max="127"/>
      <label>Short Address</label>
      <comment>NMRA standard form</comment>
      <tooltip>Digitrax systems only address 1-99</tooltip>
    </variable>
            (followed by more <variable> entries)
            (Insert new ones at the end)
  </variables>

Each variable represents one thing to configure. They can represent a single CV, e.g. address, or a few bits that can be configured to control a particular function. If some of these aren't appropriate to your decoder, you can just remove them. Make sure you remove the entire element from the <variable> up to and including the matching </variable>. You can also rearrange them if you'd prefer a different order.

The attributes include:

  • item - The 'standard' name for this variable. See the discussion on the programmer definition page for more information on this. Generally, look at the Comprehensive programmer to find something similar, and use the "name" attribute of that.
  • CV - Which CV contains the configuration information for this variable.
  • mask - A pattern to control which part in the CV contains the variable.
    JMRI supports 2 types:

    A string like XXXVVVXX where each "V" is a bit that's included, and "X" is a bit that's not to be included. It's best to have eight characters, as that makes it clearer what's going on. If the variable is a full byte, the mask attribute can be omitted.
    Example:

    <variable item="Dim Lamp 3" CV="13" mask="XXVVXXXX">
    ...
    </variable>

    Generally, the V characters should be a contiguous block of bits as specified in the manufacturer's documentation for the decoder. In certain rare cases, the layout of the decoder might require a different pattern like XXVVXXVV, but in those cases please check the operation of the resulting decoder definition carefully to make sure it does what you want.

    A second mask pattern, Radix, is useful in cases where instead of bits, digits you enter make up a pattern such as 1234C where "1234" is a turnout address and "C" is some other variable. A Radix mask can handle CVs that are coded in bases other than binary: Ones that store their parts as decimal digits (as our example), or even base 3 or 5. That's a bit more technical, it's rarely needed, but if you do need it refer to the Advanced Decoder help page or the javadoc for more details. The Uhlenbrock_63410 definition provides an example on CV1.

  • default - The default value for this variable. This is used for a new decoder, or when you want to set the decoder back to its defaults.

(There are a few more, which we'll leave for the advanced section below)

The "label" included element provides a human-comfortable name for this variable. This is generally what the decoder manufacturer calls this item, even if other manufacturers or the NMRA use a different name for similar things. It is optional, in which case the "item" value will be used to label it when it's presented to the user.

The "comment" element let you provide additional information to future developers. This information is visible when editing the definition, but isn't provided to somebody who's just using DecoderPro.

The "tooltip" element let you provide additional information to the user when the user hovers their cursor over the variable on the screen.

File contents: Creating new Variable definitions

You can also define new variables. A good starting point is to copy a similar definition, change its item name to a new value, and then edit its contents.

To define how the new variable is displayed and edited, you add elements within the 'variable' element. There are several possible forms:

  • For a decimal value, you include a <decVal> element like the example above. The two optional attributes are min and max, which define the range of acceptable values. If you omit them, values from 0 to 255 are allowed.
  • If you'd rather enter and display values in hexadecimal, use a <hexVal> element. It's otherwise the same as the <decVal> element we've already discussed.
  • If your decoder supports a long address, you can add a <longAddressVal> element. It's perhaps easiest to copy this from another file, or from this example:

    <variable item="Long Address" CV="17">
    <longAddressVal/>
    </variable>

  • If your decoder supports it, you can enter a <speedTableVal> element for the speed table. Optional attributes are: "entries", "min", "max" and "mfx" (when true enables the Märklin mfx® style speed table). Example:

    <variable item="Speed Table" CV="67">
    <speedTableVal/>
    </variable>

  • Some decoder options are best represented by "choose one option". These are represented by the <enumVal> element. Example:

    <variable item="F6 during DC operation" CV="13" mask="XXVXXXXX">
    <enumVal>
      <enumChoice choice="Off"/>
      <enumChoice choice="On"/>
    </enumVal>
    </variable>

    Each enumChoice element describes one possibility. There can be as many of these as desired. For a one bit choice, you use two enumChoice elements as in the example. For a 4 bit choice, like the FX codes in a Digitrax decoder, you can use up to 16 choices. They are displayed in the order they are entered in the file, and are also numbered in that order. If the first is chosen, "0" is entered in the CV bits; choosing the second stores "1"; etc.

    If you need to specify a specific value for an enum option, add a "value" attribute:

    <enumChoice choice="Blue" value="32"/>

Including fragment files

Decoder definitions can include "fragment files" which provide common definitions of some CVs. This has the advantage that they're already created and tested, and often include tooltip text, translations and other nice features. See the existing decoder definitions for examples. Some key ones:

  • CV1, the primary or short address, CV17 and 18, the extended or long address, and the corresponding CV29 bits can be handled by one of these, depending on what the decode supports:
    • xml/decoders/nmra/shortAddressOnly.xml
    • xml/decoders/nmra/shortAndLongAddress.xml
  • CV19, the consist address and direction, can be handled by one of these:
    • xml/decoders/nmra/consistAddr.xml
    • xml/decoders/nmra/consistAddrDirection.xml
  • The CV16/CV15 decoder lock feature can be handled by the xml/decoders/nmra/decoderLockId16.xml fragment file. Note that only CV16 is included; CV15 should not be included in the definition to prevent it from being changed after decoder installation.

You can also use fragment files to include (hence simplify) common sets of enum choices.

Note that you should use the full format for an include statement so that JMRI can find it:

<xi:include href="http://jmri.org/xml/decoders/nmra/shortAndLongAddress.xml"/>

Checking for syntax errors

At this point, you've created a new configuration file!

You can check it for syntax by selecting the "Validate XML file" item from the "Debug" menu. It opens a file selection dialog; select your file and click "open". If all is well, you'll get a dialog box that says "OK". If not, you'll get a completely incomprehensible error message. About the only useful part of that message is the line number; open an editor to that line and try to see what's wrong with the syntax.

Add the file to the index

All that's left is to enter your new file in the index. This index is used to speed the startup of the program, when the list of available decoders is constructed.

Select the "Recreate decoder index" item from the DecoderPro "Actions" menu or the PanelPro "Debug" menu.

Congratulations! You're done. Next, open the programmer application and try it.

For more advanced information on the content of the files, please see the Advanced Decoder Definitions page.