We'll talk...

Dear Michael,

Looks like a fun little unit...
(Nathan mentioned you may be looking for Beta Testers,
I have a number of applications in-works and would be happy to help...   ) 

FWIW, (and maybe as a "development feature-request guide"),
arguably the definitive "Simple DCC Shuttle" product-specification can be found at

https://model-railroad-hobbyist.com/node/5122

Highly Desirable (exhibition use, wider market penetration into the UK).

- Loco-address agnostic
(drop _any_ loco _anywhere_ on the shuttle route at _any_ time, 
_without_ needing to reprogram addresses in either loco or shuttle-unit...),

- No extra/external "active detect" circuitry required
(lessens "wires accross module joints" and "mounting key circuitry on drop-leaf staging" reliability issues)

- Easily adaptable to gain single-toggle-switch "Manual Host-DCC control/Auto-Shuttle" mode functionality... 
(The unit shown in the YT example looks to be so adaptable,
with a simple DPDT relay bypass on it's "DCC Output"?)

Stretch Goals

- Capable of semi-automating "I", "Y", and "X" form shuttle routes?
(Deterministic DCC Accy throw commands integrated into the unit's output,
1x pre-configured Accy address toggling in response to each "end-stop arrive" trigger)

- Able to address Consist as well as Individual Loco addresses?

Happy Modelling,
Aim to Improve,
Prof Klyzlr

A few thoughts

- Loco address agnostic - Sort of.  You can definitely use the DCC broadcast address, but not all decoders obey movement commands sent to the broadcast address (despite the spec saying they should).  This worked just fine with the NCE and ESU decoders in my test N scale engines, but the decoders in the two GP30s from the videos would not respond to movement commands to the broadcast address.  (I have no idea what decoders are in there - these two came from a late friend of mine when he tore down his layout.  They're probably 15+ years old.)  By default, it configures the first DCC slot to use broadcast (s000), so normally this works.

- Not sure how you'd get away from end-stop sensors.  There needs to be something to tell it that the equipment has reached the endpoint.  In theory you could do it on time, but I think there's enough error in real world model performance that would accumulate over runs so that by a few runs in, you'd be way off your endpoints.   What'd you have in mind?

- The unit feeds out 12V and ground, so it would be easy enough to wire a DPDT relay and toggle to switch back and forth.  This might be a common enough use case to provide an integrated solution.  Not integrated into the reverser necessarily, but an external module.  The problem is that for a typical 5A booster, you'd need at least a 5A-rated relay.  Those things aren't small or cheap.

- Accessory commands upon hitting end-stops?  Saw that in Duncan's old controller when doing a little "competitive research", couldn't quite work out the use case to figure out how the configuration should work.  Thoughts?  Should be easy enough to add, though.

- Consist addresses are in the DCC short address space, so yes, should work.

You asked... (too-many thoughts?)

Dear Nathan,

Don't say you weren't warned, but I've put quite a bit of thought over a long time to the issue of Shuttle systems, and you did ask...

In order of apperance:

RE Address Agnostic:

Yes, “Broadcast Address” seems like a logical solution,
until you try spontaneously mixing ST, B’mann OEM, ST OEM, Lok, and TCS decoders on the one shuttle-route/layout.
(ask me how I know this… ).

In the case of the TVD Train-Shuttle case, the unit “brute-forces” Loco address 1-100 for each start/stop command. This makes it invisible to the End-User,
 (and the 1-100 address range covers “DCC default 3”, covering the majority of
“just pull a DCC-equipped loco out of the box, put it on-track, and it will shuttle-away happily" 
and the vast majority of closed-system NG-roster and Industrial-roster situations),

but certainly makes the code-level and DCC-output operation of the unit more-verbose.
(Sometimes the only way to “make sure you address everyone” is to literally speak to each person in-turn… )

FWIW, this “selective handling of Broadcast Commands” is one of the reasons why “DCC Bitswitch” has three different types of “DCC Brake module”…

“Brake on DC” -
https://tonystrains.com/product/dcc-bitswitchtm-basic-brake-on-dc-signal-generator

"Asymetric DCC” -
https://tonystrains.com/product/dcc-bitswitchtm-brake-signal-generator-asymmetric-dcc

“Active set-speed-zero-packet” (ST specific) -
https://tonystrains.com/product/dcc-bitswitchtm-set-speed-zero-packet-generator

RE “End Stop Sensors” :

Indeed, some form of “end stop” is absolutely required. I agree that “dead-reckoning shuttle” and “time/motion-replay” systems such as those built-into some decoders simply cannot be guaranteed to “hit their end-stop marks” repeatedly, accurately, consistently, for hours-long sessions.

Whether the “end detectors” are:
- “Arrived at end position, send STOP command”
(Track-current-detector, IR/LDR detector, etc
end-detector tells the Shuttle-brain “it’s time to stop your train NOW”…)

- “BRAKE at this position, and wait until told to reverse away”
(Asymetrical DCC, analog 1N400x diode, etc
suitable for use with simple “go for X seconds, then reverse and come-back” dumb-timer Shuttle units…

IE the end-stop system “catches and holds” the loco as it gets to the nominated “end position”,
_independent_ of whatever the Shuttle-brain’s current-state is…

NB that such a system requires “X” shuttle time to deliberately _far_exceed_ the actual required “time to travel the length of the shuttle route”…)

- Optical (can detect either Locos or non-powered rollingstock)

- Track/current-based (detects Locos and SoundCar units only)

Are Conceptual and Interfacing issues.

However, the part that I’m highlighting is that it is beneficial to not-require any _active_circuitry to be _physically_ mounted “at each end-stop position”.

Why?

Because in the case of many semi-permanent, portable, show and exhibition layouts, those “end stop positions’ are located on an incredibly thin (approx 1") “dropleaf” or similar “staging area” benchwork.

IE there is scant-little room either above or below the track for IR or LDR detectors, or associated circuitry.

Examples, many of which have the trains "end-stopping" 4' above a very long and scary drop off the drop-leaf to the floor...
(This layout used an _Analog_ "dumb timer" shuttle, with simple single-diode stopping-sections.)

A "Dead Rail" logging layout, so no shuttle-unit here,
(although it would be a perfect application for such a unit!),
but a "live in-situ" example of how scary it would be for a shuttle to launch a train off the RH "dropleaf",
if the End-stop detection system did Not Work...

Further, even if such circuitry _could_ be physically mounted at the appropriate position, 
the additional wiring required to operate said circuitry:

- DC Power IN to the detectors
- Active “sense signal” OUT from each detector to the Shuttle “brain”

Makes for a significant increase in wire-count crossing the folding/splitting module<> staging joints
(increased build, maintenance, and transport complexity),

And for “removable drop-leaf” staging places a mission-critical, fragile piece of circuitry in very-vulnerable position during setup/teardown/transport/storage stages…
(EG What happens if/when the “sense line” connection between the Detector and the Shuttle-Brain is unexpectedly severed, or has an undiagnosed “wiring airgap” fault?
 4’ off the floor at the end of a dropleaf is not where you want to discover the end-detector is not working…)

IGNORE the dodgy commentry, and the fact that this dropeaf has a _traverser_ embedded in it,
the key details for the purposes of THIS conversation are:

- the thin-ness of the dropleaf
- the "fold-up for transport" position which places any Under-dropleaf circuitry and wiring in a Very Vulnerable position
- the need for any-and-all wiring to handle the repeated flexing of the dropleaf<> module hinging

In the case of the TVD unit, the “end detector circuitry” was track-current based, 
built into the “shuttle brain” (IE no physically-independent circuitry outside the unit, 
and certainly no-need for remotely-located boards mounted at/near the respective physically-vulnerable “end stop” positions),

And required only a single extra dedicated “end-stop wire”, of same known-reliable physical/mechanical/electrical properties and strength (read: known road-rugged proven) 
as the existing “Track buss” wire to operate.
This means high-reliability and minimal increase in “cross-module wire-count”. 

Such simple end-position solutions also make it easier to handle shuttle routes with 3-or-more potential end-stop positions, IE shuttle routes with “Y” or “X” schematics.

RE “DCC Host Control”/”Auto/manual control” switching :

I would argue that integrating a “relay bypass” _within_ the Shuttle unit is actually the easier and better solution. 
A simple DPDT “power switch” can provide 12VDC to the Shuttle unit, and power the Bypass relays.
(See below) 

For the End-User, it would present as:

- a single obvious hardware “Power Toggle” switch
(capable of “OFF/Bypass” or “ON/Shuttle” states)
- a 2-terminal “Host DCC INPUT”
- a 2-terminal “Shuttle-route DCC OUTPUT”
- a “Shuttle-Unit 12VDC DC Power IN”
- (and whatever “end stop detection INPUT” terminals the system requires, 
min one-per-end + maybe a “mid-route station-halt” input?)

The below is my personal TVD unit, modified with Bypass Relay switching as described, built into a simple Jiffy-box enclosure. The green multi-pin "Output" connector is required in this instance because the TVD unit has the following "Rail output" terminals:

- "North Rail"
- "South Rail"
- "Sth Rail East End-stop"
- "Sth Rail West End-stop"
- "Sth Rail mid-route Station-pause"

From L--> R

- GREEN "PSU Power OK" LED
-  ORANGE "Shuttle Mode ON" LED (OFF = "Host DCC Bypass Mode")
- Toggle "Bypass switch"
  - ...and of course, the TVD Train-Shuttle...

From L--> R
- Green Multi-pin "DCC Track Output"  -  2-pin Green "Host DCC Input"  -  DC barrel "Power Input"

Given that it's unlikely that entire-fleets of locos will _all_ be "shuttling" at the same time,
(IE the ISE Shuttle booster won't be asked to deliver more than an Amp or so in operation),

and equally the "restricted physical shuttle-route" is unlikely to have the room to host the entire layout roster in "manual Host DCC drive" mode, 
(not enough locos being powered via the bypass-relays to draw more than an Amp or 2),

I don't think "5+ Amp bypass relays" would be really required???

Re Accessory commands:

There are a number of potential applications. Depending on whether you are thinking

- unscenic'd “track-on-plank Tradestand Demo” 

- “small show layout semi-automation”
(Thanks for the pic goes to Ian Holmes and his seminal "7 Day Model RR" website)

- “home layout feature addition”
(start at 14:02 for the "shuttle section")

will determine whether the following examples make sense or not.

-    At it’s core, when most USA modellers think “shuttle”, they think of a simple, physically and electrically-isolated “Point-A to Point-B” single-end-point route, which schematically looks like an “I”.

In such cases, a “toggle Accy address on end-stop” feature could be used to trigger “arrived at end-position” signals, animations, or anything an Accy decoder can drive.

-    Now, consider a small/micro layout depicting section of main-line, with a single turnout feeding an industry spur a la Lance-Mindheim-esque “single turnout” layout (See August 2020 MR for the “Practise Plank” layout, a perfect example). 

Such a layout forms a schematic “Y” or “tuning fork” shape.

Sweeney Manufacturing, a Tuning-fork example from the scarily-proliffic Rob Chant

If the “handle” end-stop detector caused the turnout-accy-decoder to “toggle state”, 
then a “shuttling train” could alternately shuttle from Main-line to spur, 
and back again (ad infinitum, ad nauseum), 

nicely emulating the slow repetitive “pull-shove” action of switching the industry.
(Hint: integrate the “Host DCC Bypass” feature, and this would be a great way to have a simple layout which can be “PT manual driven” OR “stand back and railfan the switching action” as whims dictate…   )

-    Take the above, recast the “mainline” as the drill-track for an industry,
replace the “road loco” with a small switcher,
and both “tines” of the Y as different points in a multi-spur industry,

and you have an adjunct to the mainline action on a home-layout,
where the dedicated plant switcher “merrily keeps switching cars between plant spurs”
(IE an “added interest” or “moving scenery” feature while the “hardcore operators” focus on keeping the separate mainline running…)

-    Back to small show-layout examples, and another “ ‘Y’ schematic” situation…
…only this time the “Y” has TWO turnouts and THREE tines
(more like a Cutlery Fork than a Tuning Fork)

where one tine punches thru the backdrop to a “fiddleyard” staging track, and the other 2x tines are “onstage”.

With strategic arranging of the respective End-stop<> Accy-address/turnout throwing,
you could have a system where a _pair_ of trains are parked on the “onstage” spurs,
and each takes a turn to shuttle out-of-sight “offstage”
(onto the “backstage fiddle-yard  tine/spur”, or prototypically “somewhere else”)

and back again…

…indeed, with strategic “fast hands” work in the “fiddle-yard”,
during the “end-stop dwell time” between shuttle-unit “changes of direction”, the train that “disappears offstage” might be replaced with a _different_ train coming back _onstage_,
to the confusion and delight of particularly the younger layout-viewers…

Update: Was just cruising thru the UK-based "RMWeb" forum, and caught this show-layout-under-dev.
It depicts CSX's "Plant City Florida Potato Spur" prototype location, and is a perfect example of a
"model scene with a punch-thru-the-backdrop staging/fiddle-yard track" situation.

- As a quick aside, here's an example from the UK, where a "main" and an "industry" are both shown,

https://kidmorengauge.weebly.com/kidmore-halt-oo-gauge.html

https://kidmorengauge.weebly.com/kidmore-valley-railroad.html

it is "implied" that they connect somewhere "to the left offscene"
(which they might do in model form via a traverser or sectorplate),

but with TWO shuttle units, could host a shuttling RDC/Doodlebug on the frontmost "main"
(maybe with a "station halt" input to the Shuttle unit,

allowing the RDC to "stop at the depot", listed as "shelter" on the pic below,
 during each pass?)

while an "industrial switcher" shuttles between the two industrial spurs towards the backdrop

-    Now, to extend the application for Home layouts, 
take the above “moving scenery” dedicated-industrial switcher example above,
(shown as GREEN trackage in the diagram below.
The Industry Switcher shuttles between the GREEN industry tracks and the "Industrial Lead" track,
using the "Accy toggle" of the Spur turnout to swap between Industries 2/3 and 4 spur tracks on alternate "shuttle cycles"...)

and connect the “handle” of the shuttle route “Y” to the main layout.

Original diagram modified and posted with respect to Rod Chant

By “parking” the industrial-switch-loco “in the clear”,
(note the short little green "kickback spur", which is perfect for stashing the industrial switcher.
This could be accessed via a non-shuttle-toggle-controlled manual/ground-throw turnout),

switching the Shuttle unit to “Bypass mode”,
(thus allowing the main layout Host DCC system to control the shuttle-route trackage),

and opening the “Mainline <>  Industrial-lead” turnout,

a “road train” can do a “grand-pull/grand-shove” swap-spotting of a rake of cars from/to the industry under “manual human control”.

- Close the Main<> Industrial-lead turnout,
- kick the Shuttle unit back to “shuttle mode”,

and the industrial switcher can now resume “moving scenery” duties with a fresh set of cars…

SOOO, I'm unsure if that helped, 
or just made it as-clear-as-mud,

but either way, I can vouch that having each end-stop trigger a Toggle of perscribed "Accy Address",
(does not _need_ to be user-configurable,
just map the "West End Stop" to toggle Accy Address 0001,
and the "East End Stop" to toggle Accy Address 0002,
job done...)

could have a wealth of practical uses, and would certainly broaden the appeal of the "ISE Shuttle Unit" well beyond the continental USA...

Happy Modelling,
Aim to Improve,
Prof Klyzlr

Accessory decoder

Nathan,

The accessory commands would be used to implement for example W, X or Y track configurations the Prof was talking about. Once a train hits an end stop a switch could be thrown via a DCC accessory decoder command on the track. The switch accessory decoder(s) could be connected to the track and read its commands from there. This saves on extra wires across module ends and hard wiring switches to the train shuttle controller.

...and whaddaya know...

Dear Nathan,

Funny how timing coincidences happen occasionally. Looks like "OzTrainz" on his "Corrimal" layout is considering _exactly_ the kind of "Y schematic" shuttle route that a shuttle-unit with integrated toggling-accy-address functionality would be perfect for...

https://forum.mrhmag.com/post/corrimal-colliery-and-its-incline-a-different-slant-on-rails-12206968

In this case, both "tines" of the "Y" are "hidden behind the backdrop".
The result is a single onstage track, where _different_ trains "appear onstage" for each "shuttle cycle"...
...to the confusion and amusement of onlookers, in adjunct to the "main layout" manual operations show...  

Happy Modelling,
Aim to Improve,
Prof Klyzlr

ISE - Train Shuttle Controller

Cool!

I’ll take two, please.

Charles

I will throw my challenge

I will throw my challenge from 2014 back onto this thread as follows below.  Replies back then discussed the JMRI and multiple blocks approach, as well as Arduino, but I figured this might add food for thought.  Embarassingly, other layout work has kept me from even attempting an implementation as was suggested almost 6 years ago.

From the old post:

I would like to animate a segment of my layout that is a stand-alone section of track.  It is the track that goes from "deep in the mines" to the top of one of the crushing plants.  There is a long incline, trestle and the crusher itself.  

In real life, the incline track comes from the mine, and the locos in such service push a sting of loaded side dumps several miles on the route from the bottom of the pit to the top of the crusher.  On my layout there is no mine at the bottom, and the lower end of the incline track just ends against the wall, some 8 feet from the trestle. 

I have a loco and three side-dump cars on the track that I want to go (automatically) up and down the incline, and would ideally like to control a Tsunami equipped loco for the sounds.

General sequence of events:

1. The loco should (arbitrarily) start at the bottom of the incline, against the wall.  The loco should go to full rpms (sound) but only move at perhaps a good jogging speed up the incline. 
2. Near the trestle/top of the incline, the loco rpms (sound) should drop to idle, and the loco should slow to a walking speed and blow it’s horn (to alert the dump operators)
3. The loco should proceed out onto the trestle until the first car is over the dump pocket. It should stop there, pause (presumably to dump the first car), rev up and begin moving at walking speed. 
4. The loco should proceed further onto the trestle until the second car is over the dump pocket.  It should stop there, pause, rev up and begin moving at walking speed.
5. The loco should proceed further onto the trestle until the third car is over the dump pocket.  It should stop there, pause, reverse direction and rev up to moderate rpms and begin moving down the incline at moderate speed.  It should NOT stop at any intermediate points when heading "back down".
6. The loco should stop at the bottom of the incline, pause and repeat the above sequence, ad nauseum.

Milt's ore dump shuttle....

Dear Milt,

What you're describing can certainly be achieved in a number of ways, using various combinations of equipment (including, but in-no-way-mandating, a standalone JMRI installation),

although the use of Tsu decoders throws a couple of bumps in the road

(Hint: Search "Asymmetrical DCC Braking" and "brake on DC").

I'm at work right now, but can put some thoughts together later on this evening... 

BTW, what DCC system does your layout currently use? 

Happy Modelling,

Aim to Improve,

Prof Klyzlr

First off, I offered this

First off, I offered this rehash as food for thought, and in the mean time since 2014, all of the diesels have been converted to ESU. I am running Digitrax, JMRI and can use a PC to do the heavy lifting as needed.  I can surely implement the advice offered back in '14, and it included your (Prof) input back then.

Curious to see what advances may have been achieved in the mean time, and always so appreciative of your thoughtful responses.

Digitrax, darn, was hoping you'd say "NCE"...

Dear Milt,

Darn, I was kinda hoping you'd say "NCE", in which case a MiniPanel + a couple of Accy Decoders (in tandem with the Lok's "Asymmetrical DCC braking") would be a walk-up solution...

Will have to give this some thought, as I'm not a Digitrax user. Sure, for a guaranteed physical + electrical standalone route, a standalone "drive system" like the ISE Shuttle, TVD Train Shuttle (RIP), or Dr Geoff's "DCC Function Generator" would work, but having a solution which integrates into the existing layout Host DCC system centralises Command-and-Control, and minimises the amount of "extra hardware to buy".

In the meantime, strongly suggest looking up CV27 in your Lok decoders (Hint: try CV27 = 1, 2, or 3, and observe the differences in behaviour...

... It's a zero-risk single-CV-change experiment)

And pick-up a bulk pack (minimum 10) of 1N4001 silicon diodes...
(allows build-up of a pair of cheap "Asymmetrical DCC" directional-stop generators).

More once I get some clear brain-cycles to apply to the issue...  

Happy Modelling,
Aim to Improve,
Prof Klyzlr

Updates

So given the Prof and others' feedback (and yes, you're right, Prof, I certainly asked for it...), we've gone back and made some adjustments.

1) Accessory decoder control has been added.  Currently the unit can trigger up to 6 accessory addresses, each can be configured to start in either set or cleared, and each can independently change in the following ways:

• Set on left sensor, clear on right sensor
• Set on right sensor, clear on left sensor
• Toggle on left sensor
• Toggle on right sensor
• Toggle on left or right sensor
• Any operating modes you can think that I missed?

2) Optional single rocker switch in the faceplate that will allow you to select between the pingpong controller, your normal DCC/DC system, or isolated.  Can handle the full 5A that most boosters or throttles put out, so no worries there.

3) Intermediate stop sensors.  Added two more inputs to the board so that left and right intermediate stop sensors can be added.  By using a left and a right intermediate sensor, stops can be triggered with suitable running room in either direction so that the train decelerates to where you want it to stop, not a little past. 

If you don't want dual sensors, or would rather use a current-detecting block around the intermediate stop, the inputs are active low so you can just hook them together.  Likewise, because the inputs are active low, you can connect any number of intermediate stop sensors in parallel for multiple tracks or multiple stops.

Intermediate stops have a configurable stopped delay separate from the end stop delay time.

4) For the concern about electronics out at the end, it's easy enough to swap out the IR sensors for current-based block detectors with an open collector output.  Then they can be safely mounted wherever convenient, and only a wire or two runs out to any outriggers.  Optical is easier and better for some applications, current for others, so we'll just go with "why not both?" and make detector choice separate from the control unit.

5) The one thing we decided to not do is the "transmit address 1-100" broadcast mode, as doing that would add considerable latency to track response.  Assuming DCC can push roughly ~180 packets/sec (rough estimate based on 3-byte packets) through the rails, 1-100 for speed/direction alone would be a half second delay, and then add functions in there and you're looking at 3-4 seconds for a full refresh.  Plus it seemed like a solution that wouldn't work for many US modelers as we tend to use long addresses.  I suspect this might be one of those differences between US/CA, European/UK/IE, and AU/NZ modelers, probably just coming from how our prototypes tend to number things (four digits vs. class and unit number, etc.)  It wouldn't work at all for me since I don't have a single loco on my layout that responds to a short address, except when consisted.

Milt - what you've got is definitely an interesting problem, and not one that I think I can solve in a general-purpose controller without making configuration ugly for everybody else.  However, that doesn't mean we can't use some special-purpose firmware on the same hardware to do the job.  Seems like an interesting project.  Once I get this thing up and running as a product, let's talk about your application.

Definitely

interested in this.  I need to re-think my wiring strategy so I can flip one track to be auto-controlled with this setup and then flipped back for regular use.

Feedback-loop...

Dear Nathan, Milt,

Good to hear my ramblings made at least some sense...

Responses in order of appearance:

RE "Missing Accessory triggers"

To match the TVD unit, you're missing:
- Set on Mid-route arrive, Clear of Mid-route depart

and I'd suggest adding:
- Set on End-Stop arrive, Clear on End-Stop depart

RE "Bypass Toggle"

Good move

RE "Mid-route stop detection lines"

Um, why do we need seperate "Left and Right" Intermediate input lines?
Given the experience with the TVD unit, a single "Intermediate" input line,
which can be connected to as-many "intermediate position detectors" as required,
would seem to be-enough?

...and while we're talking "single input lines connected to multiple detectors/positions",
will the "end detector input lines" be able to handle multlple-detectors,
EG to handle "Y" schematic routes?

RE "Electronics on the end - Why not Both?"

Assuming we're working with an "active" shuttle system, I agree that both Optical (IR, LDR, Laser, etc) and Current detector options have their place...

...but I'm still keen on the idea of _Passive_ shuttling, 
(Literal "dumb timer" reverser),
with simple, independent and physically-robust "end-stop braking"...

...I mean, there's decades of reliable analog "dumb timer" shuttle operation with single-diode "don't pass beyond this point" stopping-sections, which speak to the reliability + compatibility + sheer-utility of the solution...

...just a pity that to emulate it in DCC takes a mode which is only supported by a few decoders,
despite being pretty-clearly-defined in NMRA S9.2.2   

Side-question: If a loco is "0-5-0"d onto one of the end-stop positions,
(IE right on top of the end-stop detector)

and the Shuttle Mode enabled,
what happens?
(This is important for both "Dynamic" applications such as exhibition layouts,
and "Home user" applications where the "parking position" of a "moving scenery" shuttle route will likely be considered "at one end of the route",
and thus will define a "starting condition" which could pose problems...

...it is problematic to require the shuttle loco to "always start somewhere in-between/clear-of the end-stops")

RE "1-100 address space"

A couple of things here:
- The original TVD handling of this need was prompted by the need to be able to spontaneously 0-5-0 any "show roster" loco onto the shuttle route, and have said loco "just begin shuttling" without any need to reprogram or adjust either the "shuttle brains", or the "current shuttle loco"... (Analog Shuttle FTW here... )

- In discussions, it was figured that a specific "exhibition roster" of locos may-as-well use "last 2 digits of the cab number as the active address", and thus have all locos falll within the 1-100 address space,
without too much brain-bending required if "manual drive" loco assignment had to occur...

- Bonus points (if it can be called that), assuming a "total show loco roster failure",
the "1-100 address" feature meant that the Exhibitor could run over to the nearest trader,
buy a "DCC Equipped" loco of suitable type (at least),
and have the "Default Address 3" loco "just work" on the shuttle route
(IE "the show can go on"),
again, without any need for tweak/adjust/reprogramming either the shuttle-route brains or the "emergency panic purchased" (not otherwise pre-prep'd for "show roster" work) fresh-out-of-box loco...

- I totally appreciate the "brute force" method of addressing 1-100 incurs inherrent DCC-bandwidth lags,
but in practical testing with my TVD unit, it does not seem to be a noticable or problematic lag...
IE the loco still "stops where you expect it to" repeatedly, reproducibly, irrespective of whether it's "default address 3" or "deliberately address 99"...
(admitedly, I performed all testing at "scale switching speeds" approx 10smph,
so even if there was a significant lag in "end-detect event --> brute-force Stop command",
the loco isn't going to appear to "run on" any significant distance... ).

- The commonly suggested "workaround" for 4-digit-locos on the original TVD "1-100" system was indeed to temporarily consist them, even if it meant making the desired shuttle loco "a consist of one loco"

Given the aforementioned desire to avoid having to tweak/config/reprogram either the "shuttle smarts" or any locos "mid show" just to enable the shuttle-route under exhibition conditions,
the "setup the 'exhibition loco roster' locos as 'last 2 digits of cab number'" option generally ended up being the better all-round solution...
(better than having to constantly manually Un/consist various locos every hour or so,
as each "exhibition roster" loco takes it's turn on the "shuttle route"....)

- For those who literally can't see past the "4-digit address, or nothing" issue,
there's a reason why the TVD unit later grew an optional LCD interface which allowed the "default short 1-100" brute-force list to be replaced with a pre-configured 16-entry brute-force list of 4-digit addresses.

NOTE! This was _not_ a "pick one of the 16x 4-digit pre-nominated addresses before initiating the "shuttle",
and the nominated loco is the (only) one that the Shuttle unit commands" situation,

but literally a "user-definable targetted-brute-force list" function...

IE Freely 0-5-0 _any_ of the 16x nominated 4-diigit address locos on the shuttle route,
and without needing to explicitly reconfigure/tell the Shuttle unit _which loco_ is "on track",
the system would "just work",
(It would "brute force" the nominated roster of 4-digit addresses),

and the loco would obediently start-shuttling...

RE Milt's Challenge

I've been in the midst of starting a new shift-work job, so haven't been able to put the brain-time into nutting-out a solution that I'd have liked to. Nathan, given the developments you've made to the "ISE Shuttle",
I think it _could_ do what Milt asks, with the minor addition of a pair of simple timed-trigger-relay units.

Bare with me for a moment...

Ingredient 1- The ISE Shuttle unit + chosen end-stop Detectors will handle the "end stops" at either end of the shuttle-route
(The "start position" at the bottom of the ramp, and the "3rd and final ore-car-dump" position)

Ingredient 2- An detector (optical or track-current, Milt's choice)
which triggers a simple SPST relay _after_ a perscribed period of time,

and then _releases_ the relay after a subsequent period of time,

will be required for _each_ of the 1st and 2nd "ore car dump" positions.

- NB: Each relay will short accross a respective Asymetrical DCC Braking Diode pack,
as shown earlier in this thread, feedinf gapped-sections at the appropriate "1st and 2nd car dump" positions.

Ingredient 3- The Shuttle loco is already equipped with Lok decoder, so set CV27 = 1 (RH Rail +ve = Brake),
set CV3 and 4 for appropriate basic Accel/Decel behaviour at each end of the Shuttle Route,
and set CV123 and CV254 (Lok V5) as-required to achieve the "throttle-down and creep-up to the DUMP" behaviour (Lok V4s and selects have equivalent CVs, check the manuals for the specific CVs).

Recipe .

The results are that:
Step 1- The ISE Shuttle starts the train UP the ramp towards the Dump positions
Step 2- The the loco hits the 1st "Asymetrical" diode-pack/"1st car dump position",
and starts "braking to a stop" with associated CV123/254 "audible throttle-down" behaviour
Step 3- At this same position, it triggers the 1st "detector".
Step 4- The detector "times out",
(which emulates the "time the train pauses to dump the first carload")
and then triggers the 1st relay
Step 5- The 1st Relay shorts-accross the Asym Diode pack,
delivering NOT-ASYMMETRIC DCC to the loco,
which starting it moving again onwards towards the next "car dump" position
(NB at ??? seconds later, the relay needs to "release", ready to stop the next "dump" movement)

Step 6- Repeat Steps 2, 3, 4 and 5 for the "2nd car dump position"
(Yes, it will require a 2nd complete detector+timed-relay unit and Asymm Diode pack)

Step 7- Loco then hits the "dump end-stop" of the ISE Shuttle,
which acts as the "3rd car dump position",
and stops.

Step 8- After the perscribed "end stop delay time" programmed into the ISE Shuttle Unit,
the ISE sends the train "back down the ramp to it's first-position"

NOTE! Because the "1st and 2nd car dump" positions are controlled by ASYMMETRICAL DCC braking,
they are Automatically Directional, IE the loco will "pause/brake on the way UP the ramp",
but will ignore the braking sections on the way DOWN the ramp,
(will roll straight over them as if they aren't even there),

completely agnostically and independent of the ISE Shuttle system.
(all the ISE Shuttle unit is doing is pushing the train UP the ramp until the "3rd car dump"/dump-end detector is triggered,
and then running the train back DOWN the ramp until it gets back to "1st positions" at the bottom of the ramp...)

Equally, the ISE unit will not have to know, or care,
- which track-direction the train is heading,
- whether it needs the train to stop or not "mid route" for the current-direction-of-travel,
(Indeed, Milt could turn the loco around so it's HEADlight was facing the "other way" mid-shuttle,
and without changing/reconfiguring/tweaking anything,
the above system would still work correctly, only "pausing to dump" as the train headed UP the ramp),

- or why the train seemed to take longer to do the "UP the ramp" as compared to the "DOWN the ramp" part of the shuttle cycle...

FWIW...

Happy Modelling,
Aim to Improve,
Prof Klyzlr

Professor, as always well

Professor, as always well thought out.  Was away on vacation that ignored electronic devices last week. A welcome reset, but miss my trains and fellowship with y'all.

Interesting find... (TVD "Train Shuttle" by another name?)

Dear MRH DCC-Shuttle Curious,

I was stumbling about the net (as I do occasionally) following some random wascally wailwoading wabbit down some research hole, when I came accoss this unit from the UK...

http://www.blocksignalling.co.uk/index.php/dcc-shuttle-sdcc1

Now, TVD may not make their "train shuttle" any more, 
but this unit looks oh-so-awfully-close to the _original_ TVD unit
(Prior to the "add an LCD and accomodate 16x 4-digit address" version),

in terms of:
- required connections to track
- no "active detection" circuitry required for the end-stops
(No IR, LDR, or similar)
- capable of 1/multiple mid-shuttle-route "station stop/pause"
- and the "works with any DCC loco running short-address 1-99"

Hmmm....

Happy Modelling,
Aiming to keep a note of available options from all over the Model RRing world,
Prof Klyzlr

PS these same guys also do a unit which looks oh-sooo-close to a TVD Frog-Juicer,
which again, strikes me as, um, interesting...

"Ping-Pong" / "The Motorman" from ISE

Dear Nathan,

I'm seeiing the banner ads here on MRH for "The Motorman",
https://www.iascaled.com/store/CKT-PINGPONG
/> so I figure our ruminations on this thread bore some form of fruit...

Having read the manual though,
https://www.iascaled.com/docs/ckt-pingpong/motorman-manual.pdf(Page 5, "Step 2"),

I'm still prompted to re-ask this question from earlier on in the thread...

I appreciate that the unit "learns" which-way = "Forward" on initial-move,
but given a loco which starts it's shuttle "behind the backdrop"
(see earlier exhibition layout deployment examples),

having a loco "sitting on-top-of an end-detector, with Loco-orientation unknown"

is an entirely valid starting-condition, which must be either handled gracefully,
or specifically-warned-against in the documentation...
(Witness those "> 4' fall-from-staging-dropleaf to floor" examples cited earlier.)

I would also ask, 
I get that there are "16x Loco-configs" which can be programmmed into the unit,

but if I randomly "0-5-0" any of the pre-configured 16x locos onto the shuttle route,

will the randomly-selected loco "just start running",
(IE does the "Motorman" brute force all of the preconfig'd loco addresses all the time?)

or will I have to explicitly tell the "Motorman" that
"Loco 1234/Motorman-Loco-Config 01 is NOW the one to be commanded"???

I honestly hope that "The Motorman" proves to be a winning product for ISE...

Happy Modelling,
Aim to Improve,
Prof Klyzlr

PS As an exhibition layout builder/owner, I have been away from the layout for just a few moments,
only to come back and find an entirely-trustworthy Layout Operator/Crewmember having inadvertently placed "the next loco due for a run" on the relevant staging-position with an un-expected orientation RE which way is "Loco Fwd"...
...totally not their fault, but the bad-feelings all-round if such a minor "whoops" leads to $$$s of loco/train hitting the floor are palpable...

When I've canvased my regular "Show Layout Ops Crew" before implementing any kind of "semi-auto" train-movement or animation system, the feedback is always the same...
"...happy for you to build and integrate < insert animation thing HERE> into the layout,
but either make it fail-safe/bulletproof, or understand that it will only operate when You are there to monitor it...
(...if it can fail-dangerous under typical-exhibition conditions, then we simply won't enable/use it)..."

Configurations

Only the active configuration runs.  It's not blasting out all of the addresses all of the time.

The two possibilities with the "loco on sensor in learning mode" problem are either refuse to start, which is completely failsafe, or force the user to pick a run direction in the event an endstop is tripped and then if they run off the track, it's their own fault.  Third option is that you can optionally define which endstop is which, which seems like a hassle and a bad idea.  I'll give it some thought.

Otherwise I can't come up with a lot of good ways around the problem of equipment alignment vs. physical left/right.