Author Archives: Jason Hotchkiss

The Making of Ant Attack!

Someone sent me this clip and wow, what memories came flooding back.Ant Attack on the ZX Spectrum was the first computer game that not only totally hooked me, but made me think “I wanna be able to do that”. At one point, circa 1984, I could even beat t… Continue reading

Posted in News | Comments Off

ARPIE – Arduino based MIDI arpeggiator kit

Since I made my first Arduino-powered MIDI arpeggiator a couple of years back I have been meaning (and promising) to get a kit together so others can build their own. Today I listed my first “fundraiser” on Tindie. Hopefully that will raise enough cash… Continue reading

Posted in News | Comments Off

Building an Arcade Button Monome-likey

I’ve had quite a lot of fun with the Novation Launchpad, building interactive MIDI sequencers and control surfaces. For a while I’ve had the idea in mind of making an Arduinome (an Arduino powered DIY Monome MIDI controller)

When I was working with Will Nash on the Noisy Table, I really got to like the micro-switched arcade buttons that we fitted to the table to control the sounds. And so it was I hatched a plan to make a Monome style grid controller using arcade buttons. I soon found it had been done before, but it looked so cool it just encouraged me more.

I bought the switches quite a long time before I really decided exactly how I was going to use them. They have translucent white plungers with an LED holder in the microswitch clip at the base. The supplied LEDs were white and resistored up for 12V (I guess as a drop in replacement for filament bulbs in arcade machines). I decided to replace them with RGB LEDs, but I needed to make sure I had  a decent scheme for doing this, since I needed to wire up 80 of these switches and didn’t want to end up making the same mistake 80 times!

12V LED modules and sockets

Microswitch heaven!

What I ended up with was breaking a matrix board into little squares, so I could thread the leds of the 5mm RGB LED through the holes and slide the board into the socket in place of the white LEDs modules. This worked nicely to connect the common anode and one of the cathodes to the LED socket. I was then faced with somehow getting a connection through to the other two cathodes while not interfering with the operation of the switch.

I have a big roll of Kynar wrapping wire that comes in very handy for this kind of thing. Kynar wire is a single core wire with a very thin insulation layer, so it easily gets  through the tiniest of holes and gaps. I could solder two wires to the remaining LED cathodes and thread them down through the socket and out between socket and switch. Since the thin single core wire can be brittle I used little blobs of superglue to anchor the ends after soldering (Its amazing how much more useful superglue becomes if you get a spray can of activator, which sets the glue off instantly – even in  blobs)

I am driving my LEDs with LPD6803 chips, which I have a big batch of from an eBay bargain. These are chainable 3-channel, constant current, self-running PWM controllers with a 2 wire serial interface. They allow 5 bits per channel of PWM resolution (Maybe the 8-bit PWM WS2801 would have been better, but I think these LPD6803′s are good enough, and they are what I had)

Every single LED needs its own controller chip… thats 80 chips… how to fit them all in? I considered putting an LED driver board on every button but quickly decided that wasn’t going actually to make life any easier. In the end I decided to put 8 driver ICs on a PCB and have one PCB per grid column (so 10 boards). There would be a lot of wire in there, but it seemed the most straightforward way to build it.

I’ve recently started getting small batches of PCBs made up by a supplier in China (ITEAD), and these driver PCBs are only the second batch I have ordered. Just getting the thing wired up to see if it worked (or if I had badly messed up my PCB design) took a long time and the suspense was killing me –  but finally I was able to connect up an Arduino to send some data to it… and it worked!!

As well as the 8 x LPD6803 chips the PCB contains a 74HC165 parallel input shift register for reading the switches. I wasn’t going to count my chickens until I’d also tested the input part. Wooo, that worked too! (Eventually the input and output driver chips for all the boards will be chained together so the last test will be whether that all works)

The console for the grid is laser-cut 5mm acrylic. I had considered making a box completely out of acrylic, but wondered how sturdy it would be. Eventually I settled on building the box into a flight case and thought cases designed to house 19″ rack-mount mixers would be perfect. The one I got is a Reloop case from eBay, where if cost about £75. Not the cheapest way of getting a housing, but it should be good for a few knocks.

So… looks like I have a lot of wiring to do! I am still not certain how I will drive it when its finished, but most likely I will use an Arduino.

Continue reading

Posted in News | Comments Off

Making a POV globe


I’ve wanted to make a “globe POV” for a while after seeing a totally amazing hi-res one on YouTube a while back. The mechanical side of it (motor drive and power supply) always put me off a bit – while I think I can design a PCB and feel pretty confident it’s going to work, motors, gears and bearings are still a matter of kludge and guesswork for me.

I decided to make a 24 LED proof of concept project using the largest size board my free version of EAGLE would let me work to. I originally intended to use 0805 SMT LEDs mounted on their sides but when I realised what a bitch they are to solder like that I decided to go with good ‘ole 3mm thru holes of which I have – ahem – about 3,000 blue ones (don’t ask).
The electronics was pretty straightforward – since I have made a few similar things before (basically this was an Arduino project with a custom designed PCB) The 24 LEDs are driven by 3 x 74HC595D shift registers through 100 ohm 0805 resistors. I used an Atmega328 in QPF32 package with a miniature (Nano styley) resonator.
I usually use an FTDI USB-TTL serial lead for in circuit programming, so I simply added pads for the the six ICSP connections I needed for burning the bootloader and temporarily soldered wires to them. In the past I have routed in a proper 2×3 ICSP header but I don’t think I’ll bother any more – after all, burning the bootloader is a one-off procedure and routing in the header is a pain.

The board is single sided FR4. After etching and drilling it I tinplated the tracks (I do this with all my boards now as it makes soldering easier, looks cooler, doesn’t take long, and isn’t so expensive). After adding the wire jumpers to the back I worked in stages to add the components and test things.
I think its always a good idea to test at each stage in case you need to junk the board due to a design problem. First I soldered in the Atmega and the resonator and burned the bootloader. When that worked I added the serial programming header, diagnostic LED and resistor and made sure I could get sketches to run on the Atmega. Only then did I add all the other components when was confident the brain was alive. I soldered all the components with an iron, with the exception of the resonator where I put solder and flux on the pads and used a hot air tool make the joints.
The rest of it I made up as I went along, convinced it might go wrong at any moment. I shaped the board to a disk with a stanley knife, steel rule, pliers (for snapping) and sandpaper (for smoothing). Then I added in the slots, top and bottom, to accept a 2mm drive shaft using my new diamond edge cutting disk on my Proxxon table saw (in retrospect this blade is fricking awesome and I should have used it to cut out the circular PCB… you live and learn).
Aligning the 2mm drive shafts top and bottom was pure guesswork. I both soldered them and used copious quanitites of cyanoacrylate superglue (with activator spray) to hold them in place, with the help of a couple of plastic hub wheels from a model kit supplier.
The drive shafts go through miniature model bearings in my crudely fashioned frame (made from MDF I salvaged from an old CD rack, cut with a plain old Bosch jigsaw) and at the bottom there is a simple reduction gear from a DC motor to drive it. There is a crude joinery job holding it all together – I am not proud of it,
What I am more pleased with was the electrical transfer method I used. In a previous project I
“borrowed” (saw it on a Youtube video) the idea of using an axially mounted, graphite-lubricated, 3.5mm jack plug/socket connection to take power to the rotating LED board while also acting as a bearing. This time I used some chunky graphite brushes (intended for drill equipment I think) and drilled a 2.5mm hole in each and passed the 2mm drive shafts through them, then crudely superglued the end of the brush springs to my frame. And it worked! In fact it works rather well and I think I will be using this approach again.

As I expected, some balancing was needed. I superglued a couple of nuts to the back of the board to counterbalance the LEDs on the opposite edge. Its not perfect but it was a big improvement.

I saved soldering the Hall Sensor until the board was mounted in the frame, so I could make sure I cut the legs to the right length. A small Neodymium magnet triggers the sensor.
In hindsight it might have been better to somehow mount the magnet on the front of the frame (opposite the vertical part of the frame, so 180 degrees around the axis from where it is now). The reason is that when the sensor passes the magnet, a new drawing cycle starts. So this is the point where the previous draw cycle might be ended early or overrun (depending on rounding errors due to the timer resolution and variations in spin speed). With the position of the magnet in my design these display “glitches” happen right at the front of the globe and are quite easy to see – it would be better to hide them around the back by moving the trigger point through 180 degrees, or by placing the Hall sensor on the same edge as the LEDs rather than opposite them.
There is a voltage regulator on the board and I power the motor and board from a common supply of about 10 volts. Something that surprised me was that when plugged the USB lead in to the programming header on the board, the motor received power and span up. I didn’t think the current could cross the regulator in the opposite direction so it was a bit of a nasty suprise (and presumably it does the regulator no good either). A 1N4001 rectifier diode on the +10V supply going to the board brush solved the problem. I was very glad I found this issue before the motor was attached to the frame or I could have smashed the board.
When it was all fitted together I tested it out with a simple set of vertical and horizontal lines, rendering as a wireframe globe, and it looked great. Next I wanted to display a pixellated map of the world… to get this done I found a suitable Mercator projection image on Google images and resized down to the target 24 x 64 pixels in PaintShop Pro (still my drawing tool of choice for its easy work with small bitmaps). Quite a bit of manual tweaking was then needed to get a decent recognisable monochrome image.

The next step was to calculate the bitmap values to insert in the code. I needed data as 3 bytes for each vertical scan column through the image (64 x 3 bytes of data) and I needed the low bit positioned at the vertical top of each byte.

I usually use a spreadsheet to do this kind of thing (OpenOffice). I wondered how I might import the mono bitmap image data directly into the spreadsheet, but as I was in a hurry and the image was small I just retyped it manually. To help keep track I divided the image into 8×8 squares and highlighted them chessboard fashion in yellow. This meant I could work one square at a time and it only took 15 minutes or so to enter the data into the spreadsheet and use formulas to calculate the bitmap values I needed.

I copy/pasted the values from the spreadsheet into the Arduino sketch, programmed the globe and fired it up – and it worked first time! The Pacific looked a bit empty though, so I went back and added Hawaii.
I put a 32kbit I2C EEPROM on the board so that I can store a decent set of image data to make animations possible. I haven’t done anything with it yet.
Here is a brief description of how the code works. Almost all the POV projects I’ve made work in this way…
The sketch sets up the Atmega328′s internal timers 1 and 2 to run at the same rate (1/64 of full clock speed). This means they are counting at a very high rate (I think it works out as 62500 counts a second).
The sketch uses “interrupts” – an interrupt is a way for a specific hardware event (like a pin changing value or an internal timer reaching a certain threshold) to cause a specific piece of program code (called a “service routine”) to be run immediately. This means the program does not need to keep “polling” things like inputs and timers, which would not be very accurate at these timescales. Interrupts are really the only way to get the consistent timing accuracy we need.
We use two interrupts, one is called when the hall sensor fires and the value on pin 2 (Interrupt 0 pin) changes. The service routine for this interrupt captures the value of timer 1 and resets the timer. This value is the number of timer ticks in one complete rotation of the board.
Now we divide this up to get the number of timer ticks in a single “sector” (vertical scan column width). Although there are 64 columns in the image, I actually insert an artificial blank column between every pair of image columns to cleanly seperate the “pixels” rather than letting them run together into streaks (it just looks nicer) so I treat the image like it has 128 columns.
So the timer count is divided by 128 and the result is put into the timer 2 “period register”. Now when timer 2 reaches the value of the period register it is automatically reset and another interrupt fires. The service routine for this interrupt will therefore get regularly called 128 times on each revolution – perfect! Now we just need to load values from the image data into the LEDs. We need to keep a count of how far round the revolution we are and we can add an incrementing offset to make the image appear to spin. It is also here that we turn off all the LEDs on every other call to add the gaps between the pixels.
The LEDs are loaded by simple shift register stuff (Check the Arduino tutorials if you don’t know what a shift register is) . Speed is of the essence, so the three shift registers are loaded in parallel using 3 data lines and common clock lines. I avoid using digitalWrite() to drive the output pins on anything like this and go direct to the port registers since it’s an order of magnitude faster!

*** Source code, EAGLE files and image data available at
https://github.com/hotchk155/PovGlobe

Continue reading

Posted in News | Comments Off

Stomp box clone (Big Muff)

At the BuildBrighton hackspace we have a workshop planned for DIY stompbox builders. We’ll probably be concentrating on a Fuzzface clone since thats nice and simple. Just to make sure we knew what we’re doing we put together a couple of Fuzz face circu… Continue reading

Posted in News | Comments Off

WeenyPOV on Scalextric car

Mikepea at BuildBrighton is building a Scalextric setup with a difference! One of the many features we’re thinking about is a POV display on the roof of a car which will plot out a graphic image as the car moved round the track. The first test was to s… Continue reading

Posted in News | Comments Off

Playing with MIDI ping pong table

Will and I trying out the sensing and early version of MIDI handling on one half of the table.Video by Will Nash. Will’s site is athttp://www.willnash.co.uk Continue reading

Posted in News | Comments Off

MIDI Table Top Sensing…It’s working!

I thought it was about time to give an update on the MIDI ping pong table sensing stuff. I’ve spent quite a lot of time on it, been through a few iterations of the hardware, and learned a lot! I started this as a total newbie as far as analog electroni… Continue reading

Posted in News | Comments Off

Digital POV clock working! mostly

Well, without too much pain, its just about working! Here is how I went about it, which might help you if you want to make one yourself…When you pick a drive to use, make sure it has four conductors going to the motor (“Y configu… Continue reading

Posted in News | Comments Off

POV Digital Clock on 2.5" HDD Platter

Just starting this project, which again uses a 2.5″ laptop drive.Last year I made a POV “slot” clock on a HDD platter, inspired by other peoples projects I saw online. Around the same time saw an excellent project on YouTube where someone had made a di… Continue reading

Posted in News | Comments Off