A (mostly) 3D printed MIDI controller

Ok…so…for a while now I’ve been wanting to make a MIDI device, not that I am a very musically inclined person but they look kind of cool and I’ve seen people doing interesting things with them.

There are a lot of open projects around, most of them based on Arduinos as main controllers, a couple of examples:

Dartmobo is amazing! It’s a whole system to make highly customized devices. You have an Arduino sketch and a shield whit upto 48 inputs and 32 outputs. Ther is an app to edit and configure your device but It also has an “auto detect” function to recognize inputs by itself. I might build one of these in the future but I wanted to start with something slightly easier.

fliperRGB is a project made by Gustavo Silveira. It is also based on an Arduino, it uses a 16 inputs multiplexer, 16 buttons and 8 potentiometers. I liked this one for the simplicity but also becasue it uses RGB leds and as we all know…everything is better with RGB leds. It uses 16 WS2812w leds, one for each button.

The multiplexer is a 74HC4067. I don’t have any of these but I do have a couple of MCP506 lying around. These are 16 input analog multiplexers quite similar to the 4067, with input protections and higher voltage range.

For the buttons I have a few of these big arcade buttons:

I don’t have enough, as you can see they are humongous, there is no easy way to put the RGB leds inside (at least whit out a ton of work) and they make a huge “clank” sound when you press it. So I decided to find an alternative.

I have a lot of 6mm SMD tact switches. The plan was to design an arcade button analog around these. This is what I came up with:

Assembled button on the left, section view on the right

The button is made of two parts, the bottom (or “base”) is where the tact switch will be. The top (or “cap”) is actually two main components connected together with flexures. The outside part screw into the base and the inside is free to be pushed and press the tact switch.

The displacement is highly exaggerated in the simulation.

As the rest of the device was also going to be 3D printed I put a thread on the outside component of the cap and later on add matching threads on the holes in the front panel. This way the mounting is really straight forward.

I had to come up with a way to mount the RGB leds. I didn’t want to have to wire them individually. I wanted to use the strip (at least in a few groups) so I added a hole in the middle of the cap which allows me to pass through the led strip.

Passing those RGB strip through there was far from easy

The cap is printed in transparent PLA (to act as a diffuser) and It worked really well.

Testing the threads sizes, button separation and diffusers.

This design was working but the force you need to make in order to push one of this tact switch is considerable. At least when you compare it with the arcade buttons. I looked around on the workshop and found a stack of mouse switches. I don’t know why but at some point in time, I thought It was a good idea to desolder these things before tossing out an old/broken mouse.

Several mouse devices were definetely harm in the making of this project.

I had enough switches and they seemed to be far more easy to push than the tact switches so I redesigned the base to accommodate them.

Later on I used a kitchen scale to make a crude measurement of the forces required to activate each type of button. The mouse ones need less than half the pressure that the tact switches required and I was quite happy with the end result.

Testing the force required to activate the different switches. The display on the top is a multimeter in continuity mode. The one at the bottom is the scale in grams.

As I said before the rest of the device is also 3D printed. The front has the holes for the potentiometers and the buttons. I placed the buttons 34mm apart, roughly the distance between leds in a 30 leds/m strip. The bottom has places to put both the multiplexer and the Arduino in place. Both panels are held together with 25mm hex stand offs, one on each corner and one in the midlle of the buton array to have some more support there.

There is also a side panel with another button.This one allows you to change “banks” in software. All the connections are made with point-to-point wiring and I deliberately left the sides open so you can see the “guts”…I thought that it might look better that way.

I modeled everything in CAD and found all the needed components in Grabcad. This was the end result:

There is some weird artifact in the gif…

After that It was several hours of printing and a lot more of soldering

And finally a little video I made of the assembly process

Reverse engineering a linear CCD board

One of my long overdue projects is to reuse a couple of linear CCD sensors from old flat bed scanners. This post is just the process of reverse engineer one of the pcb boards.

The CCD sensors doesn’t have any kind of markins on top, which is kind of obvious…you don’t wont to cover the sensor. I wasn’t very familiar with this kind of devices and with a quick googling around I found out that this kind of chips have the name underneath the package (oh, duhhh…) but I wasn’t comfortable desoldering the sensor, I was afraid I could damage it through the process.

I kept on looking for CCD images until I found one that looked like the one I have. It was an ILX524KA and the photo was from an ebay listing.

Google image search of CCD sensors with one quite similar to the one I have (red arrow).

The sensor is a Sony “reduction type CCD linear sensor developed for color image scanner”. I looked up for the datasheet and compared the pinout (mainly Vdd, GND and No Connection pins) with the board I have but unfortunately it was different. But with all that searching I found out that Sony has several of this ILXxxx CCDs so I went through a few of this devices datasheets.

Some of the candidates

The ILX518 and ILX718 have a different package. The ILX724 has the same pinout as the ILX524, so this wasn’t either. Finally I found one which seems to be the one I have, the ILX548K; a reduction type CCD linear sensor developed for color image scanner, capable of reading A4-size documents at a density of 600DPI and with 16020 pixels (5340 pixels for each color row).

The datasheet has an application circuit with the CCD sensor, three transistors, a 74AC04 (six NOT gates) and a bunch of passives components. The board I have has the transistors (PMSS3904) and the passives components used for signal conditioning the analog RGB outputs but it has a 74HC86 (four X-ORs) instead of the inverters. To see how the circuit was implemented and to find out how to hook up a microcontroller to the PCB connector I decided to try to reverse engineer the PCB. It isn’t a very complicated board but it was the first time I tried to do this so it was a nice little exercise.

I took photos of the board and used GIMP to align both sides of the PCB, after some spinning, mirroring, resizing and making transparent one of the sides. Pretty much the entire circuit was traced out only by visual inspection (as I said, it is not a very complicated PCB) and a few connection needed the use of a multimeter.

The final circuit looks something like this;

It doesn’t have some of the power stuff and the infrared sensor section.

I still have the controller PCB. I powered both boards and hooked up my oscilloscope to see If I could find any signal. Luckily the controller board was working and it showed activity even though the board itself wasn’t connected to a PC (It used a parallel port).

There were a lot of interesting signals but I only have a 2 channel osciloscope, so I used one channel as a reference (ROG) and with the other channel I probed the rest of the signals. I then stitched the images together and got something that resemble the graphs in the datasheet.

It seems that RS and CLP are inverted. The circuit in the datasheet uses inverters to drive the pins so I thought I probed the signal before the NOT-gate. The thing is my board doesn’t use inverters it uses an XOR gate but I don’t see how this could be doing the level inversion.

Some basic theory

I had to do some research in order to understand the signals and the pins functions (the datasheet wasn’t extremely helpful). I won’t pretend to understand all the ins and outs of CCD technology, this is just a basic sumary assembled from varios sources.[c1] [c2] [c3]

In the photo-sensitive area of each pixel, light is converted into electrons that are collected in a semiconductor “bucket.” The signal must move out of the photosensitive area of the chip, and eventually off the chip itself.

In a one-dimensional type CCD the charge is collected in an adjacent storage gate. The signal charge is then transferred to the horizontal shift register simultaneously for all pixels.  To move the charges the ΦROG signals are used.

Read out gate signal

In a 2-phase CCD, the signal charge (the “buckets”) is transferred by applying two clock pulses with different voltage levels (high and low level). Φ1 and  Φ2 serves for this purpose.

Charge transfer

The accumulated charge must be output as a voltage signal. The result of charge-to-voltage conversion is a very weak voltage that must be made strong before it can be handed off to the sensor. The most popular method for detecting the signal charge of a CCD is the Floating Diffusion Amplifier. It consist of two MOSFETs, one for reset and the other one for charge-to-voltage conversion. The charge transferred to the detection node is converted into a voltage by the amplifier MOSFET via the relation Q=CV.  To prepare for the next signal charge (againg, the next “bucket”), the floating diffusion is first drained of the previous charge using the reset MOSFET. This reset or zero signal level is converted to a voltage and immediately seen off chip which is processed as a reference level. The charge is then shifted from the last phase within the CCD and dumped onto the floating diffusion. The resulting change in potential is converted into a voltage and sensed off chip. The difference between the reference or reset level and the potential shift of the floating diffusion level determines the signal.  The ΦRS signal is used to reset the charge.

Reset transitor

Even after reset, some charge always remains in the floating diffusion storage region. This remaining charge represents noise and is eliminated using a method called CDS (Correlated Double Sampling).  The output is clamped to a known voltage, some of the references talk about clamping it to ground, SONY talks about a DC level. The ΦCLP pin serves this purpose.

Signal chain with clamp switch

In this particular CCD sensor the clamping part is internal but the sample-and-hold section is done externally. The main board uses a Wolfong WM8143-10 CCD signal processor,  integrates the analogue signal conditioning required by CCD sensors with a 10-bit ADC. It has the circuitry for sampling the signal and It even includes a section to implement Correlated Double Sampling with a clamp switch. This is probably for CCD sensors that don’t implement the clamping internally.

The next step It’s to hook up the CCD board to a microcontroller, replicate the driving signals and see what I get.



3d printing a Touch-proof connector

I’m currently working at the Electronics and 3D Prototyping Laboratory at the Facultad de Ingeniería, Universidad Nacional de Entre Ríos.  We are working on a biopotential amplifier based on a ADS1299.  The amplifier uses 1.5mm touch proof connectors like this one. Unfortunately Plastics1 is the only manufacturer (and seller) of these particular connectors. The purchase have not been done yet, and it will take a while to have them in the lab. That was a problem as we needed to make some tests ASAP. We have a couple of 3d printers so we decided to make the connectors ourselves with the stuff we have in the Lab.

I had already made the connectors’ 3D model in Solidworks in order to generate the step an wrl files for KiCad.


I modified the housing to fit standard 2.54mm pin headers. The main fear we had was that the printed plastic wouldn’t tolerate the heat while being soldered to the PCB. For that reason we didn’t use just the metal pins but also the plastic part of them. That material is designed to withstand the heat while being solder and was used to minimize direct metal-to-housing contact. The pins at the front of the connector were soldered first to the PCB and then the housing was press fit into them.


We printed the connector in a Objet Eden 260 from Stratasys. The material used is VeroWhite.


We found out about a connector with pins in a similar size to the one we needed. Circular Plastic Connectors (CPC) use 1.58mm pins, close enough.  We had a couple in the lab from another project but we needed more. Luckily my cousin (who is studying there as well) is working in a similar project for his thesis and bought a bunch of these pins to be used in a similar way. The pins were disassembled as seen in the picture and only the front part was used.


A single 17 mm long pin header was slided inside the contact and soldered in place. The pin was then bended…


.. and gluded in the printed housing.


As I said before, the pins in the front were soldered first:

cam00571the connector was press fit into them and the central contact soldered.


We made several connectors, they are not pretty but they work great.




Programando dispositivos HC08

Hace unos años (varios, unos 6….) conseguí por medio del programa de Muestras Gratis de Freescale unos micros de la linea HC08. Comencé a investigar de que forma programarlos, que interfaz de programación construir, que software utilizar, etc. En el proceso cambíé la PC de esctitorio con XP por una notebook con Windows 7. Esto trajo varios probemas: en primer lugar, leí en su momento que no iba a haber soporte del CodeWarrior (el IDE de desarollo de Freescale) sobre Windows 7, lo podía solucionar con una maquina virtual que corra XP, pero me parecía medio engorroso.

Otro problema era la falta de un puerto serie en mi notebook. Tenía intenciones de utilizar la interfaz MON08 para la programación de los micros. Es una interfaz sencilla que requiere pocos componentes. Leí en su momento comentarios contradictorios acerca del uso de conversores Serie-USB.

Así que los micros estuvieron juntando tierra todos estos años. Entre tanto Freescale (ahora NXP, si han habido algunos cambios…) dió de baja la linea HC08.

Hace unas semanas me encontré de casualidad (no recuerdo que estaba buscando) con este post que explica como instalar CodeWarrior 6,3 en Windows 7 x64 bits. Seguí los pasos y en un rato estuvo andando sin problemas.

Comencé luego a buscar información relacionada al uso de conversores USB y encontré un par de post interesantes. Uno donde muestra una placa de desarrollo para micros HC08 y utiliza un FT232RL. Y otro donde se muestra un programador para micros HC08, de la familia JL y JK, y utiliza un conversor MCP2200. Este último usaba como software de desarrollo WinIDE.

También encontré este video en el que utilizan un conversor PL2303 para la programación de un micro HC08, expecíficamente un QY4. En este caso se usa CodeWarrior 6.3 en una máquina virtual y por algún motivo menciona que el puerto virtual creado debe ser el COM1.

Otro problema era la dificultad de conseguir donde vivo un cristal de 9.8304MHz, aunque según este post sería posible utilizar cristales de frecuencias cercanas y más fácil de conseguir, como por ejemplo 10MHz.

Comencé con unas pruebas sencillas en una protoboard. Armé el circuito que se muestra en el esquemático, para los 9V necesarios para entrar en modo programación (Normal Monitor Mode) utilizo una fuente externa. El microcontrolador es un MC68HC908JL8 y el oscilador es de 10 MHz.


Acá se puede ver el circuito armado en una protoboard.

Programming HC08 devices

Las primeras pruebas las hice con un PL2303. El conversor tenía asignado el COM44 y el software de programación no lo reconocía. Luego lo cambié al COM1, elegí un baudrate de 9600 y como interfaz  la Clase 3.


luego de conectar con el microcontrolador, el software pide resetear el procesador:


y después pide apagar y encender el microcontrolador:


El apagado del micro es necesario para pasar el chequeo inicial de seguridad y acceder a la memoria flash del microcontrolador.  Un simple reset no es suficiente; para pasar la verificación de seguridad es necesario forzar al procesador a pasar por un POR (power-on reset)1.

Busqué algún firmware que me permitiera probar el funcionamiento del programador y dí con esta página. Tiene varios ejemplos para microcontroladores JL16 que son compatibles con el JL8, y utilicé el jl16-0.c que simplemente cambia el estado de uno de los pines. La descripción en la cabecera del archivo menciona un período de 4.5 microsegundos utilizando un cristal de  9.8304MHz, como utilicé uno de 10Mhz el período que obtuve es ligeramente menor:


Entre los archivos que había descargado hace unos años tenía el esquemático de un programador HC908GS de la empresa Firtec. Es un programador por puerto serie y agrega la circuitería necesaria para generar el POR mediante el software y así ahorrarse unos pasos durante la programación.  Este es el circuito que implementé en la pequeña protoboard roja:


El software utiliza la linea DTR para controlar la alimentación del microcontrolador y ahora la interfaz que se debe seleccionar en el software es la Clase 1:

Sin título

Cambié el conversor Serie-USB. Utilicé un FT232RL soldado en una placa adaptadora que me permite acceder al pin DTR.

Programming HC08 devices


  • Es posible instalar y utilizar CodeWarrior 6.3 en Windows 7 x64 siguiendo estos pasos.
  • Es posible programar dispositivos HC08 con conversores Serie-USB con CodeWarrior 6.3 en Windows 7 x64.
  • Es posible utilizar un cristal de 10MHz.




DIY ez-FET lite…ghetto style

I have a few MSP430G2955 around but non of my Launchpads are capable of programming this MCU. Texas Instruments released a while back all the informtation needed to build the new ez-FET lite. The eZ-FET lite is a low cost USB-based on-board emulation solution for MSP430 microcontrollers. This debuger supports all MSP430 devices compatible with SBW programming and I could use it to program the MSP430G2955.

The hardware is based on an MSP430F5528 and I used a QFN version with an adapter board:



it ain’t pretty…

In order to program the MSP430F5528, I tried first using the FET-Pro430 from Elpotronic. I was able to flash the BSL firmware:


despite an error dialog about code size:


…then, I programmed the ez-FET firmware:


After reseting the programmer all the drivers were installed:


But every time I tried to program a device with CCS I would get this error message:


ok, fail…let’s start over.

According to this post the error might be caused by the the custom BSL portion of the ezFET firmware being not properly flashed.  I did read this other post in 43oh about flashing the firmware with MSP430Flasher, I just wanted to see if the Elpotronic software would work.

I tried  to re-program the MSP430F5528 using MSP430Flasher but I get this “BSL memory segments are protected” error.


According to this post I have to add options to unlock  BSL memory as well as the INFO A memory. I added for that -b and -u:


Success!! At least the BSL.  Then I attemped a firmware update with MSP430Flasher:


More success!!! I should have tried this in first place…

Anyway, I tested the programmer with the old and beloved “blink” and It’s working. I still need to test the UART interface but this should work as well.


chiche nuevo…

Aprovechando el descuento del 50% que ofrecía Texas Instruments en la MSP430 FRAM Experimenter’s Board, me pedí una. Si eso le agregamos el envío gratuito resultaba una oferta muy atractiva como para dejarla pasar.

chiche nuevo...

Un poco de data de la placa;

  • Integrated MSP430FR5739 :
    • 16KB FRAM / 1KB SRAM
    • 16-Bit RISC Architecture up to 8-MHz
    • 2x Timer_A Blocks, 3x Timer_B Block
    • 1x USCI (UART/SPI/IrDA/I2C ) Blocks, 16Ch 10-Bit ADC12_B, 16Ch Comp_D, 32 I/Os
  • 3 axis accelerometer
  • NTC Thermister
  • 8 Display LED’s
  • Footprint for additional through-hole LDR sensor
  • 2 User input Switches

Un punto para destacar es sin duda el acelerometro, viene con un ADXL335 de Analog Devices, triaxial y salida analógica.

El fin de la placa es introducir los nuevos dispositivos de TI basados en memorias FRAM (Ferroelectric Random Access Memory) con velocidades de lectura y escritura superiores a los microcontroladores basados en tecnología Flash/EEPROM y un numero mayor de ciclos de escritura. Parece que es lo que se viene…