MRe-2: XBee Midi emitter

In the previous post, I  explained that I temporarily abandoned trying to use the RFM12B radio transceiver to exchange Midi information between two devices.

This post explains how I successfully used the XBee radio transceiver to achieve sending information between a Midi source and a computer.

The XBee radio comes in many different versions. The one I use is the cheapest one, the Series 1. It’s available from Digikey, Robotshop and many, many other suppliers.

Before trying my own version of the bi-directional  Midi link, I read this detailed article from LadyAda . You should probably do the same and come back here.

Note: In the LadyAda article, there is a section that explains how to replace the FTDI driver required to program the XBee to work at 31250 bauds-per-seconds. If you use Windows 8, there is no need to do this. When you install the X-CTU program from the XBee maker’s site (Digi.com), Windows 8 will recognize the FTDI chip and allow you to change the baud rate (using the method described in the ladyada article). Then, all you have to do is change the X-CTU program’s baud rate by typing “31250” directly in the Baud field:

and the terminal tab window will let you access the XBee again. This means that it will be easy to change the XBee speed again.

Two AA batteries, an XBee radio and a Midi IN port (using a 6N138 optocoupler)

The circuit in the article cited above is for bi-directional communications, but my version is for uni-directional exchange. I am only interested in sending Midi messages from the instrument to a computer.

NO  processing is done in this circuit. The Midi signal comes in through the Midi cable, enters this circuit (minus the Midi OUT section)…

Thanks Limor!

From ladyada.net (Thanks Limor!)

… and that’s it! The internal XBee circuit takes care of transmission, error correction and synchronization.

The only reason I use an opto-coupler (6N138 in this case) is because I’m using 3 Volts to run the circuit and the Midi IN port, as per the Midi specifications, runs at 5 Volts. So the optco-coupler is used for voltage level matching, not ground loop prevention. The 6N138 can run on 3 Volts, so can the XBee. This means that the circuit can run on a couple of fresh 1.5 Volt batteries (as shown in the picture). Keep in mind that there is NO voltage protection here. Using 3 x 1.5 Volt batteries will fry the XBee (maybe…).

The circuits draws ~50 milli-Amps. Most of it is to power the XBee radio. The 6N138 needs less than 2 mA. So, a batterie pair should last about 50 hours (2500 mA/hour ÷ 50 mA = 50 hours). This is theoretical. The XBee will function down to about 2.8 volts, so the circuit will stop sending Midi messages before the batteries are completely depleted.

I tested the circuit with a single CR2032 batterie and it worked fine. That particular batterie will probably only work for a few hours, but makes for a very compact installation.

On the receiving side, I used another XBee connected to an Arduino and I used an Arduino, a Sparkfun Midi Breakout board,

and a very simple program:

/*
MR-2 V0.1
 2013-1-10 PracticaUsage.com

 Receive data on XBee radio using a Software Serial Port
 then send it all to the Hardware Serial Port
 */

#include

SoftwareSerial xbeeSerial(2,3); //RX,TX

void setup()
{
 Serial.begin(31250);
 xbeeSerial.begin(38400); //can be any speed. XBee receives
 // at whatever speed the other XBee is transmitting
 //Serial.print("MR-1 V01 xBee RCV"); //for debugging
}

void loop()
{
 if (xbeeSerial.available()) { //send on standard Serial
 //anything from xbeeSerial
 //Serial.print(" "); //for debugging
 //Serial.print(xbeeSerial.read()); //for debugging
 Serial.write(xbeeSerial.read());
 }
}

The Arduino will talk to another piece of midi equipment or, using a Midi-to-USB adapter, can be connected to your computer. The Arduino could also be connected directly to the computer through its own FTDI chip/USB Port and a Processing program could digest the data.

Conclusion

The XBee is well built and the error correction algorithm does the job. While testing the circuit above, I had NO stuck note. Every Midi message was received successfully, even when the equipment was using “Running Status” to save data transfer.

One drawback is the 50 mA current used by the circuit. In the next post, I will suggest a few alternatives to put the device to good use.

This entry was posted in Electronics, MP, Music equipment and tagged , , . Bookmark the permalink.

6 Responses to MRe-2: XBee Midi emitter

  1. Peter says:

    G’day Robert,
    I have a question relating to the midi input: Is it possible for the MRe1 to handle multiple midi inputs? The application I envisage is for pitch-to-midi signals, one per string, on a bass/guitar (in this case my 5-string bass) to be sent.

    So, I don’t think a simple midi-merge would suffice, as I’d like the (switch selectable?) option to send midi in mono (like a simple merge) or over separate midi channels. For multi-channel capability, the MRe1 (or some component) would need access to the distinct midi inputs to assign channel codes accordingly. Note that the pitch-to-midi devices I’m considering (Sonuus B2M/G2M) don’t seem to have the option of channel selection – they’ll default to CH1.

    Is this doable?

    • rt says:

      The Sonuus B2M/G2M output all notes to a single channel. So I guess your idea is to have many of them connected in series. But how are you going to tell it which string to monitor? I guess that you will have to modify your guitar pickup to have one signal per string out of it, and parallel process with multiple B2M modules.

      Of course, that could be done (approximately) on the midi signal itself using one B2M module and a micro-controller that re-assigns Midi notes to different channels, based on note ranges.

      The first solution requires Midi Merge in the MRe. That’s one of the sub-projects on the table…

      The second solution is simpler and can be done more efficiently in the MP unit, that has a more powerful micro-controller on board. It is also designed for Midi signal processing.

      Please give me more details on how you plan to get those “one per string” signals out of the Bass

      • Peter says:

        Splitting of the string audio signals could be done using a hex pickup, which sends six separate audio lines, one per string. I envisage one B2M or G2M per string, subsequently requiring midi merge with some pre-merge processing to assign correct midi channel to the respective strings midi commands (note on/off, velocity, etc).

        • rt says:

          Then the MRe can do it. There would be no problem doing the merge in the MRe and sending a unique Midi signal using a number of channels. Since the incoming data from the multiple B2Ms will not be close to Midi saturation, the micro-controller inside the MRe can do this without noticeable delay. I’m working on a version, the MRe-3 that does that since I need to modify my Alesis Vortex to add more controls and switches. The MRe-2 can’t do it as is, since it does not incorporate a micro-controller. The processing is instead relegated to the receiving end.

  2. Peter says:

    Nice to know it’s doable! Now to decide if it’s something I want to pursue … 😉

  3. Transmitindo de um Keyboard para keyboard explica ok possibilidade?

Leave a Reply

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