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.....

More boards for hand-soldering

The PHP development is still taking up a large slice of time, especially now we're integrating it with some jQuery frameworks - it's so easy to put a dot in the wrong place or forget one of those silly $-signs, and knacker the whole thing up!

But we've managed to free up a few hours this week to do some more board etching.
As we've got some working hardware for our space-shooty game we're also getting a bit of interest about a more generic system, which could be re-purposed for many different game types.

At the end of our space-game-update, we showed one of these generic board game sections - a 6x8 grid which can be connected to other, similar pieces, to make more regular shaped playing surfaces. So a football pitch, for example, could be created by arranging six of these board sections in a 3x2 arrangement, giving a massive 12 x 24 square playing area.

But before we started to get too excited, we needed to make a few more of these boards. As ever, this meant a trip to BuildBrighton and another late night!

The board layout was loaded into the newly-refurbished (i.e. properly-working) laser cutter....

....and etching began. It takes about 15 minutes to etch the mask for each 200mm x 150mm board

Once the paint mask has been etched off, the board is given a wipe over with some white spirit (not acetone - don't ever use acetone to do this!)

This takes only a few seconds, but is a really important step. Looking at the sponge, there's of black residue taken off the board. Without wiping it down with white sprits, this residue stays on the copper, and inhibits the ferric chloride during etching

During etching, you can sometimes see "streaks" on the copper as it is etched away. These are where some of the residue may remain, even after wiping with white spirit. We found that boards this big benefit from being removed from the ferric, and a sponge applied to wipe the copper tracks during etching. Often this lifts yet more residue that has collected on the board, and ensures a speedy and accurate etch.

After etching, all traces of exposed copper are removed. Using the paper-based copper panels from JPR Electronics, it's quite easy to see when etching is complete (and where it needs a little more time to finish off any little bridges between traces). Some copper clad board is a funny orange colour, which can make it difficult to see when etching is properly complete. These JPR boards are a brilliant which when etched, making it much easier to see when you're done!

With the board etched and cleaned, it's time to get that paint-mask off:

This is where acetone is really handy. You can scrub with a brillo pad (we usually do this for small-sized boards) but we found that acetone and a pan scouring sponge got rid of the paint really quickly. One thing to note is that synthetic sponges don't like acetone very much and disintegrate at an alarming rate!

With the copper boards etched and cut down to size (we make all our boards over-sized because we can't always line them up perfectly in the laser cutter) we then laser-cut some mdf to sit over the top. The holes in the mdf line up with where we have soldered our SMT hall sensors (and 1206 resistors) in place.

The last part of production is to place a plastic-coated card on the top.
Unlike the space-shooty game, we've not designed any artwork for these board sections. The idea is that - because they use a contactless method of sensing where the playing pieces are - they can be dis-assembled and re-used for other games, by simply placing a different playing surface graphic over the top. It should even be possible to use modelling equipment such as flocking and fine grit to glue on top of an assembled set of boards, for a more permanent, realistic-looking playing surface.

We now have six of these boards etched and lids cut and prepared for them. The next few evenings are likely to be spent hand-soldering a load of SMT hall sensors: six boards, with 48 sensors on each is nearly three hundred components! Maybe it's time to try to convince Steve that a cnc pick-n-place is a good idea now!

No posts for a while can only mean one thing...

...real work is taking over!
That's not strictly true, but one of the joys of working as a computer programmer is that often there's quite a large overlap between hobby and work. The last few days, I've been getting to grips with Linux and PostgreSQL and PHP. Up until the turn of the year, I'd been Microsoft through-and-through. Not because of some fanboi love-in (ok, maybe a bit - I still think Microsoft wrote some of the best applications in the last twenty years) but because it worked perfectly well for what I needed, both in work and at home.

I'm a total noob with Linux and Postgre - I've used PHP and even mySQL but always within a familiar Windows environment (ok, stop shouting at the back, we all know PHP plays nicer with Linux - but it does work on Windows too!)

I had a crash course in setting up a Linux server, thanks to Justin and DigitalOcean.
I was really impressed by DigitalOcean and how easy (and, let's be honest, cheap) it is to set up a server; $5/month gets you a 20Gb Linux Ubuntu server with 512Mb RAM - not the biggest, baddest server you're ever likely to see, but at about £3.50 a month, and a working server within 55 seconds, they're certainly one of the best hosting companies I've come across in a long while! (and they take PayPal).

Their tagline is "simple cloud hosting built for developers".
And they fit that perfectly: creating, reinstalling, flattening and rebuilding a server is done through a web-based control panel, and takes just seconds. Very, very impressive!

So as quickly as Justin was typing his responses through online chat, I had the server up and running. I took me a day or so to fully appreciate the power of "sudo apt-get install" but now I've got all the tools installed on my home machine, I'm almost sold on it!

One of the advantages of working with PHP is the massive library of code that already exists, to do a lot of the grunt-work. And one of the things I was keen to try out was the much simplified social media integration that PHP affords (as writing oAuth routines in classic ASP is a real headache!).

I found HybridAuth which is a great set of routines to quickly get you logging in and out of all your favourite social media platforms - such as Google, Facebook, Twitter, Windows Live and Yahoo!

Unfortunately, the power of community-built software is also it's biggest downfall - and part of the reason why I'm still so distrustful of open-source zealots who insist on using "open" software just for the sake of it. And, sadly, HybridAuth has fallen foul of the "open curse": While I was able to get Google, Facebook, Twitter, and even Windows Live integrated with a simple php-based website in maybe half an hour (it took that long to create accounts and make API keys and secrets on each one) the Yahoo implementation simply doesn't work.

And searching around on the 'net for answers to "hybridauth yahoo error" returns a million and one pages, all from users of the software, asking how to fix it. And zero pages from people who have actually read, understood, and posted a solution to the problem. Such is the way with a lot of open source software.

In theory, it's great - people add to and improve peer-reviewed software, ensuring it's integrity, making sure it works properly. In practice, everyone assumes someone else will be responsible for fixing it. After all, we've just had the Heartbleed "incident"; a vulnerability in some open-source encryption routines - used by some of the biggest online companies in the world - which every else assumed someone else had validated.

I'm finding a similar problem with my PHP routines.
I love the fact that I can copy-n-paste some code and it just works.
What drives me up the wall is that sometimes it doesn't.
And if truth be told, I can't be bothered learning how it all works in order to fix it - because if I did, I probably wouldn't have migrated to PHP in the first place!

Electronic board game - time to start shouting about it?

We've been busy working on our electronic board game and maybe it's time we started talking to a few people to see if there's any interest in taking it beyond our current one-off-prototype stage. So far, all the hardware works perfectly, but we've still got some Flash coding to do, to finish off the accompanying app.
The dozen or so board sections we've already made up do look quite impressive when laid out as part of a tabetop game:

Even with just seven of our twelve board sections connected together, we're seeing the start of an interesting board game layout. And because of the way it all works, new board sections can be added at any time, even in the middle of a game. Space Hulk anyone?

Now it's one  thing to suggest an idea to someone, and another to actually show them. So over the next few evenings, we're going to work on a video to demonstrate the electronic board game in use. It may take a bit of smoke-n-mirrors to show it's full potential (since we haven't finished coding the app yet!) but already things are looking really exciting.

In fact, we're considering taking a trip to the Salute 2014 exhibition in London this weekend, to talk to game and miniature manufacturers and suppliers, to see if there's any interest in making a commercial product. It might be a bit of a punt, but there may be someone out there, just dying to take their own boardgame idea "to the next level" (as presenters on X Factor might say, along with "you really nailed it" and "you made it your own" etc.)

To be able to demonstrate that we've not just built a spaceship-based shooty game, and that the technology can be used for other genres (after all, this whole project started a couple of years ago, when we were asked to create a digital version of Blood Bowl) we're hoping to knock together a few generic board sections.

Because we're using hall sensors and a non-contact method of detecting the playing pieces, the same board sections could be used for a variety of different games: simply place the appropriate graphic over the top, load the corresponding app, and you can easily change your football pitch into a wild west village, for example.

With this in mind, we've already got a working prototype of a generic piece:

It's simply a 6x8 grid, split into two sections of 24 squares (since our room-with-four-exits uses a total of 24 squares, we could re-use the firware and a similar pcb layout for each half of the grid.

In the photo above there are a  couple of extra zero-ohm resistors and a few jump wires. These are not present in the final design: when testing this board, it refused to power up at first so we isolated different regions of it by cutting through the connecting copper tracks! With the problem found and solved, it was just easier to bridge these gaps than etch a new board piece.

And - for completeness - here's the testing showing each of the sensors being successfully activated (and released) as a magnetic piece is passed over them

All that remains - preferably before the weekend if possible - is to make up another two or three of these generic-style board sections, and to get the video camera out so we can show the world what we've been up to!

BuildBrighton door entry system update

Our new door entry system at BuildBrighton went live on Thursday night. It not only looked great, but worked a treat too.

We were happily giving out new keyfobs to all our members, and recording the RFID numbers as they displayed on the screen. Entering the RFID values against the member's profiles on our members website at http://members.buildbrighton.com/ saw the 'fobs becoming "live" almost instantly. Success!

Originally we'd planned on designing and building a pcb for the entry system but, this being a hackspace, we thought it might be nice to keep the circuitry on it's original breadboard - complete with loops of wires and ad-hoc amendments that were added into the system as it was designed and tested.

The reasoning being that other members could add to the system some time in the future (maybe adding a wav player or something, instead of the current monotone beeps we have to indicate success or failure).

Everything was working well - members could have keyfobs to "swipe in" to the hackspace, allowing their presence to be recorded on the members website. Even if the fob hasn't been activated to open the main space door (new members are given discretionary 24/7 access after an initial welcome period of a few weeks) new members can have fobs to record their presence at the 'space. This is really useful for our growing community as it allows everyone to put a name to a face (rather than ask amongst themselves "who was that guy who was hear the week before last, with the moustache and the stepper motors" for example).
BuildBrighton members can log into the members website and see examples of this at http://members.buildbrighton.com/visits.asp?date=20140328

Then disaster struck.
Leon proudly took his new 'fob to the reader and presented it. The familiar bleep went off, it connected to the internet and retrieved his (newly updated) keyfob data. "Accepted" said the display and the door mechanism triggered. "Welcome Holly" it said.

A duplicate RFID tag??
It's not beyond the realms of possibility, but highly unlikely.
We already have about 40 or so "older" RFID tags that long-standing members have.

The newer tags are more oblong, and were sourced from a generic chinese supplier off eBay - so it's possible that there's duplication. Or maybe even something wrong with the tags. But the most likely reason is something wrong with the reader of course!

It was noticeable that the duplication was all with the new fobs: none of the "older" style (round) tags generated duplicate values. But with the new tags, the same six or seven names kept appearing on the screen - even for tags that were "fresh out of the box". Something was definitely awry.

A quick hunt around on Google and we may have a solution:
Most RFID tags work with both "serial/UART" style readers, and the Wiegand protocol. We're using a Wiegand RFID reader, so that's the format we're reading the data from the tags. Wiegand is a 26-bit value and most RFID tags produce 26 bit values. We're taking a 26-bit value and presenting it as a 12 character, 4-byte string, in the form AAABBBCCCDDD (where AAA is a byte value between 0 and 255, including leading zeros, BBB is a byte value and so on).

Apparently, it's not unknown for some manufacturers to use 32-bit values in their RFID tags.
If this what is happening in our case, it would make sense of what we're seeing - the last 6 bits of the RFID value could be being truncated. And if the tags in our batch are numbered, even roughly, serially, dropping the least-significant bits of the value would result in the same value being produced when two different tags are presented!

Imagine one tag had a 32-bit value 00000011 11110000 10101010 00000001. This would be 3,240,170,1 and we present this is 003240170001.

Now imagine another tag had the value 00000011 11110000 10101010 00000010. This would be 3,240,170,2 - the next number in a sequence. A 26-bit version of this number would be 11 11110000 10101010 00000010 and give the same results. But, of course, if we're reading a 32-bit value as if it were a 26-bit one, we're losing the last six bits, and both tags would read 00000011 11110000 10101010 00. This would give the vale 3,240,170,0 for both tags. And this would, of course, result in "duplicate" tag ids.

Luckily, we had some different style RFID readers.
As well as the Wiegand reader (which was originally bought for use outdoors, as it came in a fully weather-proof enclosure) we also have two or three serial/UART style readers hanging around. These are not only very easy to interface with (simply provide power and when an RFID tag is presented, they spit out a 14-character string over serial) but they're also much cheaper than a fully weatherproofed reader.

this serial-based RFID reader is very similar to the one in the "owl-based" door entry system currently used to provide access to the BuildBrighton hackspace.

A quick bit of poking-wires-into-holes and we quickly had a replacement for our Wiegand reader, while able to leave the rest of the firmware (and hardware setup) pretty much as it was. In fact, it actually tidied up the breadboard quite a bit. It seems quite fortuitous that we didn't go to the trouble of making up a PCB now - as swapping one reader out for another will be much easier to do (with the rest of the hardware mounted in place on the back of the door) while everything is still on the prototyping breadboard!

BuildBrighton door entry system v2.0

So what does all this mean?
Well, everyone who has been given a (working) keyfob for the new door entry system will find that it no longer works. As we're reading the RFID value back as a 14-character string (the first and last bytes are start/end markers, and the next-to-last two bytes are a checksum) all our keyfob IDs are now 10 character strings (using the numbers 0-9 and A-F, whereas before we were completely numerical). To make integration with the earlier system easier, we'll simply prefix the "new style" IDs with the characters BB (for BuildBrighton) to make them 12 characters again.

So with this new reader in place, everyone should expect their RFID tag to be reported as BB-something-something. We'll have to update the members website, and once this is done, we can finally put the project to bed and move on to something else (CNC pick-n-place anyone?)