SNES - Problems When 2 Long Controller Extensions Used Simultaneously

[ElRuteador]

I've built two quite-long controller extension cables for my SNES, and each works just fine independently.
However, if both extension cables are connected to the console at the same time, the button assignments for one controller become swapped (in a consistent way), as if I've mis-wired something.

Does anyone have any ideas as to why this problem only occurs when both extensions are used at the same time?

As background on my extensions, I bought 6 foot controller extensions, cut them in half, put RJ-45 connectors on each cut, and extended the controllers about 25' using straight-thru CAT 5 cable and RJ 45 couplers.  As I mentioned above, this solution works beautifully when only one controller is connected to the console.

I appreciate any ideas!

[albino_vulpix]

How do they become swapped exactly? The SNES uses a single data line to present what buttons are pressed to the console, so I'm thinking maybe the cable is simply too long and the propagation delay is having an impact?

[ElRuteador]

Below is the pattern I've found (testing using Super Mario I in Mario All Stars).

Y is interpreted as Start and Down in quick succession
B is interpreted as Start and Down in quick succession
Select acts like A (jump)
Start acts like right arrow
Arrow inputs seem to give expect results

Again, everything works fine if only one extension is connected to the system at a time.
I fear that cable length / resistance is somehow the cause here as well, but I can't explain why they work independently.
I think the RJ-45 couplers I'm using are too cheaply made and might be adding the extra resistance...

I appreciate any ideas!

[albino_vulpix]

The first 3 pieces of info you give look consistent with lag on the data line. Looking here, select and up could also being triggered. Do you have a game that could confirm this, unless pushing select in-game does do something meaning I'm completely wrong?

[ulao]

I'm pretty sure you are messing up the clock.  The console expects the controller to respond with a certain sine wave ( to put it simple ). This sine wave is just a bit late omitting or shifting the result. The console is more then likely picking up the shift later on and messing up the order of the byte.

I think this is what albino_vulpix is suggesting also. Since the first 4 bits are b,y,sel,str t they are wrong. Its possible the console is trying to catch up by analyzing the falling and rising edge.  Either way toy will never get the first bits right.

You would not be able to fix this since the console sends a latch and expects the response at a cretin time. This is only a guess of course I could be wrong.