Nerd Club

Mobile development with haXe NME

2012-03-02T10:27:00.001Z

Once again real life and work got in the way of nerding about - only this time we managed to combine the two for a while; a few of us are learning mobile development for Android/iOS and the most obvious way forward, as experienced Flash developers, was to go for Flash CS5.5 with it's built-in AIR support.

We've been asked to make a simple app for a tablet (originally an iPad2, but most likely an Android tablet) or a smartphone/hybrid (something like the Samsung Galaxy Note springs to mind) so we've been learning all about tool-chains and cross compiling. Ideally we'd have liked to have stuck with Flash/CS5.5 and AIR, which is ideal for cool kids with the latest smartphones. Creating an app in Flash CS5.5 is a doddle and creating an .apk file is as easy as hitting "publish". Copy the .apk file onto your phone via a usb lead, then use My Files to install the app. If your phone doesn't already have it installed, the app will prompt you to download Adobe AIR (one-time only).

But this is where things started to wrong for us!
We'd only got as far as installing the app when a message popped up to say that our handset wasn't compatible with AIR...

It seems that many smartphones (and tablets) on the market are still running ARM6 processors (such as our Galaxy Ace handsets) and AIR doesn't run on these. We could just ignore these, concentrate on making apps for handsets nearer the top-end of the market and go back to Flash. But there's something about cutting out a large proportion of users, many of whom will be getting Arm6-based handsets (because they are free) on two-year contracts, that doesn't sit right with us. So we've been looking into AIR-free compilers....

It's been a bit of a nightmare!
There have been loads of suggestions, tips and recommendations and we're indebted to the guys at dotBrighton for keeping us going. One thing we're keen on doing is keeping CPU usage to a minimum (with a view to extending battery life while running our apps). Of all the set-ups we've seen, haXe NME looked like it offered what we were looking for - and, it uses an AS3 type syntax with familiar libraries, so the learning curve shouldn't be too steep.

It took over 16 hours to get haXe installed and working properly. There are no easy-start guides on the 'net - we should really have been a bit more organised, written down exactly what we did and how we did it and created one for others to follow. But the truth is, it was so convoluted and we ended up downloading massive 600Mb+ files two and three times (first manually, then allowing the installer to try, then uninstalling and trying again) that we'd only end up with a guide on how not to set up a programming environment!
Something still doesn't ring true that we've used up over 20Gb in disk space just getting this lot working...

But in the end, after installing Java runtimes, Java SDK, Android SDK, Android NPK, Flash Develop, haXe NME, C++, Visual Studio Express, Cygwin and a whole heap of other crap we didn't fully undesrstand, we managed to get and environment working that allowed us to compile the Actuate example from the haXe NME website

Here's our end result. The video shows up to fifty sprites (filled shapes) of differing degrees of transparency with a couple of pngs we added ourselves, to try out the png support.

[video here]

With alpha-support for pngs, and the ability to draw moving objects at different depths, things are quite exciting. A tile-based sprite-blitted game can't be too far away, surely?

Fuzz Face with NPN transistors (MPSA18 amplifiers)

2012-02-26T18:37:00.002Z

After amending our FuzzFace design to use a positive power supply, we've had a couple of enquiries about the schematic. Mainly that a few readers weren't familiar with the PNP transistors used (nor seeing them drawn "upside-down" in the circuit) so we've found a design that uses NPN transistors and different resistor values (including a potentiometer/variable resistor to adjust the amount of "fuzz")

FuzzFace with NPN transistors

Here's the PCB layout. We've not had chance to try this, as we're still waiting for some 20uF capacitors.

That said, we've a few 22uF caps lying around here (large black barrel electrolytic types) and since 22uF is just within the range of a 20uF with +/- 10% (and 20uF is within the range of a 22uF with +/- 20%) then it may just be a suitable replacement. We hope so, since 22uF caps can be easily found all over Farnell and eBay for just a few pence whereas the cheapest 20uF rated capacitors are about £3 each.

FuzzFace NPN pedal PBC layout
(print the above at 100% no scaling to create your own press-n-peel image for toner transfer)

Since simplifying the design (using 22uF instead of 20uF capacitor for example) we've managed to source all the components needed to make this pedal, so it's off to the nerd cupboard now to crack open the Ferric Chloride and get etching!

Painting Blood Bowl miniatures

2012-02-24T13:38:00.000Z

I've been trying to spend some time away from my computer lately - which is quite difficult since it's not only my work, but my hobby and most of my other hobbies (electronics, music etc) use a computer somewhere along the line too.

Since working on my Blood Bowl electronic clone, I've been looking at miniature-based war games. I never understood them, nor was I particularly interested in the whole dragons-and-wizards games, even when I was a teenage nerd-bag baby (listening to Iron Maiden, baby). But I always thought that Blood Bowl was a good game in it's own right - or rather, it could be, if it wasn't for all that pesky dice-rolling and looking up results.

One thing I have found, however, is that I can wield a tiny 000 paintbrush quite well. I'm not up to Games Workshop Golden Demon, professional painting standard, but I do seem to be able to blob colours in roughly the right places on a miniature. So I'm trying to develop my own painting style. I can't be bothered with all those washes and blending and teeny-tiny details, but I do quite like my thick black outlines and the "toon shading" finish on these models

So this is going to be my signature style. Van Gogh had his, Escher and Matisse had theirs. This is mine. Two-tone shading and thick black outlines; miniatures that look like they've been coloured in using a set of children's felt-tipped pens. I'm still building up my range of paints, so I've a couple of miniatures on the go while I'm waiting for different shades to arrive in the post. Here's an Orc "thrower" started in my new "toon shading" style:

(the colours on the actual model are much more vivid and vibrate - my camera-phone obviously isn't very good with garish bright colours!)

While I'm actually enjoying regressing back to my 14-year-old self doing this sort of painting, I still can't wait to get the models painted and actually see them being used in an electronic Blood Bowl game!

Investigating capacitive sensing

2012-02-22T00:04:00.000Z

The results from our earlier testing for a multi-plexed capacitive sensing grid are in and...... it's not good. The idea just didn't work. It seems that to use "simple" capacitive sensing - ie energising a pad then checking to see if an input is present a few moments after shutting off the power - the pad has to be directly under the top "plate" of the capacitor (i.e. your finger).

We were hoping that putting power onto a plate immediately to the side of what would be the bottom "plate" would suffice but the only way we could get an inputs to activate was to introduce a "real" capacitor and make a mechanical contact to the plates.

This got us thinking about alternatives for our cap-sensing board (and if it would even be possible). While an RC network on each input pin is immediately obvious, converting this into a grid also gives us a few headaches. So we're now investigating how to use rows and columns of pads and our working cap-sensing prototype

.We already know that we can activate/deactive single input pins one-at-a-time and detect if a piece is above it. But when it comes to multi-plexing, re-using the same inputs for different "rows" of pads is quite tricky. But we've come up with another idea which keeps the same (working) technique and builds on it:

We're going to make strips of pads, all connected in a line. At 90 degrees to these, we'll have strips of pads on the other side of an insulating material. We can then send an entire row high, flip the pin to input and check for a signal on the input pin - just like before. What we're hoping to do is to use the pads running perpendicular to "mask out" some of these pads, so if we get an input high, we know which of the pads in the strip triggered the input.

Let's say the lower (darker) pads in the diagram are on the X axis, and the paler (higher) pads are on the Y axis. We can send row X1 high and check for a high input back. But it could have been any of three pads in that row which triggered the input. BUT - if we send columns Y1 and Y2 high, when row X1 flips to input mode, only capacitance from X1,Y3 will be detected (since when row X1 goes low, Y1 and Y2 stay high, so if your finger is over X1,Y1 or X1,Y2, it won't actually "discharge" until these columns go low as well).

That's the theory anyway.
Once again, it's a bit late to try the whole thing from start to finish, but here's as far as we got:

We started by drawing 1" squares onto a strip of 1" wide sticky copper tape. In the centre of each square, draw around a penny coin. Draw lines to connect all the dics in a row and cut them out using a sharp knife

As we're going to have rows and columns running in opposite directions, we'll need some insulating material and to stick the strips of pads on each side. Ideally we'd have preferred to use tracing paper or tissue paper - but in true "hacker" style we used whatever was to hand; these paper towels were quite thin:

Stick the rows of pads in one direction, and the "columns" at 90 degrees. If we'd used tracing paper, we would be able to see where the pads had been placed on each side - we couldn't and had to guess, which is why they're a little bit out of alignment. We're not even sure if this idea is going to work - let's hope this doesn't prove critical when we come to try it out!

Rather than spend all night making a large grid of pads, we're after proving that the idea works (or, if it's anything like last time, whether it doesn't). So we've marked the four pads in this arrangement that have pads in both the X and Y axis on opposite sides.

All that's left to do is to write some new firmware and try the idea out!
Unfortunately, it's gone midnight now and with work in the morning, this will have to wait until tomorrow.....

Multiplexed capacitive sensing board(s)

2012-02-20T22:26:00.000Z

This is yet another proof-on-concept idea, but if it works, it'll be perfect for our intelligent/electronic board game. Following our earlier instructions, here are two multi-part boards for testing.

As you can see, each pad is split into two large rectangles. One half of each pad is connected to a common "power" pin and the other to an input pin on the microcontroller. The principle is to make one half of the pad "live", shut down the power, wait a uS or two, then check the input pin. Hopefully the pad size will be sufficient to allow the coin to act as a capacitor, even if the two plates of the capacitor are different sizes.

There's no real way of knowing for sure if this idea will work or is just crazy wishful thinking - except, perhaps, to build it and see!

Multiple capacitive sensing inputs

2012-02-19T17:50:00.002Z

Using our switch-from-output-to-input method of testing for a piece works fine to date. But there's a problem brewing that needs tackling early on:

Each sensing pad currently uses one digital i/o pin.
One of the larger pin-count PIC microcontrollers, an 18F4550 (or 16F877A if we're not worried about the USB stack) has only 40 pins, of which about 34 can be used for digital i/o. If we consider even a simple chess board, we'll need at least 64 digital i/o pins for an 8x8 grid.

For anything larger or more interesting than a chess board, we'll need LOTS more pins! It's possible that we could use lots of shift registers and daisy chain them to increase our pin count, but we're going to try our earlier design, using "rows" and "columns".

We'll hook up 8 pads onto a single input PORT (each port is 8-bits/one byte wide) and monitor it for input from the board. Then we'll use the left over digital pins (and perhaps a shift register if necessary to increase the pin count here) to activate specific "rows" on the board. By knowing which row is activated, and by reading which input pins are high after the row has been switched off (using residual capacitance to keep the input pin high if a pad is touched or a player touches a piece standing on top of the pad) we can calculate exactly which pad has triggered the "high" input signal.

To achieve a full-sized Blood Bowl board, we're going to construct each row from two "modules" of 8 pads. Each module can connect to its own input port (e.g. PORTB and PORTD) on a 40-pin PIC so we'll be able to monitor up to 16 pads at any one time.

Here's a module we've come up with.
For testing we're going to etch this onto single-sided copper board. For the final version, we're going to use double-sided board (so that the traces are on the bottom and can't pick up any stray capacitance from the pieces on the top).

Capacitive sensing 1x8 board module

The first 8 pins connect via a wire to the input port(s) on a microcontroller. The final pin (connected to the 8 "row" pads through a 1mm wide trace) goes to a "row control" pin (either directly to an i/o pin, or to a shift register used to increase the number of available pins).

A few people have already said that when they printed the earlier (portrait) version of this board, their printer resized it ever so slightly to get it to fit onto the page - we managed to get this effect too, so here's a landscape version of the same board:

Capacitive sensing 1x8 module (landscape)

Testing piece tracking

2012-02-19T14:40:00.000Z

Now we've tested our capacitive sensing board and everything appears to work when using pennies (and batteries) as playing pieces. The next thing we need to know - before getting immersed in board builds, data manipulation etc - is that the whole concept still works if we use anything other than pennies or batteries.

This project started out as a digital Blood Bowl game board but we've come to realise that it has potential to be used to "electronify" (is there such a word?) many other popular board games. Luckily, many of the miniature playing pieces used in these types of games are metallic (pewter). All we need to do is make sure the metal figurine is connected to a penny in the base of the miniature.

The "slotta-bases" used by many miniature manufacturers are ideal for this.

Remove some of the plastic from the underside of the slottabase and file the bottom of the figurine so that there is enough space under the miniature for our penny

The finished model should look exactly as before, only with a void under the base to house our penny. When the finished figurine is placed over the penny, an electrical connection is made from the coin to the miniature but the penny is not visible:

This means that touching the miniature gives the same result as touching the penny - i.e. we can, indeed, use a metal miniature as a playing piece on our capacitive sensing game board:

Note that the flickering LED in the demo is not due to a fault in the board - trying to watch the video viewfinder and place the piece on the correct place on the board meant sometimes it sat between pads

Tracking playing pieces

2012-02-19T11:15:00.000Z

To date we've come up with a capacitive detecting circuit which tells us when
a) a piece is introduced (put down) on the playing board
b) when a piece is either lifted off the board, or released

It's part B that's causing us a headache for use as an intelligent board game.
The two actions are actually opposite of each other, so it's difficult to track where exactly on the board a piece is at any one time.

For example, in our test-rig, when an LED lights up, we know that
a) a piece is above a capacitive sensing pad
b) the player has hold of the piece (this is necessary to provide the "ground" for the capacitive part of the sensor

So when an LED lights up, we know that a piece is in the square above the sensor. The problem comes when understanding what has happened when the LED goes out:

Either the player has put the piece down in the square and let go of it OR the player has lifted the piece off the board and continues to hold it in their hand. These are opposite statements - when an LED goes out, either the piece is on the board, or it's been lifted off. Hmmmmm. How to tackle this one?

Let's say we start the game with a completely empty board (and a matrix/array of empty cells).
The controller (whatever that will end up being, either a character LCD or a PC connected to the board or something similar) tells the player to put down a specific piece on the board - for the sake of example, we'll use chess pieces, but the principle applies to lots of other board games.

We could keep a track of the "last piece touched" or "piece in hand".
In this case, the controller sets which piece is in hand (by telling the player to pick up, for example, a black knight). Now when an input is activated (LED lights up) the board can record the playing piece type in the matrix/array. So if pad 1 lights up, it can say "square one contains a black knight".

If, sometime after this, pad 2 lights up, the board would say "the piece in hand is a black knight. Find which square contains the black knight. Square one is now empty, the black knight is now in square two." By doing this, every time a square "lights up" we simply clear the previous location and update the playing piece to the new location. This works well for a single playing piece on the board.

When we introduce more than one playing piece (which, let's be honest would make for a pretty board board game if we couldn't) things get a little more complicated, but the same principles <i>should</i> still work:

When a square lights up:

Check to see what playing piece is in this square
If no playing piece is in this square, we're working with the previously held piece - clear the previous square and update this one to say the last held playing piece is now in a new location.
If a playing piece is found, remember this is now the held playing piece and wait for a different square to light up.

This should allow us to deal with a player simply touching and releasing a piece (the LED lights up and goes out, the board knows that the square already has a piece in it and simply updates which piece is "in hand"). When the player lifts a piece off the board, the LED lights up then goes out and the board updates which piece is in hand (since it knows that the detected square contains a playing piece). But now, when the piece is put back down in a different square, a different LED lights up, the board knows that this square is empty, so updates the location of the piece "in hand".

By using this method, it should be possible to keep track of any number of playing pieces on the game board.

The only problem we can see so far is when removing pieces from the board completely. For example, when a white queen takes a black pawn:

The player picks up the white queen to start moving. The player picks up the black pawn and removes it completely from the board. The player puts the white queen in the black pawn's old square. If more than one piece is moved during a turn, things could get messy!

In this example, the board detects the white queen being lifted off the board (white queen is "in hand"), then it "sees" the black pawn being lifted off the board (black pawn is in hand) then a piece (the board doesn't know which) appears on the black pawn's square. It's possible that the board thinks the black pawn is the piece in hand, and so says that the black pawn is back in the black pawn's square - leaving the white queen where it was.

The solution to this, is to have an "offboard area":
The board sees the black pawn is in hand (when the player lifts it off the board). The black pawn is removed from the board and put into an offboard area. The board now updates the black pawn's old square and makes it free. The player then picks up the white queen (the board puts the white queen "in hand") and places it in the black pawn's old square. The board recognises that this square is now empty, so updates the location of the white queen in the matrix/game array.

Code for capacitive sensing

2012-02-19T10:50:00.001Z

Following on from an earlier post, introducing capacitive (touch) sensing, here's the Oshonsoft PIC Basic Code to read three pads, connected to PORTB.2, PORTB.3, PORTB.4

Define CLOCK_FREQUENCY = 20
Define CONFIG1L = 0x24
Define CONFIG1H = 0x0c
Define CONFIG2L = 0x3e
Define CONFIG2H = 0x00
Define CONFIG3L = 0x00
Define CONFIG3H = 0x01  '81=use MCLR, 01=pin1 is input
Define CONFIG4L = 0x80
Define CONFIG4H = 0x00
Define CONFIG5L = 0x0f
Define CONFIG5H = 0xc0
Define CONFIG6L = 0x0f
Define CONFIG6H = 0xe0
Define CONFIG7L = 0x0f
Define CONFIG7H = 0x40

Dim tmpinput1 As Byte
Dim wd As Byte

AllDigital
Config PORTA = Output
Config PORTB = Input
tmpinput1 = 0
wd = 0

init:
       WaitMs 200
      
       UsbSetVendorId 0x1099
       UsbSetProductId 0x1099
       UsbSetVersionNumber 0x1001
       UsbSetManufacturerString "Nerd Club"
       UsbSetProductString "Capacitive board game sensor test"
       UsbSetSerialNumberString "1234567890"
       UsbOnIoInGosub usbonioin
       UsbOnIoOutGosub usbonioout
       UsbOnFtInGosub usbonftin
       UsbOnFtOutGosub usbonftout
       UsbStart
             

loop:
       UsbService
      
       'turn portB into outputs
       Config PORTB = Output
       PORTB = 0xff
      
       'wait a bit to settle
       WaitUs 1
      
       'turn portb to inputs
       Config PORTB = Input
      
       'wait a bit to settle
       WaitUs 1
      
       'read which pins are still high
       '(these should be the ones with coins over them)
       tmpinput1 = PORTB
       If tmpinput1.3 = 1 Then High PORTA.4 Else Low PORTA.4
       If tmpinput1.4 = 1 Then High PORTA.3 Else Low PORTA.3
       If tmpinput1.5 = 1 Then High PORTA.2 Else Low PORTA.2
      
       Goto loop
End                                               
      
usbonioout:
       'received data from PC
       Select Case UsbIoBuffer(7)
      
              Case 1
                           
              '---------------------------------------------
              Case 252  'write a value to onboard PIC eeprom
              '---------------------------------------------
              Write UsbIoBuffer(0), UsbIoBuffer(1)
             
       EndSelect
Return                                            

usbonioin:
       'send data back to PC
       UsbIoBuffer(0) = tmpinput1
       UsbIoBuffer(7) = wd
       wd = wd + 1
Return                                            

usbonftin:

Return                                            

usbonftout:

Return                                            

This code reads whether a touch is detected over each of the pads and lights up a corresponding LED on PORTA.2, PORTA.3, PORTA.4.It also sends the value of the input pins on PORTB to a USB client (so the board game can be connected to a PC and data read in that way too, for future development).

(For our trials, we concentrate on just the LED outputs).

Here's a video showing how the LEDs light as a playing piece (metallic disc) is picked up and put down on the playing board. Note that the LEDs flash in exactly the same way as when the playing piece is stationary and momentarily touched by the player:

Intelligent board game update

2012-02-18T23:09:00.001Z

It's been a while, and we've been concentrating on the "nicer" (i.e. nerdier) side of our electronic board game. That is, storing and retrieving game play data and displaying it on a nice, fancy character LCD.This week, we've been looking more into the actual mechanics of game play.Now, our earlier attempts at tracking playing pieces on a board did work, but the board itself left a little to be desired. Because we were making and breaking contacts on the board surface, the playing side of the board was littered with lots of little metal studs.

These didn't look particularly nice so we've been investigating capacitive sensing - specifically, placing the copper/metallic pads under a printable surface and moving the pieces around on top. This should allow us to create a number of board games with different layouts, finishes etc. but more importantly, to remove the need to drill hundreds and thousands of little holes all over the place.

Cap sensing is quite straight-forward.Create some large pads, connect to the i/o on your microcontroller, set the pin to output and send it high. Wait a few uS then set the pin to input and give it a few uS to settle. Read the input pin.If your finger (or an object acting as a ground plane) is over the pad, you've effectively created a miniature capacitor and the input pin will still be high. If there's nothing immediately over the pad, the input pin will be low.

Heres' how we tested the principle:

First cut out some sticky copper tape - we cut around a penny coin and left a trailing "lead" coming off it (so we had something to connect our wires onto, to connect to a PIC microcontroller. We placed three of these onto a sheet of cardboard, then wired them up to PORTB on an 18F2455 chip.
The input pins were pulled to ground through some 500k resistors.

The process described above was carried out and the pads touched with a finger.
The corresponding LEDs lit up as each pad was touched. Next, a sheet of 350gsm (quite thick) cardboard was placed over the pads and the experiment repeated. The LEDs continued to flash as each pad was "touched" through the sheet of cardboard. At least we can be confident that we can create a grid of pads and put a nice, printed face over the top without affecting performance.

Then we placed our penny coins over the pads.
The LEDs did not light, unless the coins were touched. But once they were touched, the effect was the same as touching the pads directly, and through the sheet of cardboard.
One last test remained - if we used metallic playing pieces, with a metallic base, they should behave in the same way our coins were. But what if the playing pieces were coated in acrylic (or other non-conductive) paint? Our last test was to touch the coins "through" a sheet of paper (a shopping receipt was easily to hand).

Now we had a working prototype, we considered how we could detect the presence of a coin above our pads but without the player having to touch them. This proved trickier than we thought. The only progress we made was discovering that touching the piece/penny was the same as connecting it to the ground pin through a wire.

Make your own FuzzFace guitar pedal (cont)

2012-02-08T22:27:00.000Z

Following on from an earlier post, guitargeek82 got in touch to point out that the original circuit was based on a "negative power" design. When running your pedal from a PP3 battery rather than a plug-adaptor-type power source, this doesn't cause a problem (nor will it cause us any issues since we'll only be running our "pedal" off a battery, since the PCB will be embedded inside our guitar body).

But for anyone interested in making this pedal to run off a positive power supply, here are the amended files:

Fuzz Face revision 1c Schematic

Fuzz Face revision 1c PCB

And the amended silkscreen/layout is below.
The parts list remains the same as before - nothing has been added or removed, just the way the components are connected up has changed:

FuzzFace parts list

2012-02-08T17:45:00.002Z

The FuzzFace (amended) design is relatively simple and has just a few components: 4 resistors, 3 capacitors, 2 PNP transistors, 1 DPDT switch (and a partridge in a pair tree).

R1 = 470 ohm resistor
R2 = 33K resistor
R3 = 8.2K resistor
R4 = 100K resistor
R5 = 500K potentiometer
R6 = 1K potentiometer
C1 = 0.01uF capacitor
C2 = 2.2uF capacitor
C3 = 20uF capacitor
Q1 = PNP transistor
Q2 = PNP transistor
SW = double pole, double throw (changeover) switch

Here's the silkscreen/layout for the earlier PCB :

Simple Tiny Fuzz Face pedal circuit

2012-02-08T10:53:00.000Z

It's been nearly a month since we've done any nerding around at Nerd Towers. Unfortunately, it's just that time of year - when everyone else is easing into the New Year and starting again, we're going hell-for-leather trying to keep real-world work from overtaking us; January is a particularly busy month for us in the real-world, so hopefully now it's out of the way we can get back to to some serious geekery.....

Despite having numerous projects on the go at the minute, there's never a better time to drop everything and start a new project, than when you're already juggling about eight balls in the air. So here's our latest one.
In fact, it's quite a quick-and-easy project and took only an evening to put together.

As we're due to move again before too long, we've been sorting out the nerd cupboard(s) and having a bit of a clear out, to make sure everything will fit into the new place. In the corner of the cupboard are a few (full-sized) guitars which we just can't leave behind. But we've not done anything with them for about 18 months.

Maybe it's time we did:
One of the easiest (and most satisfying) mods to make to a guitar is to add some onboard electronics. After a quick hunt around on the 'net we found some schematics for the original FuzzFace stomp box and decided not only to have a go at building one ourselves, but to get the chisels out and actually embed it into the guitar body, with an onboard switch to flick between "clean" and "dirty" output.

Here's the schematic:

Fuzz Face revision 1b Schematic

And the PCB layout - with components placed as closely together as possible.
Note that the two potentiometers and the DPDT switch connect to three-way connectors on the board via short wires, they are not actually mounted onto the board!

Fuzz Face revision 1b Pcb
As ever, print this onto your press-n-peel as-is so that when it is transferred onto the copper board, it is reversed. This is fine, since you're etching the bottom of the PCB, not the top - don't panic, everything will just work out in the end!

Why I hate smartphones - and what makes them great

2012-01-15T20:33:00.001Z

It's taken me a long time to even entertain getting a smartphone. I used to find them a social nuisance, always ringing and pinging and going off all the time - and don't get me started on people who sit opposite each other in a cafe, each texting someone else on their handset....
Because of this, I've never bothered with them. A few years ago I threw my mobile phone away and spent four glorious years away from the mobile world. In fact, it was only because of work that I begrudgingly spent £4.99 on a handset and SIM card at the local ASDA store and that's been my 'phone of choice ever since.

But.
I've recently been given (loaned) a few different smartphone handsets and asked to write some software and some websites to run on them. It took me a while to get past the fact that as a miniature computer, they couldn't compete with my notebook and as a 'phone they're just excessive. But slowly, I'm coming to realise that it's not the device that has upset me so much over the years - it's how it's used.

The earlier example is something you see a lot in most towns and cities across the UK:
two people sat opposite each other, each on their phone, chatting or texting with someone else. Why not just invite the other person to the cafe and sit and chat with them instead? I genuinely believe that these devices are affecting social interaction between people - and not just thanks to the slang and grammar that is creeping into everyday language, but even how people relate to each other when they are face-to-face. And it's not for the better!

That said, I'm slowly warming to these smartphone devices.
Not because I can access my emails and Twitter while on-the-go (I can, but still prefer reading things full screen on my notebook). Nor because I can view any website while out-and-about; because when I'm out-and-about, I want to interact with the real world, not a series of virtual images and links! In fact, for gathering and reading information, I still think something with a puny 3" screen is a pretty poor device for doing so, however impressive the technology behind making it happen is. And to see people sitting and walking around, oblivious to their surroundings, concentrating on what's happening to their "virtual alter ego" makes me want to weep. Put your phone away - enjoy the sunshine! Listen to the sounds of the city, enjoy the company of other people!

However, as a device for taking a photo and posting a quick note - "I'm here, I've seen this, come see for yourself" - well, I'm getting to actually quite like my (borrowed) smartphone(s). Jabbing a button to take a photo or a short video, then sending to the 'net takes a minute or two at most, but allows me to share what I'm doing with the world!

But now I've fallen out of love with my smartphone - because there's just sooo much going on and sooo many people "broadcasting to the world" that it's just becoming a noise, and I don't want to be just another voice adding to the massive pile of crap that makes up most of the "social networking" side of the internet.

In fact, I don't really care about sharing my stuff with the world.
I don't care if the world is interested.
What I do want to do is publish stuff that I find interesting and share it with my friends and family who may also find it interesting. That's it really.

And that's what sites like Twitter and Facebook allow me to do (I'm a pretty new user of both). I just didn't realise it; maybe because most of the posts I read are from people wanting to broadcast to as wide an audience as possible, trying to sound impressive or interesting to as many people as they can, trying to attract as many friends/followers as possible. But my dislike of the Twitter and Facebook sites didn't stem from the technology - it came from how people were using them. But all it takes is a change of attitude, and suddenly my smartphone and a previously hated site becomes quite a useful tool.

I'd never consider phoning my best mate up to say "mmmm, I'm eating some toast, nom nom".
I wouldn't send even my closest family member an email to ask "tea or coffee? I can't decide".
I don't understand why people post rubbish like that on Twitter.
But that doesn't mean that I have to either. So I won't.

But posting text and images to the 'net (via Twitter for example) for my circle of dozen or so close friends who might be interested in what I'm doing and when is infinitely easier with one of these little smartphone jobbies. And as a result, they might come along to where I'm at and join in with what I'm doing. And when they do, the phone has done it's job so we'll make sure they are turned off and put away - there's a world going on outside that 3" screen!

Samsung Galaxy ACE S5830 review

2012-01-15T11:39:00.001Z

Although initially very impressed with the HTC Wildfire S, after trying the Samsung Galaxy S2 II, there's no comparison between the phones. I'd love my own Galaxy S2 (the phones I have are on trial while I perform some RnD for software development) but I can't justify the price to myself.

Somewhere between the two - and available from www.mobiles.co.uk for about £6/month (after cashback) with unlimited data - is the Samsung ACE S5830.

This is like the little brother to the S2. In most respects, when comparing the hardware against the WildfireS and the S2, it sits somewhere between the two. The screen/display is bigger than the HTC but smaller than the S2. This means the images are as clear (or clearer) than the HTC, but nowhere near as bright and vibrant as the S2. It has a faster processor than the Wildfire (but not as fast the S2).
The actual handset is quite slim - although it weighs about the same as the HTC, because of the larger unit size, it actually feels lighter (if that makes sense?). All-in-all, this handset is a nice compromise between the lower (budget) end of the market and the all-singing-all-dancing- top-end (the Galaxy S2).

In fact, we may be seeing a bit more of this unit, since a few Nerd Club members have already expressed an interest in taking up the mobiles.co.uk offer for a free handset with 300 minutes, 300 texts and unlimited data every month for about £6 (after claiming cashback). Not a bad handset. And not a bad contact offer either!

Samsung Galaxy S2 II review

2012-01-15T11:23:00.002Z

I'm still pretty new to the whole smartphone market, having had a few different handsets in my possession for just a few days. I spent some time getting to know the HTC Wildfire S and was pretty impressed with it. But I've no real experience of owning any other type of smartphone, so haven't really had anything to compare it to.

I've been told that the Samsung Galaxy S2 II is the dogs-danglies of mobile phones.
The posters on bus shelters certainly look impressive but to the uninitiated (like me) it was just another phone handset. What could be so great about this, compared to other phones?

The first thing to note is that the colours are amazing. The image is bright and vibrant and really sharp. It's like the difference between an LCD television and an LED TV. The screen size is a massive 4.2" (480x800) and apparently uses AMOLED - whatever it is, the result is an image that stays the bright and sharp, even in direct sunlight.

I've seen what's possible with a bit of hacking and some custom code with these handsets, but never really appreciated the quality of the hardware. It's slim and light, has excellent power saving features (after leaving it overnight with all peripherals enabled, it still had about 70% battery the next day). One nice touch is that the screen doesn't get smudged up with fingermarks (actually it does, but these are only visible when you turn the phone off, not when you're using it). The photos are a massive 8mp and uploaded automatically to my Google account - the clarity of the photos is pretty good though I can't help but think that 8mp is a bit much for photos to share over the 'net. The images are good, but not "professional camera" quality. And unless you're going to print the images (in which case, use a camera not a phone!) there's not much difference between sharing an 8mp and a 4mp image - except of course the massive file size. In fact, when I downloaded the photos from my Google account onto my laptop, I found that resizing by 50% (and even by 25%) resulted in the same great image still at a resolution that was bigger than a lot of computer screen sizes....

This is just a personal gripe (although if I was paying for the data connection rather than using my wi-fi connection it might be a different issue). Everything else about the Samsung Galaxy S2 II puts it in a league of it's own. An amazing (albeit expensive) bit of kit. I'd love to be able to keep this one! Suddenly the Samsung Galaxy S2 makes the HTC Wildfire S look like a "budget" smartphone.

HTC Wildfire review

2012-01-15T11:05:00.001Z

It's been nearly two weeks since the last post of 2011 and there's a reason for that - for the last few weeks, "real life" has just sort of got in the way. A few of us took a trip to an Irish Celidh (pronounced kay-lee) and sort-of skip-hopped-and danced the New Year in. On returning to Nerd Towers, we eagerly took all our new Xmas gadgets and gizmos round to the Nerd Cupboard to get to work on some new projects (and further advance - I'm not going to say finish - some old ones).
That's when it started to go wrong.

Real life (i.e. work) kicked in and suddenly all the spare nerding time was taken up with other things.
In fact, it's not all that bad; work involves investigating a number of different mobile handsets and writing some software to run on all of them. Some people do this as a hobby. If I were interested in mobile phones, I probably would too (some of the other club members are more enthusiastic about the phones than I and want to help out even though they're not getting paid for it!). But I'm getting paid to play about with some phones and write mobile websites and develop some iPhone and Android apps.

It's a pretty all-consuming task, so some of our earlier projects may have to wait for a week or two until this work is delivered.

Anyway, this leads onto the review of the phones.
The first phone I tried was a HTC Wildfire S

This was my first go with a smartphone. I've seen iPhones around and almost everyone at BuildBrighton has some kind of smartphone but I've never really seen the appeal in them myself. Anyway, putting that initial scepticism aside, I tried to evaluate this phone fairly.

Given it's the first phone I've tried, I was pretty impressed - but then I had nothing to compare it to. It's a nice, smart design. It feels pretty solid and the touch-sensitive screen responds well. I don't know if it's my fat greasy fingers, but the screen does get "smeary" very quickly though. Compared to my regular mobile phone, it is pretty heavy. But then again, this is a miniature computer, not an antique from the 90s.

I found that I manually have to put the phone into airplane mode to disable the wi-fi and bluetooth when I'm not using them, else the battery is flat if left overnight with everything enabled. I'm sure regular smartphone users know all the battery-saving tips already but I'm used to a phone that holds it's charge for up to 5 days at a time, not something that needs plugging in the next morning after using it!

All in all, the HTC Wildfire is a neat, compact smartphone. Probably ideal as a first, starter phone. The 5mp camera takes pretty decent photos and uploads them quickly and easily to my Google account. The 320x480 screen is big enough for most of the apps I tried and the display gives a bright, clear picture, while the black colour(s) are reassuringly dark (not greyed out like a cheap screen). But given I've nothing to compare it to, I don't really whether it's an amazing phone, or just a pretty good one!

That's it for another year....

2011-12-30T13:55:00.000Z

Plenty going on over the Xmas period but sadly not a lot of time to post about it, so look out for some updates in the New Year. Most excitingly, we've got a working version of an electronic Blood Bowl board game (well, one that you can download player data onto and it recognises which player you're moving, and can even perform some basic game mechanics).

We've also had quite a bit of interest in the microband miniature instruments so we're hoping to ramp up development on those in the new year too.

But all in all, over Xmas, we've eaten too much, made too little and blogged even less.
It's off to the other side of the country tomorrow for a New Year party so don't expect much for the next few days. In the meantime, have a great weekend, and a Happy New Year!

Blood Bowl Digital

2011-12-23T20:31:00.001Z

It's almost Xmas and time to down tools for a while and get all Christmas-y (despite what some people will tell you, tinsels and baubles still lead soldering irons and wire strippers in the Xmas stakes).
But before we wind down for the holiday season, we've been busy working on a website for our Digital Blood Bowl game board. We've called it Blood Bowl Digital.

A preview of the site can be found at http://www.nerdclub.co.uk/bloodbowl
You can create teams and build online rosters and assign attributes and skills to all your players.
The idea behind this is to have a gateway between an online team/games manager and a way of getting player data into the game board.

Hopefully - if we manage to keep on the "nice list" for the next few days - we'll have some spanky 20x4 character displays to actually demonstrate something come Boxing Day.....

Christmas clocks

2011-12-21T09:31:00.000Z

It's beginning to look a lot like Christmas...... everywhere you go. Ok, it's not. I don't know what it is this year - the doom and gloom peddled on all the news channels, the recession, austerity measures or what - but it just doesn't feel Christmassy.

Maybe it's just because the weather is still quite mild and all the spring bulbs are popping up.
But there's something particularly un-Christmassy this year. There are a few lights about and a few shops have made a half-hearted nod towards Xmas, but in the main - and talking to other people, I'm not the only one - we're still waiting to be hit full in the face with Christmas Cheer.

Which is probably why I've left it so late to get making Xmas gifts this year. Normally, come December 1st, the first little door on the advent calendar gets opened and it's straight into maker-mode, planning and making for everyone. But for some reason, this year things have been left a little late.

Back in November, I was helping Jason with his toy cars and lights controller. But since then, not much on the Xmas front. So last night I fired up the laser cutter and got designing some novelty clocks.
Most of the time was spent on the designing and drawing rather than the actual manufacture (which meant sending to the cutter, waiting a while, then some basic assembly afterwards) but the end results are quite pleasing:

[photo here]

Here are the design files should anyone fancy having a go -
Send the dxf to your laser cutter and carve out from your favourite coloured sheet of A4 acrylic (loaded in landscape).

Links to files:

To finish the clock off (and mostly, to hide the clock movement from behind) I cut out some shapes from a second colour and fitted them inside some of the cut-outs from the main clock face. By turning the clock over they could simply be held in place with some tape. I used double-sided tape, then stuck a piece of card over the whole arrangement, to keep the shapes from falling out once the clock was on the wall.

[photo of reverse]

Here's a slightly different clock, requiring a little more assembly.
At first I wasn't too sure about the design but the more I look at it, the more it grows on me. At first I thought about making the smaller coloured numbers as inserts (so they mounted flush with the surrounding shapes) but now I think I prefer them as relief shapes, sitting on top of the basic number shape.

[photo of second clock]

I think it's the clear acrylic ring that makes this clock work so well. It means positioning the numbers is relatively easy (it would have been a nightmare trying to stick just the very edges of a few numbers to the centre disc to hold it all together) but when the clock is on the wall, the final effect is quite striking!

Here are the design files if you fancy making one of these yourself:

this is the clear acrylic ring that some of the numbers mount onto

with some clever layout, you can get all the numbers onto a single A4 sheet

optional extra - inset characters for the numbers 2,4, 6, 8, 10 and 12

Links to files:

Lastly, here's a simpler version of the second clock that requires much less assembly, designed smaller to fit on a single A4 sheet of acrylic (or wood or whatever you're making your clocks out of!)

this clock has all the numbers connected to make a single solid piece

using the previous clock as a base, this clock can also have raised numbers placed on top of the base design, or you can cut the inset figures out and use different coloured acrylic (wood, whatever) to fill the gaps

Links to files:
http://www.nerdclub.co.uk/files/clock1_single_piece.dxf
http://www.nerdclub.co.uk/files/clock1_with_insets.dxf
http://www.nerdclub.co.uk/files/clock1_inset_numbers.dxf

Stripping paint from Blood Bowl miniatures

2011-12-18T13:48:00.000Z

Yesterday morning the postie delivered a whole team of (second-hand eBay bargain) Orcs to Nerd Towers and - as is normal with most things when something new arrives - we immediately dropped everything and spent some time getting all excited about the newest thing to be working on!

They're the "older" - 2nd or 3rd edition - style Orc team called The Orcland Raiders, not the American Football style team we've mentioned in a previous post, but they were (relatively) cheap with the added bonus of already being painted.

An orc team from Games Workshop. We're not expecting ours to be painted to anywhere near this standard!

None of us here have painted (or even shown any interest in) miniatures-based board games for nearly twenty years or more, so having a pre-painted team seemed like a good idea. Until they arrived....

The paint job on each miniature is ok-ish.
The basic colours are in the right places, and sometimes even the details are quite nicely done. But the colours seemed a bit "muddy" and not all the finer details were picked out in quite the way we'd have liked, so we've all decided to buy each other a set of Citadel paints (or similar acrylic-based colours) for Xmas and have a "getting-re-aquainted-with-painting-miniatures-again" session in the New Year.

Which means stripping all the miniatures we have and starting again.
We tried the usual tricks of Dettol, Fairy power spray and a whole heap of other detergents (there's no excuse in not keeping the place clean and tidy any more) but each was quite fiddly and required lots of soaking, scrubbing, re-soaking and so on. So we put on some rubber gloves and dropped the miniatures into some industrial strength paint and varnish remover. This is a white jelly-like substance, but the miniatures are ready for scrubbing after just 30 minutes soak.

The stripper causes the acrylic paint (and top coat varnish) to become a slimy coating over the entire model:

A quick scrub with a toothbrush and most of the paint comes off in just a minute or two under a running tap. Not all of the paint came off in one go, with some of the paint proving quite stubborn in the deepest of recesses. However, this does help show up some of the finer details of the model, which may have got lost under the previous paint job.

After each model is stripped, we leave to soak in a bottle of clean water, to remove any nasty chemical residue left by the paint stripper, then dab dry with a towel and leave to dry out for a few hours in front of the fire.

We're going to take reference photos of all our stripped models, so that we can see where the finer details are after we've splodged paint all over them - it's very easy to miss the little bits and bobs, but it's these tiny examples of attention to detail that make the miniatures so impressive in the first instance - it'd be a shame not to show off the exquisite modelling to its best, which means painting and highlighting these parts that could otherwise go un-noticed.

Serial character LCD driver with Flash eeprom

2011-12-14T22:27:00.001Z

No sooner had we got our serial character LCD display working than we were moving on to the next stage of the project - reading text from an Atmel AT45DB041D Flash eeprom chip to decide what to display on the screen.

We're already familiar with these chips, from our multiple servo controller board from back in May.
The idea is to store strings of text in these chips, then simply set a pointer (to tell the PIC where to start reading from) and get the microcontroller to read the text back and display it on the LCD.

We did look at I2C and other serial eeprom alternatives (at £1.20 each these Atmel chips are quite expensive for eeprom and at 4Mbit, are much bigger than we're ever going to need!) but most other (non-Flash) chips run at 100kz, or 400khz at best (yes, that's kilohertz, not Mhz). This will obviously make drawing text on the LCD run really slowly which is something we're keen to avoid.

These little Atmels can work up to 20Mhz. Which by happy coincidence is how fast the master chip will be running anyway, so hopefully we won't lose too much time reading and displaying text to the screen.

We wired our Flash eeprom chip up to PORTD on an 18F4550 (using RD.0-RD.3) and hacked some code together to read and write data to/from the chip. Amazingly, it worked first time!

AllDigital
Config PORTC = Output
Config PORTD = Output
Config PORTD.2 = Input

configuration:
       Symbol enablepin = PORTC.0
       Symbol clockpin = PORTC.1
       Symbol datapin = PORTC.2
      
declarations:
       Dim tmp As Byte
       Dim i As Byte
       Dim lcdi As Byte
       Dim lcdbyte As Byte
       Dim lcdbytetosend As Byte
       Dim rs As Bit
       Dim flag As Byte
       Dim mask As Byte
       Dim pageaddr As Word
       Dim byteaddr As Byte
       Dim byteswritten As Word
       Dim bytesread As Word
       Dim streamwrite As Bit
       Dim streamread As Bit
      
init:
       WaitMs 200
      
       Define SPI_CS_REG = PORTD
       Define SPI_CS_BIT = 0
       Define SPI_SCK_REG = PORTD
       Define SPI_SCK_BIT = 1
       Define SPI_SDI_REG = PORTD
       Define SPI_SDI_BIT = 2
       Define SPI_SDO_REG = PORTD
       Define SPI_SDO_BIT = 3
       SPIPrepare

       Gosub initialiselcd
       Gosub initialiseeeprom
      
       pageaddr = 1
       byteaddr = 0
       Gosub readanddisplaydata
             
loop:
      
       pageaddr = 1
       Gosub readanddisplaydata
       WaitMs 4000
       lcdbytetosend = 0x01  'clear screen
       Gosub writelcdcommand
      
       byteaddr = byteaddr + 16
       If byteaddr > 60 Then byteaddr = 0
      
       WaitMs 1000

Goto loop
End                                               

writelcdnibble:
       Low enablepin
       Low clockpin
       If rs = 1 Then High datapin Else Low datapin

       Gosub toggleclockpin
      
       'shift in 4 bits
       mask = 8
       For lcdi = 1 To 4
              flag = lcdbyte And mask
              If flag = 0 Then Low datapin Else High datapin
              Gosub toggleclockpin
              mask = ShiftRight(mask, 1)
       Next lcdi
             
       'now strobe the clock one more time because ST+SC are tied
       Gosub toggleclockpin

       'toggle the enable pin to "flush" the data into the lcd
       Low datapin
       High enablepin
       Low enablepin
      
Return                                            

toggleclockpin:
       'toggle the clock pin
       High clockpin
       Low clockpin
Return                                            

writelcddata:
       rs = 1
       Gosub senddatatolcd
Return                                            

writelcdcommand:
       rs = 0
       Gosub senddatatolcd
Return                                            

senddatatolcd:
       lcdbyte = ShiftRight(lcdbytetosend, 4)
       Gosub writelcdnibble
       lcdbyte = lcdbytetosend And 15
       Gosub writelcdnibble
Return                                            
      
initialiselcd:
       For i = 1 To 3
              WaitMs 50
              lcdbytetosend = 0x20
              Gosub writelcdcommand
       Next i
      
       WaitMs 50
       lcdbytetosend = 0x28  '4 bits, 2 lines, 5x7 font
       Gosub writelcdcommand
      
       WaitMs 50
       lcdbytetosend = 0x0c  'display on, no cursors
       Gosub writelcdcommand
      
       WaitMs 50
       lcdbytetosend = 0x06  'entry mode auto-increment
       Gosub writelcdcommand
      
       WaitMs 50
       lcdbytetosend = 0x01  'clear screen
       Gosub writelcdcommand
      
       'send a space character to the display to test
       WaitMs 50
       lcdbytetosend = 32
       Gosub writelcddata

Return                                            

initialiseeeprom:
       Gosub set256pagesize
       Gosub chiperase
      
       pageaddr = 1
       byteaddr = 0
       WaitMs 100
      
       Gosub startstreamwrite
       For i = 0 To 63
              tmp = LookUp("Blood Bowl      Griff Oberwald  Varag Ghoulchew The Mighty Zug  "), i
              SPISend tmp
       Next i
       Gosub endstreamwrite
      
Return                                            

startstreamread:
       streamread = 1
       SPICSOn
       SPISend 0xe8  'stream read (legacy mode)
       SPISend pageaddr.HB
       SPISend pageaddr.LB
       SPISend byteaddr
       SPISend 0x00  'four don't care bytes
       SPISend 0x00
       SPISend 0x00
       SPISend 0x00
       bytesread = 0
Return                                            

endstreamread:
       SPICSOff
       streamread = 0
Return                                            

startstreamwrite:
       SPICSOff
       SPICSOn
       SPISend 0x82  '0x82  'write THROUGH buffer1 command
       SPISend pageaddr.HB  '5 don't care bits + 11 address bits
       SPISend pageaddr.LB  'is the same as sending page address as hb/lb
       SPISend byteaddr  'last eight bits are buffer start byte
       byteswritten = 0
       streamwrite = 1
       WaitMs 5
Return                                            

endstreamwrite:
       SPICSOff  'this causes the flash buffer to automatically get written to memory
       WaitMs 5
       streamwrite = 0
Return                                            

set256pagesize:
       SPICSOn
       SPISend 0x3d
       SPISend 0x2a
       SPISend 0x80
       SPISend 0xa6
       SPICSOff
Return                                            

chiperase:
       SPICSOn
       SPISend 0xc7
       SPISend 0x94
       SPISend 0x80
       SPISend 0x9a
       SPICSOff
       WaitMs 100
Return                                            

readanddisplaydata:
       lcdbytetosend = 0x01  'clear screen
       Gosub writelcdcommand

       Gosub startstreamread
       For i = 1 To 16
              SPIReceive lcdbytetosend
              'for testing
              tmp = byteaddr + i
              Write tmp, lcdbytetosend
              Gosub writelcddata
       Next i
       Gosub endstreamread
Return                                            

Note that in the initialiseeeprom routine we actually blank the Flash chip and write some data to it. In the final version of this code, we'll transfer data to Flash eeprom via a USB connection, but read it back just the same. Although this is just a basic test, it proves the idea of us storing character/player information in eeprom and calling it up and displaying it on a character-based LCD. All with just a few extra wires from the master microcontroller.

[photo or video goes here]

Note that in this example we're using a rather tiny 2x16 character LCD (because we had some hanging around). We've got our fingers crossed that Santa will bring some larger 4x20 displays, like the one below which uses the same Hitachi 44780 controller chip, so the code should work for both.

With four lines of twenty characters, we can split player names over two lines (to allow really long forenames/surnames) and write player stats (MA, ST, AG, AV) on a single line - each stat (0-9) would take up four characters (XX-digit-space) so the output could look something like

 GRIFF
 OBERWALD

 MA4 ST5 AG8 AV9

Or, if we can get the player's name on a single line, something like:

 GRIFF OBERWALD

 MA   ST   AG   AV  
  4    5    8    9  

Serial-to-parallel LCD display driver

2011-12-14T21:59:00.003Z

Amazingly we managed to get a working serial character LCD in under an hour today!
Just followed the schematics at http://embedded-lab.com/blog/?p=30 and converted the code example they gave into Oshonsoft Basic. Fired it up and there we go - a blinking "Hello World!" message using just three pins on the microcontroller.

The only real issue we had was that the contrast isn't brilliant; instead of a 10K linear pot, we've gone and used the first potentiometer that was to hand (a 1M logarithmic pot!)

If, like us here at Nerd Towers, you're an Oshonsoft fan, here's the code listing to get everything working:

AllDigital
Config PORTC = Output

configuration:
       Symbol enablepin = PORTC.0
       Symbol clockpin = PORTC.1
       Symbol datapin = PORTC.2
      
declarations:
       Dim i As Byte
       Dim lcdi As Byte
       Dim lcdbyte As Byte
       Dim lcdbytetosend As Byte
       Dim rs As Bit
       Dim flag As Byte
       Dim mask As Byte
      
init:
       Gosub initialiselcd
      
loop:
       lcdbytetosend = 32
       Gosub writelcddata
       lcdbytetosend = "H"
       Gosub writelcddata
       lcdbytetosend = "e"
       Gosub writelcddata
       lcdbytetosend = "l"
       Gosub writelcddata
       lcdbytetosend = "l"
       Gosub writelcddata
       lcdbytetosend = "o"
       Gosub writelcddata
       lcdbytetosend = 32
       Gosub writelcddata
       lcdbytetosend = "W"
       Gosub writelcddata
       lcdbytetosend = "o"
       Gosub writelcddata
       lcdbytetosend = "r"
       Gosub writelcddata
       lcdbytetosend = "l"
       Gosub writelcddata
       lcdbytetosend = "d"
       Gosub writelcddata
       lcdbytetosend = "!"
       Gosub writelcddata
      
       WaitMs 4000
       lcdbytetosend = 0x01  'clear screen
       Gosub writelcdcommand
      
       WaitMs 2000

Goto loop
End

writelcdnibble:
       Low enablepin
       Low clockpin
       If rs = 1 Then High datapin Else Low datapin

       Gosub toggleclockpin
      
       'shift in 4 bits
       mask = 8
       For lcdi = 1 To 4
              flag = lcdbyte And mask
              If flag = 0 Then Low datapin Else High datapin
              Gosub toggleclockpin
              mask = ShiftRight(mask, 1)
       Next lcdi
             
       'now strobe the clock one more time because ST+SC are tied
       Gosub toggleclockpin

       'toggle the enable pin to "flush" the data into the lcd
       Low datapin
       High enablepin
       Low enablepin
      
Return                                            


toggleclockpin:
       'toggle the clock pin
       High clockpin
       Low clockpin
Return                                            


writelcddata:
       rs = 1
       Gosub senddata
Return                                            


writelcdcommand:
       rs = 0
       Gosub senddata
Return                                          


senddata:
       lcdbyte = ShiftRight(lcdbytetosend, 4)
       Gosub writelcdnibble
       lcdbyte = lcdbytetosend And 15
       Gosub writelcdnibble
Return


initialiselcd:
       For i = 1 To 3
              WaitMs 50
              lcdbytetosend = 0x20
              Gosub writelcdcommand
       Next i
      
       WaitMs 50
       lcdbytetosend = 0x28  '4 bits, 2 lines, 5x7 font
       Gosub writelcdcommand
      
       WaitMs 50
       lcdbytetosend = 0x0c  'display on, no cursors
       Gosub writelcdcommand
      
       WaitMs 50
       lcdbytetosend = 0x06  'entry mode auto-increment
       Gosub writelcdcommand
      
       WaitMs 50
       lcdbytetosend = 0x01  'clear screen
       Gosub writelcdcommand
      
Return                                            

Back from Berlin

2011-12-14T09:58:00.000Z

We've not really spoken much about our few days away in Berlin. Neither online, nor between ourselves. Which is a shame because we were really excited about going there and visiting a few of the different hackspaces. The problem was that the Kreuzberg region of Berlin where we were staying was pretty rough. And the so-called "hostel" we'd be invited to was little more than a doss-house squat.

After just a few days of living in squalor we changed our flights and came home. We never got to see any of the different 'spaces we'd planned on visiting scattered around the city (we'd arranged to visit the betahaus the morning after we'd arrived, which is also in Kreuzberg but got lost trying to find it!)

Graffitti is everywhere in Berlin - and especially so in Kruezberg. There are very few pictures or pieces of artwork (as shown in this photo) mostly it's mindless scrawlings, tags drawn in marker pen, and political slogans written in English.

There's a difference between "post-punk-industrial-style" and just filthy squalor. Coupled with a three-day "festival" during which thumping drum-n-bass played from midnight 'til around 10am (meaning no-one slept for the duration of the trip) we'd had enough after just a few days! Needless to say, it'll be some time before we endure another EasyJet flight to Germany's capital city!

Serial-to-parallel character LCD communication

2011-12-14T09:41:00.000Z

We're getting close to hooking up all the component parts and testing our Blood Bowl game board. The master chip uses UART/serial to talk to the slave, so we've no easy means of talking to the master chip (in a lot of our 18F-based development we usually hook the chip up to a PC using USB to read data directly from the registers - even if USB won't be used in the final design - but this won't be possible in this case, since we can't run UART and USB together)

Since our game board will include two LCD character displays, we figured we could hook those up and use them to write out debug information during testing. In an attempt to keep as many pins free on our master chip, we're looking at converting an HD44780 parallel display into a serial LCD as in this article:
http://embedded-lab.com/blog/?p=30

So before we go plugging everything together and spending hours wondering why things aren't quite working properly, we're going to make a separate project which concentrates on just displaying the information we want on a 3-wire serial LCD (in our final project we'll be using two 20x4 character displays, one green, one blue. But they're on Santa's Xmas Wishlist and not likely to arrive before the big day, so we'll try things out with an old 2x16 that's lying around in the toolbox).

Blood Bowl miniatures

2011-12-14T00:16:00.001Z

Back in the late 80s, Blood Bowl was all the rage, even with the cool kids who didn't even know that it had anything to do with Warhammer Fantasy miniatures, nor that Dungeons & Dragons was a game and not just an animated cartoon series on kids' TV.

Sadly none of our miniatures survived many house moves over the years (we've been nerds for a long time) - and maddeningly, the earlier, rarer pieces are commanding quite a price on eBay these days! Rather than pay over £30 for a team of original pieces, we've been looking for something a bit cheaper....

The original Blood Bowl teams were heavily armoured, with each character having lots of spikes, pads, over-sized shoulder pads and the like. The miniatures in the different teams looked very much like their Warhammer fantasy war-gaming counterparts (only without weapons).

The original Games Workshop Blood Bowl miniatures followed in this line.
But for us, Blood Bowl is first and foremost a strategy game of fantasy football that happens to include goblins and orcs and elves and other fantasy races. It's the game of football that makes the game fun and interesting to play, not the creatures that make up the different teams.

So it was really quite refreshing to find a team that were not only relatively cheap to buy (albeit second-hand) but they look more like a football team than a murdering crowd of goblins from Dungeons & Dragons:

Of course, for testing our electronic game board we can use copper discs (two pence pieces are the perfect size) but the whole thing would look much more like a board game with the correct pieces on it! Unfortunately it's that time of year again where buying stuff willy-nilly off the internet is out of the question, as friends and family members are on the look-out for gift ideas; so we'll just have to sit tight and see what Santa brings in a few weeks. In the meantime, there's the board to finish so we'll post some more updates here soon......

Blood Bowl electronic board - slave board complete

2011-12-13T23:49:00.003Z

Here's a quick update on our slave board for the Blood Bowl electronic board

The top board is underside of the slave board, which is basically a 40-pin 16F877A (any 40-pin PIC with hardware UART/USART would do, even the 18F4550 - but you'd be spending a lot more than necessary on your slave chip and not using most of the peripherals that you'd paid for! We just used one of the many 16F chips we had knocking around, not necessarily the cheapest/best fit for the job. One of the cheaper 16Fs from Farnell is the 16F1939 available for about £2.80 per unit)

The bottom board shows an arrangement of four 1x4 board modules (ok, it's actually 2 of our earlier 2x4 boards but the wiring is exactly the same!) We've wired them so that the two boards vertically share the same "row" signal wire. So both the boards on the left will come "live" at the same time, when row1 is sent high by the master board. Then the boards on the right will both come on at the same time. The two orange wires are the "row" signal wires and will connect to the master controller. The grey wires (to the left) will connect to the inputs on the slave controller.

Although not immediately obvious from the nasty photo (iPad cameras are about as good as cheap HP ones in low light) the slave board is simply a PIC microcontroller, a crystal, 4 wires (1 power, 1 ground, 1 serial TX, 1 serial trigger/handshaking line on the RX pin) and all the remaining digital i/o pins pulled to ground through some 100K SMT resistors.

Blood Bowl board game slave board

2011-12-13T19:59:00.000Z

Our intelligent Blood Bowl game board consists of two PIC micros which talk to each other via serial (during testing we're using 9600 baud but will crank this up for the final version). The slave board is simply a 40-pin 16F877A with pull-down resistors on all the digital i/o pins.

To allow for maximum flexibility, we're designing this slave board to accept as wide a range of PIC microcontrollers as possible, including some of the 18F series chips (if you have some hanging around from other projects, why not use them instead of buying in new?) Allowing for the power, ground, TX and RX pins (which are in the same place in the 40-pin 16F and 18F chips), as well as the useless Vusb pin on the 18F (useless in this case since we can't use UART and USB together) and the handshaking line we've got a maximum of 30 input pins (we could use the RX pin for handshaking, but for now we'll keep that clear in case we can come up with a use for it in future). In the diagram above, all available i/o pins have been taken out to a set of SMT (1206 sized) resistor pads, and all the resistors are tied to ground (making them pull-down resistors on each input).

30 inputs is an awkward number to work with since each board module is 4 squares in size the maximum number of inputs we can use is 28 (4*7=28). So we've got two free input pins on the slave board should the need arise, as we develop the concept further.

Slave Board

Intelligent board game (Blood Bowl) development

2011-12-03T15:46:00.001Z

Here are some photos of the latest board game development;
although we're working on a Blood Bowl clone, the same technology could - in theory - be used for a large number of games, with different board sizes. To date, we've settled on a 4-square module and will make our board game(s) up from this/these.

These photos are from our 4x2 boards (earlier design) but the principles work the same for both.
On the sides of each playing square (N,S,E and W) we drilled a 1mm hole and soldered some pcb studs

The studs are slightly raised on the playing surface of the game board. This isn't as nasty as it sounds - for our Blood Bowl game, it means we can add some "flocking" or similar covering but still get the playing pieces to make a good contact with the pins.

stupid cheap HP camera - even in "macro mode" it doesn't quite know what to focus on!

The plan is to weight our playing piece bases with a small copper disk (something like a 2 pence piece would be ideal, only we don't want to get thrown in prison for "defacing a coin of the realm" or whatever the punishment is these days!). Placing these on the playing side of the board bridges the two connections between the "rows" output pin on the master controller and the "columns" input pin on the slave - so when the slave is asked "which inputs are high/low" this can be used to work out which squares have playing pieces on them.

once again, a nice focussing job by our little HP camera

The tracking of which playing piece is on which square will be done by the master IC. For these early prototypes, we're more concerned about proving the concept of tracking which piece is being lifted/replaced to/from the board.

Creating the playing squares for an intelligent board game board

2011-12-01T23:31:00.001Z

While toner-transferring and etching our game board "modules" something became obvious - though it's not something we'd thought of when designing our PCBs. The photo below shows our game board etched onto a piece of eurocard sized (160mm x 100mm) copper-clad board

While trimming to size, we realised that the bit cut off the bottom was almost exactly the right size for a single row of 4 playing squares (the printed module above shows a 2x4 grid of playing squares). It then occurred to us that there's no real reason why we couldn't create modules that were 1x4 instead of 2x4.

After all, the top row still has to be connected to the bottom row using a wire jumper/via even when they are drawn/etched on the same piece of board. So here's the new PCB layout for four playing squares at a time:

Since the spacing of the playing squares is 30mm (standard Blood Bowl size) the PCB is also 30mm high (with the playing squares pretty much in the middle of each "strip" of 1x4 squares).

If you want smaller playing squares, simply resize the whole PCB. The overall size will shrink to match the size of each playing square so they should still be able to be cut to size and placed side-by-side, without affecting the spacing between playing squares.

4x1 Board Piece

As you can see, they line up perfectly for connecting horizontally once etched and cut to size:

A little bit of multi-core wire or maybe even some gloopy solder should connect the two boards, edge-to-edge.

Testing multi-plexed LEDs for word clock

2011-12-01T23:27:00.001Z

Having ditched the impossible-to-debug charlie-plexing idea, we've made up a board which simply places LEDs in columns and rows.

We're going to drive the "rows" through a shift-register (to allow more than 20mA current to be sourced) and sink them through a number of ULN2803A darlington arrays (since sinking directly to the microcontroller pin would only allow up to 20mA per row which could make a full row of lit-up LEDs appear quite dim).

Before we get clever with the sinking and sourcing, we needed to make sure that our array of LEDs worked - and to test it we simply connected the +ve and -ve terminals of a 3V coin-cell battery to the different lines on the PCB.

By touching the exposed wire ends to the positive and negative terminals of a 3V battery, we were able to confirm that every LED in the array worked individually of the others.

Serial/UART communication between two PICs (18F and 16F)

2011-11-30T23:53:00.001Z

It's taken a long time and a lot of different approaches to get even simple serial communication between two PICs working. Perhaps hampered a little by using two different PICs (a 16F and an 18F series chip) but that really shouldn't make any difference. Serial/UART communication shouldn't be platform dependent!

We've tried serial/UART, SPI, I2C and even bit-banging and each time got different (non-working) results. It's too much to go into in this blog post, so we're just going to describe how we actually got a working prototype:

The first thing to note is that although we're using one of our favoured 18F4550 PICs, we couldn't use the USB and UART together. So for this experiment, we're reading the data back off our 18F (master) chip via serial, using the excellent PICKit2 programmer and software.

In our first (failed) attempt at creating pic-to-pic communication, we had our 16F (slave) device monitoring it's input pins and simply broadcasting the results as an 8-byte message over UART. The idea was for the 18F (master) chip to read this serial stream at intervals, find the start of the message and decode the rest of it, so that it knows the state of the slave chip.

In theory this sounds fine. In practice, sending more than about 4 bytes to the 18F (master) chip caused it to lock up on the Hserin command. We even tried connecting the PICKit2 to the RX pin on the 18F and removed our slave chip altogether. Our tests confirmed the same thing happening - if we sent one or two bytes at a time to the 18F from the PICKit2 terminal, it successfully received them and sent a response message back. If we sent more than about five bytes at a time, the 18F simply stopped responding - apparently locking up at the point where it reads in the serial data
(we proved this by switching an LED on just before the Hserin command, and turning it off again immediately after).

So it appears that we have a set-up whereby we can receive data from our slave, one byte at a time, but the master can't simply "dip in" to a serial stream being "broadcast" by the slave. After reading through the datasheet, it seems that the 18F has only a two (or was it four) byte buffer so blasting more bytes into the buffer than it can handle is causing some sort of buffer overrun error.

We need some way of getting the master chip to ask for data, one byte at a time.
This is what we came up with:

The master chip sends a pin high then requests a byte from the serial buffer.
The slave chip monitors the state of the "handshaking" line. When the line goes high, and the previous line state is low, this represents a request from the master, so send one byte.
Because we're using hardware UART on the master chip, after the line goes high, the code waits until a byte has arrived in the serial buffer. Because the slave only sends a byte on a low-to-high transition on the handshaking pin, we don't have to worry about buffer under-runs or errors in the master chip.

Slave code

'4Mhz external clock
Define CONF_WORD = 0x3f31
Define CLOCK_FREQUENCY = 4

AllDigital
Config PORTB = Input
Config PORTD = Input
Config PORTC = Input
Config PORTA = Input

declarations:
       Dim linestate As Bit
       Dim lastlinestate As Bit
      
       Dim a1 As Byte
       Dim a2 As Byte
       Dim a3 As Byte
       Dim a4 As Byte
       Dim a5 As Byte
       Dim xorval As Byte
       Dim bytecounter As Byte
             
init:
       WaitMs 50
       Hseropen 9600
       WaitMs 50
             
       linestate = 0
       lastlinestate = 0
       bytecounter = 1
      
loop:
       'all the slave does is read a whole load of input pins
       'and write the response back to the master. The master chip
       'will decide which "row" is live, this chip just takes all
       'the "column" data and sends it back to the master.
      
       'RA0-5
       'RB1-7
       'RC0-5 (6&7 are TX/RX)
       'RD0-7
       'RE0-2
             
       'this should give us 6+7+6+8+3 = 30 inputs
       a1 = PORTA And 63  '(mask off bits 7+6)
       a2 = PORTB And 254 '(make off bit 0, handshake line)
       a3 = PORTC And 63
       a4 = PORTD
       a5 = PORTE And 7
                    
       'now stream the values as a response back to the slave
       'all messages begin 255,255 (since this sequence is not
       'possible in the input stream because we bitmask bytes 1,3,5)
      
       linestate = PORTB.0
       If linestate = 1 And lastlinestate = 0 Then
              'the host chip has asked for another byte of data
             
              'create the checksum value
              xorval = 0
              xorval = xorval Xor a1
              xorval = xorval Xor a2
              xorval = xorval Xor a3
              xorval = xorval Xor a4
              xorval = xorval Xor a5
              xorval = xorval And 127

              'decide which byte of the message to send
              '(the host has to ask for each message eight times for all 8 bytes)
              Select Case bytecounter
                     Case 1
                     Hserout 255
                     Case 2
                     Hserout 255
                     Case 3
                     Hserout a1
                     Case 4
                     Hserout a2
                     Case 5
                     Hserout a3
                     Case 6
                     Hserout a4
                     Case 7
                     Hserout a5
                     Case 8
                     Hserout xorval
                     bytecounter = 0
              EndSelect
             
              bytecounter = bytecounter + 1
       Endif
       lastlinestate = linestate
      
Goto loop
End                                               

Master code

AllDigital

declarations:
       Dim a1 As Byte
       Dim a2 As Byte
       Symbol lineshake = PORTA.0
       Config PORTA.0 = Output
      
init:
       Low PORTA.0
       WaitMs 200
       Hseropen 9600
       WaitMs 200
      
loop:

       Gosub getnextbyte
       'two 255 = start of message
       Hserout 255
       Hserout 255
       Hserout a1
             
Goto loop
End                                               

getnextbyte:
       'to get the next byte, we send the lineshaking
       'line high - this tells the slave to "release"
       'another byte. Once we have this byte, we drive
       'the lineshaking pin low to say we're done
       High lineshake
       Hserin a1
       Low lineshake
      
Return                                            

After connecting up the slave to the master (the TX pin of the slave into the RX pin of the master, and RA.0 on the master to RB.0 on the slave) we did actually start receiving intelligible data from the master. So it looks like we've (finally) cracked pic-to-pic communication over serial.

It's probably a bit slower than it needs to be (since the master has to "poll" each byte from the slave) but it's fast enough for what we want - and once we crank the baud rate up from 9600 to about 57600, or even 115200, it should be more than quick enough to scan an entire game board (of not more than 16 x 28 = 448 squares) at a reasonable rate.

Communication between two PIC microcontrollers

2011-11-30T23:46:00.001Z

We're having a bit of a nightmare getting two PICs to talk to each other.

The master is an 18F4550 which will do most of the grunt work and talks to the PC host via USB (we use Oshonsoft's excellent USB/HID library for our USB work).

The slave is a 16F877A (no reason for this particular model other than we had quite a few of these lying around). This basic idea is that the 16F reads 28 input pins and writes a four-byte value out to the serial port.

The master periodically polls the slave, reading the serial data. It looks for two specific bytes which signify the start of the message, then reads in the next four bytes that make up the message (the fifth byte is the XOR sum of the previous four bytes so we have some sort of checksum).

The problem is that while we can check the 16F using the PICKit2 UART tool - and it successfully reads the message being "broadcast" by the slave - when we try to read data using the hardware UART port on the 18F master chip, the USB comms lock up and our PC app stops working.

It seems that we aren't the first people to run into this sort of problem and there are lots of queries across the 'net asking for help with USB and serial comms together. Here's just one example:

http://www.3dreplicators.com/cgi-bin/cblog/index.php?/archives/461-Fixing-a-software-problem-with-hardware.html

So it looks like USB and UART together isn't going to work.

Which is a bit of a bummer.

Also, like the author of the article above, we were also hoping to use the timer1 interrupt to keep a simple clock running, which makes software-based bit-banging and no-go either. Getting a PIC to work as an I2C slave looks quite complicated too, so we're running out of ideas.

The only thing left for us to try is getting two PICs talking to either other using SPI hardware on both the master and slave chips.

Hopefully this will work with both USB and timer1 interrupts running on the master chip. But until we try, we're not going to know......

PIC16F877A resetting

2011-11-30T22:09:00.001Z

This is just a general post to remind anyone like me who often forgets the basics and spends far too long trying to find faults with hardware/firmware that just aren't there.Although in my case, it's specific to my 18F877A, the same rules apply to 16F628A chips and pretty much any of the 16F range.

Here's why I'm so stupid......

I've been working a lot lately with 18F series chips.

These are great because they have loads of different "fuses" which let you set up the chip in a particular way. One of the fuses on the 18F range allows you to reclaim pin one - the MCLR/PGV (programming voltage) pin and set it to an input. I do this with pretty much all my 18F chips.

So when I came back to the old 16F series chips (the 16F877A is an old favourite that first got me interested in PIC programming) I completely forgot that you need to apply 5v to the MCLR pin to stop the chip from resetting (pulling this pin low causes the PIC to reset completely).

So during testing, while trying to read the serial message(s) being "broadcast" from my 16F chip, I kept getting blackouts - periods when the serial stream would stop. Wiggle a few wires around on the breadboard and it would come back to life. For a little while.

Everything was pointing at a hardware problem - either a dodgy wire or a loose crystal or something. I re-wrote the firmware on both the slave and master chips, stripping each down to just the bare essentials, and used a really handy tool in the PICKit2 software to monitor the serial stream

You can connect anything that uses serial comms, and set the baud rate to any of the common bps values - 1200, 2400, 4800, 9600, 19200, 38400 etc as well as your own custom baud rate (ideal for debugging MIDI devices at 31250)

Anyway, after connecting everything up, setting it running and not touching a thing, the 16F would periodically shut down. I stripped out all the wires, rewired the board with a brand new set of jumper wires, put LEDs on all kinds of output pins and so on. I checked and double-checked the fuses, made sure the watchdog timer was disabled (and even tried enabling it and littering the firmware with watchdog reset commands) and checked the brown-out option wasn't selected. I even put a few different capacitors on the power rail of the 16F, just in case the input voltage was getting a bit wobbly.

The whole thing was suddenly a lot more complicated than any other PIC project I'd ever worked on and still it kept resetting.....

.... that's when I remembered that pin one (MCLR) has to be pulled high to stop the, erm, PIC from resetting all the time. Bugger.

It was as simple as that!
A single wire from pin one to 5V and everything worked beautifully.
If I had remembered about the MCLR pin earlier, instead of assuming it was always set to behave as an in input pin I think I'd have saved myself about two hours this evening.

Hopefully this post will help others in future to avoid wasting a similar amount of time on something so trivial!

Electronic board game - Blood Bowl clone

2011-11-30T19:58:00.001Z

Some interesting developments over the last few evenings as we've put together all kinds of ideas for an intelligent board for a board game (like, our old favourite Blood Bowl).
Our original proposal - based on freeing up as many pins as possible from two 40-pin PIC microcontrollers - was to allow for up to 600 squares, or a grid of 20x30

To allow for as much flexibility as possible, while at the same time making it relatively easy to understand, we've decided on a modular approach. Our board game will actually be made up of a grid of 4x2 "blocks" which can then be wired together in any arrangement. It means we've lost the flexibility of really wacky board layouts (although using the same technology it should be possible to create one-off boards with pretty much any layout as required) but does mean that we can simplify making boards of different dimensions.
(it also means that anyone who buys their copper boards in eurocard 100mmx160mm size can still make a board game, using a "patchwork" of smaller boards)

4x2 Board Piece

Each playing square in this board is marked out by a "cross" shape on the board. Small through-hole studs are soldered to this underside, so that on the playing side of the board, a small contact point is visible on the playing surface. Each playing piece has a conductive base (a copper coin glued to the bottom would suffice!) and when placed over the four points of a cross, makes a connection between the top and right contacts and the bottom/left contacts.

Using the above layout, we can place these pieces side-by-side and join the edges, while connecting each group of top/right contacts together using short pieces of (insulated) wire

Using this approach, we've designed our Blood Bowl board.
It's not quite 30 x 20, but we found that vertically connecting 7 "rows" of 4 contacts means for each row we can read back up to 28 lines of "column" data. By placing four of these smaller boards side-by-side, our board size is 28 x 16 playing squares. Not a bad compromise and certainly a sizeable playing area for a lot of different board games.

So what does it look like? In short, a nightmare!

As you can see, each smaller board is connected to the board horizontally next to it (the traces were deliberately lined up to make this bit quite easy). Every 7 vertical rows of contacts are connected via wire traces (shown in this diagram by different coloured bars) and each group of these 7x4 = 28 contacts is then connected to the slave microcontroller via a short wire (the connection points for these wires are circled in a matching colour).

There are 16 wire connect points - these go to the master PIC. The 28 traces from the bottom/left sets of contact points are connected to the slave. By flashing one of the 16 wires at a time, and reading the input values on the 28 inputs, we should be able to work out which set(s) of contacts are being bridged by a playing piece on the board.

That's the theory anyway.......

PICKit2 clone programmer alternatives

2011-11-30T00:12:00.001Z

Something has happened to our faithful old PIC programmer - it was (was being the key word) a PICKit2 clone, iCP01 from piccircuit.com and had worked tirelessly for about three years.
But for some reason, it has suddenly stopped working.
No puff of smoke or funny smell - it just stopped working.

At first it had problems recognising a 16F877A DIP, so - as we always do before wiggling wires - it was removed from the USB port (removing any power from the breadboard) and then when it was plugged in there was no "bing-bong" or any indication that the PC had recognised the USB device.

That's it. Despite stripping off the yellow shrink wrap and inspecting the components on the board (nothing seems to have blown and there's continuity across the connections where you'd expect there to be) the device simply refuses to work.

The PICKit2 software doesn't even recognise that the device is plugged in, and Device Manager fails to identify it too. So it's officially dead. The question is, do we get another one (they're great little programmers and really fast too) or try something else?

Multi-plexing LEDs for word clock

2011-11-29T12:35:00.001Z

Having failed miserably at debugging our charlie-plexed LED array we've decided to stick to the simpler approach of using multi-plexing.

There's a subtle difference, but since we're already getting down and dirty with multi-plexing for inputs on a board game it made sense to use this same approach for outputs/LEDs. The main difference is that we'll be using a pin for each row and a pin for each column (10 rows x 9 columns = 10+9 = 19 pins).
If we move away from the 16F628A (with 18 pins) and go far a larger chip, with more i/o pins, then multi-plexing gives us a simpler, easier-to-debug solution.

With this in mind, we set about creating a new PCB to use multi-plexing.
So far we've just put a load of LEDs into a grid formation - the actual controller board will be a separate PCB mounted onto the back:

Uln2803a Driven LED array

Here's a photo of the completed board, populated with LEDs, ready for testing.

Unlike last time, testing LEDs is quite straight-forward; and already we've found some potential problems; a lot of the LEDs are re-used from the old board and by connecting a 3v coin-cell battery straight across the anode and cathode of each LED, we've found about half-a-dozen that refuse to light up.

Whether these were damaged during removal, or never actually worked on the original board, we'll never know. But at least we've an explanation as to why the charlie-plexed board didn't work. Sort of.

Anyway, we're going to pop out those duds and test each individual LED on this board before even considering wiring it up to the rest of the project!

The nerds are off to Berlin!

2011-11-28T16:21:00.001Z

Ok, it's only for a week or so, but we've confirmed our tickets for early next month (December). And a quick look on hackerspaces.org tells us that there are no less than 12 hackerspaces, in Berlin alone!
We won't have time to visit all of them (unless we go to three different ones on each day we have free) so we'll have to concentrate on English-speaking spaces for now (a few of us can speak French to an ok level, but German is a whole new language!)

Woo-hoo, Europe here we come!

Using 2 PIC micros for a huge input array

2011-11-27T22:03:00.001Z

After spending some time thinking about a large board game input device - which simply tracks the position of each piece by comparing the current board state to a previously known state - we've decided that a multi-plexed approach will probably be the easiest to implement.

The problem with a multi-plexed approach is that whatever size grid is used determines the number of pins needed (so a 10 x 10 grid needs 10+10=20 i/o pins).

Rather than try the idea out with something simple, then discover it doesn't expand well for bigger/more complex games, we've decided to have a go at quite a complex game, and - if it works - scale it back for simpler board games. For now, we're concentrating on tracking the positions of "dumb" game pieces on the board throughout a game.

One of our favourite geek-games of the 80s was Blood Bowl (which thanks to a console remake being released in 2011 is seeing a bit of revival in recent months). Now, the original Blood Bowl board was a massive 15 x 26 = 390 squares in size.

Obviously, using a PIC with only about 30 spare pins is never going to cut it. So we're back to either using analogue inputs or increasing the i/o pins using shift registers. After much discussion, however, one idea really started to appeal: use two PIC microcontrollers!

This is not only cheaper than implementing a whole array of shift registers, but also gives us a bit more oomph to play with, as we could split game play up over a master and a slave controller.

We're planning on using the master to activate an entire "row" of inputs (the output Port1 in this previous port) but then to start listening on a serial RX pin for a response from the slave. The slave micro simply looks at the input state of all the pins (uC Port2 input in this previous post) and sends this back to the master via serial TX.

Because the master knows which row it activated, it can decode the value received over serial and work out which combination of buttons/inputs were activated. Now, by using 2 x 18F4550 chips, we've up to 30 pins available on each chip and a grid of 30 x 30 inputs (900 squares) is suddenly achievable.

For our Blood Bowl game, we could easily implement a 15 x 26 grid of squares and still have about 15 i/o pins freed up on our master controller (this controlling 15 rows, with the 26 inputs on each column being read by the slave controller). With this in mind, and after much more discussion (and a few more cups of tea and a whole packet of hob-nobs) we reckon we could come up with a generic board game controller which would have:

a) support for up to 600 squares (e.g. 20x30 but not necessarily in a square formation)
b) an LCD display for each player/side which can display current game status
c) built-in dice roll and other random-number generators
d) ability to calculate results/outcomes which would otherwise require dice rolls and table look-ups in the rule book

Although we've not actually built anything yet, this is quite an exciting development.
We remember Blood Bowl as being a great game, but bogged down with dice rolling, looking up results in tables, applying modifiers based on the playing piece type and so on. The Third Edition of Blood Bowl tried to do away with a lot of this by using a simpler dice system, but eventually the same thing happened: the immediate action could be resolved quickly (did a particular action succeed or fail) but when this affected another players ability, yet more dice rolls and table look-ups were necessary.

If we could remove all this dice rolling and referring back to the rule book and introduce a simple interface - so a player could pick up a piece to identify which is being moved, then press a button to say which action they were performing - the microcontroller could do all the random number generating and issue resolving; simply displaying a message on an LCD screen to the user, to inform them of the outcome and what to do next.

Here's how our Blood Bowl game could look with the clever electronics in place:

Using a multiplexed keypad for other input ideas

2011-11-27T21:31:00.001Z

After a less-than-successful show-and-tell session at the weekend (yes, the one we've been devoting so much time and effort to over the last few weeks, and putting all our own personal projects on the backburner for!) the few people who did turn up spent some time discussing the various projects we were working on.

A few old ideas were explored once again - sometimes a fresh pair of ideas on an old problem can turn up some really interesting ideas in themselves - and a few new ideas were chewed over.

One of the ideas that came up was using a keypad style matrix, not for output (lighting LEDs like we were doing with our charlie-plexed array for the word clock) but for input. It came following the announcement that some of the members of BuildBrighton were looking to set up a monthly board-game-geek meeting (ok, we left Brighton some time ago, but it's important to keep in touch and see what those crazy guys are up to every now and again!). A few of us here at Nerd Towers remember fondly playing uber-geek board games like Blood Bowl, HeroQuest and Space Crusade, as pimply-faced youths, when they were first released during the 80s.

The idea being investigated is using a microcontroller to load data about each piece (a lot of playing pieces in these role-play type games had a range of different values associated with them) and then to place them on the board in a specific sequence. Each piece will be a "dumb" token - i.e. does not contain or broadcast data about itself - but the board-game controller would keep track of each piece on the board, based on when it was placed on the board, and comparing the current board state with a previously known state, to work out which piece has been lifted off the board.

A quick search on Google turned up some interesting results, but most solutions broadly follow one of two methods - a multi-plex approach (using a pin to activate a full row of inputs, then querying each pin on the row to see if it has been activated) and an analogue approach, to reduce the number of pins required.

Because we're potentially dealing with hundreds of squares on a typical board game (even the simplest of board games, chess, uses 64 squares in an 8x8 grid) we're keen to keep the number of pins required down to an absolute minimum:

With the correct value resistors, we should be able to read which key has been pressed using a single input pin. This idea looks perfect for what we need. However, in practice this is quite a difficult method to implement. Why?

The solution above is better suited to single-key entry, such as a telephone keypad or security pad, where each key is pressed, one at a time.

To be able to detect multiple key presses using a single analogue input pin, we'd need to use resistor values in roughly base-2 increments. i.e. 200 ohms, 400 ohms, 800 ohms, 1600 ohms, 3200 ohms etc.

Now we know that

a) resistors don't always come in exactly the value we want so we have to go for a best match

b) resistors have up to 10% error in them already

c) reading an analogue input is not accurate - you need to take an average over time, or work with "bands" or thresholds, to decide the true value of the input on the analogue pin.

In fact, to get to 16 inputs, we'd end up using really huge value resistors - the error in which could be more than some of the lowest-value resistors, further down the array. In short, calculating unique key combinations on a single analogue input pin is going to be, at best, difficult and in practice, almost impossible!

Which takes us back to the multi-plex approach:

Here, we need to strobe each of D0, D1, D2, D3 and take multiple readings to calculate which pins are pressed. So, for example, we could force Port1 (output) D0 low (since the outputs are tied to Vcc through a pull-up resistor) and then read the values on input pin D3 on the Port2 (input).

Under normal circumstances, D3 is pulled high through the pull up resistor at the top left of the circuit. If, however, D3 is LOW, we know that button 3 must be being pressed down. Now we read the value of Port2 D2. Like before, we expect it to be high (no button pressed) but if it is low, this tells us that button 2 must be being pressed. Similarly, if Port2 D1 is low, button 1 is pressed, and if Port2 D0 is low, button 0 must be being held down.

Now we sent Port1 (output) D0 high and pull Port1 D1 (output) low.

Checking the input pins again this time tells us whether buttons 7,6,5 or 4 are held down.

Although this approach uses more pins and appears more complex (in execution rather than in hardware) it does allow us to tell exactly which combination of buttons are pressed, even if two, three or more buttons are pressed all at the same time.

We're looking at the 18F4550 which is a 40-pin PIC microcontroller (and includes USB so we can easily download game data onto the chip) but when you take out all the used pins (2 x power, 2 x ground, usb etc) we're lucky if we have up to 28 pins to play with.

In a grid arrangement, this gives us not much more than a 14 x 14 matrix which is pretty small for anything but the simplest of board games......

Fanell Blogger Outreach Program

2011-11-24T23:16:00.001Z

Here at Nerd Towers, we're big fans of Farnell.
The level of service, fast delivery but most of all, their amazing website leaves the others in the shade!
Although you can sometimes save a few pence (or even a few quid) by going to competitors such as RS, Rapid, Mouser, eBay etc, you often find buying a few bits from one, and a few bits from another - just to get the best deal - means waiting ages for all your different suppliers to send stuff out.

Wherever possible we try to source all our components in one hit, from one place. And more often than not, it's from Farnell.

The reason is because their website is so easy to use!
I've never really browsed by category, or spent any time just clicking from item-to-item. I go straight for the search bar, type in what I want and then apply different filters to the results until I get what I want. Unlike some sites (*cough* RS) where even if you provide the exact part number you don't always get a match, the Farnell site has some really clever search intellegence behind it. You can even type in a vague description of the sort of thing you're after and it'll have a stab at what it thinks you mean. And then alongside each set of results, are alternatives or related components. Not Amazon-style-other-people-bought-this, but actually complimentary alternatives to what you've found.

Now we must add in a caveat to this Farnell-love-in.
But it's just another reason we put them above the others - brand loyalty.
Like most other "tech" suppliers, Farnell recently entered into the "community" arena; RS have their DesignSpark community (and their, frankly, dismal PCB design software), Instructables was recently bought up by AutoDesk - suppliers of the eye-wateringly expensive AutoCAD - just to get a community base and even gave away free versions of their CAD software, and Farnell launched element14.

In fact, element14 was one of the first to recognise that what drives geek-communities is a challenge. So they set up the Global HackerSpace Challenge. They even gave each hackspace a budget to buy stuff with. Not drop their own branded "freebies" onto them as a cheap alternative to beta-testing, but gave away real, genuine cash, and said "go buy stuff, make something with it, tell us what you made".

Now Farnell are continuing in this vein, giving away yet more stuff - but allowing the recipient to decide what to choose, not just promoting their own range of products. It's called a "blogger outreach programme".

And we think it's a great idea.
But then again, we probably would, since we're one of the lucky recipients!
It's hard, being given the Farnell catalogue to choose from, to decide what to go for. Choose something too expensive and you just end up looking greedy and getting expensive stuff for the sake of it. But then again, a handful of resistors worth 50p are hardly worth bothering with! In the end, we took a look at the projects we had on the go, and decided to grab some freebies to help complete them.

So yesterday we received 100 SMT LEDs which originally were going to be for our word clock project (using SMT means not having to drill over 200 holes on the next board!) but we might just incorporate into a full-sized light-up guitar fingerboard.

[photo here]

Since we've spent many months working on our range of miniature instruments, we've neglected what it was that first sparked the initial idea - that is a love of cool/geeky (full-sized) guitars. With a load of LEDs, we started designing an acrylic fingerboard (yup, acrylic. Not rosewood or ebony or maple - the usual choice of wood for a fingerboard, but good old laser-cuttable plastic!) The idea is to create a "learn to play" guitar neck, which can light up and show you where to put your fingers. Such guitars do exist, from places like FretLight, but they're quiet expensive!

We've a load of cheap guitars (off eBay) that play ok so we're going to try to retro-fit a light-up fretboard onto an existing instrument. But once we're done, we want the rest of the guitar to light up too!

So our second freebie from Farnell was a selection of EL (electro-luminescent) wire which we're planning on putting around the guitar body, for the ultimate glow-in-the-dark finish!

[EL wire photo]

We're really looking forward to spending a bit of time doing what we do best - just nerding out with a bunch of components and seeing what we can come up with. And, of course, posting the results on our blog.

Check back for progress updates soon!

Multi-lights controller for toy cars

2011-11-24T22:37:00.001Z

As one of the younger members of HackLlan Jason was busy making LED traffic lights for his younger brother last Thursday. This week, we've been working on taking that idea to the next level.

Instead of a simple pin-on, pin-off with delay approach, we've changed the code in the microcontroller to use a single Timer0 interrupt (raising an "event" every 1ms) and a number of counters and state machines to control lots of different devices all at the same time.

Instead of the smaller 16F628A chip (used in the original prototype) we've gone to the other end of the scale and put in a massive 40-pin 18F4550. This gives us plenty of i/o options. So far, we've kept PORTB for inputs (using the internal pull-ups to reduce the final component count), put the traffic lights on PORTD and used PORTC for the servo and LED controller for the level crossing.

The what???

That's right. This controller now simultaneously handles:

two sets of inter-dependent traffic lights
two sets of alternate flashing level crossing lights
two servos (level crossing gates)
a one-shot fire-on-release ultra-bright LED (speed camera)

There are still plenty of spare i/o pins to add more to this project in the future (pelican crossing, belisha beacon etc) but we need to think about finishing off what we've got here, otherwise it'll be Xmas and we'll still have everything on a loose-wired breadboard (which let's be honest, won't be much of a final gift!)

Here's a video showing the breadboard, controlling all the different lights and servos at the same time -
well done Jason!

Note how the traffic lights continue to work independently of the other things on the board - the alternating lights work separately to the traffic lights, and the servo signals are being sent every 20ms to update the servo horn/gate positions. And all the while the speed camera goes off at periodic intervals!

Debugging charlie-plexed LED array

2011-11-20T17:48:00.001Z

All of the online tutorials that mention charlie-plexing and LED array over using shift registers list pros and cons. The pro is always few components, simpler layout etc. and the cons always include "difficult to debug".

They're not wrong!
Since getting our 90-LED charlie-plexed array soldered up nearly a week ago, there's still little improvement on getting it to work properly! We did track down a few broken traces (the black toner in the printer was a bit faint in places so a few traces over-etched and had breaks in them). But even after fixing those, and spending hours and hours with the continuity tester/multimeter, there are still six different scenarios that cause the matrix to fail.

Although we feel we're close to solving it (having identified which pins cause it to fail) the last bit - understanding our findings - is still as elusive as ever! Here's the array working as it should:

The sheet in the background is a drawing of our findings - the six scenarios that cause the matrix to fail and the LED pattern created, instead of a single LED lighting up

Every now and again, however, we get something like this result

The LED we expected to be lit up is in the centre of the "cross" shape - and remains stubbornly unlit

Even more peculiarly, we did some measuring with the voltmeter. When an LED is lit properly (from a 5v source running through 200 ohms) the voltage across the cathode and anode pins is around 2.9V. The voltage across all the other LEDs in the same row/columns is about 0.6V which is the typical voltage drop across a diode, but not enough to cause it to light up.

When we measured the voltage across the pins of an LED that wouldn't light up (the one we expected to light up but is in the middle of the cross - and remains unlit) we got almost a full 5v across the two pins. All the other LEDs that were faintly lit measured about 2.8-2.9V. So in this case, with the dim LED in the centre of the cross, we're measuring 5V across the pins, but it does not light up.

Here's a diagram of the pins combinations which don't work, and the LED "patterns" that are lit up.
If anyone can spot a pattern or - better still - come up with an explanation, please leave a comment below (and anyone else in future having similar problems might have some idea where to begin debugging!)

Testing our 90-led charlie-plexed LED array

2011-11-15T13:46:00.001Z

There's something not quite right with our LED array.
In the main, it works fine. By simply applying 5V across different terminals we can see individual LEDs light up. Here's an example of lighting a single LED by applying 5v across two of the 10 available terminals:

(yes, that is Jason's traffic light LED project - I just nicked the 9v battery and 5v regulated output for the sake of testing this new board!)

But every now and again - and it is just every now and again, not very often - we get a peculiar result. Instead of single, bright, LED lighting up, an entire row (and sometimes part of the column) lights up too. We're putting this down to either a dodgy LED somewhere, or an LED being soldered in the wrong way around.

At the minute there's no real pattern to which combination of terminals gives the bad response.
There's one way to get to the bottom of this - to build an LED tester:
The idea is to create something that we can control which pin takes 5v and which takes ground, and record the result in a truth table (similar to the table created at design stage). Hopefully by cross-referencing these results to our schematic, we should be able to identify which LED(s) are common to all the problem terminals.

Charlie-plexing 90 LED array for word clock

2011-11-14T22:35:00.001Z

Despite somehow printing the PCB for our word clock project at about 90% (so the 0.1" pitch connector won't fit properly!) we decided that we'd put too much work into the first version just to scrap it - drilling over 200 holes by hand was over an hour's work on it's own!. We do now have a "proper" sized board, but we figured that we could use this messed up one as a proof-of-concept prototype.

So we got 100 white 3mm LEDs off eBay and set to work.

We started out with the top row of 10 LEDs - soldering the legs but NOT cutting them to length. Then after the second row of ten LEDs had been soldered in, we could bend the legs on the top row across to solder to the LEDs on the second row. This is how we're making our connections between each horizontal "row" on the PCB.

Care should be taken to make sure that all "ground" legs (i.e. the shorter, cathode leg) are clipped short enough so that the legs being bent DON'T make contact with them (effectively shorting one or more LEDs to ground).

Here's the top side of the board after the first two rows of LEDs were installed

After installing a couple of rows of LEDs, getting the snips in between all the flying legs was a bit of a problem, so we cut the cathodes of all the LEDs to length before putting them onto the board.

This made installing the LEDs much easier - less than 30 minutes later and we had a fully populated board:

The reverse side showing how the LED legs were bent in different directions, to create connections across the horizontal rails on the PCB

(note the connector is still in place but the final job will be to remove this and solder the ends of the wires from a 10-way multi-core cable straight onto the board)

The final LED matrix with current limiting resistors in place on each "column" of the matrix.

Now we're ready to hook it up to a microcontroller and start flashing those lights! Sadly, it's a little late to be starting such a thing now, so it'll have to wait until the morning......

PIC microcontrolled traffic lights

2011-11-14T22:29:00.001Z

This is a set of traffic lights, created by the newest (and youngest) member of HackLlan, Llangollen's hackspace. Jason is also a member of our nerd club and his first microcontroller project was this funky set of traffic lights

He's used a PIC16F628A - the perfect "beginner" chip for starting out with PIC programming, although he's not really done much with the myriad of interfaces available on this chip (I2C, SPI, serial UART etc). Jason wired up the board, created the state machine for the lighting sequence and coded the Oshonsoft BASIC program to make the lights play out the same sequence as a real set of traffic lights.

The final result is quite impressive, with the 5mm LEDs mounted onto tiny little home-made PCBs, ready for fitting into their final enclosure.

Microband goes live

2011-11-10T21:28:00.001Z

One of the reasons there's not been much hardware activity is because we've been coding away like a troupe of monkeys to get the instrument software (and accompanying website) if not finished, at least in a state that we can use to demonstrate the instruments.

We're calling the range "MicroBand"

(micro because they're small, but also because they're driven by Microchips micro-controllers. You really couldn't get more micro than one of our micro instruments!)

The software uses an Activex DLL to raise events whenever the instrument is played. This allows us to concentrate on getting everything working, then handing a large part of it over to the community to play about with and see what they can come up with!

When a micro instrument is connected, the DLL raises a connected event, reads some data off the device and displays it as an interactive animation on the screen

(the onscreen guitar highlights which fret the user has selected at any time the instrument is held and played properly - note how the onscreen display changes to match the instrument you're holding)

The software includes a sequencer, so multiple players can collaborate on a single song. In the example below, another user has already laid down a drum track (red) and the sequencer shows the guitar track just played and recorded (yellow)

Using this multi-layered approach, other players with different instruments (bass, synth/keys, rhythm guitar, vocals etc) can come together to create tracks, using the website integration to pull everything together.
Which brings us onto the website - it's pretty straight forward and rather than spend ages discussing it with photos here, visit http://www.microband.co.uk and see for yourself!

Having recognised my username and password, the server knows which guitar I've got, and updates the onscreen avatar to reflect my customisations. In time, we hope to have a full video creation tool, where players - having created their multi-track mp3 songs - can animate their avatars in time to their own musical creations.

We've still quite a way to go to get a "complete" working, finished product. But at the same time, we're now at the point where we need to see how people use the instruments, to see how and where we need to improve things. So the first batch of guitars have been made up and sent out.

The next job is to get some pals together, have a massive jam session one weekend and get a load of samples recorded for the website! (and of course, to record some videos to demonstrate just how cool these little instruments are to play - if a picture is worth a thousand words, one Youtube video is worth, erm, just loads of these types of blog posts - look out for a video update soon!)

Miniature instruments update

2011-11-10T21:21:00.001Z

We've not really done much on the actual instrument hardware in recent days - except perhaps finally settle on a design we're happy with. Since trying numerous ways of building the instrument from layers of acrylic, we feel we never quite got the neck/fingerboard design right. Until tonight....

This latest style - the Les Paul classic shape - now has a fingerboard slightly raised from the body join. This is how a real guitar looks- the neck may be bolted flush to the body, but the fingerboard is always slightly raised (presumably to help the player to reach those tricky 22nd and 23rd frets!)

We're going to use this design on all our guitars in future, raising the fingerboard slightly proud of the guitar body. Here's how we acheived it -

Each guitar body is made of 2 layers of 5mm acrylic (with the middles cut away to create a hollow into which the electronics are places inside the guitar body). The lower layer does not include a cut away for the guitar neck to sit in. In the old design, we would glue the 5mm guitar neck onto this lower layer, so that when the fingerboard and 3mm top body layer were placed on, they were pretty much in line.

By adding a 3mm shim on top of the bottom layer, when we put the guitar neck on, it is raised above the height of the second layer. When the final (top) layer of acrylic is in place (often a different colour to the 5mm layers) the whole assembly is flush. The fingerboard is placed on top of the neck, with the end result that it stands a few millimetres above the guitar body - just like the real thing!

Word clock

2011-11-10T20:55:00.001Z

Carrying on our Word Clock project, we managed to get a PCB made for it tonight.
The final PCB was drawn out in our old favourite ExpressPCB (because the free version of DipTrace has a limit on the number of pins you can use in one circuit). It took a while getting used to the rather basic interface again, but it didn't take long before it all came flooding back!

Here's the PCB design we came up with.
Charlie Plex 90 Pcb - Black

It's not really 100% complete, because we've only really run the traces in the horizontal direction. When the LEDs are in place on the board, we'll have to bend some legs over and solder an LED leg to another LED leg - because otherwise we'd either end up with a really complex PCB layout or crossed traces somewhere:

note that the horizontal LEDs are connected where necessary (e.g. D51-D55, to D45-D50 are all connected) but the vertical LEDs (D5, D15, D25, D35 etc) need to be connected using the component legs

To connect the LED legs in the vertical directions, we'll just solder the legs together, similar to the way shown in this diagram -

Anyway, here's the board after etching and cleaning - getting ready to drill the LED holes.

Almost an hour later, after drilling over 200 holes with a hand drill, it started to look like an array of components might actually live on this board:

With the board drilled (and while we waited for the 150 LEDs we'd ordered off eBay to arrive) we lined up the plastic inserts, that we cut last week, against our PCB. Each LED should sit snugly into each "cell" in the insert -

Bugger. We're out by quite a bit. Having measured the spacing for 3mm LEDs and set the spacing in the insert grid to 8mm (that's 3mm for the LED plus 2.5mm top and bottom for the PCB traces) we're still not sure how we got this one so far out.
But the PCB is made and etched (we've another one in the making too) so it makes sense to redesign and cut the grid to better suit the PCB, rather than the other way around. Maybe it's time to fire up the laser cutter again......

Delta robot update

2011-11-04T13:39:00.001Z

Here's our delta robot after gluing the "hip" joints to the servo horns and assembling the limbs.
Note that the joints are simply bits of elastic tied through the connecting pieces. We don't know yet if this is a suitable way of making joints, but they look ok so far - and allow for multiple degrees of movement, in all different directions, not just in one direction (without having to use expensive ball-and-socket type joints)

Please, no more comments about how messy the desk is or "haven't I seen that black guitar somewhere before?" - we tend to tidy up after we've finished what we're making. Which, given the number of projects we've actually completed, explains why the place is always such a mess!

Now to let the glue dry before trying to actually move it around.
So while that's happening, let's get on with the controller board. As ever, it'll be a USB HID device, driven by a trusty PIC 18F2455

(the final robot may not be usb-driven, but putting a USB chip on during development makes it really easy to read back values for debugging and to see what's actually going on in your code!)

Miniature guitars manufacturing process

2011-11-04T00:10:00.001Z

Incredibly, it's November and we're still perfecting the manufacturing process for our range of miniature instruments (starting with the micro guitars). We've got the PCBs made up and have placing and soldering the components down to quite a fine art - even if we're still doing everything by hand, until we've a working pick-and-place machine.

Soldering the multi-core cable is still quite a job to do by hand but we've got it down to about five-ten minutes per instrument, including testing and resoldering should any dry joints cause problems.

One of our bottle-necks is getting the guitar strings consistently the same length and all bent to the right angle(s). These finished guitars look ok, but if you examine them closely (around the bridge and neck positions) you'll see that on some, the guitar strings look a bit bent and wiggly.

While we had the laser cutter out, we made a simple jig for bending the wires.
We went through all the guitar designs and made sure that the holes for each lined up exactly then made a template for bending our wires.

As you can see, using the jig, all our guitar strings are now neatly lined up, all the same length, and all entering the guitar body at the same angle. Such a simple job - but it makes such a difference!

Word clock

2011-11-04T00:01:00.003Z

As part of the HackLlan show-and-tell session, we're hoping to get a number of projects finally finished (or at least in a presentable form) and so we're furiously cutting and making, every time the laser cutter gets pulled out of the HackCupboard.

Here's the internal guts for a word clock.

Here it is assembled (missing the top and right-edge struts)

The idea is to place this structure over an array of LEDs (90 in total) which are charlie-plexed by a single PIC 18F2455 microcontroller.
Using the formula pins required = n(n-1) we can work out that we're going to need 10 pins to drive an array of 90 LEDs (10 * (10-1) = 10*9 = 90). It may be possible to drive this array from a cheaper, lower-spec PIC, such as the 16F628A and our chosen chip is probably a bit of over-kill for what we need, but it'll be nice to have extra i/o pins if needed, for extra functionality in future.

Here's how we're driving 90 LEDs:

And the truth-table (which pins to activate) to turn on each individual LED

How does a matrix of 90 LEDs become a clock then?
By simply placing our cell-structure over the leds (so we don't get any light-leakage) and fitting an etched piece of glass/perspex like this over the top:

Light up the LEDs depending on the time - so for half past four, we'd light up LEDs numbered 1,2,3,4,5,6,7,33,34,35,36,64,65,66,67. We'll put a watch crystal inside to keep accurate time, then just convert the current hours and minutes into a selection of LEDs to light up - and use the charlie-plexing routines to make the appropriate lights come on at the correct times. Easy huh?

Delta robot and laser cutting

2011-11-03T23:36:00.001Z

At another of our HackLlan meetings, and in preparation for the show-and-tell (provisionally booked for Sat 26th November, on the same day as the Llangollen Xmas Festival) we've had the laser cutter out, busy making and preparing a number of different projects.

First up is a simple three-servo delta-robot.
This robot will be programmed with a script to perform repetitive tasks such as pick up, move, release an object. There are no plans for any further intelligence to be programmed into it at this stage - but perhaps could be used as a project for any follow-up workshop from the show-and-tell session.

The photo above shows the main structure with the servos mounted on it at 120 degree intervals. Slots were cut into a round disk, to allow the servo heads to move through 180 degrees, perpendicular to the base. The servos were lined up by placing their corners on top of some small cross-hairs etched into the base and stuck down with double-sided tape (in the final version we'll use permanent plastic cement, but for now we may need to move them around again as development continues!)

There are three legs, each made up of three lengths of acrylic.
The "hip" joint - the part that connects to the servo - is a single piece with a large circular head (for connecting to the servo horn). The lower part of the leg - from the "knee" to the ankle - is made up of two pieces connected either side of the top piece.

We're still thinking about how to make the joints, as the "ankle" joints need to free-moving in all axis directions. Someone suggested hobby-sized ball joints (like those found on remote control cars, helicopters etc). A cruder (but easier and cheaper) solution might be to simply use elastic bands to make the joints....

Pick and place update

2011-10-31T18:41:00.000Z

We've been a bit busy with all kinds of projects lately, but this popped up in Google+ today and looks like a really good idea - it's a homebrew pick and place machine, based on a CNC frame.

http://hackedgadgets.com/2011/10/24/diy-pick-and-place-machine-called-the-redfrog/

But the thing that caught our imagination was the tape advance method.
The head simply drops into one of the tractor tracks on the side of the tape and pulls it along! No need for complicated electronic feeds or multiple steppers - just use the positioning head to pull the tape along to the correct place. A neat idea.

Hopefully it won't be too long before we get to try it on our own machine!

New guitar models added to the microband range

2011-10-28T00:41:00.000+01:00

After spending a few days soldering up some of the new PCBs from www.pcbcart.com we fired up the laser cutter to make some enclosures for the new miniature guitars. We're working on a complete range of micro instruments at http://www.microband.co.uk and hope to have at least eight different guitar models.

We've already got

And we're hoping to complete the range with

Les Paul
Warlock
Telecaster
Gibson SG (AC/DC)
F-hole blues (like BB King's Lucille)

Tonight we managed to design and cut out two of these new guitars:

This is going to be an SG style guitar, for Andy at BandJammer.
While Angus Young from AC/DC usually plays a maroon-coloured SG, Andy's favoured guitar is a mustard yellow one (at least that's the one he uses in most of his videos and promotional material!). The closest match we could make was a yellow acrylic, but here it is partially assembled. It's a surprise gift, so let's hope he's not reading this blog!

We've some 1.5mm HIPs on order for the scratchplate. We tried making it from thick card, but it didn't look nice (and stank the workshop out with a nasty tarry smell as the laser just burned the paper and filled the cutter with smoke!). Here's the guitar we're basing this one on....

For our Les Paul style guitar, we wanted to try something a bit different to the previous styles. We've got a red Stratocaster, a yellow Explorer, a green Flying V and now another yellow guitar. A blue Les Paul just didn't look right and we don't have any gold coloured acrylic to re-create Slash's famous goldtop.
So who else plays a Les Paul and isn't Slash...?
Zakk Wylde not only plays a Les Paul, but also plays a white one, with a striking bulls-eye black-and-white pattern. Perfect! We've plenty of white acrylic in both 3mm and 5mm!

Unlike previous miniature guitars, we've moved away from the 5mm black acrylic, and decided to make the entire body from the same colour, yet stick with a black fretboard. The end result is actually quite nice.

A few stickers and a bit of finishing off and we shouldn't be too far away from the real thing -

PCBs arrived from PCBCart

2011-10-24T23:11:00.001+01:00

More exciting news about the miniature instruments as our second set of PCBs from PCBCart.com arrived this afternoon. Woo-hoo! We had 200 boards made up for just under £100 - making them less than 50p each.

Here they are, ready for inserting into our first commissioned miniature guitars. The soldermask and HASL (hot-air-solder-level) finish certainly makes soldering the boards up much easier than the homebrew boards we've been struggling with so far!

The cable on the right was soldered first. As we got familiar with the method for attaching the ribbon cable, the last cable (right) has a much better finish. These cables were hand-soldered using solder paste rather than the solder pot but only because that was what was to hand!

Even soldering by hand with a cone-tipped iron (rather than our preferred hot-air-soldering method) was quick and easy. Ok, the first transistor we put down went a bit wonky, but that's only because we were rushing to see how quickly we could assemble a full board!

Here's the first of our new boards ready to go into the latest (commissioned) micro guitar

Back in 1991, Metallica released their eponymous "Black Album".
It is still considered by many to be their best album to date. Everything about it was black. Including the guitars. This guitar is for a 90's Metallica fan who wants to remember James Hetfield before he shaved off his handlebar moustache and cut his hair!

2011-10-19T19:57:00.001+01:00

Here's a grid of 54 blocks of colour - each with a unique combination of RGB values, one for each playing card in a regular deck (52 cards + two jokers). We're hoping to use these with a colour sensor to build a device which can "read" playing cards placed in a special holder.

Creating unique colour combinations for playing card reader

2011-10-19T12:04:00.000+01:00

Ok. With the numerous problems and repetitions in our previous attempt, we've turned to Excel to help us solve this conundrum. We need to be sure that every playing card has a unique combination of red, green and blue in the colour block (whether we settle for a single colour in the block, or stick with the 2x2 grid approach, we'll have to wait and see, once we know how sensitive our LDR is going to be).

Each colour will have an intensity of zero-to-three.
By writing out all possible permutations, we get 64 combinations (three colours, four intensities, 4^3=64)

Red	Green	Blue
0	0	0
0	0	1
0	0	2
0	0	3
0	1	0
0	1	1
0	1	2
0	1	3
0	2	0
0	2	1
0	2	2
0	2	3
0	3	0
0	3	1
0	3	2
0	3	3
1	0	0
1	0	1
1	0	2
1	0	3
1	1	0
1	1	1
1	1	2
1	1	3
1	2	0
1	2	1
1	2	2
1	2	3
1	3	0
1	3	1
1	3	2
1	3	3
2	0	0
2	0	1
2	0	2
2	0	3
2	1	0
2	1	1
2	1	2
2	1	3
2	2	0
2	2	1
2	2	2
2	2	3
2	3	0
2	3	1
2	3	2
2	3	3
3	0	0
3	0	1
3	0	2
3	0	3
3	1	0
3	1	1
3	1	2
3	1	3
3	2	0
3	2	1
3	2	2
3	2	3
3	3	0
3	3	1
3	3	2
3	3	3

We only need up to 52 colours, so we've decided to do away with the "darker" colours

(e.g. a block with the colour combination 0 1 0 would have one single green square and three black ones in a 2x2 grid). The easiest way to do this was to sum the totals of RGB and any block with a total of two or less was discarded (0-1-0 gets binned, 0-1-1 gets binned, but 0-0-3 can stay, as can 0-1-2 and so on)

This leaves us with 54 colour combinations:

Red	Green	Blue
0	0	3
0	1	2
0	1	3
0	2	1
0	2	2
0	2	3
0	3	0
0	3	1
0	3	2
0	3	3
1	0	2
1	0	3
1	1	1
1	1	2
1	1	3
1	2	0
1	2	1
1	2	2
1	2	3
1	3	0
1	3	1
1	3	2
1	3	3
2	0	1
2	0	2
2	0	3
2	1	0
2	1	1
2	1	2
2	1	3
2	2	0
2	2	1
2	2	2
2	2	3
2	3	0
2	3	1
2	3	2
2	3	3
3	0	0
3	0	1
3	0	2
3	0	3
3	1	0
3	1	1
3	1	2
3	1	3
3	2	0
3	2	1
3	2	2
3	2	3
3	3	0
3	3	1
3	3	2
3	3	3

Where the total sum of colours in a block exceeds three (1-2-3 for example represents 1R-2G-3B) we'll have to mix the colours to make secondary colours (magenta, cyan, yellow) and maybe even black and/or white. But hopefully, using these colour intensity charts as a guide, we'll come up with colour blocks that enable us to uniquely identify a card based on the RGB values received by the LDR/light sensor.

Seeing playing cards with an LDR and RGB LED

2011-10-19T11:48:00.000+01:00

It didn't take long after posting about our intelligent poker table for the emails to come in pointing out a few mistakes on our colour-block image.

We'd tried to come up with at least 52 unique combinations of colour blocks, using only primary (red, green, blue) and secondary (magenta, cyan, yellow) colours. We thought we'd done a pretty good job until Matt from BuildBrighton pointed out -

Looking at the top-left block of colours, it's easy to see that we've two red, one green and one blue block. Let's write this as 2R-1G-1B.

Now on the top row, look at blocks three and five.
Block three has two red, one magenta and one green.
Magenta is made up of equal parts (1:1) red and blue.
So block three is 3R-1G-1B

Block five is made up of two red, one yellow and one blue.
Yellow (as most people who paid attention in physics class will tell you) is made up of red and green light (yes, when mixing paint, yellow+blue = green, but when mixing light, red+green = yellow. Just accept it!)
This makes block five also 2R + 1R+1G + 1B = 3R-1G-1B

So although we'd used unique combinations of colour pigments for our blocks, we've actually repeated intensities of light for a lot of the colour combinations. In fact, looking through the image, we can see we've actually repeated ourselves quite a few times!

Back to the drawing board....

Intelligent poker table without RFID

2011-10-19T11:37:00.002+01:00

As a member of HackLlan (Llangollen's Hackspace) we're trying to get some ideas together for a show-and-tell session in November and to organise a robot kit for a weekend-workshop.
This means a few of our other projects have been sidelined, while we try to find projects that are both simple enough to explain in a few hours, but complex enough to keep people's interest for the whole day.

One project we're looking at is an intelligent poker table. You know the sort - players put their cards face down on the table and a graphic appears on-screen showing their "hole" cards. This was first seen in the UK on Channel 4's Late Night Poker, where the rather lo-tech solution was to put a camera behind a sheet of glass at every player's position.

This approach is still used in a lot of televised poker tournaments, and they are available on the 'net to buy, but you'd have to be a dedicated poker player to house a full-sized 10 seater table in your house!
A variation on this theme is to have cameras mounted in the "rail" of the poker table, which sneak a peak at each player's hand, as they bend their cards upwards to have a look at them.

For home-games, an alternative approach is becoming popular, but it still quite expensive - RFID playing cards. Each card in the deck has a tiny RFID tag, and each player has an RFID reader in front of them. As the cards as placed on the reader, the unique ID is read from each tag and the system knows which cards the player holds.
This is infinitely simpler than having up to ten webcams under a table, but RFID tags are expensive. Each tag costs 50p-£1 and a professionally made deck of cards costs £100 or more. You can make your own cards, by simply applying an RFID label to each playing card, but this increases the thickness of the deck significantly and the labels are still susceptible to breaking if players bend the cards too much.

We're after a much more low-tech (i.e. cheaper solution) that should be accessible to almost anyone.
One of the ideas we're investigating is a colour sensing circuit and a 2x2 grid of colour, unique to each card.

The idea is to have an RGB LED and a light sensor (either an LDR or something like a light-to-voltage sensor) under an opening onto which the card is placed. By flashing the LED red, then measuring the amount of reflected light, then green, then blue, should allow us to work out which combination of colours is showing.

At the minute it's all just a fancy idea - but hopefully this week we'll find time to put together a proof-of-concept prototype to see if it's feasible to continue.

Interesting servo hack

2011-10-17T16:46:00.001+01:00

After reading a few other articles about hacking servos to make them rotate continuously, I noted quite a few people suggested disconnecting the rotary pot and replacing with a voltage divider made up of 2 x 2k resistors (in a sort-of Y shape)

Our servo is much too small to fit extra components inside it, but without these, it doesn't seem to work. It spins in one direction, by sending a repeating 1ms pulse every 20ms, but increase the pulse length to 2ms and instead of running in reverse, the servo just judders and makes a nasty noise.
(if the servo is "centred" at 1.5ms, a pulse of 1ms tells it to move 90 degrees in one direction, and a pulse of 2ms tells it to move 90 degrees from centre in the other direction. By removing the pot input, the servo never knows where the head is so should continue to move).

Removing the pot seems to have caused the problem.
To simulate the pot, we soldered a piece of wire from the board where it was connected to the potentiometer (we should have snipped the end nearest the pot, not nearest the board and we could have re-used the bit of wire without extra soldering!) and connected to a voltage divider on the breadboard, made up of two 2K pots

This sort-of solved the problem, but not quite.
The servo no longer judders, but it's not not right. With a pulse width of 1ms, the servo runs at full speed in one direction. A pulse width of 2ms makes it run in the same direction, only much slower.
Maybe this is because we're using power and ground on either side of our voltage divider, rather than taking them off the internal pot (but then to get at those wires would require completely dismantling the servo!)

Now we could play about with the resistor values, or maybe even replace them with an exterior potentiometer (with the wire from the servo connected to the wiper and each end connected to power and ground) but here's a thought....

Pulling the signal on the wire to ground causes the servo to run at full speed in one direction.
Pulling it to power (5v in our case) causes the servo to run at full speed in the other direction.
So now we have a binary method of moving the servos either forwards or backwards - simply connect this new wire to an output pin and pull it high to drive the servo in one direction, and pull it low to drive it the other way.

Edit...
interestingly, we did have to make some changes to the servo control values to get the servo to work consistently without juddering. When pulling the signal pin high, we set the servo signal length to zero. When pulling the signal pin low, we set the servo signal length to 2ms. This resulted in the servo running at full speed in opposite directions. (using a signal length of 1ms and pulling low occasionally caused juddering so we ditched it!)

The downside to this approach, of course, is that we don't have a way of programmatically stopping the servos from turning. For our little robots project, we'll live with this restriction.
It's a fine balance between coming up with a project that can be completed inside a couple of hours but still demonstrates "hardware hacking" and spending all day perfecting servo controls which probably wouldn't get used!

Anyway, this is to document how we hacked our micro servos to allow us to create little tiny robots, instead of the big monstrosities normally associated with continuous rotation servos ;-)

For anyone interested, here's the Oshonsoft BASIC PIC code for our servo test board:

Define CONF_WORD = 0x3f18
Define CLOCK_FREQUENCY = 4

declarations:
       Dim servolen As Word
       AllDigital

init:
       Config PORTB = Input
       Config PORTA = Output
       OPTION_REG.7 = 0  'pull-ups on PORT inputs
      
startup:
       While PORTB.0 <> 0
              'do nothing: we have to press the button to start
       Wend
      
loop:

       'button controls direction
       'connect the extra wire from the servo
       'to pin PORTA.1
       If PORTB.0 = 0 Then
              High PORTA.1
              servolen = 0
       Else
              Low PORTA.1
              servolen = 2000
       Endif
             
       'servo control signal
       'for our hacked servo, signal length doesn't matter
       High PORTA.0
       WaitUs servolen
       Low PORTA.0

       WaitMs 15

Goto loop
End                                               

Hacking to make a continuous rotation servo

2011-10-17T13:13:00.001+01:00

As part of the up-and-coming HackLlan show-and-tell session, and for the follow-up workshop, we're making robot kits in preparation for the Robot Week Wales.

As with most robotic projects, this begins with hacking some servos to make them rotate continuously. We could just buy factory-set rotational servos from our pals at Oomlout but as the workshop is to include "hardware hacking" we figured we'd have a got at modifying some micro servos.

We're after making some small, compact robots so these micro servos are the perfect size (plus of course, a ready-made continuous rotation servo is £11, a micro servo less than half this at £5 each). We already had a couple of these from an earlier project but if all goes well with this experiment, we'll be buying more!

At this stage, we're not sure if the modifications will work, but we've looked into how a servo works. It's basically a small motor with a control board. The output from the motor is geared right down, giving the servo plenty of torque (twisting power). The control board has a microcontroller and a rotary potentiometer, which is turned as the motor moves the servo "horn", which is connected to the shaft of the motor.

These easiest way to explain this is to have a look at what goes into a servo.

Whenever you take anything apart, the most important tool you can have is a digital camera - and a hammer. Hammers open anything ;-)

We put the hammer to one side and open up the servo with a tiny jeweller's screwdriver.

We actually found that the smallest flat-headed screwdriver worked better than even our smallest cross-headed 'driver (despite the servo having cross-headed screws holding it all together).

You can see that the motor shaft has plenty of cogs, gearing the output down many, many times. This is what gives the servo motor it's power.

Underneath the control board, you can just make out the rotary potentiometer. As the motor turns, the gears and cogs also turn, and the shaft on the second "pile" of cogs causes the wiper on the potentiometer to turn. This signal is fed back onto the control board, so that when the servo head has reached the required position, it knows to stop turning the motor.

We traced the wire from the pot to where it meets the control board. Taking photos (so it can be replaced later if necessary) we snipped the wire from the pot and taped it up. Now, when the motor turns, the control board won't know where the servo head is, and so will keep turning the motor.

The last thing to amend is the physical lock on the servo head.

A small "lug" on one of the cogs stops the head from turning too far during normal operation.

We snipped this lug off the cog and reassembled the servo, using the earlier photographs as reference. We then put the head back on the servo and turned it by hand, to check that it does, indeed, turn through 360 degrees. The last thing to do now is to check that the servo direction can be controlled by our microcontroller.....

PCBs ordered from PCBCart.com

2011-10-12T23:01:00.000+01:00

After receiving such great service from PCBCart.com for our earlier guitar neck part of the project, and struggling to find a quick and easy way to attach cables to our home-etched boards, we decided to put another order in for more PCBs.Soldering multi-core cable to professionally produced boards (with only the pads exposed and solder mask covering the traces) is quite easy when using a solder pot.

Soldering quarter-pitch cable to home-etched boards with exposed traces can get a little messy with bridges and shorts and traces lifting when you try to correct them and so on.Simliarly, using home-brew reflow techniques are a little difficult with tiny components on home-etched boards because when the solder paste melts, instead of it pulling the component into line over the pads, the solder sometimes runs along the traces, dragging the component with it!

Hopefully all these problems will be solved by using properly masked, professionally produced circuit boards for our little guitars. Now we can simply populate a board and either hot-air gun or bake the board to fix everything in place. We already know that soldering cable to a professionally produced board is much easier and less likely to cause faults, so while we're waiting for these new boards to arrive, we're going to buy/build a stop watch to time how long it takes to build a miniature guitar from start to finish!

For anyone interested, here's the schematic and PCB layout for the miniature guitars.

Working guitars - Flying V and Explorer

2011-10-11T16:47:00.000+01:00

After what seems to have been months of development (and re-development) we're finally ready to ship our first two miniature guitars. The software is still in "beta" phase, so these are going to our good friends Aaron from Oomlout and Chris at HPC Laser

Here's a video showing the basic guitar functions, and the software in it's current state (including lots of "coder art" - we're techies here are Nerd Club, not artists!)

Each instrument uses an Activex exe (sorry true geeky types, Windows only until someone can write a Linux port) but the benefit of this approach is

using a different thread to actually play sounds means more responsive play
anyone with a bit of macro-building experience can write their own software to integrate with the instruments.

The software shows how multiple users can share music by recording to a different track for each instrument. This demo shows an existing drum track with a guitar track being played over the top.

[video goes here]

Robot Week Wales Wrexham

2011-10-08T18:20:00.002+01:00

It's been a busy couple of weeks and while we've not managed to get much further on the multitude of projects we seem to be working on, we have been involved in some exciting developments.

The first thing is being involved with setting up HackLlan, a new hackspace for Llangollen and North Wales. At the minute it's a small community with a small space, but after less than a week, numbers are already increasing, and just as importantly, so is the interest in the group.

We're also looking to get involved with Robot Week Wales which is a week-long celebration of robotics, based at Techniquest in Wrexham's Glyndwr University.

And as part of the build-up to the Robot Week, we're looking to put on a show-and-tell session with other members of HackLlan, to show new potential members the kinds of things they can make at their local hackspace. This will be followed up with a more formal robot-building workshop, where attendees can make their own line-following robot.

So while all this is going on, our recent x-y plotter/cnc pick-n-place machine looks like it's going on hold. But we're determined to soldier on with our miniature instruments developement. The software is almost finished now (we've been working on it over recent weeks, while the internet connection here has been a bit intermittent) so we just need to get our guitars finished and tested and we're ready to launch a new website (details to be posted here nearer the time)

What can you salvage from a floppy disk drive?

2011-09-30T17:53:00.001+01:00

In true Nerd Club fashion, no sooner have we decided to start (or re-start) a project, and something else comes along and takes our attention away. This time, it was the postie bringing us a clutch of four floppy disk drives, won off eBay just 48 hours earlier.

Why would anyone want such old crappy hardware?
Well, for a start the winning bid was just 1p, so even allowing £3 for delivery, they came to less than a pound each. (if you're ever at a car boot, and someone is selling off job-lots of drives as they often do, for 50p or so, it's worth grabbing a few). But that's not the main reason - we actually went out looking for old floppies, as a source of cheap stepper motors.

Here's what we found in one of our floppy drives:

The bit we're interested in is the stepper motor - usually seen at the back, next to the IDE cable connector. Whip the lid off and take a look. The motor usually has a corkscrew shaft and a bit of grease on it. These aren't important right now.

Normally two screws is all it takes to get the motor out of the casing. The other end of the shaft is usually in a part moulded into the actual casing. If the shaft and casing are all one unit (as often found in low voltage or portable/laptop drives) you'll need to undo a few more screws. But 99% of drives are built like this one.

Undo the two screws and pull the stepper motor backwards. Eventually it will stop. That's the flexible ribbon cable holding it in place. Pull until it comes free.

If your motor still has the ribbon cable attached, you can use this to connect to a PCB in future. But most messing about with steppers is first done on a breadboard/prototyping board, in which case simply solder some wires onto each of the four connection points.

The rest of the drive can be junked. We've got what we came for. But if you're in a scavenging mood, there's plenty more to be had from these little things. Get rid of the disk caddy and moving parts...

Remove the plate above the spinning head and pull. The actual spinning head should come off in your hands. It's a doughnut-shaped magnet with a spindle in the middle. It should just lift off. Undo a few screws from the bit it's sitting on and you should see some cool coils.

It's these coils that control how the head spins. As each coil is activated in a particular sequence, it can attract or repel the magnets inside the spinny head thing. If you really wanted to, you could use this as another crude stepper motor. But it's probably more hassle than it's worth. The coils themselves, however, might be useful in other projects.

Let's take a quick look at what we've scavenged from our floppy disk drive:

In our drive (though not all) we found some useful 0.1" pitch flexible ribbon cables. These are useful for joining two or more PCBs together, especially if soldering isn't your strong point - they're quite easy to work with.

There were a few springs, used to pull the disk drawer in and out, and a few "peg-style" clip springs too.

The rod that the disk head was on could always come in useful for something robot-y.
Of course, the stepper motor is going to come in handy - that's what we came for in the first place! And there were also a few "self-tapping" screws which might be handy in future. They have a slightly wider thread than normal screws and are perfect for fixing into plastic or acrylic (where they make their own thread as they are screwed into place, hence the name)

Not a bad haul for a few minutes work.
Get yourself some component bins, a few cheap drives and get to work!

Back to business - little guitars again

2011-09-30T15:24:00.000+01:00

It's been a disruptive couple of weeks - the move from Brighton to North Wales was ok, but finding everything in the aftermath has proved a nightmare! So what better way to find out what's here, what's missing, and what's still somewhere in the depths of our monster Transit Van than to actually get making stuff.

Not having access to the tools (nor even the internet for most of the last few weeks) means quite a bit of software development has been going on. We've been working quite a bit of late on
Setting up HackLlan - a new "hackspace" in the mountains
Creating a time-line-driven sequencer for players to create and share music over the 'web

But now we've got some of our stuff out of boxes and into the hack-cupboard, it's time to get making again.

a state of chaos in the new cupboard-come-office

if you can't find it, look in one of those stacking boxes...

We're actually quite excited about how well the software development is coming along, even though it's not much more than an array of samples and a piano-roll style screen. Our current guitar prototype works quite well with the software, but we're still having a few teething problems. Whether this is the software, the hardware or the firmware, we've yet to resolve. So in true "hacker" style, we've attacked all three at once.

Here's the new pcb layout, etched and ready to solder.

Before we left Brighton we were working on using a solder pot to connect the tiny fine-pitch multi-core wires to the circuit boards. We've got everything ready to go - except the components box with all our SMT stuff isn't immediately to hand. That doesn't mean it's not here. But it could just as easily mean it's somewhere in the back of a van, under a heap of household items and bedding....

Llangollen canal

2011-09-22T14:40:00.002+01:00

Having lived aboard a narrowboat, a few of us nerdy types already knew what a beautiful place the canal can be - especially at this time of year, as the autumn leaves paint everything a red-and-gold colour. After moving to Llangollen, we took a bike ride along the canal, to the Trevor Basin.

(this was the start of our bike ride in Llangollen)

British Waterways have made an excellent job of upgrading the tow-path along the full length of the canal, and riding it was fantastic (helped, of course, because it's all absolutely level and flat). It took about an hour to meander along - rarely travelling faster than the boats on the canal!

What was so impressive were the views - so, inspired by Barney at BuildBrighton, we've decided to have a go at making a time-lapse camera that can be mounted onto a bike. The idea being that the next time we go for a bike ride, we can create a video to show everyone else what they are missing! We might even add in some GPS position recording, so that the cue points in the video can be tied in with an automatically updating Google map. But for now, we'll stick with making a camera that takes pictures every few seconds, and doesn't freak out when we ride over a few bumps (the towpath is lovely and smooth, but sometimes you have to go "off road" to cycle around obstacles such as dog walkers, moored boats, horses and woodland detritus).

Nerd Club has a new home

2011-09-20T13:16:00.000+01:00

There's little to report on the maker front this week;
We've been pretty well tied up with firstly moving, and secondly, finding a new workshop. It's been an arduous few days but finally things are looking a bit more positive.

This is mainly because we've secured a unit (well, ok, a cupboard) in the Llangollen Malthouse. So now we've somewhere to get making again, we're hoping to run a few workshops and build up a community to support HackLlan - the new hackspace for North Wales

Nerd Club is moving

2011-09-14T20:20:00.003+01:00

After three fantastic years down here in Brighton, we're on the move.

Hopefully it'll only be a temporary move, but with work and family commitments, we're having to decamp for a while and move up to North Wales.

It's not all doom and gloom of course!

First up, we're looking to start a hackspace/maker group up in the mountains. As members and regular visitors to BuildBrighton, we'd love to see something similar, albeit on a slightly smaller scale (BuildBrighton have just taken over a large part of the Rodhus Art Studio and arranged the 2011 Brighton Mini MakerFaire thanks to their increasing subscriber base and growing community - it'll take us quite a while to get to that level!)

And, of course, once the move is over and we've settled into our new space (wherever that may be) we're hoping to get making, blogging and video-ing all over again. With a new bunch of nerds and geeks.

So while it may be a bit quiet on the blog for a while, it's not an indication that nothing is going on - there'll be plenty of news, when we're back up-and-nerding in a few short days...

Soldering quarter pitch multi-core cable

2011-09-12T18:31:00.001+01:00

Matt turned up at the last BuildBrighton meeting with two solder pots from DealExtreme. I'm a little disappointed with DealExtreme - they may be cheap, but you've got to be prepared for a long wait; these 'pots have been on order for about five or six weeks and there were no email updates to say where the order was up to (unlike PCBCart - another China-based supplier - who have excellent order status updates).

Anyway, the solder pot arrived and no sooner had I cut my finger on the sharp exposed edges around the pot than I had it up and running (careful of these cheaply-manufactured electronic tools - reminiscent of those nastily made PC cases that flooded the market in the early 90s, some of those edges can be razor sharp!). The moulded Australian style plug had to be cut off and a UK style plug fitted, but it didn't take long for the sharp tang of a new heater coil to fill the air.

The pot holds LOADS of solder - about quarter of a coil of regular solder wire and there was still only a small lump of molten solder in the bottom of the pot. The rosin/flux inside the solder didn't half smoke! And it created a tarry brown coating over the exposed parts of the pot. But once the solder was molten, it was easy enough to use.

(picture taken after solder has cooled, to show the rosin tarring inside the pot)

First, cut some multicore wire to length and strip back to expose the ends.
(we use quarter-pitch IDE cable - the sort of stuff you find in "round" IDE cables)
Dip the exposed copper into the solder, leave for a second or two, then remove.

The ends are perfectly tinned with just the right amount of solder.
Place the cable onto the tiny-pitch PCB connectors and heat with the tip of a soldering iron. Easy peasy - every wire connected first time, with no bridges or lumps of solder like we usually get when trying to solder these by hand.

We're still having to connect each wire one-at-a-time, but it's relatively easy. Ideally we'd like to get a really wide (15mm) chisel tip on the iron, so all wires can be connected in one go. But so far, the solder pot looks like it's going to be a useful addition to our arsenal of tools!

Choosing the stepper motor resistors

2011-09-11T20:30:00.002+01:00

Using a combination of L293D stepper controller ICs and IRF640 mosfets, we've now got a way of controlling both unipolar and bipolar stepper motors - so no matter where you salvage your motors from, we should have a way of offering a way of controlling them.

Now we have to get a bit nerdy and re-visit old school topics.
Back in the dark ages, those of us of a certain age will remember electronics, or even physics, lessons where we learned Ohm's Law.

Ohm's Law helps us to work out current and power requirements for controlling our stepper motors. We already know - from bitter experience - that if you ignore you basic power requirements, you'll quickly get through quite a few components, as you let the magic smoke out after just a few seconds of driving the motors!

We need to look at the things we can't change, and introduce elements to control those that we can.
For example, we're using the L293D stepper controller. It has a maximum current rating of 600mA (0.6A) per channel. That means, if we push more than 0.6A through the chip, it'll get hot, start to smell, and eventually burst into flames with a pop and a rush of smoke. Understandably, we don't want this to happen, so we need to introduce some resistors to limit the current.

This is where Ohm's Law comes in. Simply put:
V = IR where V=voltage, I=current, R=resistance
P = IV where P=power, I=current, V=voltage

Using these two equations, we can work out what type of resistors we need to use to limit current through the motor coils, to keep everything within safe limits.

As our stepper controller chip L293D has a current rating of 0.6A, ideally we want to drive the motors at not more than about half this (so that if the motor "spikes" or draws more current, to suddenly change direction, for example, we're still within safe limits).

We're going to use a 12V supply for driving the motors (because at a lower voltage, and lower current, the motor loses torque and can slip when driving a load). Now we just need to fill in the missing value:

V = IR; 12 = 0.3 * R; R = 12/0.3 = 40

So we know we want to use a resistor of roughly 40 ohms.
Common resistor values are 22R, 33R, 47R. If we increase the resistance too much, the motor will stall, so let's see what happens if we choose the 33R resistor:

V = IR; 12 = I*33; I = 12/33 = 0.36A
This equation has used only the resistance of the resistor. But we're putting the resistor in series with the motor coil - so we need to factor in the resistance across the coil(s) in the stepper motor.
The motor we're using has a coil resistance of 5 ohms (measure the resistance across your steppers with a simple multimeter - they're all different) so our total resistance is actually 38R.

So to find the current consumption, if we use a 33R resistor in series with the stepper motor coil(s):

V = IR; 12 = I*38; I = 12/38 = 0.32A

It seems that a 33ohm resistor in series with one side of each of the stepper coils results in the motor drawing just over 0.3A per phase. This is half of the current rating of the L293D driver chip, and seems like an ideal value.

BUT

Just shoving a regular 33R resistor in-line isn't going to do much good.
We know - from experience - that using puny little resistors with stepper motors means bad smells and lots of smoke! Why? Well, a typical resistor (the type you normally use with breadboard/prototyping boards) can have a resistance of between a few ohms, up to a few million ohms, but typically only handle about 0.25W

Watts are the units of power that the resistor can handle.
Watts are a product of voltage and current.
Ohm's Law tells us that P = IV (power = current * voltage).

So in our example here, we've a 12V supply and a 0.32A current draw.
The total power requirement is 12*0.32 = 3.84W
So we need a resistor with a power rating of at least 4W - ideally more.
It's no wonder that when we pushed current through our 0.25W resistor to drive the motors, they got hot and started to smoke very, very quickly! We're going to need to get hold of some power resistors and maybe a couple of heatsinks, to help keep them from getting too hot while in use.

Stepper motor control 2-phase 4-phase

2011-09-10T21:13:00.000+01:00

Critical to getting our CNC-based pick-and-place machine working is driving the stepper motors.
We've already managed to get some 4-phase, six-wire motors spinning using a ULN2803A darlington array. But the problem was the current was too great and they started to smell really quickly. Not much longer after that, the magic smoke get let out.

We stripped a Lexmark Z73 printer scanner and salvaged some motors, and even stripped the steppers from old floppy disk drives. So we've no end of stepper motors to play with, but not much luck in getting them turning. The main problem has been that the motors we took from the old hardware and donated stuff off Freecycle are all 4-wire 2-phase/bipolar motors.

We upgraded the original stepper circuit, replacing the ULN2803A with 4 x IRF640 mosfets. The IRF640 chips have built-in fly-back diodes (they're designed for driving inductive loads) so we don't have to worry about any extra external components. The "gate" is isolated and can use logic-level (5V) voltages to switch them on.

This allows beefier stepper motors to be controlled (up to about 16A) but they are set up to drive 6-wire/4 phase/unipolar steppers. We still didn't have a way of driving 4-wire/2 phase bipolar motors correctly.

Until today.
Thanks to Jason at BuildBrighton, we've got a few L293D half-H-bridge chips to play with. And they work perfectly for driving scavenged stepper motors. Here's how we connected each IC to the coils on a bipolar stepper motor.

So now we've got a way of driving both 4-wire, 5-wire and 6-wire stepper motors.
We've got a nice beefy PC power supply to provide the power without having to worry about running more than two motors together (the earlier 500mA phone-charger just wasn't up to the job!) and the stepper driver chips can handle up to 1A per channel (4-wire/biopolar) and a massive 16A or more for six-wire (unipolar) motors.

The trick is to make our driver board(s) compatible with any combination of steppers so that anyone else who wants to make one of these machines can source parts for it cheaply and easily.

At the minute we're trying out a number of different ideas and don't have enough time to devote to developing each idea, AND write it up on the blog with photos/diagrams/full descriptions. So over the next few days, we're going to play about with a few ideas then write up the most successful ones here......

CNC pick and place machine update

2011-09-09T23:46:00.000+01:00

After an evening at BuildBrighton, exchanging ideas and motor control circuits, we've had a re-think about our CNC-based pick-and-place machine. In fact, we've had several re-thinks, returned to abandoned ideas, discarded previously agreed ideas and gone around in circles enough times to make everyone very, very dizzy!

At first, we concentrated on making a machine that would be simple to understand during it's construction.
We concentrated on theoretical accuracy - using a small angle stepper motor, relatively few teeth on the cog, sticking to numbers that were easily divisible and so on. The problem with this approach is that actually obtaining parts is quite difficult - 1.8deg steppers are quite expensive (£20/unit) wereas cheaper, salvageable motors (from printers, cd drives etc) are more difficult to drive, and have peculiar voltage requirements.

Our compromise is this -

Where possible, use parts that can be salvaged from easily obtained hardware.
An old, obsolete PC could be a major source of parts - the power supply gives us multiple 5V and 12V supplies, the CD and floppy drives provide 4-wire (2 phase) stepper motors, specifically designed to run on 5V/12V. The IDE cables are perfect for connecting homemade PCBs to other parts on the machine (old hard drive cables use 0.1" pitch, the same as breadboard prototyping and lots of through-hole components, pin-headers etc).

Rather than concentrating on using motors and belts that make the maths for calculating steps per mm easier, we're going to build a machine that works with mostly salvaged parts. The final device will be a "puppet and playback" machine - the user will manually position the picking head either using buttons on the machine, or using a PC/software interface, then record the co-ordinates (in terms of steps rather than mm from a known origin) back to the PC/eeprom memory. Once one complete "animation" has been recorded, the script can be played back over and over again.

This way, the actual accuracy of the device becomes less important - it just has to be "accurate enough" to pick up a component and place it on the board. We're not going to be loading g-code type files into the device, or have to do tricky conversions from one format to another. The machine will simply use a record-the-steps-and-play-them-back approach for placing the components. So the actual distances travelled and units used won't matter; if you're using 1.8 deg steppers and half-stepping to give 400 steps/rev, with a 5mm belt, it doesn't matter how far between components the head moves: the machine will simply remember x number of steps on the x-axis and y number of steps along the y-axis. Someone using a machine with 7.5 deg steppers will simply have fewer steps in each axis to travel the same physical distance.

Talking of belts, we've decided to ditch them and go with a rack-and-pinion system.
This means we're removing another potentially costly part from the bill of materials - a 1.25mm belt can be had from a printer or a scanner, but it may be 1.2mm, or 1.25mm, or the imperial equivalent, a 0.05" pitch belt. All these belts need to have the right pulley or cog, with the teeth exactly spaced to match the belt.

By using a rack and pinion approach, everyone can use the same set of laser-cutting templates, and matching the right pulley/cog to your (possibly unknown) belt is no longer an issue.

CNC pick-and-place update

2011-09-08T16:37:00.000+01:00

We've spent a few days scavenging stepper motors from a variety of sources, and looking at what's available on eBay and other online sources. It's proved a bit tricky to decide exactly what to use for our pick-and-place machine; there are just too many options available!

It's a fine balance between scavenging and ease-of-use.
Typically, the easily accessible stuff (stepper motors from floppy drives, old printers and so on) is not so easy to drive - mostly they're high voltage (24V, 36V etc) and bipolar (2-phase, 4-wire) motors. While these are not impossible to use, they're more difficult to drive than our preferred uni-polar (5 or 6 wire) motors, which we've discovered can be run at lower voltages, using less current.

Current draw is proving to be an important consideration.
We've spent ages getting multiple motors working - albeit one at a time. When we introduced more than one motor at a time, our power supply (a 500mA phone charger providing 5V) wasn't up to the job. So we've upgraded the power supply and salvaged a PC power unit (PSU) which is good up to 400W, and gives us plenty of 12V and 5V power connectors.

The idea now is to use a PC supply (which should be easy to get hold of) and concentrate on 5V or 12V motors.

Unfortunately, we soon discovered that our original circuit was no good for higher voltage motors.
After beefing up the actual power supply, we managed to get more than one motor turning, but at a cost - a funny smell and a lot of smoke! It turns out that the ULN2803A chips we were using to drive the motors can only handle up to 500mA. And the motors were drawing 1A at 12V. Hence the darlington arrays blew after only a few seconds of usage.

This chip didn't just smell and smoke, it actually scorched the breadboard and blew the bottom off the chip when we tried to force it to drive two 1A motors at full belt!

All this means we've had to upgrade our stepper motor circuit.
We've replaced the ULN2380A chip with a series of IRF640 mosfets.
We need a single mosfet on each phase of the stepper motor coil(s) - i.e. four per motor (for a 4-phase unipolar motor). They include internal fly-back diodes and accept 5V logic level inputs, so are quite easy to use and require no extra components.

Here's a photo of the breadboard with the darlington arrays replaced with mosfets.
The benefit of this approach is that the mosfets can be used with low-power motors as well as the bigger ones, so the stepper motor driver will be compatible with a wider range of motors once complete.

The schematic is here - showing how to connect 4 pins from a PIC to 4 mosfets, for driving a single 6-wire/4-phase stepper motor.

[schematic pdf goes here]

Once we got the motor turning again, it was time to build the pulley for the belt-drive system.
We're using one of the belts we got out of the Lexmark Z73 - it's got a really fine tooth-pitch, about 1.2mm. So our cog/pulley needs to have a similar pitch to make the belt teeth fit snugly without slipping. We wanted as large a cog as possible, so that one single rotation moves the belt as far as possible. The larger to cog, the lower the precision, so like everything else, it's a fine balancing act to get the right combination.

Here's how we decided what to use:
The stepper motor is a 1.8 degree motor. This means 200 steps per revolution.
We're using half-stepping, so 400 steps/rev. The tooth-pitch is 1.2mm, or maybe 1.25 if the belt is imperial rather than metric (we can't be sure at this stage, so we're going to make the system, try it out and if there's any slippage, replace the cog/pulley for one with more/fewer teeth).
If we say our pitch is 1.25mm, then a cog with 40 teeth would move 40*1.25 = 50mm per revolution. At 400 steps per revolution, this means each step moves 50/400 = 0.125mm per step. This seems quite quite a nice level of accuracy.

The photo above shows a 40-tooth cog with a pitch of 1.25mm. It's pretty small.
So we thought, if we used an 80-tooth cog, we'd double the speed of the movement (80*1.25 = 100mm per revolution, or 100/400 = 0.25mm per step). Although not as precise, moving a head to within a quarter of a millimetre seems precise enough for a pick-and-place machine, so we decided to make a cog with 80 teeth.

Why pink? Just using up scraps of left over acrylic from a previous job! It wasn't a conscious decision to use pink over any other colour!

We added the disks above and below the cog to stop the belt slipping off the pulley during use. In fact, we found that our belt was every so slightly wider than 3mm (the thickness of the acrylic) so we created little spacer disks from cardboard, and used these between the disks and the cogs, to space them apart slightly.

With all the centre holes lined up, we stuck the multiple layers together and fitted to the stepper motor shaft (although the datasheet said the shaft was 6.25mm, we had to cut our holes 6.35mm to get them to fit and even then, it took some effort to get them onto the shaft!)

We made our cogs using InkScape.
It has a built-in gear maker. On a new document, go to the Extensions menu, Render, Gears:

By default, Inkscape uses 90 pixels per inch resolution. We decided that our belt is probably 0.05" pitch, so the circular pitch in pixels is 0.05*90 = 4.5

I found this diagram when looking for definitions such as circular pitch and pressure angle (I didn't know what they meant either!)

With the parameters in InkScape set, it was just a case of letting it create our gear by hitting apply:

With the gear created, we just needed to add the hole for the shaft. After much trial and error, we discovered that the ideal sized hole for the shaft was 6.35mm. We drew a circle with no fill colour and set the height and width to 6.35, then placed it inside the cog:

With both items selected, go to Object, Align and Distribute. Set "relative to" the biggest object. Then centre along both the x and y axis:

The end result is a cog with a perfectly centred hole for the shaft:

Which fits perfectly with our tiny-toothed timing belt. Or so it seems. We'll know for sure, once we've got the CNC machine up and running!

CNC pick-and-place machine needed!

2011-09-06T11:29:00.002+01:00

After spending hours and hours last night assembling and soldering just a couple of PCBs, the need for some sort of automation is growing - especially if we're going to realise the dream of actually making and selling a few miniature instruments.

So we're back to investigating a miniature CNC-type pick-and-place machine.
We've already got some stepper motors working and pulled apart a few printers and scanners, and have had no luck in finding exactly the types of steppers, belts and pulleys we were hoping to use.

Which has lead us down a slightly different path - instead of determining which types of stepper motors and belt-drive system we're going to use up-front, we're going to build a system which anyone else can build too - but using parts that can easily be scavenged from old computer hardware.

We dismantled an old Lexmark Z73 and found some useful looking stuff - stepper motors, carriage rods, belts and so on. None of these match our original cnc requirements (1.8deg steppers, 20-tooth pulley, 5mm pitch belts) but we've decided to change our approach, and build a machine using the parts we can get hold of. We'll write some software to drive our custom-made stepper board, so that you can simply enter a few parameters and let the computer do all the tricky calculations.

This sounds like we're heading towards Mach3/traditional CNC type ground - the original plan was to just build something that would work "out-of-the-box" without lots of difficult setting up and parameter fiddling. But then again, buying all new hardware is going to get quite costly for us, or anyone else wanting to make a similar machine, whereas re-using and recycling old computer hardware is a much more eco-friendly way to go about making stuff in general.

Here's our starting point - a stepper motor and a timing belt.

The stepper motor is a Mitsumi M42SP-6NK.

A quick look on Google returns the datasheet, telling us that it's a 7.5 degree motor, runs at 12V and has a peak current of 400mA. We marked one of the teeth on the cog, then counted them clockwise, and discovered that this motor is fitted with a 15-tooth pulley

The timing belt didn't reveal much - the serial number OPM 300766 returned nothing of interest, so we had to do a bit of investigating....

To find out the pitch of the belt, we need to measure from the centre of one tooth to the centre of another. This belt has tiny teeth, so we marked out 20 teeth using some masking tape and measured across the tops of the teeth with a steel rule (marked in 0.5mm spacing). Despite the photo's appearance, we made it 24mm across 20 teeth, making the belt pitch 1.2mm

This may or may not be correct. The belt may even use imperial measurement (e.g. 1.2mm = 0.0472 inches - it may be a 0.05" pitch belt and we've just not measured it properly!) All this can hopefully be corrected in software once we've actually got the machine built, entered a few parameters and calibrated everything fully!

Miniature Explorer and Flying V

2011-09-06T01:22:00.001+01:00

Following the Brighton Mini MakerFaire, and taking a few days off to help out at BuildBrighton (setting up stalls, packing away again, moving to the new hackspace and so on) it's time to concentrate on actually getting these miniature instruments finished!

Aaron from Oomlout came all the way down from Halifax to Brighton, especially for the MakerFaire but had already expressed an interest in the miniature guitars, so we demonstrated our early prototype. He wanted to buy one there and then! So we've set about making a few different guitars.

Here's a Flying V being put together in green. We've only got 1.5mm in white, so all the scratchplates and accessories have to be white for now - so we're trying to pick colours that will show up the scratchplate well (we're sick of making stuff out of red, black would be a bit boring, blue a bit dark....)

Below is an Explorer-shaped guitar (as played by U2's The Edge, and James Hetfield of Metallica - although they tend to stick to black rather than bright sunshine yellow!)

Then we had to make a whole load of pick-ups and embellishments.In this case, we're cutting them from 3mm black acrylic - the square-shaped ones at the bottom are humbuckers and the middle bits get covered in chrome sticker to make them look authentic (although for a Les Paul type guitar, the pick-ups are usually gold coloured, rather than silver, but we've only got silver!)

A few different guitar accessories - single-coil pick-ups, humbuckers, and bridge supports

The guitars being assembled - the red stratocaster is our working prototype. The others are new designs, which have taken quite a bit of trial-and-error to get right!

Brighton Mini MakerFaire

2011-09-04T14:55:00.004+01:00

This Saturday, 3rd September 2011, saw the first Mini MakerFaire come to Brighton.
And what a fantastic makerfaire it was - with over 5,000 people attending the one day event, running from 10am to 6pm. There are loads of photos all over the 'net, but videos are harder to come by - perhaps because it was such a hot and noisy event!

It was really nice to see so many HackSpaces attending - some of the more established ones like London and Nottingham, as well as the newer fledgling spaces like Manchester (Hac-Man, you gotta love it!)

There were some fantastic individual people displaying weird and wonderful gadgets too. There were loads of midi- and arduino- based music making machines...

...a guy in a white coat so he must have been a bona-fida scientist...

...magic mouldable rubber compounds for hacking even greater ideas....

...create-your-own-furniture design and prototyping services...

...amazing self-balancing skateboards...

...H2O-based music making (probably playing Hadel's Water Music - see what I did there?)....

...local celebrity Jane Bom Bane...

...wasn't the only person creating weird and wonderful hats....

Everyone had their own personal favourites. For me, the robotic drawing arm, part of the AI-Kon Project was just incredible to watch. Stylised drawing - with a biro no less!

There were 3D-printers...

...a soldering workshop and drop-in hack room...

...a whole world of craft and techo-textile mash-ups...

... including beautiful flowers from recycled materials...

... and workshops where you could sit and make your own...

There were stunning mosiacs....

...chain-mail-like metallic textiles...

...knitted and felt-making classes...

... rampaging robots who squirted unsuspecting passers-by, and blew smoke rings at them from behind!

There were intricate gingerbread mini-masterpieces...

... a giant etch-a-sketch...

... geeks....

... and nerds of all ages!

There was loads more besides - but by this point I'd just forgotten all about the camera and was wandering around, staring in wide-eyed marvel at all the brilliant (and bizarre) things there.

One of the best things about the makerfaire is that it was a truly family event - mums and dads were amazed at the technology and work that had gone into a lot of the exhibits, while the kids laughed and squealed at anything that beeped, farted, or flashed. The overall feeling at the makerfaire was that the Maker Movement in the UK has finally got a bit of momentum behind it. And with so many kids taking an interest, it's not just a middle-aged big-boys-club of shed-dwellers: making stuff is really accessible to everyone now - it's an exciting time to be a geek or a nerd!

Red	Green	Blue
0	0	0
0	0	1
0	0	2
0	0	3
0	1	0
0	1	1
0	1	2
0	1	3
0	2	0
0	2	1
0	2	2
0	2	3
0	3	0
0	3	1
0	3	2
0	3	3
1	0	0
1	0	1
1	0	2
1	0	3
1	1	0
1	1	1
1	1	2
1	1	3
1	2	0
1	2	1
1	2	2
1	2	3
1	3	0
1	3	1
1	3	2
1	3	3
2	0	0
2	0	1
2	0	2
2	0	3
2	1	0
2	1	1
2	1	2
2	1	3
2	2	0
2	2	1
2	2	2
2	2	3
2	3	0
2	3	1
2	3	2
2	3	3
3	0	0
3	0	1
3	0	2
3	0	3
3	1	0
3	1	1
3	1	2
3	1	3
3	2	0
3	2	1
3	2	2
3	2	3
3	3	0
3	3	1
3	3	2
3	3	3

Red	Green	Blue
0	0	3
0	1	2
0	1	3
0	2	1
0	2	2
0	2	3
0	3	0
0	3	1
0	3	2
0	3	3
1	0	2
1	0	3
1	1	1
1	1	2
1	1	3
1	2	0
1	2	1
1	2	2
1	2	3
1	3	0
1	3	1
1	3	2
1	3	3
2	0	1
2	0	2
2	0	3
2	1	0
2	1	1
2	1	2
2	1	3
2	2	0
2	2	1
2	2	2
2	2	3
2	3	0
2	3	1
2	3	2
2	3	3
3	0	0
3	0	1
3	0	2
3	0	3
3	1	0
3	1	1
3	1	2
3	1	3
3	2	0
3	2	1
3	2	2
3	2	3
3	3	0
3	3	1
3	3	2
3	3	3

Red	Green	Blue
0	0	0
0	0	1
0	0	2
0	0	3
0	1	0
0	1	1
0	1	2
0	1	3
0	2	0
0	2	1
0	2	2
0	2	3
0	3	0
0	3	1
0	3	2
0	3	3
1	0	0
1	0	1
1	0	2
1	0	3
1	1	0
1	1	1
1	1	2
1	1	3
1	2	0
1	2	1
1	2	2
1	2	3
1	3	0
1	3	1
1	3	2
1	3	3
2	0	0
2	0	1
2	0	2
2	0	3
2	1	0
2	1	1
2	1	2
2	1	3
2	2	0
2	2	1
2	2	2
2	2	3
2	3	0
2	3	1
2	3	2
2	3	3
3	0	0
3	0	1
3	0	2
3	0	3
3	1	0
3	1	1
3	1	2
3	1	3
3	2	0
3	2	1
3	2	2
3	2	3
3	3	0
3	3	1
3	3	2
3	3	3

Red	Green	Blue
0	0	3
0	1	2
0	1	3
0	2	1
0	2	2
0	2	3
0	3	0
0	3	1
0	3	2
0	3	3
1	0	2
1	0	3
1	1	1
1	1	2
1	1	3
1	2	0
1	2	1
1	2	2
1	2	3
1	3	0
1	3	1
1	3	2
1	3	3
2	0	1
2	0	2
2	0	3
2	1	0
2	1	1
2	1	2
2	1	3
2	2	0
2	2	1
2	2	2
2	2	3
2	3	0
2	3	1
2	3	2
2	3	3
3	0	0
3	0	1
3	0	2
3	0	3
3	1	0
3	1	1
3	1	2
3	1	3
3	2	0
3	2	1
3	2	2
3	2	3
3	3	0
3	3	1
3	3	2
3	3	3

Red	Green	Blue
0	0	0
0	0	1
0	0	2
0	0	3
0	1	0
0	1	1
0	1	2
0	1	3
0	2	0
0	2	1
0	2	2
0	2	3
0	3	0
0	3	1
0	3	2
0	3	3
1	0	0
1	0	1
1	0	2
1	0	3
1	1	0
1	1	1
1	1	2
1	1	3
1	2	0
1	2	1
1	2	2
1	2	3
1	3	0
1	3	1
1	3	2
1	3	3
2	0	0
2	0	1
2	0	2
2	0	3
2	1	0
2	1	1
2	1	2
2	1	3
2	2	0
2	2	1
2	2	2
2	2	3
2	3	0
2	3	1
2	3	2
2	3	3
3	0	0
3	0	1
3	0	2
3	0	3
3	1	0
3	1	1
3	1	2
3	1	3
3	2	0
3	2	1
3	2	2
3	2	3
3	3	0
3	3	1
3	3	2
3	3	3

Red	Green	Blue
0	0	3
0	1	2
0	1	3
0	2	1
0	2	2
0	2	3
0	3	0
0	3	1
0	3	2
0	3	3
1	0	2
1	0	3
1	1	1
1	1	2
1	1	3
1	2	0
1	2	1
1	2	2
1	2	3
1	3	0
1	3	1
1	3	2
1	3	3
2	0	1
2	0	2
2	0	3
2	1	0
2	1	1
2	1	2
2	1	3
2	2	0
2	2	1
2	2	2
2	2	3
2	3	0
2	3	1
2	3	2
2	3	3
3	0	0
3	0	1
3	0	2
3	0	3
3	1	0
3	1	1
3	1	2
3	1	3
3	2	0
3	2	1
3	2	2
3	2	3
3	3	0
3	3	1
3	3	2
3	3	3