Skip to main content

This is my first post on OGR, so please be kind. : )  Some brief info about myself.  I grew up with a 4x8 HO layout that my father and I built.  That layout is long gone, and I gave up the hobby for many years while I pursued a career in systems programming/architecture, started a family, and purchased a home. I am finally in a position with my own 16x23 room in my basement for a permanent layout.  We always ran my grandfather's O Gauge set around the tree at Christmas.  I grew an appreciation for the level of detail and functional accessories available for O versus HO at an early age.

I have spent the last 2 years refining a three-level layout for my space featuring a switching yard with 2 spurs for incoming breakdown and outgoing staging, turntable, and every aspect of the PA coal business in the 1940s-60s from mining, coking, to distribution.  High level objectives are min O-72 on mains and O-54 on yards.  Three passenger stations are in the layout.

Given the number of switches in the design it would be extremely difficult for a single person to operate multiple trains concurrently.  What is needed is automation.   Given my background, the electronics aspect of the hobby really interests me, and I am looking to apply programmatic solutions to this problem.  I have researched options and here are my conclusions.

1) DCS and TMCC are prohibitively closed and expensive.  Advanced automation does not seem possible on these platforms.  Every control plane is proprietary.  Every hardware component speaks on a closed protocol and costs $100+.  This is not tenable.

2) DCC is open and supported by DCC++ and a wealth of open software written in Java.  A wealth of options exists to extend it using Arduino in a cost-effective manner.  DCC is the clear winner for my goals.  As a bonus, the DCC decoders offer more functionality than what comes stock in most MTH and Lionel models.

3) Block management in DCC++ is there, but it is very rudimentary.  As an aside, I see that some folks on here have automated blocks using relays and didn't use a software solution.   You folks are gods among men. : )  Designing such a solution would be an intense exercise with no room for mistakes.  I am looking to create something more modular whereby blocks are conceptual in the software tier and managed completed in software via DCC.   Some challenges as I see them:

  1. Block presence: Third rail has the unique ability to reserve a rail just for this purpose. I see many others have wired just a side and center rail just to determine if a block is full.  I plan to do the same.
  2. Block location: DCC can issue commands to units anywhere on the layout, but it knows nothing of where the unit is located. I see that HO folks perform tricks using resistance in axels to infer this.  This does not seem ideal.  I have read a few articles on RFID tags.  Before reading them, this was my first thought given some work experience on systems using them.  RFID tags cost spare change and the readers can be bulk purchased from Aliexpress for about $5/unit.  What I have not seen is an example of anyone building a network of readers feeding into a central DCC controller reporting block data.  Armed with this info, many options (including AI driven automation) become possible.  Networking the readers is where things could get expensive.  Naively one could use 1 Arduino unit per reader within antenna range and then simply network the Arduinos over USB or BT.  The Arduino costs would get high doing this when an Arduino could service multiple units outside RFID antenna range.  Has anyone tried using a cheap null modem on the RFID antenna to communicate with the Arduino over a longer distance?
  3. Block management: I don’t want to share all of my engineering efforts, but conceptually I envision a train layout as simply a graph database with nodes representing switches and relations representing tracks. The nodes are connected at run time (when running a train) using directed acyclic graph (DAG) traversal methods with collision detection with other routes.  I think this could lead to some portable software routines universally applicable regardless of layout spec.  Is there anyone else pursing such a project?

I look forward to hearing everyone’s thoughts.  I am excited to be part of this community and learn from the wisdom everyone has to offer.  In a world where folks are trapped on screens all day, it brings me joy to combine the physical world, an appreciation of history, and STEM in a way that brings joy to my son and others.

Original Post

Replies sorted oldest to newest

KC

Welcome to the forum.  You have a great start on OGR and I am sure others will jump in on your ideas and project.  I am just a ole post war, conventional control guy but will be waiting for some smart replies.  2 trains on 1 track, with blocked sections and relays is about as low tech I have gotten.  Gunrunner John and others will chime in here soon.

Charlie

Last edited by Choo Choo Charlie

Hello KCStage -

I don't think you necessarily have to give up on TMCC or DCS to meet your goal of automation. While they are proprietary platforms, it is easy to control a TMCC or DCS engine from an Arduino (or a PC). If you're going to home-brew your detection and automation system, the TMCC or DCS interface to control trains or switches is relatively trivial.

But if you are interested in going the DCC route, then you should definitely check out JMRI. It has support for very sophisticated layout automation, although I've never used it. you may not have to re-invent the wheel when it comes to logical representation of layout connectivity.

As you set off on this project you should take a look at all the DCC automation devices that already exist. Tony's Trains has a reasonably comprehensive list on their website. I know some professional layout builders are constructing fully automated, computer controlled DCC layouts in HO and N scale. Several layouts have been delivered to customers.

I am an S gauger, many S scale operators use DCC. I considered DCC but decided to use Legacy with the add on LCS (Layout Control System.) It provides iPad touch control but not any automation. In S gauge the Lionel Legacy engines can operate on DCC, unlike in O gauge. One of the major differences in O/S compared to HO is the amperage draw of the engines. This limits the selection of decoders, but high current decoders do exist.

My layout is the same size as yours with 700' of track on four levels, all interconnected. There are eight power districts, each with a 10A supply and about 30 on-off switchable blocks within those 8 power districts. I know some O gaugers use 20A per power district because multiple unit O gauge engines can trip a 10A breaker.

It is nice to be able to combine professional knowledge with a hobby and then build something unique.

Thanks for the feedback.  Agreed that JMRI should be part of the plan.  With the goals I had in mind, I was looking for a codebase I could expand so that I would not be starting from scratch.  JMRI provides that.  It has a well thought out object model covering every device type I could ask for.  It also has a module for train automation that permits one to design routes, set classification types for trains/stock, and dispatch along those routes according to their assigned class. 

JMRI integrates with DCC out of the box, but no support is supplied for TMCC or DCS.  Agreed if I was homebrewing everything this would be moot, but since I want to speed things along with JMRI I want to use its native support.  Furthermore, I am somewhat loyal to MTH and they have DCC support in PS3 anyway.  JMRI is well documented and has some guidance for automation re block detection and switching prerequisites.  The block detection I covered in the post above.  My plan is to use Arduino and RFID as custom JMRI reporters to feed this data in.  The switching guidance is to have positive confirmation when the points are closed in set direction.  This is a logical necessity.  I know that some of the DZ switch machines have this feature.  However, for a large layout, purchasing 100+ of those would be crazy expensive.  I saw a post on OGR a while back about using a stall motor from MicroMark as a switch.  I bought one of these.  For the price, I was astounded to see that it was just a small DC motor on a bracket with a piece of wire on the shaft to connect it to a switch.  One can buy DC motors in bulk and easily craft wires to the driveshaft themselves!  I found one with a suitable stall amperage and rotation speed.  My plan is to use these, but remaining is the problem of points detection.  I have not solved that issue yet, but I considered reed switches, contact switches, reading amperage, etc.  Nothing so far seems to be mass producible without great effort or cost.  I am thinking I am going to need to use 3D printing to craft a custom bracket for the motor housing, feed the wire armature though it, and have it hit contact switches positioned at the housing base.  Has anyone else come up with any other ideas? 

One question I have, when you say full automation do you want it where you basically have trains running on the layout and have software that literally just lets you sit back and watch the activity? So for example, if you have engine(s) running a particular train, that the software would control the engine, that if it was going to enter a block with another train on it it would stop or slow down, would the program know where the train is going and throw the switches to the proper direction, and if a train approached a switch set the wrong way (Ie coming off a branch, would throw the switch to allow it to enter the main?

To me that would be full automation (and approaching this as a path theory problem would indicate to me specifically). Asking this out of curiousity but also it may help others reading this know what you need.

Last edited by bigkid

Yes, the idea is to turn the layout into a self-sufficient world governed by rules controlled by software.  However, a typical switch board would be presented showing the activity and permitting a user to set new routes and take over.  Lastly, one would be able to control engines directly with the software acting to prevent collisions.  JMRI documentation covers different types of block management to achieve these goals.  If you have ever worked with databases, they remind me of concurrency models governing relational data. 

1) Pessimistic Concurrency: A route is selected by a train and it is locked.  All tracks are locked by that train until it reaches its destination.  All other trains wanting to traverse a part of the route must go around it or wait.

2) Optimistic Concurrency: A route is selected by a train and not locked.  As it approaches blocks, it requests access.  If it is first to do so or if it has priority set (like passenger vs freight), access is granted and it proceeds.  Another train my also set a route concurrently along the intended path and proceed in a likewise manner.  This works well if the layout is designed such that all traffic is one-way.  If part of the route permits two-way traffic, a "Deadlock" or two trains stuck facing each other could occur.  Therefore, directionality of all tracks along the route must be evaluated before this type of locking is permitted by > 1 train for a given bi-directional route.  Alternatively, the system would have to generate an "execution plan" whereby one unit goes into a siding at an intersecting point on the route to permit the other to pass.

Hi KC, welcome to the Forum!  You have some great ideas, and I really hope that you're able to follow through and implement them!  I hope you share your progress by posting videos every now and then.

Personally, I wouldn't use the insulated rail method for block detection.  The redundancy of two ground rails is one of the best things about 3-rail O gauge.  Lionel makes an infra-red detector, and I imagine that there are optical sensors available and used in other scales.

Regarding routing, train priority, etc.:  along with 3-rail O gauge I've messed around with V-scale (virtual simulations.)  Specifically, the Auran Trainz series.  Using this software, you can build a virtual "layout" with passing sidings, signals to control junctions, etc.  You can also assign AI drivers and create "rules" allowing trains to traverse the network in an autonomous scenario.  However, at least in early versions of the software, when you start creating loops the AI gets confused and usually required some degree of human intervention.  You will definitely need to designate train priorites, decide how many blocks "ahead" a train will reserve at any one time, and perhaps designate some arbitrary point on the loop as your world origin (think of it like the international time-date line for your railroad!)  I think you'll find that in a complex network with loops, alternate routes, etc., the logic gets pretty mind-boggling.  But that's what makes it worth doing!!

I encourage you to purchase a copy of Trainz Railroad Simulator to experiment with rules and AI in a software simulation before you create your own code for the 3-D world.  Can't wait to hear and see more about your project!!

That is quite a challenge! More than likely pessimistic concurrency will be easier to achieve, but even with that the ability to 'take over' (while the software still maintains control over emergency situations) can be pretty intensive to run properly.  If the layout is complex, with a lot of potential paths (and potential "collisions" on a particular 'node'), it will be very complex especially  if you manually override a particular route, that will require the other trains under automatic control to re-do their spanning tree (it is doable, of course). Optimistic concurrency would work better in that case, in case someone changes their route and is on a block that they aren't supposed to be.


This could also be a challenge if you have switching going on and the switcher for example has to foul the main in the process.

The real challenge is train detection. It is relatively easy with an IR detector for example to see if a block is in use, but with what you want to do that won't be enough. You need to be able to track and see what train is where for this to work, especially if you want to try and do something like have an 'inferior' train halt or go into a siding for example. The problem is that while each engine has a unique id, that dcc uses to control it, I don't think there is any way to detect where a train is based just on that. My take would be something like RFID, where it is generating the train id (relatively easy to have a map of train id to dcc engine id(s) if it needs to let's say slow or stop a train in the path of a superior one). So you would have rfid detectors on each block that reads via an rf tag on a train, what it is (in theory you could use bar code tags on a train, not sure that would work all that well, though, lot more precise to read that then RFID).

Obviously if you can id a train and where it is, you can do things like program in going into the hole or on the main, including switch set and clear to allow a train to into the hole or main in my example. The other thing is using train id to control a train, you wouldn't need to worry about the DCC id, since when making the train in the system, you would map that "train 1011" is controlled by engines 33 and 44 in DCC (I don't know how many digits DCC uses, that is just my hypothetical example).   Going to take a lot of practical work to get this to work and debug it, but hey, if you enjoy it, it certainly is an amazing goal!

Hi KC,

An idea I've had for inexpensive locomotive identification is to use Hall effect sensors to read the strength of a magnet; every loco on your layout would have a magnet of a unique magnetic field strength range.  I started to play around with the idea but I only needed to identify 2 locos/motorized units, so I just did a magnet mounted left or right side under the chassis, with reed switches between the rails, since direction of travel would never change in my case.

I use insulated rail for occupancy detection without an issue.

Best wishes!!

Take care, Joe.

Last edited by Joe Rampolla

Joe,

That is a great idea and it would be very cost effective.  I think however that the delta between pull strengths would need to be very high to compensate for inaccuracy when moving at speed.  One would need to read the max value and that would be reached for a millisecond and therefore require a very high poll rate on the hardware.  The delta would help smooth this out, but limit the number of identifiers greatly.

I was doing pro/con of ideas last night and I think I have settled on the method I am going to prototype.  My original idea was to place the RFID stickers/tags on the trucks of every train and piece of rolling stock.  At the intersection of each block I was going to place a RFID reader.  This increased costs and resulted in a huge number of readers to network over large distance.  My motivation for doing that was for yard sorting and firing events for specific stock under conditions tracked by the controller software.  However, I realized I was merging the solution for yard sorting with block detection and the two could be mutually exclusive.

One of the reasons I went with O is because the inside of cars and trains is cavernous so adding custom electronics is no issue.  So, one could supplement whatever decoder is in the board with a secondary board (Arduino micro) that has no job other than to broadcast the loco ID and its location over bluetooth.  The Ardunio would route the RFID antenna to sit at the bottom of a pair of trucks on the train or tender.  The problem is now flipped so the RFID tags can be placed in abundance on the track where ever needed to trigger location events or other events related to the train itself.  Effectively, we are making DCC bi-directional now. : )  I imagine other possibilities like video feeds and fuel level reporting, but that'll be V2.

For yard sorting, I will still place RFID tags on the trucks of every car as well.  I will only have to place RFID readers under the track in a few places to help with sorting cars at the yard throat.     

Add Reply

Post
OGR Publishing, Inc., 1310 Eastside Centre Ct, Suite 6, Mountain Home, AR 72653
330-757-3020

www.ogaugerr.com
×
×
×
×
Link copied to your clipboard.
×
×