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.

[The_Ghan]

John,

My response was delayed by my wife's timetable ....  .... I should wrap it up and send it to you in the next six hours.

Aesthetically, soldering to the bottom of the track is the way to go, but that isn't what I do.  I found it too difficult.  I also failed at soldering to the joiners.  I was using Peco track for my subway at the time and the finish to the bottom of the joiner didn't want to accept solder.  Also, it was hard to fit the joiners once soldered.

You're going to have HOURS of soldering ahead of you.  I recommend drilling very small holes in the plastic track ballast and bringing the wires up through on the OUTSIDE of the rails.  Then solder to the outside of each rail.  I use Molex computer wires to do this as discussed in a separate thread.  If your layout is temporary then I recommend this kind of approach because you can unclip things and put them away.  There is nothing worse than spending hours unravelling your wires.

Molex link on eBay: http://cgi.ebay.com.au/4Pin-IDE-ATA-Power-Supply-Molex-SATA-adapter-cable-/370392231244?pt=LH_DefaultDomain_0&hash=item563d18ed4c ... cut of the black end and throw it away.  Solder the wires to the track and the other end is pre-wired for you. I make up custom lengths using these plugs - separate items for male and female: http://cgi.ebay.com.au/ATA-ATX-Power-Supply-Molex-Plug-w-Male-pins-mini-ITX-/220628280636?pt=LH_DefaultDomain_0&hash=item335e78653c

Mini connectors:  I also use the mini connectors from this guy ... http://stores.ebay.com.au/towzatronics ... they are colour coded and come in 2, 4, 6 and 9 pin set-up.

By the way, you only need to strip about 5mm of wire (1/5 inch) and solder immediately above and to one side of the hole so that you can pull the excess cable back down.  I forgot to mention the BIG advantage of soldering on the outside of the rail - you can SEE when a joint fails and EASILY repair it without removing any track. 

Finally, don't use the plug in connectors.  The joints aren't good enough for DCC and they become a nightmare with time.

Cheers

The_Ghan

[Darklighter]

I also failed at soldering to the joiners. 

How come? I'm no expert in soldering but I found it quite simple. Here is a good tutorial: http://cargoplus.dynalias.net:82/content/view/18/19/

[Martijn Meerts]

I forgot to mention the BIG advantage of soldering on the outside of the rail - you can SEE when a joint fails and EASILY repair it without removing any track.

You can also see where the joint is, which can (if you're no good at soldering/have bad equipment/use heavy wire) stick out like a sore thumb :)

I have experience with both soldering to the side (did that with my fathers layout, some joints are fine, some stick out big time. We painted the track rusty brown though, which makes the joints less visible, but at the same time also makes it less visible to see if a joint is bad), soldering to the bottom (with both Tomix and Peco track), and with bottom solder joints being bad (Tomix track, one of my early attempts.)


As for not being able to solder to joiners, depends on the metal the joiner is made of. Some types of metal are just impossible to solder to with a regular equipment.

[john_ibw]

The soldering talks is starting to worry me. I am going to try a few tonight and tomorrow. I will try the joiners first, then I will attempt the sides of the rails. I would like to avoid further purchases this month if I can so won't really consider the connectors unless absolutely necessary. Circuit breaker has kicked in as regards to my spending on trains. Cool-off period is about 4 to 6 weeks before spending can resume :)

BTW, I have received my Digitrax consignment today. Will start with a few drop-in installations and have the programming track setup. Looks like a busy active weekend.

The_Ghan: please take your time. It will be a while before the decoders are in and I am on basic DCC up and running.

[john_ibw]

How come? I'm no expert in soldering but I found it quite simple. Here is a good tutorial: http://cargoplus.dynalias.net:82/content/view/18/19/

Thanks Darklighter. The pictures and instructions make it look like I may be able to do it. But, I have not soldered in years and will have to try a few practice ones before I am certain I can solder good and lasting joints. Martijn mentioned about the metals playing a part in the ability to solder on them. I hope the ones I have will not throw a surprise at me. If nothing else works, I will attempt the following solder-less option until I find someone who can solder and is willing to bail me out. http://sites.google.com/site/josephbales/unitrackfeedertutorial

 

[The_Ghan]

I also failed at soldering to the joiners. 

How come? I'm no expert in soldering but I found it quite simple. Here is a good tutorial: http://cargoplus.dynalias.net:82/content/view/18/19/

As I mentioned in my post, I was using Peco joiners and Peco track.

[The_Ghan]

John,

Here's my first draft.  There is a document and a drawing.  Let me know what you think.  Response welcome from all members.

Cheers

The_Ghan

[David]

John,

Here's my first draft.  There is a document and a drawing.  Let me know what you think.  Response welcome from all members.

Cheers

The_Ghan

Since you seem to have some real world experience with the RX4 I have a question - when joined with a BDL168s do the transponding blocks replace, augment or consume multiple detection blocks? Assuming I have a single BLD168s, and plug in 2 RX4 modules, what is the maximum number of blocks I can now wire up?

From reading the documentation I originally got the impression that the RX4 consumed some of the detection blocks - 2 detection blocks consumed to create 1 transponding block - so the assembled package would have 8 blocks (all transponding). However reading elseswhere it seemed like they augmented it - you would have 24 blocks, 8 of which performed transponding.

Is there an alternate source of documentation for Digitrax equipment? I find their documentation never actually gets to practical usage - lots of pinout labels, but no mention of what those labels mean or what they should be connected to. The decoder wiring diagram included with every manual is about the only documentation that I haven't needed an external source to clarify.

[john_ibw]

Here's my first draft.  There is a document and a drawing.  Let me know what you think.  Response welcome from all members.

The_Ghan. Thank you! You have spent considerable time on this obviously. I hope I can do justice to your time and effort.

What do I think? The assumptions you made at the start? Spot on! The design and suggestions sound too good to be true for a DCC newbie. I can’t ask for a better start. I would have taken forever to get to this point with some serious damage along the way. To start with, I will convert to DCC with the blocks and have that up and running. Changes to the tracks to make it less parallel as you suggested, I would hold it for a while if you don’t mind. I completely understand and I am with you on making it lesser parallel. It is just that my layout is temporary for now. When I am at a more permanent residence, I will relay the track with better design elements. I will have the must-have programming track incorporated though.

My bench? 4 foldable trestle table laid out in the living room. I can walk around the layout. It is temporary and hence stuff like back don’t arise for the moment.

BTW...2 drop-in decoder installed, Zephyr is out of the box, connected and all well so far. With factory default settings, I can move, turn on / off lights! So, I am a DCC convert officially tonight. Two trains! All cars are not lighted though. When I say 2 trains, 2 trains that will move after DCC conversion. A few cars have lights. It is 1 AM, my neck hurts but I am pleased with the results. I will get a few more done this weekend.

From doing a quick check on the inventory, I am short of one BLD. And I do not have the PM42 either. Of course the power district can wait a little longer.

Thanks again!

[john_ibw]

Some pics of the DCC conversions. Image quality is not the best. I have now finished converting 3 trains :)

The quality of work on the wired conversion will not match the ones I have seen here, but I am glad I was able to pull it off. The soldered joints seem to stick.

With the last one, for a moment I thought I fried a decoder. There was a short and I smelt something burning. To my surprise, the decoder works! Not sure what is the extent of damage. I hope it won't cause me trouble at a later date.

[KenS]

Since you seem to have some real world experience with the RX4 I have a question - when joined with a BDL168s do the transponding blocks replace, augment or consume multiple detection blocks? Assuming I have a single BLD168s, and plug in 2 RX4 modules, what is the maximum number of blocks I can now wire up?

From reading the documentation I originally got the impression that the RX4 consumed some of the detection blocks - 2 detection blocks consumed to create 1 transponding block - so the assembled package would have 8 blocks (all transponding). However reading elseswhere it seemed like they augmented it - you would have 24 blocks, 8 of which performed transponding.

I'll throw my two cents out, with the caveat that I'm still wiring things up, and haven't seen my system in operation yet.

I had the same confusion on first reading Digitrax's manual. And additional info is hard to come by, although Digitrax has a separate Application Note that adds a bit of clarity.

As far as I can tell, and it's reading a bit between the lines, the RX1 sensors are a function in addition to the 16 occupancy detectors.  You can wire four of them on the four inputs to the BLD168, and get train identification everywhere, but no ability to refine that within the four sub-blocks of that input.  That could be useful if you have a set of closely-spaced blocks where you need to detect position in fine detail, but would never have more than one train.

If you want to use fewer blocks for one train, another technique is to run two (or more? I can't tell from the documentation if that would work) occupancy detector output wires through one RX1 sensor, and have shared indentification in those blocks.  That would be useful, for example, with the decelleration and stop sections The_Ghan suggested, as both could share an RX1.

However, one concern I have there is what happens if you have multiple detectors on one train (cab and motor, for example) doing transponding.  I suspect this would work for a moving train, as one detector enters first, and is the one detected.  But for a stationary train, my suspicion is that two would interfere with each other, and neither would be correctly identified.

Finally there's the basic approach Digitrax describes in the manual, where you pick 4 or 8 of the 16 outputs and run them each through an RX1.  With that you get all 16 detecting the presence of something, and 4 or 8 doing both that and reporting the identity.  That can be useful if you don't need to locate trains on power-up, just when moving, and you have track you want to divide into detection blocks for signaling purposes (so trains can prototypically follow each other with various speed restrictions based on proximity) with long runs where the train is on one track, so you know from the last identification detctor passed what train is in each subsequent block.

[The_Ghan]

Hi David,

Please see my answers below in blue.  Also, read the following digitrax document:

http://www.digitrax.com/ftp/bdl16rx4pm42appnote.pdf

Cheers

The_Ghan

Since you seem to have some real world experience with the RX4 I have a question - when joined with a BDL168s do the transponding blocks replace, augment or consume multiple detection blocks? They augment detection blocks.  You can wire them up to transpond on sections that are also detected or to transpond on 4 sections that have no detection.  Assuming I have a single BLD168s, and plug in 2 RX4 modules, what is the maximum number of blocks I can now wire up?  24 - 16 detection blocks plus 8 transponding blocks.

From reading the documentation I originally got the impression that the RX4 consumed some of the detection blocks - 2 detection blocks consumed to create 1 transponding block - so the assembled package would have 8 blocks (all transponding). However reading elseswhere it seemed like they augmented it - you would have 24 blocks, 8 of which performed transponding.    Your latter assumption is correct.

Is there an alternate source of documentation for Digitrax equipment? I find their documentation never actually gets to practical usage - lots of pinout labels, but no mention of what those labels mean or what they should be connected to. The decoder wiring diagram included with every manual is about the only documentation that I haven't needed an external source to clarify.  I've not found any good commentry on the use of Digitrax products.  I rely on the generic Digitrax documentation and lots of patience and testing.