I got a couple of pieces of flexible copper-clad kapton sheet from ebay a few weeks back, and just got round to trying it out....
We have a new project at Build Brighton hackspace to make a POV fan to display SMS text messages sent to it. There is a long way to go, but one of the first steps is to make the LED array to be fitted to a fan blade. This needs to be as light and compact as possible, but I also wanted it to have sixteen 5mm RGB LEDs (thats a total of 48 LEDs to drive). SMD shift registers and resistors, together with a flexible (but more importantly thin and light) board seemed just the ticket.
I expected the sheets to be horrible to work with, and a nightmare for lifted traces, but actually it all went pretty well. I designed the layout for 8LEDs in EAGLE and then edited the image to double up the number of LEDS (my free version of EAGLE doesn't allow a layout big enough). I used press-n-peel blue toner-transfer film in my old HP LaserJet 1000 printer and ironed the toner onto the copper-clad film (just as I do for rigid PCBs) and etched in ferric chloride. Some gentle cleaning with fine steel wool and the result was pretty good.
I've had a bit of practice with hand-soldering SMDs.. I use a 0.4mm needle tip and a high temp (400 celsius) with 0.015" silver bearing solder. The high temp helps zap the solder without heating the part for too long, as long as you're quick. I do all the work through a 10x loupe and make a lot of use of tweezers and a flux pen, and to be honest I actually quite enjoy it!
There are 48 x 0805 resistors on the board and six 74HC595D shift registers, each with a 100nF 0805 bypass cap. The 5mm through hole RBG LEDs were surface mounted along the edge of the board and the shift regs were wired up with Kynar wire-wrap flex (I decided not to risk drilling the film). I used a wooden jig to space and hold the LEDs for soldering.
I had a handy roll of kapton tape which I used to insulate the ground track so it didn't short on the LED anodes passing right above it. Since the tape is heat resistant it behaved itself while the LEDs were soldered. This solved an otherwise tricky routing problem.
Soldering went fine, though it was obvious that things heat up much more quickly on the film than they would on a solid PCB, and solder stays molten longer since the heat has nowhere to go. I also think I should use a lower temp as the backing did seem to be getting slightly warped, but nothing serious.
However everything seemed to go OK and my first experience of making a flexible board went pretty well!
As for the POV fan project, I will keep ya posted
Sunday, 11 September 2011
Monday, 4 July 2011
Solid State Tesla Coil Fun
A solid state tesla coil is one that uses transistors to switch the primary coil voltage (instead of a spark gap or mechanical contacts). Using transistors also makes it straightforward to get the coil to spark at specific frequencies (e.g. to play a specific musical note). You can also make a simple feedback loop driven by an antenna picking up the EM field, which can automatically "tune" the coil to run it at its resonant frequency.
Anyway - a few months ago I made a solid state tesla coil based on Steve Ward's design. I put it in a box made of acrylic sheets and hot glue which had a couple of flaws - namely lack of shielding of the logic ICs (like the 555-based oscillator which drives the coil) against the strong electric field - so the coil fried its own electronics! and the other flaw.. well it fell to bits basically :)
I always meant to resurrect it in a more appropriate metal case and decided to go for some cool 1.5mm aluminium treadplate (not realising how hard it is to bend that stuff with any accuracy). My recently acquired jigsaw and drill press meant I was able to put together a box made of MDF sheets and pine mouldings which actually looks mostly OK :) The secondary is magnet wire (about 800 turns) wound on a PVC drain pipe, topped with a steel sphere garden ornament.
Steve Wards circuit is designed to run at 120VAC US mains. I built mine using uprated MOSFETs, caps and bridge to run at 240VAC UK mains supply, but I'm still being a chicken and running the primary through a step down transformer at 30VAC. Once I've played with different drive circuits I will probably add cooling fans and give it a try on higher voltages via a variac. But, before I blow it all up, I'm going to play with it some more and try controlling it via MIDI.
First off I had to work out how to get the coil to play a tune. I already had a little PIC circuit that could play a dodgy version of "Captain Pugwash" on a piezo sounder. I tried Using an opto-isolator driven by the PIC's square wave output to replace the 555 timer output in Steve Ward's circuit and it worked.
Before I plug any MIDI leads into it I need to make a fibre optic connection. I think the EM field around the coil would induce a voltage in any wiring that wouldn't be too kind to a MIDI keyboard or soundcard. Working on that bit now....
Something else I had a go at was an "ion windmill"... this is simply an "S"-shaped bit of bent wire that can spin around a vertical wire stuck to the top of the coil. When the coil is on, the electrons streaming from the tips of the wire drive it round!
Anyway - a few months ago I made a solid state tesla coil based on Steve Ward's design. I put it in a box made of acrylic sheets and hot glue which had a couple of flaws - namely lack of shielding of the logic ICs (like the 555-based oscillator which drives the coil) against the strong electric field - so the coil fried its own electronics! and the other flaw.. well it fell to bits basically :)
I always meant to resurrect it in a more appropriate metal case and decided to go for some cool 1.5mm aluminium treadplate (not realising how hard it is to bend that stuff with any accuracy). My recently acquired jigsaw and drill press meant I was able to put together a box made of MDF sheets and pine mouldings which actually looks mostly OK :) The secondary is magnet wire (about 800 turns) wound on a PVC drain pipe, topped with a steel sphere garden ornament.
Steve Wards circuit is designed to run at 120VAC US mains. I built mine using uprated MOSFETs, caps and bridge to run at 240VAC UK mains supply, but I'm still being a chicken and running the primary through a step down transformer at 30VAC. Once I've played with different drive circuits I will probably add cooling fans and give it a try on higher voltages via a variac. But, before I blow it all up, I'm going to play with it some more and try controlling it via MIDI.
First off I had to work out how to get the coil to play a tune. I already had a little PIC circuit that could play a dodgy version of "Captain Pugwash" on a piezo sounder. I tried Using an opto-isolator driven by the PIC's square wave output to replace the 555 timer output in Steve Ward's circuit and it worked.
Before I plug any MIDI leads into it I need to make a fibre optic connection. I think the EM field around the coil would induce a voltage in any wiring that wouldn't be too kind to a MIDI keyboard or soundcard. Working on that bit now....
Something else I had a go at was an "ion windmill"... this is simply an "S"-shaped bit of bent wire that can spin around a vertical wire stuck to the top of the coil. When the coil is on, the electrons streaming from the tips of the wire drive it round!
Thursday, 16 June 2011
FTDI's Vinculo Development Board: A Review
I was lucky enough to get involved in the Farnell/element14 'road test' programme, where individual electronic hobbyists get a chance to review (and keep) cool hardware items from Farnell.
If you don't know it already, element14 (www.element14.com) is a community/networking site for electronics professionals and hobbyists, run by the electronic components supplier Farnell...
Last year I was lucky enough to attend a really useful free Eagle (PCB Design Tool) course run by element14, and earlier this year my local hackspace, BuildBrighton, reached the final of the Great Global Hackspace Challenge which was sponsored (very generously) by element14.
While other suppliers might give out samples and freebies to industry, its refreshing that Farnell/element14 really do seem to be actively targetting and supporting the electronics hobbyist/hacker community - and so I am more than happy to sing their praises here.
Anyway, back to my road testing... I chose to review the VNCLO-START1 kit from FTDI. This kit is made up of a USB development board and a separate programmer/debugger board and the current cost on Farnell's web site is a little under £28.
The development board is branded the Vinco/Vinclo/Vinculo/Vnclo (it seems that FTDI aren't sure about the name yet, but I will call it “Vinculo”) containing the 64-pin version of FTDI's VNC2 'Vinculum' USB Host/Slave chip.
Very interestingly, FTDI have given the board the same form factor as an Arduino Uno, including pin-compatible Arduino shield header sockets and even an on-board ADC chip to provide the six analog inputs. This means that you should be able to make use of existing Arduino shields (add on boards) with the Vinculo, which is a clever move by FTDI.
The Vinculo can emulate an Arduino because it's on-board VNC2 chip is so much more than just a USB controller... its a fully fledged MCU. In fact it's a very powerful one, with a 16-bit core, 256kB of Flash, 16kB of RAM and 48Mhz clock among some other nice features... This makes it substantially more powerful that the AVR chip on the Arduino....And that’s before we get on to its USB support: Two full speed USB ports, each individually configurable as host or slave!
So, we're talking an impressive piece of silicon (and a reasonably priced one, with the 64-pin VNC2 chips selling on Farnell's site for just over £3, which is cheaper than the Atmega328).
I am planning to use VNC2 chips in two projects I have in the pipeline:
The Vinculo board seems like the perfect way to prototype these projects... so how to get started?
FTDI have a free, downloadable developer toolchain for the VNC2. This works with the VNC2 programmer/debugger to allow programming and interactive debugging of the Vinculo. And I really do mean interactive debugging... single stepping, breakpoints, watches and so on... controlled via USB to the debug board.. put that in your Arduino pipe and smoke it :)
So that's all good news, but once I got started I found a few problems with the developer tools which made me think FTDI may not be quite there yet...
First of all I was unable to use the IDE on my desktop computer (where I do all my coding) because of a strange display problem with the source code editor window - all the text becomes garbled and unreadable each time the window scrolls. I reported this to FTDI support who quickly got back with a 'That’s strange, we'll look into it' kind of response but no fix as yet. However, luckily my laptop doesn't get the same issue so I could move on.
The second issue I found was stability of the IDE, particularly during debug sessions but even some times when compiling, the IDE would stop responding and needs to be killed in task manager and restarted.
Moving on, I played a bit with some of the provided sample code. The Vinculo is not FTDI's first VNC2 evaluation board, and some of the sample code is for the older eval board, which has different pin to connector mappings, meaning that the older sample programs don't work on the Vinculo without modifications. For example the UART (used by the sample programs for debug output) has moved.
Luckily the remapping can be done in software.... a very nice feature of the VNC2 is that all the IO's go through a programmable multiplexer, so IO functions can be assigned to pins of your choosing. However the need to reassign IO's just to get the sample programs to work isn't what you want when you're first starting with a new device.
Another niggle is that while there are sample programs provided to demonstrate standard Arduino stuff (blinking LED, PWM examples and so on) what is glaringly lacking are any USB code examples that will work, without modification, on the Vinculo. Since USB is the attraction of Vinculo over vanilla Arduino I think this is something FTDI need to work on to make the board attractive to Arduino fans... I am still trying to work out how to modify the USB examples to get them running on Vinculo, and its not been straightforward.
On a more positive note, something FTDI have done is to create a simple application framework that should appeal to Arduino coders by presenting an Arduino-like syntax.... For example, when using the supplied main.c in your Vinculo project you define the Arduino standard entry points 'setup' and 'loop'.
Arduino-likey function wrappers like digitalOut() are provided, and libraries like Serial are emulated with structures containing function pointers, so familiar Arduino syntax like Serial.begin(9600); can be used.... Its just syntactic sugar, since behind the scenes the VNC2 API functions are being called, and its not 100% compatible (don't expect your Arduino code to 'just work' on Vinculo). However, it's a nice idea and will certainly appeal to Arduino developers. And you are still free to simply ignore it and work directly with the VNC2 API if you prefer.
FTDI also have a variety of documentation for online download, which I am still working my way through. I have to say the information seem to be a bit 'scattered' over many different application notes, but at least it mostly seems to be there. Its just a bit daunting and confusing when you first get started.
In conclusion, I have to say I'm very excited by this hardware. The VNC2 is a powerful and flexible chip, and the Vinculo is a great prototyping board, encompassing some innovative ideas by FTDI.
However, at the moment I think much could be improved in the accompanying development software package. For me it has been a uphill struggle, and I think that Arduino users who are not experienced coders may fall at the first hurdle with this.. that is until FTDI can iron out the IDE issues and provide a more consistent and usable set of Vinculo code samples.
This is a new product though, so I have hopes that these things will improve soon with software patches.
A couple of other things that would be nice are
If you don't know it already, element14 (www.element14.com) is a community/networking site for electronics professionals and hobbyists, run by the electronic components supplier Farnell...
Last year I was lucky enough to attend a really useful free Eagle (PCB Design Tool) course run by element14, and earlier this year my local hackspace, BuildBrighton, reached the final of the Great Global Hackspace Challenge which was sponsored (very generously) by element14.
While other suppliers might give out samples and freebies to industry, its refreshing that Farnell/element14 really do seem to be actively targetting and supporting the electronics hobbyist/hacker community - and so I am more than happy to sing their praises here.
Anyway, back to my road testing... I chose to review the VNCLO-START1 kit from FTDI. This kit is made up of a USB development board and a separate programmer/debugger board and the current cost on Farnell's web site is a little under £28.
The development board is branded the Vinco/Vinclo/Vinculo/Vnclo (it seems that FTDI aren't sure about the name yet, but I will call it “Vinculo”) containing the 64-pin version of FTDI's VNC2 'Vinculum' USB Host/Slave chip.
Very interestingly, FTDI have given the board the same form factor as an Arduino Uno, including pin-compatible Arduino shield header sockets and even an on-board ADC chip to provide the six analog inputs. This means that you should be able to make use of existing Arduino shields (add on boards) with the Vinculo, which is a clever move by FTDI.
The Vinculo can emulate an Arduino because it's on-board VNC2 chip is so much more than just a USB controller... its a fully fledged MCU. In fact it's a very powerful one, with a 16-bit core, 256kB of Flash, 16kB of RAM and 48Mhz clock among some other nice features... This makes it substantially more powerful that the AVR chip on the Arduino....And that’s before we get on to its USB support: Two full speed USB ports, each individually configurable as host or slave!
So, we're talking an impressive piece of silicon (and a reasonably priced one, with the 64-pin VNC2 chips selling on Farnell's site for just over £3, which is cheaper than the Atmega328).
I am planning to use VNC2 chips in two projects I have in the pipeline:
- The first to USB-host a Novation Launchpad keypad controller and run a suite of animation/MIDI-input apps. The idea is to make a standalone version of my 'playpad' MIDI controller projects.
- The second is as the 'brain' of my laser projector, where I need a high speed USB device to push coordinate data from a PC to a pair of DACs driving laser-projector galvos. Using a VNC2 means I can use a single chip (no need for separate USB chip and MCU) while avoiding the slowness of a polled USB stack implemented in software.
The Vinculo board seems like the perfect way to prototype these projects... so how to get started?
FTDI have a free, downloadable developer toolchain for the VNC2. This works with the VNC2 programmer/debugger to allow programming and interactive debugging of the Vinculo. And I really do mean interactive debugging... single stepping, breakpoints, watches and so on... controlled via USB to the debug board.. put that in your Arduino pipe and smoke it :)
So that's all good news, but once I got started I found a few problems with the developer tools which made me think FTDI may not be quite there yet...
First of all I was unable to use the IDE on my desktop computer (where I do all my coding) because of a strange display problem with the source code editor window - all the text becomes garbled and unreadable each time the window scrolls. I reported this to FTDI support who quickly got back with a 'That’s strange, we'll look into it' kind of response but no fix as yet. However, luckily my laptop doesn't get the same issue so I could move on.
The second issue I found was stability of the IDE, particularly during debug sessions but even some times when compiling, the IDE would stop responding and needs to be killed in task manager and restarted.
Moving on, I played a bit with some of the provided sample code. The Vinculo is not FTDI's first VNC2 evaluation board, and some of the sample code is for the older eval board, which has different pin to connector mappings, meaning that the older sample programs don't work on the Vinculo without modifications. For example the UART (used by the sample programs for debug output) has moved.
Luckily the remapping can be done in software.... a very nice feature of the VNC2 is that all the IO's go through a programmable multiplexer, so IO functions can be assigned to pins of your choosing. However the need to reassign IO's just to get the sample programs to work isn't what you want when you're first starting with a new device.
Another niggle is that while there are sample programs provided to demonstrate standard Arduino stuff (blinking LED, PWM examples and so on) what is glaringly lacking are any USB code examples that will work, without modification, on the Vinculo. Since USB is the attraction of Vinculo over vanilla Arduino I think this is something FTDI need to work on to make the board attractive to Arduino fans... I am still trying to work out how to modify the USB examples to get them running on Vinculo, and its not been straightforward.
On a more positive note, something FTDI have done is to create a simple application framework that should appeal to Arduino coders by presenting an Arduino-like syntax.... For example, when using the supplied main.c in your Vinculo project you define the Arduino standard entry points 'setup' and 'loop'.
Arduino-likey function wrappers like digitalOut() are provided, and libraries like Serial are emulated with structures containing function pointers, so familiar Arduino syntax like Serial.begin(9600); can be used.... Its just syntactic sugar, since behind the scenes the VNC2 API functions are being called, and its not 100% compatible (don't expect your Arduino code to 'just work' on Vinculo). However, it's a nice idea and will certainly appeal to Arduino developers. And you are still free to simply ignore it and work directly with the VNC2 API if you prefer.
FTDI also have a variety of documentation for online download, which I am still working my way through. I have to say the information seem to be a bit 'scattered' over many different application notes, but at least it mostly seems to be there. Its just a bit daunting and confusing when you first get started.
In conclusion, I have to say I'm very excited by this hardware. The VNC2 is a powerful and flexible chip, and the Vinculo is a great prototyping board, encompassing some innovative ideas by FTDI.
However, at the moment I think much could be improved in the accompanying development software package. For me it has been a uphill struggle, and I think that Arduino users who are not experienced coders may fall at the first hurdle with this.. that is until FTDI can iron out the IDE issues and provide a more consistent and usable set of Vinculo code samples.
This is a new product though, so I have hopes that these things will improve soon with software patches.
A couple of other things that would be nice are
- That Arduino staple - The always-useful pin 13 LED
- The ability to direct debug text output over the same USB cable that runs the debugger, where is can perhaps show up as a virtual COM port on the host PC (like on the mbed).
Monday, 6 June 2011
Solenoid Percussion for BuildBrighton's Noise Toys Event
Video by Barnoid (http://www.flickr.com/photos/barnoid/)
Last monday, BuildBrighton (my local hackspace) along with Playgroup (Brighton arts and events collective), ran “Noise Toys”... a day of making noisy gadgets in a local pub, anyone welcome – as part of the Brighton festival fringe.
At BB we were intending to provide a selection of “sound sculptures” around the place, but in the end we only managed a couple, which included my Lava-Lamp modulated synthesiser and an “interactive solenoid percussion” thing, which I'll give you the low-down on here
My idea was to have some MIDI triggered solenoid percussion (similar to http://hotchk155.blogspot.com/2010/10/solenoid-drum-machine.html) together with some kind of control surface to allow passing punters to control the solenoids and make little tunes and rhythms.
I thought it would be fun to use my Novation Launchpad to control the solenoids.
The Launchpad is a grid of illuminated buttons that is intended as a controller for Ableton Live (music app), but like most things it can be hacked :)
A while back I made a little Windows-based program to run a “rain storm” sequencer on the Launchpad (as seen on http://www.youtube.com/watch?v=ZgMDTJce9D8). Basically this was a simple step sequencer where notes are triggered by pressing buttons on the Launchpad and they “fall” - only sounding when they hit the bottom of grid. Pressing buttons on the lower row toggles them between Green (notes in the column are played then cycled back to top of grid) and Red (note plays once and does not cycle)
To add to the challenge (and because I needed the laptop to run Reason for the Lava Lamps) I thought it would be nice to be able to run the rain storm sequencer without the computer....
The Launchpad is a USB device (it doesn't have 5-pin MIDI connectors) so something would be needed to work as a “USB host” to allow a program running on a microcontroller (Arduino, PIC etc) to listen out for button presses and to control the Launchpad lights while sending out MIDI notes to trigger the solenoids.
I'd thought about making my Launchpad into a standalone MIDI controller before, and I had been looking at the FTDI VNC2 USB host chip (more about that later) but first of all I decided to try out the Sure Electronics USB HID Host Module which is based around a PIC and is a little short of £10 on eBay including the postage.
Sure's board is a nice little module, with 0.1” headers for the PICKit programmer and for serial comms with other application hardware. It also has a USB Type-A (host) socket and couple of addressable LED's. The on-board PIC24FJ256GB110 supports “USB On the go” (OTG) which means it can act as a USB host. Sure's web-site has downloadable source code for a firmware app, based Microchip's own open-source USB host stack, that will host a standard USB mouse or keyboard.
The only disappointment here is that only a minimal set of I/Os from the PIC are bought out through the headers which limits applications of the board since most of the PICs I/Os are inaccessible. Still, its a nice handy board and reasonably priced. But will it work with the Launchpad?
The Launchpad is not a standard USB MIDI or HID device. Rather it has a custom interface using two interrupt endpoints. This can be accommodated on the PIC with a couple of mods to the “Generic” device driver code from Microchips stack. It was my first time working with USB hosting and with 16-bit PICs so it was a learning experience.
When used under Windows via the Novation drivers, the Launchpad shows up as a MIDI device and is controlled by sending it MIDI note and controller info to toggle the LEDs. When Launchpad's buttons are pressed, it spits out MIDI notes/controllers which an application can act on.
So that the MIDI interface from Windows but exactly is happening on the USB wire? Well, a quick bit of trace code on the PIC showed that exactly the same MIDI bytes are being passed between the USB endpoints, making it nice and easy to drive the Launchpad from an embedded USB host like the PIC. Thankyou, Novation!
So on to the Rainstorm sequencer program, which I wanted to run on the same PIC. The sequencer code itself is pretty simple, but there are some complications when using Microchip's USB host stack which meant it took a while to get it working....
The main gotcha for me was that USB I/O operations need to be first initiated then polled for completion (or they can send completion events). However, to keep the stack ticking, the app must poll it via a “USBTasks” function. Without this polling, the stack does nothing and I/O will not complete. Ok, so just call USBTasks all over the place right? No sireeee, not if you don't want to end up in a confusing re-entrant mess and watch the PIC collapse in a heap.
In fact you need to be careful not to make USBTasks call anywhere but the top level loop, and to make sure that the application attempts just one USB I/O operation between USBTasks calls. One result of this is that long sequences of USB I/Os can become painfully slow to complete. With the Rainstorm sequencer I found that it became very sluggish at responding to input when there were more than a couple of dozen notes in play.
I am looking forward to trying this on the FTDI VNC2 chip which has the USB stack and application running in separate threads and should be able to get much better throughput.
OK – back to the fun and games! So the UART from the PIC is broken out to the header on the Sure Electronics board, and with the code changed to set up the correct MIDI baud rate and remove all other UART debug output from the code I could just stick on a 5-pin DIN socket via a couple of 220R resistors and I was sending MIDI.
On the other end of the MIDI connection I had a breadboard with a PIC16F688 receiving MIDI through a 6N138 isolator and triggering 8 digital outputs (each mapped to a MIDI note from the sequencer). Each output goes through a 1K resistor to a TIP120 NPN power transistor which directly drives a solenoid. The solenoids need about 18 volts to work properly so there's a 7805 and smoothing caps between the 18V side and the 5V logic side. I also had a hefty cap (2200uF) smoothing the 18V side since the solenoids can cause some big voltage dips when they fire all at once and this can reset the PIC. The schematic is available here
Once all the electronics was working it was time for the art... and unfortunately I didn't leave myself much time for that bit. I ended up gathering up milk bottles and hammering together a wooden frame for them to sit on, all the night before the gig. I had for some reason assumed that milk bottles, tuned with water, would make a pleasing “xylophone” effect... I hadn't really anticipated the the terrifying wall of machine gun clinking that they actually threw out.
Hmmm, well, there is always next time :)
Thursday, 5 May 2011
Adding a composite output to a ZX Spectrum
Tonight at BuildBrighton we have Sinclair night! One problem that we have is that the Spectrum, ZX81 etc (and a lot of other 1980's home computers) do not have composite video output sockets but rather were designed to run on an analog TV set tuned to the correct channel to pick up their signal. Analog TV sets are getting a bit hard to find these days, so this is an inconvenience...
Many years back I got my Spectrum to run on an old greenscreen mono monitor I was given. I don't have that speccy any more but decided to try the same trick on a spec I picked up on eBay earlier this year. With a composite output it is possible to hook it up to most modern TVs and many computer monitors.
Well, technically there is nothing to it... the Spectrum already has the composite signal (it is fed into the UHF modulator box that converts it to a TV signal) so its just a matter of getting the signal to the outside world.
I already had a 3.5mm mono jack to coaxial video lead from an Olympus digital camera (its the lead for showing your pics on the TV set) so I decided to simply add a 3.5mm socket so I could use the same lead.
The modulator is the nice little tin box on the inside of the Specc's TV connector. Take care when lifting the lid off the speccy or you might accidentally pull out the keyboard ribbons
Connect the SIGNAL (jack plug tip) to the connection going into the box furthest back from the TV socket (on my speccy it had a white plastic insulator). Connect GROUND (jack plug barrel) to the metal box itself, using solder to make sure you get a good connection.
Fit the socket... ah hot glue, how thee makes a craftsman of any pleb!
... get out the swiss army knife and scratch a groove to accomodate the socket in the lid so it can close
And the proof of the pudding... a "Specbook"
Many years back I got my Spectrum to run on an old greenscreen mono monitor I was given. I don't have that speccy any more but decided to try the same trick on a spec I picked up on eBay earlier this year. With a composite output it is possible to hook it up to most modern TVs and many computer monitors.
Well, technically there is nothing to it... the Spectrum already has the composite signal (it is fed into the UHF modulator box that converts it to a TV signal) so its just a matter of getting the signal to the outside world.
I already had a 3.5mm mono jack to coaxial video lead from an Olympus digital camera (its the lead for showing your pics on the TV set) so I decided to simply add a 3.5mm socket so I could use the same lead.
The modulator is the nice little tin box on the inside of the Specc's TV connector. Take care when lifting the lid off the speccy or you might accidentally pull out the keyboard ribbons
Fit the socket... ah hot glue, how thee makes a craftsman of any pleb!
And the proof of the pudding... a "Specbook"
Sunday, 19 December 2010
Battlezone With Lasers Part 2
Still an ongoing project to play Atari Battlezone via a laser projector (for no other reason than I like a challenge :)).
I stumbled for a long time over pushing data fast enough to a microcontroller, with a USB serial port proving too slow and a USB isosynchronous device being very complicated to program. Now I am using an mbed microcontroller board (with a decent amount of RAM and fast clock) to receive data and drive the DACs, and with the ethernet support of the mbed, I am able to send data over a TCP socket, which seems to be plenty fast enough.
The mbed's speed and RAM also allowed me to do a lot of the number crunching on the microcontroller (in particular the plotting of lines) so all I need is to push the lists of vertices to the mbed and it will generate "in between" points along a line (required so that the laser galvos can be moved a bit more incrementally - and with less probems of intertia -than just throwing them at the raw vertices. Also means I can keep plotting a frame while the next one arrives.
The "hard bit" - the actual Battlezone game - is actually easy, since I am using the wonderful open-source MAME emulator and was simply able to locate the vector display emulation code and hook my stuff into it. Luckily Battlezone does output vectors with decent continuity (i.e. where lines join up they tend to be sent consecutively, which saved me sorting list into some kind of optimised plot order). So basically my hooks in the MAME vector code just convert the floating point vector coordinates into 12 bit integer values (for my ADC) and flag "move" vs "draw" actions. Then the list can be dumped to the TCP socket at the end of the refresh cycle. At the moment I am only outputting every 10th frame to let the microcontroller breathe.
On the mbed side I am using a MCP4922 12-bit dual Digital to Analog Converter (DAC) with SPI serial interface, which can easily be driven from the mbed. The DACs drive a 20kpps Galvo set purchased from ebay (about £100 including PSU and drivers). I also have a 6N139 opto isolator driving the TTL blanking for the laser (a 50mW green DPSS module from Aixiz).
I am still working on the mbed code... at the moment I use a kind of double buffering with 2x16kb buffers, one of which can receive the frame buffer from TCP/IP socket while the mbed is plotting the other. Between plots the mbed checks if the receive frame is complete and switches the buffers if this is the case.
The frame rate I can plot is too slow, and I need to work out how to make it better. I need to force delays during plotting to allow the mechanical galvos to catch up with the driver signal. These are all <1ms but they add up and reduce the frame rate. Also the lines are "plotted" with "in-between" point calculation to try to keep galvo movement rate reasonable. I need to work out the best combination of delays and divisions to get the best plot with the best framerate. I am also thinking about recognising the text at the top of the display (status text and scanner) and missing them out of the plot (text kills the plot rate)
Still a work in progress, but fun!
I stumbled for a long time over pushing data fast enough to a microcontroller, with a USB serial port proving too slow and a USB isosynchronous device being very complicated to program. Now I am using an mbed microcontroller board (with a decent amount of RAM and fast clock) to receive data and drive the DACs, and with the ethernet support of the mbed, I am able to send data over a TCP socket, which seems to be plenty fast enough.
The mbed's speed and RAM also allowed me to do a lot of the number crunching on the microcontroller (in particular the plotting of lines) so all I need is to push the lists of vertices to the mbed and it will generate "in between" points along a line (required so that the laser galvos can be moved a bit more incrementally - and with less probems of intertia -than just throwing them at the raw vertices. Also means I can keep plotting a frame while the next one arrives.
The "hard bit" - the actual Battlezone game - is actually easy, since I am using the wonderful open-source MAME emulator and was simply able to locate the vector display emulation code and hook my stuff into it. Luckily Battlezone does output vectors with decent continuity (i.e. where lines join up they tend to be sent consecutively, which saved me sorting list into some kind of optimised plot order). So basically my hooks in the MAME vector code just convert the floating point vector coordinates into 12 bit integer values (for my ADC) and flag "move" vs "draw" actions. Then the list can be dumped to the TCP socket at the end of the refresh cycle. At the moment I am only outputting every 10th frame to let the microcontroller breathe.
On the mbed side I am using a MCP4922 12-bit dual Digital to Analog Converter (DAC) with SPI serial interface, which can easily be driven from the mbed. The DACs drive a 20kpps Galvo set purchased from ebay (about £100 including PSU and drivers). I also have a 6N139 opto isolator driving the TTL blanking for the laser (a 50mW green DPSS module from Aixiz).
I am still working on the mbed code... at the moment I use a kind of double buffering with 2x16kb buffers, one of which can receive the frame buffer from TCP/IP socket while the mbed is plotting the other. Between plots the mbed checks if the receive frame is complete and switches the buffers if this is the case.
The frame rate I can plot is too slow, and I need to work out how to make it better. I need to force delays during plotting to allow the mechanical galvos to catch up with the driver signal. These are all <1ms but they add up and reduce the frame rate. Also the lines are "plotted" with "in-between" point calculation to try to keep galvo movement rate reasonable. I need to work out the best combination of delays and divisions to get the best plot with the best framerate. I am also thinking about recognising the text at the top of the display (status text and scanner) and missing them out of the plot (text kills the plot rate)
Still a work in progress, but fun!
Saturday, 27 November 2010
Tesla coil diary - part 2
I've been playing on and off with the coil for the last couple of months, but the first test a few weeks ago was a little bit disappointing, only managing sparks of 6" or so and then only to ground (no air streamer breakout event with a breakout point on the top)
At first I thought the problem was positioning of the primary coil tap (i.e. change the number of active turns on the bottom coil) but I still could not get any better than 6" sparks to ground. Then I started to play with the spark gap and found that using a spacer to force a larger gap between the lengths of copper tube making up my static gap, the sparks improved a bit. That is until the spacers caught fire :)
So, I decided to try with a simple rotary spark gap and holy crap did it make a difference! Here it is...
I used 5mm acrylic sheet as a base material and a nominal 3000rpm shaded pole motor running at 240VAC. In theory 3000rpm is 50 revs per second. With the spark gap opening twice per rev (i.e. presenting at zero and 180 degrees) this should give 100 breaks a second I think... in theory this is perfect for discharging the capacitor bank just as it reaches maximum charge twice (positive and negative) on each mains AC 50Hz cycle.
Thats the theory, but its not a proper synchronous motor and the load of the spinning gaps looks likely slow it down a bit... if I get on to tuning things further I might try to work out its actual RPM. The motor is fitted to a base plate which can be rotated so the phase (i.e. when in mains cycle the breaks happen) can be changed, but I think this is really only going to be of value if the break rate really is 100Hz. I haven't played with moving the motor yet, something for another day.
Well... here are the results, without any serious attempt at tuning the primary tap.
Some other recent additions are a Terry Filter (safety spark gap and surge filter which protects the Neon Sign Transformer getting fried)
When I was packing it all up I was rather perturbed to receive small electric shocks every time I touched the secondary connections. At first I thought I had done something dumb like leave the mains connected or that the primary capacitors had remained charged somehow. However I got shocks handling the secondary even after I had completely removed it from the rest of the setup and I think the PVC pipe and/or the varnish layer were storing a static charge which leaked slowly over to the copper wire. The outside of the varnish certainly had a static charge like a TV screen right after the coil had been run. Interesting!
Subscribe to:
Posts (Atom)



