Stuff and Nonsense

Digital POV clock working! mostly

2012-02-08T14:42:00.000-08:00

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 configuration") rather than three ("Delta configuration") if you want to use the TDA5140A/TDA5144 to drive it. The conductors are likely to be on a tiny flexible ribbon going into the motor on the back of the board.

Get yourself a proper Torx driver to take out the screws holding the drive together (you can work around it with other things but you will drive yourself crazy). Remove the PCB from the back, being careful not to damage the ribbon going to the motor. Remove the metal front cover, remembering that there are usually a few screws hidden behind labels. Less brute force, more patience :o)

Remove the head and magnets by taking out screws. Take out the central screw of from the hub and take off the platter. You might be unlucky and have a platter which sits very low to the backplane. You might need to improvise to jack it up a bit to leave space behind from the leds, or you could combine parts from a couple of drives (as I did) to get the best combination. Another thought is to cut windows for the LEDs in the aluminium backplane, but that seems like a lot of effort!

My replacement platter was cut out of FR4 single sided copper clad board using a 70mm holesaw. A smaller holesaw (19mm I think) was used to cut out the centre, which was then filed to snugly fit the hub of the 2.5" laptop drive. The digits were actually laid out in EAGLE (PCB designer) since it was the only package I had to hand which let you type in rotation angles for characters. This worked OK, but a decent vector drawing package will have more interesting font options. The platter was etched just like a PCB.

It was challenge to fit LEDs and section dividers in the few mm of room behind the platter. My solution was to use SMD components and mount them on flexible kapton copper clad board (awesome stuff) which I picked up on eBay. Just press and peel and etch it as a normal PCB. The finished result, with components on, is only a mm or two in height and can be shaped with scissors and a knife, then glued down in the space under the platter. I made the light dividers from a bit of card cut with a knife and glued to the flexible board.

To index the rotation I used a reflective surface sensor (Osram SFH9202) which detects the passing of a piece of white paper stuck to the back of the platter. I used a strip of matt black insulation tape to give decent contrast on the rim of the platter (FR4 is a bit shiny).
I was a bit worried that the sensor seemed to be getting hot. I am still not convinced this is right, but looking at the data sheet they do dissipate 80mW, and I tried 3 of them and they all did it, so maybe this is right (it hasn't blown up yet!)

The sensor output is quite "analog" and doesn't, by itself, give a nice sharp switching signal. I should have shopped more carefully since Osram do the same sensor with a built in Schmitt trigger output. Still, I had some CD40106 Schmitt trigger inverter chips so I used one of those to give me a clean logic output and it seems to work fine now.

The main board was designed in EAGLE and etched on SRBP using some cheap toner transfer film from a chinese ebay shop. This film is great! it works better than the much more expensive press'n'peel blue and seems less fussy about your ironing technique (i have none). Another first was to etch this with Hydrochloric Acid and Hydrogen Peroxide mixture rather than Ferric Chloride. It is very fast and resulted in less erosion of tracks under the toner, but it also resulted in a nasty lingering chlorine smell pervading the house.

I really enjoy working with SMDs these days, but I used to be terrified of them. Those tiny surface mount components have many advantages: They tend to be cheaper, your boards can be much smaller and need less drilling, and the result is actually really satisfying. I'd say the most important things are magnification (I use a 10x loupe) a decent iron with a small tip (e.g. 0.4 or 0.8mm needle tip), fine solder (e.g. 0.015"), tweezers and a flux pen. Most important of all is practice and expecting it to all go wrong at least a couple of times before you get on a roll with it. Then you'll never look back :)

I'll admit I used solder paste for a couple of the components (the LEDs and their resistors, the two tiny resistor networks, the 16MHz resonator for the Atmega328). I used a hot air tool to reflow the paste. Everything else was done with an iron. The LEDs, resistors and small caps are 0805 size.

I have a small stock of M41T100 realtime clock chips in SOIC8 packages (from an ebay bargain) and I used one of these on this project, with a backup battery.

The MCU is an Atmega328 set up with Arduino bootloader. The code is all Arduino stuff. The Arduino drives the LEDs through a ULN2803 transistor array, since these LEDs are powered in groups of 3 and draw something like 30mA each, which would be too much to drive directly from the Arduino digital output pins.

Last but certainly not least, the hard drive motor is driven by a TDA5144. A word of warning - Don't think you can put power to a hard disk motor and it will spin. These are brushless motors and need electronics to make them work. If you want to try any HDD motor project I recommend you invest in a special IC for it. The Philips TDA5140A and TDA5144 have been perfect for the job in my experience (The TDA5140 - without the A - seems more finicky to get working). You can certainly make your own brushless DC motor controller, but that is a project by itself and I prefer to jump in with the fun stuff :)

Something I was glad I did was to add isolation jumpers to the board so I could power up the Arduino stuff without the motor starting, and vice-versa.

Code and EAGLE files can be found here
https://github.com/hotchk155/DigiPovClock

POV Digital Clock on 2.5" HDD Platter

2012-02-01T02:10:00.000-08:00

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 digital POV clock by spinning a set of digit-shaped windows, in front of a row of LEDs. By illuminating each LED when the appropriate digit was in front of it, a row of digits can be displayed... aka a digital clock (http://www.youtube.com/watch?v=7Qyawcw-ots)

That project used a 3.5" drive and it looked like the digits were actually laser or plasma cut into the metal platter itself. I decided to make an easier version by etching the digits into a piece of FR4 copper clad board to replace the platter. FR4 (the fibreglass PCB backing material) is quite translucent so it should transfer the light nicely from LEDs placed behind it.

So far I just have the platter made. I am using a 2.5" laptop drive and the space behind the platter is very limited, so I will probably place the LEDs on flexible kapton copper-clad sheet and put a row of windows cut in plastic sheet over the top to stop cross-illumination.

I'll spin the disk using the same TDA5144 circuit I used in the previous project but I'm not sure about indexing yet... there is not really space on the platter to cut a slot for a photointerrupter, and a magnet on the disk (for a fixed hall sensor) would need a counterweight and might not fit. I might try an IR reflective sensor here, but need to play with them a bit first as I've not used them before.

Keep ya posted!

POV Fun With 2.5" Hard Disk Drives

2012-02-01T01:51:00.000-08:00

I picked up a few faulty laptop drives cheap on ebay to take to bits and use for POV projects. I haven't finished them yet, but have been tinkering over time and will post my progress as I go.

For the first one I wanted to put a row of SMD LEDs on the platter itself (or at least on a bit of PCB replacing the platter). The problem is powering the thing... I still need to play with inductively coupled coils for power transfer, but for now I decided to use batteries.

With CR1216's and 1117 regulator

I started with a couple of CR1216 cells in holders - they balanced pretty well when the disk span up and it didn't vibrate too much. Unfortunately when I built up the rest of the circuit I hit a problem.. the LEDs would start up fine but after a few seconds they had faded down to nothing. Fresh batteries - same thing.

CR1216's are 3V lithium batteries (putting out about 3.3V) so I had a 1117 5V regulator on board to give me 5V for the PIC16F688 and the LEDs. I wondered if the current draw was reducing the battery EMF right down below the drop-out voltage of the reg so basically nothing got through the regulator. However when I removed the regulator from the circuit exactly the same thing happened. I guess CR1216's just don't have the oomph for running these high power LEDs :o(

Then I removed the CR1216 holders and put a couple of LR44 holder in their places. LR44's are alkaline button cells at 1.5V and they are a bit bigger than the CR1216's so I worried a bit about their mass on the spinning disk, but it seemed I could get away with that and they didn't fly off or anything (well, maybe just the once..)

The other concern was the lower voltage. I would get 3V instead of 5V to power the LEDs, so would they light properly? They did :o) However, the 3144 hall-effect switch I was going to use for indexing needs 4.2V minimum so I could not use that. Therefore I am currently able to get some pretty, but not stable, patterns while I wait for some new hall switches to arrive (with 3V minimum supply).

With LR44's and reg removed

Once I have the new hall switch I should be able to index the position of the disk using a magnet fixed below it, then I want to display text on the platter. This is really a test... the PIC doesn't have the memory to do much and the batteries probably wont last that long, but I hope to make another with external power (either with a brush to the back of the platter - there is continuity through the hub which makes that easier - or by inductive coupling)

This clip shows it in action. The data is just a binary counter for something to display, but its pretty

From POV on laptop hdd platter

Midi-izing the Reissue Stylophone

2012-01-08T06:21:00.000-08:00

A while back I did a "midi conversion" of a couple of Stylophones (The original analog model). I did this by removing the Stylophone electronics and leaving just the stylus, keyboard and resistor ladder. Using the keyboard as a voltage divider its then possible to connect the stylus to an analog input of a microcontroller (such as Arduino) and read the analog voltage to work out which note is being touched, then send out MIDI note data accordingly.

There are a few problems with this approach:

The stylus, keyboard and resistor ladder need to be disconnected from the rest of the stylophone circuitry... Looking at the stylophone schematic the best I could do was a minimum of three connections to break. It wouldn't be possible to have the original sound at the same time as MIDI doing it this way.
As with any mapping from an analog voltage to a range of discrete values there is a risk that a bit of dirt or grime on the keyboard will add enough resistance to cause the wrong note to be mapped. Not good!
Original Stylophones are classic bits of kit and ripping the guts out of them doesn't feel right. Also they aint getting any cheaper.

Since I had a couple of "reissue" Stylophones I picked up on ebay I decided to see if they might prove a better bet for a conversion...

The first problem was getting inside the thing... while the old Stylophone closed with a clip-on back, the new one is glued shut and getting it open without breaking any of the plastic is easier said than done.

Expecting similar nasty cost cutting inside I was actually surprised to find how much is actually in these things. There are no less than four separate circuit boards all individually screwed down to the case and connected with wires (although they are crappy wires with joints that snap when touched)

Removing the boards from the case I found there is the obligatory chip-on-board "black blob" and a few SMD components on the main board. As I expected these new Stylophones do away with the analog tone generator circuit in favour of some custom chip that presumably digitally creates the sound. There is also a through-hole soldered amplifier board and separate carriers for the power/vibrato switches and volume pot.

Those chip-on-board blobs are usually heart-sinkingly unhackable and the sight of one usually spells the end of any thoughts of doing anything interesting. However I was intrigued to see that there was a separate trace from each keyboard pad to the blob, and checking the stylus I found it was wired directly to the +4.5V supply.... so could it be that we had a digital inputs line for each keyboard pad, with some pull-down resistance? That would almost be too good to be true... but true, it was!

So why is that good? well microcontrollers like the Arduino love to read digital (i.e. ON/OFF) inputs. These are nice and reliable without the dirty connection issues of analog inputs, but not only that, you can "piggy back" your inputs off the original input lines (since you are just reading a voltage, not drawing a current). What this means is that you can read the notes being played, while the Stylophone circuit is still attached to the keyboard and playing normally. Also you should be able to get an Arduino to actually play the Stylophone, by feeding ON (logic HIGH) values into the lines... but I might leave that till another day :)

Even better, the board has an exposed pads on each line perfect for carefully soldering a wire to. So thats the good bit. The bad news is that there are 20 of these input lines... thats a lot of wiring and is enough to use up all the inputs on a Arduino board...

I decided to use 74HC165 shift registers to read the keyboard and cut down the number of input lines needed. These chips each read 8 inputs then send the data out in a serial stream. By chaining these together, any number of inputs can be read with just 3 wires to the Arduino (one to "capture" then inputs then a "clock" and data line for reading the data).

Using fiddly surface mount components it was possible to fit 3 of these shift registers on a board that would fit underneath the Stylophone main board, keeping it out of the way and snugly held to stop it shaking around.

An Arduino Nano would fit in the Stylophone case, but I decided to use a custom SMD board since I wanted to add an KXPS5 accelerometer to detect tilt (for pitch bend). I also added another 74HC165 shift register to the chain for reading additional inputs from a row of tactile switches mounted to the back of the Stylophone. A 5mm RGB on the front allows a "mode" to be indicated.

And it worked... mostly. I am having some issues with the accelerometer which may be down to a bad connection (those things are a bitch to solder!) but the keyboard reading and MIDI is working pretty well. Hopefully it will all be finished soon. Watch this space!

UPDATE: I finally found out why the accelerometer wasn't working... even in analog output mode on the KXPS5 it is neccessary to set the "enable" input high only AFTER the chip is powered up (at least 1ms after). I had tied the enable input high on my etched board, d'oh! Failure to do this makes the analog outputs go mental... I only found this out after I decided to ditch my homebrew board and use an Arduino Nano in there.

Flashing LED Christmas Card Project

2011-12-03T03:35:00.001-08:00

This is a DIY project to create a flashing christmas card based on a 555 timer. I did a project like this many moons ago at school, and when my local hackspace, Build Brighton, were thinking of seasonal electronics projects we could offer in workshops I decided to try to recreate this idea.

The circuit is a basic "astable" circuit (which simply means it oscillates between states). In this case we use the venerable 555 timer integrated circuit to make a square wave oscillator with a frequency of a second or two.

The output of the oscillator circuit goes to 0V, stays there a while, then flips up to 9V, stays there a while then flips back to 0V and repeats again. When the output is 9V it lights up a set of LEDs. The "clever" bit is that when the output is 0V a second set of LEDs light up, because those LEDs are already connected to 9V (i.e. "positive") on their other side, and get connected to 0V (i.e. "negative") when the output of the oscillator goes down to 0V. The end result is that the two sets of LEDs flash alternately.

I found a small current flows even between the "high" output of the 555 and the 9V supply, so the LEDs are never completely off but flash from dim to bright (but in some ways that looks even nicer :o)

The parts needed for this project are

8 x identical "standard" LEDs
1 x "standard" LED for top of tree (can be same type as above, but you might want a different colour)
9 x 220 ohm resistors for the LEDs (typically 220 ohms but you might want to experiment with higher or slightly lower values to get the brightness levels you want. I used 100 ohm resistors on my red LEDs and a 470 ohm on the blue led)
1 x 555 timer IC (e.g NE555)
1 x 10M (10 mega-ohm) resistor
1 x 470k (470 kilo-ohm) resistor
1 x 10nF (0.01uF) ceramic capacitor
1 x 100nF (0.1uF) ceramic capacitor
1 x PP3 battery snap connector
1 x PP3 battery
Some connecting wire (e.g. 1 meter or less of thin equipment wire)

You can build this by poking the component legs through holes punched in the card, then soldering them on the back. This is kind of fiddly but it wouldn't be quite the same end result to build it on a board.

The following diagram shows the connections from the INSIDE of the card (i.e. the side you see when soldering). Click to enlarge

When putting the 555 IC on the card make sure that you insert it through the front of the card with pin 1 at the top (the end of the chip with pin 1 will be marked with a notch or dimple).

The LEDs must be inserted the right way round for this project to work. The anode (+) side of the LED is marked by a longer leg and the cathode (-) has a flattened edge to the lens. Use the + symbols next to the LEDs in the diagram above to make sure you put them in the right way round and remember the diagram shows the BACK of the circuit!

The resistors and capacitors have no specific polarity and can be soldered either way round.

Don't heat components for too long when soldering. LEDs are particularly sensitive to overheating and it probably won't do the 555 a lot of good either. It helps to bend leads together (so they stay joined by themselves) before soldering so you can be quick with the heat.

My card was particularly utilitarian, but I'm sure you can make it look much nicer :) sticking a sheet of card over the wiring hides the mess and strengthens it all. It would be good to see other peoples results!

Lost in Maths! (2D Sound location with 4 sensors)

2011-11-05T07:06:00.000-07:00

This post is about my ongoing project to do fast 2D sound location on a ping pong table, this is some ideas I've been having and wanted to share - since I need some help!

Ok here's the problem... we have a rectangular area ABCD and somewhere in that area (point X) there is an event that produces a sound (e.g. a ping pong ball strikes the surface). This results in sound waves travelling outwards to the corners where they are picked up by sound detectors.

The first sound to be picked up at each sensor arrives at a time that obviously depends on that sensor's distance from the original sound. Lets call the times tA, tB, tC, tD. (Each sensor will pick up reverberations and echoes after the original sound, but its the first "edge" of the sound we're interested in)

Now since we don't know when the original sound happens (we only detect it when it got to the closest sensor) we don't actually know the real values of tA, tB, tC, tD but we get relative times from the first sensor. In this case X is closest to D, the sound reached D first. The time we read at each sensor A,B,C is relative to tD. Graphically this can be shown like this (each red line is reduced by distance XD)

Now we can use these reduced distances to define circles based on the points A,B,C and D (radius at D is initially zero)

As pointer out by Arduino forum member Necromancer on http://arduino.cc/forum/index.php?topic=52583.0 we can find X geometrically by progressively increasing the radii of the circles at A,B,C and D by the same amounts until all the circles intersect at a single point. At this point we have added back the unknown distance XD and the circles intersect at point X as shown below.

The problem is that this iterative calculation of circle intersections is processing-heavy and would probably take too long to solve on a microcontroller to be responsive enough for my application. However I started thinking about getting a "head start" by doing some simple calculation to get the initial increment where all the circles intersect for the first time, and go forward from there.

Here's what I mean.... point Q is a point on the line AC which is equal distances from the points where the initial circles around A and C cross AC.

The actual coordinates of Q aren't needed, we just need to know how much to increase the radii of the circles around A and C so that they intersect at the first time (which will happen at Q)

The calculation is simply the length of AC minus the radii of the two circles, all divided by two. If we calculate this value and add it to the radii of the circles they will meet at Q.

If we do the same calculation for lines AB, BC, CD, AD, AC, BD we'll get 6 different values that we should increase circle radii by make them intersect. We can just take the largest of all the 6 values and apply that as the base value by which the radii of all the circles should be increased to get to the initial point where all the circles intersect.

This will not neccessarily be point X... we might need to interatively expand the circles a bit more to make them all intersect at the same point. However we got a big head start and so far we've just done simple arithmetic.

I made a simple program where I could click with the mouse to simulate the values arriving at the 4 sensors., then applied the above calculations... in many cases the results are very close to the final point X. For example:

In other places the accuracy is not so spot-on, but it looks like some kind of simple averaging of the points of intersection might give a position good enough for what I want, and without having to iteratively apply complex calculations (like square roots), so it should be pretty fast.

Only three sensors are strictly required for multilateration, however I found that adding the fourth sensor made a massive difference to the accuracy of the above calculation.

The next step is to calculate the points of intersection and give it a try with some averaging, to see if I can avoid the iterative method. However I'm not a mathemetician, so if anyone has a better idea, please let me know!

Update: OK, I gave the averaging thing a try. This clip shows my test program using these calculations to track the mouse pointer. The tracking is not perfect and there are a couple of places (vertical midpoint of the area, towards left and right side) where it is worst, but I think this is good enough (especially given that my sensors won't be perfect!).

The program displays the fours circles calculated as above. The final calculated position is displayed by the red crosshairs

The process is as follows:

1. Firstly I need to simulate the sensor inputs, so I take the position of the mouse pointer, calculate distance to each corner and then subtract the minimum distance from all the others. The results (tA, tB, tC, tD) are representative of time or arrival info from real sensors.

2. For each edge, and the two diagonals I get the length of the line (area width, height or diagonal distance) and subtract the relative arrival times for the points at each end.

offset1 = (width - tA - tB)/2

offset2 = (width - tC - tD)/2

offset3 = (height - tA - tD)/2

offset4 = (height - tB - tC)/2

offset5 = (diagonal - tA - tC)/2

offset6 = (diagonal - tB - tD)/2

Now take the maximum of these 6 values:

offset = max(offset1,offset2,offset3,offset4,offset5,offset6)

now calculate the circle radius by adding the offset to each time.

rA = tA + offset

rB = tB + offset

rC = tC + offset

rD = tD + offset

now calculate the intersection points of all pairs of circles. I used the C code example from here http://paulbourke.net/geometry/2circle/

There are six pairs of circles, AB, AC, AD, BC, BD, CD. Not all may intersect (ignore pairs which do not intersect). Otherwise we get 2 insection points (which may be identical if circles just touch) for each pair of circles. Lets say that for each pair of circles we can get two intersection points P and P'

For each pair of points P and P', one will be closest to our target point and the other should be discarded. The way I did this was to calculate the average of all the points, then go back through the list selecting the point from each pair that was closest to the calculated average point and then averaging just these "closest points".

ie. Take the first "rough" average of all points P and P' - lets call is (Xave, Yave), then recalculate the average position using either P or P' from each pair based on the condition:

if (Xp - Xave)^2 + (Yp - Yave)^2 > (Xp' - Xave)^2 + (Yp' - Yave)^2

then use point P'

else use point P

The resulting average (X , Y) is the final calculated point.

Better accuracy would be got by interatively increasing rA, rB, rC and rD and recalculating the intersection points until they are at their closest to each other. However I don't think I need this - the sensor input is unlikely to be so accurate it would benefit from this.... and I think it would be computationally expensive due to calling sqrt( ) many times and therefore slow.

Once again I'm no mathematician and I'd be grateful for any advice here!

Musical ping-pong tables and 2d multilateration

2011-10-12T13:27:00.000-07:00

I'm currently trying to help out a local artist who is building an Interactive Ping-Pong Table, where each bounce of the ball generates a musical sound which depends on the position of the bounce.

I thought it should be possible to do this without drastically changing the table (i.e. without chopping the surface up) by using 3 piezo disks and an Arduino or PIC to time the arrival of the pulse at each disk and work out the position of the ball. It all sounded pretty easy, and an interesting project. Its certainly been interesting, but I'll think twice in future before deciding something is easy before I've properly thought it through :o)

I found pretty quickly that some kind of amplification is needed.. the piezo disks are pretty sensitive to a sounds close by but not so great for something the other end of a table. First of all I tried to boost the level using 4069 inverter chips (I got that idea from Nicholas Collins' book - Handmade electronic music) since I've never really understood op amps and didn't want to get into all that dual supply rubbish. In my initial circuit I used an NPN Darlington transistor on the output of the amplifier stage to generate the logic pulse.

It kind of worked, but I was finding that the MCU would hang when an interrupt-on-change interrupt was being fired by multiple sensors. I also had a problem with the output getting stuck on (I think this might have been due to supply noise, noise picked up on a long wire to the piezo, and an overly sensitive amp stage). I think the hang thing might have been due to noisy outputs triggering a rapid train of interrupts than the poor PIC could not handle. I have an IKA Logic analyser and using this I could see a mad train of pulses coming from sound waveform, echoes, supply noise whatever... I don't really know, but the PIC didn't like it.

Searching about for ideas online I read about running op-amps like LM358 from a single supply, which seemed to be a better way to do things than using logic chips as amps. I also saw how a 555 monostable circuit can be used to clean up a dirty pulse by keeping an output high for a timed period as soon as the first edge of the input pulse comes in, so the train of pulses from reverberations and so on get masked by a nice clean extended output pulse... nice and friendly for MCU interrupt pins.

The resulting circuit seems to work pretty well, even though it still seems a bit complicated. Maybe it is a case of over-engineering, but I learned a lot and it does at least work pretty well. Using SMDs I can also get it on a board about the same size as the piezo disk so it can sit on top.

For some reason I thought the maths behind working out a point from timing would be easy..and it is in one dimension with 2 sensors...

However working in 2 dimensions with 3 sensors seems to be a completely different kettle of fish... the technique is called Multilateration and there have been entire research papers written about it :o) The problem is that all the timing readings you're working with are relative... its more complicated than I thought to get back to an actual position. Maybe I can simplify things, since my sensors will be arranged in the corners of a rectangular area and I can always calibrate them at the start by tapping the corners of the table. Or maybe some dirty trial and error approach will be good enough... Anway thats the next step... wish me luck..!

Here is the source code used in this clip

// SOURCEBOOST C
// PIC16F688
#include <system.h>
#pragma DATA _CONFIG, _MCLRE_OFF&_WDT_OFF&_INTRC_OSC_NOCLKOUT
#pragma CLOCK_FREQ 8000000

#define SENSEA            0b00010000
#define SENSEB            0b00100000
#define SENSE_MASK        (SENSEA|SENSEB)

typedef unsigned char byte;

// INITIALISE SERIAL PORT FOR MIDI
void init_usart()
{
    pir1.1 = 1;    //TXIF transmit enable
    pie1.1 = 0;    //TXIE no interrupts
    
    baudctl.4 = 0;        // synchronous bit polarity 
    baudctl.3 = 1;        // enable 16 bit brg
    baudctl.1 = 0;        // wake up enable off
    baudctl.0 = 0;        // disable auto baud detect
        
    txsta.6 = 0;    // 8 bit transmission
    txsta.5 = 1;    // transmit enable
    txsta.4 = 0;    // async mode
    txsta.2 = 0;    // high baudrate BRGH

    rcsta.7 = 1;    // serial port enable
    rcsta.6 = 0;    // 8 bit operation
    rcsta.4 = 0;    // enable receiver
        
    spbrgh = 0;        // brg high byte
    spbrg = 15;        // brg low byte (31250)    
}

enum {
    READY,
    LISTENING,
    TIMING,
    TIMEOUT
};

byte remaining;
long timeA;
long timeB;
byte state;

void interrupt( void )
{
    // check for interrupt on change
    if(intcon.0) // IOCA fired
    {
        // are any of the signals we're waiting
        // for now ready for us?
        byte savePortA = porta;
        byte whichSensor = savePortA & remaining;
        unsigned long thisTime;
        if(whichSensor)
        {
            if(state == LISTENING)
            {
                // start the timer
                t1con.0 = 1;
                thisTime = 0;
                state = TIMING;
            }
            else
            {
                // grab the current time
                thisTime = tmr1h << 8 | tmr1l;
            }
        
            // Grab times from sensors
            if(!!(whichSensor & SENSEA))
                timeA = thisTime;
            if(!!(whichSensor & SENSEB))
                timeB = thisTime;
                
            // clear bits for the sensors we 
            // already have
            remaining &= ~savePortA;
            if(!remaining)
            {
                intcon.3 = 0;            // ioca off
                state = READY;
            }
        }        
        
        // clear interrupt fired flag
        intcon.0 = 0;
    }    
}
        
////////////////////////////////////////////////////////////
// SEND A MIDI BYTE
void send(unsigned char c)
{
    txreg = c;
    while(!txsta.1);
}

////////////////////////////////////////////////////////////
// NOTE MESSAGE
void sendNote(byte channel, byte note, byte value)
{
    send(0x90 | channel);
    send(note&0x7f);
    send(value&0x7f);
}
void main()
{ 
    // osc control / 8MHz / internal
    osccon         = 0b01110001;
    
    
    // comparator off
    cmcon0         = 7;                      
    
    // configure io
    trisa         = SENSE_MASK;                  
    trisc         = 0b00000000;              
    ansel         = 0b00000000;
    porta        = 0b00000000;
    portc        = 0b00000000;

    // initialise MIDI comms
    init_usart();

    // 
    t1con = 0b00000000;
    
    // interrupt on change porta.4
    ioca = SENSE_MASK;
    intcon.7 = 1;
    intcon.3 = 0;
    intcon.0 = 0;

    byte note = 0;
    for(;;)
    {
        // Prepare to listen
        timeA=0xffff;
        timeB=0xffff;
        remaining = SENSE_MASK;
        state = LISTENING;
        t1con.0 = 0;            // reset the timer
        tmr1h=0;
        tmr1l=0;
        intcon.3 = 1;            // ioca on
        
        // wait to start timing
        while(LISTENING == state);
        
        // wait to complete timing
        while(TIMING == state)
        {
            unsigned long timeNow = tmr1h << 8 | tmr1l;
            if(timeNow > 0x8000)
                state = TIMEOUT;
        }
        
        if(TIMEOUT == state)
        {
            // ignore the interrupt if it does 
            // not register on all the sensors
        }
        else
        {
            long x=0;
            // i know i'm getting reading of up to 5000 'cos I printed 
            // them to serial port... you might get something different
            if(timeA > 5000) 
                timeA = 5000;
            if(timeB > 5000) 
                timeB = 5000;
            if(timeA) 
                x = 5000 + timeA;
            else if(timeB) 
                x = 5000 - timeB;
            if(x)
            {
                note = x/100; // is is in range 0-10000 so move this to MIDI range 0-100
                sendNote(0, note, 127);
            }
        }
        
        // delay (I think delay_ms function needs timer1)
        int i=1000;
        while(++i);        
        if(note)
        {
            sendNote(0, note, 0);
            note=0;
        }
    }
}

POV message fan project update

2011-09-12T14:48:00.001-07:00

Got a bit of time this evening to test out the LED array I made yesterday for the Build Brighton message fan..

The thin wire-wrapping wires are soldered to a scrap of veroboard for test connections , and the code is running on a PIC16F688. The shift regs are wired to share common clock lines, but each has its own serial data line, so all LED data can be loaded in 8 clock pulses so refresh should be nice and fast in the final thing.

Everything seemed to work first time, amazingly! These water clear RGB LEDs are nice and bright, but its possible to see the individual red/green/blue elements more than you would in a diffused LED (e.g. when you display yellow you can see the red and green elements rather than a single yellow point). I'm hopeful this won't be a problem when the thing is spinning and viewed from a distance.

My 100 ohm series resistance is rather low when the LEDs are run continuously but in the past I've found a low-ish resistance like this to be good when pulsing the LEDs quickly in a POV display. Still - I'll have to try to make sure the LEDs dont get left on 100% duty for a long time just in case they don't like the current.

I also mounted the board to the fan! With the help of some heavy duty double sided tape (for sticking carpets down) and cyanoacrylate superglue to hold the LEDs in the holes it seems to be pretty sturdy... famous last words...

Next step is to build a microcontroller board small enough to fit into the hub of the fan, then we (me and the Rev's Neil and Dave from BuildBrighton) need to get it power (via a pair of coils) and data (hopefully a modulated signal riding on the power)... and so the fun will really start!

Home made flexible circuit boards

2011-09-11T14:12:00.000-07:00

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

Solid State Tesla Coil Fun

2011-07-04T14:54:00.000-07:00

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!

FTDI's Vinculo Development Board: A Review

2011-06-16T09:19:00.000-07:00

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

I will post again soon with my progress applying the Vinculo/VNC2 to my own projects... watch this space!

Solenoid Percussion for BuildBrighton's Noise Toys Event

2011-06-06T13:03:00.000-07:00

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 :)

Adding a composite output to a ZX Spectrum

2011-05-05T02:04:00.000-07:00

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"

Battlezone With Lasers Part 2

2010-12-19T09:03:00.000-08:00

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!

Tesla coil diary - part 2

2010-11-27T04:20:00.000-08:00

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)

And a wooden base for it all to sit on

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!

Solenoid Drum Machine

2010-10-24T11:57:00.000-07:00

Just a quick project to try out some new push solenoids...

Based on PIC16F688 and building on the MIDI input code used on my earlier POKEY project

include <system.h>
#include <memory.h>

#pragma DATA _CONFIG, _MCLRE_OFF & _WDT_OFF & _INTRC_OSC_NOCLKOUT
#pragma CLOCK_FREQ 8000000
typedef unsigned char byte;

// define the pins
//#define P_LED portc.0

// MIDI defs
#define MIDIMSG(b) ((b)>>4)
#define MIDICHAN(b) ((b)&0xf)
#define MIDIMSG_NOTEON 0x09
#define MIDIMSG_NOTEOFF 0x08

// MIDI message registers
byte runningStatus = 0;
int numParams = 0;
byte midiParams[2] = {0};

#define SZ_RXBUFFER 20
byte rxBuffer[SZ_RXBUFFER];
byte rxHead = 0;
byte rxTail = 0;
int tmr[4] = {0};

////////////////////////////////////////////////////////////
// INTERRUPT HANDLER CALLED WHEN CHARACTER RECEIVED AT
// SERIAL PORT
void interrupt( void )
{
// check if this is serial rx interrupt
if(pir1.5)
{

// get the byte
byte b = rcreg;

// calculate next buffer head
byte nextHead = (rxHead + 1);
if(nextHead >= SZ_RXBUFFER)
{
nextHead -= SZ_RXBUFFER;
}

// if buffer is not full
if(nextHead != rxTail)
{
// store the byte
rxBuffer[rxHead] = b;
rxHead = nextHead;
}
}
}

////////////////////////////////////////////////////////////
// INITIALISE SERIAL PORT FOR MIDI
void init_usart()
{
pir1.1 = 1; //TXIF
pir1.5 = 0; //RCIF

pie1.1 = 0; //TXIE no interrupts
pie1.5 = 1; //RCIE interrupt on receive

baudctl.4 = 0; // SCKP synchronous bit polarity
baudctl.3 = 1; // BRG16 enable 16 bit brg
baudctl.1 = 0; // WUE wake up enable off
baudctl.0 = 0; // ABDEN auto baud detect

txsta.6 = 0; // TX9 8 bit transmission
txsta.5 = 1; // TXEN transmit enable
txsta.4 = 0; // SYNC async mode
txsta.3 = 0; // SEDNB break character
txsta.2 = 0; // BRGH high baudrate
txsta.0 = 0; // TX9D bit 9

rcsta.7 = 1; // SPEN serial port enable
rcsta.6 = 0; // RX9 8 bit operation
rcsta.5 = 1; // SREN enable receiver
rcsta.4 = 1; // CREN continuous receive enable

spbrgh = 0; // brg high byte
spbrg = 15; // brg low byte (31250)

}

byte rxInc(byte *pbIndex)
{
// any data in the buffer?
if((*pbIndex) == rxHead)
return 0;

// move to next char
if(++(*pbIndex) >= SZ_RXBUFFER)
(*pbIndex) -= SZ_RXBUFFER;
return 1;
}

////////////////////////////////////////////////////////////
// RECEIVE MIDI MESSAGE
// Return the status byte or 0 if nothing complete received
// caller must check midiParams array for byte 1 and 2
byte receiveMessage()
{
// buffer overrun error?
if(rcsta.1)
{
rcsta.4 = 0;
rcsta.4 = 1;
}

// any data in the buffer?
if(rxHead == rxTail)
return 0;

// peek at next char in buffer
byte rxPos = rxTail;
byte q = rxBuffer[rxPos];

// is it a channel msg
if((q&0x80)>0)
{
runningStatus = 0;
switch(q&0xf0)
{
case 0x80: // Note-off 2 key velocity
case 0x90: // Note-on 2 key veolcity
case 0xA0: // Aftertouch 2 key touch
case 0xB0: // Continuous controller 2 controller # controller value
case 0xC0: // Patch change 2 instrument #
case 0xE0: // Pitch bend 2 lsb (7 bits) msb (7 bits)
runningStatus = q;
numParams = 2;
break;
case 0xD0: // Channel Pressure 1 pressure
runningStatus = q;
numParams = 1;
break;
case 0xF0: // (non-musical commands) - ignore all data for now
return q;
}
// step over the message
if(!rxInc(&rxPos))
return 0;

}

// do we have an active channel message
if(runningStatus)
{

// read params
for(int thisParam = 0; thisParam < numParams; ++thisParam)
{
midiParams[thisParam] = rxBuffer[rxPos];
if(!rxInc(&rxPos))
return 0;
}
// commit removal of message
rxTail = rxPos;
return runningStatus;
}
else
{
// remove char from the buffer
rxInc(&rxTail);
return q;
}
return 0;
}

void main()
{
// osc control / 8MHz / internal
osccon = 0b01110001;

// timer0... configure source and prescaler
cmcon0 = 7;

// enable serial receive interrupt
intcon = 0b11000000;
pie1.5 = 1;

// configure io
trisa = 0b00010000;
trisc = 0b00110000;
ansel = 0b00000000;

porta=0;
portc=0;
memset(tmr,0,sizeof(tmr));

// initialise MIDI comms
init_usart();

// loop forever
for(;;)
{
// get next MIDI note
byte msg = receiveMessage();
if(msg)
{
byte note = midiParams[0];
if(note >= 48 && note < 52)
{
int which = note-48;
// 0x90 note on
// 0x80 note ff
if((msg & 0xf0) == 0x90)
{
tmr[which] = 200;
}
}
}

for(int i=0;i<4;++i)
{
if(tmr[i] > 0)
tmr[i]--;
}

porta.2 = (tmr[0]>0)?1:0;
portc.0 = (tmr[1]>0)?1:0;
portc.1 = (tmr[2]>0)?1:0;
portc.2 = (tmr[3]>0)?1:0;
}
}

Tesla Coil Diary - Part 1

2010-09-18T13:04:00.000-07:00

I've wanted to own a Tesla coil pretty much since I knew what one was, but I always thought it would be a bit difficult to make and possibly a little bit dangerous... Anyway, I decided to bite the bullet and started gathering the bits a couple of months back and actually started the building of it a couple of weeks ago after I got the courage to fire up the 10kV Neon Sign Transformer I got off ebay.

I got all the information and many great tips of websites of other coilers and have borrowed many ideas. I will try to remember and credit as much as I can.

I started off by getting this neon transformer

its a 10kV 50mA F.A.R.T. (oh the fun!) Resinblock. Here is my first try out of it, making a Jacobs ladder from coat hanger wire....

So far so good...

After a bit of online reading I eventually decided to wind my secondary coil on 125mm PVC ducting pipe (After deciding the 68mm drainpipe I first bought was just too wimpy). I got a nice 2Kg reel of 0.71mm magnet wire from ebay and got winding. I initially rigged up a motor driven jig to wind the wire but ended up winding by hand so I could keep a good tension on the wire (The motor came in very useful later while varnishing). I wound 800 turns in a couple of hours then put on about 5 coats of polyurethane gloss varnish. I used kapton tape to secure the outer windings (I owe http://deepfriedneon.com/ for many tips I used ... given my DIY prowess, without this information I would have ended in disaster I am sure)

Here is my winding rig...

I was quite pleased with the end result, which looked nicely like something from a B-movie mad scientists lab.

I originally bought 6mm microbore copper tubing to make my primary coil, but realised that I had not bought enough, and it was rather too expensive to go and buy another, longer length, so I looked around for alternatives and found some 4.75mm solid aluminium wire at the much better price of £12 for 20 metres. The wire was a lot softer and easier to kink than I expected and at first I wasn't too happy with the result. But after some reworking I think its OK. Here is the result (set on MDF with acrylic stands secured with nylon zipties)

I managed about 17 turns. I think I need to tap the coil after about 10 turns based on what Tesla Coil CAD told me - but I thought it would be good to have the extra tunability offered by the extra coils

For the top load I got some 10mm semi-rigid aluminium ducting hose (as is a coiler traditional I believe) and set it between two 34cm steel trays from the local 99p shop (these have to be the best bargain of this build!). This whole procedure was more difficult than it probably sounds... I needed to bolt the trays together first, with a wood spacer, then use tensioned strips of gaffer tape to hold the 2 plates parallel to each other. Then I threaded a rubber bungee cord through the flexible duct and after putting the ducting around the rim of the trays I hooked up the bungee and spread the out ducting round the rim until it joined up. I used a bit of flexible plastic sheet to make a sleeve to put inside one end of the ducting and help join the ends together. A bit of aluminium tape joined the ends, then more aluminimum tape to secure the ducting on the rim of the trays (helpful tips from http://www.hvtesla.com/toroid.html)

It might not be the best looking toroid, but it does look pretty meaty and mean!

Next steps are to add a strike rail to the primary (finally getting some use out of that microbore copper pipe), build a chassis (in progress - out of chipboard and softwood) and add fittings to secure it all together properly without danger of it collapsing. In the mean time here are the parts stacked on top of each other for a photo opportunity....

And so onto the electrics... I threw caution to the wind and got some Cornell Dubilier 942C20P15K-F capacitors, which a bit of online research seemed to indicate were THE choice for a good coil, even though they are not cheap, especially when factoring postage from US to UK. My capacitor bank has 28 of these 0.15uF, 2000V capacitors arranged in two parallel strings of 14. I mounted them on clear acrylic and wired them up with 1M bleeder resistors using high current wire taken from a set of car jump leads.

I just made my spark gap this weekend... I initially intended making a cylindrical "Richard Quick" type design but I preferred the idea I saw on a web site (which I would credit if I could find it again) where the multiple copper tubes are laid out side by side on the top of a box, and air is drawn through them by fans mounted on the ends of the box. Airflow keeps the gaps cool, but also sucks away ionised air from the gaps and quenches the sparks more quickly, which (so I read) results in better operation of the coil.

I made the spark gap box from acrylic sheets with an 85mm 240VAC fans (from Maplin) mounted at each end. 10 copper tubes of 15mm diameter and 90mm length form the gap. Two layers of kapton tape at each end of each copper tube provide spacing of ~0.4mm between tubes when they are laid side by side. Connection is made (at the moment) by a plug of compressed aluminium foil around which is wound the connection wire (car jump lead) inside the two "terminal" tubes. I am not sure how well this arrangment is going to work... we shall see.. The tubes are not permanently attached to the box, so my idea is that the number of tubes included in the gap can be varied by moving one of the tubes to which the wire is attached (the other being fixed at one side) by simply removing and shuffling the tubes.

I still need to complete build of the Terry Filter circuit (which I hope will protect the neon transformer from voltage surges) as well as the structural bits and pieces, however I hope I can get this thing up and running before too much longer. Watch this space for the results....

DIY Boss PC-2 / Amdek PCK100 Analog Percussion Synth

2010-06-30T13:43:00.000-07:00

Back at the end of the 80's I went in a music shop in London and on impulse I bought this wierd BOSS box that made weird bloopy noises... a PC-2 Percussion Synthesizer. It wasn't a difficult decision at the time since it only cost me £10 brand new boxed (I think they were trying to get rid of them) and it came with a free brand new BOSS HC-2 Hand Clapper pedal, although that seemed even less useful (though the guy did a good sales pitch involving a tale about a friend with no arms who had trouble applauding at gigs... :o)

Apart from a bit of novelty value I gotta be honest they didn't get a lot of use... I think the HC-2 got chucked during a house cleanout and the PC-2 was sold on ebay a few years back (and was amazed to get £100 for it). Well now I am kicking myself and wished I'd held on to these two collectables.

So when I saw the schematic of the Amdek PCK100 online (actually a kit form of the PC-2 sold by a Roland affiliate) I decided to try to make one and once again re-live boingy noise heaven.

On the page http://www.effectsdatabase.com/model/amdek/pck100 where I found the schematic I also found a photo of the PCB and decided to try to use it directly. With some manipulation in Paint Shop Pro and the use of Press'n'Peel PCB etching film I was able to make a copy of the board and after working out some workarounds (e.g. using BA6110 instead of ultra-rare BA662A VCA chip) I actually got it to work.. So in case you're interested ..here is how I did it

1) I started off with this photo of the track side of the original PCB

2) Turned to mono, upped the contrast, then very carefully use the "eraser" tool to ensure there are good clean gaps between all the tracks

3) Marked drill holes with circles

4) Drop colour depth to 2 colours

5) Negative image and a few embellishments and its ready to press'n'peel

6) Laser printed etch-resist transferred to copper clad board using a hot iron

7) Etched, drilled and trimmed ready for components

I mounted the board inside a project box from Maplin. By the way I have a thing for Dymo embossed label tape :)

The Amdek user guide gives info on some mods to the board (VCO wave form change, mod waveform change) which I added toggle switches for. Usually the Sweep control is a center tap pot.. I didn't have one so I instead rigged up a DPDT toggle and a resistor to a normal pot so that the same effect could be acheived (although I am not sure it works so well)

The original board calls for a Roland BA662A VCA chip... you won't find one! you can use a similar BA6110 chip but the pinout is different. I found the following worked

socket 1 connect to BA6110 pin# 4
socket 2 connect to BA6110 pin# 2
socket 3 connect to BA6110 pin# 1
socket 4 no connection. BA6110 pin#3 connected to GND (pin 5)
socket 5 connect to BA6110 pin#5
socket 6 connect to BA6110 pin#6
socket 7 connect to BA6110 pin#7
socket 8 connect to BA6110 pin#8
socket 9 connect to BA6110 pin#9

Click below to get the full size PCB template to use directly. See the link at start of article for schematic, photo of top of the board and original PCK100 kit instructions

Battlezone with lasers

2010-05-11T15:30:00.000-07:00

This is a project I've had simmering on the back burner for a while. Still at the early stages but thought it might be fun to keep track of each step here

A few months back I got a 20kps laser scanner galvo set off ebay with the intention of making my own laser projector and a vision of using it to play some old vector arcade games... particularly my old fave Atari Battlezone. The arcade game bit seemed pretty easy, since you can play BZ on the open source MAME emulator so I thought I could hook into the vector terminal emulation.

I found the asynchronous UART on an Arduino board was not quite fast enough to cope with the data... dropping bits all over the place, so I started looking at a USB conneciton to a PIC2455. As a SourceBoost C user I was not able to find any easy to understand USB CDC (Communication Device Class, a.k.a serial port) implementations for the PIC - so I decided to make my own, leaning heavily on sample code I found online.

Well I finally got to the point where my PIC would connect via USB show up as a COM port and be easy to access from a Windows program. Then I hooked up an 12-bit SPI dual DAC and connected it to the galvo setup and tried the first random hacking into MAMEs vector module.

I didn't expect it to work first time, and didn't! but my impatient hacking did produce some interesting squiggles at about 2 fps. I needed to use a long exposure photograph to actually make sense of it, but eventually I recognised a couple of parts of the display and got quite excited that the concept was proved!

The coordinate handling is obviously messed up and the image is wrapping on itself multiple times, also there is no attempt at blanking yet - so there are stray lines all over. The big job will be to find some way to optimise the render list to stop throwing the galvos all over the place and improve on the 2 fps refresh!

As you can see I have a long way to go!

Here is the plot showing the bits I recognised

Here is an actual MAME screen showing what it should look like

If things improve I will post an update!

Webcam motion detection to midi with puredata

2010-05-03T06:31:00.000-07:00

another experiment with puredata, webcam image is passed through pix_movement object and a pix_blob turns the result into two midi note streams which are sent into reason via midi yoke. the image is the output of the pix_movement (difference between frames)

I put the pd patch at http://sites.google.com/site/skriyl/Home/pd-projects (motion noise.pd)

The patch outputs on midi channels 1 and 2. I used midi yoke and PD's midi output, then piped this into propellerheads reason, where you can use the "advanced midi" to set up midi bus A then lock down channels 1 and 2 to specific instruments in the rack. I used an NNXT with glockenspiel patch and nn19 with strings patch

First play with PureData

2010-05-02T03:37:00.000-07:00

I was thinking about making a midi "harp" and thought of trying with a webcam, using puredata to analyse the images and generate midi/sounds. This is the first time I have played with PD and I don't really know what I am doing with it yet... you'll see I am not quite there with the midi harp yet, but I am impressed with how quickly you can get something fun working in PD

Here is the PD sketch, which I got to by hacking about with one of the GEM tutorial sketches

Matrix feedback in Reason

2010-04-22T08:35:00.000-07:00

How to do something like this...

A great thing about Reason is that it allows you to wire a continuous input (like a CV, MIDI CC#, Mod wheel etc) to pattern changes on something like the Matrix sequencer or Redrum. You can't do this directly (there is no pattern change CV input) but you can do it via the "programmer" in the combinator. This is a great thing to experiment with...especially if the patterns are different beat lengths/step values and you layer a few of them . In one of my other clips I used MIDI CC# signals generated by a Lavalamp to randomly switch patterns on a set of Redrum modules.

In the above above clip I have 3 matrix sequences driving each other, which can result in some random sounding patterns which repeat over long periods and can descend into chaos with one small tweak.. eventually arriving at a new repeating cycle (of course you need to drive one or more sound modules like NNXT etc with the matrix outputs to be able to hear anything...)

Start by making a Combinator...

Inside the combinator, create 3 matrix sequencers.

Wire Curve CV output from each Matrix Rotary inputs 1,2,3 on the combinator. Ensure these are only connections between matrixes (-ices?) and combinator

Click the "show programmer" button. Click on Matrix 1 and next to "Rotary 2" source select "Pattern Select" target. For Matrix 2 map Rotary 3 to pattern select, For Matrix 3 map Rotary 1 to pattern select

Flip to Curve view on each matrix and draw a few random curves (Randomize pattern option can be good). Start the Matrixes and click randomly on their pattern screens. Soon they should be flicking between patterns almost at random

Wire the Gate and Note CV outputs of one or more matrix to a sound module such as NNXT.

Flip the matrixes to note mode and click at random on the screens. Change pattern lengths and note resolutions, try the "randomize pattern" option. After a while things should be getting pretty freaked out

Pre programmed PICs

2010-03-23T14:48:00.000-07:00

Following some requests, I have listed pre-programmed PICs on ebay for a couple of my projects. If there is much interest (and its not all a massive hassle) I might also look into getting some PCBs made up and putting kits together
For now here are the PICs http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=150426687494

POKEY sound chip experiments

2010-03-23T13:41:00.000-07:00

The Atari POKEY was the classic soundchip in the Atari 8-bit home computers and many 1980's arcade games. This clip shows some of my experiments in driving a POKEY from MIDI. A PIC receives MIDI data and two 74HC595 shift registers are used to assemble the 12 lines of bus data for the POKEY so it can be driven from a humble 14 pin PIC16F688. A 6N139 isolator is placed between MIDI in from PC and the PIC's serial input. The POKEY is clocked at 2MHz from the PIC's internal clock output.

I am using REAPER to sequence some MIDI files I found on the internet. Credit goes out to the authors of these MIDI files.. also to YouTube member little-scale, whose clips inspired me to poke about with the POKEY in the first place, and Bryan Edewaard, whose crib sheet I could not have done this without.

Here is the schematic for the circuit as built on breadboard (I am working on neater, stripboard based version)

And the source code for SOURCEBOOST C on the PIC16F688

#include <system.h>

#include <memory.h>

// PIC CONFIG (_INTRC_OSC_CLKOUT is needed so we output clock

// clock signal on pin 3)

#pragma DATA _CONFIG, _MCLRE_OFF & _WDT_OFF & _INTRC_OSC_CLKOUT

#pragma CLOCK_FREQ 8000000

typedef unsigned char byte;

// define the pins

#define P_DATA portc.0

#define P_SHCK portc.2

#define P_STCK portc.1

#define P_POKEY portc.3

// define "pure" tone sound mode. Other settings

// of bits 4-7 will add varying levels of distortion

#define POKEY_SOUNDMODE 0b10100000

// MIDI defs

#define MIDIMSG(b) ((b)>>4)

#define MIDICHAN(b) ((b)&0xf)

#define MIDIMSG_NOTEON 0x09

#define MIDIMSG_NOTEOFF 0x08

// structure for managing channel info

typedef struct

{

byte midiNote; // triggered MIDI note

byte note; // POKEY divider value

byte volume; // volume (bits 0-3)

byte count; // playing duration counter

} CHANNEL;

// Buffer to hold state of 4 POKEY voice channels

CHANNEL chan[4] = {0};

// MIDI message registers

byte runningStatus = 0;

byte midiParams[2] = {0};

byte numParams = 0;

byte thisParam = 0;

// Divider values for POKEY channels

byte notes[48] = {

250, // C#2

236, // D2

222, // D#2

210, // E2

198, // F2

187, // F#2

177, // G2

167, // G#2

157, // A2

148, // A#2

140, // B2

132, // C3

125, // C#3

118, // D3

111, // D#3

105, // E3

99, // F3

94, // F#3

88, // G3

83, // G#3

79, // A3

74, // A#3

70, // B3

66, // C4

62, // C#4

59, // D4

56, // D#4

52, // E4

50, // F4

47, // F#4

44, // G4

42, // G#4

39, // A4

37, // A#4

35, // B4

33, // C5

31, // C#5

29, // D5

28, // D#5

26, // E5

25, // F5

23, // F#5

22, // G5

21, // G#5

20, // A5

19, // A#5

18, // B5

17 // C6

};

////////////////////////////////////////////////////////////

// INITIALISE SERIAL PORT FOR MIDI

void init_usart()

{

pir1.1 = 1; //TXIF

pir1.5 = 0; //RCIF

pie1.1 = 0; //TXIE no interrupts

pie1.5 = 0; //RCIE no interrupts

baudctl.4 = 0; // SCKP synchronous bit polarity

baudctl.3 = 1; // BRG16 enable 16 bit brg

baudctl.1 = 0; // WUE wake up enable off

baudctl.0 = 0; // ABDEN auto baud detect

txsta.6 = 0; // TX9 8 bit transmission

txsta.5 = 1; // TXEN transmit enable

txsta.4 = 0; // SYNC async mode

txsta.3 = 0; // SEDNB break character

txsta.2 = 0; // BRGH high baudrate

txsta.0 = 0; // TX9D bit 9

rcsta.7 = 1; // SPEN serial port enable

rcsta.6 = 0; // RX9 8 bit operation

rcsta.5 = 1; // SREN enable receiver

rcsta.4 = 1; // CREN continuous receive enable

spbrgh = 0; // brg high byte

spbrg = 15; // brg low byte (31250)

}

////////////////////////////////////////////////////////////

// RECEIVE MIDI MESSAGE

// Return the status byte or 0 if nothing complete received

// caller must check midiParams array for byte 1 and 2

byte receiveMessage()

{

// loop until there is no more data or

// we receive a full message

for(;;)

{

// buffer overrun error?

if(rcsta.1)

{

rcsta.4 = 0;

rcsta.4 = 1;

}

// poll for a MIDI byte

if(!pir1.5)

{

// no data ready

return 0;

}

// read the character

byte q = rcreg;

pir1.5 = 0;

// is it a channel msg

if((q&0x80)>0)

{

numParams = 0;

thisParam = 0;

switch(q&0xf0)

{

case 0x80: // Note-off 2 key velocity

case 0x90: // Note-on 2 key veolcity

case 0xA0: // Aftertouch 2 key touch

case 0xB0: // Continuous controller 2 controller # controller value

case 0xC0: // Patch change 2 instrument #

case 0xE0: // Pitch bend 2 lsb (7 bits) msb (7 bits)

runningStatus = q;

numParams = 2;

break;

case 0xD0: // Channel Pressure 1 pressure

runningStatus = q;

numParams = 1;

break;

case 0xF0: // (non-musical commands) - ignore all data for now

runningStatus = 0;

return q;

}

}

// else do we have a channel message?

else if(runningStatus)

{

// fill in next command parameter

midiParams[thisParam++] = q;

if(thisParam>=numParams)

{

// return the command

thisParam = 0;

return runningStatus;

}

}

}

return 0;

}

////////////////////////////////////////////////////////////

// DRIVE DATA OUT TO SHIFT REGISTERS

// m is a bit mask to highest bit in the data

void dataOut(byte d, byte m)

{

while(m)

{

// shift clock low

P_SHCK = 0;

// data out

P_DATA = (d&m)?1:0;

// shift clock high

P_SHCK = 1;

// shift the mask

m>>=1;

}

}

////////////////////////////////////////////////////////////

// WRITE ADDRESS AND DATA TO POKEY

void writePokey(byte address, byte data)

{

// store clock low

P_STCK = 0;

// fill the shift regs

dataOut(address,0x08);

dataOut(data,0x80);

// store clock high

P_STCK = 1;

// pulse POKEY chip enable line

P_POKEY = 0;

delay_us(100);

P_POKEY = 1;

delay_us(100);

}

////////////////////////////////////////////////////////////

// POKEY RESET SEQUENCE

void resetPokey()

{

// fill all locations with 0

for(int i=0;i<16;++i)

writePokey(i, 0);

// reset sequence

writePokey(0x0f, 3);

writePokey(0x09, 1);

}

////////////////////////////////////////////////////////////

// HANDLE MIDI NOTE TRIGGER (ON OR OFF)

// MANAGES THE 4 VOICES

void handleNote(byte midiNote, byte midiVelocity)

{

int iAlreadyPlaying = -1;

int iFree = -1;

int iSteal = -1;

int iUpdatePOKEY = -1;

int iLongestPlay = -1;

// map 7-bit MIDI velocity to 4-bit POKEY volume

byte volume = midiVelocity >> 3;

// scan through the 4 channels

for(int i=0;i<4;++i)

{

// incremement play duration counter for this

// channel. we use this counter to detect which

// note has been playing longest if we need to

// steal a channel

chan[i].count++;

// check if the note is already playing on channel

if(chan[i].midiNote == midiNote)

{

iAlreadyPlaying = i;

}

// else is channel spare?

else if(!chan[i].midiNote)

{

iFree = i;

}

// else is channel the longest playing channel?

else if(chan[i].count > iLongestPlay)

{

iLongestPlay = chan[i].count;

iSteal = i;

}

}

// already got a channel playing this note?

if(iAlreadyPlaying > 0 )

{

// need to stop a note?

if(!volume)

{

// turn a note off

chan[iAlreadyPlaying].midiNote = 0;

chan[iAlreadyPlaying].note = 0;

chan[iAlreadyPlaying].volume = 0;

chan[iAlreadyPlaying].count = 0;

iUpdatePOKEY = iAlreadyPlaying;

}

}

// else check we have a nonzero volume. We will ignore

// zero volume requests against any note that is not already

// playing

else if(volume>0)

{

// convert from MIDI note to index in the notes[] array

byte note = midiNote;

while(note<37) note+=12; // 37 is lowest MIDI note we map

while(note>84) note-=12; // 84 is highest MIDI note we map

note-=37; // convert to array index value

// got a free channel?

if(iFree>0)

{

// use it

chan[iFree].midiNote = midiNote;

chan[iFree].note = notes[note];

chan[iFree].volume = volume;

chan[iFree].count = 0;

iUpdatePOKEY = iFree;

}

// else steal a channel from another note

else if(iSteal>0)

{

chan[iSteal].midiNote = midiNote;

chan[iSteal].note = notes[note];

chan[iSteal].volume = volume;

chan[iSteal].count = 0;

iUpdatePOKEY = iSteal;

}

}

// do we need to tell the POKEY anything?

if(iUpdatePOKEY > 0)

{

// make it so!

writePokey(0 + iUpdatePOKEY*2, chan[iUpdatePOKEY].note);

writePokey(1 + iUpdatePOKEY*2, POKEY_SOUNDMODE|chan[iUpdatePOKEY].volume);

}

}

void main()

{

// osc control / 8MHz / internal

osccon = 0b01110001;

// timer0... configure source and prescaler

cmcon0 = 7;

// configure io

trisa = 0b00010000;

trisc = 0b00110000;

ansel = 0b00000000;

// initialise MIDI comms

init_usart();

// reset the POKEY

resetPokey();

// loop forever

for(;;)

{

// get next MIDI note

byte msg = receiveMessage();

// handle note on/off (transpose down 1 octave)

if(MIDIMSG_NOTEON == MIDIMSG(msg))

handleNote(midiParams[0]-12, midiParams[1]);

else if(MIDIMSG_NOTEOFF == MIDIMSG(msg))

handleNote(midiParams[0]-12, 0);

}

}

Hand-cranked MIDI sequencer from a baked bean can

2010-03-16T02:32:00.000-07:00

One empty baked bean tin, some lego and a stack of little magnets... stick magnets on the tin and slide them about to 'program' the sequencer, then grab hold of the 'transport control' and crank away.... The breadboard contains 5 hall-effect switches and a PIC16F688 to generate MIDI note on/off information. This is piped to Reason in the first half of the clip and to a Dave Smith Mopho synth in the second half.
I reckon with a baked bean tin about 16ft in diameter and about 25,000 magnets you could dump your sequencer software.. and you'd be getting some good aerobic exercise to boot :o)

Here is the schematic (if you make one, note that hall effect switches need the magnet to be the right way round.. if it does not trigger, flip the magnet over)

And the code (SourceBoost C... NOTE: you'll need programmer hardware like PICKit2 to burn the program to the PIC chip)
// HALL SENSOR TO MIDI NOTES

// J.Hotchkiss Mar2010

#include <system.h>

#include <memory.h>

// PIC CONFIG

#pragma DATA _CONFIG, _MCLRE_OFF&_WDT_OFF&_INTRC_OSC_NOCLKOUT

#pragma CLOCK_FREQ 8000000

#define P_SENSE1 porta.5

#define P_SENSE2 portc.2

#define P_SENSE3 portc.1

#define P_SENSE4 portc.0

#define P_SENSE5 porta.2

typedef unsigned char byte;

// INITIALISE SERIAL PORT FOR MIDI

void init_usart()

{

pir1.1 = 1; //TXIF transmit enable

pie1.1 = 0; //TXIE no interrupts

baudctl.4 = 0; // synchronous bit polarity

baudctl.3 = 1; // enable 16 bit brg

baudctl.1 = 0; // wake up enable off

baudctl.0 = 0; // disable auto baud detect

txsta.6 = 0; // 8 bit transmission

txsta.5 = 1; // transmit enable

txsta.4 = 0; // async mode

txsta.2 = 0; // high baudrate BRGH

rcsta.7 = 1; // serial port enable

rcsta.6 = 0; // 8 bit operation

rcsta.4 = 0; // enable receiver

spbrgh = 0; // brg high byte

spbrg = 15; // brg low byte (31250)

}

////////////////////////////////////////////////////////////

// SEND A MIDI BYTE

void send(unsigned char c)

{

txreg = c;

while(!txsta.1);

}

////////////////////////////////////////////////////////////

// CONTINUOUS CONTROLLER MESSAGE

void sendController(byte channel, byte controller, byte value)

{

send(0xb0 | channel);

send(controller&0x7f);

send(value&0x7f);

}

////////////////////////////////////////////////////////////

// NOTE MESSAGE

void startNote(byte channel, byte note, byte value)

{

send(0x90 | channel);

send(note&0x7f);

send(value&0x7f);

}

void main()

{

// osc control / 8MHz / internal

osccon = 0b01110001;

// timer0... configure source and prescaler

option_reg = 0b10000011;

cmcon0 = 7;

porta=0;

wpua=0;

portc=0;

// configure io

trisa = 0b00100100;

trisc = 0b00001111;

ansel = 0b00000000;

// initialise MIDI comms

init_usart();

// Set up the MIDI notes for each sensor

byte note[5] = {60,62,64,65,66};

// byte note[5] = {36,37,38,39,40}; // For Reason REDRUM

byte sense[5] = {0};

for(;;)

{

if(P_SENSE1 != sense[0])

{

startNote(0, note[0], P_SENSE1? 0:127);

sense[0] = P_SENSE1;

}

if(P_SENSE2 != sense[1])

{

startNote(0, note[1], P_SENSE2? 0:127);

sense[1] = P_SENSE2;

}

if(P_SENSE3 != sense[2])

{

startNote(0, note[2], P_SENSE3? 0:127);

sense[2] = P_SENSE3;

}

if(P_SENSE4 != sense[3])

{

startNote(0, note[3], P_SENSE4? 0:127);

sense[3] = P_SENSE4;

}

if(P_SENSE5 != sense[4])

{

startNote(0, note[4], P_SENSE5? 0:127);

sense[4] = P_SENSE5;

}

}

}

MIDI Guitar on Stripboard... Kind of

2010-03-06T04:11:00.000-08:00

Somewhere between the Omnichord and the Stylophone lies this thing... simple but suprisingly effective... a PIC16F688 microcontroller, 2 shift registers IC's, 36 switches and a bunch of wire. The buttons select major/minor/maj7/min7/7/dim/aug chords based on any root note, and you "strum" across 3-4 octaves of notes from the chord by touching bits of exposed wire with a "stylus". The output is all MIDI (circuit makes no sound by itself) and Reason is being used here for sounds.

Note - If you are new to PIC stuff and want to make your own version of this project, remember you will need some way to program the PIC chip (its like a tiny computer and it comes without any software installed). The code is included below, but you'll need to compile it (using the free SourceBoost compiler) and "burn" it to the PIC... you can buy a programmer (e.g. PICkit2) or maybe borrow one. If there is enough demand I might be able to provide pre-programmed PIC16F688's for this, or my other PIC projects. Drop me a message if you'd be interested.

Schematic

The business end...

The mess on the back...

How it works (if you are interested)...
It's the tried and trusted principle of the keyboard matrix - the 74HC595 IC's are "shift registers" which are simply used to scan a single "on" bit across 16 lines, one at a time (all 16 are used for the stylus, the first 12 are used for the columns of the kepad). The program running on the PIC chip reads the voltage coming back from each row of the keypad and also from the stylus. Since the program knows which one of the 16 shift register outputs it has switched "on" at any moment in time it then knows which buttons are pressed / which "strings" the stylus is touching at any moment in time by which input lines (if any) it reads the voltage back on. The rest is down to the program code to convert this info into MIDI notes and send them to a synth. One other important things are the 10k "pull down" resistors on each of the 3 keyboard rows and the stylus line... they make sure that an unconnected line settles at 0V rather than reading spurious random values.

The source code
// STRUM CHORD CONTROLLER

// (c) 2010 J.Hotchkiss

// SOURCEBOOST C FOR PIC16F688

#include <system.h>

#include <memory.h>

// PIC CONFIG

#pragma DATA _CONFIG, _MCLRE_OFF&_WDT_OFF&_INTRC_OSC_NOCLKOUT

#pragma CLOCK_FREQ 8000000

// Define pins

#define P_CLK porta.2

#define P_DS portc.0

#define P_STYLUS portc.1

#define P_HEARTBEAT portc.2

#define P_KEYS1 portc.3

#define P_KEYS2 porta.4

#define P_KEYS3 porta.5

typedef unsigned char byte;

// Chord types

enum {

CHORD_NONE,

CHORD_MAJ,

CHORD_MIN,

CHORD_DOM7,

CHORD_MAJ7,

CHORD_MIN7,

CHORD_AUG,

CHORD_DIM

};

// special note value

#define NO_NOTE 0xff

//byte silent[1] = {NO_NOTE};

// Define the chord structures

byte maj[3] = {0,4,7};

byte min[3] = {0,3,7};

byte dom7[4] = {0,4,7,10};

byte maj7[4] = {0,4,7,11};

byte min7[4] = {0,3,7,10};

byte dim[3] = {0,3,6};

byte aug[3] = {0,3,8};

// Define the MIDI root notes mapped to each key

byte roots[16]={36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51};

// bit mapped register of which strings are currently connected

// to the stylus (notes triggered when stylus breaks contact

// with the strings)

unsigned long strings =0;

// Notes for each string

byte notes[16] = {0};

// current chord type

byte lastChordType = CHORD_NONE;

// current root note

byte lastRoot = NO_NOTE;

////////////////////////////////////////////////////////////

// INITIALISE SERIAL PORT FOR MIDI

void init_usart()

{

pir1.1 = 1; //TXIF transmit enable

pie1.1 = 0; //TXIE no interrupts

baudctl.4 = 0; // synchronous bit polarity

baudctl.3 = 1; // enable 16 bit brg

baudctl.1 = 0; // wake up enable off

baudctl.0 = 0; // disable auto baud detect

txsta.6 = 0; // 8 bit transmission

txsta.5 = 1; // transmit enable

txsta.4 = 0; // async mode

txsta.2 = 0; // high baudrate BRGH

rcsta.7 = 1; // serial port enable

rcsta.6 = 0; // 8 bit operation

rcsta.4 = 0; // enable receiver

spbrgh = 0; // brg high byte

spbrg = 15; // brg low byte (31250)

}

////////////////////////////////////////////////////////////

// SEND A MIDI BYTE

void send(unsigned char c)

{

txreg = c;

while(!txsta.1);

}

////////////////////////////////////////////////////////////

// CONTINUOUS CONTROLLER MESSAGE

void sendController(byte channel, byte controller, byte value)

{

P_HEARTBEAT = 1;

send(0xb0 | channel);

send(controller&0x7f);

send(value&0x7f);

P_HEARTBEAT = 0;

}

////////////////////////////////////////////////////////////

// NOTE MESSAGE

void startNote(byte channel, byte note, byte value)

{

P_HEARTBEAT = 1;

send(0x90 | channel);

send(note&0x7f);

send(value&0x7f);

P_HEARTBEAT = 0;

}

////////////////////////////////////////////////////////////

// CALCULATE NOTES FOR A CHORD SHAPE AND MAP THEM

// TO THE STRINGS

void changeToChord(int root, int which)

{

int i,j,len=0;

byte *struc = maj;

byte chord[16];

if(CHORD_NONE == which || NO_NOTE == root)

{

// stop playing

for(i=0;i<16;++i)

chord[i] = NO_NOTE;

}

else

{

// select the correct chord shape

switch(which)

{

case CHORD_MIN:

struc = min;

len = sizeof(min);

break;

case CHORD_DOM7:

struc = dom7;

len = sizeof(dom7);

break;

case CHORD_MAJ7:

struc = maj7;

len = sizeof(maj7);

break;

case CHORD_MIN7:

struc = min7;

len = sizeof(min7);

break;

case CHORD_AUG:

struc = aug;

len = sizeof(aug);

break;

case CHORD_DIM:

struc = dim;

len = sizeof(dim);

break;

case CHORD_MAJ:

default:

struc = maj;

len = sizeof(maj);

break;

break;

}

// fill the chord array with MIDI notes

int from = 0;

for(i=0;i<16;++i)

{

chord[i] = root+struc[from];

if(++from >= len)

{

root+=12;

from = 0;

}

}

}

// stop previous notes from playing if they are not a

// part of the new chord

for(i=0;i<16;++i)

{

if(notes[i] != NO_NOTE)

{

// check to see if it is part of the new chord

byte foundIt = 0;

for(j=0;j<16;++j)

{

if(chord[j] == notes[i])

{

foundIt = true;

break;

}

}

// if not, then make sure its not playing

if(!foundIt)

{

startNote(0, notes[i], 0);

}

}

}

// store the new chord

for(i=0;i<16;++i)

notes[i] = chord[i];

}

////////////////////////////////////////////////////////////

// POLL KEYBOARD MATRIX AND STRINGS

void pollIO()

{

// clock a single bit into the shift register

P_CLK = 0;

P_DS = 1;

P_CLK = 1;

P_DS = 0;

// get ready to scan

int root = NO_NOTE;

int chordType = CHORD_NONE;

unsigned long b = 1;

// scan for each string

for(int i=0;i<16;++i)

{

// clock pulse to shift the bit (note that

// the first bit does not appear until the

// second clock pulse, since we tied shift and store

// clock lines together)

P_CLK = 0;

P_CLK = 1;

// did we get a signal back on any of the

// keyboard scan rows?

if(P_KEYS1 || P_KEYS2 || P_KEYS3)

{

// have we decided on the root note yet?

if(NO_NOTE == root)

{

// look up the root note

root = roots[15-i];

// get the correct chord shape

switch(

(P_KEYS1? 0b100:0)|

(P_KEYS2? 0b010:0)|

(P_KEYS3? 0b001:0))

{

case 0b111:

chordType = CHORD_AUG;

break;

case 0b110:

chordType = CHORD_DIM;

break;

case 0b100:

chordType = CHORD_MAJ;

break;

case 0b101:

chordType = CHORD_MAJ7;

break;

case 0b010:

chordType = CHORD_MIN;

break;

case 0b011:

chordType = CHORD_MIN7;

break;

case 0b001:

chordType = CHORD_DOM7;

break;

default:

chordType = CHORD_NONE;

break;

}

}

}

// now check whether we got a signal

// back from the stylus (meaning that

// it's touching this string)

byte whichString = 15-i;

if(P_STYLUS)

{

// string is being touched... was

// it being touched before?

if(!(strings & b))

{

// stop the note playing (if

// it is currently playing). When

// stylus is touching a string it

// is "damped" and does not play

// till contact is broken

if(notes[whichString] != NO_NOTE)

{

startNote(0, notes[whichString], 0);

}

// remember this string is being touched

strings |= b;

}

}

// stylus not touching string now, but was it

// touching the string before?

else if(strings & b)

{

// start a note playing

if(notes[whichString] != NO_NOTE)

{

startNote(0, notes[whichString], 127);

}

// remember string is not being touched

strings &= ~b;

}

// shift the masking bit

b<<=1;

}

// has the chord changed?

if(chordType != lastChordType || root != lastRoot)

{

// change to the new chord

lastChordType = chordType;

lastRoot = root;

changeToChord(root, chordType);

}

}

void main()

{

// osc control / 8MHz / internal

osccon = 0b01110001;

// timer0... configure source and prescaler

option_reg = 0b10000011;

cmcon0 = 7;

// configure io

trisa = 0b00110000;

trisc = 0b00001010;

ansel = 0b00000000;

// initialise MIDI comms

init_usart();

// initialise the notes array

memset(notes,NO_NOTE,sizeof(notes));

for(;;)

{

// and now just repeatedly

// check for input

pollIO();

}

}

When Lava met Mopho

2010-02-28T10:19:00.000-08:00

I got a new toy! an Mopho analog synth from Dave Smith Instruments. First use.. a companion to my MIDI lavalamp to free it up from PC based soft synths. Since my original MIDI lavalamp project was based on a standard Arduino, I decided this time to make a quick little module for it using a PIC16F688 (my current weapon of choice)

Here is the circuit on stripboard

...the mess on the back...

...and the schematic...

... the lamp is wired up as described on this post

... and the PIC source code is included below (SourceBoost compiler)

#include <system.h>

#include <memory.h>

#define ANA_0 0b00000000

#define ANA_1 0b00000100

#define ANA_2 0b00001000

#define ANA_3 0b00001100

#define ANA_4 0b00010000

#define ANA_5 0b00010100

#define ANA_6 0b00011000

#define ANA_7 0b00011100

#define ADC_MAX 6

#define P_HEARTBEAT porta.5

#pragma DATA _CONFIG, _MCLRE_OFF&_WDT_OFF&_INTRC_OSC_NOCLKOUT

#pragma CLOCK_FREQ 8000000

#define ADC_AQUISITION_DELAY 10

typedef unsigned char byte;

enum {

ADC_CONNECT,

ADC_ACQUIRE,

ADC_CONVERT

};

void init_usart()

{

pir1.1 = 1; //TXIF transmit enable

pie1.1 = 0; //TXIE no interrupts

baudctl.4 = 0; // synchronous bit polarity

baudctl.3 = 1; // enable 16 bit brg

baudctl.1 = 0; // wake up enable off

baudctl.0 = 0; // disable auto baud detect

txsta.6 = 0; // 8 bit transmission

txsta.5 = 1; // transmit enable

txsta.4 = 0; // async mode

txsta.2 = 0; // high baudrate BRGH

rcsta.7 = 1; // serial port enable

rcsta.6 = 0; // 8 bit operation

rcsta.4 = 0; // enable receiver

spbrgh = 0; // brg high byte

spbrg = 15; // brg low byte (31250)

}

void send(unsigned char c)

{

txreg = c;

while(!txsta.1);

}

void sendController(byte channel, byte controller, byte value)

{

P_HEARTBEAT = 1;

send(0xb0 | channel);

send(controller&0x7f);

send(value&0x7f);

P_HEARTBEAT = 0;

}

byte adcInput[ADC_MAX] = {ANA_2, ANA_3, ANA_4, ANA_5, ANA_6, ANA_7};

byte adcInitComplete = 0;

int adcResult[ADC_MAX] = {-1,-1,-1,-1,-1,-1};

int adcIndex = 0;

int adcState = ADC_CONNECT;

////////////////////////////////////////////////////////////////

//

// doADC

//

// State machine for running the ADC and updating the adcResult

// array with the result from each analog input

//

void doADC()

{

switch(adcState)

{

// Connect ADC to the correct analog input

case ADC_CONNECT:

adcon0=0b10000001 | adcInput[adcIndex];

tmr0 = 0;

adcState = ADC_ACQUIRE;

// fall through

// Waiting for a delay while the ADC input settles

case ADC_ACQUIRE:

if(tmr0 > ADC_AQUISITION_DELAY)

{

// Start the conversion

adcon0.1=1;

adcState = ADC_CONVERT;

}

break;

// Waiting for the conversion to complete

case ADC_CONVERT:

if(!adcon0.1)

{

// store the result

adcResult[adcIndex] = (((int)adresh)<<8)|adresl;

// and prepare for the next ADC

if(++adcIndex>=ADC_MAX)

{

adcIndex = 0;

adcInitComplete = 1;

}

adcState = ADC_CONNECT;

}

break;

}

}

#define BUFLEN 8

typedef struct

{

char midiChannel;

char midiController;

int minADC;

int maxADC;

char currentValue;

char history[BUFLEN];

} CONTROLLER;

CONTROLLER controllers[ADC_MAX] = {0};

void initInput(int which, byte channel, byte controller)

{

controllers[which].midiChannel = channel;

controllers[which].midiController = controller;

controllers[which].minADC = -1;

controllers[which].maxADC = -1;

controllers[which].currentValue = -1;

}

void checkInput(int which)

{

// pointer to the controllers

CONTROLLER *p = &controllers[which];

// read the raw analog value 0-1023

int adc = adcResult[which];

// remember highest and lowest values

if((p->minADC == -1) || (p->minADC > adc))

p->minADC = adc;

if((p->maxADC == -1) || (p->maxADC < adc))

p->maxADC = adc;

// get the range of known readings

int range = p->maxADC - p->minADC;

if(range < 1)

range = 1;

// scale the current value into the range

// NB no floating point support...

int newValue = (127*(adc - p->minADC))/range;

// add the value into the history buffer

long smoothed = 0;

for(int j=0; j<BUFLEN-1;++j)

{

p->history[j] = p->history[j+1];

smoothed += p->history[j];

}

p->history[BUFLEN-1] = newValue;

smoothed += newValue;

smoothed /= BUFLEN;

// has the value changed?

if(smoothed != p->currentValue)

{

sendController(p->midiChannel, p->midiController, smoothed);

p->currentValue= smoothed;

}

}

void main()

{

int i;

// osc control / 8MHz / internal

osccon = 0b01110001;

// timer0... configure source and prescaler

option_reg = 0b10000011;

cmcon0 = 7;

// configure io

trisa = 0b00001010;

trisc = 0b00001111;

ansel = 0b11111100;

// turn on the ADC

adcon1=0b00100000; //fOSC/32

adcon0=0b10000001; // Right justify / Vdd / AD on

// initialise MIDI comms

init_usart();

// Initialise the controllers

initInput(0, 0, 1);

initInput(1, 0, 2);

initInput(2, 0, 4);

initInput(3, 0, 7);

initInput(4, 0, 11);

initInput(5, 0, 74);

adcInitComplete = 0;

for(;;)

{

doADC();

if(adcInitComplete)

{

for(i=0;i<ADC_MAX;++i)

checkInput(i);

adcInitComplete = 0;

delay_ms(20);

}

}

}

Stylophone MIDI controller

2010-02-21T09:21:00.000-08:00

A few months ago I used an Arduino clone board to send MIDI messages out of a Stylophone. I always intended to take it to the next level and get another Stylophone (preferably a broken one) and rip out the guts to fit all the electronics inside, and also add a few buttons and pots for perfomance controllers.

Well, I finally got round to it. This time I am using a PIC16F688 microcontroller.. this little monkey only has 14 pins and costs a mere £1 yet it has a built in clock, serial port and ADC, which means its pretty much the *only* component needed in this project (with the exception of a couple of resistors and switches).

I added a pitchbend pot, a modwheel and a pot to control the note velocity. And pushbuttons to shift octaves and "hold" a MIDI note (basically force the code to forget to send note-off message so the last note rings on after lifting the stylus). This allows a kind of polyphonic drone out of the usually strictly monophonic stylophone.

I will include the code below. I wont bother with a schematic, but the wiring to the PIC16F688 is as follows

pin 1 - 5 volt supply
2 - octave UP momentary switch (other side of switch connected to ground)
3 - octave DOWN momentary switch (other side of switch connected to ground)
6 - to pin 5 of MIDI out socket via a 220R resistor. Pin 4 of the socket is pulled up to 5V via another 220R resitor
7 - wiper of PITCHBEND pot (100k). Pot terminal between from ground/+5V
8 - wiper of VELOCITY pot (100k). Pot terminal between from ground/+5V
9 - to the stylus. Also pulled up to +5v via 470k resistor
10 - activity LED via 1k resistor
11 - wiper of MOD WHEEL pot (100k). Pot terminal between from ground/+5V
13 - HOLD NOTE momentary switch (other side of switch connected to ground)
14 - to ground

If you want to run it from a PP3 you'll need a 5V voltage regulator. You also need to connect the stylophone keyboard/resistor ladder between 0V and 5V and you will need to set up the scale[] array based on the ADC values you get from each pad on *your* stylophone keyboard (which are almost certainly different to mine)

A few photos


// MIDI STYLOPHONE.. PIC16F688.. (c) 2010 hotchk155

// SourceBoost C



// Header files

#include <system.h>

#include <memory.h>



#pragma DATA _CONFIG, _MCLRE_OFF & _WDT_OFF & _INTRC_OSC_NOCLKOUT

#pragma CLOCK_FREQ 8000000

typedef unsigned char byte;



#define MIDI_A    45  // default root note

#define NO_NOTE   0x7f // means stylus "off keyboard"

#define NUM_PADS   20  // number of stylophone pads  



#define BUTTON_DEBOUNCE 10  // debounce octave buttons

#define ADC_AQUISITION_DELAY 10 // settling time for ADC

#define PBD_TOL   16  // tolerance applied to pitchbend ADC

#define MOD_TOL   5  // tolerance applied to modulation ADC



// Digital pins

#define P_HEARTBEAT  portc.0 // activity LED

#define P_UP   porta.5 // octave UP button

#define P_DN   porta.4 // octave DOWN button

#define P_HOLD   porta.0 // note hold button



// Analog pin mappings

#define ANA_MOD 0b00001000  // AN2 - MOD WHEEL

#define ANA_KBD 0b00010100 // AN5 - KEYBOARD STYLUS

#define ANA_VEL 0b00011100 // AN6 - VELOCITY

#define ANA_PBD 0b00011000 // AN7 - PITCHBEND



// define the four analog inputs

enum {

 ADC_KBD,

 ADC_VEL,

 ADC_MOD,

 ADC_PBD,

 ADC_MAX

};



// for the state machine which read analog inputs

enum {

 ADC_CONNECT,

 ADC_ACQUIRE,

 ADC_CONVERT    

};



// define the ADC readings for each stylophone key pad. This

// is likely to be different if you make your own circuit, so

// you will need to work out your own ADC values

int scale[NUM_PADS+1] = {

 0x000,

 0x043,

 0x081,

 0x0b9,

 0x0ed,

 0x110,

 0x149,

 0x172,

 0x199,

 0x1bd,

 0x1df,

 0x1ff,

 0x21c,

 0x238,

 0x252,

 0x26b,

 0x281,

 0x298,

 0x2ab,

 0x2c0,

 0x3ff

};



// midi note at bottom of scale (can be shifted

// up and down by an octave at a time)

char baseNote = MIDI_A;



// data used by doADC function

byte adcInput[ADC_MAX] = {ANA_KBD, ANA_VEL, ANA_MOD, ANA_PBD};

byte adcInitComplete = 0;

int adcResult[ADC_MAX] = {-1,-1,-1,-1};

int adcIndex = 0;

int adcState = ADC_CONNECT;



////////////////////////////////////////////////////////////////

// 

// init_usart

//

// Initialise the PIC16F688 USART (serial port) according to the

// requirements of sending MIDI traffic

//

void init_usart()

{

 pir1.1 = 1; //TXIF transmit enable

 pie1.1 = 0; //TXIE no interrupts

 

 baudctl.4 = 0;  // synchronous bit polarity 

 baudctl.3 = 1;  // enable 16 bit brg

 baudctl.1 = 0;  // wake up enable off

 baudctl.0 = 0;  // disable auto baud detect

  

 txsta.6 = 0; // 8 bit transmission

 txsta.5 = 1; // transmit enable

 txsta.4 = 0; // async mode

 txsta.2 = 0; // high baudrate BRGH



 rcsta.7 = 1; // serial port enable

 rcsta.6 = 0; // 8 bit operation

 rcsta.4 = 0; // enable receiver

 

 spbrgh = 0;  // brg high byte

 spbrg = 15;  // brg low byte (31250 baud) 

}

  

////////////////////////////////////////////////////////////////

// 

// send

//

// Send a single byte out on the serial port

//

void send(byte c)

{

 txreg = c;

 while(!txsta.1);

}



////////////////////////////////////////////////////////////////

// 

// sendController

//

// Send a MIDI continous controller message

//

void sendController(byte channel, byte controller, byte value)

{

 P_HEARTBEAT = 1;

 send(0xb0 | channel);

 send(controller&0x7f);

 send(value&0x7f);

 P_HEARTBEAT = 0; 

}



////////////////////////////////////////////////////////////////

// 

// startNote

//

// Send a MIDI note on message (or note off if 0 velocity)

//

void startNote(byte channel, byte note, byte velocity)

{

 P_HEARTBEAT = 1;

 send(0x90 | channel);

 send(note&0x7f);

 send(velocity&0x7f);

 P_HEARTBEAT = 0; 

}



////////////////////////////////////////////////////////////////

// 

// pitchBend

//

// Send a MIDI pitchbend message (14 data bits)

//

void pitchBend(byte channel, int value) {

  P_HEARTBEAT = 1;

  byte msb = (value>>7)&0x7f;

  byte lsb = value&0x7f;

  send(0xE0 | channel);

  send(lsb);

  send(msb);

  P_HEARTBEAT = 0;

}



////////////////////////////////////////////////////////////////

// 

// doADC

//

// State machine for running the ADC and updating the adcResult

// array with the result from each analog input. This function is 

// called periodically and keeps the adcResult[] array updated so

// other code can just check the array rather than making direct

// calls to the ADC

//

void doADC()

{

 switch(adcState)

 {

  // Connect ADC to the correct analog input

  case ADC_CONNECT:   

   adcon0=0b10000001 | adcInput[adcIndex];

   tmr0 = 0;

   adcState = ADC_ACQUIRE;

   // fall through

   

  // Waiting for a delay while the ADC input settles

  // - this is neededs or you can get garbage readings

  // as the ADC transitions between one input voltage

  // and another. The TMR0 (timer 0) register is used for

  // timings this

  case ADC_ACQUIRE:

   if(tmr0 > ADC_AQUISITION_DELAY)

   {

    // Start the conversion

    adcon0.1=1;

    adcState = ADC_CONVERT;    

   }

   break;

   

  // Waiting for the conversion to complete

  case ADC_CONVERT:

   if(!adcon0.1)

   {

    // store the result. Note that the PIC16F688 has

    // a 10 bit ADC so we need to form a 10 bit value

    // from ADRESH and ADRESL

    adcResult[adcIndex] = (((int)adresh)<<8)|adresl;    

    

    // and prepare for the next ADC

    if(++adcIndex>=ADC_MAX)

    {

     adcIndex = 0;

     

     // flag that each ADC has been read at least

     // one time, so adcResult now contains valid

     // information

     adcInitComplete = 1;

    }

    adcState = ADC_CONNECT;    

   }

   break;

 }   

}



////////////////////////////////////////////////////////////////

// 

// getNote

//

// Map ADC values from the stylus to MIDI note values by 

// looking for the scale[] entry which lies closest to the

// input value

//

char getNote(int input)

{

    for(int i = 0; i < NUM_PADS; ++i)

    {

      int lo = 0;

      int hi = 0x3ff;

      if(i>0)

      {

        lo = (scale[i-1] + scale[i]) / 2;

      }

      if(i<NUM_PADS)

      {

        hi = (scale[i] + scale[i+1]) / 2;

      }

      if(input >=lo && input <=hi)

      {

        if(i==NUM_PADS)

          return NO_NOTE;

        return baseNote+i;

      }

    }

    return NO_NOTE;

}



////////////////////////////////////////////////////////////////

// 

// main

//

// Where program starts running!

//

void main()

{ 

 // osc control / 8MHz / internal

 osccon = 0b01110001;

 

 // timer0... configure source and prescaler

 // port A weak pull ups enabled

 option_reg = 0b00000011;

 

 // enable pull ups on each button

 wpua = 0b00110001;



 // turn off the comparator to allow digital IO on CIO pins

 cmcon0 = 7;               

 

 // set data direction on each pin       

 trisa = 0b00110101;              

 trisc = 0b00001110;              

 

 // set up the analog input pins

 ansel = 0b11100100;

  

 // turn on the ADC

 adcon1=0b00100000; //fOSC/32

 adcon0=0b10000001; // Right justify / Vdd / AD on



 // start up the serial port

 init_usart();

 

 // ensure that the initial aquisition is completed

 // for all analog inputs that we're using

 adcInitComplete = 0;

 while(!adcInitComplete)

  doADC();

 

 

 //char buttons = 0;

 char debounce = 0; 

 char lastNote = NO_NOTE;

 int lastPitchBend = -1;

 int lastModWheel = -1;

 int value;

 int diff;

 for(;;)

 {

  // the debounce variable makes sure that user

  // has release buttons for a period of time before

  // a new press on the button can be registered.

  // handles possibility of "switch bounce"

  

  // Buttons are pulled up and touch ground when 

  // pressed, so the pin reads low when the button

  // is being pressed

  if(debounce > 0)

  {

   if(P_UP&&P_DN)

    --debounce;

   

  }

  else

  {   

   if(!P_UP)

   {

    // octave shift UP

    if(baseNote < 103)

     baseNote+=12;

    debounce = BUTTON_DEBOUNCE;

   }

   else if(!P_DN)

   {

    // octave shift DOWN

    if(baseNote > 12)

     baseNote-=12;

    debounce = BUTTON_DEBOUNCE;

   }

  }



  // poll the ADCs

  doADC();



  // check for a new note being played

  char note = getNote(adcResult[ADC_KBD]);

  if(note != lastNote)

  {

   // do we need to kill the previous note?

   if(lastNote != NO_NOTE && P_HOLD)

   {

    // make it so!

    startNote(0,lastNote,0);

   }

   // is a new note playing (rather than stylus

   // removed from keyboard?)

   if(note != NO_NOTE)

   {

    // play a note with appropriate velocity

    char velocity = (adcResult[ADC_VEL]>>3)&0x7f;

    startNote(0,note,velocity);

   }

   lastNote = note;    

  }



  // check for change in pitchbend which is 

  // outside the "noise" tolerance

  value = adcResult[ADC_PBD];

  diff = value - lastPitchBend;

  if(diff*diff > (PBD_TOL*PBD_TOL))

  {

   // Send MIDI pitchbend.. this has a 14-bit

   // data value

   pitchBend(0, value<<4); 

   lastPitchBend = value;

  }



  // check for change in modwheel which is 

  // outside the "noise" tolerance

  value = adcResult[ADC_MOD]>>3;

  diff = value - lastModWheel;

  if(diff*diff > (MOD_TOL*MOD_TOL))

  {

   // Send MIDI continuous controller message

   // for controller #1 (mod wheel) which has

   // 7 bit data value

   sendController(0, 1, value);

   lastModWheel = value;

  } 

 }

}

DIY Games Console

2010-02-10T13:03:00.000-08:00

Another PIC project... this one using a 14-pin 16F688 and playing a version of "Breakout". I might see if I can get a convincing version of "Space Invaders" to run on that 8x8 matrix too....

Usual setup of 74HC595 shift registers (x3) and ULN2803 NPN transistor arrays (x2). Columns are driven directly thru 100R resistors from one of the 595's... rows alternate red LEDs/green LEDs and are driven via 2 x chained 595's (data out from one goes to data in on the other) which in turn drive the NPN arrays, so only 5 I/O's from the MCU are needed to drive the display..

- Data in for the 595 driving the columns
- Shift clock for the 595 driving the columns
- Data in for the first of chained 595's driving the rows
- Shift clock for the pair of 595's driving the columns
- Store clock line for all 3 x 595's

There are 4 buttons: 3 are connected to PIC I/O for controlling game (only 2 used for Breakout game) and other is MCU reset (grounds MCLR#). 12k pull up resistors on all 4 lines.

The piezo buzzer is connected to the remaining I/O via a 0.1uF capacitor.

The LED matrix was from Sure Electronics (on eBay).. I got 10 of them for about £10. It is red/green but by driving both you get orange.

Here is the PIC code

#include <system.h>
#include <memory.h>

// Config bits
#pragma DATA _CONFIG, _WDT_OFF & _INTRC_OSC_NOCLKOUT

// Clock freq (for SourceBoost delayt functions)
#pragma CLOCK_FREQ 8000000

typedef unsigned char byte;

// define IO ports
#define P_STORE     porta.2
#define P_DT_ROW    porta.4
#define P_SH_ROW    porta.5
#define P_DT_COL    portc.0
#define P_SH_COL    portc.1
#define P_BUTTON3 portc.5
#define P_SPEAKER portc.3
#define P_BUTTON1 portc.4
#define P_BUTTON2 portc.2

// define IO port direction
#define P_TRISA 0b00000000
#define P_TRISC 0b00110100

// macro defs
#define SET_RED(x,y) disp[y]|=1<<(7-(x))
#define SET_GREEN(x,y) disp[8+(y)]|=1<<(7-(x))
#define SET_ORANGE(x,y) SET_RED(x,y); SET_GREEN(x,y)
#define BUTTON_DEBOUNCE 2

// info used by the interrupt handler
byte soundPhase = 0;
byte soundPeriod =  100;
byte soundDur = 0;

// display buffer (rows 0-7 for red, 8-15 for green)
byte disp[16];

//////////////////////////////////////////////////////
//
// interrupt handler
//
// timer0 interrupt is used to drive the piezo speaker
//
void interrupt( void )
{
// check if this is timer0 overflow event
if( intcon.2 )
{
// drive the piezo sounder
soundPhase=!soundPhase;
P_SPEAKER = soundPhase?1:0;

// still sounding?
if(!soundDur)
{
// stop the interrupt.. killing sound
intcon.5 = 0;
}
else
{
// still sounding
--soundDur;
}

// setup the next timer interrupt
tmr0=soundPeriod;

// clear interrupt flag
intcon.2 = 0;

}
}

//////////////////////////////////////////////////////
//
// beep
//
// start a sound playing
//
void beep(byte pitch, byte dur)
{
soundPeriod = 255-pitch;
soundDur = dur;
intcon.5 = 1;
}

//////////////////////////////////////////////////////
//
// refresh
//
// update the LED matrix based on content of the
// disp[] array
//
void refresh()
{
  int i;

  // clear vertical shift register and load a logic 1 at
  // bit position 0. This bit will be shifted along to
  // drive each row of the LED matrix in turn
  for(i=0;i<16;++i)
  {
    P_SH_ROW = 0;
    P_DT_ROW = (i==15)?1:0;
    P_SH_ROW = 1;
  }
  P_DT_ROW = 0;

  // for each row of data (8 x red, 8 x green)
  for(i=0;i<16;++i)
  {
// this cross reference of vertical bit position to row of the
// disp[] array is used since the matrix is connected for wiring
// convenience and the order of rows is different
byte ix[16] = { 15, 7, 14, 6, 13, 5, 12, 4, 0, 8, 1, 9, 2, 10, 3, 11 };

// look up the row data byte
    byte d=disp[ix[i]];

    // store clock low
    P_STORE = 0;

    // load the 8 bits of data
    for(int j=0;j<8;++j)
    {
      // shift a column bit
      P_SH_COL = 0;
      P_DT_COL = d&1;
      P_SH_COL = 1;
      d>>=1;
    }

    // store clock high.. row data is clocked to
    // the output of shift registers, simultaneously
    // with the clocking in of a new scan row in the
    // vertical shift registers
    P_STORE = 1;

    // set pins low again and add a "display delay"
    // while the row data is shown, before it is
    // hidden again
    P_SH_ROW = 0;
    P_DT_COL = 0;
    delay_ms(1);
    P_SH_ROW = 1;
    P_STORE = 0;
  }
  P_SH_COL = 0;
  P_SH_ROW = 0;
}

void breakout()
{
int i;
byte bricks[8];
byte rowsOfBricks=3;
byte speed = 250;
byte lives=3;

// loop for each level
for(;;)
{
// setup the wall
memset(bricks,0,sizeof(bricks));
memset(bricks,255,rowsOfBricks);

// init variables
char x=3; // position of bat
char bx=4; // position of ball
char by=6;
char dx=0; // direction of ball
char dy=-1;

// ball movement counter. Set to a value to
// give a short delay at the start of a level
byte bc = 100;

// counter used to debounce the movement buttons
byte buttonDebounce = 0;

// loop until level is complete
for(;;)
{
// do we need to move the ball?
if(++bc == 0)
{
// reset the counter
bc = speed;

// calc next ball position
char nx = bx + dx;
char ny = by + dy;
if(nx<0||nx>7) // off screen left or right
{
dx=-dx;
nx=bx;
}
if(ny<0||ny>7) // off screen top or bottom
{
dy=-dy;
ny=by;
}
if(ny==7) // on the bottom row?
{
if(bx==x) // flat hit left side
{
if(dx>0) dx=0; else dx=-1;
beep(200,50);
}
else if(bx==x+1) // hit right side
{
if(dx<0) dx=0; else dx=1;
beep(200,50);
}
else if(nx==x) // hit left end
{
dx=-1;
beep(100,50);
}
else if(nx==x+1) // hit right end
{
dx=1;
beep(100,50);
}
else
{
// ball has dropped off bottom of screen
for(i=0;i<3;++i)
{
// death routine
refresh();
beep(50,100);
delay_ms(100);
refresh();
beep(150,100);
delay_ms(100);
}

// lose a life
if(lives-- <= 0)
{
// all lives gone
for(;;)
{
for(i=0;i<50;++i)
refresh();
delay_ms(500);
}
}
else
{
// start of next round
x=3;
bx=4;
by=6;
dx=0;
bc=100;
}
}

// common stuff
nx=bx;
ny=by;
dy=-1;
}

// move the ball
bx = nx;
by = ny;

// hit a brick?
if(bricks[by]&(1<<(7-bx)))
{
// remove the brick and bounce
bricks[by]&=~(1<<(7-bx));
dy=-dy;
beep(100,200);

// any bricks left?
byte allGone = 1;
for(i=0;i<sizeof(bricks);++i)
{
if(bricks[i])
{
allGone=0;
break;
}
}

// end of level
if(allGone)
{
// beep
for(i=0;i<10;++i)
{
beep(50,50);
delay_ms(100);
}

// add more bricks
if(rowsOfBricks<5)
{
rowsOfBricks++;
}
else
{
// or make it faster
if(speed < 254)
++speed;
}
break;
}
}
}

// prepare screen buffer
memcpy(&disp[0], bricks, sizeof(bricks));
memcpy(&disp[8], bricks, sizeof(bricks));

// show ball
SET_RED(bx,by);

// show bat
SET_GREEN(x,7);
SET_GREEN(x+1,7);

// still in debounce period?
if(buttonDebounce)
{
// wait for button release
if(P_BUTTON1 && P_BUTTON2 && P_BUTTON3)
buttonDebounce--;
}
else
{
// left?
if(!P_BUTTON1)
{
if(x>0) x--;
buttonDebounce = BUTTON_DEBOUNCE;
}
// right?
else if(!P_BUTTON2)
{
if(x<6) x++;
buttonDebounce = BUTTON_DEBOUNCE;
}
}

// and refresh the display
refresh();
}
}
}

void main()
{

osccon = 0b01110001; // osc control / 8MHz / internal
cmcon0 = 7; // comparator off
ansel=0; // digital IO

trisa = P_TRISA; // port A I/O direction
trisc = P_TRISC; // port C I/O direction

porta = 0; // clear port A
portc = 0; // clear port C

option_reg = 0b10000011; // timer0... configure source and prescaler
intcon.7 = 1; // GIE - enable interrupts
intcon.6 = 1; // PEIE - enable interrupts
intcon.5 = 0; // T0IE - timer 0 interrupts diabled for now
intcon.2 = 0; // T0IF - clear timer 0 interrupt flag

breakout();
}

DIY radio controller for Lego

2010-01-10T13:35:00.000-08:00

This was an experiment with a couple of Holtek remote control encoder and decoder chips (HT12E and HT12D) together with a cheap RF transmitter and receiver pair I picked up off ebay. OK, so the chips are not really designed for controlling models (more for opening your garage doors and so on) and lego's own IR controller would probably work better but its all good fun!

The receiver connects up to the Lego Power Functions 9V battery box and drives 2 power functions motors independently with forward/stop/reverse control. I bought a couple of power functions extension cables to get the connectors.

The receiver uses a cheap RF receiver module from ebay (I got receiver + transmitter for about £9) which is connected to the Holtek H12D. The address bits are all tied to ground and the data bits feed the 4 inputs of an L293D motor driver. A 7805 +5V regulator supplies the IC's and the RF receiver circuit (since the Lego 9V supply is too high for them)

The timing resistors on the H12D receiver are 100K + 12K in series. These pair with the transmitter's 1M + 470K (I'm not sure how good these selections are but it seems to work...)

The transmitter simply drives the 4 data bits of the H12E with tactile switches (closed to ground, pull ups on open). The H12E is powered and transmit enabled all the time the transmitter is on (to make sure the "all buttons off" state is transmitted to stop the motors)

Since there is no proportional control its all a bit stop-start and sometimes I found the receiver got "stuck" while the car was spinning on the spot and I had to place the transmitter really close (I think the electrical noise from the motors might be to blame.. but I also suspect my timing resistors not be quite right)

PLAYPAD program for Launchpad fun

2010-01-06T02:30:00.000-08:00

I've been promising it for a while but I finally got round to making a download for other people to try out my Launchpad MIDI experiments.

Downloads and description are here...
http://sites.google.com/site/skriyl/Home/launchpad-playpad-download

Check out the mindblowing visuals...

Make your own annoying musical greetings card!

2010-01-03T14:24:00.000-08:00

I love the tiny 8 pin PICs from Microchip.. an entire computer in a package the size of a fingernail that costs pennies and can be programmed from your PC using just C and run on a watch battery. They're great.. but its taken me a while to find a use for one.

This was a quick and silly project to play a tune on a piezo sounder. Hopefully the comments in the source code included below are enough to work out whats going on.. this was actually a great project to work out how to use timers and interrupts on PICs, which I'd not done before. There were a few little hoops to jump through to fit the melody data into the tiny EEPROM space (128 bytes) of the 12F629.

I used SourceBoost C and PICkit 2 USB programmer.


#include <system.h>

// config word; internal oscillator, watchdog and master clear are off
#pragma DATA _CONFIG, _INTRC_OSC_NOCLKOUT & _WDT_OFF & _MCLRE_OFF

//Set clock frequency
#pragma CLOCK_FREQ 4000000

// This is the tune data... high nybble of each byte is the relative duration (1-16) and the
// low nybble is the note (1-16) or a break (0). Note numbers are mapped to frequencies in 
// code. A melody can use only 15 different notes in total and the total number of bytes that
// can be stored in EEPROM on a PIC12F629 is 128. There is a null terminator at the end of the
// melody data
#pragma DATA _EEPROM, 
0x44, 0x20, 0x44, 0x10, 0x18, 0x16, 0x10, 0x14, 0x16, 0x10, 0x18, 0x1b, 0x10, 0x18, 0x16, 0x10, 
0x14, 0x41, 0x20, 0x41, 0x10, 0x15, 0x13, 0x10, 0x11, 0x13, 0x10, 0x15, 0x17, 0x10, 0x15, 0x13, 
0x10, 0x11, 0x44, 0x20, 0x44, 0x10, 0x18, 0x16, 0x10, 0x14, 0x16, 0x10, 0x18, 0x1b, 0x10, 0x18, 
0x16, 0x10, 0x24, 0x10, 0x1b, 0x1a, 0x10, 0x19, 0x18, 0x10, 0x17, 0x16, 0x10, 0x15, 0x14, 0x20, 
0x16, 0x20, 0x14, 0x10, 0x14, 0x16, 0x10, 0x17, 0x48, 0x20, 0x48, 0x10, 0x18, 0x19, 0x10, 0x1a, 
0x1b, 0x10, 0x1a, 0x19, 0x10, 0x18, 0x17, 0x10, 0x16, 0x15, 0x10, 0x16, 0x17, 0x10, 0x16, 0x15, 
0x10, 0x11, 0x12, 0x10, 0x13, 0x44, 0x20, 0x44, 0x20, 0x44, 0x20, 0x44, 0x20, 0x24, 0x1b, 0x1a, 
0x10, 0x19, 0x18, 0x10, 0x17, 0x16, 0x10, 0x15, 0x34, 0x36, 0x44, 0x40, 0x00

typedef unsigned char byte;

// info used by the interrupt handler
byte next_tmr1h = 0;
byte next_tmr1l = 0;
byte wave = 0;

// interrupt handler called when the timer1 overflows
void interrupt( void )
{
 // check if this is timer1 overflow event
 if( pir1 & (1 << TMR1IF) )
 {
  // set up the timer 1 counters so they will overflow 
  // again after the appropriate time delay
  tmr1h = next_tmr1h;
  tmr1l = next_tmr1l;
 
  // toggle pin state GPIO5, which drives the piezo sounder
  wave=!wave;
  gpio = wave? 0b100000 : 0b000000;  
  
  //clear timer 1 interrupt bit
  clear_bit( pir1, TMR1IF ); 
 }
}

void main( void )
{
 // configure timer1 for interrupts / no prescaler
 t1con=0; 
 intcon.6=1;
 intcon.7=1;
 pie1.0=1;
 clear_bit( pir1, TMR1IF ); //clear timer 1 interrupt bit
 
 // set up IO pins
 trisio = 0;
 gpio=0;

 // loop forever
 for(;;)
 {
  byte addr = 0;
  byte data = 0;
  
  // loop through the tune
  for(;;)
  {
   // read byte from EEPROM
   eeadr = addr;
   eecon1.0 = 1;
   data = eedata;
   ++addr;

   // a zero byte indicates end of the tune
   if(!data || addr > 0x7f)
    break;
    
   // extract the note number from the low nybble
   byte note = data & 0x0f;
   
   // play a note?
   if(note)
   {
    // lookup corresponding frequency
    long freq = 0;
    switch(note)
    {
    case 1: freq=196; break; // G
    case 2: freq=220; break; // A
    case 3: freq=247; break; // B
    case 4: freq=262; break; // C
    case 5: freq=294; break; // D
    case 6: freq=330; break; // E
    case 7: freq=349; break; // F
    case 8: freq=392; break; // G
    case 9: freq=440; break; // A
    case 10: freq=494; break; // B
    case 11: freq=524; break; // C
    }
    
    // convert this into the correct timer count values
    // Internal clock is 4MHz and Timer1 counts at 1/4 
    // of this frequency (1MHz). We need to call the 
    // interrupt handler at double the pitch frequency so
    // that we can generate the 2 phases of the square wave
    // pulse. What we calculate here is the initial 16 bit 
    // Timer1 value that will overflow (at 0xffff) after the 
    // appropriate period of time.
    long l = (0xffff - (500000L/freq));
    next_tmr1h = l >> 8;
    next_tmr1l = l&0xff;
    tmr1h = next_tmr1h;
    tmr1l = next_tmr1l;
    wave = 0; 
    
    // enable the timer (start sound)  
    t1con.0=1; 
   }
   else
   {
    // disable the timer (stop sound)
    t1con.0=0; 
   }
     
   // duration is in top 4 bits. We'll just 
   // us an empty "for" loop to provide a delay
   int dur = 70*(data >> 4);
   for(int p=0;p<dur;++p)
   {
    // empty for loop for delay
    for(byte q=1;q;++q);
   }
  
  }
 }
}

The poor mans Harmonic Keyboard

2010-01-03T13:31:00.000-08:00

I have always been curious about the Axis Controllers and their unusual key layout, particularly as this 'harmonic table' layout is intended to make chord structures simpler and easier to understand. I wondered what it would be like to play one and thought, hey, maybe I could do it on my Novation Launchpad..!

The first problem is that the Axis has a staggered honeycomb of a hexagonal keys where the Launchpad is a square 8x8 grid. I thought the notes might translate better if the Launchpad was held at 45 degress, but eventually decided to keep it simple.

Here is the key layout I ended up with...

The code is based on some earlier Launchpad MIDI projects. It is Visual C++ / Windows API code which simply receives input from the pad, sends MIDI to light up the buttons and outputs a MIDI stream to Reason (which actually makes the sounds). I used the wonderful Midi Yoke utility from Midi-OX which lets you transmit MIDI from one Windows application and use that stream as input to another (without that I would need to implement a Windows Midi Input device)

I am gathering all my recent Launchpad experiments into a single app which I will post for download together with source code some time soon. Watch this space.

edit: get it here http://sites.google.com/site/skriyl/Home/launchpad-playpad-download

what the blog?

2010-01-03T09:02:00.000-08:00

Well, here I am in the blogosphere... lets see how long this lasts... At the very least I hope to post up info about my various spare-time projects; music, electronics and so on. Maybe the occasional rant if you are lucky. Catch you later