MRe-1: A special version of the MP-1: A Midi Transmitter

A special version of the MP-1 was built to get MIDI data from the Vortex and send it wirelessly to a computer for further processing. I have decided to name it the Midi Remote Emitter 1 (MRe-1).

MRe-1 with a short Midi cable

In fact, the electronics is the same as the MP-1, but the Midi-Out port was not put in, and of course, a special version of the software was used.

The idea is to use an RFM12B radio attached to a Jeenode Arduino compatible board  from Jeelabs to send midi commands. The initial goal was to only send CC commands, but I decided to try and see if I could also send NoteOn and NoteOff commands.

Jeenode with Midi IN port

The software works. The hardware… not so much! The RFM12B is using 915Mhz as a base frequency for communications. This is a general band that is used by alarm systems, weather sensors, etc. The main use of this unregulated band is to send sensor data to a processing unit. In general, if a data packet doesn’t make it to the base, it’s OK. Of course, when using it for an alarm system, you either have to keep sending the signal until it is received or you have to use some error correction processing. So, my idea was to have the unit send most commands without worrying about delivery. This is perfect for repetitive  commands like Volume control or Pitch Bend. But there are situations when you want to be certain that a command is received. For example, Command CC65, Sustain, forces the receiving equipment to hold all notes currently on and any note sent in the future until the same command is received, this time with a value of zero. So, the way I chose to do this was to send an Acknowledgement request from the receiver and resend the command until completion.

The problem starts when a series of commands is sent in rapid succession. For example, it might be OK to miss a NoteOn command here and there (although it can really mess up a piece). But you want to make sure that a NoteOff command is received, because it becomes really upsetting when a random note gets stuck when playing. The traffic can get pretty awful when playing complex pieces and two-handed chords.

I chose to have a three-stage error correction routine:

  • First, send a command and request an Acknowledgement (Ack) and wait for a few milliseconds for an answer
  • If no Ack is received, put the command in a buffer so it can be resent later and keep processing incoming data
  • Every once in a while (but frequently), go through the buffer and resend any command in there. A command only gets erased from the buffer when an Ack has confirmed its reception

There are many parameters to think about here. First, how long can we wait for a command to be Acked before the next one has to be sent. Midi is working at 31250 bps. This is about 32 micro-seconds between each bit. So you’re getting roughly 3,125 bytes per second (serial transmission in 8-N-1 format). This is 1/3 of a millisecond. Since a midi command generally contains 1 to 3 bytes, throughput is, on average, less than 1500 commands per second. Now, thats a lot of notes to play! But remember, your Midi channels also transmits NoteOff, CC, PC, Pitch Bend, AfterTouch, etc. So yes, there are situations when there is too much traffic. Also, the RFM12B is set to transmit at ~49K bps. While it is faster than Midi, my data structure is sending 12 bytes for each incoming Midi command. So, I’m effectively quadrupling the data sent.

So, how long can the program wait for an Ack? I set the period at 5 ms. There is a buffer that can deal with incoming Midi messages and store a few, and I can accept a droped message here and there.

The Ack buffer is set at 16 commands in my program. This means that up to 16 commands can be waiting for a re-transmit at any time. I address the buffer in round-robin mode and remove any command that has been Acked. But to process the buffer takes time, especially if it fills up a bit. In the buffer process, I set the Ack delay to 50 ms. I really want these commands to get out of there.

The main problem is radio interference. As explained in these two posts, the RFM12B is sensitive to radio interference. So much so that it becomes impossible to use error correction and keep the data flow intact.

I have to abandon the RFM12B for now. I will test with XBee radio when I have time.


Leave a Reply

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