Recently I’ve been making a lot of printed circuit boards. One of the common problems I run into is aligning holes correctly when hand drilling. This is especially troublesome on boards with large arrays of pins, such as my hexapod controller (I promise I’ll write that up soon!). A misaligned hole will prevent IC sockets from fitting correctly or cause pin headers to sit at crazy angles. This is really obvious on the first version of my hexapod controller board as shown below.
In order to work around this for the second version of the hexapod board I used my CNC machine to drill the holes. This is great for relatively large jobs, but the setup time makes it less attractive for small one off boards.
Since I was scheduled to have an induction on Nottingham Hackspace’s new laser cutter and given the option of cutting my own project during the induction, I came up with a simple mechanical solution to drilling holes at the 0.1 inch spacing required for most IC sockets and pin headers.
The concept is very simple: a zigzag line is cut through a piece of plywood with a “wavelength” of 0.1 inches. One side of the cut is clamped to the work surface of a pillar dril,l and the board to be drilled is taped to the other side. The serrated edges can be moved around, and when pushed back together they naturally align to multiples of 0.1 inch. I went with a sawtooth style wave in the end so pressure can be applied in towards the flat edge of the sawtooth without the piece slipping.
The photo above shows masking tape, but double sided tape would have worked better if I’d had any with me when taking the photos.
In order to make grid style layouts I added a second layer of serrations at 90 degrees to the first. I’ve not had chance to test this as the work area of the pillar drill I’ve been using does not have space. The intended usage is that both of the outer stages would be clamped in place and the inner piece manipulated by hand to drill columns of holes. Once a column is complete the middle stage would be un-clamped, adjusted then re-clamped. This is repeated for as many columns as necessary.
I’ve used the jig with a single stage on a few boards now, and it works well so long as the initial hole is well aligned. An easy way to ensure this is to align the drill bit with the smallest hole in the row and then clamp the jig in place.
To ensure that the board is aligned correctly in the jig, I usually find the longest run of holes on the board and put a ruler against the edge. Drawing a pencil line along the ruler provides alignment marks on the board that can be matched up with the etched lines on the jig.
In the current version, the inner section of the jig is a sacrificial piece which will eventually become full of holes. I toyed with the idea of making the inner section in an L shape into which the board would fit, but this would rely on the edges of the board being cut exactly parallel with the grid so it’s less useful in practice. Hopefully the sacrificial part of the jig will last long enough, and it’s cheap enough to just make another when it wears out.
Earlier today I used the jig to make a very simple breakout board to match the pinout from an FTDI board to an Arduino style six pin header. The 6 pin header and 32 pin (minus 4 due to the weird layout on the FTDI board) IC socket I used fitted perfectly first time.
I’ve made the CAD drawing for the jig available to download. Hopefully it will be useful to someone.
Charlie’s SuperGun had me inspired to build my own at some point, but I thought I’d start at the other end and build some appropriate controllers first. Partly as a birthday present to myself I decided to make a pair of arcade control panels.
After a long time reading SlagCoin, I settled upon a fairly simple box design with a joystick and 6 buttons on the front face and a pair of buttons on the left and right. I eventually settled on a black and white theme, with a black Perspex face plate and white buttons.
I just finished participating in the 28th Ludum Dare game jam. This time around the theme was ‘You Only Get One’.
I chose to interpret this fairly literally as a game mechanic and came up with Loot of the Forest. It’s a game about bribing forest guardian creatures as you make your way through their forest maze, but you only have a single item per species of guardian.
I’ve been a bit quiet on here for a while, and slacking on the PCB milling experiments I’ve been meaning to do, though I have made some progress on that front.
Anyway, here’s what I got sidetracked by building:
This is a small budget hexapod, using 18 of the cheapest servos I could find (£2.50 each). It uses a custom board with a power supply and 3 shift registers to control the servos. This in turn is controlled through an SPI bus to a Minimus USB AVR board, pretending to be a USB to serial device. The data sent over the serial line is interpreted as servo IDs followed by the desired position of the servo.
Mark 2 servo controller board
The control software I wrote for the hexapod can run on any Linux computer with a USB port. For dev I use a netbook but it also runs nicely on a Raspberry Pi.
The original plan was to use the Raspberry Pi’s SPI port to control the servo board directly, unfortunately due to Linux’s scheduling not being particularly real time even in real time mode there was a lot of timing jitter leading to real life servo jitter. Switching to the Minimus meant having a very dedicated if much slower CPU generating the pulses resulting in much smoother control of the servos.
I’ll hopefully post a full making of post on the hexapod soon, but for now I just wanted to post a video of some stomping!
Guest post by Charlie again as he continues his quest to take over Moop’s blog with his super long posts:
Then here’s a video instead…
Recently I got into arcade boards. They can be found reasonably cheaply on eBay and as most use the standard JAMMA connection, setting these up so you can play them on a TV at home is pretty straight forward. Especially in Europe where SCART is still widely used and thus almost all TVs have an RGB input.
I built a very traditional supergun (device that allows you to play JAMMA boards on a TV) last year. It was time consuming but it wasn’t particularly hard. It used a PC ATX power supply to supply the voltages needed (-5V, +5V and 12V), audio/video output was via SCART and Neo Geo AES pin compatible D-SUB 15 plugs for the controller inputs. Here’s a couple of pictures of my first effort…
Once I started getting more boards, I found that some bootlegs drew a heck of a lot of current. So much so that the voltage drop over the half a meter or so of wiring between the PC supply and the board was causing the boards not to power up (due to the voltage drop across the wire). I initially tried solving them by using some wider gauge wire in parallel to feed the board. This worked but for some bootlegs I owned even this wasn’t good enough. I was reading as close to 5V as I could get at the connector but measuring the voltage on distant parts of the board, the voltage had dropped to sub 5V. I needed something better.
I could have got a JAMMA power supply off eBay with a variable voltage output. This was initially tempting but I just couldn’t bring myself to use one for safety reasons. On all the ones I saw the mains power was just wired into screw terminals. This is fine as it’d be inside my super gun’s case. The thing that worried me was that the outputs were right next to the mains screw terminal. The boards aren’t in a cabinet like a traditional arcade, they just lay on top. If the mains lead became loose there is a possibility of the board becoming live. This may sound surprising coming from the person that made his own bluetooth controlled mains plug, it wasn’t a risk I wanted to live with.
So, I went looking for a variable DC/DC convertor that could transform a lot of current without needing any active cooling. After some searching I came up with http://docs-europe.electrocomponents.com/webdocs/0eec/0900766b80eec532.pdf. With this I could power the 5V line from the 12V output of the ATX power supply and add a pot to adjust between around 5-6V so even my very power hungry boards would be happy.
With this done I felt I had a reasonable design. Then with Christmas coming around I decided I could make another one for a friend as a present. Building the first one, I wasn’t really thinking about the time it took as I built it and tweaked it over a couple of weeks. Even knowing exactly how to build it now, it still took at least 10 hours to actual do it. I made a few improvements along the way but it was a tedious build due to the huge number of wires involved (>100 connections) and all the modifications needed to the case. Also, even with a lot of salvaged parts (the ATX power supply, the SCART plug etc) it also ended up being quite expensive at about £50. A lot of this was due to the case which was quite hard to find as it needed to be tall enough to fit an ATX power supply.
With that out of the way I vowed never to make another supergun again….. but of course I did. I just kept thinking I must be able to make a better one. After trying the toner transfer method for the first time, it got me thinking that I could do away with almost all the wires by just making a supergun PCB.
Starting the design of a supergun PCB, I really wanted to make it as compact as I possibly could while still making it easy and cheap to assemble. One of the ways to do this was to leave out anything superfluous. The JAMMA standard has various service switches but not all need hooking up. COIN1/COIN2 are the coin inputs for adding credits. These are useful to have on the controller so I wired these to the AES controller’s select button as this would otherwise not be used by JAMMA boards. SERVICE on every board I own also just gives credits so I left this out. TILT (for detecting people shaking the machine) is rarely hooked up on superguns and I suspect does nothing interesting on 99% of boards. This only leaves TEST which is useful so this got it’s own microswitch on the board.
Power was pretty easy. One reason to use an ATX power supply is that it supplies the -5V that the JAMMA specification requires. However, looking at my collection of arcade boards, one 1 (out of around 10) uses the -5V line at all. They were normally just used for older types of audio amplifiers (my one board which does use it works without it but just without sound). I felt fairly comfortable with just leaving the -5V line out all together. This decision along with using the same DC-DC convertor from my original design means the supply only has to be 12V. Many laptop power supplies are 12V, compact, cheap and can supply plenty of current.
The rest of the design mapped quite nicely to the PCB concept. PCB mounted DSUB and SCART connectors are common. How to connect the JAMMA edge connector was slightly more difficult. However, I noted that two standard 1.6mm PCBs stacked on top of each other was almost exactly the tag separation on the rear of the JAMMA connector. I could make a small board that sat on top that could then run the signals for the top back of the connector down onto the bottom board. Both boards I designed to be single sided (for ease of creating at home) although because they sit on top of each other it does effectively make it partially double sided.
The design was quick to knock up in Eagle (maybe too quick as we’ll see later) but when I came to lay it out I hit my first snag. The free version of Eagle is restricted by the size of the board it will let you lay out. The longest dimension is 10cm. This wasn’t long enough to connect to every pin of the JAMMA connector. In fact, it was 3 pins short. Luckily of these three, one is unconnected and the last two are ground which exists on the other side of the connector anyway. It would have been nice to connect these additional grounds but I didn’t see much harm in leaving them floating (assuming the grounds are connected on the arcade board itself). So I designed the board to the Eagle limitations and just added terminals at that end of the board if in the future I wanted to wire the extra grounds in with some short jumper wires.
Laying out the board itself was straight forward but time consuming as I wanted to keep the layout single sided (with no jumpers) as it needed to be simple to etch at home using hobbyist processes like the toner transfer method. As such I needed to keep the traces fat too. This led to another compromise. Because the traces had to be fat and single sided fitting two controller ports was just too difficult. It’s something I’d like to fix in a future design if I was just going to get it professionally manufactured via PCBcart or similar.
Construction wasn’t particularly interesting and was quite straight forward. It was only my second attempt at the toner transfer method but the traces were fat enough that I could fix most problems by hand with just an etch resist pen. It wasn’t perfect but I was fairly pleased with the end result.
Soldering the various connectors was quick and painless. The only difficult bit was lining up the top and bottom boards to make the double sided portion. Although because the via pads were quite big the positioning wasn’t that critical and any slight alignment problems could be fixed by just adjusting some of the drilling locations.
Once the components were all added, it was ready to test!
Once everything was assembled I grabbed my male to male SCART cable and immediately realised I had made a mistake. I knew I’d made a mistake as I’d made the exact same one with my friend’s supergun. Male to male SCART cables don’t map all the pins through one to one. Most do but some are crossed over, so for example the audio output pins on one side go to the audio input pins on the other. And the same for the video signal. D’oh! So, out came the scalpel the offending traces were cut and replaced by bodge wires.
Tried again and this time the game sprang to life, everything was great and then I noticed the colours were off. A quick check on the Neo Geo test menu showed red and blue were reversed! Two mistakes on the same board was quite embarrassing. I know exactly how it happened though as when I tried to fix it, I made the exact same mistake. I initially wired up the RGB pins on the SCART from memory and then checked them before doing the board layout. I saw the mistake at this stage and thought I had corrected it. Everything was connected via named labels in the schematic so I just renamed the label on the pin (say from RED to BLUE). Eagle asked “Do you want to connect RED to BLUE?”. Thinking this would then cause all the pins to connect I said no but assumed the rename had worked. Nope, I’d just done nothing. A second, “D’oh!”.
So back out came the soldering iron and another set of bodge wires causing the final board to be a messier than I would have liked but everything I have thrown at it has worked so I’m quite pleased with the results. Everything works as well as my big traditional super gun but now it’s in a very tiny portable package.
Make your own
I made this as my contribution to the super gun / JAMMA comunity so I’ve fixed up my board layout (the swapped channel problem etc) and I’m offering it as a download here: Minigun – Final (EAGLE file format). I hope people will build there own, make improvements and share these improved versions with the community.
Nb: The current design has the SCART socket mounts overlapping as the connector I used had a different mounting to the stock one in EAGLE. Also the single top layer trace is the 5V line to the controller port. I don’t use this in my home-brew controllers so I left it unconnected but if you did want to use AES controllers you may have to solder a jumper wire between these points.
I was partway through writing a draft for a post about PCB milling when I realised I hadn’t yet written anything about the machine I’ve been using, so I think it’s about time for a post about the eShapeOko CNC machine I built.
I ordered the mechanical kit only, so no motors or electronics were included. To kill time while the much awaited parcel made its way to me, I ordered a pair of EasyDriver stepper controllers and some stepper motors to experiment with. The EasyDriver boards aren’t particularly cheap but very easy to use, just supply power, ground, connections to the motor and signals for Step and Direction.
I soldered some pin headers onto the boards to break out all of the pins I needed. With them plugged into a breadboard I could easily experiment with driving them via a Minimus USB microcontroller board. Thanks to the simplicity of the stepper controllers I had it driving the motors nicely within an hour, though unfortunately I shortly after discovered several ways to fry the Allegro A3967 chip that the EasyDriver is based on.
EasyDriver stepper boards
The first mistake was forgetting to power off the boards while unplugging a motor. The controller keeps the coils in the stepper motor energised continuously in order to hold the motor steady. Suddenly removing the load tends to fry the controller. When I make a permanent controller board for the machine, I plan to use locking connectors to avoid absent mindedly unplugging the motors in this way.
The second mistake was playing around with circuit on the breadboard while it was powered up. I accidentally connected the Step input to my 12v supply instead of the regulated 5v output that the EasyDriver provides.
Either way, I now had two unusable EasyDriver boards. Fortunately the A3967 chips are available for about 1/4 of the price of the EasyDriver board, so I was able to order some replacements. Despite being surface mount chips they were relatively easy to replace, with a fine tipped soldering iron. The hardest part being removing the old chips as the solder wicks under the pins. Some brute force was required, but not too much as it is easy to peel up the tracks.
With the stepper controllers proven to work (once refurbished) I ordered an additional board to control the third axis.
The next step was to get something in place to act as a controller. I briefly considered writing my own but decided it would add a lot of work and even more unknowns. After looking around online I decided on GRBL. GRBL is a CNC controller firmware designed to run on an Arduino, and thanks to a conveniently timed workshop at Nottingham Hackspace I had an Arduino board I’d built lying around. GRBL takes instructions in G-Code — which is a fairly standard language for controlling CNC machines — and outputs step and direction pulses.
GRBL is designed to read G-Code through the Arduino’s serial port, so a USB to serial converter was required (and was also required to program the Arduino). Fortunately, the trusty Minimus board came to the rescue, along with some instructions provided by Reading Hackspace. With a Minimus acting as a USB to serial adapter, I had the electronics side of the machine in place (albeit cobbled together).
Cobbled together CNC controller
I’ll cover the mechanical side of it in another post.
It’s me, Charlie again, continuing with my scheme to take over Moop’s blog with nothing but home automation articles.
Readers of this blog will know that I’ve been playing around with LightwaveRF’s home automation stuff a lot recently. Mainly setting up voice control systems for it. One thing that irked me though was that to control the devices across the network requires a £65 ($100) box called the WiFi link (http://www.lightwaverf.co.uk/LighwaveRF-Connect-Home-Automation-Smartphone-Wifi-Link-White.html). This seemed a bit much to me but I shelled out the money as there didn’t seem to be any option. However, when someone at work started asking about it, it got me thinking if there could be a cheaper way. Maybe it’d be possible to hack the much cheaper mood controller (http://www.lightwaverf.co.uk/LightwaveRF-Connect-Home-Automation-Hand-Held-Remote-Control-Black.html) to be controlled from a Raspberry Pi (or any cheap microcontroller) directly.
So, I started by cracking open the controller I got free in a 3 bulb bundle. At first there didn’t seem to be any screws at all. Peeling back the label revealed one though. Even with the screw removed however, it remained stubbornly in one piece. So, I got my spludger out and worked it into the gap of the case. Working my way around I found tabs that needed releasing.
Once inside, I got my first surprise. There’s more buttons on the circuit board then there are on the front of the device. I didn’t try these buttons but I am curious to know what they are there for.
Next nice surprise was that the switch electronics were very simple for the buttons I wanted to hack (the on/off and device select slider). All three controls clearly weren’t multiplexed as they all shared the battery’s ground. This made the hack a heck of a lot easier. Next up was checking with a multimeter that the other terminals of the buttons were pulled high. Checking the on and off buttons showed 3V, which is close enough to drive from the Pi’s 3.3V logic. The slider however, showed no voltage. Checking on the oscilloscope revealed that the slider switch was only powered for a split second when either the on or off button was pressed, presumably to save power. The first three pads do this but the fourth is never powered. I assume this pad isn’t actually used as if the switch isn’t in the first three positions, then it logically must be on the fourth pad.
With everything working as expected I soldered on my connections and connected these to a header.
The program to actually interface with the device was very easy. I originally planned to use the tri state logic function to simulate the button being open. This didn’t seem to work however so in the end I just used a logic high output. This is a bit wrong as the Pi outputs 3.3V logic which is higher than the potential of the controller but doesn’t seem to cause problems. To simulate the button being pressed, a logic low output is generated from the Pi. For the slider, I just need to pull one of the three lines low or keep them all high to select device 4.
Naturally I made a video to go along with this hack…
Once again, it’s not moop but Charlie, so we’re talking home automation instead of planes.
My last video on home automation turned out to be surprisingly popular! So, to celebrate I’ve done a quick follow up on the same idea. One thing people commented on was that I should have used SiriProxy. I had considered this when writing Jeeves (http://www.youtube.com/watch?v=gZkwvSX0_Os). I felt it wasn’t quite as cool as having a device that listens all the time though. However, SiriProxy doesn’t seem to require a huge amount of processor time so can run happily next to Jeeves even on a Raspberry Pi, so I thought I’d give it a go.
Setting up was amazingly easy. I basically followed the instructions verbatim from the main SiriProxy page (https://github.com/plamoni/SiriProxy). There’s a lot of complicated guides for old versions of SiriProxy but the latest version is quite simple to setup, so just follow the instructions from the main page.
The only thing I did differently to the instructions was that I had to copy my .siriproxy directory from my user directory to /root/.siriproxy. This is probably because when I generated the certificates, I wasn’t root. You should be able to run SiriProxy as an unprivileged user but I didn’t get that to work. It’s only on the Pi so, I don’t have any reservations about running SiriProxy as root anyway, so I just went with it.
Once the Pi was set up and running, all that was left was to set up my phone. This required e-mailing the generated certificate and changing the WiFi settings so that the DNS server pointed at the Pi.
With that working, next was the fun part of actually making a plugin for SiriProxy so it would do my bidding. There’s already a LightwaveRF plugin but what’s the fun of being like everyone else! Naturally I wrote my own. It’s might be worse that the existing plugin, I didn’t check before writing my own version.
The first hurdle to overcome was that the plugins need writing in Ruby. I’d never even seen Ruby code until I wrote the plugin so I probably didn’t do things in the most efficient way but it was easy to get something working.
The main bulk of the plugin consists of these clauses…
listen_for /some regex/ do |variables,to,store,matches|
say "Hey I recognised that"
Adding the lightwaveRF UDP protocol was easy from Ruby. First a socket is created and the host/port set up with…
s = UDPSocket.new
port = 9760
host = "192.168.0.10"
To turn on a device can then be done with only one line…
s.send("000,!R1D1F1|Siri|On", 0, host, port)
Each room contains a list of sockets that it has. When saying “There is a desklamp in the left socket”, it first matches via a regular expression and extracts the two important bits, “desklamp” and “left socket”. Next it verifies that “left socket” is a socket it knows about. If it is, then it inserts a new entry into the “items” hash map linking “desklamp” to the left socket.
When you say “Turn on desklamp”, the word “desklamp” is looked up in the items hash map. If it finds a match then it sends the required command to the socket it was registered with. If it doesn’t find anything in the map then it will check for a socket called “desklamp”. Being a lazy programmer, the lights use this trick as they are implemented as just another socket. I could say “There is a banana in the lights” and I would be able to turn on my lights by saying “Switch on banana”. That sort of bug, I don’t mind letting slip through though as it’s a remote possibility anyone would try.
I think that pretty much covers it. I hope someone finds it fun and has a go at implementing their own system.
It’s not moop today but me again returning as a guest contributor. So, it’s not planes or lathes today but wireless plugs and stuff.
If you read my last blog post (http://www.moop.org.uk/index.php/2013/05/27/homemade-wireless-plug/) you’ll know that I tried building a cheap Bluetooth controlled plug socket that’d fit in a standard back box. When it came to actually installing though I got cold feet. There are safety and legal issue to fitting something like that into the wall so instead I opted for a commercially available version. I choose the LightwaveRF range of plug sockets and dimmer switches. These are just like what I was designing in that they just replace the standard fittings and are switchable remotely. With the LightwaveRF Wireless Controller this also includes controlling them across the network. They are pricey compared to my design but on the other hand, look a lot nicer and far less likely to catch fire.
The LightwaveRF network protocol is a fairly simple UDP scheme that’s very easy to hook into (http://blog.networkedsolutions.co.uk/?p=149). The only strangeness is having to send a message with ID 533 first time to get the LightwaveRF box to prompt to register a new device. Coding this only took a few minutes and once that was working the only thing left was to think of something to do with it!
The most obvious thing to me was to live out Star Trek (http://www.youtube.com/watch?v=hShY6xZWVGE) by controlling things in my house by talking to them. “Computer, lights on” for example. I didn’t want to leave a computer running all the time but I did have a Raspberry Pi lying around which I’ve been wanting to find a use for.
So, I started by looking for voice recognition technology to use. Doing a quick Google, bought up a lot of suggestions to use Google’s voice API (they would say that! ). As much as I like Google, I don’t really want everything I ever say getting sent to their servers, so that was out. Next best choice seemed to be CMU Sphinx. pocketsphinx is designed for embedded systems so seemed a good fit for the Pi.
On first impressions I was very unimpressed with CMU Sphinx. The accuracy of recognition seemed absolutely terrible. However it does have facilities to work with a subset of words for doing digit recognition for example. With a text file of commands I wanted it to recognise the lmtool (http://www.speech.cs.cmu.edu/tools/lmtool-new.html) creates all the files needed. Using these files the quality of recognition improved considerably. However there were still problems distinguishing “on” and “off”. Also the word “Computer” was frequently misunderstood. So accepting this as a limitation of voice control, “Computer, lights on” became “Jeeves, lights up”. Finally I adapted the voice model (http://cmusphinx.sourceforge.net/wiki/tutorialadapt) which improved the voice recognition even further.
Up until this point I’d been doing everything on my laptop but moving this to the Pi was fairly straight forward. I now needed some sort of microphone though. I tried Singstar mics at first. These worked straight off but didn’t really do a very good job unless speaking directly into them. So next I tried another of my discarded game accessories, a PS3 Eye camera. This worked much better when picking up sound from across the room.
For sound output I used a pair of cheap PC speakers which I could connect to the 3.5mm audio jack on the Pi. I had spent some time trying to sort out a problem where the first second or so of audio when using HDMI output was silent. I tried updating the firmware and googled around for the answer. In the end I worked around this by appending a second of silence to the start of my audio output with sox. However when using the speakers the problem just went away anyway much to my relief.
As a finishing touch I made a quick LED display to indicate when the Pi was ready to accept the next command. While doing this, I decided to also wire up an IR LED so I could control the television too. Not having IR LEDs in my parts draw I just cracked open an old remote and took the LED out of there. I connect this to GPIO 7 as an arbitrary clock can be generated on that pin. I used this to provide the 38KHz modulation needed for my TV. I then toggled that pin between clock and a zero output in software to encode the commands to control the TV. This did not work at first. I could see on my laptop’s webcam that the IR LED was flashing away but the TV did not respond. Cracking out the oscilloscope I found that the pulses when the output was a clock were all around 200us too long. I assume this is due to a delay in toggling the state. I decided to take the easy way out and just adjusted these timings. After these adjustments I was successfully able to control my TV using just an IR LED and a resister.
So enough talk, here it is in action…
Nb. The source is downloadable here Lightwave Source. I warn you now though it’s some pretty ugly code. A lot of this coding was done crouched on the floor working directly on the Pi. Getting back off the floor was my top priority, not following any coding standards. Still thought I should include it just in case anyone wanted some reference. The main guts, speech.c is just a modified version of the pocketsphinx continuous speech sample. irTrans turns the TV on and off and lightwave.c deals with the network side of things. speaker.c just keeps festival open so I don’t have to pay the start up time when doing voice synthesis. Hope it’s helpful to someone.