What do you do when you want to rock out on your keytar without the constraints of cables and wires? You make your own wireless keytar of course! In order to get the job done, [kr1st0f] built a logic translator circuit. This allows him to transmit MIDI signals directly from a MIDI keyboard to a remote system using XBEE.
[kr1st0f] started with a MIDI keyboard that had the old style MIDI interface with a 5 pin DIN connector. Many new keyboards only have a USB interface, and that would have complicated things. The main circuit uses an optoisolator and a logic converter to get the job done. The MIDI signals are converted from the standard 5V logic to 3.3V in order to work with the XBEE.
The XBEE itself also needed to be configured in order for this circuit to work properly. MIDI signals operate at a rate of 31,250 bits per second. The XBEE, on the other hand, works by default at 9,600 bps. [kr1st0f] first had to reconfigure the XBEE to run at the MIDI bit rate. He did this by connecting to the XBEE over a Serial interface and using a series of AT commands. He also had to configure proper ID numbers into the XBEE modules. When all is said and done, his new transmitter circuit can transmit the MIDI signals wirelessly to a receiver circuit which is hooked up to a computer.
What about delays? Aren’t they to big in a radio based system?
Radio and cable are about the same speed. If there is no complex protocol in the XBEE then there should be no noticeable delay.
But there IS complex protocol in Xbee. There is delay of a few tens of milliseconds from USART string transmitted on one side and the same string appearing on other side. The delays get worse if there are more Xbee modules on the same channel just listening, not transmitting and it gets absolutely messy if some of them try to transmit.
Once I made network with 80 Xbee modules and it was nightmare. Unpredictable data dropouts and large lags were quite common.
OK, I looked at the XBEE and thought – there’s a module I don’t have – so I don’t know much about it. It sounds like a *dumb* radio module may be much better.
I agree, an RF transmitter would be way better.
yes, the xbee has delay, AND dropped chars AND even corruption. I run xbees (a lot) but I find that in non-api mode (at least) I have to run a transport layer of my own (almost tcp-like) to keep the streams honest. and that really slows things down.
I notice he has series-2 and I only have series 1 radios, so maybe s2 is better. s1 really is not reliable on its own. I ended up adding a gps/nmea style layer (dollar sign, payload, star and 2 chars of cksum) just to ensure each packet is error-free. that works well enough but its annoying that I had to do that when xbee advertises itself as a reliable data stream. on its own, its just not.
MIDI sharks with lasers, to the rescue.
(now, just have to figure out how to modulate the shark without getting eaten)
yes and no. I tend to run my xbee network with all radios in transparent mode (non-api), all on the same PANid and all doing ‘poor mans multicast’ simply by being on the same pan channel. one tx’s and the rest all rx the same data. it does slow things dow a bit (there is no router or supervisor node, all are just peers) but not that much. for fast things like music notes that have to have lot latency, I would not do it. my application is about remote control and if I hit a volume-up key on a remote and it sends an xbee message to my preamp, other boxes on my network also see it but the volume control feel is just fine, even with (say) 5 xbees on the same pan id and all listening.
so, there is some delay with more stations like that, but its only a problem on very latency-sensitive traffic. and music note data is not something I would want to jitter around.
re: 80 xbees – wow -that sounds extreme ;) I keep my network to 5 or so nodes and things are usually fine. I can turn a rotary encoder, send a flurry of data and it still feels interactive. at 80, yeah, I bet it would be unacceptable.
The extra latency associated with wireless systems doesn’t come from signal propagation time – it comes from the extra processing that has to happen to noisy signals to recover the data from them. Getting acceptable robustness & error correction often involves increasing FFT window sizes which will raise latency. And god forbid something gets corrupted and needs to be retransmitted.
The “same speed” principal may have held up in the days of analogue transmission but digital is a different ballgame.
This is wrong.
MIDI over wireless is a 30 year old dream – and even 20-30ms extra latency is noticeable, especially on top of software synthesis and sample playback, which often also has noticeable delay.
I would expect this to at least use 115kbps and a custom protocol that attempts to keep the connection alive, so to speak.
Quick google search yielded this: https://www.midijet.com/index.php?option=com_opencart&Itemid=104&route=product/product&path=7&product_id=5
They claim 2.7ms.
Speed is sound at room temperature is something like 1.2ft/ms. The latency with these isnt the issue. The issue is when your roommate starts microwaving his burrito and microwaves use 2.5ghz as their freq with which to excite water molecules.DSS radios arent bad but theyre not industrial rock solid either.
The protocol stacks in most radio systems are rather lightweight, and are often dwarfed by the delays commonly found in USB host protocol stacks.
Just curious, what is the latency of the whole chain?
More then a few milliseconds of delay could be really disturbing for a band.
I am wary of lag. Here is what turns me on to this. I think XBEE has a range of a mile or two, even blocks would do. We have a theater with a restored theater pipe organ with midi IN interface! If I could play it and relay the audio with analog (LPFM) or web feedback (more prop delay), I could play it at many other places in downtown. Live sound, just not quite. Maybe only fast enough for ambient or solo playing? Still a blast hearing 110 dB of acoustic sound.
Someone years ago marketed a midi-thru-wireless mic setup. They must have used some treble boost to pull 31.5kB off back then. That would have been in the dial-up era. Maybe it wasn’t type certified?
series1 can just barely go from one end of the house to the other. you must be thinking of xbee pro, even then, its NOT a wan thing, as I understand it. a mile is definitely WAN and not LAN anymore.
Using XBee to send a sequence of bytes. Amazing.
This would actually work really well for DMX controllable lighting as the DMX and MIDI protocol are almost identical.
There is no perceivable delay in these unless one is out of range or here is radio interference happening. The delay would be the time it takes the three bytes to pass the recieve buffer at 31250k. From experience latency is percievable after 10ms, this would be no where near that. The radio frequency jamming does make this application a concern in live situations, I wouldn’t recommend it if loosing a packet or two is critical, especially since loosing a note off packet can stick a note on until you find the panic command (all notes off)
Considering that midi sometimes is too slow for (good) keytar players, the extra delay the xbee protocol and the signal buffering will, most likely introduce make this less than a proof of concept. One might just as well use MusicLab’s Midi-over-LAN.
Transmission rate for MIDI is 31250Baud, that,s 31kbits per second. One note command is 24 bits. 1/31250 = 0.000032 seconds x 24 bits = 0.000768 seconds. or 768microseconds, or .7 milieseconds. The propagation delay on the serial buffers and mesh network stack of the radios is going to add negligible time.
Your numbers are, at part, correct, your line of thoughts is not. While a single note on may be done in 3 bytes, a piece of music usually contains more than one note on.
Keytar players are using a lot of control messages (ribbon band, joystick, whatever), so there’s a constant flow of commands. I personally know a keytar player who has bought a non-midi-connection system for his performance rig to get out of the (very limited) 31kbps limitations (again: This is not just for single note on commands, but for stuff that he is actively playing on his keyboard – several notes at once, to trigger commands to the synth, fast arpeggio etc.).
Several notes at once would be negligable, MIDI would be serially buffered in a way that wouldn’t be an issue, I’ve also found that pitch bend/mod wheel CC changes while mashing four keys with one hand isn’t a problem. Essentially this radio is fine for playing leads on a keytar. But I wouldn’t claim xbees are bullet proof, you’d probably want to purchase an expensive Frequency Hopping Spread Spectrum type radio if you’re the Joe Satriani of keytars. This design is for people that aren’t afraid to have fun. Are You Afraid TO Make Money? AYATOMM.
Well, let’s leave it at: You have different experience on using MIDI for high data rates than I have. Ain’t it great that people can agree to disagree?
Noone’s claiming you aren’t allowed to have fun. Noone should be claiming that a hack is the answer to all problems a decades old protocol has inherited, either. You are entitled to use hackaday to promote your products. Now be a man (or a sheep, if you have the guts for that, because sheep are so much tougher than 3d-printing nerds) and accept critics.
:-)
Criticism is more than accepted, all the feedback is appreciated! Thank you to everyone who stopped by my website!
Wouldn’t EPS modules and something like https://en.wikipedia.org/wiki/RTP-MIDI offer a more general solution to wireless midi? May even be cheaper.
It would be cheaper. RTP-MIDI is new to me, thanks for the tip. I think I’ll give that a try.