Remote Commander Passive Mode with TIU

Keith,

It will work fine.

However, be aware that any command issued by one remote commander handheld controller will be acted upon by whichever, or both, receivers that can "see" the controller.

Barry Broskowitz posted:

Keith,

It will work fine.

However, be aware that any command issued by one remote commander handheld controller will be acted upon by whichever, or both, receivers that can "see" the controller.

Thanks Barry

That will work for me. I only intend to run one locomotive with the remote commander. It would be screwed up running 2 (factory reset) locomotives, 1 on each loop.

Oman posted:

... I switched the locomotive under the remote commander control from the outer loop to the inner loop and lost control.

I assume you mean you lost control of that locomotive as opposed to lost TIU control of other DCS engines on the inner loop.  Hence that's why you're adding a Remote Commander to the inner-loop so that a single Remote Commander handheld can control the locomotive on either loop.

The change in behavior you might see is if both you and your grandkids are actively and simultaneously pressing the controls on your respective systems.  Both the TIU and Remote Commander lock-on will spray commands onto the loop that you (TIU) are controlling.  So you might experience an occasional latency or seeming lack of responsiveness as overlapping commands will corrupt each other.  Ironically your grandkids should not see this because the TIU keeps track of where its engines are and should "know" not to send DCS commands onto the loop where there are no actively controlled engines.  That is, the Remote Commander base does not have this level of smarts and sprays out commands even if no one is listening.

stan2004 posted:

Oman posted:

... I switched the locomotive under the remote commander control from the outer loop to the inner loop and lost control.

I assume you mean you lost control of that locomotive as opposed to lost TIU control of other DCS engines on the inner loop.  Hence that's why you're adding a Remote Commander to the inner-loop so that a single Remote Commander handheld can control the locomotive on either loop.

The change in behavior you might see is if both you and your grandkids are actively and simultaneously pressing the controls on your respective systems.  Both the TIU and Remote Commander lock-on will spray commands onto the loop that you (TIU) are controlling.  So you might experience an occasional latency or seeming lack of responsiveness as overlapping commands will corrupt each other.  Ironically your grandkids should not see this because the TIU keeps track of where its engines are and should "know" not to send DCS commands onto the loop where there are no actively controlled engines.  That is, the Remote Commander base does not have this level of smarts and sprays out commands even if no one is listening.

Yes, control of the locomotive under TIU control was maintained. In general, the Remote Commander doesn't seem to be as responsive as the TIU remote. A couple of times, I did appear to lose speed control of the locomotive operated by the remote commander, but on the other hand, I tried the horn and whistle of the 2 remotes at the same time and tried it many times and both always worked. I think it will be good enough. I will be ready to push Emergency Stop. The TIU DCS signal doesn't seem to be bothered by the Remote Commander signal.

Stan,

So you might experience an occasional latency or seeming lack of responsiveness as overlapping commands will corrupt each other.

That's extremely unlikely.

Commands cannot "corrupt each other"unless they are duplicate instances of the same command. Even then, the differential signaling aspect of DCS acts to ensure that duplicate commands are rejected in nearly all cases, keeping any such issues to a minimum. Differential signaling is discussed in The DCS Companion 3rd Edition on page 158.

Actually, using the DCS Remote and the DCS Remote Commander handheld controller simultaneously is even less demanding than using 2 DCS Remotes to control 2 different engines through the same TIU. Latency at the TIU is nonexistent.

Further, in the case of 2 DCS Remotes addressing two different engines, the TIU is simultaneously receiving commands from 2 remotes at the same time. In Keith's case, the TIU sees one command and the DCSRC receiver sees the other.

As far as command packet latency on the rails is concerned, each engine completely disregards commands that aren't addressed to that engine.

This and a whole lot more is all in “The DCS Companion 3rd Edition!" This book is available from many fine OGR advertisers and forum sponsors, or as an eBook or a printed book at OGR’s web store!

Barry Broskowitz posted:

Stan,

So you might experience an occasional latency or seeming lack of responsiveness as overlapping commands will corrupt each other.

That's extremely unlikely.

Commands cannot "corrupt each other"unless they are duplicate instances of the same command. Even then, the differential signaling aspect of DCS acts to ensure that duplicate commands are rejected in nearly all cases, keeping any such issues to a minimum. Differential signaling is discussed in The DCS Companion 3rd Edition on page 158.

I disagree.  Overlapping DCS signals, one from TIU and one from RC, will corrupt each other whether differential signaling is used or otherwise.  By overlapping and corruption I'm about the actual signals/voltages on the track occurring at the same time.  Most network designs where there are multiple talkers typically have a protocol where you first look to see if the channel is free before talking.  Since two TIU channels don't reside on one track section in DCS, this protocol is not required.  It is entirely possible for the TIU and RC to send commands simultaneously and corrupt each other at the signal/voltage level.  I am not talking about engine(s) getting conflicting commands!  I'm talking about engines not even receiving valid commands at all.

Actually, using the DCS Remote and the DCS Remote Commander handheld controller simultaneously is even less demanding than using 2 DCS Remotes to control 2 different engines through the same TIU. Latency at the TIU is nonexistent.

As above, apples and oranges.  I'm talking about the physical signals/voltage conflicting on the track AFTER the TIU and RC have decided its time to start talking.  Again, the two transmitters have no awareness of the other transmission and the signals will interfere rendering them un-intelligible to engine(s).  The discussion gets a bit involved because the TIU and RC use different "strategies"  to insure that commands get through to the engine.  Perhaps your Companion details the ins-and-outs of acknowledge-retry protocol as used in the TIU vs. the RC protocol which does not have to ability to receive acknowledgements from the engine.

Further, in the case of 2 DCS Remotes addressing two different engines, the TIU is simultaneously receiving commands from 2 remotes at the same time. In Keith's case, the TIU sees one command and the DCSRC receiver sees the other.

Exactly.  That you have two different systems operating essentially independently and ignorant of the other's existence is why you can get overlapping command signals on the track. 

As far as command packet latency on the rails is concerned, each engine completely disregards commands that aren't addressed to that engine.

Again, apples and oranges.  I'm not referring to conflicting commands being those destined to different engines (addresses).  The latency or effective responsiveness delay is because the conflicting signals from the TIU and RC means it can take longer for a "clean" command  (in practice a duplicated command) to make it thru the engine's receiver and processing to effect the desired response.  While the DCS protocol can send hundreds of commands per second onto the track, slight delays measured in fractions of a second between pushing a button and seeing/hearing the response can be bothersome to some people.  Additionally, variations in responsiveness can also be bothersome to some people.

Stan,

We're not talking about "radio signals", rather, DCS commands are composed of "data packets", where each set of packets has an address portion. They work in a manner similar to data traffic on a computer LAN, not like radio signals. The only difference is that computer LANs have a ton more traffic than is ever seen in the rails of even a huge DCS layout.

Further, data packets simply don't"corrupt" each other. The only confusion can come from an engine receiving multiple occurrences of the same data packet of address and command, which is not the case in the OP's described scenario. Further, differential signaling is implemented to mitigate that exact scenario, if it was the case, which it is not.

Regardless, let's just agree to disagree.

Barry Broskowitz posted:

Stan,

We're not talking about "radio signals", rather, DCS commands are composed of "data packets", where each set of packets has an address portion. They work in a manner similar to data traffic on a computer LAN, not like radio signals. The only difference is that computer LANs have a ton more traffic than is ever seen in the rails of even a huge DCS layout.

Further, data packets simply don't"corrupt" each other. The only confusion can come from an engine receiving multiple occurrences of the same data packet of address and command, which is not the case in the OP's described scenario. Further, differential signaling is implemented to mitigate that exact scenario, if it was the case, which it is not.

Regardless, let's just agree to disagree.

Verily. We disagree.

If this were actually like an Ethernet network, it would use Carrier Sense Multiple Access/Collision Detect (CSMA/CD), however I see no evidence presented that it does.

 Carrier sense multiple access (CSMA) is a probabilistic media access control (MAC) protocol in which a node verifies the absence of other traffic before transmitting on a shared transmission medium, such as an electrical bus, or a band of the electromagnetic spectrum.

Carrier sense means that a transmitter attempts to determine whether another transmission is in progress before initiating a transmission. That is, it tries to detect the presence of a carrier signal from another node before attempting to transmit. If a carrier is sensed, the node waits for the transmission in progress to end before initiating its own transmission. In other words, CSMA is based on the principle "sense before transmit" or "listen before talk".

Multiple access means that multiple nodes may send and receive on the medium. Transmissions by one node are generally received by all other nodes connected to the medium.

I have to go with Stan on this one.

John,

If this were actually like an Ethernet network, it would use Carrier Sense Multiple Access/Collision Detect (CSMA/CD), however I see no evidence presented that it does.

I said "similar to" an Ethernet network. DCS uses differential signaling. Regardless, when you have evidence of an actual (not hypothetical) occurrence of latency with the OP's setup, be sure to explain to us how it happened. 

Since you're on the wrong track, I suspect I'll get to the destination before you.

John,

Since you're on the wrong track, I suspect I'll get to the destination before you.

I'm sorry to disappoint you, however, I'm not going away. Once again, you're misinformed.

Neither am I Barry, and history will judge if I'm misinformed.

Keith, I'm somewhat dense, and don't understand the reason for all this.  My 6 grandchildren were all able to quickly comprehend how to use the speed (thumbwheel) and whistle and direction controls on the remote (in that order), and then the emergency stop button, on the remote.  This when they were about 2-3.  You could use multiple remotes.  If you want to be absolutely certain that one child can only use one loco, only have that loco in a remote.

The only problem with the Emergency stop is it really stops, you have to reset everything to get running again.

GRJ, that's true, but it beats a head-on collision between a pair of $500 (or more) locos, especially if the shock sends one over the "cliff" & onto the concrete.  I never chided the GCs for hitting the stop button when they thought a problem was developing.  Second-guessing should only be done by the GAO.

RJR posted:

Keith, I'm somewhat dense, and don't understand the reason for all this.  My 6 grandchildren were all able to quickly comprehend how to use the speed (thumbwheel) and whistle and direction controls on the remote (in that order), and then the emergency stop button, on the remote.  This when they were about 2-3.  You could use multiple remotes.  If you want to be absolutely certain that one child can only use one loco, only have that loco in a remote.

This choice wasn't specifically for my grandson, but for my neighbors grandchildren and other visitors. My neighbor purchased the single locomotive for child use. I can't even teach him how to use the TIU remote. In his own words, he's done learning. I'm not always going to be present when the train is running.

In his own words, he's done learning.

Nuff said.

John,

This and a whole lot more is all in “The DCS Companion 3rd Edition!" This book is available from many fine OGR advertisers and forum sponsors, or as an eBook or a printed book at OGR’s web store!

Let's split some more hairs here Barry, you obviously knew what I was talking about, but don't ever miss an opportunity to contradict.

John,

you obviously knew what I was talking about, but don't ever miss an opportunity to contradict

I wan't contradicting you at all, rather, I was correcting your erroneous statement.

Of course I knew what you meant. However, my concern was that perhaps someone, less DCS-knowledgeable than am I, might mistake your incorrect statement as gospel, and actually reset a remote after experiencing an E-STOP event. Since doing so would delete the entire contents of their remote, I believed that a correction was in order.

Wouldn't you agree that preventing that possible occurrence is more important than protecting your bruised ego?

So isn't putting a remote commander in the same loop as a TIU channel the same as putting two TIU channels together?  That's a guaranteed signal killer

Matt,

So isn't putting a remote commander in the same loop as a TIU channel the same as putting two TIU channels together?

Good question, however, the answer is "no", it doesn't interfere.

The difference is that when two TIU channels are connected together and a command is issued by a DCS Remote, the same, identical command is simultaneously sent over both TIU channels at the same time, to the same engine, on the same track. This can definitely result in a bit of "confusion" on the part of the receiving engine.

However, when a TIU and the DCS Remote Commander receiver are both connected to the same track, each device  gets and forwards commands from a different device, and forwards them to different engines. It's just like using 2 different DCS Remotes with one TIU channel, rather than using 1 DCS Remote with two connected TIU channels.

So if the TIU is sending addressed data packets to all channels at the same time why would connecting two channels of the TIU together kill the signal.  If the signals are transmitted at the same time, wouldnt that double your signal strength? Or is the duplicate data packets what kills the signal?

Matt, I think statistics are on your side with two truly separate signal sources.  While it's certainly true that the two could step on each other, that would only happen if they sent out command packets at the same time.  Since the amount of time the link is idle far exceeds the time that command packets are being transmitted, you'd normally not see an issue.  I suspect that occasionally, you could see some confusion between the two signal sources.

Matt,

why would connecting two channels of the TIU together kill the signal ... Or is the duplicate data packets what kills the signal?

Nothing "kills" the signal. The signal strength is a computed value based on the percentage of packets, out of 100 sent by the TIU, that the engine receives and acknowledges.

In the case of two TIU channels that are connected to the same track,  it's the engine receiving multiple virtually occurrences of the exact same command nearly simultaneously that has an adverse effect on executing a command.

There's a discussion of how DCS signal strength is calculated during a test in The DCS Companion 3rd Edition on page 58:

DCS Signal Strength 

DCS signal strength is a number, from 1-10, that's calculated based on the number of data packets that the TIU sends and receives back from a DCS engine that's performing a DCS signal strength test. 

During the test, the TIU sends a continuous series of data packets to the DCS engine. The DCS engine is expected to reply to every packet that it receives, however, some packets are either not received by the engine or the response is not received by the TIU. Regardless, the TIU calculates DCS signal strength by counting how many response packets the TIU receives from the DCS engine out of each hundred data packets the TIU sent, and then looks at a sliding scale to determine the signal strength that should be reported. The scale is not linear, rather, it is such that 87-100 packets equates to a DCS signal strength of 10, 80-86 equates to a 9, and so on. 

When using a DCS engine to measure the DCS signal strength on a particular section of track, the engine will report some value from 1 to 10. If DCS signal strength is exceptionally low, an error message may be displayed instead of a value. A value between 8 and 10 is generally described as strong, between 6 and 7 is generally described as adequate and from 1 to 5 is described as low. While many operators strive for a consistent DCS signal strength of 10, it's a proven fact that nearly all DCS commands will operate just fine when DCS signal strength is 7 or higher. 

This and a whole lot more is all in “The DCS Companion 3rd Edition!" This book is available from many fine OGR advertisers and forum sponsors, or as an eBook or a printed book at OGR’s web store!

Can you have a  perfect(tiu) DCS signal with two or more  channels not separated by    insulated center rail joint?

I think you can but it doesn't work very well.

Barry, I am in the process of re-reading your, seems I forgot quite a bit of information. I was just a bit curious as to why connecting 2 channels together would effectively kill the DCS signal. I forget if I had 2 channels from the same TIU connected( by connected I mean there were 2 loops of track that were not isolated form one another) or 2 channels from 2 different TIU's. For me it helps to fully understand the problems to know the solutions.

Gregg, from my experience you cannot. Connecting 2 channels together will effectively kill your DCS signal for, me it brought it down to 1's and 0's and "RF OUT OF RANGE" errors. You would honk the horn and it would stay on for like 45 feet until if got a signal again, and forget about changing speed. I ran my DCS locos with quickset speeds

A more relevant situation to the original topic would be 2 TIU channels connected to same loop - but 2 separate TIUs and 2 remotes with1 TIU channel coming from each TIU.  And, as in the OP's case, one TIU is connected in passive mode.  Additionally, each TIU would have its remote directly connected so that remote commands don't interfere with each other.  Then, start actively banging away on the two remotes.

Now you have the situation where you have 2 DCS talkers that are unaware of the other.  This is what the OP has with a TIU and Remote Commander.  Using 2 channels from a single TIU is not a good proxy for the experiment because the processor inside the single TIU has intimate knowledge and control what's going on with its channels.

As GRJ points out, it comes down to statistics.  The likelihood of conflict increases as demand for the limited resource increases.  So as I stated initially, this might occur if both users are actively and simultaneously banging away on their respective remotes.  In such situations more data packets are being transmitted and the likelihood of a collision/corruption increases.  In addition to busy and frequent button pressing increased DCS packet activity can result from the type of command or what the user is doing.  So if the OP is using the Protocast function, the TIU channel is furiously sending packets to one engine; in such a case every time the grandkid presses a button trying to control the factory-reset engine there's a high likelihood the two DCS transmitters will send overlapping packets that become unintelligible to each engine. The quality of the Protocast sound will degrade.  A more mainstream example might be controlling a quillable whistle which has more DCS packet activity than the occasional horn blast or speed change.  A less mainstream example would be running the signal-strength test on the TIU channel when the Remote Commander is also spraying packets every time the grandkid presses a button.

In fact, if you've followed along to this point, the statistics can come into play in another way.  DCS packet activity on a track increases as signal-strength decreases.  So for the same button press activity, a TIU channel with signal strength of, say, 5 will have more packet activity than one with signal stregnth of 10.  This is because the TIU uses an acknowledge-retry algorithm and will repeat (duplicate) a packet if it does not receive an acknowledgement from the addressed engine.  Most communication networks exhibit similar behavior with channel utilization or occupancy increasing under degraded signal conditions.

Stan,

A more relevant situation to the original topic would be 2 TIU channels connected to same loop - but 2 separate TIUs and 2 remotes with1 TIU channel coming from each TIU.  And, as in the OP's case, one TIU is connected in passive mode.  Additionally, each TIU would have its remote directly connected so that remote commands don't interfere with each other.  Then, start actively banging away on the two remotes.

How is this "more relevant to the original topic"? The OP clearly states:

I added a DCS remote commander in passive mode to my 2 loop layout. 1 TIU channel for each loop. I overlooked the fact that the remote commander is only applying the DCS signal to the loop that it is connected to. I'm thinking of adding a second remote commander for the other loop. I would have both remote commander receivers physically in the same vicinity. Any reason why this wouldn't work?

I switched the locomotive under the remote commander control from the outer loop to the inner loop and lost control

Clearly, the two loops are not connected, or the engine being controlled by the DCS Remote Commander would not have become uncontrollable when it crossed from the Remote Commander's loop to the other one.

Now you have the situation where you have 2 DCS talkers that are unaware of the other.  This is what the OP has with a TIU and Remote Commander.  Using 2 channels from a single TIU is not a good proxy for the experiment because the processor inside the single TIU has intimate knowledge and control what's going on with its channels.

Actually, the processor has no clue what is going on with its channels. It just passes along commands from the remote without the faintest idea what the commands are intended to do. The remote does all of the heavy lifting. the only difference between using two TIUs or using two channels of the same TIU is that the components of each TIU are in a range of acceptable performance.

On a related subject, I recall a conversation some time ago with MTH R&D where I learned why one particular PS2 engine had much better performance on one TIU's tracks than on another. It was the only engine that had this issue. The most likely reason for this behavior, I learned, was that the matchup between the engine and the TIU had the engine's communication capabilities at one end of the acceptable operating range while the two TIUs were each more towards different ends of the spectrum than than was the other.

So as I stated initially, this might occur if both users are actively and simultaneously banging away on their respective remotes.  In such situations more data packets are being transmitted and the likelihood of a collision/corruption increases. 

Far and away, the greatest amount of packet traffic is generated by Super TIU mode, which sends all engine commands to all engines via all TIU channels. Remember, the TIU has no inkling of where a particular engine is at any time, or where it was in the past. Further, it's the remote that keeps track of all associations between engines and TIUs. Again, the TIU is clueless.

Regardless, as a Super TIU operator and as a DCS beta tester for more years than I care to remember, I can assure you that the increased traffic flow of Super TIU mode adds not one iota of discernible latency to DCS commands. If there is, indeed, any latency present, although you might be able to measure it with some instrumentation, it's not at all noticeable and creates absolutely no issues.

the statistics can come into play in another way

One can theorize and hypothesize to one's hearts content and I appreciate your thoughts. However, regarding statistics, I'm reminded of the old saying that there are 3 types of liars: liars, dam*ed liars, and statisticians.  

Barry Broskowitz posted:

Stan,

A more relevant situation to the original topic would be 2 TIU channels connected to same loop - but 2 separate TIUs and 2 remotes with1 TIU channel coming from each TIU.  And, as in the OP's case, one TIU is connected in passive mode.  Additionally, each TIU would have its remote directly connected so that remote commands don't interfere with each other.  Then, start actively banging away on the two remotes.

How is this "more relevant to the original topic"? The OP clearly states:

I added a DCS remote commander in passive mode to my 2 loop layout. 1 TIU channel for each loop. I overlooked the fact that the remote commander is only applying the DCS signal to the loop that it is connected to. I'm thinking of adding a second remote commander for the other loop. I would have both remote commander receivers physically in the same vicinity. Any reason why this wouldn't work?

I switched the locomotive under the remote commander control from the outer loop to the inner loop and lost control

Clearly, the two loops are not connected, or the engine being controlled by the DCS Remote Commander would not have become uncontrollable when it crossed from the Remote Commander's loop to the other one.

It's more relevant to the original topic because Matt asked the new question about whether 2 TIU channels (from the same TIU) would be a proxy for the discussion about how signals and commands interact/interfere on a SINGLE loop.  You're correct that the OP has 2 loops.  But that's not where the discussion has evolved to.  If you re-read the entire discussion we're now talking about how 2 talkers might interfere with each other ON A SINGLE LOOP.  And in particular the SINGLE LOOP where both the TIU and the Remote Commander are actively and simultaneously transmitting packets.  There are no outstanding issues with the OP's 2nd loop where just the Remote Commander is active.  Let's just agree to disagree.

Now you have the situation where you have 2 DCS talkers that are unaware of the other.  This is what the OP has with a TIU and Remote Commander.  Using 2 channels from a single TIU is not a good proxy for the experiment because the processor inside the single TIU has intimate knowledge and control what's going on with its channels.

Actually, the processor has no clue what is going on with its channels. It just passes along commands from the remote without the faintest idea what the commands are intended to do. The remote does all of the heavy lifting. the only difference between using two TIUs or using two channels of the same TIU is that the components of each TIU are in a range of acceptable performance.

Bold added to your text.  I disagree.  The processor has very intimate knowledge of what's going on with its channels and knows exactly to the microsecond when the electrical signal is being transmitted to the track.  After all it is executing instructions to send the bits to the transmitter hardware.  Whether or not it knows the meaning of the packets is IRRELEVANT; the issue at hand is whether the electrical signals on the track from two simultaneous overlapping packets can interfere with each other rendering both un-intelligible to the receiving engines.  Let's just agree to disagree.

On a related subject, I recall a conversation some time ago with MTH R&D where I learned why one particular PS2 engine had much better performance on one TIU's tracks than on another. It was the only engine that had this issue. The most likely reason for this behavior, I learned, was that the matchup between the engine and the TIU had the engine's communication capabilities at one end of the acceptable operating range while the two TIUs were each more towards different ends of the spectrum than than was the other.

So as I stated initially, this might occur if both users are actively and simultaneously banging away on their respective remotes.  In such situations more data packets are being transmitted and the likelihood of a collision/corruption increases. 

Far and away, the greatest amount of packet traffic is generated by Super TIU mode, which sends all engine commands to all engines via all TIU channels. Remember, the TIU has no inkling of where a particular engine is at any time, or where it was in the past. Further, it's the remote that keeps track of all associations between engines and TIUs. Again, the TIU is clueless.

As a general statement that may be true.  But it's IRRELEVANT to the matter at hand.  The OP is not using Super TIU mode.  We are talking about situations where packet traffic is heavier on a SINGLE LOOP and specifically in the albeit unusual situation where 2 potential talkers are trying to share that channel.   Also, if you're making a general statement about what generates the greatest packet traffic on a single DCS channel, I think it's a toss-up between downloading a new soundset into an engine, operating in Protocast mode to send your voice or music over the rails to and engine, or running the signal-strength test function.  If the system lets you perform any of these in Super-TIU mode would theoretically increase packet traffic on a single channel but again I suggest it's irrelevant to the matter at hand.  Let's just agree to disagree.

Regardless, as a Super TIU operator and as a DCS beta tester for more years than I care to remember, I can assure you that the increased traffic flow of Super TIU mode adds not one iota of discernible latency to DCS commands. If there is, indeed, any latency present, although you might be able to measure it with some instrumentation, it's not at all noticeable and creates absolutely no issues.

Again you're introducing a new twist that's irrelevant to the discussion and answering a question that has not been asked.  No one is asking if Super TIU mode adds latency.  The relevant question would be if someone banging on a Remote Commander that shares a loop of track in Super-TIU mode would add latency or degraded responsiveness.  I believe it would for reasons discussed previously and for which we've already agreed to disagree on.  So, again,  let's just agree to disagree.

the statistics can come into play in another way

One can theorize and hypothesize to one's hearts content and I appreciate your thoughts. However, regarding statistics, I'm reminded of the old saying that there are 3 types of liars: liars, dam*ed liars, and statisticians.  

To this, I agree.

Stan,

I continue to maintain that my response to the OP was exactly correct. You may continue to hypothesize whatever additional scenarios you like, however, you'll do so without my input.

When you have anything resembling proof  that you can demonstrate, in some legitimate DCS operating scenarios, that you can introduce noticeable latency, slow downs or some other degradation of DCS commands in contradiction of my statements, I'll be happy to join back into the discussion.

Have fun!

Barry Broskowitz posted:

Stan,

I continue to maintain that my response to the OP was exactly correct. You may continue to hypothesize whatever additional scenarios you like, however, you'll do so without my input.

When you have anything resembling proof  that you can demonstrate, in some legitimate DCS operating scenarios, that you can introduce noticeable latency, slow downs or some other degradation of DCS commands in contradiction of my statements, I'll be happy to join back into the discussion.

Have fun!

I don't know if "youtube" is proof but here's a demonstration.  The DCS operating scenario is what OP says he's using - agreed it's a very unusual scenario but it's the configuration under discussion so I'd call it legitimate.

Remote Commander attached in passive mode to a TIU track.  Engine is under command control.  Video shows a couple horn blasts, then Protocast mode is turned on streaming music (a lot of DCS packets) over the rails to the engine.  Start pressing the Remote Commander buttons to spray DCS command packets over the rails at the same time as the streaming Protocast packets.  The Remote Commander packets are addressed to the "factory-reset" address so a different address than the engine.

Protocast is not exactly hi-fidelity but I believe it's quite obvious that there is "degradation of DCS commands."  Watch the LED on the Remote Commander base/receiver.  When the LED is "off" it's presumably sending DCS packets to the track which I claim are garbling/corrupting the Protocast DCS packets going to the engine as evidenced by hiccups/degradation of the audio.

I offer a gold-star to anyone who "gets" the selection of music. 

Stan,

The DCS operating scenario is what OP says he's using - agreed it's a very unusual scenario but it's the configuration under discussion so I'd call it legitimate.

First, the OP wasn't using ProtoCast orProtoDispatch, and wasn't contemplating either one..

Second, in the video, was the ProtoCast port or the ProtoDispatch port being used? There's a known, long-standing issue in DCS that disables all DCS commands when the ProtoDispatch port is used.

Third, if the ProtoCast port was being used, there's possibly something else going on. ProtoCast typically sounds a lot better than that video sounds. I'd be a bit suspect of the DCS environment, unless you could personally vouch for it or were actively involved in the experiment.

I typically don't accept YouTube videos at "face value".

Stan, I'd give it up.  Barry will never admit the possibility that you're right.

Barry Broskowitz posted:

...

Further, data packets simply don't"corrupt" each other. The only confusion can come from an engine receiving multiple occurrences of the same data packet of address and command, which is not the case in the OP's described scenario. Further, differential signaling is implemented to mitigate that exact scenario, if it was the case, which it is not.

Regardless, let's just agree to disagree.

Barry, I don't think the OP is using Protocast at all.  I think he's good to go.  The topic has evolved to a discussion about an unusual scenario where two DCS devices talk at the same time on a single DCS channel/loop/track.  For all I know he's the ONLY person in the world where a Remote Commander is actively sending command packets onto a TIU channel.  The guys using a Remote Commander to trigger a once-per-powerup watchdog on a TIU track siding is not the same since presumably they are not using the remote to actually have the Remote Commander send DCS packets onto the track.

You believe data packets don't "corrupt" each other.  I believe they can. 

You believe "differential signaling" mitigates this scenario.  I believe "differential signaling" (as defined by Wikipedia and elsewhere) has nothing to do with mitigating simultaneous/overlapping data signals.

Anyway we have already agreed to disagree. 

gunrunnerjohn posted:

Stan, I'd give it up.  Barry will never admit the possibility that you're right.

Now that's something I can agree to agree!

Stan,

For all I know he's the ONLY person in the world where a Remote Commander is actively sending command packets onto a TIU channel

I'd still be interested in knowing if it was the ProtoCast port or the ProtoDispatch port being used in the video. As I said, there's a known, long-standing issue in DCS that disables all DCS commands when the ProtoDispatch port is active.

In my earlier days with DCS, I was able to use multiple remotes simultaneously, on the same TIU channel, while streaming music via the ProtoCast port with no issues at all. However, when using the same scenario with ProtoDispatch, the issue n the video would surface,

Regardless, I admit that I haven't tried repeating this experiment recently.