Making your biggest project to date is a tall order, and is bound to come with all sorts of unforeseen problems. This one was a matter of communication.
First, here’s a video of what it did:
The two LED strips refused to work together, and as you can hear from the audio, this effect confounded me greatly.
At wit’s end, I spoke to a friend of mine who has worked with addressable pixels before. He said that in the past, he’s used individual pixels as repeaters. Not having any better ideas, I got to work making a set of repeaters which could be spliced into the communication lines. A connector on either side, a short section of silicone tubing, and some RTV silicone to pot the whole thing and weather-seal it, and I had a bunch done. Fortunately, one of the pairs on the communication line was already carrying +5V for the sensors, simplifying the process.
Since each pixel could only push the signal a further 1.5m, I changed the layout of the lines as well. Originally, each line would run up the centre rib to the spine, along the spine to the target rib where there would be a spliced connector for the sensor, then continue down to the end of the rib where the LED strip would begin. To shorten the run and reduce the number of repeaters, I cut the lines after the sensor, and spliced the LED output that same distance back from the sensor, and ran the rest of the cable directly to the controller (which sat safely in the Powerhaus). This ended up saving me 8 repeaters, which was nice, considering how tedious it was to splice them into the Cat5 lines.
A Matter of Timing, or How I Learned to Stop Worrying and Love the CLK
So what had caused this effect? Earlier in the project, I had chosen to use the OctoWS2811 adapter and the Teensy 3.1 so that I would have 5V-level outputs on this 72MHz, 64KiB MCU. Since I had 5 data lines and only 8 outputs, I couldn’t just give each of the CLK and DAT lines their own output. Knowing how the APA102 protocol works (in that it ignores an arbitrary number of zeroes that are clocked in after a pixel has latched) and that FastLED’s software SPI sets its outputs to LOW when it’s finished, I figured I could be clever and cheat. I ran each strip’s CLK line from the same pin on the OctoWS2811, for a total of six out of eight lines used. Feeling proud of myself for getting this to work on the small scale, I rested at ease and went about finishing off every other aspect of the project until I was ready to assemble it.
It turned out that connecting more than one strip’s communication line (one side of a twisted pair inside a Cat5e cable, around 10m long) to the same output, had far too much capacitance for the little 74HCT245 on the Octo adapter. It just couldn’t push charge into the line fast enough to read a stable serial signal from the resulting voltage, even at speeds as low as 1MHz. And at this data rate, just updating the LEDs took so long that the frame rate dropped below 10FPS.
The moral of the story
I could say that the lesson here is to know your electrical or signaling theory, but it boils down to something much simpler that I learned early on as a programmer: being too clever.
Brian Kernighan wrote in The Elements of Programming Style,
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?
A short sidenote here: the version that includes the phrase “by definition” was invented by the Internet, and is not an accurate quote.
I would go on to suggest that the same applies to any machine — electronic or mechanical. Debugging a problem in any machine requires you to first keep in mind what you were trying to accomplish, and then, simultaneously, keep track of your observations pertaining to why it’s not doing the thing you tried to make it do. And if it took all of your ability to get to “how I’m going to make it do the thing”, then you simply won’t have enough spare brain to fix whatever problems come along.