blinktronicator

Joe and I recently wrapped up our #NeuroBytes grant so I got my hands on a spool of 34 AWG magnet wire and spent yesterday building a deconstructed blinktronicator:

This exploration into the world of novelty soldering is without question the most tedious tangent I've ever embarked upon. I bumped the shift register package up one size since the 0.5mm-spaced DHVQFNs from the original were insanely hard to free-hand solder, but... to be honest, the 0.65mm-spaced TSSOPs shown above aren't any better, since one has to tack onto a teeny pin hanging out in space rather than a slightly teenier metal pad on the bottom of a chip. I also used a hilariously massive DIP ATtiny45 since I ran of the TSSOP models and thought it would look neat.

Electrically, this version is pretty much identical to the standard PCB other than the resistors; I decided to skip the bussed units for "ease of assembly". This also helps thermal performance a bit as the original 8-resistor networks dissipate around half a watt each when all the LEDs are on at full brightness, which is a tad over the per-element limit of 0.05 W. All the LEDs are rarely on at full brightness, but it's still something I should fix if I do another PCB iteration. Hence the graveyard of tombstones along the back of the rear of the board:

The bypass capacitors for the two shift registers were fairly easy to add after dealing with the LEDs (at least 0402 ceramic capacitors aren't flat!), but I'm especially happy with how I decided to mount them:

This creation will likely meet its untimely demise as soon as I accidentally crush it with a stray piece of paper (as the free-air portions are insanely delicate). Until then it stands as my best personal example of furthering the impracticality of an impractical project.

I took a ~6-month hiatus from this project, partially because #NeuroBytes has taken up all of my time but mostly because I have trouble getting excited about firmware development. This weekend I spent a day to finalize the firmware and run the boards through their paces, and I'm ready to change the "ongoing" tag to "completed". Yay!

First, a teaser picture designed to pander to our editorial overlords:

above: 1/8s, f/11.0, 35mm lens, iso200, swinging the camera around like a madman.

I also put together a < 3min video describing the four operating modes:

Mode Zero is pretty simple: the left and right buttons cause the selected LED to move back and forth, recycling at the end of the row. The buttons have a rollover function so you can hold 'em down to move between several elements. Everything is displayed at 25% brightness, which seems to be a good balance between blinding the user and not being useful. This is the default mode the blinktronicator reverts to whenever power is cycled.

Mode One is novelty mode, designed to look cool and demonstrate the fading capabilities of the firmware. I've implemented a 6-bit PWM fading routine, which breaks down nicely into a few discrete brightness levels separated by multiples of 4--enough to be obvious to the eye but also compact enough to leave a few LEDs off. This mode pretty much scrolls an array of brightness values, {1,4,16,64,16,4,1} (where 64 represents 100% brightness) through the sixteen elements at a rate controlled by the two buttons. Brightness values could be calculated on the fly using some simple bitwise math, but using a preset array means I can easily tweak individual brightness as needed.

Mode Two (which I confusingly called "Mode Three" in the video) is color mixing/design/utility mode. The right button works as it does in Mode Zero--pressing it once moves the 'cursor' one LED to the right, while holding it down rolls over. The left button allows the user to select four different brightness levels (1, 4, 16, or 64) along with "off" for each LED. This button also rolls over, which serves as a handy reminder of what the mode does as the user's first instinct is often to hold down buttons willy-nilly. I love this mode: you can project the LEDs onto a piece of diffusing paper to see how relative brightness LEDs mix, or just get a feel for how a selection of wavelengths look next to each other. Four discrete brightness levels helps compensate for the relative brightness differences of the elements; for example, the 527nm ("true green") LED is substantially brighter than the adjacent 560nm LED, to the point that comparing them side-to-side is best done with the 560nm LED at brightness level 64 and the 527nm LED at brightness level 4.

Mode Three is persistence-of-vision display mode. To make the refresh rate work right I had to dramatically speed up the program loop for this mode, so to avoid rolling over the mode change I added a separate delay function on the mode select statement to compensate (otherwise it was really hard to get the board to stay in this mode). POV mode just scans through a 2 byte wide array representing an "on" or "off" value for each LED, and sets them to full brightness as needed. Fading doesn't work here as the PWM code isn't nearly fast enough, but it works well enough to display simple images and text. I found experimentally that if I make the array longer than 48 bytes I start to run into memory overflow issues; too bad the 't85 doesn't come in a TSSOP package like the 't45. Now that I think about it, it might be worth redesigning the board to use the 't85 QFN, maybe with a big via on the bottom so you can still hit the ground pad with an iron. I like that blinktronicators are 100% hand-solderable without a reflow setup!

One interesting note: the POV display distortion is caused by the curvature of the LED array. I thought about fixing this in software (by pre-distorting the Jolly Wrencher in the opposite direction) but got lazy. Also, if you build one of these and want to use your own graphics, know that the resistor arrays aren't really spec'd for 100% duty cycle on all LEDs; they get a bit hot if you leave everything on. If nothing else, put a bunch of space between repeating graphics if possible.

Functions include a few designed to read button status using an implementation of Elliot Williams' clever debounce algorithm, along with a few speedy functions to update the various LEDs through the two shift registers. These could probably be rewritten to be more efficient (or at least readable), but I exited the never-ending optimization turnpike once this stuff was fast enough to work for the four modes above.

So that's about it--the blinktronicator is done, the repo is up-to-date (use 'runtime', the other two programs are earlier version that don't do as much), and I'm on to other projects. As I mentioned in the video, Mode Three bears some relevancy to an upcoming project, so .. stay tuned, I guess?

One thing I liked about the 2015 Hackaday Prize (specifically the Best Product competition) was that entrants had to make three identical working copies of a device. It's a good exercise, and it helps that OSHpark sells boards in multiples of three. Here they are, nestled together on my shelf-mounted USB hub:

The slots didn't work, which isn't entirely surprising. The browser preview showed off-center holes, so I wasn't shocked when I opened the package to find the same. A few minutes with a razor blade opened the holes up enough to stuff in the structural tabs from the USB plugs.

above and below: old (left) and new (right) board comparison, showing the "slots", lack of USB data pins, "no data" text on the front copper, revised programming pad locations, and a variety of other minor changes.

After assembling the first board, I used a few scraps of FR4 I had lying around along with a quartet of finicky surface-mount pogo pins to build a nifty little programming rig. The USB socket, salvaged from a still-in-use mini fan, is used for power/gnd and physical support; the entire structure is flexible enough that one can push down lightly on the board to engage the four pins.

Not a terrific in-use picture, but you get the idea:

This was fun enough to build (and super convenient once complete) that I'm going to keep doing pogo rigs for my projects from here on out. However, the SMD spring pins can be a bit of a pain to properly align, so I'll likely start using traditional insertion devices instead.

One last thought: Dave Jones was right about soldering tips, folks. Get the damn chisel tip if your iron didn't come with it and throw out the conical garbage. I snapped a picture of my trusty WES51 posing with a finished board so you can see how much bigger the tip is compared to the 0.5mm pitch 16-DHVQFN shift registers; it's wide enough to span four pads:

My process: 750 degree iron, Chip Quik 96.5Sn/3Ag/0.5Cu RoHS solder, and gobs of no-clean (hah!) gel flux. Tin the iron and drag it across the pins:

Super simple once the chips are properly aligned...

I put together a simple PWM-based fading routine for the LEDs; it's pretty much a pair of functions that run as fast as possible:

updateLEDs(unsigned char ledOutput1, unsigned char ledOutput2)

displayFader()

I'm guessing the code could probably be significantly more efficient; I'm still learning a lot about how bitwise operations work and so forth, so comments are absolutely welcome and encouraged. I also added a slower loop to gradually change the LED brightness values sequentially.

When I used the full 8-bit brightness value for each LED, I was able to maintain a ~40 Hz refresh rate according to the 'scope; this produced noticeable flicker, so I reduced the threshold for faderCount to 100. I'd like more rangeability as brightness level 1 still isn't super dim, but it's a start.

Firmware update has been pushed to the repo.

above, OSHpark rendering; below, KiCad GerbView.

As mentioned in the last update, this order reflects a few changes:

• changed color names to peak wavelength values (nm)
• updated name of project
• flipped shift register footprints and rerouted board as needed
• slight modification to "+" and "-" indicators
• updated USB plug footprint
  • added holes for plastic pegs
  • eliminated data pin footprint (replaced with "no data" notice in the copper)
  • changed structural connection footprint to slots
  My understanding of OSHpark's slot spec is that the above board should work properly but there are no guarantees. The two large pads are structural so I'm not too worried if they come out as shown in the rendering; I can always drill out the slots by hand without concern with respect to the slot plating integrity.

Any way to embed gfycat animated HTML5 images? They're wicked fast. Anyhoo, the Blinktronicator seems to be working.

https://gfycat.com/ShorttermAnimatedBeetle

I also uploaded the test program onto the second prototype. This is before I remembered to reset the ATtiny45 fuse to 8 MHz.

https://gfycat.com/HonoredCorruptBubblefish

The latest firmware/hardware has been pushed to the repo, including a 2-LED-wide test chaser and a new PCB design:

Changes: (1) correctly oriented shift registers (no longer mirror image footprints); (2) slot-shaped USB plug structural pads (rather than 2.5mm plated holes); (3) better programming pads (or, at least, easier to access); (4) wavelength silkscreen rather than "color"; (5) full title instead of just "blinktronicator", which I may or may not update.

I ended up flipping a few shift register connections (and as such, the currently published firmware functions won't work perfectly--I'll fix this when I order the new boards); in the process I also de-cluttered the schematic a bit by separating the resistor networks from the LEDs:

Imagine I didn't accidentally disassociate a library that included the resistor network symbols--they'd be on the right side of the above image. I will fix this at some point, but it is late and I need to go to bed.

I also changed the project name to "blinktronicator". I kept forgetting "Rs" or "Os" and got the files confused a few times. Also, "Bg" should really be "Gb"; 527nm really isn't very blue. It's up-to-date on GitHub and here, but I may have missed a few spots (such as the PCB silkscreen).

So yeah. #blinktronicator.

As suggested in the video from the last log, I finished soldering together one of the bad boards. Today, I took a bit of @K.C. Lee's advice and tried standing the shift registers up on one edge:

I enjoyed avoiding six point-to-point solder connections. Securing the chip first was a big plus, too--the previous method required a few extra steps and was difficult to get right on the first (or second...) try. The four side connections were, once again, the most difficult part of the operation.

After some de-fluxing, this is what the two boards look like side-by-side:

I also temporarily soldered wires onto the six programming pads of the first board and tapped the board a few times to re-check the LEDs (the newer board was checked in a USB hub):

So why the '-ish' in the post title? Well... I haven't actually tested the functionality of the boards. As in, I haven't sent the shift register a specific series of pulses and observed the correct result.

The second '(-ish)' in the title is because this hardware iteration is destined for the wastebasket: it requires the user to install 67% of the ICs upside-down. Not a good design! I did update the schematic and board layout but haven't double-checked the work yet; I want to be sure I include some of the other complaints I'd recognized previously. And I want to make sure the circuit works, so that means the next step is [finally] working on firmware using the two existing prototypes.

The board needs a thorough de-fluxing, and it's late and I need to go to bed. But I soldered up the other shift register, along with the other components, and plugged the whole works into a USB port that I've got mounted to the underside of my shelving (hence the odd perspective):

This was unexpected behavior. I plugged the Blinkronicator in just to make sure it didn't release the Magic Blue Smoke (tm). When I touched the back of the board (specifically, a few of the programming pads), it started doing weird things as you can see in the video.

What's going on? I'm guessing I'm picking up 60hz from my house's wiring, and that's running through the MOSI pad to SRCLK on the first shift register. Then ... the ATtiny is doing something too? Keep in mind, I just soldered everything together--no code has been uploaded at this point (or written, for that matter).

Anyhoo, it looks like the shift registers are doing something right, and the LEDs are all lighting up (and appear to be different wavelengths), and nothing caught fire. We'll see what happens when I try to control the display...

One shift register down, one to go. No electrical tests yet, but all sixteen leads move with the chip when I give it a nudge. Wire is from a 28 AWG stranded bundle, which turns out to be 7x36.

More to come..

The boards arrived yesterday. They are, as expected, tiny.

They also have a number of issues, one of which is unfortunately fatal with respect to the #The Square Inch Project deadline: this generation will never work. But first, some pictures of a partially assembled and inadequately cleaned board:

I'm particularly happy that the shift registers and the resistor networks appear to be successfully soldered to the board. Actually, that's one of the reasons I mostly finished this board after discovering the big problem--I wanted to make sure I'd be able to hand-solder the next generation if I used the same chip packages. These images are via 10x loupe (and thus have a hilariously bad depth of field), but the joints appear to be sound and un-bridged:

Above: 74HC595, DHVQFN16; below: 8-element 150-ohm resistor array, 1206. I lucked out in that the shift register doesn't require its bottom pad to be connected (or even grounded), so I skipped it entirely and didn't have to get out any reflow equipment. We'll see if that decision yields negative thermal consequences.

So what are the problems?

First: the USB connector footprint. The large (2.5mm!!) diameter holes used for the mounting tabs in place of slots mean only the corners of the tab are touching the plating, so I'm a bit concerned about the joint's mechanical strength. Worse, I completely forgot to include a pair of unplated holes for the plastic mounting bosses that protrude from the bottom of the plug, as shown in the center top image of the part drawing. Skipping these pins made initial alignment a bit more cumbersome, and I'm guessing they also add a bit of mechanical strength to the connection as well.

Second: the pogo pads for programming. I learned today while working on a concurrent project that these pads aren't large enough to use as bases for a pogo jig, and the 1.5mm diameter pad is tough to align with manually placed posts on blank FR-4. Might be worth skipping this entirely and just including a standard header.

Third, and most severe: the shift register footprints are flipped. As in, no matter how many times I rotate the chips, they're still mirror images of what I thought they would be. I even tried soldering one on upside down using tiny scraps of wire but I almost died of tedium. It just won't work.

What happened?

Well... I made my own footprints based on the datasheet. Er, that is to day, my erroneous interpretation of the datasheet. In the DHVQFN16 pinout drawing on page 20, I ignored the top image and based my pad design on the second image, which shows a view of the chip from the bottom. By copying this directly into copper instead of its mirror image, I doomed this generation before it ever hit the fab. Or at least, doomed it to a mediocre life of soldering practice.

What now?

I'll never make the 12/22/2015 deadline for an image of the working boards, so I'm going to accept a DQ in the contest. My missing (/forgot-to-order-last-week-so-I-ordered-them-Thursday) #NeuroBytes parts just showed up (as in, Saturday delivery, 20 minutes ago) and I want to see some blinky neurons on my desk before leaving for vacation on Tuesday. My hope is to have updated #RRRRoOYYYYgYgGGBgBPW Blinktronicator board designs off to fab before the holiday, in which case I'll get back to this project in early January.