So, what's the news?
Well, assembly is going great, and yesterday I powered up the machine for the first time after wiring it up. At first nothing happened. After a few scary minutes I figured I forgot to put the fuses in the power entry connector :-)
Next problem - nothing showed up on the screen, and something smelled funny... The keyboard and sequencer seemed to work though, but no sound could be heard.
After a bit more debugging, and an hour of work, the following was fixed:
- New cable for the display - six of the wires had snapped!
- The smell came from the display backlight overheating, I have to switch to a less powerful current source or something
- The missing sound was due to the two midi wires going from the controller to the analogue parts being swapped.
So, after working for a couple of hours the machine actually works!
It does however have some errors:
- The sampled sounds (Hi hat, cymbals) don't work
- The main output doesn't work (though the headphone amp works very well)
- The first step key and the left-arrow key are mixed up somehow
- Four leds are either broken or a data line is not working as intended.
- The software is slightly buggy, it crashes sometimes. No idea what causes this.
Also, the wires from the pots have to be replaced as they are too big, and the spacers between the keyboard and the aluminium back plate are too short, making it impossible to mount the display and keyboard at the same time.
All in all I'm quite satisfied with the result. I brought the machine to work today for a little demo, and my colleague rocked away ;-)
The making of a classic - this blog follows my progress as I construct and build a TR-909 drum machine clone from scratch.
Showing posts with label keyboard. Show all posts
Showing posts with label keyboard. Show all posts
Friday, 15 July 2011
Saturday, 17 January 2009
Display reconnected
I've just merged the older LCD panel code base with my newer keyboard/LED code, and also connected the LCD display to the new controller card for the first time. To my big surprise it worked immediately! Finally both the LCD screen and the keyboard are up and running at the same time. And it only took me about 3 years ;-)

I also constructed a new cable and added connectors to the LCD end as well, as the soldered-on cable started to show some wear and tear. As the connector on the controller end is a normal ribbon cable connector, but the other end requires a 2,54mm spacing of the cables, I had to add to come up with a special solution. I am very satisfied with the end result, both in terms of how the cable looks and how it will fit the system.

I also constructed a new cable and added connectors to the LCD end as well, as the soldered-on cable started to show some wear and tear. As the connector on the controller end is a normal ribbon cable connector, but the other end requires a 2,54mm spacing of the cables, I had to add to come up with a special solution. I am very satisfied with the end result, both in terms of how the cable looks and how it will fit the system.
Sunday, 16 November 2008
First keyboard/sequencer integration
For the first time since I began working on the project, the keyboard and leds now integrate with parts of the sequencer software. I've added the possibility to toggle the step leds, and switch between the 12 internal sequencer tracks. It is extremly fast and works incredibly well. I'm so really satisfied with the result! I should put up a video of this to show how cool it really is :-D
Also, I broke my PICFlash2 In-circuit programmer and had to order a new one from Mikroelektronika. Not sure what happened, but I think I put the power to my circuit on the power out pins instead of the power in ones...
Also, I broke my PICFlash2 In-circuit programmer and had to order a new one from Mikroelektronika. Not sure what happened, but I think I put the power to my circuit on the power out pins instead of the power in ones...
Labels:
909,
controller,
electronics,
hardware,
keyboard,
software
Monday, 27 October 2008
Encoder experiences
The encoders on the drum machine keyboard are working now. The missing leads discovered earlier were not the only obstacles I had to overcome. After fixing the circuit, the encoders still didn't work properly. For some reason, I had not thought about what would happen when the encoders stood still and did not have a connection to +5v. This, of course, would lead to floating inputs on the direction-detection flip flops, and no clear readings from the circuit.
I then added 10k pull down resistors to all the inputs, this fixed most of the problems and made it possible to detect encoder clicks.
However, if the encoder is turned slowly, one click of the dial leads to multiple detected clicks, as the circuit keeps outputting clicks, as the flip flops are not reset.
To fix this, I've added a state check in software. Clicks will only lead to events if a 0 has been read in between two reads of 1. This fixes most issues, but quick turns of the dial will in fact give fewer clicks than slowwe turns. Also, I've experienced a few 'backward' clicks in between the forward clicks, not sure what causes this.
But, all in all, things are looking very bright. The mode selection leds light up and respond to the encoder. Now I'll just have to get the rest of the keyboard up and running againg. And fix the head phone amplifier and get a license file for my compiler...
I then added 10k pull down resistors to all the inputs, this fixed most of the problems and made it possible to detect encoder clicks.
However, if the encoder is turned slowly, one click of the dial leads to multiple detected clicks, as the circuit keeps outputting clicks, as the flip flops are not reset.
To fix this, I've added a state check in software. Clicks will only lead to events if a 0 has been read in between two reads of 1. This fixes most issues, but quick turns of the dial will in fact give fewer clicks than slowwe turns. Also, I've experienced a few 'backward' clicks in between the forward clicks, not sure what causes this.
But, all in all, things are looking very bright. The mode selection leds light up and respond to the encoder. Now I'll just have to get the rest of the keyboard up and running againg. And fix the head phone amplifier and get a license file for my compiler...
Labels:
909,
controller,
encoder dial,
errors,
hardware,
keyboard,
software
Wednesday, 8 October 2008
Oh, how I hate hardware bugs...
I must have misplaced my head while designing the keyboard PCB.
The last two days my girlfriend and I have
1) Checked all the ICs involved in the rotary encoder circuit
2) Checked the functions of the rotary encoders
3) Checked the PCB routings for any errors or broken paths.
We didn't find any errors on the ICs, they all performed flawlessly on the bread board.
As for the encoders, they seem to be of different kinds. The tempo encoder seems to stay permanently connected to +5v and send out pulses of 0V (or rather, it varies with the position of the encoder), while the mode encoder stays at 0 and sends out pulses of +5v. Not sure if this is a problem, but it has to be checked.
The routing, however, is a different story. First of all, although it is not possible to see why when inspecting the PCB, the connection between the tempo encoder and pin 5 on the left flip flop IC is broken! This may have happened when the IC overheated earlier.
More important though, I have not routed +5v and ground to the ICs! This is a mistake made in Gschem, the software I used when designing the circuits, I simply must have forgotten to attach the necessary pins to the power connector :-(
So, right now I have to:
1) swap the tempo encoder for one similar to the mode selector one.
2) connect pin 5 on the left flip flop to pin 1 of the tempo encoder
3) connect pin 14 on the right flip flop to pin 2 of the tempo encoder (5v)
4) connect pin 7 to pin 8 on the right flip flop (ground)
...then we'll see what happens.
The last two days my girlfriend and I have
1) Checked all the ICs involved in the rotary encoder circuit
2) Checked the functions of the rotary encoders
3) Checked the PCB routings for any errors or broken paths.
We didn't find any errors on the ICs, they all performed flawlessly on the bread board.
As for the encoders, they seem to be of different kinds. The tempo encoder seems to stay permanently connected to +5v and send out pulses of 0V (or rather, it varies with the position of the encoder), while the mode encoder stays at 0 and sends out pulses of +5v. Not sure if this is a problem, but it has to be checked.
The routing, however, is a different story. First of all, although it is not possible to see why when inspecting the PCB, the connection between the tempo encoder and pin 5 on the left flip flop IC is broken! This may have happened when the IC overheated earlier.
More important though, I have not routed +5v and ground to the ICs! This is a mistake made in Gschem, the software I used when designing the circuits, I simply must have forgotten to attach the necessary pins to the power connector :-(
So, right now I have to:
1) swap the tempo encoder for one similar to the mode selector one.
2) connect pin 5 on the left flip flop to pin 1 of the tempo encoder
3) connect pin 14 on the right flip flop to pin 2 of the tempo encoder (5v)
4) connect pin 7 to pin 8 on the right flip flop (ground)
...then we'll see what happens.
Monday, 29 September 2008
Quadrature decoder how-to
I am having some problems with the new controller in terms of power consumption. While investigating this I realised that I've forgotten how the decoder for the digital pulse givers works.
Here is the original article describing the circuit:
"The Encoder Decoder Circuit"
Our task this week is to create a circuit to count pulses coming from the encoder and display the count on a dual 7-segment LED display. The circuit should be smart enough to know whether the knob is rotating clockwise or counterclockwise, and increment or decrement the count appropriately. To determine the direction of rotation requires us to build a special quadrature decoder circuit, and for this we need to learn something about computer memory.
Computers store information in millions (sometimes billions) of small devices called “flip-flops”. The purpose of a flip-flop is to store a single bit (either a 1 or 0) until requested to change. One of the simplest types of flip-flops is called a D-type flip-flop, shown in the figure at right. The functioning of a flip-flop is actually pretty simple: a piece of data is stored at (and can be read from) port Q until a clock pulse is received at the CLK port. When a clock pulse is received, whatever data value exists at the D (for data) port is written to Q. Most D-type flip-flops change state only on the rising edge of a clock pulse, hence the name “edge-triggered flip-flop”.
Our quadrature decoder circuit will make use of the data storage capability of the flip-flop. As shown in the figure above we feed the signal from pin A of the decoder into the D port and the B signal into the CLK port. If the pulses from pin A lead those of pin B, the D port will be in a high state whenever the clock port sees a rising edge – hence Q will remain high. Conversely, if the B pulses lead, Q will remain low. In this way the output at Q provides a means of decoding the direction of rotation. The circuit below shows a practical implementation of the quadrature decoder.

The circuit also makes use of two NAND gates in the CD4011 chip. The NAND gates are used to combine the constant high or low signals from Q with the pulse train from the encoder to provide pulses to the counter inputs. If Q1 is high the CLK UP port will receive the pulse train and if Q2 is high the CLK DN port will receive the pulse train.
Here is the original article describing the circuit:
"The Encoder Decoder Circuit"
Our task this week is to create a circuit to count pulses coming from the encoder and display the count on a dual 7-segment LED display. The circuit should be smart enough to know whether the knob is rotating clockwise or counterclockwise, and increment or decrement the count appropriately. To determine the direction of rotation requires us to build a special quadrature decoder circuit, and for this we need to learn something about computer memory.
Computers store information in millions (sometimes billions) of small devices called “flip-flops”. The purpose of a flip-flop is to store a single bit (either a 1 or 0) until requested to change. One of the simplest types of flip-flops is called a D-type flip-flop, shown in the figure at right. The functioning of a flip-flop is actually pretty simple: a piece of data is stored at (and can be read from) port Q until a clock pulse is received at the CLK port. When a clock pulse is received, whatever data value exists at the D (for data) port is written to Q. Most D-type flip-flops change state only on the rising edge of a clock pulse, hence the name “edge-triggered flip-flop”.
Our quadrature decoder circuit will make use of the data storage capability of the flip-flop. As shown in the figure above we feed the signal from pin A of the decoder into the D port and the B signal into the CLK port. If the pulses from pin A lead those of pin B, the D port will be in a high state whenever the clock port sees a rising edge – hence Q will remain high. Conversely, if the B pulses lead, Q will remain low. In this way the output at Q provides a means of decoding the direction of rotation. The circuit below shows a practical implementation of the quadrature decoder.

The circuit also makes use of two NAND gates in the CD4011 chip. The NAND gates are used to combine the constant high or low signals from Q with the pulse train from the encoder to provide pulses to the counter inputs. If Q1 is high the CLK UP port will receive the pulse train and if Q2 is high the CLK DN port will receive the pulse train.
Tuesday, 5 February 2008
Success!
Everything works like a dream now :) I've implemented all commands and tested the keyboard using the second controller as a loopback. It looks so good I can hardly stop working on it :-D
I may have to simplify the transfer protocol a bit though, to get increased throughput. Hopefully I can skip some error checking if I just make sure that no invalid state leads to a deadlock.
The remaining work on the keyboard is now:
- Glue some of the perspex pieces in place so they don't obstruct the keys
- Drill holes for the rotary givers and implement the necessary code
- Cut and solder the paths for the second row of instrument select buttons
- Fix the keys on the keypad that are not working (two signal paths)
- Fix a problem with S528 - it seems one of the switches does not work very well (a key release is send immediately after key press). I suspect this is a hardware error.
And then - onto coding the controlling software! Can't wait!
I may have to simplify the transfer protocol a bit though, to get increased throughput. Hopefully I can skip some error checking if I just make sure that no invalid state leads to a deadlock.
The remaining work on the keyboard is now:
- Glue some of the perspex pieces in place so they don't obstruct the keys
- Drill holes for the rotary givers and implement the necessary code
- Cut and solder the paths for the second row of instrument select buttons
- Fix the keys on the keypad that are not working (two signal paths)
- Fix a problem with S528 - it seems one of the switches does not work very well (a key release is send immediately after key press). I suspect this is a hardware error.
And then - onto coding the controlling software! Can't wait!
Labels:
909,
controller,
electronics,
errors,
hardware,
keyboard,
software
Saturday, 2 February 2008
All leds working
I'm back to working on the real keyboard circuits after spending a week debugging the soft_uart code. I've tested the leds and all work as expected, both as red and green. It looks fantastic. I've made some code testing a running light, and the outcome is really encouraging!
Thursday, 31 January 2008
Inter-uC communicatoin
I am having some problems getting the soft-uart from MikroC to work properly. I have been trying to send data from PORTA.F4 for a long time without success. Yesterday, after first having some problems because I didn't connect ground on my prototype card to ground on the EasyPIC3 development board, I managed to use soft-usart-write to send data that could be received with the real uart of the other uC. However, When I send 0x36 using the soft uart, it is received as 0x13 on the other. I have no idea why yet, either the clock frequency is wrong or some interrupt delays the sending. Will have to work on that.
Also, I had to switch to PORTA.F0, not sure if I have broken PORTA.F4 or if I just need to disable something.. not a big deal anyway, but took ages to figure out.
Also, I had to switch to PORTA.F0, not sure if I have broken PORTA.F4 or if I just need to disable something.. not a big deal anyway, but took ages to figure out.
Wednesday, 26 December 2007
(almost) finished keyboard
This is a big day for me. I've powered up the keyboard for the first time. I have not yet connected the pulse givers (dials) as the perspex pieces were not correct. I also have not been able to test all leds as the 2N3906 transistors I use are not in stock at Elfa. I do, however, suspect that using the transistors, at least in my config, is a waste, it seems the power is drawn from the controlling circuit, not trough the transistor.
The 7 leds that I've been able to connect work flawlessly, in both red and green modes. I've also (temporarily) connected the PCBs to the aluminium from Schaeffer. Some pics below.



The 7 leds that I've been able to connect work flawlessly, in both red and green modes. I've also (temporarily) connected the PCBs to the aluminium from Schaeffer. Some pics below.


Subscribe to:
Posts (Atom)