MTH Engines Missing the Watchdog Signal...Why?

It could be just engine placement. If you have too many engines in one block getting power all at once that is.

I have not seen this when I upgraded to 6.1. I believe the release is pretty stable with less issues.

Have you run signal strength test in these areas where the engines are at start-up? How's the voltage in these areas? If the power dips then I would guess the signal would suffer as well. Why it showed up now? I'd be looking for any other change like new equipment.

What Joe said, also 

Try a different TIU channel ?  Clean wheels and track ?  

Too many engine in same block may be culprit...need to cut power to few and see what gives...thanks!

Greetings All,

 I have experienced similar issues using a Lionel Power House 180.  My layout is divided into 3 separate loops, one of which is powered with a PW180, while the other two loops are controlled by a Z4000 with one handle for each loop.  Every so often, (but not always) when I power up the PW180 and there is a MTH engine on that track it will miss the watch dog signal and begin the start-up process by itself.  When this happens, I press the shut -down button on the remote for that particular engine, wait for it to totally shut-down then press start-up on the remote and we are good to go.  It was explained to me why this happens but I just can’t seem to find that information.  I normally only have one engine on the PW180 loop so I can’t help with multiple engines.

 Chief Bob (Retired)

All I run on my 2 rail loops are PH180s! 4 of them. No false start problems.

Before I cut power to my engine yard, engines would fire up all over the place. Now that yard is off. I only power what engines I'm running.

I have been experiencing similar issues recently.  My symptomology is a bit different than above, and detailed below.  It nonetheless most aggravating, especially after 4+ years of operation with hardly more than an occasional lash-up glitch.

==========================================================================================================================

Motors A, B and C are PS3 units, which have operated together flawlessly for a few years now.  I only have one power block (no need for more) and have never had any issue with adding them to either remote I have, or powering them up close together or or far apart; nigh perfect operation.

Motors D and E are recent acquisitions.  They are PS2 units that are brand new; they had not been run prior to my acquisition.  Being a PS3 operator, I foolishly added both of these units in succession to the DCS remote, without inspecting the batteries first.  They added fine, but, predictably, the remote couldn't find them after a power recycle.  Then the PS3 motors A and C also began acting up; starting up on their own upon power application, which apparently means that the unit in question missed the watchdog signal.  After going back and forth between adding and re-adding units to the remote, it finally occurred to me that the PS2 units' batteries might be an issue, having sat so long on the shelf.  I simply pulled PS2 motors D and E from the layout.

However, motors A and C continue to exhibit issues being added to the remote and operating together.  I can add motor A to the remote, then remove it from the layout and add motor B to the remote.  They work fine by themselves and always show 9-10 signal strength from the TIU.  However, when they are on the layout together, one or both of them always fire up automatically upon application of power.  The few times they don't, one of the two motors (A or C) are not seen at all by DCS (ENGINE NOT ON TRACK error), though it is obviously getting power, having just worked by itself moments before.  In that case, the unit that works is often partially lost by the remote, IE, I hit buttons and the motors don't always respond immediately.  The same buttons need to be pressed a few times before the motor will acknowledge, though no error shows on the remote.  Occasionally, I lose control of the working unit entirely, though no error is shown on the remote.  The TIU signal strength is still reads 9-10 on whichever motor is working, at all times.  Oddly enough, through all of this buffoonery, motor B has been unaffected, and exhibits no issue.  It adds and fires up by the remote with no issue; TIU signal strength shows 9-10.  If motors A or C are powered up with motor B, the former often start up on their own again, while the latter has no issue.

I went through and methodically reset both remotes and did a factory reset on motors A and C; all of the odd behaviors remain.  At this point, I am unsure what to do next.  Is it possible for a PS2 unit with a dead battery to screw up PS3 units?  Or is it possible that PS2 units with dead batteries can mess with a TIU?  I did not do any reset on the TIU at this point.  I saw no need given the good signal strength and perfect operation of motor B.

In summary, I run DCS 6.00, and have had no issue for a long time.  The addition of the PS2 units with apparently dead batteries was the genesis of all of the issues outlined above, and persist on the PS3 motors even after removing the PS2 motors from the layout.  Does anyone have any insights as to what might have happened, why, and how to fix it?  I might try a TIU reset in the meantime, but that is all I know yet to do.  Thank you in advance.

===========================================================================================================================

I should qualify some of my statements above; I do have other troubleshooting steps to try.  I can reset the TIU, change TIU fixed power channels, or even change TIUs.  My spare Revision H is old, but it runs DCS 6.00 and would be a good test.  Finally, I have a spare PS3 board I can switch out and experiment with as well.  I just figured I'd ask here before undertaking those more time-consuming troubleshooting steps.

Nothing else done to layout between all ABC unit always working fine and addition of the PS-2 units?  Why are you constantly re-adding ABC if already in the remote?

There can be cases where PS-3 units interfere with DCS signal and each other.  If diesel, making sure caps are down horizontal and all wiring is above and away from the Toroid signal transformer near 8 pin connector.  Wheels and pickups clean.  Track clean.  Since they worked fine before, not sure wiring would be issue, but worth a look.  Degradation of wheels and pickups, and track can certainly push you closer to poor DCS strength.

Otherwise I can not explain why the change on two units.  I would think the addition of the PS-2 is coincidental, especially since removing them from the layout has not resolved issues.  G

Hi G:

Thanks for getting back to me.  I should clarify that I wasn't adding/removing motors A and C constantly per se, or with no purpose.  After I added the PS2 units, that is when A and C began starting up on their own and not consistently responding to their respective entries in the remote.  That is when I deleted them out of the remote and re-entered them, with no success.  Thinking the remote might be confused, I reset it and then re-added all 5 units, with the same odd behavior from A and C, and the PS2 units not responding after a power recycle.  After removing the PS2 units, the premature starts of motors A and C persisted, so I went through the same troubleshooting procedure as before, to no avail.

I researched dozens of posts about similar symptoms prior to my posts, and have seen your other suggestions previously.  I will look into all of them, though I am less than hopeful given the perfect operation of A, B, and C prior to the addition of the PS2 units and the oddities I have seen since.  I also agree completely with your last comment.  However, there indeed was no operational issue of any kind prior to the PS2 unit additions; it's mystifying.

I will begin working though the more involved troubleshooting steps I outlined in my last post.  That is all but guaranteed to at least isolate the offending component, so I at least have something to go off of.  I will post the results as I have time.  Thanks again for your help.

I have not arrived at any solutions, and troubleshooting has been an ongoing exercise in frustration.  However, I think I have isolated the issues and have 1 last known step to try.

To start, everything was fine with my three PS3 motors, and has been since I started with DCS in mid-2015.  When I recently added two PS2 motors without checking the batteries, all this craziness broke out.  Since then, two of the PS3 motors will add to a remote and run individually in DCS.  However, if you try to run them together with 1 or more of the other motors, they always start up on their own, I.E conventional mode in neutral.  On rare occasions one of the the problem units will stay dark, allow addition to the remote and start up, but operation is very intermittent, I.E. sometimes it responds to the remote, more often it does not.  The other problem unit always come up in conventional mode when on the track with other units.  By itself it will add to the remote and run in DCS.  I have troubleshot all of this as follows:

1.  Factory-resetting all problem units, then adding to the original remote,

2.  Resetting the remote and re-adding the factory-reset units,

3.  Resetting the TIU using the reset remote and adding the factory-reset units,

4.  Using a different known-good remote with the reset TIU and adding the factory-reset units,

5.  Using a different known-good TIU with the original reset remote and adding the factory-reset units,

6.  Using the different known-good remote and different known-good TIU and adding the factory-reset units.

(NOTE:  In all cases, the TIU signal strength was 9 or 10 as read from the problem units or good ones.)

In all cases, the problem units will add/run in DCS by themselves, but will almost always start up on their own, (conventional mode in neutral), or be unresponsive the few times they can come up in DCS.  I also tried running the problem units in conventional mode with an MRC transformer (with no DCS components in-line), and they both worked fine in conventional mode, which suggests the boards are OK.

The last thing I know to try is a conventional reset with a transformer.  Unfortunately, I do not have a transformer with bell/whistle buttons, so I got a Lionel 40W from eBay for $25.  I won't be able to try the conventional reset until next week.

Is there anything I missed or forgot to try?  Thanks.

Have you taken the locomotives to another DCS layout to see if they experience issues there.  Given it's multiple units, my guess is something has changed on the layout.

Hi John:

The last testing with the second TIU was done on a separate test track, a simple straight section, totally separate from the main layout.  In any case, there hasn't been any change on the layout for a long time.  The only change has been to add those two PS2 units.  Even if both of them were having a problem (they were unused before I got them), I wouldn't see why it would screw up the two PS3 units once the PS2 units were removed.  I do have a spare PS3 freight board I can swap out to prove it either way, but I was rather hoping to not come to that point.  I am reasonably experienced with DCS, but even with all the research, this one has been mystifying to say the least.

I think it's time for some organized debugging.  Personally, I'd start by actually measuring the DCS signal from the TIU's.  I have already had to repair a couple of my TIU's (all Rev. L), because a channel gets a weak DCS signal.  I have one that still needs repair on my bench, I'm just using FIXED #2 until I get around to fixing that one.

Did you ever look at this thread: Design of a $10-20 DCS-TIU Port Tester Tool?  This is a handy little tool to have around, and pretty cheap as well.  A few of us collaborated on the design and build, and I believe Tom is still offering a kit of parts to make one.  It's a really useful quick go/no-go tester for the DCS signal on each channel.  My contribution was a tweak or two to the design and doing the board layout.

Yes, he is still offering the kits!  I have about 15 or so TIU Tester kits left from the current batch. 

Anyone wanting a kit can contact me at the email address in my profile. 

Hi John:

While I would be more than willing to give the tester a shot, I rather question the purpose at this point.  Prior to the addition of the two PS2 units, there was no issue with any of the PS3 units at any time.  Additionally, the issue has persisted through 2 full sets of DCS equipment.  I do not really think that DCS itself is the issue.  However, please don't think I am discounting your suggestions; I am not, and I will give that thread a close look.  In any case, a DCS tester would be handy to have around.

One other 'easy' step I thought of tonight is to pop the shells and re-check the wiring.  That is one item that George suggested that I have not yet done, and it occurred to me that I have had the shell off both problem units recently to grease the worm gears.  I will let you know what i find out.

Thanks again all for weighing in; I appreciate it.

John:

After going back at it tonight, and made an interesting discovery.  I thought for sure I checked this before, but apparently not.

I checked the signal strength on the PS2 units by themselves, 3-5, with a very occasional 8 on both.  I checked the signal strength of them on the system together, now 1-4, with a very occasional 5.

(EDIT:  a number of 'Out of RF Range' errors make into the signal test.  That would explain the intermittent remote command acknowledgement.)

However, the signal strength is always 9 or 10 with the all working PS3 units, from anywhere on the layout.  All signal measurements are right at the catenary/track feed point.  I did not check the second TIU, but since the behavior is the same, I would imagine this symptom is the same, but I have yet to test that.  This is a big enough development as it is.

I will do more research in the meantime, but any ideas?  The one PS2 has a new 8.4v battery, the other has a 2.5v that holds a good charge.  Thanks.

GGG posted:

Nothing else done to layout between all ABC unit always working fine and addition of the PS-2 units?  Why are you constantly re-adding ABC if already in the remote?

There can be cases where PS-3 units interfere with DCS signal and each other.  If diesel, making sure caps are down horizontal and all wiring is above and away from the Toroid signal transformer near 8 pin connector.  Wheels and pickups clean.  Track clean.  Since they worked fine before, not sure wiring would be issue, but worth a look.  Degradation of wheels and pickups, and track can certainly push you closer to poor DCS strength.

Otherwise I can not explain why the change on two units.  I would think the addition of the PS-2 is coincidental, especially since removing them from the layout has not resolved issues.  G

https://ogrforum.ogaugerr.com/...ce-needed-with-photo

To elaborate from above...also my current environment is 6.1 with 4 mu's  with 4 addresses.2 mu's 6 eng each,1 mu 5 engine and 1mu 4 eng. Very stable..all mu's maintain there individual settings. Hope this helps.

Nate, have you added any lighted rolling stock to the layout? If so try removing them and see if things get better. I have a few parking spurs on my layout that end with a lighted bumper. If I run a passenger train with lighted cars into the spur (that the engine is at the bumper) the next time I power up the layout, the watchdog signal gets absorbed by the passenger cars and never makes it to the engine. If I back into the spur, that the tail end of the train is at the bumper, the engine will receive the watchdog signal with no problem. My solution is to eventually add chokes to the lighted cars or add GRJ's LED kits to them, because when I pull a passenger train into the spur that has GRJ's light kits installed, I have no problem. I also have a block on the main line that experiences signal collision, where if I use a soft key in that block for a whistle command, it will play the soft key sound twice. When I shut down the layout, and an engine is left in that block, it will miss the watchdog signal. I have to work on that block and find the issue. Do you ever experience any signal collision on your layout where the watchdog may be getting messed up?

I think my previous comments still apply.  Start by eliminating suspects until only one is left. 

FWIW, just because you get high numbers in the track signal test, that does not mean the TIU is not suspect.  The signal test numbers are just the percentage of commands make it through to and from the locomotive.  However, it has been demonstrated that the actual DCS signal can be seriously degraded and still get high numbers at times, depending on the mix on the tracks and the location of the tested locomotive.

The reason I recommend testing the TIU signal is once you verify it's good, that's one less thing you have to consider in your troubleshooting.  Debugging is simply eliminating possibilities until only one remains.

Hi John and all:

I figured out what was going on, and every issue is resolved.  All units (PS2 and PS3) are running on DCS with no issue, and 9-10 signal strength.  Regretfully, I am up to my ears moving furniture today, so I will post the details later; it's a bit of a yarn.  As George told me earlier this week, 'no easy fix'.  Man, was he right.

Thanks all for your input, especially you, John.  I appreciate it.

I am waiting for this one G

I'm kinda' interested in what the issue really was as well.   I wonder how much "later" it'll be before we get the details?

Good morning all:

Sorry for the delay.  I have another busy day on tap (ugh), which includes the impending arrival of in-laws.   Rest assured, I will not forget to fill you guys in.  As someone mentioned in another thread, I hate it when someone has an issue, and either never posts an outcome, or promises to and never gets to it.  That won't be the case here.  Thanks.

I don't think he wants to tell us or he could have explained it  last week, instead of telling us why he can't.

Joe:

At risk of sounding a bit terse, my wife's back is out and she is slowly getting over pneumonia.  My son has severe physical and mental needs, and I just had to fire his night nurse for gross negligence last week.  That now means that 5 days out of the week I stay up most of the night taking care of him and then trying to work full time during the day and help my wife run her business.  Forgive me if trains haven't exactly been the first thing on my mind in the last week or two; a lot of this started right after I finally fixed the issues on the layout.  I have made notes on everything that happened and I will share my findings just as soon as I am able, as I think it will help someone else troubleshoot their issues.  Thanks for your patience.

--NMM

Good afternoon all:

Again, please forgive this late reply.  This debacle turned out to be a confluence of multiple primary and secondary causes, which made it challenging to troubleshoot and isolate what was going on.  I went into a bit more detail below in the hope that it can help someone else troubleshoot their own issues.

1.  FINAL OVERVIEW OF SYMPTOMS

When I last posted, there wasn't really much on the system that was working correctly. Since I powered up the system in late 2016, I have scarcely seen any electrical or control glitches of any kind, much less this level of malfunction and abysmal signal strength.  (NOTE:  I am only using signal strength as a consistent performance metric, not a direct indicator of proper TIU function, as John mentioned above). 

Of the five motors on the system (three PS3 and two PS2):

• Only one PS3 motor consistently came up in DCS mode (I.E., quiet on power-up) and responded properly to commands from the remote.  Even so, its DCS signal strength was only 6-8 right at the feed-point.  Typically, signal strength measured from any motor, anywhere on the system was a solid 10, with a very occasional 9.
• The second PS3 unit also came up in DCS most of time, with a 2-4 signal strength if it was powered up by itself, with no other motors on the system.  However, the more motors were on the system, the weaker the signal became (1-2 with frequent 'Out of RF Range' dropouts) and naturally the less it responded to the remote.  Upon power recycling, the motor would often come up in conventional mode / neutral.
• The third PS3 motor almost always came up in conventional mode / neutral.  On the rare occasion that I could add it to DCS (if it was the only motor on the system), signal strength was 1-2, with frequent 'RF' dropouts.  Add even one motor to the system, and it would come up in conventional mode / neutral every time.
• The two PS2 units would come up in DCS about half the time, but the signal strength was 1-4 with frequent 'RF' dropouts.  Upon power recycling, the PS2 motors often came up in conventional mode / neutral.
• (NOTE:  Symptoms were always the same with both remotes I have.  As such, I used the primary remote for all subsequent tests).

As can be seen, not much was working right, and even the symptoms were not always consistent.  It was very frustrating to say the least.

2.  FIRST PRIMARY CAUSE:  EMI

Proper troubleshooting always starts with 'what changed since it worked'.  John eluded to this as well, and I had already racked my brain for what had changed before I ever posted anything.  I never came up with anything; there were no changes on the layout, as I had done little in recent months due to issues elsewhere.  The 'ah-ha' moment came when I considered not what changed on the layout, but around it.

A quick look at the post of my layout construction (linked above) will reveal that my loft area isn't exactly huge, and it takes some critical thought to make the best use of the available cubic footage.  This is a bit of a 'living' process, as I occasionally change desks or benches to expand my available workspace, and the other loft furniture gets slightly re-arranged to accommodate the change.  About a month or so ago, that is exactly what happened.  I acquired a long desk that barely fit into the loft, and made for some great bench space.  So, I installed the desk in the corner of the room, and moved my computer desk and all of its electronic goodies closer to the opening of the loft area...right in front of the TIU and control circuitry.  I immediately wondered if the computer desk was interfering with the TIU RF connection to the remote.  It would certainly make sense, as there is a lot of electronic equipment on/in my computer desk, (Precision workstation, dual 24" screens, network switch, NAS, laser printer wireless keyboard/mouse, etc).  The more I thought about it, the more convinced I was that this was a big part of my problem.  Testing was easy, as I have an older Revision H TIU that runs DCS 6, which was used as a DCS test bed on the bench.  It is powered by the fixed AC output of an MRC controller (18VAC, 40VA).  This way, I have a second DCS instance whose TIU/power supply is completely distinct and separate from the primary TIU / power supply.

Test #1 Procedure:  Connect the secondary TIU (Revision H) and its MRC power supply to the layout as far away from the computer desk and primary TIU/power supply as possible.  Reset the primary remote and add motors, testing signal strength and remote response behavior between each motor added.  The primary TIU and power supply are completely disconnected and isolated from the system.

Test #1 Results

• The same PS3 motor that had worked previously still worked the same, only now it showed a signal strength of a solid 10.
• The second PS3 motor that had sporadic DCS performance came up more often in DCS, with a signal strength of 4-6.  Occasional RF dropouts were observed, but less than had been previously.  Power cycling into conventional mode/neutral was noticeably less frequent.
• The third PS3 motor that had almost always came up in conventional mode / neutral continued to do so frequently, roughly 3 or 4 out of 5 tries.  Previously it would come up in DCS 'maybe' 1 or 2 tries out of 20.
• The two PS2 motors always came up in DCS, always responded to the remote, and showed a signal strength of a solid 10.  I ran them both for almost an hour, with no issue or deviation from from a '10' signal strength, (occasional '9's).

Test #1 Conclusions

This test proved that the secondary TIU and power supply can put out an apparently good and readable signal.  It did not eradicate all problems for all motors, but it did so for three out of the five, and the last two showed some noticeable improvement.  This in turn proved that the two PS2 motors are in good shape, holding a good battery charge and functioning as designed.  Most importantly, the test proved conclusively that either the primary TIU was bad, or there was some kind of EMI in play due to the proximity of the primary TIU to my computer desk electronics.

Test #2 Procedure:  Place the secondary TIU (Revision H) and its MRC power supply (both proven to function properly per Test #1 above) in the same location as the primary TIU / power supply.  Connect secondary TIU (Revision H) to the primary feed-point of the layout.  Reset the primary remote and add motors, testing signal strength and remote response behavior between each motor added.  The primary TIU and power supply are still completely disconnected and isolated from the system.

Test #2 Results

• The same PS3 motor that had worked previously still worked the same, but again showed a lower signal strength of 6-8.
• The second PS3 unit again came up in DCS most of time, with a 2-4 signal strength if it was powered up by itself, with no other motors on the system.  However, the more motors were on the system, the weaker the signal became (1-2 with frequent 'Out of RF Range' dropouts) and naturally the less it responded to the remote.  Upon power recycling, the motor would often come up in conventional mode / neutral.
• The third PS3 motor again came up in conventional mode / neutral most every time.  During the rare time it came up in DCS (if it was the only motor on the system), signal strength was 2-3, with frequent 'RF' dropouts.  Add even one motor to the system, and it would come up in conventional mode / neutral every time.
• The two PS2 motors again came up in DCS sporadically, with the signal strength again 1-4 with frequent 'RF' dropouts.  Upon power recycling, the PS2 motors again often came up in conventional mode/neutral.

Test #2 Conclusions

This test proved that some kind of EMI from my computer desk was interfering with the TIU signal.  Forget the primary DCS system for now, I had proven that the secondary DCS system worked fine previously from another location, and now when placed in the same spot as the primary TIU, exhibited the same symptoms as the primary TIU was.  Now, I needed to get the computer desk back where it had been previously, away from the TIU mount area.

Test #3 Procedure:  After moving the computer desk back where it had been and restoring the loft to its original configuration, run Test #2 as outlined above.

Test #3 Results

• The same PS3 motor that had worked previously still worked the same, and now showed a signal strength of 7-9.
• The second PS3 unit again came up in DCS most of time, with a 6-8 signal strength if it was powered up by itself, with no other motors on the system.  However, the more motors were on the system, the weaker the signal became (3-5 with occasional 'Out of RF Range' dropouts) and naturally the less it responded to the remote.  Upon power recycling, the motor would sometimes come up in conventional mode / neutral.
• The third PS3 motor again came up in conventional mode / neutral more often than not, but I could add to DCS more than it had been.  When I could add it to DCS (if it was the only motor on the system), signal strength was 4-5, with semi-frequent 'RF' dropouts.  Add even one motor to the system, and it would come up in conventional mode / neutral almost every time.
• The two PS2 motors usually came up in DCS, with the signal strength 4-6 with occasional 'RF' dropouts.  Upon power recycling, the PS2 motors would sometimes come up in conventional mode/neutral.

Test #3 Conclusions

This result was a bit unexpected, as it proved that while the computer EMI was definitely an issue, it was not the only issue.  Motors still acted a little odd at times, and signal strengths varied where there should be little or no variation of signal.  Something else was going on, and it would take another pondering brain wave to figure out what it was.

3.  SECOND PRIMARY CAUSE:  ATLAS AEM7 LOCOMATIC BOX

After staring at the control area for quite a while, the second 'ah-ha' moment came to me.

I run a 'true' electric railroad, where all motors run off catenary instead of third-rail.  While MTH motors dominate the system, I also run a few Atlas O AEM7s.  They are extremely well-detailed, and are very strong pullers.  Unfortunately, they cannot be command-controlled, but employ a 'glorified-conventional' control scheme known as 'Locomatic', designed by Dallee electronics.  It consists of an independently-powered control box that is wired between the transformer (or whatever layout power supply) and the track feed-point.  It then spits out digital commands for bell, horn, lights and various sounds as you push the buttons on the control box.  While it works fine with conventional transformers, it is also designed to be cut in line with DCS and Lionel TMCC command control systems with no interference.  I have one such box in line between my TIU output and the catenary to control my Atlas O AEM7s.  It has been there for 3 years and worked fine.  I ran MTH DCS motors along side Atlas AEM7s and never had an issue with it.  Now I began to wonder if that Locomatic box had either failed, or it was interfering with the DCS signal.  That would be the next test.

Test #4 Procedure:  Remove the Locomatic box from the primary layout feed-point.  Then run Test #3 again from above.

Test #4 Results

• The same PS3 motor that had worked previously still worked the same, only now it showed a signal strength of a solid 10.
• The second PS3 motor that had sporadic DCS performance now always came up in DCS, with a signal strength of 6-8.  Occasional RF dropouts were still observed.  Power cycling into conventional mode/neutral was rare, perhaps 1 time out of 15.
• The third PS3 motor that had almost always came up in conventional mode / neutral continued to do so frequently, but now maybe 50% of the time.
• The two PS2 motors always came up in DCS, always responded to the remote, and showed a signal strength of a solid 10.  I ran them both for almost an hour, with no issue or deviation from from a '10' signal strength, (occasional '9's).

Test #4 Conclusions

This test proved that the Locomatic box was another major problem, as DCS performance improvement was realized in all five motors again, but to a higher degree than previous tests.  The final major test was to use the primary TIU and power supply as it had been originally wired, only away from  my computer desk and minus the Locomatic box.

Test #5 Procedure:  Run Test #4, using the primary TIU and power supply instead of the secondary TIU and power supply.  

Test #5 Results

• The same PS3 motor that had worked previously still worked the same, only now it showed a signal strength of a solid '10'.
• The two PS2 motors always came up in DCS, always responded to the remote, and showed a signal strength of a solid '10'.  I ran them both for almost an hour, with no issue or deviation from from a '10' signal strength, (occasional '9's).
• The second PS3 motor that had sporadic DCS performance now always came up in DCS, with a signal strength of 6-8.  Occasional RF dropouts were still observed.  Power cycling into conventional mode/neutral was rare, perhaps 1 time out of 15.
• The third PS3 motor that had almost always came up in conventional mode / neutral only continued to do so frequently, but now maybe 50% of the time.

Test #5 Conclusions

This result was the same as that for Test #4.  Now using the primary TIU and power supply, I had replicated proper DCS function in 3 of 5 motors, with the same noticeable improvement in DCS performance with the other two as I had seen with the secondary TIU and power supply.  This proved that the primary TIU and power supply, plus the wiring chain from them to the catenary and track were fine, assuming the Locomatic box was removed and the computer desk was moved away.

4.  SECONDARY CAUSES:  PANTOGRAPHS AND WIRE-WRAP

There remained the issues with the two PS3 motors.  Seeing the improvements with the primary TIU, I suspected that there was something up with the motors themselves.  I remembered that I had both motors opened up for lubing (red/tacky in the gearbox) and pantograph upgrades.  Was the pantograph feed wire wrapped around the PS3 electronics (or the 'standing capacitors') of either motor?  That would certainly cause DCS interference as has been proven by George, John and others on the OGR forum.  Was there an issue with the pantograph?  Poor pantograph conductivity could certainly account for poor signal strength.

Test #6 Procedure:  Open both malfunctioning PS3 motors and check for wire wrapped around the PS3 electronics or capacitors.  If that is OK, then use a heavy gauge jumper to link the motor pantograph feed directly to the catenary, bypassing the pantograph entirely.  An increased signal strength will prove the pantograph is not conducting effectively.

Test #6 Results.

• The second PS3 motor that had sporadic DCS performance had no wires wrapped around the PS3 electronics.  However, it was fitted with a refurbished E44 pantograph.  When it was bypassed with the heavy jumper, it's signal strength jumped to a solid 10.  When the refurbished pantograph was used, the signal was back down to a 3-5, with occasional RF dropouts.
• The third PS3 motor that had almost always came up in conventional mode / neutral did have its pantograph feed wire wrapped around the PS3 electronics, and its capacitors were standing straight up.  After folding the capacitors down and re-routing the pantograph feed wire, its signal strength was a solid 10, and it has not come up in conventional mode / neutral since.

Test #6 Conclusions

Dealing with the findings of Test #6 resolved the final issues on the system.  Now, the primary TIU and power supply were back online, with all 5 motors always coming up in DCS, all with signal strength at a solid 10.  I added three MTH AEM7 motors, and they also came up in DCS properly, with all motors still showing a solid 10 signal strength.

5.  FINAL CONCLUSIONS

There ended up being two major issues (EMI and the Locomatic box) and two secondary issues (a bad pantograph and a power feed wire wrapped around the PS3 electronics).  I learned that I have to think hard about what might have changed on the system, (or off or around it) to effectively troubleshoot issues.  It never occurred to me before that moving the computer desk where it was would have an effect on the trains.  I have been so busy with life 'elsewhere' that I had not run trains for a while, and hence never noticed the issues I caused.  I also  had forgotten some minor control issues I had with the Atlas AEM7s a few months back, which was a warning to me then that the box was failing, or at least malfunctioning.  It also never occurred to me that I had to be careful where I ran the pantograph feed wire when I reassembled the motors after routine maintenance.  I had just 'stuffed' it back inside, giving little thought to it's proximity to the control electronics.  Also, I had known before that MTH E44 pans were problematic due to that ghastly blackening they use on them, which is electrically insulating.  That cursed blackening is nearly impossible to remove, and pans that have it generally perform poorly when used as a current collector.  These oversights went unnoticed and caught me off-guard when I decided to run trains one day, and *surprise*, nothing works right.  I learned my lesson(s) for sure.

If you made it this far, thanks.  I'm sorry it took longer than I would have liked to post this.  I hope it will be helpful to someone.

It's a shame you didn't mention the Locomatic connection, that would have been hugely helpful information to have!  I suspect that was far more of an issue than the computer in the same room.  The Locomatic actually imparts signals on the track, small wonder it steps on DCS!

Here's a small clip from a document I found on Locomatic, kinda' sheds a light on the issue.  The fact that they mention a choke to isolate it, and that lighted cars will attenuate the signal means they impart this waveform directly on the track across the track power.  Mixing that with the DCS signal is bound to be an issue!

Any load on the track such as conventionally lighted passenger
cars or cabooses will have a tendency to reduce the signal
strength of the LocoMatic™ Controller. If the loss is such that
the sounds or other requested operations do not activate
properly, it will be necessary to install a supplementary circuit in
conjunction with the lights. This is referred to as a CHOKE and
is available in various amperage ratings (items 1610, 1611,
1612).

I point this out to illustrate the importance of including ALL the details of an environment when you're looking for assistance in solving an issue like this.  If you had mentioned this at first, I could have saved you a ton of diagnostic time!

Hi John:

Honestly, since it had never been an issue before, it never even occurred to me to mention it at the start.  As you can see from my report, it was not until after I had moved the desks back as they were that the Locomatic box even came to mind.

I do agree with your comment and certainly make no excuses.  However, it would not have been the first thing I thought of as it had not given me any issues previously.  Even 2 or 3 months ago (when I last operated consistently) I ran DCS and Locomatic together and had no 'obvious' problem.  I have gotten 9/10 signal strengths with the Locomatic in line in the past, (its been a while, but I did see it).

As I said at the end, lessons were learned that I won't soon forget.  I appreciate your time and responses.

I should have looked closer at the Locomatic engine I had when I had one, I had the AEM-7 and sold it when I found the MTH one with PS/2.  I was going to upgrade the Atlas, but it was easier this way.   I am curious what frequency they run down the track.

FWIW, we have recently discovered that TMCC will affect DCS under the right circumstances, and that's only one side of the signal on the track, the other half of the signal is airborne.  That's why it's not a surprise that Locomatic that actually imparts it's control signal across the rails the same as DCS interacts with it.

I'm actually a little surprised that the computers have a significant effect, I have several computers very close to my bench and layout, never seen any effect.

John:

I have spent time pondering potential ways to upgrade Atlas AEM7s with MTH electronics, or even transfer and Atlas AEM7 shell to an MTH frame, since I liked it so much.  I have yet to come up with a reasonable solution, though I confess I did not think that hard on it.

I agree; it actually surprised me from the first day that I connected a Locomatic box that it and DCS could co-exist.  But I assure you it can; I ran both together for hours over the weeks and months with no problem.  I could send Locomatic commands even as I was changing speed on a DCS engine (impractical, but it was a test) and I never saw a problem.  I actually have a few other Locomatic boxes, some of which have never been used.  If I ever get some extra time, maybe I will break another box out and see if it has the same affect on DCS.  I could hook up the scope while I am at it and see what the signal looks like.

I agree with you on the EMI; I was as surprised as you.  But I ran those tests several times, and the result was the same every time.  Move the desk or the TIU, and DCS performance clearly increased with all motors to the same degrees.  Go figure.

Anyway, at this point I am just glad to be enjoying my trains again.  I really enjoy DCS and think it is a great system.  However, I do see the place of good ole' conventional and passive components.

Please forgive the shameless plug and borderline hijack, but this is the result of all the efforts above.  Trains are working hard again.

The 5 motors you see are the ones I referenced in the adventure above.  Details on this train can be found here.

Pantenary posted:

John:

I have spent time pondering potential ways to upgrade Atlas AEM7s with MTH electronics, or even transfer and Atlas AEM7 shell to an MTH frame, since I liked it so much.  I have yet to come up with a reasonable solution, though I confess I did not think that hard on it.

I agree; it actually surprised me from the first day that I connected a Locomatic box that it and DCS could co-exist.  But I assure you it can; I ran both together for hours over the weeks and months with no problem.  I could send Locomatic commands even as I was changing speed on a DCS engine (impractical, but it was a test) and I never saw a problem.  I actually have a few other Locomatic boxes, some of which have never been used.  If I ever get some extra time, maybe I will break another box out and see if it has the same affect on DCS.  I could hook up the scope while I am at it and see what the signal looks like.

I agree with you on the EMI; I was as surprised as you.  But I ran those tests several times, and the result was the same every time.  Move the desk or the TIU, and DCS performance clearly increased with all motors to the same degrees.  Go figure.

Anyway, at this point I am just glad to be enjoying my trains again.  I really enjoy DCS and think it is a great system.  However, I do see the place of good ole' conventional and passive components.

The Atlas AEM7 uses a horizontal drive motor correct? If PS3 can't be installed then perhaps you could convert it with a ERR Cruise Commander? You would be able to run it from the DCS remote. Just pick up a TMCC command base and the cable to connect the base to your TIU. Although you would need a Cab-1 to program the ERR board.

I have a TMCC base connected to the TIU (revision L) on my layout and run DCS and TMCC locomotives together without issue from the DCS remote.