Well, that didn’t take long:
The red spot in the next-to-bottom row of the test fixture (*) marks a failed WS2812 LED. All of the LEDs above it, plus the LED just to its left, are in pinball panic mode: random colors flicker across the panel as the LED’s controller transmits garbled data and the downstream LEDs pass it on.
This failure provides several bits of information:
- The LED sees the same power supply as all the rest, so it’s not a power thing
- The LED gets data from the adjacent WS2812, so it’s not an Arduino output thing
- It failed after about four days = 100 hours of continuous operation
I connected the previous LED’s output (#6) to the next one’s input (#8), so the failed LED (#7, now with output disconnected) continues to flicker, but doesn’t influence any of the downstream LEDs.
(*) The LEDs are daisy-chained from lower right to upper left, row by row, so that’s LED #7 of 28.
The Smell of Molten Projects in the Morning 
That’s in interesting failure mode. Not only is it confused, but it’s babbling to all its downstream neighbors too. That kind of narrows down where the failure occurred to its input circuitry. I’d be tempted to scope the output and see what it looks like.
I vaguely recall seeing non-logic-level wobbulations: the pullup transistor was toast.
I must fire up the scope and try that again!
OT question: I see that knock-off Arduinos are using the Winchip CH340, and you posted on one last October. I think I found a good driver, from 0xcf.com, and source code is around, but, where did you find your driver? It’s not built into my kernel… Haven’t had to build drivers before, and it’s been a while since I’ve had to create a makefile.
I’ll admit I haven’t tried the Linux driver yet myself (I’ve been using a Mac lately), but there is a Linux driver available from the chip’s manufacturer here (their Mac driver works fine): http://www.wch.cn/download/CH341SER_LINUX_ZIP.html
That looks like the one mentioned at 0xcf. I went to winchiphead dot com last night and got the Chinese site. Oops.
Thanks!
Somewhat to my astonishment, It Just Worked with the CH340 driver baked into Mint 18.3 and Ubuntu 16.04: no hassle at all.
The factory wch driver worked. After “ftdi-gate”, hackaday was promoting the ch340. I saw source code for a driver in Linus Torvald’s github repository, so I’m not surprised that some distros have it already.
This is for the Elitech RC-5 temp datalogger. There’s a python script that’s supposed to cover both the RC-4 and the 5, but I’m getting complaints about size mismatches when I’m doing higher level commands. (Not sure the author did much with the RC-5, but it’s the only Linux game in town.) Raw data send and receive seem to work. At first glance python looks like Perl5 after a trip through the C –> C++ transmogrifier, so it shouldn’t be too hard to debug. I hope..
As it turns out, the factory driver works with older kernels, 2.6 to 3.13, but blows up in 4.4. I grabbed ch341.c source from the linux github, and after devolving the reset-resume code to drop a new function, It Just Worked. I didn’t want to try upgrading my kernel, and my git-fu wasn’t good enough for me to grab 4.4 source. Slackware is a wee bit conservative, I think…
The little Elitech temp dataloggers seem to work, at least withf a casual test run. At $18 or so, it’s worth a try. The MalwareSoft Windows version of the control program is all right, and works through Win 7 at least. Not sure if it bundled the 340 driver; had to search for it on the Windows Laptop. For linux, there’s elitech-datareader, a python script l. Lightly documented, but the Elitech hardware isn’t documented beyond “push the button, Max”, so I’ll not complain about the script. civic (Takashi Sasaki) did a great job.