This start of this issue is documented in this thread:
[Link: remotecentral.com]

I figured that I would share this in case anyone else ran accross the same issue.

The short of it...

I had to use 2 pairs on a CAT5 to send power, receive RM433 trigger, send high out and connect ground between an RP6 and a remote location about 85 wire feet away.
I paired Power and ground on the browns and trigger signal and high out on the blues. Green and Orange were in use for another application.

At the remote location I was getting intermittent control of a Mitsubishi LCD (via emitter) and a Denon receiver (via direct IR input port) through a Niles MSU140 IR block. I addition, any attempt to issue an ATON DLA code would lock up the RP6 with a cyclical loop of some sort that seemed to continuously issue whatever ATON code was attempted (power on, volume, etc...). Further testing today revealed that some macros (not containig DLA codes) would also cause a lockup.

We tested several times for wiring faults, shorts, resistive issues, inductive issues, etc... we tried diode isolating all connections between the receivers...

I finally discovered that it was the pairing of signals on the CAT5 that was causing the issue. I paired high out and ground and then power and trigger signal and the problem disappeared. I am assuming that there was some sort of inductive crosstalk taking place that was particularly sensitive to the ATON codes. Perhaps the trigger codes and the ATON codes were similar enough that crosstalk on some of the wires tripped out the processor.

On another note... after solving that issue I still had an odd issue with the Denon receiver. I could not get power on to work (this was not a code issue). I had to switch from the IR port to an emitter. I have used the IR ports on Denon receivers many times so perhaps there was some sort of resistive issue with the long wire run that adversely effected the power on code.... perhaps because the receiver responds a bit differently in standby than it does when fully powered???

T, obvious stuff I know.....but is it an 08 Denon? If so, don't forget the '2-way remote' setting in the config....

Yes, it was an '08. The setting was correct.

It was only the power on command... funny? It worked fine via emitter, however.

Whenever you use CAT5 to send any varying voltage, use it in pairs, as you found out. Adopt this as a rule and it will never lead you wrong. Always use the whites for grounds and the colors for hots. But there's another detail that you found out about here.

Output is a varying signal. RM433 trigger is a varying signal. Both can induce a signal in an adjacent wire.

Power is a constant, so it can't induce a voltage in an adjacent wire. Ground is also a constant, so, yeah, the same.

It's natural to pair a signal with the ground wire. That's what you do with an unbalanced signal on a CAT5. The twist then keeps that pair from inducing or picking up a signal from another wire pair.

What's not intuitive is that you can pair an active wire, that is, a wire with a varying signal, with the power wire. The power wire has DC, but no AC. A ground wire has no DC, and no AC. So, as regards AC, a power wire looks like a ground to an adjacent wire with AC on it! Power supplies are made so that there's a low impedance from power to ground, except at DC, so any bit of (AC) signal induced on the power wire just shorts to ground. When designers are talking about noise and noise immunity they will often refer to a power wire as an AC ground because they're focusing on what it does as regard induced AC.

So what I hear you saying is that the issue was happening as a result of the RM433 signal and High out signal being paired. Funny enough, this was my first suspiscion, however, I went for a thorough troubleshoot of the physical wiring and potential device interactions first to make sure that i was not chasing ghosts.

I looked at this two ways... one, it was obviously the nature of some of the signals that caused the RP6 to lock in a way that suggested a feedback loop. This pointed to the signal line(s). Second, it seemed that since the RM433 signal occured first, followed by the high out (it was happening when only one system macro was triggered as well as during volume ramps), perhaps it was something involving the shared ground.

It seems to me now that it must have been the high out inducing a sensitive signal onto the RM433 signal causing it to reissue trigger commands or causing some sort of confusion at the RP6. The ATON codes may be similar enough to the trigger commands to cause the processor to trip up if they were looping back (induced) onto the RM433 signal input to the processor. Some of the other codes may have been simply ignored by the RP6 as background noise. The odd thing, however, is that the ATON codes themselves were continually being issued during the "lock up"... volume would keep ramping, the on code would issue continually, etc... This is pretty specific behavior for an induced feedback loop so perhaps it just paralyzed the processor during the issue of the code???

Rats. I just read your response and realized that I forgot to tell you there's another thread here somewhere about ATON codes locking up processors, and that's even without any tweaky wiring such as you are taming. It's at

[Link: remotecentral.com]

Sorry if I wasted any of your time by not passing that on.

Yeah, you're right in the first sentence. And if it's not that, the only way to find out is to repair ( get it? re - pair! ) the wiring. Twists are what make CAT5 better than coathangers (search that one in the last month or so), so you should always pair an active signal with an AC ground, as I explained above, or pair an active signal with itself out of phase, which is a balanced signal.

Just as as experiment, someone should take an NTSC and audio balun and pair the hot of one channel of audio with the hot of the NTSC, connecting their grounds as another pair. That audio should BUZZ something awful.

No waste of time Ernie... that is me in that other post dealing with the same issue. I stopped using that name and posted on it by accident from my laptop.

Your response helped me confirm (or rather validate) the suspitions that I had... you are always good for that!

Yeah. I see that I just referred you to the thread you mentioned at the outset. My careful thinking should have been preceded by careful looking.

So where are we now? When I first saw the title of this thread, "and the solution...", I figured that a problem had been described and then the title had been modified to tell everyone it had been solved so that no newby would dredge this up in 2014 only to have Stanley and me reinstruct people on how to tighten the screws. Or something else that would be irrelevant by then.

Is this solved yet?

Yes!

Sorry about the two posts. My first was a frustration post from the field so when I solved the issue with the wire pairing scenario, I decided to repost with a title more specific to future searches in case other may encounter the same thing.

...perhaps I did not achieve this result and instead made it more complicated :)