Skip to main content

I have a DCS Remote Commander that I would like to hook up to a loop of track on my Lionel Legacy layout.  The instructions say to hook AC power to the MTH receiver and then two wires to the track.
 
The loop I want to use has four power blocks supplied by four outputs from a Lionel ZW transformer.  Is there anyway that I can connect the Remote Commander in this situation?
 
 
Original Post

Replies sorted oldest to newest

Pops,

 

You can run the DCS Remote Commander on any one of your four loops in Passive Mode, however, only one loop at a time.

 

Just connect the IR receiver to any one pair of Hot and Common wires of your ZW, leaving nothing plugged into the receiver's power port.

 

This and a whole lot more is all in "The DCS O Gauge Companion 2nd Edition", now available for purchase as an eBook or a printed book from MTH's web store site! Click on the link below to go to MTH's web page for the book!

 
 

If I am reading you correctly you have ONE loop of track with 4 seperate power connections. Each one is connected to a different output of a ZW transformer. If this is correct then the question ask itself, WHY? If you have only one loop of track you need only one output from the ZW. Take all four power feeds and conect them to either the "A" or "D" terminal on the ZW. This will give you one power feed to which you can connect the DCS Remote Commander.

 

Al

Barry, Pops has four power blocks (districts) combined into one loop.  This has been done to allow for multiple trains to run on what is a rather large loop of over 120 feet.  Is there a way to possibly couple the signal output of the DCS Remote Commander to all four blocks?  Maybe with  four appropriate size capacitors.  If not then there would seem be only one way to get this to work.  That would be to rewire the loop as one  power district and use a continuous bus to supply power around the loop.

Is there a way to possibly couple the signal output of the DCS Remote Commander to all four blocks?  Maybe with  four appropriate size capacitors.

If there is I'm not aware of it. The danger, of course, is that connecting the four power districts all to the same DCS Remote Commander would also connect the AC. I don't know enough to say if there's a filter that would pass the DCS signal without passing AC and without seriously compromising the DCS signal.

 If not then there would seem be only one way to get this to work.  That would be to rewire the loop as one  power district and use a continuous bus to supply power around the loop.

No, there's another way, as well. That would be to use 4 DCS Remote Commander receivers, one wired in passive mode to each loop and all 4 wired back to a central point on the layout. All DCS Remote Commander receivers will communicate with any DCS Remote Commander handheld.

 

Although it's a bit pricey at ($160 MSRP), its' still about half the price of a full DCS. And you get 3 extra handhelds, as well.

You have to read down a bit in this thread, but Dale M. just started experimenting with the capacitor idea to communicate to 2 separate power blocks with a single Remote Commander.  As he says, "stay tuned," but my guess is it's going to be one of those Your Mileage May Vary scenarios. You might want to add your application to that thread as it's slightly different but clearly relevant.

 

 

Originally Posted by Barry Broskowitz:

No, there's another way, as well. That would be to use 4 DCS Remote Commander receivers, one wired in passive mode to each loop and all 4 wired back to a central point on the layout. All DCS Remote Commander receivers will communicate with any DCS Remote Commander handheld.


One operational quirk with multiple receivers occurs when an engine or powered rolling stock straddles two blocks. 

 

Per the other thread, if two receivers simultaneously talk to an engine, the DCS commands interfere and nothing gets through. Unlike the TIU where communications on its 4 outputs are under control from a single master, two (or more) Remote Commander receivers seeing the same handheld command are ignorant of the other.

 

I suppose you could live with these communication dead-spots though if a train came to rest straddling two blocks you might not get a command through to go again.  A minor twist to the age-old issue of straddling power blocks...

Stan,

I suppose you could live with these communication dead-spots though if a train came to rest straddling two blocks you might not get a command through to go again.

You're worrying about a non-problem. There are no "DCS dead spots" in your scenario.

 

First, there is no issue at all when a PS2 or PS3 engine straddles tracks belonging to two different DCS Remote Commanders. This is exactly the same as straddling two tracks belonging to two TIUs that are in Super TIU mode.

 

Further, if two operators were to issue commands at the same time, this is also no different than two DCS Remotes attempting to send commands to the same engine at the same time. The engine would simply make the best of it and obey whatever commands it can interpret, in the order in which it receives them.

 

Since all DCS activity occurs at the speed of light (somewhat reduced due to not  happening in a vacuum), it's unlikely in the extreme that two commands would even be issued or received at the same time.

Hi Barry,

 

As reported in the other thread, two Remote Commander receivers on the same power block interfere with each other when listening to the same handheld.  The engine does not respond.

 

The Super TIU example is slightly different. Unlike the Remote Commander, TIUs can confirm an engine received a command, and if not (such a packet interference from another TIU) to wait and try again - repeatedly. To my way of thinking, this makes it more likely the Super TIU would work better.

 

As for being unlikely that two commands would be issued at the same time, that’s the essence of the problem.  If the two base units could send the same signal at absolutely the same time, I suggest it would work. It’s that they don’t send them at  absolutely the same time that causes the two signals to get garbled at the engine.

 

I’ll agree to disagree on this one!

Stan,

As reported in the other thread, two Remote Commander receivers on the same power block interfere with each other when listening to the same handheld. 

First, we're not talking about two receivers on the same track, rather we're talking about two tracks being bridged for a split second. Second, I just don't buy that two receivers can actually send commands at the exact same time (see below). If you stop a train straddling two tracks belonging to two receivers, a command will get through. Remember, unlike TMCC or Legacy, a TIU is not always sending a signal. It only sends packets when a command is issued.

The Super TIU example is slightly different. Unlike the Remote Commander, TIUs can confirm an engine received a command, and if not (such a packet interference from another TIU) to wait and try again - repeatedly. To my way of thinking, this makes it more likely the Super TIU would work better.

When a TIU sends a command, it does, indeed, wait for an acknowledgement. However, it can lock up the TIU for as long as a minute while it waits. That's the worst possible outcome, and why Speed Mode was added to DCS - to prevent that from happening. The DCSRC works in Speed Mode all the time.

If the two base units could send the same signal at absolutely the same time, I suggest it would work.

First, the odds against that are so small as to be nonexistent. When electricity travels on the order of 186,234 miles per second, synchronicity just isn't going to happen. One command always gets to the engine first. However, even if they did arrive at exactly eh same time, how would you know it? You can't measure things moving at relativistic speeds.

Originally Posted by Barry Broskowitz:
 
First, we're not talking about two receivers on the same track, rather we're talking about two tracks being bridged for a split second. Second, I just don't buy that two receivers can actually send commands at the exact same time (see below). If you stop a train straddling two tracks belonging to two receivers, a command will get through.
 
Hello again.
 
When a train is stopped straddling two tracks belonging to two DCSRC receivers, isn't this equivalent to two DCSRC receivers on the same track for the purposes of DCS signaling?  That is, both DCSRC bases will be transmitting on the same "wire" because of the straddling. Even if the train is going a few sMPH, the "dead-spot" or time interval during which commands might not get through, will be more than a split-second - that is, longer than the duration of the DCS transmission ... particularly so if the DCSRC uses "speed mode" as you say. Again, this is based on the reported observation that commands don't get through if two DCSRC receivers are on the same track. I take the observation at face-value.
 
I absolutely agree that the chances of two DCSRC receivers sending their identical commands out at absolutely the same time is non-existent. And that's the point. Because the two or more DCSRC bases are not exactly synchronized, their DCS commands will be skewed, overlap and conflict such that an engine listening to both (i.e., straddled across two blocks) will have trouble decoding either.
 
 
 
 
 
 
 

stan2004,

Your post are some what confusing but that may be due to the use of the word "receiver" and then the use of the phrase "base unit". There is only one receiver and that is in the engine. There are two base units, each containing one transmitter for a total of two transmitters. And there is one hand held controller talking to the two base units at the same time causing the two base units to attempt to transmitt a command to the same receiver at the same time. The question is "Will the signals from the two base units interfer with each other and what will the result be?". Appearently the answer from observation is that during the short time that the condition exist the command will be ignored. Is my understanding correct?

 

John,

Your solution may work on some layouts but as I understand this one it would be impractical. Simply running the train around the loop one time could result in constantly operating the switch.

 

Al

Stan,

 Again, this is based on the reported observation that commands don't get through if two DCSRC receivers are on the same track. I take the observation at face-value.

Let me be perfectly clear: you can most likely have a dozen DSCRC receivers on the same track and if you point the handheld at only one of them and issue a command, there is absolutely nothing to prevent the engine from obeying that command.

 

Conversely, if you send a command into more than 1 of those receivers, you may experience problems - because that would, in effect, cause more than one instance of the command to go to the engine, at close to the same time.

Last edited by Barry Broskowitz

John,

I also posted this on Dale's thread. Why can't you attach the remote commander's passive power connection to a rotary switch that's connected to all power blocks and switch it as the engine moves between blocks?

The problem isn't connecting the DCSRC to multiple track blocks per se, rather, it's only a problem when those track blocks are fed by different power sources.

 

If they're all fed by the same power source, just connect the DCSRC receiver to the transformer output terminals or to the entry to a terminal block connected to those transformer terminals.

 

This whole discussion is moot unless one is connecting to a loop that has multiple power districts fed by multiple transformers. This is a situation that is most likely not very prevalent on layouts where a DCSRC is being contemplated as a substitute for a full DCS TIU and remote.

Originally Posted by HOSO&NZ:

stan2004,

Your post are some what confusing but that may be due to the use of the word "receiver" and then the use of the phrase "base unit". There is only one receiver and that is in the engine. There are two base units, each containing one transmitter for a total of two transmitters. And there is one hand held controller talking to the two base units at the same time causing the two base units to attempt to transmitt a command to the same receiver at the same time. The question is "Will the signals from the two base units interfer with each other and what will the result be?". Appearently the answer from observation is that during the short time that the condition exist the command will be ignored. Is my understanding correct?

Hi Al,

Thank you for pointing out my inconsistency and I agree it is confusing. "Receiver" is the name MTH uses in the DCSRC manual.  Either I picked up "base unit" from another thread or that's what my brain unconsciously wants to type!

 

dcsrc

 

Yes to your question.  And great job summarizing the issue so succinctly. 

 

The proposed solution was 4 base-units (one hooked passively to each power block) each wired back to a central point on the layout. My reasoning is if the base-units are central, all 4 will simultaneously see a remote command.  Each base-unit will then simultaneously send out the same command to its power district. But if the engine is stopped or moving slowly over a gap, the commands from two base-units will collide on the straddled power blocks.  And because the commands will be slightly off in timing, they will overlap, garble and the engine cannot decode it. 

 

Even if the MTH engine is wholly within a ~30 foot long block, a 2nd engine (non-MTH) or powered car could be stopped or straddling the adjacent gap which would also cause the problem.

 

But as I stated up front, this is just an operational quirk. The sky is not falling, there is no wolf, and the Emperor still has clothes.

 

As was described in the other thread, if the base-units can be strategically positioned (and shielded or masked in some way to defeat its omnidirectional lens), the remote could be aimed at one base-unit at a time. Then only one base-unit would see a given remote command and only one base-unit would send a DCS track signal hence no garbled command overlap.

 

John's rotary switch suggestion raises an interesting point.  I can't think of how to do it economically but it reminds me of insulated rail block occupancy detection.  If there were some way to detect the presence of an MTH engine on a block, then the base-unit attached to that block alone gets powered up.  It would be an automatic solid-state rotary switch.  Nothing says a rotary switch has to be "manual"!

 

And since I presume this is a forum to discuss ideas here's another one.  Since the OP has only 1 MTH engine, what if the base-unit were mounted on the MTH engine itself (say on a flat-car or in a box-car).  I read about this being done on a battery-powered engine. The guts of a DCSRC base-unit was wired in passive-mode onto the DC power wires going to the engine from the battery box-car.  This enabled low-cost remote control; I thought it pretty clever. 

We have a rather unique situation here. There is one loop of track 120 feet long that has been divided into 4 different powered blocks so that 4 different trains can be controlled at the same time. You could install 4 different DCSRC's and seperate them so that they would not try to transmit at the same time but then you would need to find and aim the remote at the correct one for the train location. This sounds good on paper but when the train is going down the track and people are asking questions and other things are going on it may get difficult. Having them all grouped together so that they all receive the command and transmitt at the same time is better but has the limitations we have been discussing. I believe what Dale is attempting to do over on the ELECTRICAL forum with one of these DCSRC's may be a better solution but I don't think he will suceed. It seems to me that the only workable solution is to seperate the DCSRC's or groupe them together and deal with the problems either way. Of course by the time you shell out enought money to buy 4 of these things for a little bit more you could go with the whole TIU and remote and soulve the problem plus have a more reliable and better system.

 

Al

Post
The DCS Forum is sponsored by
×
×
×
×
Link copied to your clipboard.
×
×