Since the Jeenode’s RFM12B is a bit slow (transceiving at 49.2K bps) and midi is a bit slower at 31250 bps, the processor doesn’t have much time to process all the traffic. Keep in mind that the Jeenode has to be able to receive MIDI messages on the serial port, receive incoming wireless transmissions through the RFM12B and do any necessary data manipulation at the same time. Since, in theory, a fully saturated MIDI line will need to be processed at 31250 bps speeds, the routines handling everything else have to be very efficient.
Again, this is theory. In practice, I haven’t been able to saturate the processor or the communication link.
But it WILL happen. There are many variables at play here and very little resource from the ATMega micro controller.
So, compromises have to be factored in. As far as I’m concerned, a dropped note here and there is not a major problem. Of course, dropping a NoteOff command means a stuck note. Anyone using MIDI knows what these can do to a performance (even when using wired communication!). So I have added a simple “panic!” button to the MP. It will send the panic! command to the receiving equipment: this way, if you suspect that the receiving equipment is acting bizarrely because it missed one or more MIDI message, you can reset it. It is implemented two ways: Either a separate button is installed on the case (preferably red!) or a rapid double press on the rotary encoder (for display equipped units) will send a MIDI CC121, which will effectively reset pretty much anything MIDI when processed by most equipment. I am also processing the panic! signal locally, but that could be parametrized.
The second method to increase reliability in the system is to use “acknowledged” (ACK) transmission. This is done by asking the receiving equipment to send back an ACK message as soon as it can, to confirm successful reception. This is initiated by the sending MP. One part of the message includes a request for ACK. if the message is received successfully, the receiving MP sends a message back. If the sending MP doesn’t receive the ACK in a timely manner, it will resend the original message, again with an ACK request. Eventually, an ACK message will be received by the sending MP.
I did not implement the ACK process to NoteOn and NoteOff MIDI messages. But all other messages will use it by default (except Pitch Bend and Control Changes driven by pedals, actuators or knobs, again because of the possibility of saturating the processor or the communication link).