Back to DC

[DKS]

Curious... and here I thought it was just a matter of buying a bunch of modules, linking them together, and arriving at a solution. Seems not to be quite as straightforward as some claim; indeed, so far DCC doesn't seem to offer an off-the-shelf answer to the problem at hand. Or am I wrong? I remain intrigued.
 

[John]

Because like so many enthusiast-developed software "packages", refinement stops the moment functionality is achieved.

I think the JMRI crew of "volunteers" does a pretty good job of moving things forward .. and if you want something new, I would ask .. or help develop it

[C855B]

Curious... and here I thought it was just a matter of buying a bunch of modules, linking them together, and arriving at a solution. ...

Easy reverse loop management, simple occupancy detection and momentum braking are DCC solutions that don't require external tech. Automation is something else.

I think the JMRI crew of "volunteers" does a pretty good job of moving things forward .. and if you want something new, I would ask .. or help develop it

That, actually, is my point. "Something new" they're happy to jump on, just as long as it's adding to the feature pile. Going back and making the UI comprehensible just doesn't seem a priority. And like I said, my coding days are over - I hated to code, but was good at it, only coding if somebody made me mad enough. Not to mention, I've already fought that war, writing a fairly major app that was easy to use and obvious in function, and my peer developers didn't get the hint. Good UIs are hard work.

[lashedup]

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

OK back to electrons.

LOL. Holy crap that is awesome on some crazy level.

Good UIs are hard work.

You got that right.

[DKS]

Easy reverse loop management, simple occupancy detection and momentum braking are DCC solutions that don't require external tech. Automation is something else.

But about occupancy detection... it's not a matter of knowing a train is there; it needs to be parked in a specific location. So, either the detection must be handled in a short section of track, or some other means is required. And reverse loops can be handled with ease as part of automation. So, that sort of just leaves momentum braking as the best task for DCC... so far, it would seem...

Good UIs are hard work.

QFT
 

[Sokramiketes]

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.

I agree.  Like so many other things, I have such high standards now thanks to Amazon, Google, Facebook, etc that I'm growing soft when it comes to unrefined, hobby-shopped software. 

So what other options are out there competing with JMRI?

[Sokramiketes]

But about occupancy detection... it's not a matter of knowing a train is there; it needs to be parked in a specific location. So, either the detection must be handled in a short section of track, or some other means is required. And reverse loops can be handled with ease as part of automation. So, that sort of just leaves momentum braking as the best task for DCC... so far, it would seem...

QFT

I think the thing DCC has over DC for block detection is AC current detection is easier and more refined.  Good DC detectors need an AC tickler, and that's more complexity in wiring transformers to power the detectors.  The DCC coil detectors are pretty easy and just need 12V power.  But past that, it's the same wiring and blocking on the layout itself. 

Reverse loop is somewhat easier DCC, but not enough to tip the scales.

Momentum, now we're on to something.

[DKS]

As an alternative to current-based block detection, what about IR emitter/detector pairs, or even proximity detectors? The latter are available as completely self-contained devices that can directly interface with relays or other circuits.

[mmagliaro]

As an alternative to current-based block detection, what about IR emitter/detector pairs, or even proximity detectors? The latter are available as completely self-contained devices that can directly interface with relays or other circuits.

That's what I would use.  That's why I provided that schematic for a photocell detector.  They are easy to build, don't require attaching anything to the train or the track power, and with just a little care, they can be very dependable even in low  room light.   An IR pair (instead of photocell), would be more resiliant to room light effects, but then again you need a transmitter/detector lined up to form a place where the train can break the beam.  It's your choice, but I would not use current detection in DC.

[Sokramiketes]

True, I'm thinking from the signaling side again, which is where I'll use current detectors since you need to know if a block is occupied or not. 

For animation triggers, and the reverse loop staging scenario, the optical detectors will be best.

[wcfn100]

Good UIs are hard work.

That's because all users are stupid. 

Jason

Former Application Developer

[peteski]

I think the thing DCC has over DC for block detection is AC current detection is easier and more refined.  Good DC detectors need an AC tickler, and that's more complexity in wiring transformers to power the detectors.  The DCC coil detectors are pretty easy and just need 12V power.  But past that, it's the same wiring and blocking on the layout itself. 

Reverse loop is somewhat easier DCC, but not enough to tip the scales.

Momentum, now we're on to something.

Also keep in mind that in DCC there is such a thing as Automatic Braking Control where the train will slow down on its own.  But it seems that no American made decoders have embraced that technology. But it is popular in European-made decoders which are usually much better than the American counterparts (but the cost is no longer too much of an issue).

http://www.dccwiki.com/Automatic_Brake_Control
http://www.dccwiki.com/Asymmetric_DCC

[Point353]

True, I'm thinking from the signaling side again, which is where I'll use current detectors since you need to know if a block is occupied or not.

Beyond one block for each return loop and one for the single track line in between, how many more blocks do you envision needing?
Won't there be just one train operating at any given time?

[SAH]

This thread has been a joy to read on so many levels.  Thought provoking stuff.

Home for the weekend, I decided to replace the Digitrax track power connection with my ancient Troller Transamp 1 power pack just for kicks.  I pulled out stuff I hadn't run in years.  Every locomotive started up without a hitch.  Pure fun for an hour.

The DCC factor has been the demise of a couple of local layouts within the last year.  Others have bagged Digitrax for NCE.  I bought Digitrax because the rest of the local crew had it.  No longer is that the case.

I've no real interest in sound, fancy lighting and the rest of the eye candy DCC has to offer.  I do hope to get to the point where I can invite you all over for a challenging TT&TO session on the AC&Y some day.  DCC enables that kind of ops perfectly.  I'm sure I could build a DC layout that supports TT&TO but I suspect there would be compromises.

Perhaps I simply need to look for a better DCC experience as has been suggested here.  Lots to think about.

[altohorn25]

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

OK back to electrons.

That's just wrong on so many levels...... my C5 is crying in the garage right now..........

Nate