Decoding the PG-200

Just did something cool - I used a logic probe and decoded the PG-200 protocol :) I've identified the address of every switch, button and potmeter. However, since two of the rotary switch shafts on my PG-200 are loose, I have to get the multimeter out and do some measuring of the various position to verify that some of the logic measurements are correct.

So far I can tell the following about the PG-200 (partially from the service manual, partially from my research.

The manual says that the dataformat is asyncronous serial start-and-stop. The PG uses a 0 as a start bit and 1 as a stop bit (or stop period, as it runs untill a new start bit is encountered).

The data format is 9 data bits, no parity. The 8 first bits are address or data bits, the 9th selects either data or address. 1 is address, 0 is data.

Each potmeter sends two frames, one with the address and the second with the value
Switches are sent as three frames and are grouped as they only require 1 bit per state (or two for up to four states as is the case with the rotary switches). The first frame is the address of the group, the second is a bitmask saying which bits in the third frame to look at, the third frame is the state of all switches within that group.

From experimenting I've figured out the following:
The output from the PG is inverted, 0 is high and 1 is low
The bitrate is 31.5kb/s, which makes sense since the transfer line is connected to the same data RX line as the MIDI in (which of course is also 31.5kb/s

There are three switch groups, with addresses 1-3
There are 18 potmeters with addresses from 16 to 33

I will add the addresses and bits in groups for all controllers as soon as I have decoded the last rotary switches.

Success at last!

Finally! The hihat started working five minutes ago :-)

I did a lot of debugging on the circuit itself:
- touching up on all solder joints in the HH circuit
- checking every single path in the HH circuit (measuring conductivity)
- checking every solder joint through a magnifying lense
- measuring every resistor value
- checking that no electrolytic capacitor legs had broken off

Through all this I found a few suspicious solder joints, as well as created (and later discovered) a short circut. I also found three errors in the 9090 Hihat schematics, two of which does not matter and one that certainly do - however, the PCB is the correct one...

Anyway - I am not sure of any of this actually had much to do with the error. After taking a very close look at the various connectors involved in the HH, I discovered that a crimp in the HH tune connector was bent out of shape. It makes sense if this was the error, as it would affect both the closed and open hat. After replacing the crimp, I put the PCB back in the box and hooked up all cables - and whaddaya know, it works! :) Now, this was the last known HARDWARE error (excluding the rotation encoders that are just anoying, not really an error).

I also tried moving the headphone amp away from the circuit board to remove the noise (after all the previous supply line tricks failed to do so), however, this did NOT work. The noise in the stereo mix main out is not that bad though.

Now all I have to do is put everything back together again, and pray for everything to work once that is done :)


The bent crimp is seen through the right hole.

Output working

No idea why, but when I switched back to the old output stage, it worked perfectly fine. Some loose connections somewhere, bad solder joints or something maybe.

However, this means that untill the problem comes back again, I will leave the circuit board in the box. This also means that I won't replace C6 and C7 (changing from 1uF to 10uF would have improved the bass responce as the 1uF filters away anything below 140Hz, greatly impacting the bass drum when tapping the signal from the stereo mix jacks).

Now, if I could only get that Hihat working again. Tried swapping U42 for a new, known good opamp, but no luck.

Also, I will try moving the headphone amp away from the box to see if I can get rid of some noise.

New output mixer tested

Instead of unmounting the entire circuit board from the machinebeats, I decided to make a new output mixer on a prototype board. The output mixer consists of 7 components - four capacitors, two resistors and an TL072 opamp (+ the necessary connectors), which means that I only need to check a very limited amount of circuitry on the original board if the new one works.

Well, after 1 1/2 hours of building, and 10 seconds of testing, I conclude that it is indeed one of these 7 components or attached solder points that don't work as intended. I still have to remove the circuit board, but at least now I know where to look :-)

Cymbals fixed

The cymbals and hihat have never been loud enough, rather, they've been much quieter than the rest of the voices.

Today I searched through the archives at yahoo groups, and discovered that this is a well known problem that has a known fix. After replacing three resistors, the cymbals are much louder :)

However - the stupid silent hihat is back. Earlier this year I had problems with the hihat not triggering (or not making any sound at least). When I put a probe from my oscilloscope to either the collector of Q73 or pin 2 of U42, it worked, but when removing the probe it stopped working again. Somehow I managed to make it stay working, but now it is broken again. No idea why, this really frustrates me!

Also, the main output is way too low and the main output pot is working the wrong way, turning DOWN the sound when moving to the right. Strange.

Modding the power wiring

Just finished rewiring the internal power lines tonight. I have had some serious problems with digital noise in the headphone stage. The headphone amp drew power from the same board as the midi controller and other digital electronics reside on. I have changed this so that it now draws power from the card closest to the transformator. Also, I have re-added a 5v voltage regulator to the controller board and added a separate ground wire. I hope this fixes some of my problems.

While having the lid off I've also added the missing 500ohm (or actually dual 1k in parallell) pot to BD Accent, so now I thing everything except for the too-low samples/output levels are fixed. Fingers crossed, will test tomorrow!

Progression

So, I got several things fixed friday.

One led had actually broken (though only the red part, the green was still working), one had been short circuited by solder (very strange!) and one was simply working but since the key didn't work it was not possible to activate the step.

As for the keys, after unsoldering the left-key I discovered that one of the pins had been bent on assembly. Bending this back out and resoldering the key fixed the problem. I also remembered that, since this key has always been broken, I did a work-around in software to be able to complete the code - I remapped the first step key to work as the left-key. This, however, means that I have to build a new version of the firmware to fix this.

Now, the sampled sounds are another strange case. As no sound could be heard, and it has been working previously, I tried swapping in the old sample ROMs for the new ones (Crash cymbal only). This worked! But even stranger, when the crash started working, the ride cymbal also seems to work. Hi hat is still broken though. I will try swapping in all the old chips to see if they work. If they do, my conclusion is that there's something fishy with the new chips.

When it comes to the output mix, I did some testing with a stand alone headphone amp circuit, and could clearly hear the sound playing - but at a very low volume. I tried swapping the mixing OP-AMP, but this didn't do the trick. However, at the same time I noticed that the separate outputs are very clean and free from digital/powersupply noise! This means that the noise heard when using the headphone output is either introduced in the mixing stage or in the headphone amp itself. I have to investigate this further.

Yesterday I also managed to put together the front panel inner/outer assembly for the first time. After trying several ways to get things together, I came to the conclusion that the parts have to be put together in the following order:

- First, insert the upper part with the display and pots.
- Then insert the lower aluminium plate, but without the circuit boards.
- The keypad then has to be wiggled into place from the right, between the top plate and the spacers extending from the lower plate.
- Now, screw the two plates together using two countersunk screws.
- Connect the keypad to the main keyboard and the main keyboard to the controller
- Slide the keyboard under the front 'lip' of the box and screw it to the bottom plate.

Voila! Everything should be in place :-D

Today I will hopefully start attaching the new wires for the potmeters. I will use a technique called wire lacing to keep the wires together, instead of using plastic strips. This will make the bundle less rigid and saves a lot of room since the thread used (waxed linen cord) toes not protude from the cable bundle :-D (Thanks dad, for learning me how to do this back in the early nineties :-D)

Still pushing for a July deadline, but some issues may have to be worked out in September. Here is a shortlist of what I think is missing:

- Rewire pots
- Change the power for the backlight and side lights
- Recompile the code
- Fix the samples
- Fix the output stage, check introspectiv groups to see what they wrote about the output level being too low
- Get a stereo 1k pot for the Bass drum attach, solder the channels together to make a mono 500Ohm pot.


Also, it would be nice to do the following:
- Figure out where all the noise comes from. Will be a bit hard though.

Yesterday was a great day...

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

Modular synth parts arrived

I got a shipment of parts today, enough to build 20 something modules for a modular synthesizer. The PCBs have been etched and drilled already. Pots and front panels are still missing though, and I'm not sure if I want to create a pre-patched synth with ext. out/in or just a normal modular. We'll see.

On another note, I've also mostly finished the box for the 909, including retractable feet! I might just order it after easter.

Finished programming (!?)

This is a great day. The sun is shining, it's about 29 degrees outside (This is Norway and it's not even June yet, so that is pretty good). And the drum machine code is now ready for extensive testing. I guess there are still some small bugs in there, but now all major and minor functionality is finished and the machine is playing cool rythms :-D

Next up will be to get some silk screen equipment and start work on the box. Also I've had to come to terms with a few shortcomings with the current controller design. The LEDs flicker a bit while the sequencer plays, and the encoders are a bit unstable. To overcome this I will have to build a completely new controller again (v5), with a separate led controlling circuit, and with dedicated encoder chips. However, everything works ok, so this wont happen for a while.

I had to re-make the ribbon cables between the controller and the keyboard as well. Half of the numeric keyboard didn't work due to some stupid wiring mishap. Now the only key that doesn't work is the left-key. I'm not sure why yet, have to get my multimeter out and start measuring :-D

I guess this wraps things up for summer, have fun untill the cold winds of fall makes it possible to be inside coding again :-D

Dial idea

I thought of a new cool feature last night - what if, instead of switching instantaneously between two settings, the leds would 'fade'/count down or up to the desired level (within 0,5 seconds or so)?

For example, say that 2 diodes are lit. then a change to 10 diodes is requested. Instead of instantly lighting the 8 diodes, they would lite up like 3, 4, 5, 6 ,7, 8, 9 and then 10, creating a moving indicator. Each diode could even fade in to make a more pleasant effect.

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

Encoder/leds circuit v1

I've started work on the led dial. So far I've left it to the users to decide if they want to use i2c or any other way of inter-ic communication, all data transmission pins are available as pin outs.

I've also added a mikroelektronika-compatible programming interface to enable programming of the chip after soldering.

The chosen mcu, pic18F2431, contains both a quadrature decoder and an internal ocillator, making the number of external components very low.

I have not yet tried the programming circuit like this, so it may have to be changed.

The schema:



The PCB. Dimensions 29 x 29 mm:



I still have some work to do on the footprint of the encoder, and of course have to find a way to solder this since the mcu, resistors and capacitor are SMDs

Digital LED brightness control

While working on the encoder-with-led-ring concept I figured it might be cool if I could control the brightness of each LED individually. For example, the led ring brightness could increase while turning a specific encoder, or the leds be brighter the further 'up' the ring they are.

I already intend to time multiplex the diodes to get away with a single resistor between 16 leds, so I thought, why not try using pulse width modulation (is that the correct term?) to control the LED brightness in software?

I just did a proof of concept, and although the picture below doesn't do the result justice, you can clearly see that it works :-D

the code for the test is dirt simple. Each led down the row is turned on twice as long as the previous one, exponentially increasing the time (but not the brightness):

Pseudo code of the program is as follows:

while(true){
PORTD = 1;
delay_us(10);
PORTD = 2;
delay_us(20);
PORTD = 4;
delay_us(40);
PORTD = 8;
delay_us(80);
PORTD = 16;
delay_us(160);
PORTD = 32;
delay_us(320);
PORTD = 64;
delay_us(640);
PORTD = 128;
delay_us(1280);
}

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.

Midi controller 4 v1.0 PCB received

Resent events: turned 30 yesterday... Sigh. I would have hoped to be finished before turning 30, but noooo.

I also received the new PCB for the controller. I've already populated it, testing starts tonight. I have great expectations for this new version. However, I still haven't tried the digital giver circuits, so perhaps I'm in for a version 1.1 of MC4 as well? Only time will tell.

New controller finished

Except for finishing touches and error checking, Midi controller number 4, v1.0 is finished! This uses a single 40 pin mCU instead of two smaller ones, which made it a challenge to route all the paths in the small space available. It looks promising though.

I just tought of another idea for a dual mCU version though. Perhaps it would be possible to use i2c for communication between the devices? In that case, I would be able to use hardware instead of software-emulated com, but I'm not sure about the speed of the i2c bus. Will have to research this later if I get into trouble running everything on a single mCU (It should not be a problem, but who knows...).

Here is a pic of the new PCB:

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!

Inter-mcu communication working

I've finally got the communication working with both mcu's on the controller pcb. I ended up bending away pin 6 on the LCD/midi controller, to prevent it from interfering with the data transfer, and it works very well. finally I can test the transfer protocol :-)

Keyboard PCB problems

I have made a crucial mistake on the keyboard PCB. The second line of instrument buttons is connected to select line 1 instead of 2, meaning both rows map to the same keys :-( This has to be fixed by cutting a line on the keyboard and connecting it manually to select line 2. Bummer.

Also, SEL9 and 10, going to the keypad, are not working properly. This could be just the cable though.