I chose to use Tortoise slow motors to change the turnouts/switches from Clear to Thrown. It takes ~4 seconds to change from one state to the other. As a result the turnouts have three states (Clear, Thrown and in between). The laptop JMRI program needs to know what state the turnouts are in so a train can safely run across a turnout. Depending on how far ahead a turnout is changed, the train can reach the turnout and derail if the turnout is not properly set or in motion, so the three states of the hardware need to be reported to the laptop in real time.


There are several ways this could be done in hardware (HW) and or software (SW). Each has advantages/disadvantages.

  1. Of course the SW knows when a command has been sent to change a turnout. The delay in reaching the new state could be accounted for in SW. 
    • There is an assumption that SW commands sent to HW are executed.
    • From what I read this delay in status change would need to be added to the JMRI software.
    • With up to 4 trains, using a sleep function, etc. to incorporate the delay is an issue. Effectively adding threading/parallel processing to JMRI sees to be a major effort.
    • At different times each train could trigger changes to 3 turnouts. That delay, ~4 seconds each, could be a problem. Worse case each train could trigger turnouts at the same time. Depending on the situation and programming a 4-48 seconds delay.
    • Using the Wabbit's "Smart Rout" to change several turnouts with one command/address creates a problem. This complicates the SW by
      • requiring each turnout being controlled individually, not using the "Smart Rout" ability or
      • updating the status of several turnouts in SW when a "Smart Rout" is used.


  1. Use one of the two HW outputs from a Wabbit to provide feedback about the state of a turnout. This could move the SW delay process from the laptop/JMRI to the Raspberry Pi using interrupts to detect changes and threading to manage the delay(s). The three states, Clear, Thrown and unknown, require 2 sensors reporting to the JMRI software, Clear, Thrown and NOT clear/NOT thrown. When a command is received by a Wabbit, the feedback changes state. 
    • Raspberry Pi SW could control 2 DCC++ sensors for each turnout, setting one high the other low based on the Wabbit feedback. A sensor would be set low immediately when the feedback changes, but delay setting the other sensor high. This results in the needed three states, one or the other sensor high or both low (unknown).
    • Using feedback from the Wabbits resolves the "Smart Rout" issue.
    • JMRI has a process to associate two sensors with a turnout. How to associate two DCC++ sensors, one high/one low, with a single HW sensor is an issue.


  1. Use both outputs of a Wabbit to provide feedback about the status of a turnout. The two outputs, one high one low; Clear, Thrown, both change state immediately when the Wabbit receives a command. The Raspberry Pi could use interrupts to monitor the Wabbit feedback lines and threading to manage the delays when going high.
    • Using HW feedback from each turnout resolves the "Smart Rout" problem.
    • Each Wabbit feedback line would be associated with one JMRI sensor. No JMRI mod required.
    • When a feedback line goes low that would be reported immediately. When feedback line goes high there would be a delay before changing the associated sensor, introducing the needed three states. Threading can be used to handle the delays.