DCC based automation (with Transponding focus)

[john_ibw]

This thread is being created because automation and transponding was being discussed in another thread to do with Decoder selection

 

Original thread.... http://www.jnsforum.com/index.php/topic,4647.0.html

 

Since this will benefit several others, a dedicated thread is a good idea. Thank you KenS, who suggested we make the split.

 

I have posted a layout design below that can aid the discussion. The DCC equipment being considered is all Digitrax. Please note that this is a personal choice. Initially I had considered NCE and a mix of decoders. The_Ghan made a mention of Transponding and I was hooked instantly. I liked the idea of automation and the challenge it posses for me. I looked at the JMRI documentation and relaized with scripting I could program to respond to events in the layout. Using pre-defined routes, block detection and transponding automation of simple layout is attainable.

 

Zephyr Xtra - because I am new to DCC and I don't believe I need anything more than this one to run about 4 trains at a time

All mobile decoders from Digitrax - my reason to consider - several of my Kato stock accept drop-in ones from Digitrax and all current production ones support transponding

Digitrax PR3 Decoder Programmer - allows PC hookup to JMRI

Digitrax BLD168 - occupancy detection

RX4 - to be used along with BLD168 provides two way communication with Digitrax transponding complaint detectors. Hence identity and location easily available to the JMRI application

DS64 - stationary decoders. Apart from the fact, all other DCC equipment was now Digitrax, I thought it was useful to stick to LocoNet for all inter device communication including the PC

 

Though there is a learning curve, I think I can figure out the JMRI syntax and scripting. Decoder programming and panel creation is straight forward as far as I can tell. I have already installed JMRI and going through the documentation, I am encouraged to know that automation is achievable.

 

Before I forget, my idea of automation for my layout is the ability to run multiple trains on each line (I have 2 lines), stop at sidings and stations for pre-defined lengths of time. Yard automation will be cool but I am not sure I can try everything together.

 

Why JMRI? Open source and is available on Mac. I have experience working with Java based technologies and so if and I absolutely need to write some custom code, I could try that too.

 

Before I close this post, I wanted to state that I have got much far in my hobby in the last few months than I did in several years. At first, I could not believe it myself and looked back to check. Being part of forum helps the hobby and keeps you going. Thanks all for the support and advice.

[Martijn Meerts]

One thing to remember about transponding is that Digitrax uses their own system, which isn't going to be part of the NMRA DCC standard. Not that not being part of the standard is bad by default, but just something to keep in mind. Digitrax might be the only company manufacturing transponding decoders, while the rest might use the (likely-to-be) standardized RailCom system.

 

I haven't heard anything bad about Digitrax, other than that their hand held controller designs are terrible, but that's personal taste :)

 

You can also have a look at RocRail instead of JMRI. It's also free, open source and available for Mac, but it's not written in Java. It's a different take on computer control compared to JMRI.

 

 

As for the layout, You might want to get rid of the left most track in the yard, I believe it's a bit too close to the curve of the main line, and might cause problems. You'll also be able to run more than 4 trains at a time on that layout, depending a bit on what you'll be running. Yard automation isn't difficult btw, just brings with it a little added cost for additional occupancy detectors etc. :)

[john_ibw]

Yes Martjin. I thought about Digitrax going solo on LocoNet. My reasoning was that the DCC part conforms to NMRA and which is good. So any decoder will work without transponding on the layout. To enable transponding, I have to add an additional Digitrax decoder (that is if factory fitted ones was not from Digitrax or I have to use another decoder for some reason). 

 

I think somewhere along the way in the last few weeks, I started to convince myself that I should take a position and decide on the equipment. :) To be honest, I have not checked all other options in-depth. Kato, since it uses Digitrax, was the obvious starting point.

 

I am going to look at RocoRail. And about the leftmost track, you are right. I checked the additional clearance required for the viaduct from the edge of the outer track to the outermost point. Yes, it will be a problem. In fact, thanks to you, I checked the lengths of the other lines. I realised I may be going to close to the tracks at the yard ends. I will have to reduce lengths of a few by at least 124mm. There may be more to fix while I start work on the yard.

[CaptOblivious]

You should ask yourself (and Martijn, too, he knoiws way more then you or me) whether transponding is strictly necessary for your needs, where simple detection and dead reckoning might suffice.

[Martijn Meerts]

You should ask yourself (and Martijn, too, he knoiws way more then you or me) whether transponding is strictly necessary for your needs, where simple detection and dead reckoning might suffice.

 

I think I mentioned it before in another thread. Right now the only benefit of transponding is so that the computer program gets confirmation of which train is in which block. It's sort of an added security layer (if the program supports it), but it's not necessary for full automation.

 

The way programs usually work, is that when a train is in a certain block, the program decides (based on routes, rules, block vs train length, train type etc. etc. etc.) which block the train will go to next. Once that next block becomes occupied, the program assumes the train managed to make it's way to the block just fine. The problem here is that a rogue train from a different block might have entered the destination block, and giving it the occupied status. The actual train that should be in the block is now stopped somewhere on the layout, probably in a nasty spot, while the rogue train keeps on going, because the software assumes the rogue loco isn't running at all. A rogue loco is a common problem, if a turnout refuses to switch, you have a rogue loco :)

 

With transponding, whenever a block becomes occupied, you can ask the train in that block to return it's address. That way you can check if the correct loco is occupying the block, and if it's the wrong loco, just hit the emergency brakes.

 

(Saying it like this makes transponding sound like a critical feature, but if you control turnouts using switch motors like the Tortoise, or servo's, chances are slim that a turnout won't be thrown.)

[john_ibw]

Very true and I may be over-emphasizing on the transponding bit due to my lack of experience in DCC. It may not be required at all to meet my present needs.

 

I am waiting for my decoders and the Zephyr to start my DCC journey. That I am certain is the first step. Stationary decoders, detection and computer control should probably be the next steps before automation.

[The_Ghan]

One shouldn't be too fussed about the NMRA standard.  Clearly Kato and Digitrax aren't, and I sure won't be.  Transponding aside, I provided John with at least half a dozen other good reasons to consider Digitrax.  Actually, I'd like to think that John came to his own conclusions and I simply provided the list of considerations that led me to go with Digitrax.

 

Interestingly, I was first considering NCE, but couldn't stand their controllers - especially the NCE 524017, with its funny hammer-head design.  I had a good look at them at the Castle Hill Model Railway Show in Sydney last June.  I also don't like the look of their Power Pro and Power Cab range of products - which remind me of HAM radios out of the late 1970's.

 

If the NMRA goes with RailCom over Transponding then, in my opinion, the decision will be political rather than performance based.

 

John, in terms of software I'm a fan of TrainController.  I don't know if it works on Mac.

 

Cheers

 

The_Ghan

[Martijn Meerts]

Very true and I may be over-emphasizing on the transponding bit due to my lack of experience in DCC. It may not be required at all to meet my present needs.

 

I am waiting for my decoders and the Zephyr to start my DCC journey. That I am certain is the first step. Stationary decoders, detection and computer control should probably be the next steps before automation.

 

Well, being certain which train is in which block is quite nice. Trying to locate a rogue train isn't always easy, unless you continue running until you hear the sound of 2 trains smashing into each other :) That certainty can be mostly gotten by using solid, reliable turnout mechanisms though. Having the option for transponding from the get go is nice though, and since it's built into pretty much all the new Digitrax stuff, there's no reason not to go for it.

 

But yeah, getting the base system and some decoders is enough to keep you busy for a while. Installing the decoders isn't always very straight forward. Getting to terms with all the features, terms and CV programming and whatnot is also going to take some time. After that, you're probably best off going for turnout control, and setting up a manually controlled layout using the computer. That way you get the hang of the program and how to set things up without the added complexity of the block system. Once that's out of the way, "just" add the blocks :)

 

 

 

One shouldn't be too fussed about the NMRA standard.  Clearly Kato and Digitrax aren't, and I sure won't be.  Transponding aside, I provided John with at least half a dozen other good reasons to consider Digitrax.  Actually, I'd like to think that John came to his own conclusions and I simply provided the list of considerations that led me to go with Digitrax.

 

Interestingly, I was first considering NCE, but couldn't stand their controllers - especially the NCE 524017, with its funny hammer-head design.  I had a good look at them at the Castle Hill Model Railway Show in Sydney last June.  I also don't like the look of their Power Pro and Power Cab range of products - which remind me of HAM radios out of the late 1970's.

 

If the NMRA goes with RailCom over Transponding then, in my opinion, the decision will be political rather than performance based.

 

John, in terms of software I'm a fan of TrainController.  I don't know if it works on Mac.

 

Cheers

 

The_Ghan

 

Few of the currently available systems are bad, so it really takes effort to buy something that just doesn't work at all. The Digitrax system, and especially Loconet is a solid system. The reason it wasn't an option for me when I started is that in Europe it's not common so everything would have to be imported. I'm not a firm believer of 1 system being the best, and the 5 different systems I have is a certain amount of proof of that :) (Marklin Motorola, Marklin Mfx, Selectrix, Lenz DigitalPlus, ECoS) I also don't stick to 1 brand, except maybe for my decoders. I tend to use Lenz Silver Mini, but that's because they're pretty much the smallest I can get for a decent price.

 

As for the NMRA, considering the DCC standard is pretty much the Lenz system, it makes sense they're going for RailCom as well. Railcom/RailComPlus isn't that bad though, and plenty fast. Of course, it uses a new bus (again), so you end up having a lot of different loops under the layout.

 

TrainController only works on the Mac if you run BootCamp or something like Parallels, it's not a native app. It's definitely one of the better pieces of software available right now, although quite expensive compared to JMRI or RocRail :)

[CaptOblivious]

I'm not advocating against Digitrax, far from it (full disclosure: I love my Zephyr). What I am advocating against is making things unnecessarily complex, because of a perceived need for complexity, is all. I am a fan of making things as simple as possible.

 

That said, the NMRA's decision for RailCom probably was heavily political (You should look at the politics surrounding the recently adopted standards for "NMRANet"…OMG.) Too, the RailCome standards are currently underspecified, which is a real problem. But then, have you looked at Digitrax's terms for licensing their technology? Not exactly a good foundation for an open standard. The big players in this field have no idea how to go about setting quality, lasting, and open standards, and apparently have no interest in it.

 

So I'm not counting on using either system :D

[David]

I'm not advocating against Digitrax, far from it (full disclosure: I love my Zephyr). What I am advocating against is making things unnecessarily complex, because of a perceived need for complexity, is all. I am a fan of making things as simple as possible.

 

That said, the NMRA's decision for RailCom probably was heavily political (You should look at the politics surrounding the recently adopted standards for "NMRANet"…OMG.) Too, the RailCome standards are currently underspecified, which is a real problem. But then, have you looked at Digitrax's terms for licensing their technology? Not exactly a good foundation for an open standard. The big players in this field have no idea how to go about setting quality, lasting, and open standards, and apparently have no interest in it.

 

So I'm not counting on using either system :D

 

Digitrax has terms for licensing 'transponding'? I was under the impression they had patented main line acknowledgement and where keeping it to themselves.

[CaptOblivious]

I'm not advocating against Digitrax, far from it (full disclosure: I love my Zephyr). What I am advocating against is making things unnecessarily complex, because of a perceived need for complexity, is all. I am a fan of making things as simple as possible.

 

That said, the NMRA's decision for RailCom probably was heavily political (You should look at the politics surrounding the recently adopted standards for "NMRANet"…OMG.) Too, the RailCome standards are currently underspecified, which is a real problem. But then, have you looked at Digitrax's terms for licensing their technology? Not exactly a good foundation for an open standard. The big players in this field have no idea how to go about setting quality, lasting, and open standards, and apparently have no interest in it.

 

So I'm not counting on using either system :D

 

Digitrax has terms for licensing 'transponding'? I was under the impression they had patented main line acknowledgement and where keeping it to themselves.

 

They claim to offer it to other companies:

http://www.digitrax.com/faqtransponding.php

although they do not explicitly state their terms. One imagines they are similar to the terms for licensing LocoNet, the terms of which are also, to my surprise, not explicitly stated on their site. But you can get a glimpse of what they might be here:

http://digitrax.com/faqloconetq.php

in the strictest sense of the word LocoNet is a proprietary system. In order to maintain a system as complex as LocoNet someone has to be "in charge" so that valuable system resources are not used unwisely. Digitrax maintains LocoNet professionally for the benefit of the hobby & works with other competent DCC developers so that they can include it in their systems. The non-disclosure agreements & licensing agreements & fees for the use of LocoNet are not intended to prevent or discourage anyone from using LocoNet but merely to insure that system resources are used prudently & to cover Digitrax cost to maintain and expand the LocoNet as needed.

 

Compare to RailCom, for which Lenz has basically waived all licensing fees, and does note require any kind of non-disclosure agreement, etc, etc.

[brill27mcb]

I do not do DCC, but with all the licensing requirements, compared to Lenz, it sounds like the "politics" is on the Digitrax side, not the NMRA...

 

Rich K.

[David]

I do not do DCC, but with all the licensing requirements, compared to Lenz, it sounds like the "politics" is on the Digitrax side, not the NMRA...

 

Rich K.

 

There are plenty of politics with the NMRA - even with licence free Lenz they still don't accomplish anything. But that didn't stop Lenz from opening up RailCom resulting in other brands using it, which in turn is what will create a standard.

[Darklighter]

I'm building a small automated layout, too. I'm using Rocrail, DIY LocoNet hardware ( http://wiki.rocrail.net/doku.php?id=mgv-overview-en ) and DDX (software command station already included in Rocrail). My decoders are made by Lenz and Digitrax though. Haven't had any compatibility issues yet.

[The_Ghan]

Prototypically speaking, if you're running a layout of multiple EMUs, shinkansen, and the like in a contemporary setting would you not be interested in PC control and transponding?  After all, that is what JR controllers throughout Japan are looking at day-in day-out, is it not?  For me, transponding and PC control will be part of my contemporary setup.  It is not a case of merely automating a process, but one of truely representing the control of trains as it is in that period.

 

I once had a BR steam layout in OO gauge.  Good ol' Hornby in the 1970's.  The layout had two or three fiddles and the art was in forming up steam consists, turning engines around, adding helpers, etc.  For me, it would be almost sinful to have the PC doing all that for me.  For steam, I'd like to make things as real as possible, ie: as manual as possible.  My LMS Class 5 never used to stop in exactly the same place, but neither did the real train.  However, my shinkansen all stop at the same spot each time they pull into the station.  THAT is how JR works!

 

This is the basis of my arguement for transponding on a contemporary Japanese layout.

 

Cheers

 

The_Ghan

[Martijn Meerts]

Prototypically speaking, none of us could run any train with the space we have available :)

 

 

Anyway, transponding isn't a requirement for prototypical automated control. The software is smart enough to figure out which train is where on the layout without needing transponding/railcom. The added benefit of transponding however, is, like I mentioned earlier, the extra layer of certainty of which train is in which block.

 

Layouts like Miniatur Wunderland in Hamburg don't use transponding, yet their control room shows exactly where everything is (unless of course, a turnout malfunctions ;))

[David]

Prototypically speaking, if you're running a layout of multiple EMUs, shinkansen, and the like in a contemporary setting would you not be interested in PC control and transponding?  After all, that is what JR controllers throughout Japan are looking at day-in day-out, is it not?  For me, transponding and PC control will be part of my contemporary setup.  It is not a case of merely automating a process, but one of truely representing the control of trains as it is in that period.

 

I'm on the same page. While part of the draw of automation is that I'm a programmer, I would like to reproduce something like the real system. For example I want to have a working time table (updated in real time based on what trains had been assigned to what routes and what distruptions where occuring on the line) showing arrival times for each station. This way it's not just extra scenary around the train I'm driving, those other (computer controlled) trains actually have a time table to keep and are affected by if train is late or ignores a signal.

[john_ibw]

My decoders and the Zephyr should arrive in the next couple of days. There is no turning back now :)

 

Like David, having a programming background, automation and the ability to control from a PC was something I could not ignore. I am hoping that I can run multiple electrics on each line and maintain a time table. Of course, I am also thinking about my Unitram layout and about introducing timed stops for them as well. If that was not enough, I started laying guide wire (from Faller) on some plates to test run the Tomytec / Faller type buses. I can't claim that I know exactly where I am heading with all this, but I am very busy with lots of mini projects and having a great time :)

 

Also, I managed to convince my wife (it did cost me!) to allow me 2 more trestle tables in the house. More space = more structure + track + trains

 

The_Ghan and Martijn: any suggestions on how many blocks? Do I need 3 blocks at a minimum between the stations to run multiple trains,  detect and maintain distance? At the stations, do I need to create multiple blocks inside each siding for braking?

[David]

The_Ghan and Martijn: any suggestions on how many blocks? Do I need 3 blocks at a minimum between the stations to run multiple trains,  detect and maintain distance? At the stations, do I need to create multiple blocks inside each siding for braking?

 

The number of blocks between stations would be entirely dependent on how far apart stations are and how dense you want to run trains. At the least dense you could use a single block between stations (with the station itself being a block). In that case a train could not leave the station until the next station up the line had been vacated.

 

I started a thread on station stopping and how to go about cheaply detecting the trains progress:

 

http://www.jnsforum.com/index.php/topic,4499.0.html

 

A big issue with automated braking is how much you want to rely on timing vs. actual feedback. The timing approach simply assumes that if you apply the same speed steps at the same time the train will stop at the same place (in DCC this is sometimes baked into the decoder as the constant stopping distance feature - however this feature is really meant for distances of only a few inches, not the slow braking you would use in a 5' station). With timing you only need one block for the station - as soon as the train is detected entering that block the timed sequence is started. Of course this doesn't account for wheel slip, temperature (a cold, warmed up and overheated motor all behave differently), dirt (the first wheel may not trigger the detector) and other factors. The feedback approach is where we get into a lot of detection zones (or some other method of cheaply determining position). In theory the blocks would get smaller as you reached the end of the platform to allow for a precise stop without any uneven deceleration. My own guess is that by combining it with timing that 4 blocks could provide 'good enough' results while remaining cheap - the first big block starts the braking sequence, the smaller 2 in the middle provide minor corrections (if the train reachs block 2 early then extra braking is applied, if too late then less braking is applied) and the last tiny block halts the train.

[Martijn Meerts]

The_Ghan and Martijn: any suggestions on how many blocks? Do I need 3 blocks at a minimum between the stations to run multiple trains,  detect and maintain distance? At the stations, do I need to create multiple blocks inside each siding for braking?

 

Blocks depends on a variety of things. The first main deciding factor is the length of the blocks. A block should be at least as long as the longest train that will enter that block (there are exceptions to this, but it's a good general rule to start with deciding where blocks should go). Another thing to keep in mind, is that you'll want at least 2 free blocks ahead of a train in order to get good running, without trains slowing down constantly because the next block is occupied.

 

Clockwise, starting at the viaduct station, you could add 3 blocks before getting to the suburban station. After the suburban station it might be a bit tricky, I'm not sure what the idea is behind the siding there. Is that another station, or some sort of passing track? Either way, the inner loop you'll want blocks in between the turnouts, the outer loop you can have a block between the suburban station and the double crossover. After the crossover, you could devide that section in 2 or 3 blocks, again depending on what you want to do with the unitram plates section.

 

Make sure not to have any turnouts inside a block though, that can cause serious deadlocks, or at least cause a lot less trains to be running that can theoretically be running.

 

 

As for how many detectors, it depends on whether or not you want blocks to be able to be used in both directions, or just a single direction. Depending on that, 2 or 3 detectors should be enough for good control. You could add additional detectors for finer control, but it's not really necessary unless you're running long/heavy trains with a long braking distance on the same line as short local trains with short braking distance. In that case you could add a detector in the middle somewhere, which will signal when the short train should start slowing down, whereas the heavy starts slowing down the moment it enters the block.

[The_Ghan]

My decoders and the Zephyr should arrive in the next couple of days. There is no turning back now :)

 

...

 

The_Ghan and Martijn: any suggestions on how many blocks? Do I need 3 blocks at a minimum between the stations to run multiple trains,  detect and maintain distance? At the stations, do I need to create multiple blocks inside each siding for braking?

 

John,

 

You'll love your purchase!  There is nothing like the fresh electronic smell of a new Digitrax controller right out of the box!!!

 

At to your blocks question:  I'm going to post a mark-up of your layout and a description in pdf in about 15 hours.  I'm half way through it.  It should answer most of your questions.

 

In the meantime, you might invest in 100m rolls of AWG14 red and black copper wire and a 5m roll of AWG14 green.  You will also need about 20m of AWG20 (ish) of the following:

    -    white and brown if you are using 2 wire points such as Tomix and Kato;

    -    white, blue and yellow if you are using 3 wire points such as Peco.

 

Also look into the LocoNet wiring at the Digitrax site.  I bought myself a roll of 6 wire telephone cable (you've got to be careful to get the right stuff), a bunch of RJ12 connectors and a crimping tool so that I can make my own custom lengths of LocoNet Cable.

 

Cheers

 

The_Ghan

[john_ibw]

Thanks The_Ghan. Perfect timing actually. I was going to pick up wire and other material tomorrow or the day after.

 

Meanwhile, more track and trains arrived today. I also had some time last evening to test the layout design a little. Attached is a picture of the layout shaping up. I took the Narita out and had to set it on the track! Could not resist. Then the white sonic ran for a while :)

 

I have to build the second viaduct station to expand the one in the layout. Talking about layouts, I also need to resurrect the personal projects thread soon.

 

I am using Kato points. For Loconet, I have only been able to buy the crimping tool. Have not been able to locate the RJ12 6P6C jacks. Regular stores only carry 6P4C jacks. I will visit Jaycar or some place similar for those and the cables in the weekend.

[Martijn Meerts]

Ah, definitely getting a better idea of the whole thing with that picture :)

[john_ibw]

Ah, definitely getting a better idea of the whole thing with that picture :)

 

:) my wife had no idea what she was getting into when I talked about "a little space to run a tiny train!"

 

I forgot to ask this earlier, but are using feeders that are soldered to the joiner? Or using a solderless approach. I do not wish to spend on Kato connectors for feeders for several blocks.

[Martijn Meerts]

I don't use Unitrack. I do have a bunch of FineTrack though, and I soldered feeders to the bottom of the track pieces I was going to be using. I try to rely on track joiners as little as possible, because they can become problem issues down the line.