Category Archives: build log

Building Tannin 2

In this post, I’ll be talking about build process of my latest and greatest MIDI controller; Tannin 2. It took me almost 5 months to actually finish it since there were so many architectural changes in it that I basically started from scratch.

The design

Tannin 2 design is, naturally, very similar to the original Tannin controller (incidentally, I never actually wrote a post about that one since it was finished some months ago before I started this blog). Since Tannin 1 is first Shantea Controls controller ever built, it has a special meaning for me – not so much as a physical product since it’s disassembled (I used some of its parts for Tannin 2) – but more as an idea. I had to make sure that Tannin 2 would be a worthy successor. For the reference, here’s the rendering of original Tannin controller:


Assembled controller:


And one from the back:


I can assure you it looks much better on the pictures than it really looked.

It had 16 potentiometers and 16 buttons in 4×4 grid, 3 additional metal buttons and 4 LEDs at the bottom. Very simple and very efficient layout. Over the time, I got used to it so much that I mapped virtually every function I need in my DJ software (Traktor Pro) using nothing but this controller. Still, it was my first controller, and naturally it had some flaws. First and most obvious one, there were too many screws. Second, that box was huge, too heavy and after few months it started to crack all over the place. It was also such a pain in the ass to carry around. On the hardware side of things, it featured Arduino Nano and circuitry that later became the basis for OpenDeck board. If you’re wondering what’s that chemical – it’s Flavan-3-ol.

So, now that we have Tannin 1 as a reference, let’s move on to Tannin 2.

Tannin 2 was imagined to be an improvement in every area – not just the flawed ones. When I thought about the design, I was trying to figure out what was missing in original controller. First of all, I wanted better buttons than those tactile ones and more LEDs. I also wanted either faders or encoders. Eventually I discarded the faders idea since it was impossible to fit them in same dimensions (I wanted to keep plate dimensions exactly the same – 200x300mm). So, after some consideration, this is what I came up with:


As you can see, design is really similar to original Tannin, but with few tweaks. Below 16 potentiometers, I wanted to have 4 encoders, and under them 16 silicone buttons with white LED inside each of them. 4 LEDs at the bottom got removed since a) I didn’t have much room left, and b) who needs 4 LEDs at the bottom when you have one in each button above? Potentiometers and metal buttons remained the same. I also added number 2 to Tannin name, even though it actually looks like letter ‘R’. Tannin Remixed? Acceptable as well. Notice that there are only few screws in this one. All in all, I was happy enough with that layout to proceed to actual build process.


As with the Ceylon controller, I wanted to experiment a bit with plate color. This time, I picked green one, and it really looks great – same as any gravoply plate.


The case

Until I built this controller, cases were always source of biggest frustration, since – let’s face it – they looked like crap, and thus ruining the overall feel of entire controller. Well, I didn’t want to go through same story again, so for a couple of weeks I was searching for someone who would do the job right. Whether or not I was successful, judge for yourself:


And back.


Finally, I have gorgeous case! That green plate really blended well with the tone of the wood. Also, its weight is just about right, not too light (it’s wood after all), and actually not heavy at all. Perfect!

One more thing – I redesigned USB cable plate:



For second revision of Tannin controller, I decided to use PCBs crafted specifically for Tannin 2, instead of using OpenDeck reference board. This proved to be a very challenging task, as I literally had to do everything from scratch. The main premise behind designing electronics for this one was that I was going to use ATmega32u4 as microcontroller. In the past, I used either Arduino Nano or Arduino Pro Mini. Both of those boards are fine on their own, however, the biggest drawback to using them is that they have no native USB capabilities. In practice, this meant that I had to use serial-to-usb adapter to program them and couple more layers of software to make them talk MIDI. In my commercial designs I also used those boards, but in addition to main board I used USB MIDI board which translated serial signals from Arduino to USB MIDI. Works just fine, but that USB MIDI board doesn’t support MIDI System Exclusive (primary method of configuring the controller) and it represents additional hardware. So, using ATmega32u4 solves both of those problems since it has USB built right into the chip. In case you didn’t know, Arduino Leonardo, Arduino Pro Micro and Teensy 2.0 use that exact microcontroller, however, this time I needed my own custom board. I needed it to be as small as possible – so Leonardo was discarded right away, I needed pretty much every available pin – discarded Pro Micro at this point as well and I also needed ability to use a custom bootloader for uploading new firmware to board. Now, you absolutely can put a new bootloader on a Teensy board – but you can’t upload the new code on it using Teensy loader then since that bootloader is proprietary, an aspect of Teensy I’m not particularly fond with. So, when you put new bootloader on Teensy, what’s the point of buying Teensy in the first place? Also, it was cheaper to buy pure ATmega32u4 chip with few external components than buying Teensy. I’ve been delaying this design with each controller since I figured that soldering SMD is going to be much harder than soldering standard DIP packages. I was right, but just because it’s harder doesn’t mean it’s impossible. You just need steady hand and some patience. The final result was this:


Only 5x5cm! Obviously, main component is ATmega32u4, the mighty brain which does all of the processing. Next, it features my standard hardware for LED/button matrix, 74HC238 decoder and ULN2803 current sink. For reading button rows, this time I added 74HC165 shift register. I had few 4021 registers lying around, but 165 register can work a bit faster, so that’s why I’ve chosen it. I also added reset button, ICSP header so that I could program it with external programmer (USBasp) and also MIDI header, which is nothing more than +5V, GND and RX/TX serial pins from microcontroller. Having them on header allowed me to test hardware MIDI on this board as well, and it works! This means I can expand this board with real DIN MIDI in/out connectors. Not that I have any use for it at the moment, but since this board will serve as a basis for OpenDeck v2 reference board, I wanted to see how it’s going to behave. Board also features pin headers on the edges to connect potentiometers, buttons, LEDs and encoders. One resistor is missing in this picture – at that point I was unsure what to do with HWBE (hardware boot enable) pin on ATmega, but more on that later.

Now, having the main board finished didn’t mean I was done with electronics. At all. First of all, those silicone buttons needed a PCB. Encoders also needed a PCB, and potentiometers as well. That’s lots of PCBs. I ended up designing a single 10x10cm board with panelized designs for each part. In total, I needed 4 separate PCBs for buttons, 2 boards for encoders and 2 boards for potentiometers. I also needed a small board for USB connector which would be housed in the box. Luckily, I managed to fit all of that in a single board, and the guy who cuts gravoply plates for me also did the cutting of PCBs.


To make one controller, I actually needed two of those boards, however, you can’t order less than 10 pieces, so that wasn’t a problem.


Free candy! I mean PCBs!

This is how Tannin 2 looked inside after first round of soldering:


Analog boards feature one 4051 multiplexer each. One of them is “slave”, other is “master”. This only means that slave (right one) connects to master (left one) using 6-pin IDC cable. That allowed me to use only 7 wires from master analog board to main board. Encoder boards feature 5 pins each. Both boards also connect to main board. Four boards with LEDs and silicone buttons have shared columns, so each board connects to the next using four wires. Finally, those four wires are connected to main board. Boards also have one LED/button row wire each, so that’s two additional wires from each of the four boards to main board. Three metal buttons below also connect to main board on assigned pins.


I used some hot glue to ensure the wires don’t move and break. Each board has one resistor for LEDs and 4 diodes for button matrix (there are actually 2 diodes per package so there are 2 packages per board). Diodes for three metal buttons are placed on main board.

Since encoders are nothing more than a two buttons, they are connected in separate button matrix. Reason for separation is that button/LED matrix switches columns every 1ms, and that’s too slow to read encoders properly. Setting the matrix to faster switching rate would result in LED flickering since I also needed PWM for LEDs.

Final look inside:


That wooden part makes sure the button PCBs don’t bend. Also, main board is designed so that it fits perfectly on four screws holding two PCBs together. Finally, I added some hot glue to secure all contacts:


Entire schematic will be available on my GitHub at some later date.


As I mentioned before, Teensy 2.0 board uses ATmega32u4, same microcontroller that I picked. Even though Teensy boards are compatible with Arduino, software is of much higher quality and they can also be programmed as USB MIDI devices, something Arduino boards aren’t officially capable of doing (at least in Arduino environment). Selecting Teensy 2.0 board in Arduino IDE and then trying to upload it to Arduino Pro Micro or Leonardo won’t work because Teensy uses Teensy Loader to load software on board, which in turn communicates with their HalfKay bootloader, which you can’t download. However, I needed that USB MIDI stack that Teensy boards provide. So, I simply connected my main board to USBasp programmer, selected Teensy 2.0 as a board, USB MIDI as device type and uploaded it to board. Note: if you want to upload code to Teensy/Arduino using external programmer, simply hold shift and then press upload. That worked flawlessly! Board immediately showed up as Teensy MIDI on my computer. Awesome! Now, the hard part was moving all of my existing OpenDeck code to Arduino-style format. In the process, I integrated most of Ownduino functions directly into OpenDeck library. I could talk about the software part for hours, but you can easily check the code yourself on my GitHub. This was all very nice, but every time I needed to change something in the code, I needed to connect external programmer to main board. In practice, this meant constant opening and closing of controller – quite tedious. I needed a bootloader and I found one. It’s called USB Mass Storage Bootloader and it’s really fantastic. After you reboot your board into bootloader mode, your PC shows a new device connected to your PC: removable drive! It shows two files: EEPROM.bin – which contains all parameteres stored into EEPROM (obviously) and FLASH.bin – the compiled code. To upload new code, simply delete FLASH.bin, copy new one, eject the drive (very important – ejecting it actually triggers the upload process), and then simply reconnect controller to USB.


The trouble I had with bootloader was that the controller was constantly turning on in bootloader mode – it never showed as MIDI device. Later I found out I need to change certain fuses on microcontroller. USB AVR microcontrollers generally have two fuses responsible for deciding whether to run user program or bootloader: BOOTRST and HWBE. If you enable BOOTRST, microcontroller is going to run bootloader everytime it’s reset. HWBE, on the other hand, acts a bit differently. If you enable HWBE and disable BOOTRST, your device will reboot into bootloader only if HWBE is shorted to ground before you turn on microcontroller. This is why you need to hold reset key on certain devices before you can update firmware on them. I figured I don’t really need any of these fuses, so I disabled both of them. I want microcontroller to always run application program, and bootloader only on demand. To trigger the bootloader reset, I need to send specified MIDI System Exclusive message to controller. After that, controller reboots into bootloader mode, showing as a disk drive. Just what I want. Great! Another puzzle was how to generate that FLASH.BIN file? I only use Arduino IDE for testing out stuff and use Atmel Studio for any bigger project. After you compile project in Atmel Studio, it generates .hex, .elf and few other files inside your project directory. You can also define “external tools” in Atmel Studio. I defined one such tool to convert .elf to .bin. Basically, you need avr-objcopy tool with these parameters:

-O binary -R .eeprom -R .fuse -R .lock -R .signature <compiled_project>.elf FLASH.bin

I only need to figure out how to do that automatically after compilation so that I don’t have to manually invoke the command.


This is how controller looks right now – fully assembled:


So, here’s a quick video showing Tannin 2 in action. Notice how LEDs fade now – I finally added PWM support with selectable fading speed using System Exclusive.


Building Ceylon

This is a long overdue post about Ceylon, another Shantea Controls controller, only this time, one that I’ve built for myself. Of course, it’s based on OpenDeck platform.

Ceylon was actually built about three months ago. Reason why I haven’t written about it is a combination of things really. First, it was in a beta period for more than a month, and after that I just didn’t have much time to write posts, as I was really busy (and still am) with other projects that I’ll hopefully write about soon.

Name and design

Let’s start with a name. After Anandamidi and Sensimidia, it was time to bring back tea in Shantea Controls again. So, Ceylon is actually well-known high-quality tea originating from Sri Lanka, former British colony known as Ceylon (hence the name). There are couple of variations of it, black one being my favorite (with some spices of course, that is, loads of ginger).


Picture above is a rendered drawing of Ceylon design. Numbers around the circle are coordinates of Kandy District, heartland of tea production in Sri Lanka. So there you have it, a Ceylon story!


Since Tannin was my only controller so far, I’ve mapped nearly every function I need, so when I started designing my second controller, I wanted something really simple that would complement Tannin well. There was no need for a complicated layout or redundant functions, that’s why its design is really minimal. There are 3 faders, 12 orange LEDs for some eye-candy, err, I mean VU-meter, shift button, two potentiometers above faders for gain control, six anti-vandal switches with blue LEDs, and disk. Most significant change here from Tannin is the use of encoder. Well, not your usual encoder though. It’s a salvaged HDD motor acting to be encoder actually.


Ceylon is first controller I’ve built which doesn’t use standard black/white Gravoply plate, as I grew tired of it. Instead, I’ve picked blue plate this time, and it looks really gorgeous.


I also redesigned USB plate.


Case is white again, just like Tannin.

The disk

As I’ve already stated, only thing new in Ceylon is the disk. So, how does it work? The motor in mechanical hard disk generates phase-shifted sinusoidal waveforms when spinned. The faster you spin it, larger the amplitude and frequency of waveforms. By examing waveforms, you can determine disk direction, which is what I needed. There are couple of issues with this:

1) Signal amplitude is way too low to be sampled directly by a microcontroller, unless you spin the disk real fast, which is kind of missing the point of whole setup as you want fine grained control. My measurements showed that disk generates +-500mV when spinned at maximum speed (maximum being somewhat subjective term, I spinned it by hand).

2) For encoders, you don’t actually need analog signals, but digital ones. By examining output data from two encoder pins, you can easily determine its direction. Those two outputs are called quadrature outputs, as they are 90 degrees out of phase.



Making the signals digital

Basically, what this setup needed was ADC (analog-to-digital converter). For this use, I’ve chosen LM339, a very cheap, available and popular comparator. LM339 contains four comparators in a package, making it suitable for this setup, as I needed only two. Comparator takes two inputs, and simply determines which one is bigger. If voltage on non-inverting input (+) is larger than voltage on inverting input (-), output is digital 1, or Vcc, and if non-inverting input is smaller than inverting input, output is digital 0, or -Vcc (in this case GND). Very simple. But as usual, there are couple of caveats.


Connecting motor inputs directly to LM339 isn’t such a good idea, for two reasons:

1) What happens if two signals are very close to each other? Comparator would output bunch of ones and zeros very fast, which is actually junk, so you get unreliable results.

2) According to LM339 datasheet, you cannot apply more than -0.3V at either of its inputs. This is a problem, as disk actually outputs about -0.5V when spinned real fast.


It took me really long to figure out what hysteresis actually is, but it’s actually really simple. Using hysteresis on comparator, you are creating two thresholds for generating two output states, that is, you are setting one threshold for output to be Vcc, and second one to be -Vcc, that is GND. This is achived by applying positive feedback from output back to input, using two resistors. Since signal from motor is really low, I’ve designed hysteresis for low values, just to keep signal from circling around switch point. Hysteresis is calculated using this formula:

Vth+ = -VN ∙ (R1 / R2)
Vth-  = -VP ∙ (R1 / R2)

Vth is threshold voltage, Vn is negative output (in this case 0V), and Vp is positive output (+5V in this case).  I wanted to set positive threshold above 0V, and negative below -5mV, so resistor values are 1k for R1, and 1M for R2:

Vth+ = -0 * (1000/1000000)
Vth+ = 0V
Vth- = -5 * (1000/1000000)
Vth- = -5mV

So, when positive input voltage is above 0V, output is 1, and only when negative input drops below -5mV, output is 0. This way I created “dead zone”, or area where my signal can be of any value (between 0 and -5mV), without affecting the output of comparator.


Graph is showing the input signal (U), usage of comparator on that signal without hysteresis (A), and output signal from comparator with applied hysteresis (B).


Picture above shows hysteresis setup. This is how you debounce your inputs using hysteresis, so that your output never becomes gibberish.

Voltage clipping

Now, there is one more concern. As I stated already, inputs on LM339 cannot be smaller than -0.3V. To accommodate this, I used BAT46 Schottky diode on inputs, having anode connected to ground. When the input is positive, diode doesn’t do anything as current cannot pass through. When the input is negative, diode still won’t do anything, as long as input voltage doesn’t become smaller than -0.3V. Those diodes have a voltage drop of about 0.3V (how convenient), so, when input voltage exceeds -0.3V, current will pass through diode, and voltage on comparator input will actually be voltage drop on that diode, and it will not exceed those -0.3V. Two problems solved, yay!


Software side of things

Now that I’ve taken care of hardware, it was time to actually read and process signals from motor. For this, I’ve used modified encoder library for Teensy/Arduino. Library is great as it has two really clever parts:

1) Since it’s written with Teensy/Arduino in mind, it automatically detects whether the pins on your microcontroller on which you’ve connected encoder have interrupt capability. If they do, library reads encoder using interrupts. Since HDD motor can be spinned real fast, I’ve connected both motor pins to interrupts (pins 2/3 on Arduino) in order not to miss any pulse. Pins 2 and 3 are two out of four unused pins on my OpenDeck board, so this was very convenient.

2) It has “predicting” algorithm, giving your encoder 4x more resolution. This is achieved by remembering previous state of pins, and comparing it to current state of pins with a lookup table. Lookup table contains valid encoder transitions:


This works really, really well, but since HDD motor jumped a bit when changing direction, I’ve implemented additional debouncing:

void OpenDeck::readEncoders(int32_t encoderPosition) {
if (_board == SYS_EX_BOARD_TYPE_OPEN_DECK_1) {
if (encoderPosition != oldPosition) {
if (millis() - lastSpinTime > ENCODER_DEBOUNCE_TIME) initialDebounceCounter = 0;
if (encoderPosition > oldPosition) {
if (!direction) { initialDebounceCounter = 0; direction = true; }
if (initialDebounceCounter >= ENC_STABLE_AFTER) {
sendPotCCDataCallback(127, 127, 5);
} else initialDebounceCounter++;
else if (encoderPosition < oldPosition) {
if (direction) { initialDebounceCounter = 0; direction = false; }
if (initialDebounceCounter >= ENC_STABLE_AFTER) {
sendPotCCDataCallback(127, 1, 5);
} else initialDebounceCounter++;
oldPosition = encoderPosition;
 lastSpinTime = millis();

If there is a movement detected, code first checks for whether the disk hasn’t been moved for more than ENCODER_DEBOUNCE_TIME (70mS). If it hasn’t, it resets the debounce counter. This is to avoid extra pulses when disk is slowing down. After that, initialDebounceCounter variable is incremented until it reaches 1. This is to prevent disk jumping when changing direction.

So there you have it, a pretty good resolution from HDD motor for use in MIDI controller! In all honesty, its resolution is far from optical encoders, but as this is more of a proof-of-concept, I’m really satisfied with results.

LEDs on anti-vandal switches

This was another issue that I had while building Ceylon. Anti vandal switches (the ones around the disk) I had around have blue LED on them. Their pins are separated from button pins. Those button pins can be connected in NC and NO configuration, so there’s 5 pins in total. Since I’m using shared column button/LED matrix in my OpenDeck platform, I’ve connected – pin of LED and one of button pins together, going into same column, and then + pin of LED into LED row, and second button pin to button row. Nothing out of ordinary, right? Well, something weird was happening with this setup. Whenever I pressed the button, LED on it lighted up. This is not the behavior that I expected nor wanted, so for a while I had no idea what was happening. Only few days later, I’ve discovered that it doesn’t really matter where you connect + and – of the integrated LED on button, since there are 2 LEDs inside, one of which has anode on + pin, and second one on – pin.

anti vandal configuration

Okay, but why does the LED turn on when button is pressed? For this, answer is in matrix setup. LED/button matrix works by switching columns very rapidly. Only one column is active at the  time, and during that time, it is connected to GND, while others are connected to Vcc. When button is pressed, connection from microcontroller input on which button is connected goes to GND, and button press is registered, but only during the time the column is active. When column isn’t active anymore, it’s connected to Vcc. Since those switches have two LEDs inside, one of which has anode on – pin, when button is pressed, and column isn’t active, that anode is actually connected to Vcc, and LED row on microcontroller starts acting like current sink, so LED is lighted up.


In order to solve this, I’ve placed Schottky diode (to minimize voltage drop) between LED anodes and microcontroller LED row pin, so that the current is blocked for second LED inside switches.



So, to conclude this post, here’s a short video of Ceylon in action, together with Tannin.

And also some higher quality pictures of Ceylon.

IMG_8551 IMG_8553 IMG_8565

Thanks for reading!

Sensimidia MIDI controller

Sensimidia is third Shantea Controls controller, and also my second commercial project. I’ve been working on it for the last two months, but most of that time I did nothing, because of some delivery issues with faders and box. Now that it’s finally over, I’d like to present it here.

SensimidiaIn many ways, Sensimidia is similiar to Anandamidi controller. Same buttons, same pots, same faders, same mounting techniques – except for the faders, which I’ve done right this time. It features 24 buttons, 12 LEDs, 6 rotary potentiometers and 2 faders. I’ve also added two additional mounting screws to the plate to avoid its bending, although I should’ve added two more – one in the middle left, and one in the middle right. Design features logo from the guy who ordered the controller. It turned very cool, but then again, that board has magical capability of turning everything into something super-nice.

This controller is first controller I’ve built using my recently-announced OpenDeck platform, therefore, if you’re interested what hardware does this run, scroll few posts below. Worth of note is that even though it’s based on OpenDeck design, it doesn’t mean Sensimidia runs full version of OpenDeck software. Yes, buttons, pots, MIDI input – all of that works, but full controller configuration via MIDI System Exclusive messages doesn’t work yet. Luckily, that is nothing to worry about in this case, since the guy really wanted something simple that works out-of-the-box. I can always update the firmware on controller later – once the OpenDeck platform is finished, and also assuming the guy would actually want the extra features.

Anyways, here’s how Sensimidia looks all wired-up:

OLYMPUS DIGITAL CAMERAAs I said, it’s all very similiar to Anandamidi construction. This OpenDeck board connects to my MIDI USB PCB via pin header right above that electrolytic cap.

OLYMPUS DIGITAL CAMERAThis is how it looks in case. Very nice, but a bit too dark for my taste.

P1010005_crAnd standard USB plate for the cable.

All in all, very fun project again, even though it’s not been really that much different from Anandamidi. Here’s a quick video I’ve taken demonstrating some of controller functionality (really sorry for the lack of good camera and tripod):

Building Anandamidi, part 4

This is the last post about Anandamidi, I promise! So, in case you forgot, this is the remaining stuff to finish the controller:

  1. Painting the case
  2. Interfacing Arduino with separate USB MIDI chip on separate PCB (Altmustech AU-123)

1) Painting the case

Fairly easy part. I’ve simply bought black spray for wood and sprayed the case 3-4 times. Looks really cool!


Thing I haven’t mentioned before is the cable plate and the cable itself. I bought several of these USB cables off eBay:OLYMPUS DIGITAL CAMERA

I’ve cut off the mini-b part of cable and replaced it with 4 cables with female headers on them, so that I can simply plug it to USB MIDI or serial conversion board. Since just screwing that cable directly on wooden case would look rather ugly, I’ve also designed a cable plate board, made from same Gravoply board as the main plate.

OLYMPUS DIGITAL CAMERAMuch nicer, although I’m not too happy with screws on that plate (I haven’t had anything else). Right, let’s move on to #2.

2) USB MIDI board

OLYMPUS DIGITAL CAMERAThere were more than several issues with this thing, as usual. After I received the PCBs, I asked a friend to help me solder that MIDI chip, since I’ve never soldered SMD component before, plus I don’t have necessary equipment for that job. After we soldered everything, connecting the board to PC did nothing. No errors, no anything. Checked everything few times, but I couldn’t find the error. Grrr! Since that didn’t work, I’ve decided to give the controller to the guy for whom I was building it without that board. Instead, there’s simple CP2102 serial module inside the Anandamidi at the moment. Everything is the same, except that way you need to install drivers (atleast if you’re on Windows), install virtual midi port and an app which converts serial messages from Arduino to MIDI. Couple of extra unnecessary layers, but it works without issues. After I got home, I spent few more days trying to figure out where I did mistake. Eventually, I figured I used capacitors far too large to be put in parallel with 12MHz crystal which MIDI chip needs. I bought 22µF tantalum caps, simply because the official documentation said only “22” for two crystal caps, so I assumed they meant microfarads. Did I mention how expensive tantalum caps are? Very. Tantalum caps are very expensive. Oh well. What I needed was 22pF caps, so after I bought them, suddenly everything worked. Hooray! Windows happily reported it found new USB MIDI device. Awesome. Unfortunately, issues didn’t end here.

Testing the board

For first try, I only connected TX pin from Arduino to RX pin to that board, so I was only able to send data from Arduino to PC. It worked without any issue whatsoever, so I assumed sending MIDI data to that chip would work as well. Wrong. I’ve tried to send some  MIDI messages to Arduino via that chip, only to get some gibberish values. Checked everything more than dozen of times, didn’t find anything wrong. So, I went back to reading the AU-123 documentation (after things don’t work, RTFM, right?) and noticed something interesting:


Active high? What the hell is that? Apparently, pins on microcontrollers can be either active high or active low. Active high means that HIGH signal (usually +5V) represents binary 1 and vice versa. Active low is exactly the opposite: +5V signal represents binary 0 and 0V represents binary 1. After some more investigation, I learned that USART pins on AVRs are active low, meaning that I need inverter if I want to interface them with active high signals. That was also the reason I got gibberish value on Arduino end without the inversion. Obviously, there’s more than several ways to invert digital signal. First I tried with NAND gates (74HCT00 chip) – worked! I simply connected one input of single NAND gate to +5V, and other input was the TX pin from AU-123 chip. Output from gate was inverted, so I connected it directly to Arduino RX pin. While this solution works, that chip contains 4 NAND gates and has 16 pins, and I only need one input on gate, so it’s a waste of chip. Instead, I went with transistor solution (2n2222):


Really simple schematic and works just like the NAND gate solution. Finally, the MIDI USB board is fully fuctional.

Controller demo

Since everything works, here’s a video with Anandamidi, and my first controller, Tannin. Note that this was recorded before the case was painted. Enjoy.

Building Anandamidi, part 3

Like last time I posted here, there’s been much progress. In fact, the controller is already working, even though everything isn’t finished yet. So, let’s start where we finished last time. Faders!

Placing faders

As I’ve already stated, I had some issues with placing the faders. Main source of issues was that I didn’t have any 2mm screws to screw them to the plate. As I’ve found out, those tiny screws are incredibly hard to find, at least in my area, so I had to figure out something else.


Above each fader, there is really thin piece of plastic board super-glued to its surface. Couple of mm away there is standard 3mm hole. To make it more stable (otherwise that plastic would’ve fallen off) there are wooden holders screwed really tight so that there’s no way anything can happen with faders. Wooden pieces on left/right fader are shown here only for reference, as I designed PCB to fit between those two faders, but more on that later. Pretty dirty hack, as it involves extra stuff like wooden pieces, plastic and superglue. And, as the only real constant in universe says “thou shalt not use superglue without supergluing thyself”, I managed to spill some glue on my sweat suit. 😦 So yeah, building MIDI controllers is dangerous. You have been warned.

Worth of mention is that all of this would never happen if I had those damn small screws! I eventually ordered bag of them from eBay, when I finished all this, since eBay shipping times are getting horrible lately, and I wanted to get this done as soon as possible.


I’ve done PCB schematic in EAGLE CAD, my so-far favourite PCB design application. The board houses Arduino Pro Mini, two resistors for LED rows in matrix, 16 diodes for buttons in matrix to enable multi-press, 4051 multiplexer for potentiometers and couple of capacitors to make everything run more smoothly. There’s also lot of pin headers for wiring LEDs, buttons and fader. Pretty simple schematic, but prone to errors like everything. After all, what is a project without issues? There were three issues in total with PCB, but luckily, all are solved.



1) The board dimensions

PCB has been designed to fit between left and right fader, to make wiring more efficient and easier. Unfortunately, I completely forgot that I have to pay attention to board height, as those 3 mm screws actually set the height limit. To my good fortune, lower dimensions were okay and upper  needed a bit of trimming with sandpaper. Luckily, I’ve checked the design in EAGLE with upper few mm cut off, to see if that would mess with ground planes. It didn’t! One issue solved.


2) Button matrix and diodes wiring

This issue popped out after I’ve finished wiring all the buttons. So, I connected the controller in PC to check if everything is OK with buttons. Yes, they all worked, but eight left buttons registered as only four buttons, and same thing happened on the right side. Basically, pressing buttons next to each other showed up as same button. A bit of inspective work later, I found out I made really stupid mistake of connecting two buttons under same row and column on PCB design. Ugh!

OLYMPUS DIGITAL CAMERAThe fix consisted of soldering four buttons on the left to right side of PCB and vice versa. Not too much of a problem, but after that I had 8 wires in total soldered directly to PCB, which really broke my modular design, as I wanted each component to be un-pluggable.

3) Ground issues

This is probably the last time I’m ever going to build something with PCB without protective layers. Only reason I did it this time is because I ordered PCB from local shop from which I can get PCB done in a few days, but the prices are absurdly high compared to ITead studio, for example (I found out about that site after I already sent PCB to production, of course). Ordering 10 of those boards from ITead with protective layers, silks etc. would’ve costed me LESS than single board I used here, without any of those layers, just plain double-layered board. Ugh. Lesson learned. Anyways, after I connected pretty-much everything, the LEDs started to behave weirdly, as well as two buttons (their presses showed up like pressing couple of buttons instead of only one). Again, some investigation revelead that one of my columns in matrix-setup was connected to ground. The reason it did is because after I soldered PCB to faders, one tiny bit of PCB surface touched a piece of metal part on fader, short-circuiting that column line to ground. With protective layers this would’ve never happened. What I had to do was to un-solder faders, disconnect every wire from PCB and also to un-solder those 8 wires from issue #2 (somehow I knew sooner or later I would have to do that, things just DON’T work at first, second or third try). After that I’ve put some isolation tape across whole bottom of both faders, and also on PCB to places where I connect faders, just to be sure. Messy bussiness again, but I fixed it.

After solving all the issues with PCB, everything worked. Below the board there are two wooden pieces, put there so that I can screw the four screws to secure both the board and faders, and also to avoid bending of PCB.

The box

After I finally solved all the issues with electronics, I was still left with couple of other things. The first was the case. It’s a fairly simple wooden case, and the guy who did it has done pretty good job. Things can always be better, but sometimes they don’t have to be.


Remaining stuff:

  1. Painting the case (black!)
  2. Interfacing Arduino with separate USB MIDI chip on separate PCB

More on that next time!

Building Anandamidi, part 2

Lots of progress since my last post. I got the plate, already placed most of the components, finished software and just today I made some final adjustments to PCB.

Here’s how the plate looked after I got it and after I’ve put some stuff on it:


That board is really awesome, sometimes I feel it’s not worth even designing anything since the board alone looks so good with anything engraved on it. The fader screws in this picture were not actually those I prepared for Anandamidi. They’re only here since at the time I did not have them yet. LED holders are here, but they don’t contain any LEDs yet. Buttons were originally mechanical buttons, but not anymore. More on that later.

One of the advantages of having 2-plate board (plexiglass+gravoply in this case) is that you can make two different layouts for each board. I used that advantage to make holes for screws bigger on engraved board, and smaller on plexi, so that they don’t stick out. I made the same thing with buttons: round hole on plexi, square hole on top. I only wish I made those squares for buttons 0.2mm smaller so that they truly don’t move at all, even tho it’s fine like this as well, when I screwed them I hardly noticed anything.



Tweaking the buttons

Here’s the thing with those buttons. I had a bunch of them, back when I first started doing all this and was unaware of many different types of switches (hey, a button is a button, right?). These were mechanical, and they’re truly awful, atleast if you intend to use them on DJ controller where you need instant reaction. However, unlike most of mechanical buttons I’ve seen, these can actually be disassembled. Let’s see what’s inside!



Lots of stuff inside. They’re really hard-to-press because of those strings. When you press them, you push them until that small metal circle touches the pins on the cap. Some buttons react better, some worse, some react just random (no reaction at all on hard press, reaction on light press, etc.). In short, pretty crappy. However, given that they can be hacked into, plus they look really nice,  I figured I must somehow use those things instead of throwing them to garbage can (where they almost did end up few years ago when I bought over 30 of them only to find out they’re crap – they were not cheap, that’s the worst part). So, just for the kicks, I removed all that stuff inside the button and tried to put a tactile switch underneath it to see if they fit.


 Awesome! Now all I needed was something to put inside the button instead of those strings, and something to keep that tactile switch from falling. Simple metal screws proved as great replacement. It turned out you can even screw them inside the switch, so that they don’t fall out. Wow, these buttons are truly awesome for tweaking! That’s the first part of problem, the second was to keep tactile switch below the button. It’s the best to take a look at the pictures, instead of reading an explanation:

983653_452628388217130_1167125224532009197_n 10154176_452628404883795_6039742779084255572_n 10151967_452628478217121_7552256885835806934_n

 Great. Nice looking buttons with even nicer tactile switches below them.


LEDs were a lot simpler task. I had lots of both LEDs and metal holders for them, however, those holders don’t actually “hold” the LED in place as they should, as they tend to move a lot. Simple solution was adding a bit of heat-shrinkable tube between that plastic cap in which LED goes and LED itself. LED does need to be pushed a bit harder into the holder after that, but you don’t have to worry about whether will it move or fall out – because it won’t.



Only thing I added to pots are pin headers. That way the wiring is a lot easier, and if for some reason pot fails, or you (for whatever reason) want to unplug it, then you just do. No need to unsolder, then solder again etc. Plug and play.


I already did some soldering work to LEDs. Since they work in matrix (like buttons), each column of LEDs on Anandamidi has a single row, which simplifies soldering a lot.

Only components not there yet are faders. They are kind of tricky, and I had some issues with deciding how to screw them, but more on that in next part.