NixTrainz Decoder Buddy Pinout Cross Reference for Various Decoders

The author is aware that this information is available on the NixTrainz website but it is a little hard to find and recently there has been some confusion about pinout matchups for different decoders. Table 1 below show the various decoders and the appropriate pinouts cross references to the Decoder Buddies.

                   Original            V5
Pin #          Decoder       Decoder     LokSound         SoundTraxx    TCS     Digitrax**
                   Buddy           Buddy         V4   (V5)            T2 & E2                        and
                                                                                        (21PNE8)                     NCE
  1                                         A10             (A10)                          

  2                                         A7                (A7)

  3                                         A6                (A6)                   (Fx8) 

  4                                         A4                 A4                      Fx6             F4            F4

  5                                         A12              (A12)

  6                                        A11               (A11)

  7               A0r                   A0r                 A0r                    F0r              F0r          F0r

  8               A0f                   A0f                 A0f                    F0f               F0f          F0F

 13              A3                    A3                  A3                      Fx5              F3            F3

 14              A2                    A2                  A2                      Fx4              F2            F2

 15              A1                    A1                  A1                      Fx3              F1            F1

 17              A5                    A5                  A5                     (Fx7)             F5*          F5
* Note: TCS functions 5 and 6 are not programmable, and will only output constant bright lights.

** Unavailable for comment

Table 1 Pinout cross reference

It is hoped that NixTrainz appreciates the repeating of their information.

---

If you have an idea for a blog post here, let me know. If I can comment on it, I will or I'll see if someone else can and post it. 

Digitrax Software/Firmware Updates for 27 July 2021

Digitrax has released a new SoundLoader version 2.5.3 which includes an updated version of DigiIPL version 2.9. Along with this update they have released the latest firmware update for the DT602 series of throttles dated July 15, 2021.

All of these updates are for compatibility with their new quad switch controller DS74. 

They are all available here.

Thanks to Ross Kudlick of the Digitrax-Users groups.io forum for the notification on this.

---

If you have an idea for a blog post here, let me know. If I can comment on it, I will or I'll see if someone else can and post it. 

Digitrax Prices Going Up

Digitrax is experiencing rising prices for all the components we use to build our products and our freight costs have increased, too. Labor costs are rising now and are expected to rise more in the coming years. Effective July 20, 2021 prices on all Digitrax products are increasing. Most items only went up a small amount but some went up significantly.

As you may have heard, there is a worldwide chip shortage which is affecting deliveries of components. Even though we have all the components we need for the next year on order now, we are finding that some suppliers are late shipping or unable to ship at all. For this reason some items may be temporarily unavailable due to supply chain disruptions that are beyond our control. We are working every day to keep up with this and prevent shortages.

Thank you for your understanding and your continued support.

- The Digitrax Team

---

If you have an idea for a blog post here, let me know. If I can comment on it, I will or I'll see if someone else can and post it. 

An Introduction To Digitrax's "Bushby Bit" (Updated 14 Jul 2021)

Below is an 'Introduction to the Digitrax command station "Bushby bit"'. Included is a description of the implications toward various types of devices which receive control information via LocoNet switch control messages or via DCC track signal "switch control packets". This is a post by Billybob experimenter who has contributed excellent information to this blog previously. He is welcome here anytime.

Billybob has tried to limit the "technobabble" by breaking it down into small parts, but it still seems to go on and on and on... If anything is unclear, log onto the digitrax-users group of groups.io forum, send a message stating which part is unclear, and Billybob or another list member will attempt to clarify.

Before directly addressing the "Bushby bit", there are a number of things to understand:

1. "Normal" switch control messages are sent using one LocoNet message type.
2. LocoNet defines an alternate message that can be considered approximately the same as a "Normal" LocoNet switch message.
3. While LocoNet device may send either type of LocoNet switch control message, most LocoNet devices that allow switch control are only able to generate switch control messages using the "Normal" switch control message.  Only a few can generate the "Alternate" switch control messaging.
4. A Digitrax command station will forward both types of switch control messages from LocoNet to the DCC track signal when the command station’s OpSw27 is "T"hrown.  This is the factory default value for OpSw27, and it means that the "Bushby bit" is disabled.
5. Because the DCC track signal must provide control information to locomotives, and because Digitrax engineers feel that controlling switches is of less importance than controlling locomotives, Digitrax places "higher priority" on mobile decoder control packets, and "lower priority" on switch control "packets" when making up the DCC track signal.
6. Control of some switch mechanisms require time between re-triggering, so Digitrax engineers implemented an OpSw setting to control "metering" of the speed with which switch control messages are forwarded to the DCC track signal.  This is generally controllable by OpSw31.  My notes show that different Digitrax command stations have different settings to disable metering, and that different command stations differ in whether metering is enabled or disabled when in factory default conditions.  See your command station documentation to determine correct settings and default values.
7. Because of the delay in propagating LocoNet switch control messages to the DCC track signal, the command station must implement a "buffer" to hold any LocoNet switch control messages until they can be propagated to the DCC track signal.  This buffer is not very big, perhaps with a capacity of somewhere in the range of 10 to 20 switch commands.  The buffer can "empty" only as fast as the "metering" setting allows.
8. When the command station's switch control message buffer gets full, the command station will report that condition via LocoNet, and it will not accept LocoNet switch control messages for later propagation to the DCC track signal until after the command station frees up space in the buffer by propagating a message from the buffer to the DCC track signal.
9. When JMRI sees that report that the command station buffer is full, JMRI's "retry mechanisms" kick in.  That is a whole separate discussion, which we will not go into here, but which is discussed in the JMRI help page for Digitrax hardware.  This link was previously presented in this thread, and was the source of the request for clarification of the "Bushby bit".

Now to address the "Bushby bit":

      a) Command Station OpSw27 is the "Bushby bit".  It is "disabled" by factory default 
           (i.e., OpSw27 = "T"hrown).

      b) As mentioned in 4) above, when the command station "Bushby bit" is disabled 
          (i.e., default state of OpSw27="T"hrown), the command station sends both 
          the Normal type of LocoNet switch message and the Alternate type of LocoNet
          switch message, and places them in the switch control "buffer", for later sending
          to the DCC track signal.

      c) When the command station "Bushby bit" is enabled (via command station
          OpSw27="C"losed), the command station only forwards "Alternate" type
          LocoNet switch control messages to the buffer, for later forwarding to the 
          DCC track signal.  "Normal" switch control messages are not buffered, 
          and will not appear on the DCC track signal.

      d) According to the Digitrax-users group's post #6426, the "Bushby bit" gets its
          name from "Strad Bushby", the person who suggested the concept to Digitrax. 
          If the author recalls correctly, he felt the feature would make certain aspects of
          controlling his layout a little bit easier and make certain aspects of his software
          design (non-JMRI) a bit easier.  Digitrax implemented the feature based on his
          suggestion.  (Once again, "Thanks Strad!")

What does all this mean for JMRI and Digitrax command station users?

• Enabling the "Bushby bit" can reduce and/or eliminate over-filling the command station's switch command "buffer", and this can reduce and/or eliminate the problems associated with JMRI's behavior when its "switch control message retry" mechanism kicks in.
• Per c) above, enabling the "Bushby bit" prevents the typical LocoNet device from controlling those things which are controlled by DCC track signal switch control "packets".  (See also the last bullet point below.)
• JMRI provides mechanisms so that JMRI "Turnout" objects it controls can send either "Normal" LocoNet switch control messages, or "Alternate" switch control messages.  In JMRI, this can be controlled on an individual JMRI Turnout basis, by a "system-specific" setting for each LocoNet Turnout object in the JMRI Turnout table.
• For those devices which are controlled by DCC track signal switch packets, if the command station Bushby bit is enabled, JMRI will only be able to control those devices which have been configured to be controlled via LocoNet "Alternate" switch control messages, because of the command station behavior described in item c) above.
• A JMRI LocoNet turnout may be configured to send the "Alternate" LocoNet switch control message type via a checkbox which is available in the JMRI Turnouts table.  Enable the "system specific columns" checkbox at the bottom of the Turnouts table to see the "Bypass Bushby Bit" column of checkboxes.  For any turnout which must get its control information from the DCC track signal (When the command station Bushby bit is enabled), the "Bypass Bushby Bit" checkbox must be checked.  This configures JMRI to use the "Alternate" LocoNet message type when JMRI controls that specific Turnout.
• Some hardware, including the Digitrax SE8C, can get its switch control messaging from either the "low-power DCC track wires" on the LocoNet cable.  Such hardware's operation will be affected by the "Bushby bit" if it is getting control messaging from the LocoNet "low-power DCC track wires".  Careful configuration of the JMRI "Bushby Bypass Bit" settings for any JMRI Turnout associated with that hardware can enable proper DCC control of that hardware when the command station "Bushby bit" is enabled.
• Some hardware, including the Digitrax SE8C, can be configured to get its switch control messaging from the "LocoNet data wires" on the LocoNet cable, instead of the LocoNet cable "low-power DCC signal wires".
• If the command station "Bushby bit" is enabled, and the specific hardware devices are configured to get switch control messages from the "LocoNet data wires" (as noted in the previous bullet above), those messages will not need to be placed in the command station's switch message buffer. Configuring for JMRI control of such hardware via "Normal" switch control messages will reduce the traffic thru the command station switch control buffer, and therefore reduce the likelihood that the buffer will "overflow".
• JMRI's control of SE8C signaling, especially with large signaling installations, but also with smaller installations which use "Flashing" indications are a common source of switch message traffic which can significantly contribute to overflow of the switch control message buffer.
• To avoid this occurrence of SE8C messages overflowing the buffer (as noted in the previous bullet above), enable the command station "Bushby bit" and configuring JMRI's Turnout objects associate with the SE8C(s) with the "Bypass Bushby Bit" un-checked will prevent SE8C messages from being placed in the command station switch message buffer.
• Remember - when the command station "Bushby bit" is enabled, it will be impossible for a typical LocoNet Throttle to control a switch which is controlled via the DCC track signal.  If you need a Throttle or other LocoNet device to be able to control a DCC-signal-controlled accessory device via switch messages, other techniques are required. Those techniques are related to, but beyond the scope of this "introduction to the Bushby bit".

The author hopes that "clears up" at least a few things about the "Bushby bit" and its impacts on JMRI and the benefits when used with JMRI.

Regards Billybob

<UPDATE 14 Jul 2021>

I expect that JMRI test release 4.25.2 (not 4.25.1, which apparently is imminent!) will include a sample Jython script which can provide "Bushby forwarding".

By "Bushby forwarding", I mean:

The script "monitors" LocoNet messages, and, for those "normal" turnout control messages associated with specific (user-defined) turnout addresses, sends a corresponding "special" LocoNet turnout control message.

This Jython script can be modified by the user to specify which turnouts qualify for forwarding.

If plans work out, 4.25.2 will become available some time after 18Aug.  Of course, that is simply a target, and many things can push that date back...

But you can get the script via JMRI's on-line help under the "Examples" link on the "Scripting" page.  From there, the curious user can cut-and-paste into the script entry window, or cut-and-paste into a new file.

Examples page:
https://www.jmri.org/help/en/html/tools/scripting/Examples.shtml

Specific help on the Bushby script:
https://www.jmri.org/help/en/html/scripthelp/LnBushbyForwarder/LnBushbyForwarder.shtml

The script itself: https://www.jmri.org/jython/LnBushbyForwarder.py

Regards Billybob

---

If you have an idea for a blog post here, let me know. If I can comment on it, I will or I'll see if someone else can and post it. 

Reverting To Previous Digitrax Firmware Versions (Updated 2021-08-09)

The following is from a discussion on the groups.io Digitrax Users Forum concerning the updating of the UR93 firmware. The answers are provided by billybob experimenter who is a frequent guest poster on the Hostlers Inn. This is excellent information but is filled with "technobabble" so be prepared.

On 4/15/2021 8:44AM, Ross Kudlick wrote:

I suggest you check your UR93 and update if it doesn’t have the latest firmware.

Billybob replied:

All these firmware versions report the same version information in DigiIPLII's "Find Devices" tool. As such, there is no convenient way for a user to differentiate between firmware from February, March, or April of this year (or previous releases!).

What to do? If you have a UR93 with "unknown" firmware version, I recommend that you update the UR93 using the latest firmware from the Digitrax "Downloads" web page, and then mark the new firmware's filename on a sticker and attach that sticker to the UR93.

But how do you prevent older revisions from overwriting a newer revision you already have on your device?

The ability to "revert" firmware versions was available with DT402-series throttles and DigiIPL.exe, and was, in a couple of cases, very important when a rather "buggy" DT402-series throttle firmware release got "into the wild".

I investigated DigiIPL many years ago and discovered many things about the Digitrax firmware update process.  Unfortunately, much of this is "technobabble".  If you don't like technobabble, the remainder of this message is not for you!

The investigations I did many years ago, long before DigiIPLII.exe existed, revealed these things:

KEY FINDING

A firmware update would be "allowed" if the "major portion" of the version number of the firmware currently installed on the device was less than or equal to the "major portion" of the version number of the firmware-to-be-installed; you cannot "revert" to a firmware file with a "major portion" number that is less than the "major portion" number of the firmware already installed in the device.

Figuring out a device's installed firmware's Version number

A firmware update would be "allowed" if the "major portion" of the version number of the firmware currently installed on the device was less than or equal to the "major portion" of the version number of the firmware-to-be-installed; you cannot "revert" to a firmware file with a "major portion" number that is less than the "major portion" number of the firmware already installed in the device.

• that the device makes the decision to accept or ignore the firmware update based on the "major portion" of the version number, without any extra help from DigiIPL
• that the device does not provide any sort of feedback to DigiIPL, whether accepting or ignoring the firmware update process
• that the device that accepts a firmware update does not provide any sort of feedback to DigiIPL about the success or failure of the update process

As described above, a key part of the process is the "major portion" of the version number.  What is the "major portion" of version number, you might ask?

There are two parts to this, what is the "major portion" of the version number of a given firmware file, and what is the "major portion" of the version number of the firmware installed on a device. I will handle them in this order, as the first part is easier to explain.

Figuring out the firmware's Version number

Unfortunately, you cannot rely upon Digitrax to give you the "version number" information.  For various reasons, the version numbers reported on the "Downloads" page of the Digitrax web site sometimes do not match the version numbering in the firmware file. Luckily, one can easily determine the actual version number, and from that, the "major portion" of that version number, using the DigiIPLII program. This is a fairly easy part!

Start DigiIPLII. In DigiIPLII, "Open" the firmware file for which you wish to find the "major" version.  Look about in the center of the DigiIPLII window and find the reported "SWVer" number.  Take that number and divide by 8.  The result gives the "major portion" to the left of the decimal point, and the "minor" portion to the right of the decimal. To get the major number, it is simply a case of ignoring all of the digits to the right of the decimal point of the result of the division! Note that the "major portion" of the firmware file's version number can be 0.

As an example: The most-recent DT402 firmware file (10-16-2016), DigiIPLII.exe reports "SWVer 17" when loaded into DigiIPLII.  Take the (decimal) number 17, divide by 8, and get a result of 2.125.  Ignore every digit to the right of the decimal point, to get a major portion of "2".

In extreme technobabble, Digitrax seems to define their version numbering as "major" number and "minor" number.  They encode this information into a (7-bit?) value which combines the two into a single number.  The "major" number is the upper (4?) bits of that (7-bit?) number, and the "minor" number is the least-significant 3 bits of that (7-bit?) number.

But you do not (necessarily) need to worry about that extreme technobabble.  Often, but not always, you can retrieve the version number, or even the "major portion" of the version number, directly from the device itself:

• The DCS52, DT602-series, and UT6-series throttles all report Version number, Subversion number and date code as part of their power-up display sequence.  For our purposes, only the Version number is important, and the "Major" portion of the version is the portion that is to the left of the decimal point of the reported Version number.

• DT402-series and DT500-series throttles report the version number directly, in the first second or two of the power-up display.  The version number shows up as a pair of digits on the right-hand end of the same line as the device type display, such as "DT402D21" or "DT500 01". For these devices, the "major" revision is the left of the pair of version digits, so for the examples, the DT402D had major revision 2, and the DT500 had major revision 0.

Recent (firmware-updatable) command stations and recent (firmware-updatable) boosters may report their version number information via a DT500-series throttle using the "Query Mode".  This is not a particularly reliable mechanism because of idiosyncrasies of the Query Mode process, and it can be difficult to get the desired device when there is more than one "query-mode-capable" device on LocoNet.  If you can use Query Mode to get to the "SWver" display, and it is for the desired device, and it is showing non-zero data for other aspects of the device, then the "major portion" is the number between "SWver" and the decimal point.  For example, "SWver0.1" has a major revision of 0.

If you cannot get a LocoNet device to display the version information, and you cannot get it via "Query Mode", you can try to get the info via DigiIPL/DigiIPLII's "Find Devices" feature.  If the "Find Devices" feature finds the device you are interested in, then the "major portion" is that portion of the "S/W" number that is to the left of the ".".

Some Digitrax devices do not have a display and do not respond to the "Find Devices" request, so there is no (known to me) way to retrieve the firmware version information.  I have not stumbled upon the trick for determining the firmware version information for the LNRP that I have in my collection.

Summary

If you have real version numbers (not the confusing junk found on the web site!) for the firmware in the device and for the firmware you wish to install, compare the "major portion" of the version numbers.  You can install a given firmware file if the firmware file you are attempting to apply has a major portion number which is equal to or greater than the major portion of the firmware version number that is already in the device.

One can easily try "reverting" a device's firmware if one has "collected" the various firmware files that have been released on the Digitrax web site.  It is my expectation that the basic rule described in the preceding paragraph will hold true.

Regards,

Billybob

<Update 2021-08-09>

The following information was provided by Lynn Grandle of the Digitrax-users.groups.io forum in response to this post:

"I can tell you from personal experience that you can load an old version of firmware in at least a UR92 if you have bricked them.  They are setting in the IPL state and have no clue as to their last firmware version.  I too was in the computer industry for more years that I want to count -- laboratory hardware and software development( both the software and hardware).

I also agree that if you want to load an older version of the firmware, that starting with the first firmware load and going forward is the best way to do it. 

But from what I have seen so far in loading firmware I do that think that the Digitrax loader is an incremental( patch) loader --- i.e. it appears to want a complete package not patches.  I also believe that there is a bug in their loading code that has a problem checking the firmware version that it is loading, if it actually does the check as stated in the web post (Author's Note - meaning this post).  I suspect that reloading the same version of firmware on a working Digitrax device will brick it.  I bricked at least 3 UR92 that way. Just some observations, from personal experience.  Actually, unbricked them by loading older versions of the software.  Then they upgraded correctly."

Thanks to Lynn for this additional information.

---

If you have an idea for a blog post here, let me know. If I can comment on it, I will or I'll see if someone else can and post it