Data cable weirdness issue.

Data cable weirdness issue.

In order to minimize people-cable interactions, I am rewiring our BRC3PO lights. The idea is to have the 8 2-conductor cables carrying data and ground for each string of LEDs go to a patch box and then run one 8-conductor ethernet-type cable and a common ground wire to the arduino, where the data lines break out of the RJ45 jack and go to individual pins.

It sort of works, but when I got it up I found that I was getting flicker on some of the LEDs, (but not all) when they should have been steady. The color was correct on both flickering and steady LEDs. All are neopixels.

In standard debug style I began changing things…and I found that the flicker stopped when I used a different ethernet cable. Both labeled Cat 5e. Anyone have an idea what’s going on with the flicker?

Don’t have two data lines on the same twisted pair, that way lies sadness.

Since I am running data on all 8 conductors, why would one cable cause flicker and the other not?

I assume both cables are the same length ?

No. The flicker-causing cable is 10 ft, the no-flicker cable is 6 ft. Both are just old ethernet patch cables I had lying around.

@Paul_Guthrie

Well… that makes for an easy explanation !!

I look forward to hearing it, because in actual application that cable needs to run about 25 ft.

Hi @Paul_Guthrie ,

Sorry, I figured you understood that the longer cable is just ‘more likely’ to give problems.

I’ll assume that you are running that data in parallel and you are effectively getting crosstalk between data lines.

I agree with Daniel that having 2 data lines on the same twisted pair is looking for trouble. That is not normal usage of that cable and you should not expect Cat5e data rates vs cable lengths out of that setup.

“more likely” is not a very reassuring basis for a design decision. Is it your prediction that if I get a 25 ft cat 5e cable tomorrow and hook it up I will see flickering? Because we can do that test.

Frankly, I am dubious. If I was getting crosstalk in a 10 ft cable, why not in a 6 ft cable? What happens in that next 4 ft?

You and Daniel may be quite right in counseling that this is a bad idea, but the failure mode doesn’t make sense at this point.

You should only be running four “signals” down one Ethernet cable, with each paired wired connected to ground. By running a signal down each of the eight wires you are essentially forcing cross-talk between (twisted) pairs of separate light strings. Remember, those wires are not shielded from each other.

The twisting of a data and ground wire is what allows the high frequency transmission to work. Each of the pairs in an Ethernet cable is actually twisted a different number of turns per inch in order to allow them to not interfere with each other. Ethernet cables fail if too much of the pairs is untwisted at the end (improperly connected to plugs/jacks).

As for failing at 10 feet but not at 6 feet, you may just not be seeing the failure at 6 (as it may be so slight). It’s entirely consistent for for longer runs to be more problematic, as the chance for error (cross-talk or outside induced noise) increases. By the way, were the cables stretched out, or were they perhaps coiled up?

Hi @Paul_Guthrie ,

Yes, of course it is my prediction that your 25 feet cable will be significantly worse than your 10 feet cable !!

When I asked about the length, I really did not expect your answer. I was thinking that as unlikely is it would seem to me, maybe not all Cat5e cable are created equal. But that would have been a lot more difficult to explain then.

You may be dubious but you are also getting some crosstalk in that 6 feet cable, it just happens that it is below the point that data gets corrupted.

What happens in the 4 ft ?

67% of what happens in the 6 ft.

Okay, bad idea. Thanks all for taking the trouble to explain why.

Unless you have one readily available to ‘play’ with, I would not consider the Cat6 cable.

The crosstalk you are getting is mostly between the 2 data lines on the same twisted pair. Using a Cat6 cable will change nothing there.

Any improvement between pairs or in the connector will ‘not likely’ be sufficient for your application.