To be fair, large layouts can be a nightmare with DCS, and there is no "BUFFER" that can be applied to fix it. @Adrian! did a fair amount of research on a buffering scheme for DCS, but a workable solution is yet to be found.
John is right. Here's the insight into why this is so:
Legacy is one way (base to train) signaling, so "buffering" is easy. The triangle (amplifier) points away from the base and towards the train.
The first issue is DCS is two way (train to TIU and TIU to train) signaling... so buffering is complicated since ... which way would the triangle point? If it just points one way it's not helpful since it will isolate in the other direction and you'll have no reverse signaling... and if you put two pointing both ways.... well then its just a loop of two triangles and now you have an oscillator. To do this successfully, you would need to "know" when a packet is about to go in one direction or another and switch in or out your triangle directions accordingly, which means the switching thing you build needs other logic signals from deep within the TIU (tapping the logic upstream of the output drivers)... to give your switch enough time to get the amplifier setup. Not easy with a big layout that has 20 or even more different TIU channels. You would need to tap all that logic on all the TIU channels in the layout to see when one of them somewhere is about to transmit a sequence.
The second part is the DCS packet timing: While we do know the sequence is always TIU-to-train before Train-to-TIU the TIU-to-train part is variable length (different commands --> different times) so it's not as simple as having an RC timer or something switch the triangle direction after a certain time constant so the amplifier points one way then the other. Unlike the TIU (who's firmware knows what command it is sending and what packet length it will be, and what response length to expect), you the outsider would need to extract this information from the outgoing packet to get these details for setting direction, and you would need to do it very very quickly since the packet you're decoding is also the packet you're steering the switch for. That also means you're going to need some kind of fast look-up of the outgoing commands, too much for a microcontroller, it'd have to be an FPGA with a respectable clock... so now you're getting into the $1000 range.
The third issue is that we're talking about trains which move: Like mentioned above it's TIU-to-train, and train-to-TIU signaling. Understanding where to place the TIU-to-train amplifier is simple... you'd put it at the TIU before the connection to the layout... but how would you place the amplifier for the train-to-TIU signal? If you place it at the TIU, well the signals already gone through the layout at that point and all the ringing, distortion, and noise is already in there so an amplifier won't help much at that point. You'd need to place it inside the train (at the point where the transmission originates and is "clean")... Put modules in each locomotive one by one... with an FPGA inside tapped into the PS2/3 board to get timing.
The more you think about it ... the less sense it makes... and that's why we don't have such a booster.
I've worked with people on a lot of layouts with signal issues using both systems, and I can say with certainty that I've had more and more complex issues with MTH DCS than I've ever had with TMCC/Legacy. Virtually all the issues with TMCC/Legacy signals can be addressed successfully, there are many people that have dinked around with DCS for years and never gotten it working well.
