Soldering 4-pin WS2812B SMT RGB LEDs to the laser shades

Wow. That's a lot of acronyms in just one title! But here's a quick description of what we've found to be the best way to solder the 4-pin surface mount LEDs for our laser shades project.

To begin with, we're working on a homemade PCB with exposed copper tracks - none of what follows would probably be required, if the board were "professionally" made, with solder mask and so on. But we've lots of exposed copper. And that means lots of opportunities for bridging (and lots of potential points of failure!)

Here's a close-up of the board we're working on:

There's not much room between the top-left pin of one LED and the top-right of the succeeding one (we're placing our LEDs from right to left). Also, it's possible that while soldering the top-right pin of the LED, there's a chance of bridging onto the power rail running along the top of each row.

(Note that the holes drilled into the board serve no mechanical purpose - but the do allow the wearer some kind of vision while wearing the shades!)

Our preferred method of hand-soldering SMT parts is to coat the pads with flux pen and place the solder paste directly onto the pads. Except, in this case, the tiniest little movement while placing the LED could result in solder paste being smeared between the pads and the tracks above. And should this happen, there's no guarantee we'll be able to get our soldering iron in there, to burn away any excess.

Instead of placing the solder paste onto the pads, we're using a bit of wire to apply the paste onto the sides of the pads on each RGB LED.

 There's no solder being applied to the underside of the LEDs (which probably means the connection is not as "true" as it might be) but when we apply heat via the iron, the solder that's been applied to the sides of the pads makes a nice, neat connection to the pad underneath.

It's a slightly peculiar way of applying paste (and may well be frowned upon by a few people) but it does make soldering rows of these in close proximity a little easier!

After applying each LED, we test for continuity between the data out of the preceding LED and the data in on the LED just placed. We also test for continuity between the Vdd pin and the power rail, and the Vss pin and the ground rail. Lastly, we test for continuity between the Vdd and Vss pins (to make sure that there is none, otherwise we've shorted something during soldering!)

After about 40 minutes, we had our first row soldered up:

We've six rows in total, but some of these are not full rows - so without counting, we reckon we're probably about a fifth of the way there!

Laser shades - LED 3d glasses - data format

We've got a few LEDs soldered onto a board now, for testing our crazy LED shades so we need to be able to send data to them to get them LEDs to light up. Which means thinking about some kind of data format.

Originally the idea was to have a "video screen" made up of single-coloured LEDs, but using these fully-addressable RGB WS2812 jobbies, we're concentrating more on patterns and simple shapes, rather than actual images or text. So the plan is to have an editor where the user can create individual "frames" for a pattern, which will be stored in an eeprom chip (maybe something simple like a 24C256 serial eeprom). Then an animation pattern can be played by simply saying "display frame x, scroll left for y frames, with a delay of z milliseconds between each".

Our fully addressable RGB LEDs have multiple levels of reg, green and blue, thanks to a 3-byte interface (each colour has intensities 0-7, allowing the full range of RGB colours from 0x00 to 0xFF to be displayed). But in truth, there's not really much difference, on the LED output between RGB(255,0,0) and RGB(250,0,0). Similarly, the purple produced using RGB (255,0,255) looks very similar to the one produced by RGB(240,0,240) and similar subtle differences in intensity of red and blue.

Since each "frame" is a 6x5 grid (30 pixels) and each pixel is 3 bytes, to store the RGB values for a single full colour frame requires 90 bytes. For both lenses, that'll be 180 bytes. For a single frame. Our 24C256 eeprom has 32,768 bytes of memory. That sounds a lot, but it works out at just 182 individual frames (32768 / 180 = 182.04). This may be enough, but it'd be nice to have the extra capacity for "stop frame" animation, should the need arise.

So we've decided that instead of a full 24-bit colour interface, giving a palette of 16 million colours, we're going to use the GIF image format idea, and use a palette for each image that makes up a frame - simply reduce each colour to 2R, 2G, 2B and use the numbers 0-63 to refer to each individual colour.

Sure, we won't get 255 different shades of purple, for example, but we'll have about four. And four different shades of purple is more than enough, for drawing patterns on our glasses lenses! This allows us to store the colour of each pixel in the image in a single byte; meaning one frame of animation requires only 30 bytes per lens. And our eeprom can store over a thousand individual frames of animation (546 per lens).

When converting our stored image to a 24-bit value for the LEDs, we'll simply read the first 6 bits of the value from eeprom and break each value into 3 lots of 2-bit values (each part having the value 0-3).
On a value zero (b00) we send, obviously, zero.
On a value one (b01) we send 255/3 = 85 (or 0x55 in hex)
On a value two (b10) we send 2*(255/3) = 170 (0xAA in hex)
On a value three (b11) we send 255 (or 0xFF in hex).

In truth, when reducing colours to a low-bit pattern, red and blue tend to take precedence over green. So reducing a 24 bit 8R-8G-8B colour to 16 bit is usually done by reducing to 5R 6G 5B. Green gets the extra bit, as the human eye can detect a wider range of shades in the green spectrum, apparently (http://en.wikipedia.org/wiki/High_color). We've also found, with some RGB LEDs, that the red component can sometimes be a little overpowering (though on some, it's the blue element). So when we come to actually implement our bit-depth reduction, we can "weight" two of the three component colours, should any one be more prominent that the others. In practice, we may actually end up with 2R 3G 3B for example.

So we'll simply store each frame of our animations as a stream of 30 bytes (each pixel being a palette colour reference) in eeprom, jump to the correct address where the image information begins, and read back 30 bytes. We could even program the microcontroller to perform simple animations with each single frame, instead of having to keep reloading the information.

For example, we might load an image into memory, and draw it from the top-right corner, to the bottom left, using the sequence below:

We draw our images from top-left to bottom right, simply because of the LED pixel layout - the data in pins are on the bottom right of the LED, so it makes sense to push the data into the first pixel from the right, shunting it along to the next LED (to the left).

If we wanted to scroll the frame upwards, for example, we don't need to go back to the eeprom to load a second frame of animation - we simply do some array value swapping as shown on the spreadsheet under "shift up": so array(1) takes the value in array(7), array(7) takes the value in array(13), array(13) takes the value that was in array(19) and so on. Once all the values have been shifted around in the array, the 30 colours (90 bytes) of data are shifted into the LED matrix, to get the new, scrolled image to appear.

Of course, all this is fine in theory. What we need to do is finish soldering up at least one lens, to allow us to actually test it all out!

Testing homebrew solder resist with enamel paint

UV curable solder mask is great stuff. But when you misplace your tub of it, and a replacement coming from China is going to take anywhere between 15 and 30 days, and you've a project which - for once - actually really needs solder resist to be reliable, it's time to get creative.

Our laser-shades project (ok, it doesn't use lasers, more LEDs, and they're not really shades, more like blanked out 3d glasses) has some really fine 0.25mm traces, squeezed between the pads of a WS2812 6-pin LED. Now we've had experience of working with fine pitched, laser-etched PCBs in the past, and it wasn't pretty. It's one thing to successfully etch a PCB with fine traces - and quite another to successfully solder it up!

So this time, we figured, before we made a mess of the project with our soldering irons, it'd be worthwhile making a solder mask. We've also had some success in the past, using nail varnish as a solder resist (however clumsily applied). This time, rather than using nail varnish, we thought we'd give Humbrol enamel paint a try. Not only does it usually give a nice, solid coat (the nail varnish looks a little translucent at best) but the local hobby store sells a massive range of colours. We went for the most lurid, garish ones he sold (the orange and dark green are actually fluorescent, which doesn't come out too well in the photo below)

 

The idea is to apply some peelable solder mask (Chemask from Farnell) over the pads, then paint the entire board in enamel paint. Then the peelable mask can be pulled away from the pads, leaving the shiny copper behind, while the rest of the board will be coated in enamel paint (a cheap solder resist).

To apply the dots of mask on each of the pads required a stencil. We used some plastic-laminated thick paper and laser cut the pads, once each had been resized to about 75% (to allow for a bit of "spread" during laser cutting, and to make sure that the mask didn't extend beyond the outline of each pad).

Lining up the stencil with the actual pads was a bit tricky at first, but after applying some double-sided tape to the back, and some careful re-alignment, we finally got a half-decent match

Aside from a bit of smearing as the stencil was lifted off, the result was pretty good. As it wasn't critical that the pads affected on the right-hand side of the board were well masked (it's mostly the bottom-left and middle-left pads that really needed the solder resist to avoid bridging during soldering) we decided this was good enough!

Then we hit our first disappointment (and, dear reader, so might you, as we forgot to take photos of the disaster!). The enamel paint remains sticky for a very long time, taking 6 hours or more to dry fully. It is also quite tacky during application. The very real danger with this method - which we only just realised - was that as the enamel paint is applied, is starts to lift the latex-based mask on the pads, and seeps underneath. Not good!

So Steve did some tests with acrylic car paint. Unconvinced that it would be heat resistant, he tried soldering a couple of spots on some painted copper board. Surprisingly, the acrylic held firm and acted as a solder mask on the un-exposed areas.

When we tested nail varnish as solder resist, we deliberately tried to burn the varnish away with the iron, to see how it holds up under extreme heat. When soldering using paste and SMT components, we tend to apply the iron only for as long is necessary - so the acrylic paint doesn't need to be as robust as enamel-based paint, just good enough to withstand hot solder paste (not the iron directly) for a short period of time.

Inspired by this, we re-applied the latex mask and sprayed the board with Halfords acrylic car paint. Then we a second, and similar, disaster

As the latex mask was lifted off the pads, it ripped the acrylic paint off in chunks, exposing the copper traces we were so keen to keep covered over. A new approach was needed - it was nearing midnight (so the deadline for success was looming over us!). The simplest - and most obvious - method worked quite well:

The entire board was sprayed with acrylic car paint, and under a bright light (it really hurts your eyes to do this under ambient light) the raised copper pads were scraped clear using the tip of a large drawing pin. While the final result is not particularly neat, it does look serviceable:

That was it for another BuildBrighton session. We've now got one PCB we can have a got at soldering up. And a number of methods not to use for making homebrew solder-resist on the cheap!

Small boards mean double-sided etching

Wherever possible, we try to stick to single-sided boards for our projects, particularly if we're planning on posting them on the blog, to share with other people. Making double-sided boards is, at best, a pain, and at worst, really really hard. So where possible, it makes sense to keep to single-sided, so anyone can download a pdf, print the design onto some press-n-peel, and make the board themselves.

But for this project, Steve specifically asked for a small PCB.
And, if the circuit works as we hope it should, we may just go crazy and get some PCBs manufactured (complete with solder mask) which means having a double-sided design shouldn't be such a problem.

With all this in mind, here's the latest layout for our serial-controlled wav-player boards:

The board size is just 28mm wide x 33mm high. It's been planned so that a micro SD card holder can be mounted on the reverse of the board, while a full-sized SD card can be mounted on the "front" (the side with the copper traces).

We've had experience of different SD card holders - and they come in different orientations: some have pin one/nine on the left, some on the right (so you mount the SD card "upside-down", with the pins facing upwards in some, and with the pins faces down in another).

To make the whole board as flexible as possible, we've allowed for:

• Full-sized SD card holder can be mounted on either side, depending on orientation - either on the "face side" with the body of the card to the right, facing away from the rest of the circuit, or on the "reverse side" with the holder in either direction.
• Micro SD card holder can be mounted on the reverse, to keep the overall footprint to an absolute minimum (the SD card would sit entirely within the outline of the PCB, on the back)
• The audio output from the PIC can be directed through the onboard amplifier (a BS170/2N7000 fet) before going into the op-amp, or can be fed straight into the op-amp directly, by soldering a 0R 1206 resistor either on the left or on the right hand side of twin 1206 pads labelled "SW".
• The entire board can be powered directly from a 3v source (2xAA batteries for example) or through the LDO voltage regulator, via a 5v-12v source
• The audio signal "volume" can be adjusted via a trim-pot across the three pins marked R2
• The gain of the op-amp can be set to a fixed value by changing the value of the capacitor C3

One thing to note is that the pin-out of the full-sized and micro SD card holders are not pin-for-pin. This has caught us out in the past, when trying to change a full-sized design into a micro- one!

Pins 8-4 are the same, but on the micro SD card, pin 3 on the micro card goes to pin2 on the full sized version, and pin2 (on the micro-) goes to pin1 (on the full-sized connector). It's worth also noting that the micro-sd card has only one ground pin (the full sized card has ground on pins 3 and 6).
Strangely - for something with such a small form-factor - pins 1 and 8 are not used in SPI mode for the micro-sd card, whereas on the full-sized card, seven out of nine pins are used.

Anyway, that's the board designed, for use with an LM386 op-amp.
We're going to have to dust off the laminator for etching these - it's easy enough to laser the mask for one side, but to get the two sides to line up properly, it's often easier to etch and drill one side, then toner transfer (using press-n-peel) the pcb layout for the back. This allows the holes to be lined up with much more accuracy than can be achieved with laser etching the mask.

Serial audio player with amplifier

A while back Steve used one of our wav playing boards inside a small, remote-controlled K9 toy. He took our audio output and ran it into another chip-based op-amp.  Unfortunately, he couldn't remember whether it was the amplified signal (through the 2N7000/BS170 fet) or the raw output from the PIC output pin that went into the op-amp. Nor which op-amp he used.

So, while pondering our LED glasses and waiting for the LEDs to arrive, we hit Farnell last night, and ordered some TL072 op-amps and some LM386 amplifiers to give them a side-by-side comparison.

Steve has asked for a couple more wav-playing boards, which can trigger sounds off an sd card via serial, so we thought we'd review the original design and see if we can't integrate a slightly better amp than the rather crude (though still quite effective) FET we're powering the speaker through.

While we're reviewing the design, we also added a low-pass filter on the audio output pin.
On the original design, sometimes (depending on the type of speaker used) an audible clicking can be heard at the start of the audio playback - this is part of the 125khz "carrier wave" coming through the speaker.

Serial Wav Player With Amp

As we couldn't decide whether the audio output should be amplified through the original BS170/2N7000 fet before going into the op-amp, we have allowed this part of the circuit to be by-passed if necessary.
We've also added the low-pass filter before the input/volume pin entering the amp. It may be necessary, following testing, to put this filter on the "output side" of the amp - in theory we're taking out the input signal above 25khz, so it shouldn't really matter which side of the amp (input or output) the filter goes (though, thinking about it, it might be useful on the output side, to help reduce/eliminate noise).

According to an online RC low-pass filter calculator (sorry, no link, can't find it now!) a filter with a 68 ohm resistor and a 0.1uF (100nF) capacitor should filter out any frequencies above 25khz. With a bit of luck, that'll get rid of that audible clicking before the sound actually starts playing!

Hopefully tomorrow we'll have all the bits from Farnell to get etching, not one, but two, PCBs (we've also got some peelable solder mask coming to help make masking the boards for SMT soldering a little easier - those LED glasses have some tiny little 0.2mm traces which could otherwise be a nightmare to solder!)

LED shades

A quick weekend project that got out of hand was my LED visor/shades idea. It all started because I found a load of 3D glasses in a drawer and thought they'd make cool LED glasses. But I couldn't design a circuit small enough to make a decent sized LED matrix in each "eye" (and simply dumping an 8x8 grid and only using up about half the available space in each lens seemed a little naff).

Then Jason suggested using some WS2812 RGB LEDs. I even got a reel of the 5mm square SMT versions from him and planned making some shades. But those were 6-pin jobbies, and I since found some easier-to-use 4-pin versions, and designed the entire project as a single, large, video-screen-as-a-visor.

But now I've a project that's designed, using components I don't have, and an idea that isn't what I originally wanted (which was, at the very start, to re-purpose some old 3D glasses) as well as a reel of SMT LEDs, not doing anything. Time for a re-think!

While, originally, I liked the idea of a "video screen" on the shades, I was also limited to single-colour LEDs. These WS2812 LEDs, however, are not just RGB, but support different levels of red, green and blue: so instead of just red on, green on, blue off to get yellow, it's possible to have red 100%, green 50% and blue 0% to get a nice orange-y colour. These LEDs support a wide range of colours - so who cares about pixellated video displays? Let's just make some funky colours!

Here's a single lens, using the 6-pin versions of the LEDs.
From reading on the 'net, these particular ones are tolerant of up to 6v on both the Vcc and Vdd (supply for the LED and the supply for the controller logic). Which means the extra 150R resistor, and a current limiting resistor on the LED supply shouldn't be necessary. The smoothing cap can go on the power supply to the entire matrix (or perhaps a range of different valued caps) meaning we might just get away with a matrix of just LEDs on a single PCB.

Here's a design I knocked up. It's using a 0.25mm trace to squeeze between the pads of the 6-pin LED. I suspect it'll be a nightmare to solder on a homebrew board, so I've also got some UV-curable solder resist ready to try out, when the board is etched.

This same design can be used for both lenses of my 3D glasses, and this particular design fits snugly into both. The through-hole connectors allow the two PCBs to be connected together via just three wires, while the other end of the circuit can be connected to the MCU which will do all the fancy data controls to the LEDs (and the power/ground supply from the battery operated "control box").

As it's already late, there might just be another trip down to the BuildBrighton Hackspace tomorrow evening, to try the circuit out - maybe with just three or four LEDs to begin with. But if it works with just a few LEDs, the rest of the board already has the rest of the circuit to get an entire lens working.

Another quick weekend project that got out of hand

I've been doing a lot of coding lately. Real work sometimes interferes with nerding about but every now and again it's nice to get away from the screen for a few hours and do something else. As part of a recent clearout, I found we had no less than 9 pairs of 3D glasses in our house. These are from the days when glasses were given free with the first screenings of the first 3D movies (and I obviously "forgot" to put them back in the box on leaving the cinema).

So, looking for a quick-and-easy weekend project, I thought I'd pop the lenses out of a pair of glasses and replace them with some SMT-LED-covered PCBs, to create some cool funky video-specs. There are a few similar projects on the 'net like this, but they use pre-fabbed, multi-layer circuit boards, and masses of resistors and ribbon cables (and are quite expensive to buy, even in kit form). I thought I'd try to design a PCB which could be made by anyone at home, with the simplest of equipment (some press-n-peel and a bit of ferric chloride at least).

My idea was to lay out a matrix of SMT LEDs and control them from a single MAX7219 chip (each lens would be controlled from the same chip, making each one a mirrored copy of the other). This seemed like a great idea, so I used the ever-so-scientific method of laying out my LEDs, printing them out onto paper, lining them up with the glasses, moving the LEDs and repeating this process, until they fit in the frames.

I only have through-hole versions of the MAX7219 chips, not SMT versions, so I called on Jason to see if he had any in his massive library of components. It turns out that he does, but he also had some really interesting SMT RGB LEDs that I couldn't turn down.

WS2812 LEDs are usually found in addressable RGB strips - and Jason has used them to great effect in his 1D pong game. He also had a load of them available individually, and they seemed like a really great idea: provide 5v and ground, and use a daisy-chained data line (the data out from one LED goes to the data in on the next in the chain, and so on) - what a simple, easy way to build a matrix of LEDs which require just three wires to connect them to a microcontroller and power source.

Determined to get a working project in a weekend, I put together a design using these LEDs and discovered that, because of the peculiar 6-pin arrangement, I could only get a 4x4 grid on each lens of my 3D glasses; less of a wearable video display, and more like geeky specs with a few flashing lights on them!

A quick Google later, and a visit to eBay, and there are some WS2812B LEDs winging their way over from China. These are just like the LEDs Jason gave, except they have only 4 pins (removing the need for the external capacitor and resistor required on the WS2812 modules).

However, the physical dimensions of these mean we still can't fit more than four  either across or down on each of our lenses. The answer?
Well, the project started out because I had a load of 3D glasses that could be re-purposed to make cool funky shades - and has somehow become an RGB video display "visor". If the 3D glasses are not going to be big enough to hold the 5mm square LEDs, maybe the answer is to do away with the 3D glasses! Which means designing a single-sided PCB that can be used as the front of a pair of shades (with the arms being mounted on to the edges).

Here's what I came up with:

The 2mm pads on the left-hand side of the image are for holes to be drilled into the "shades" (there should be the same on the right-hand "lens" - just forgot to draw them in) to allow the wearer to see out - albeit with a severely limited viewing field!

Hopefully the LEDs will arrive from China within the next few weeks, and I can solder up a test pair of video-shades and publish the PCB layout PDF very soon.....