Introducing the Chimaera DSP Unit

A project log for Space Whistle - wind controller - musical IoT

A highly responsive wind controller with expressive continuous push buttons based on linear hall-effect sensors - A musical IoT device -

ventosusventosus 08/04/2014 at 09:200 Comments

How do we get the analog signals from the respiratory pressure sensor and the 8 expressive buttons via the network to a software synthesizer? We need a MCU and PHY, right? We will use one of our designs we already have at hands from an other project: the 'Chimaera DSP Unit'.

Chimaera DSP Unit

It is a mixed-signal board. It uses a 32bit ARM Cortex M4 microcontroller from STMicroelectronics (STM32F303Cx) clocked at 72MHz. Of the available peripherals, we use the FPU, ADC1, ADC2, ADC3, SPI1, I2C2, DMA1, DMA2, USB, several TIMERS and a couple of GPIOs. The main circuitry runs at 3.3V, driven by a low-drop-out voltage regulator (LM1117).

To leverage the MCU, we use a hardwired UDP/TCP/IP/PHY chip from WIZnet (W5500) which takes care of all the low-level networking and is communicated to via SPI1.

There are two EEPROMS (24LC64, 24AA025E48) which store the MAC address, the configuration and the calibration data of the device.

The analog part of the board consists of 10 analog inputs which provide connection points to connect up to 10 (surprise!) analog sensory peripherals. Those analog inputs go directly to three in parallel running 12bit ADCs embedded on the MCU. In order to reduce noise, The ADC circuitry on the MCU is driven by a dedicated low-drop-out voltage regulator (MCP1703). The sensory units are connected to by 3 wires (Ain, GND, Vout).

Finally there are a RJ45 MagJack and a mini USB socket. USB is solely used to flash the MCU with new firmware. There are also two SPST buttons to reset the board and to get it into flash mode. The board's dimensions are 80x44 mm.

The KiCAD project is located at:

Here a link to the schematics:

Here the renders from OSH Park:

Here the equipped board:

STM32F303Cx and libmaple F3 port

The firmware is developed atop of LeafLabs libmaple.

We have ported 'libmaple' to the F3 line of STM32 chips already last year.

WIZnet W5500

People most probably have come across one of the hardwired UDP/TCP/IPv4 chips from WIZnet, as earlier versions (W5100, W5200) are found on most Ethernet shields for the Arduino and its clones. We use the newest version in the series: the W5500. Compared to its predecessor, the W5200, it gets much less hot and is more DIY friendly, as it comes in a 48-LQFP package instead of a 48-VQFN. It's an easy way to add networking to any MCU project.

The chip can be configured with up to 8 individual sockets. In our case the sockets are configured as follows:

0MACRAW/UDP68IPv4LL (Zeroconf), DHCP client
1UDP123Simple Network Time Protocol (SNTP)
2UDP319Precision Time Protocol (PTPv2 event port)
3UDP320Precision Time Protocol (PTPv2 general port)
4UDP/TCP3333Open Sound Control (OSC) event stream output
5UDP/TCP4444Open Sound Control (OSC) configuration in/out
6UDP/TCP5555Open Sound Control (OSC) debug output
7UDP5353mDNS and DNS-SD (Zeroconf)

Time synchronization

For an expressive play we need highly resolved data. The higher resolved the data, the higher will be jitter, too. OSC has the advantage, that messages can be timestamped. We use this feature to get rid of network jitter. But in order for timestamping to work, clocks of MCU and host must be synchronized in some way. For this we use the precision time protocol PTPv2 for which there are free implementations for Linux at least. For the other OSs, one can fall back to SNTP, or do without time synchronization altogether.


The IP can be configured 1) statically, 2) via IPv4LL or 3) via DHCP. Using the device is thus plug'n'play. A minimal implementation of the Zeroconf stack with IPv4LL, mDNS and DNS-SD makes device discovery by the host straight forward, too.


The device sends its highly resolved continuous event stream via Open Sound Control (OSC) on a dedicated port, either via UDP or TCP.

UDP can be a bit faster and may be used on a simple network topology where packets are not likely to be dropped, e.g. direct connection device-host. TCP is to be preferred when packets are likely to be lost (e.g. complex network topology, wireless bridges, www, ...).

The exact OSC serialization format for the event stream will be featured in an upcoming blog post.

Configuration  in/out and debug output also is (de)serialized to/from OSC via UDP/TCP on dedicated sockets.