(March 2016)

When the Grid was running on the Arduino, the very first pixel of the last board in the chain seemed to always want to trigger differently than the rest. Otherwise, it seemed to work just fine (low bitrate not withstanding).

When I upgraded to the Teensy, I had to do somthing about the 3.3V to 5V logic level conversion. The LED board and all it's chips are 5V, and the Teensy 3.0 is 3.3V. I had one of these sparkfun level translator boards on hand, so I started there. I didn't actually need the bidirectional feature on any pin, but the 4 channels and ease of use looked great. Neither of the libraries I used on the Arduino were exactly the right fit for the Teensy, so i had to also write a bunch of new code.I replaced the NeoMatrix library (and underlying NeoPixel library) with FastLED by PJRC. It just works. I did keep the NeoMatrix lookup for converting X,Y coordinates to string index, but removed all the options for other matrix configurations.

On the shift register side, I just wrote a bit-banging routine using the Teensy's DigitalFastWrite commands to reduce the Teensyduino interpretation delays. This is where the bits went to die. For a while I thought I was just clocking things too fast, and I went through various hoops to prove that it wasn't my software, and it wasn't the PCBs. The symptom was that each board thought the last few LEDs were being touched, no matter what, but randomly. It also got progressively worse the further down the chain I went. I didn't capture the scope traces, but I was able to see both with my scope and my logic analyzer that the bits were disappearing. Since each PCB in the chain has 25 bits of real data followed by 7 bits of padding, the padding bits were getting shifted into the data area. Actually touching the IR areas of the board made it worse.

After weeks of intermittent troubleshooting, I determined that the data bits were somehow being coupled into the clock line, causing it to randomly clock extra times. I happened to have used pretty high speed shift registers, so they had no problem at all keeping up with a glitched clock. I tried just about everything I could think of, from buffering the signals through extra channels of the LM339s, to even moving the clock and chip select lines to direct I/O. The 3.3V output of the Teensy is well above the input spec for the CMOS shift registers, so didn't even need conversion. Somehow, even with this, the data is being coupled back into the clock.

Just to test everything, I went back to the Arduino and everything still worked. I also removed a row from the assembly and tested sets of 1, 2, and 3 boards with the Arduino and the Teensy. The Teensy was Just Not Working.