JMRI - Hardware needed for Signal Switches

[surfingstephens]

I am using JMRI software and a SPROG controller  to control my layout.    I have all my Kato switches (using the Digitrax dcc soldered into switch itself)  and Trains being operated via the software.    What I want to do is show a red/green light for my switches to show thrown or not.   What I am thinking is there must be a dcc decoder of some sort I can hook into that will control the lights for the switches.     I have seen the write ups of wiring your Kato switch to turn the light red/green, but my thought process is why not have the JMRI software change the light and the switch together?       

 

I am overwhelmed at this point with all the signal head stuff etc.    Could someone point me in the general direction of:

   1. What piece of hardware is needed to work with JRMI to set red/green switch light.  (Pretty sure there are multiple ways to go, just recommend something, I am all ears)

   2. What pre-built red/green light is on the market I can buy for each switch?   (I can solder anything, but would rather not build them, I have a LOT of switches)

   3. Brief explanation of how to configure it in JRMI?  Just a high level of how a light switch is associated with the turnout switch.

 

 

If you have some of the answers to the above please feel free to respond, just trying to zero in on what I can use. 

 

Many Thanks...

 

 

[kvp]

The easiest would be to add bipolar turnout decoders with continous output for driving the leds and just set them to the same addresses as the turnouts. These are originally meant for turnouts with mechanical end switches but work great with 2 wire pipolar leds (just add a current limiting resistor to each red/green led). No extra programming is needed and the leds will switch with the turnouts.

[surfingstephens]

Thanks, Anyone else on the above questions??

 

I did just find this item that looks like it might be what I am looking for:

http://www.digitrax.com/static/apps/products/detection-signaling/se8c/documents/SE8C.pdf

 

It mentions it works with JMRI

​

[inobu]

SS,

 

Signaling is Advance Layout Operations and it's not easy. It requires logic to determine and operate lighting conditions in multiple directions. That logic has to be created and implemented. I think you are taking the easiest route by using Digitrax. The problem is it is going to be expensive.

 

I choose Digitrax DCC system because they pretty much covered/support all of the signaling configurations found in modeling. This eliminated the need to search for components or spending time trying to create/build the components yourself. It is easy to "say build this or that" but getting it done is another story. If you want to get it done you found the right component (SE8C). 

 

My suggestion to you would be to get a Digitrax Zephyr. This will allow you to use their products (LocoNet) to configure your system. I used the Zephyr with JMRI using a touch Screen PC for the control panel and Ipod's as throttles. Using the DS64 was easier than wiring the decoders to the switches. It is costly but I got the system up and fully functional. Many choose to build their own to save money but very few are successful in getting it completed. 

 

Getting to your Answer 1 and 2

 

 

You will need to get the BDL16 occupancy detectors to run in conjunction with the SE8C. The BDL16 will broadcast whats is in the area giving the first variable. The SE8 records commands sent which allows it to track signal conditions. The commands that are sent to thrown the switch is what controls the Head (light) states.

 

JMRI Has 2 Sides

 

JMRI has the Decoder Pro which is the decoder programming tool and Panel Pro the visual operating interface. 

 

Decoder Pro will allow you to configure the decoders to operate the switches and to input the settings into the SEC8. This will allow it to operate the HEAD lamp based on commands sent to operate the switches.

 

So you will need to create your layout design document. This document/drawing will have all the switches in there respected location so you can assign numbers to them. These numbers will allow you to manage them in the programming step. There is a worksheet on page 16 (Digitrax Signal Location Record)

 

Trying to give a high level overview is difficult. So here are a few screen shots. 

 

 

 

 

 

 

Remember there is a logic map that drive the lights. You need to create that map and load it using Decoder Pro. Next you will need to use Panel Pro to display and operate it.

 

Here is an image that gives a correlation of the two components of JMRI.   

 

 

 

 

I started with the basic component and got them working one by one on a test board. Afterwards I move it to the layout. It was time consuming but it was a lot of fun getting there.

 

Inobu

 

 

 

 

 

.  

Edited February 15, 2016 by inobu

[surfingstephens]

Thanks for the help.  I have few questions..

 

My suggestion to you would be to get a Digitrax Zephyr. This will allow you to use their products (LocoNet) to configure your system. I used the Zephyr with JMRI using a touch Screen PC for the control panel and Ipod's as throttles. Using the DS64 was easier than wiring the decoders to the switches. It is costly but I got the system up and fully functional. Many choose to build their own to save money but very few are successful in getting it completed. 

 

Trying to get this:   I have seen a video where someone is using JMRI and also has a second controller for Digitrax plugged in at the same time.  JMRI sees both controllers(Digitrax and Sprog) and basically lets you work each individually or both together.  You essentially have two command stations plugged in.   I suppose each is sending it's own signals(Is this right?).

 

So, 

    1. Sprog connects to pc via usb and to pc.   Then the output connects to the main bus.     (this controls the train and switches via the the JMRI software.   (This is what I have today.)

    2. Add a (Loco net connector) plug into second usb port on the pc.    Use JMRI to handle this as well.  

 

 

   Here is a video where some guy is doing just this: 

 

 

 

     1.   http://jmri.sourceforge.net/help/en/html/hardware/loconet/LocoBufferUSB.shtml

OR

     2.    PR3XTRA SoundFX USB Decoder Programmer (This guy seems to also allow you to have your computer hook up to JMRI and handle Loco net??)

 

Not sure I understand ​why I need the zephyr?   How does that relate to using JMRI to control things??     Is the Zephyr just used to facilitate the programming of the digitrax equipment, but not really for the operating of it?

 

 

2nd question  -  More a statement.  To get started I think I at least need the following pieces

    1. Power supply for the digitrax boards  (recommend anything?)

    2. SE8C  (sounds like is does not require Loconet to work?)

    3. ​​BDL16  (block sensors)  These are not available anymore.  Here is what Digitrax states....BDL History:  BDL16 was released in 2000 and was replaced by BDL162 in 2002. 

 

Anything else?

​

I definitely seems it is learning by doing hard to describe with the written word.   Just making sure I buy the right components to get started and then I will figure it out.   I am fully using JMRI today with graphical screens for all the switching and have used the remote throttle as well with some old apple gear.

​

 

 

Thanks on the tip on the Decoder Pro vs. the Panel Pro

Edited February 15, 2016 by surfingstephens

[surfingstephens]

I can see why this is the Dark Side of DCC and electrical.  After much reading I definitly am going to set up a test area to get this figured out.  Here is what I "think" I need to get started.

    1. SE8C Digitrax Board   (This thing appears to be very cool.  It does NOT require loconet, but does work with it.  It does do signalling and also appears to handle block detection as well(not sure about his as it may receive signals from the BLD168)   

    2. PS14  (Power supply for the board above)

    3. PR3XTRA  (this guy allows me to go from a usb connection to a LocoNet type connection which will plug into SE8C)

 

    4. BLD168  - Not sure if I need this.  I think this guy is to handle the block detection and then send the signal to the SE8C to process?    It also needs a PS14 power supply.

 

 

So I am going to set up some test track that will use a Sprog controller, SE8C, PR3XTRA, and JMRI to run it all.      With this, I should be able to do Signaling, block detection and run it all with JMRI.

 

 

Stop me if I am off track somewhere.  Will take a break from my 3 hour web reading session and purchase the parts later tonight..

 

As I put this test track together with all the wiring and components I will take some pics and document....  It does look to be quite expensive.  

Edited February 15, 2016 by surfingstephens

[inobu]

The inter-operate-ability between DCC manufactures are functional but there are some quirks that exists. Sometimes it can lead to wasted time and money trying to make things work. I suggested the zephyr because it gives you the best bang for your buck. It'sa fixed throttle and command station that you can build around. Because it is Digitrax you know the components will work 100%.

 

• Chances are they had one command station and the other configured as a boosters/repeaters on the layout.

 

Notice the Zephyr is pretty much a Kato Controller with buttons. You can use it to control a yard at the same time run it as a command station. It simplifies the control for anyone yet gives you DCC operations. You will be able to grow it in any direction.  You don't need it, It just makes it a lot easier in the long run. I have it and the NCE power cab and see that the Zephyr's good for the beginners to control things.   

 

 

 

The BufferUSB is better than the PR3 but I just stuck with the PR3. After I got things working I saw that either one will work.

 

You don't need a Zephyr its just easier to grow your layout feature sets with it. Remember the feature sets are based on the command structure of the manufacture. The manufacture are required to open the basic command sets. Many of the special features are controlled by their specific command structure. This is part of the reason some decoders do not program well on the main line operation.  

 

Here is an example.

 

Start your JMRI with the SPROG selected. Look for the at the SPROG pull down. There is no configuration for the SE8C.

 

Select Edit menu, Open preference, change manufacture to Digitrax, Set system connect to Loconet PR3 and select a port, save and restart. 

 

JMRI is running Digitrax look and the LOCONET pull down and you will see all the components including SE8C.

 

This will simplify you configuration.

 

 

Essentially JMRI gives you the ability to generate commands via a PC interface rather than the LCD throttle/controller.    

 

2nd question

 

1. To be on the safe side I just bought Digitrax power supplies just because I wanted to plug and play (more so plug and figure out). After which if I need another power supply I looked for a cheaper one.\
2. You are correct but it will be easier if you did have it.
3. Yes its the 168

There is a guy on you tube that has a video on his setup. search for DBL168 (Detroit River Railroad)

 

Inobu

Edited February 15, 2016 by inobu

[inobu]

OK,

 

Yes, I see he is using two different JMRI connections. NCE and Digitrax Loconet. Which it can work but this alludes to my initial point. I chose Digitrax because they the most features and I felt it more advantageous to stick with one manufacture. Try looking at Detroit River Railroad you tube videos. Organization is key

 

Inobu

Edited February 15, 2016 by inobu

[kvp]

One bit of advice: if you try to use two command stations on the same loconet bus, make sure that only one is connected with a 6 wire loconet cable and the other one only with the 4 center wires as the two side wires are the actual DCC signal and they should only be driven by a single command station. The other one can usually be set up as a slave unit, essentially as a throttle and dispatch panel.

 

On the other side, getting a single usb to loconet adapter, a booster and a bunch of throttles will get you a working DCC system without a command station as everything can be done on the computer side as long as the adapter has a loconet bus pullup and DCC signal generation capability. Using a computer as a command station also makes it easy to talk in any of the available protocols, including even SX (which isn't even DCC) if the booster(s) support it. Optional extras are separate loconet bus with DCC signal for the boosters and block detectors and another one with fixed power in place of the DCC signal for the throttles and other accessories. It's also possible to use a separate programming track output for programming locomotive decoders and wire connected accessory ones. Of course, a good command station can be used instead of a computer, but imho it's harder to keep them up to date.

[inobu]

He posted the video and it shows 2 USB interfaces not 2 command stations. It appears that the example is using the LOCONET as a sided system. If he uses all of the Digitrax components withing that loconet system he should not have a problems. 

 

Inobu

[surfingstephens]

Thanks for the help guys.  I am going to start with the LocoBuffer USB, SE8c.   I am going to set up a small section of track with two switches and signals and set it up to play with it.   Later I will then set up some power blocks and try that out.

 

KVP, If I were to go the route you are suggesting, I would just find a booster (recommend one) and then PC (JMRI using the locobuffer ) is essentially the command center right.  Did I get that correct?

 

 

I am having trouble letting go of my sprog because it has been great with JMRI.  It is a power unit and command center in one and with JMRI I can control all my trains and my switches today.  It has worked great.    However, I guess since I already have purchased the locobuffer, all I need a is a power source and then I can stop using the sprog and move over to this other method.    I get that running two "different" systems is potentially making it overly complex.  

[kvp]

The locobuffer is loconet only and can't generate the dcc signal into the loconet bus, so it can't be used instead of a command station. Imho you should keep your existing setup as switching to a single usb loconet/railsync (dcc) gateway is not needed in this case.

[inobu]

Unfortunately, IT will  I think the existing setup is going to be challenging. The switches are on one side and the signaling system is on the other side. The 51's are controlled by SPROG DCC.

 

Inobu

 

It is hard to point out issues after the fact as it does no good but not pointing out issues when you see them has its own issues.

 

Explanation as to why the setup is challenging.

 

The usage of the DS51K presents a problem in that the turnout is controlled by the DCC signal. In the existing setup the SPROG is the command station issuing the switching command. The SE8C signaling system will be isolated in its own network (Loconet) and will not know when the switch it thrown because of this separation.

 

Typically the SE8C works with the DS-64 (DS51K replacement). Because it is within the same system its operation is handled within Loconet. When using the SPROG as DCC command station and the DS51K it is isolated from the signal system (SE8C, BDL168 and Loconet). 

 

It will take a lot of finagling to get it going you will have to go into the advance preferences in JMRI.

 

Although I don't have the DS51K I will try to setup a test bed using my NCE. It will be interesting to see.

 

Inobu

Edited February 16, 2016 by inobu

[kvp]

If you only throw the turnouts on the JMRI screen, then they will stay in sync even with two separate systems. If you want manual buttons too, then it would be a better idea to use a single command station with USB and loconet connectivity and connect everything to this point. That would make sure that the command station and JMRI will know about all turnout throw commands.

[inobu]

 If you want manual buttons too, then it would be a better idea to use a single command station with USB and loconet connectivity and connect everything to this point. That would make sure that the command station and JMRI will know about all turnout throw commands.

That would mean getting a Zephyr........

 

but the issue is the DS51K

 

Inobu

Edited February 16, 2016 by inobu

[kvp]

If a turnout decoder is running from DCC and not loconet, it just means that the command station has to keep the DCC signals in sync with the loconet status and all throwing must be done through the command station. (either from hand controllers, control boards or a computer) The command station must support this loconet-dcc translation for accessory decoders. Most of them do, so i don't see a problem as long as the command station speaks the data format of the decoders and emits all DCC turnout throw commands towards the loconet bus too. (actually this means it emits the DCC for the DS51K and at the same time a loconet message for decoders like the DS64 so the SE8C-s can read it) An alternative is to throw the turnouts with loconet commands only and get the command station to translate this into DCC commands for the DS51K. (only acting as a loconet-DCC gateway) This may require a loconet based turnout/signal control board though.

 

Getting DCC based signal decoders is also an option, which will operate without a loconet bus and see all the DCC turnout control signals. This will work with any DCC command station, including ones not supporting loconet at all. There are very good turnout, signal and other accessory decoders running with the DCC signal only. (there are no block detectors though as the DCC bus is mostly unidirectional) This method (with the ancient S88 occupancy detection bus added for feedback) is the common setup for most european DCC systems that lack the flexible loconet bus.

 

The third option is switching to a loconet only system and replacing the DCC based turnout decoders, but this could get expensive.

 

ps: You are right that the cleanest solution is having all data on the loconet bus and using the DCC signal for the locomotives only and even taking this DCC info from the loconet railsync wires with loconet based boosters. Actually, this is the suggested setup for modular fremo layouts.

[surfingstephens]

Ok guys, when I get the equipment in the next week or so(ordered last night)   I am first going to attempt to do this with the equipment I have.    Use the sprog to control the trains and switches, use the loconet to control the signalling.  I think I can make it work becaus JMRI will know what signal is associated with the swtich and has the ability (I think) to throw the switch with the sprog and then also send a message on the loco net to change the signal for that switch.   Might as well start with the equipment I  have on hand first and see what I can do and then go from there.  I will shoot a video and some pics to share the results.

Jim

[inobu]

Yes, use what you got as it will allow you to see what is what. There a lot more to it........ which is what I was trying to convey earlier.

 

The answer lies in the rail sync connection. There are grounding requirements for some system that will allow the rail sync data transfer to work.

I know for me, the best way to learn is to do it yourself.

 

Inobu

[surfingstephens]

Yes, use what you got as it will allow you to see what is what. There a lot more to it........ which is what I was trying to convey earlier.

 

The answer lies in the rail sync connection. There are grounding requirements for some system that will allow the rail sync data transfer to work.

I know for me, the best way to learn is to do it yourself.

 

Inobu

Agree.  I think at this point I need to learn by doing a bit to get my arms around this.  I have to ask what is the "rail sync" connection?  I saw that in diagram and it is mystery to me what that is?

 

Part of my problem is I have never used digitrax equipment so I lack some of the terminology of it.      I did see the the grounding requirments and that seems to be something unique to digitrax?   

[kvp]

Rail sync is in the two side wires of the loconet cable and usually contain a low voltage and low current copy of the main dcc signal (~12V, 0.5A). Many loconet throttles use it to power themselves and a dedicated throttle loconet cable may just have 12V DC in place of the signal. Loconet boosters simply amplify the railsync signal to track voltages and currents (14-16V, 1-8A) depending on the selected scale and booster power.

Edited February 16, 2016 by kvp

[surfingstephens]

Rail sync is in the two side wires of the loconet cable and usually contain a low voltage and low current copy of the main dcc signal (~12V, 0.5A). Many loconet throttles use it to power themselves and a dedicated throttle loconet cable may just have 12V DC in place of the signal. Loconet boosters simply amplify the railsync signal to track voltages and currents (14-16V, 1-8A) depending on the selected scale and booster power.

I understand.  I find it amazing that we are chatting and you are Hungary and I am Texas  Every now and then it reminds how crazy great the internet can be.

[kvp]

One more thing: Connected grounds are only required if you are using impulse adapters instead of isolating safety transformers. In this case the booster grounds have to be connected and all boosters have to operate from the same AC phase.

 

With isolating safety transformers and optically isolated boosters there is no need for the common ground as power districts will float and equalise on wheel contact. Most commercial equipment lacks the optical isolation though, so the digitrax common ground method is a good fallback strategy but may trigger ground fault equipment if not powered through the same braker.

 

The usual advice is to plug everything into the same switchable power strip and turn on and off everything at the same time. Adding a ground fault and an overcurrent breaker before the strip can also save lives in case one of the chinese adapters fail into a short.

[kvp]

I find it amazing that we are chatting and you are Hungary and I am Texas Every now and then it reminds how crazy great the internet can be.

Me too. About two decades ago it took around two days for a newsgroup post to get from Hungary to the US west coast over uucp and another two for any answers to get back. A few years later when i got my degree the university mainframe was doing a sync every hour if the stars were right and the sat link was up so it was possible to have a faster conversation with the several thousand people already on the net.

 

Today i've sent the post you replied to from my phone while i was riding on a tram that is equipped with a realtime information system and phones can show the location, speed and expected arrival times of all public transport vehicles in the city in real time. And all these technologies were invented within a few decades.

[inobu]

SS,

 

I try to give advice based on the things I know and have done myself. In this case I know that it is easier to stay with Digitrax equipment. Because it may not be practical for all situations I'm going to test your configuration. I think it is a good exercise also.

 

I think there are varying limitations in who (throttle, JMRI, Loconet) will control the switches and how it will be updated. It is easy to tell you to send the update to the loconet equipment. Telling you how to do it is hard and what counts. I'm curious to know myself so I'm going to do it myself. Doing harder

 

Inobu 

Edited February 17, 2016 by inobu

[inobu]

Findings

 

It appears that some Loconet devices have a selection priority. If there are two inputs (DCC and Loconet) then the device will default to Loconet. As suggested this creates a problem as the DS51K will be operating on the DCC network. If the SE8C operates in the same manner then it will never see the operations on the DCC side because it is monitoring the Loconet. 

 

The SE8C can control switches but it does not state if it can operate momentary switches its only mentions tortoise.

 

For basic DCC control the DS51K are ok but not for highly automated operations.

 

It think it best to create a design document with all your feature requests and see it your current components can support it. 

 

Inobu

 

I will continue with my test config.

Edited February 17, 2016 by inobu