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.