When I started with the Electrumpet it was immediately clear that I wanted it to be wireless. I could not imagine myself playing an instrument and not feel free in my movements. (actually the first student project which was not really an Electrumpet yet had wires and I felt restricted). There are still ideas to be developed that require wireless communication (like spatialization based on trumpet position) but also the practical issue of not having your trumpet gripped from your hands or the stand because somebody (probably me) stumbles over the wires. Since the beginning I have used a few different options.

I have to warn you that this chapter can be quite technical.

Arduino Bluetooth (Electrumpet version 1.0)

Although it was kind of briljant to make a cast for vacuüm forming a plastic holder for the arduino that I could clip on the trumpet it also looked very proto typic and it was a little bit vulnerable for breaking. It never did luckily but I always had to be very careful.

The Arduino bluetooth attached to the trumpet with some vacuum formed plastic and wires connecting the sensors

The most important reason to step away from this platform was the latency. Although I never measured it exactly it was notable when playing and more important it was not stable (I figure that a stable latency that is less then 10 ms is kind of a must). Connecting blue giga the manufacturer of the bluetooth module on the Arduino learned me that bluetooth 2.1 has an inherent latency of at least 10 ms but probably more. Newer versions of bluetooth might work better but I decided to go for another platform that was promising. One of the issues with wireless technologies and separate modules to send the data is that the package of data needs time to be formed (it needs a header, there is a checksum to be calculated etcetera). This task is mostly carried out by a separate controller that is part of the wireless module that also has to handle the serial communication with the microcontroller. I always found it hard to get the exact information on the latency involved in the transfer of a package. Roving technologies from which I was testing one of their WIFI modules admitted that while the throughput speed of data was quite high I would never be able to send packages with a rate higher then about 15 ms in between packages to keep my connection stable. Newer modules have faster processors as part of their architecture and the possibility to send data through SPI. I am researching new options for wireless connection.

XBEE direct:

Witnessing the presentation of a NIME article on wireless communication from IRCAM in Oslo 2011 (Flety 2011*) which was used in their MO handheld unit caused me to change to working with XBEE’s in API mode using the direct sensing possibility of the XBEE radio’s. Since I only used sensors with analogue outputs this was well feasible. With 3 XBEE pairs I had about 18 analogue sensor inputs that I could use. I used one of those to measure my digital switches (9 in total) by using them in a parallel series of switched resistors.

Picture with two of the three XBEE’s that are on the Electrumpet

the other side of the XBEE pairs was connected directly to the computer.

It was now that I discovered that the serial communication in MAX/MSP (the program that I use for audio processing) is not very stable. MAX own serial object again gave me unstable results. Luckily I discovered alternatives and I have used the Comport object ported from Pd by Jasch which was very stable in its latency and throughput. The problem with all serial communication though that strange things could happen when MAX would crash. The serial port was often occupied which resulted in the fact that I could not use my mousepad and keyboard anymore nor could I use my XBEE sensors anymore so I had to restart the computer when a crash occurred. This was especially bad when I had to work on a patch that was not yet stable. It was also very hard to trouble shoot.

I have worked with this setup for about two years though until I found the courage to change the setup again. One of the culprits in Serial communication is the FTDI chip that is needed on the hardware side (in my case the XBEE explorer board) for the serial communication. A driver in the computer manages the process of handeling the communication. Normally this driver will have a buffer that is flushed once in 16 ms. With the help of FTDIchip.com I managed to get this down to 2 ms but I knew I wanted to get rid of the serial communication.

Teensy 3.1:
I was already familiar with the teensy family through my contacts with UC Berkeley. They had good experiences with the teensy connected to their multitouch and multi pressure finger pads (eg David Wessels instrument) (Roh 2011**). The teensy does not use the FTDI chip for serial communication but sends the data directly through USB which can handle 12 Mbps and is also much better in handling the connection (it does not hold the ports when the program that uses the connection crashes). When the teensy 3.0 and 3.1 came out they came with three UART ports. On the computer side I decided to connect a teensy to the three XBEE receivers through those UARTs. I then used the direct USB speed.

Ethernet, OSC and UDP:
Encouraged by the stability improvement of using the teensy and USB speed I now contemplated the other improvement that was in the article of Roh which I also spoke about with Yotam Mann one of the co-authors of the Roh article. To send OSC messages over ethernet (UDP protocol) which he claimed was the fastest option. I added the Wiz820 ethernet module to my setup and used the Arduino OSC library to make OSC messages to MAX. This not only improved stability but it also reduced the processing power needed by the computer (MAX MSP) quite a bit.

Future:
Although I am happy with the current setup it cannot last. I would like to implement a few new sensors on the Electrumpet that communicate through I2C instead of a ‚normal’ analogue voltage that I can sample. In order to communicate these values I will need a microcontroller to gather the data and then sent it on through some form of wireless communication. At this moment I am still contemplating which platform to use. Any advises on the best option are welcome. More on my struggles with wireless communication in coming blog posts.

I will also add a schematic and some other pictures to this post.

*Fléty, Emmanuel, and Côme Maestracci. “Latency improvement in sensor wireless transmission using IEEE 802.15. 4.” Proceedings of the International Conference on New Interfaces for Musical Expression. 2011.

**Roh, J., et al. “Robust and reliable fabric, piezoresistive multitouch sensing surfaces for musical controllers.” New Interfaces for Musical Expression. 2011.