Marching forward with OpenDeck: The hardware

This post will shed some light on the development of OpenDeck platform, since it’s been quite some time I’ve done any updates on this project. Don’t let the silence fool you – project is very active.

For those who don’t know what OpenDeck is (there are couple of posts about it on this site) – it’s a MIDI platform designed to relieve you of doing tedious stuff in the build-process of a MIDI controller. Those who want to build their own controllers quickly find out that it’s not really a small thing to accomplish, even if there are some great platforms out there which can make the job much easier, such as Teensy or Arduino. You need to know how to write code, choose the right hardware, install software development tools on your computer, deal with all kinds of errors (both hardware and software) etc. OpenDeck allows you to forget about all of that. It’s a system which allows you to pick basic components of your MIDI controller – such as potentiometers, buttons, encoders, LEDs etc. – plug them into the OpenDeck board, and actually use them in your MIDI controller in a matter of minutes. Neat, right? So, how does it work? I’m going to talk about it in a couple of posts, since the project has several layers. In this one, I’ll try to do a hardware architecture breakdown of the project.

The board

The board is 10x10cm in size. It’s 1.6mm thick and the current color is green. It has four M2 mounting holes, one in each corner. I don’t have pictures of the board since I’m currently waiting for it to arrive from ITead studio, but here’s render of front and back (the holes in the corners are not displayed):




You can connect various components which are the building blocks of your MIDI controller into OpenDeck board. It allows you to connect:

  1. 64 buttons or 32 encoders max (one encoder is kinda like having two buttons)
  2. 32 potentiometers or FSRs (force-sensitive resistors)  – support for other analog sensors is planned as well
  3. 48 single color or 16 RGB LEDs

The board also contains DIN MIDI in and out ports. MIDI in port can be used in two ways:

  1. MIDI to USB converter, allowing you to receive data from MIDI gear and translate it to USB MIDI to control your MIDI software on a computer
  2. LED control, allowing you to receive data from MIDI gear and control LEDs connected to OpenDeck board.


Complete schematic and PCB files can be found on this link.


The board has only one power connector – USB (B type). Board can be used either using computer or standalone, in which case USB wall charger is required – any one will do, as long as it meets USB power spec (5V/500mA).

ESD protection

USB data and voltage lines have ESD protection diodes. There’s a nice article on electro-static discharge on Wikipedia.

Indicator LEDs

There are two LEDs on board – power and bootloader LEDs. Power LED is constantly on when board is powered on, while bootloader LED is only active when firmware update is in progress.


The brain of OpenDeck board is same microcontroller used in Arduino Leonardo and Teensy 2.0 – Atmel ATmega 32u4. That little microcontroller has USB hardware built right into the chip which allows your computer to recognize it as generic MIDI device, so that there are no drivers required on any major platform (Linux, Mac OS X, Windows).

Button/encoder hardware

In order to read buttons and encoders, a matrix setup is used. There are 8 input rows controlled by 74HC165 shift register and 8 columns controlled by 74HC238 decoder. Matrix uses column-switching to read data and there is only one active column at time during which all 8 rows are being read. There is more info on how button (and LED) matrix works on this link.

LED hardware

LED setup also uses matrix. It has 6 rows and 8 columns. Driving LED matrix directly from microcontroller is generally un-advisable, since the microcontroller isn’t really meant to be current source (or sink) so its capabilities are quite limited in that regard. Matrix can draw a lot of current, so if not careful, you can easily damage the microcontroller. In order to solve this, several components are used:

  1. LED hardware uses dedicated voltage regulator, LP2985-N. Regulator outputs stable 4V.
  2. Each LED row has a MOSFET transistor which turns the row on or off, triggered by a state of digital pin on microcontroller. This way, very little current is required to turn the MOSFET on, and when it is on, transistor draws the current from 4V voltage regulator instead of microcontroller, and feeds it into LED.
  3. Each column is connected to ULN2803 current sink, since 6 rows of LEDs can generate about 200mA of current and absolute maximum microcontroller can handle is 40mA.
  4. Current sink inputs are connected to another 74HC238 decoder so that only 3 pins are required to handle column switching instead of 8.

The big question here was which resistors to choose for LED rows. In order to achieve full brightness, most LEDs require 20mA of current. In matrix, LEDs get switched on and off very fast without you noticing it. Current flawing through LEDs in matrix is called “pulse” current, since it flaws for a very short period of time. If you would pick a resistor for 20mA of current in LED matrix, you would notice that LED isn’t really set to maximum brightness, since the current is actually lower. Because of this, we will calculate the value of resistor to achieve 30mA of current. Another problem rises here: each color of LED has different voltage drop. For instance, red LED usually has voltage drop around 1.7V. Green has around 2.2V. In order to select resistor value, I took the average voltage drop for most popular colors, based on this table. The average drop is 2.3V. For 30mA current, 4V voltage source and 2.3V of voltage drop, a resistor value of 56 ohms is chosen. Since this calculation is based on average voltage drop, the current will vary depending on chosen color.

Analog hardware

For analog components to work reliably, stable voltage is absolutely required. Like LED hardware, analog part of the board also has dedicated 3.3V voltage regulator, MCP1825. To read values from 32 analog components, two 4067 analog multiplexers are used.

MIDI hardware

MIDI in hardware requires the use of opto-coupler – I’ve selected 6N138 as recommended on MIDIbox forums and official MIDI documentation. MIDI out circuit is the same as recommended on Teensy web site.

That would be all in this post – in the next one I’ll talk about the software running on the board.

9 thoughts on “Marching forward with OpenDeck: The hardware

      1. Please post an update to reflect the information you provided at DJTechtools

        OpenDeck Web configuration utility?
        Pics of populated board, you say that your taking orders $?
        Can this board do everything that a BCR2000 can, like the ability to populate a text file with a .tx type language ( )

        A Kickstarter would surely give the best exposure and gauge of demand, especially if pitched as the BCR2000 killer….is it?

      2. Hi. Here’s the picture of populated board:

        I haven’t had much time for this lately since I’m working one full-time job and one part-time job. Moving to a new apartment hasn’t helped either. However, OpenDeck is also my thesis, and I’m writing it as we speak, so there will be a new blog post in next couple of days since there’s a lot of updates. Basically, I don’t want to write about half-finished product so I’m polishing things right now. As for Web config utility, proof of concept currently exists and it’s working – you can find demo video here:

        It’s really ugly, but as I said, it’s a proof of concept really. Since I don’t have time for Web development, I’ve hired two people to work on that tool, which should be finished in the next few weeks.

        Not really sure what you meant with BCR2000 stuff.

        Kickstarter would be nice, yeah. Maybe if I cloned myself I’d find time for everything.

  1. Since Livid is dead, hoping you everyone could utilize this hardware to make custom controllers again. I for one am looking forward to it. Any improvements since 2015?

      1. The SecretBC document is a quick read. In short, allow users to control and edit all OpenDeck ->Hardware functionality within a text file, convert to sysex and upload to said device.

        Controllers for software are well covered in the market, what’s not covered well apart from the BCR2000 is control over hardware utilizing Sysex and NRPN, Livid never had that.

        I can appreciate very much your time constraints, maybe you can elaborate in your next post how you’d like to progress your project. I’m sure a community would build around this and take up some of the public facing demands. I would recommend as a nice platform to build community.

  2. Good info from:

    This is my list of interfaces that fail with large block SYSEX (large being anything over 255 bytes)…some of these interfaces will work if you can divide the large SYSEX into small 128 byte blocks and send them one after another.

    Access Virus TI Polar
    Akai MIDI Controllers – mpkk49
    AXIOM Pro series
    AXIOM 25
    Behringer BCA2000
    Behringer BCF2000
    Behringer BCR2000
    Cakewalk UM-1G
    CME VX 5
    Edirol UM-1 Midi/USB
    ESI – Midimate II
    ESI – M4U XL
    HOSA USB to MIDI adapter.
    Focusrite Saffife Pro 14
    Focusrite Saffire Pro 24 DSP
    Focusrite Pro 24
    Focusrite Saffire 40
    Focusrite Saffire 56
    Justin Midi USB
    Lexicon I-O|FW810S
    M-Audio UNO – there are three versions of this one 1 works, 2 is flaky and 3 semi works.
    M-Audio Keystation Pro 88
    MidiTech MIDILink Mini
    MOTU 828
    MOTU 828 mkII
    NI Kore 1
    Novation Remote SL unstable SysEx transfers
    Presonus Firestudio
    Presonus FireStudio Mobile
    Prodipe 1×1
    Prodipe 4×4
    Roland UM-1
    RME Fireface 800 – intermittent
    Swissonic MIDI-USB 1X1
    Tascam US-122
    Tascam US-122L
    Yamaha UX256
    USB MIDI Cable $5 eBay Specials
    Yamaha UX16

    As I said some of these interfaces will work with small SYSEX blocks (255 bytes), some will work with smaller blocks (<255) and some will work if you only send a byte at a time.

    The $5 specials are just problems now. Some of the "current" ones I've tested show up as multiple in/out ports. That's a big red flag since they are only 1×1's. But I commonly see 2×1, or 1×2 show up in my device listings. These are the class compliant USB to MIDI converter interfaces, no driver needed.

    The interesting part of SYSEX is, without fail, almost every interface I've tested will receive SYSEX of just about any size, where they fail is on the send.

    Part of my testing is a loopback test as well. A small percentage of interfaces that work fine, have failed a loopback test.

    Lastly, for some interfaces that do work on SYSEX, they don't like a fast series of SYSEX streams coming at them. For example in the MIDICPU you can send a SYSEX where the MIDICPU will send back all the configuration as a series of SYSEX dumps, one after another. The interfaces that don't support large blocks of SYSEX will generally work for about the first 6 to 8 sysex streams they receive and then drop data for a couple and maybe catch the last one. Thus when they are hammered hard with streams, they need a "delay" between the streams or they deliver crud. I found a delay of about 100ms is all that's needed but that would have to be in the MIDICPU firmware.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.