Search The Inn

Wednesday, July 14, 2021

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. 

No comments:

Post a Comment