Back to DC

[lashedup]

Not to derail Mike's DC exploration, but we did talk about this a little and I think it is interesting. Most of the "issues" with DCC relate to things getting more and more complicated - sound in locos, different decoders, signaling, block detection, etc., etc. Although arguably, DC will also get far more complicated with more complexities as well. Most of the issues we have had with a large group/modular layout and DCC relate to finicky locos (most often related to poor running mechanisms to start and/or shoddy DCC installs), shorts due to the lack of separate power districts and derailed equipment, wireless throttles that don't always respond (could be LOTS of issues for this, especially at shows) and occasionally a command center that gets a little out of wack and needs a reboot or clearing of addresses. Otherwise the layout issues usually stem from track and wiring stuff separate from DCC. Remember we're talking about 20+ modules that different people have all built at different times. They are not always set up in the same layout configuration or same module order either, so getting cohesive block detection and signaling is tricky. But overall I'd say we have more issues with module maintenance than we do with DCC. That said...

When Mike and I were going back and forth on this there was some discussion related to what he was unhappy about with DCC and the current state of DCC in this country versus others. Many people on this side of the pond use Digitrax or MRC or NCE. Digitrax is probably the most prolific. That said, it is arguably the cheapest components with the least amount of real development in the last ten years.  If you look at what's available in Europe right now with the Fleischmann/Roco Z21 or ESU's new Command Module II or ECoS there are some major advances occurring that make even basic programming and CV changes infinitely easier. Yes, some of these systems are expensive. With many/most coming from Germany, that's probably to be expected. But, there are advances in the ability to keep evolving what can be done with DCC and some positive moves with the user interfaces. Whereas we're still using the same basic DT-series throttle from 15 years ago. I know it can be debated endlessly how complex or how simple a controller is necessary, but clearly with sound and more features evolving over time, there is a need to control those features.  I operated years ago on a large DC layout at a club and while it mostly worked once you understood cab control and how everything functioned, I'm not sure I'd go back to that given the advantages of a well running DCC system.

As I'm about to build a new layout in the house, I've been looking at various DCC systems as my current Digitrax system is more than 15 years old. It has it's quirks and feels like I'm using a Casio calculator watch versus an Apple Watch. I also like tech stuff, so its a good excuse to try something different.   I'm leaning towards an ESU system right now as I've installed a LOT of their decoders in my locos and I'd like to try something engineered in Germany to see if it is any better.  I'm happy to pass along my thoughts and experiences with it as well. I'll keep my Digitrax components as we still use them with the Modutrak layout.

So meanwhile back to Mike's Z scale layout. As the above discussion shows, we can collectively come up with a solution to make it all run on DC, but will the complexity actually be significantly less? Will the operating quirks also be a lot less than with DCC? I'm curious to see how it all shakes out.

Great minds in here helping out. Been fun to read.

-jamie

[DKS]

A few thoughts, just to clear up some possible misconceptions...

A harsh stop, in my view, is just asking for derailment troubles.  I'd avoid this just for that reason.

Based on decades of experience operating a large staging yard that uses hard stops, there have been zero derailments due to the stopping.

...I think the analogy of using a computer to turn on a light is great, but you should use the analogy of using an Alexa to turn on a light, even a 5 year old can do this, because of all the software already developed to make his life easy.

But I think my gist might have been missed. No matter how much software a 5 year old might have at their disposal, a toggle switch is always going to be simpler and more robust.

Get a basic transistor throttle of your choice, replace the rotary potentiometer with a linear one, and connect that to a motor-drive switch machine.  Run THAT at a voltage that gives you the acceleration rate you want.

I've actually done exactly this. It proved to be unnecessary, because hard stops never caused any derailments in the yard. (BTW, John Allen built throttles this way to simulate momentum.)

Okay, so here's a way to get your track selection working... if you want to go all DC with this, the motor/wiper system is sounding really good to me.

I've built many "player piano" systems like this for a variety of applications. But it's not always the best approach. The system I built for Rick is actually all relay-based (and it replaced a solid-state version that failed). His yard is larger and more complex than Mike's--with options to "pre-program" track selection--yet only required about a dozen or so relays. And it's been running without issue for decades.

Granted, the DCC folk could more than likely replicate the whole thing with a bunch of off-the-shelf stuff, but one thing I've been asking about and no one has addressed yet is cost. It's almost as if money is no object any more. Does it not matter to anyone that a DC solution could potentially be had for a fraction of the cost of a DCC system? Yeah, it might require more skills than most might have, and I suppose those without the skills are paying for it--and that's OK, really. It's just a bit irksome to just ignore it as a factor.

As for the whole way-overblown "computer-controlled throttle" thing, I wish I'd never described it like that. I should have learned my lesson: it's the reason N Scale rejected my article about Rick's yard--one silly word threw them into a tizzy.

Well, that's enough from this old hack, back to your regularly scheduled discussion.

 

[C855B]

... one thing I've been asking about and no one has addressed yet is cost. ...

OK, you've set the hook, so I'll bite. Time spent on engineering, procuring, assembly, integration and testing/debugging a unique system is a "cost". I did address it generically, that it comes down to the classic "make vs. buy" decision. And there's cost:benefit, too, where one of the benefits, as you raised, is the satisfaction of designing something truly trick that works. When it comes to the dollars-and-cents part, I invite you to peruse my several boxes of electronics components and support bits that were deemed unusable, surplus once the project was finished, or obsolete once I finally got the roundtuit.

Speaking for myself, if tools are available at reasonable cost that hasten implementation, that's time freed for other tasks that can't otherwise be reasonably bought.

[DKS]

Spoken like a true businessman (and I can relate, having had to evaluate the same build/buy, cost/benefit ratios professionally myself, so I'm not being snarky).

And I appreciate your touching on the unquantifiable aspect of satisfaction. But, the amount of disposable income available for a project must be considered--which can possibly trump any arguments against DIY.

It might perhaps be worth looking at some hard numbers. What DCC components would be required to accomplish Mike's goals, and what are the total estimated costs?
 

[lashedup]

I think these are both good points (and David's cost factor in particular) and really, one of the things that makes this hobby attractive to people for vastly different reasons. There are things we are good at doing and enjoy figuring out and building. Then there are things we aren't good at or don't have the time for that are easier to purchase or get someone else involved. The third piece is that over the long run we also tend to float between different things in this hobby that interest us at a given point in time - shiny object syndrome of sorts. In the end it all depends on time, means, talent and patience.

Are there times I'd rather go back to a first generation Volkswagen GTI for it's utter simplicity and lack of electronics and raw mechanical feel? Absolutely. But in doing so I'm giving up on a number of things that can't change the fact that while it is more simple and cheap, it won't be as nice as a current GTI in many respects - everything has its compromises. That's not to say it's an archaic way to think either - there is a reason tons of people restore and own old cars. It's more a matter of our own preferences and what floats our boat.

I'm enjoying the retrograde discussion on how to use a classic DC system in a modern layout. I agree with what many have said in the simple layout, simple solution bit.

[strummer]

I'm thinking this thread will someday end up as a "Best Of" piece; fascinating read...

Mark in Oregon

[Sokramiketes]

Ok, so what /is/ the DCC solution here?  I get detection and signaling. And I’ve set up both discrete signal solutions (Modutrak is TracTronics signal logic for all intents and purposes, no computer) as well as computer controlled signals via JMRI and RR Cirkits.

Sorry, but JMRI makes me want to stick sharp objects in my eye.

If I want this layout to parade trains, is JMRI what everyone is thinking of for the DCC solution?  Has anyone touting that actually set up a layout in this way? Or do we just know that after we spend 40 hours learning the ins and outs of JMRI, learning to program java and adjusting tables by hand when JMRI glitches... that we think it should maybe be reliable?

Please tell me there is something other than JMRI in mind here.

[Chris333]

Do they even make the GTI as a 2 door any more? 

[brill27mcb]

Maybe it's time to bring this up:
http://www.trainweb.org/tomix/control/tnos.htm

The Tomix TNOS system is brand new, and while they do not yet offer a layout scheme for a single track with reversing loops, maybe sometime they will. They have committed to releasing more layouts and automated operation sequences in 2018.

Rich K.

[lashedup]

Do they even make the GTI as a 2 door any more? 

Negative ghost rider...  Only in Germany. 

[C855B]

...Sorry, but JMRI makes me want to stick sharp objects in my eye. ...

Me, too. Just last night I was wanting to add a crossover to a panel - one "button" object to throw both switches. No problem in Layout Editor, but, no, I want it in an existing panel. No dice, can't do it, make it a "route". Came close to testing mouse aerodynamics.

If I want this layout to parade trains, is JMRI what everyone is thinking of for the DCC solution?  Has anyone touting that actually set up a layout in this way? Or do we just know that after we spend 40 hours learning the ins and outs of JMRI, learning to program java and adjusting tables by hand when JMRI glitches... that we think it should maybe be reliable? ...

I for one am not advocating the JMRI solution. I definitely have a love/hate relationship with it. Like similar software I worked with in ham radio (and was a principal developer for), JMRI is a Swiss army knife - all the tools are there, but actually using them for real work is going to bloody your knuckles. But as far as "time invested", which is a cost, the Arduino-based idea - for me, at least - requires an investment in learning that particular tool, with its own ins and outs. Conceptually I understand it, but making something work and work reliably will take much more time than using existing knowledge.

Long way of saying I have no idea about JMRI to solve the puzzle. There might be something in the scripting language, but I'm just learning that tool. I do know that there is enough in the basic DCC toolbox for getting close to the objective that become an engineering project for a similar result in DC, starting with reverse loop management.

[nkalanaga]

David:  Thank you!  I just threw that "motorized throttle" idea out as an alternative to fancy electronics.  It's nice to see that it's been done, and works. 

For those who want a challange, the original control system for the NP's Pasco hump yard was all relays.  The "analog system" worked for over 20 years, and may still be there today.  It was "replace" with a computer in the very early 70s, right after the BN merger, but even then they fell back on the old system quite often.  The computer simply wasn't as flexible as a human retarder operator, and it still used the analog system to actually control the yard. 

The system ran everything, controlling the retarders and throwing the switches, all in turn controlled by a large control board/yard map in the operator's office, with two-position rotary switches for turnout control, indicators lights, a few levers for the retarders, and a printed switch list for track assignments.  Not too different from a control panel on a large model railroad of the time.  My father loved the job, until the computer came along.  He hated having to sit there, collecting his pay, and watching the machine run itself.

[Chris333]

Negative ghost rider...  Only in Germany. 

That is like putting a spoiler on a bus. Or this:
https://photos.app.goo.gl/o1NJpMaWVlUkUdSD3
 

OK back to electrons.

[Greg Elmassian]

There are tons of software options, JMRI is not the only answer. The Internet is littered with automation programs for DCC.

But why does JMRI make you want to stick a stick in your eye?

Bad experience? Hate computers?

Just curious, since you do seem to have an sort of "road block" to every solution that others think is a good solution for you.

Greg

Ok, so what /is/ the DCC solution here?  I get detection and signaling. And I’ve set up both discrete signal solutions (Modutrak is TracTronics signal logic for all intents and purposes, no computer) as well as computer controlled signals via JMRI and RR Cirkits.

Sorry, but JMRI makes me want to stick sharp objects in my eye.

If I want this layout to parade trains, is JMRI what everyone is thinking of for the DCC solution?  Has anyone touting that actually set up a layout in this way? Or do we just know that after we spend 40 hours learning the ins and outs of JMRI, learning to program java and adjusting tables by hand when JMRI glitches... that we think it should maybe be reliable?

Please tell me there is something other than JMRI in mind here.

[C855B]

... But why does JMRI make you want to stick a stick in your eye? ...

Because like so many enthusiast-developed software "packages", refinement stops the moment functionality is achieved. The UI is infuriating, the learning curve steep and strewn with rocks. The mere issue that objects cannot be edited or modified, but, rather, must be deleted and re-entered tells this professional developer that nobody wants to take on the chore - and it is a chore - of coding true editing capability.

I use and rely on JMRI, and am of the mind there is not a better or more comprehensive solution, but I'm frequently not happy about it. But not unhappy enough to code... those days are behind me, and are going to stay that way.