Wireless midi for an independant robot

[mb944]

hi,

A good friend of mine is thinking about making an animatronic creature for fun and short films.

I suggested he used mios hardware for the animation, he could then control it with his laptop or even a midi keyboard

He is really excited about the project but could really do with jumping that extra leap and going wireless, thus enabling full 360 rotation and movement without getting itself cought in the midi cables.

Has anyone tried using some sort of Rf or IR interface for their midibox?

We obviously are into this for the fun of experimenting, so we can't really invest in a 800 euros KENTON WIRELESS MIDI SYSTEM.

Maybe using two cores sending raw data between PICS?

Any word of advice would  really be appreciated!

thanks in advance,

Alex

[Davo]

My initial impression of sending raw data between pics is "bad idea".  I don't know how long is the maximum allowable cable is, but when you're talking about wiring boards together, it isn't much.  Now for cobbling together a wireless MIDI system, that's probably even tougher.  I'll think about what would be required and post back on it in a week or so.  Perhaps an easier approach would be to use modified telephone handset swivels.  I haven't considered how much noise that would introduce to the signal, but it's somewhere to start.

[Steven_C]

Wireless midi has been brought up on this forum before. Do a forum search. You should find some ideas, but no-one else here seems to have ventured down that road yet. (though there is mention of an integrated RF tranceiver that the manufacturer claims can be adapted to midi) Kenton make a commercial solution, but is is REALLY expensive.

[mb944]

Hey!

thanks for your thoughts,

I'll continue looking around the net for ideas.

I have a small PIC PRACTICE book somewhere that explains how to send data via RF from one pic to another, thats why I was thinking in that approach.

Cheers,

Alex

[TK.]

Hi Alex,

the biggest problem with sending MIDI data via RF is, that MIDI doesn't provide some kind of flow control. There is a defined baudrate (31250 baud), this means that the transmitter needs to support the appr. bandwidth to avoid buffer overflows. At the receiver side it must be ensured that a bitstream is received error-free. Thats very difficult at this baudrate (impossible at large distances and a lot of EMC arround?)

There are three solutions: adding an ECC (error correction code) so that at least one bit errors can be repaired, and multiple bit errors are regognized (so that your robot software never executes invalid commands).

Second solution: a bidirectional connection between Transmitter/Receiver + a transfer protocol to realize flow control (e.g. receiver has to acknowledge the data with a checksum).

Third (and most simple) solution: try to get two premade bluetooth based COM interfaces (or bluetooth ASICs if they are available in small quanitties)  which connect together. If they don't provide MIDI baudrate, then you can just use the MIDIbox-to-COM option (which runs at the standard PC baudrate 38400)

Best Regards, Thorsten.

[nickw]

or you might want to try something like this (scroll to the bottom of the page)

[nickw]

of this page (whoops)

www.totalrobots.com/access_files/wcm.htm

[kris]

there used to be  texas instruments chips that did this one on the midi send one onthe midi recieve i cant rememberthe numbers of the chips though sorry dont know anything about the range eiether