January 12, 2022: Progress

Not many updates lately, but work hasn’t stopped entirely. There is still a very long way to go before the EnsembleBot can play, but we’ll get there, eventually.


The master controller is the bridge between the MIDI host (pc) and the EnsembleBot, and it’s main function is to relay MIDI/EBP messages from the USB serial bus to the EnsembleBot CAN bus. Previously, this function was served by the same microcontroller responsible for tubular bells, glockenspiel and miscelleaneaous percussion.

Master Controller Enclosure

To reduce the risk of buffer overflows because of too slow buffer handling (which actually did occur) the bus bridge tasks has now been moved to a dedicated master controller, that pretty much only buffers incoming serial messages and relays them onto the CAN bus.

Making a stand-alone master controller also helps keep the EnsembleBot more modular. Previously, nothing worked if the combined tubular bells/glockenspiel/percussion circuitry wasn’t present and switched on. Now, it’s possible to use only a single instrument (or instrument group) independently.

The master controller is based on a Teensy 3.2 (72 MHz). This is a bit oversized, but it’s better to err on the side of caution. This extra muscle makes the firmware coding easier, as it doesn’t have to be perfectly optimized. Also, to have some kind of practical feedback, the controller box has been fitted with 16 LEDs – one for each MIDI channel – that will light up shortly, when a MIDI/EBP message is sent to that particular channel.

The hardware is assembled and tested, but the firmware has yet to be written.

Linear Actuator

After many failed attempts, the PipeMare swell panels for both the accordion and the cabinet are now working. Originally, the swells would be controlled by silent, geared motors, combined with a number of micro-switches to check for extreme positions. Especially in the accordion it was very hard to make it work reliably because of space constraints.

To make a functioning swell panel, the geared motors were dropped for now in favour of much simpler linear actuators. These are 12V devices that extends or retracts a small arm in a slow and smooth motion, and they are able to exert quite a force. Another bonus is that there is no need for switches to check for extreme positions, as the actuator automatically shuts down, when it reaches the fully extended or retracted position. All that’s needed is 5 seconds of power, and the actuator takes care of the rest.

PipeMare swell doors

Unfortunately, these actuators are anything but silent. To be honest, they are quite noisy. This is a problem, since the swells were supposed to be part of the PipeMare instrument, changing the dynamics (volume) of the music through MIDI commands. However, as they are now, they would pretty much ruin any music playing when activated. So, unless there is some way to reduce the noise, they should be considered a temporary solution.

12V 45N solenoid

The percussion section really lacks a decent bass drum. Earlier attempts were underwhelming to say the least, so they had to be redesigned from scratch. After watching a youtube video of a MIDI-controlled drumbot, I contacted the creator, who gave me the inspiration for the next design.

First of all, the new bass drum will based on a large floor tom to give a more substantial sound. The previous two flimsy mallets are replaced by a single, heavy bass drum mallet. For activating the mallet with enough force, we use not one but two heavy duty solenoids in parallel.

Bass drum prototype

These two solenoids each pull 45 N (nominally) when actuated with 12V. In this application they will only be actuated very intermittently, e.g. 30 msec with much longer pauses in between, and the risk of overheating the solenoid coils is greatly reduced. So, to give the mallet extra force, the solenoids are driven at 15 V (i.e. a 25 % overvoltage) through a pair of power MOSFET drivers and a dedicated switching PSU block.

This, combined with a much more rigid and lossless mechanical mounting, gives the bass drum its much needed oomph. Now it’s just a matter of making the beater-system look good, and mounting it on the tom, along with the driver circuit and PSU block.


Right now, the primary concern is firmware programming. The master controller needs new code, and the previous multi-purpose controller must be re-programmed to only act as slave-controller for tubular bells, glockenspiel and percussion.

Then there’s still a lot of work on the PipeMare project. The two pipe organ stops must be voiced and tuned, and perhaps it’s even necessary to build a secondary pressure regulator, if the flutes can’t work with the high pressure for the harmonic piccolos. And the accordion also needs some work, especially building and programming a handheld unit for calibrating the many servos and storing the information on EEPROM built into the accordion control circuit.

May 11, 2021: General update

Being forced to work from home during the pandemic means that practically all physical work on EnsembleBot has been stalled for more than a year now. This is quite annoying, especially since I compensate by thinking up new projects and enhancements.

Dedicated master controller

Currently, an Arduino Mega serves as both interface to the host and master controller, while also serving as instrument controller for the tubular bells, glockenspiel and misc. percussion. As the number of instruments in EnsembleBot grows, we’ve begun experiencing some data congestion problems. This is partly because of bad programming (i.e. not enough focus on bus priority and input buffering), and partly because of the current master controller, that quickly becomes a data bottleneck.

For these reasons alone it’s obviously a good idea to implement some separation of functionality by building a dedicated master controller unit. This actually makes the overall architecture of the EnsembleBot simpler and more compliant with the master/slave principle.

EnsembleBot architecture overview
EnsembleBot architecture overview

The new Master Controller will interface to the host computer through USB, buffer incoming EBP messages and relay EBP messages to the CAN bus. The old master controller will be reprogrammed to serve as a CAN bus slave instrument controller only.

Physically, the Master Controller will be built as a small box containing a microcontroller and a CAN bus interface. Power will be supplied from the central EB-PSU (A-side power domain) – not from host USB.

Firmware reprogramming

To prevent any more data congestions, the instrument firmwares are going to be reprogrammed with a much more strict focus on input buffering. This is not a huge undertaking, but it still means changing code that hasn’t been touched in a very long time.

Air pressure evaluation

As feared, the optimal air pressures of the piccolos and the flutes respectively in the PipeMare cabinet are not quite compatible. I.e. the air pressure, that allows the piccolos to overblow (desired), makes the flutes also overblow (absolutely not desired). Unless we can find a delicate sweet-spot, where both pipe stops blow nicely, we will have to address this problem by building some kind of secondary pressure regulation.

PipeMare instrument calibration

The PipeMare project contains 3 instruments, and none of them has been calibrated yet. For the accordion we even need to build a dedicated microprocessor-controlled calibrator.

PipeDream61 valves

The valve controller boards in the PipeDream61 organ has electrical problems with two of the 64 valve drivers. This is probably just a trivial matter of bad connections or a bad MOSFET driver, but it’s quite difficult to access the boards without having to disconnect and reconnect all the pipe valve control wires.

Velocity-controlled percussion

The percussion instruments need to be sensitive to MIDI velocity values, i.e. able to play softer or louder depending on the music.


The main cabinet still needs to have a dual-mallet woodblock installed.

September 6, 2019: New pressure monitor

New PipeWind pressure sensor

As mentioned earlier, I decided to replace the STM32F103C BluePill microcontroller in the PipeWind pressure monitor/logger with a more problem-free and widely supported Teensy 3.2. This replacement exposed some problems with our chosen graphics TFT display, as it turned out be both extremely slow and unreliable. So, I replaced the display with a much faster and better ILI9341-based display.

Unfortunately, the breakout PCB of this display is larger than the old one, so I had to drop the nice, compact enclosure and use a much bulkier and uglier junction box. Damn.

Anyway, the pressure sensor worked right away, and even though I haven’t programmed the actual logger/analyzer function yet, the box shows the organ air pressure in mmH2O above ambient pressure. The rest is just basic programming.