remote switching ideas

[chillhuman]

I have had a concept in my mind for quite a while now for a remote bypass system that allows for switching a large number of effects. The circuit on GEOFX for a remote triggered switch is a great start, but needing a line to trigger each effect is too limiting for me. For me, I think the answer is to use a pic micro-controller to read signals in a floor stomp switch enclosure, and send that data to remote units.

Right now I'm leaning toward using a pic that supports the I2C comms protocol, having a MSSP capable chip in the foot switching unit and I2C slave units in the actual switching enclosures. The reason I am thinking I2C is because :
    1 - It is 7 bit addressable, which means I will reasonably never run out of addressing space
    2 - It uses only 2 communication lines, so a 1/4 jack or XLR solution can be used as comms b/w foot board and FX unit. This will require external power for the floor unit, but I am fine with that.

While I don't pretend to be an electronics person, I do embedded vehicle control software for a living, so I'm pretty sure I can handle the programming end of things. Anyway, before I get moving too far along, I wanted to post my idea and get any feedback, including possibly "don't waste your time, it's already done!"

Thanks!

[R.G.]

Been there, got the T-shirt. There are preexisting examples.

My preference was to do a local foot controller and a remote foot receiver and connect them with a CAT5 ethernet cable, or a short-haul radio link. Both are available for reasonable prices today. Most of the remote-switching guitarists use a MIDI foot controller because they can understand them (kind of!) and they're available.

I have programmed both a PIC and an AVR on the foot controller to read and debounce the switches, then spit out commands to the remote switching unit. The remote unit receives the commands, then manipulates the switching setup.

The tricks are all in how you do that send/receive stuff. The line protocol needs to be robust and quick.  RS232 works, of course. MIDI is a variant of high speed RS232 at the physical link level, just modded to use a variant of the 4-20ma current loop and an optoisolator link.

There are some nice digital RF links for cheap if you trust RF. Maybe the best idea is to put both an ethernet cable socket and an RF link into the system so that if you get RF interferrence you can bag it and run the CAT5 patch cable. These come in 25 foot lengths at most computer stores, consumer electronics stores (i.e. Best Buy), and Walmarts in many cases.

The programming isn't too bad at all. I prefer to throw away speed and cruftiness to get clear programming by using either BASIC or C so the code is easy to maintain. It's unusual in something like this to need the speed of programming right down to the bare metal.

[chillhuman]

I had already thought about RS232. Maybe that will be my initial attempt to keep things simple. However, RS232 starts to get messy once you start getting into multi-drop scenarios, which is what an I2C network with a strong master node solves. 422 / 485 setup for multi drop is an option.....maybe I should do CAN bus(kidding of course). Do you have the code you did for the RS232 solution posted? I read everything on your site I could find about the remote switching, which is what inspired me to try taking on a project like this. Thanks for the quick response.

[Mark Hammer]

Whatever you do, I put in a plug for non-latched switching here.  There are some thngs you turn on and leave on until you want them off.  The amount of time required to engage in consecutive engage and bypass actions is not so short that it is disruptive to one's playing.

There are, however, some sorts of effects (and ring modulation is the poster child for this category) where you want them for individual phrases and nothing more.  In those instances, pressing to turn it on and pressing again to turn it off is distracting and disruptive.  More preferred would be a switching arrangement that permits one to enable the effect as long as a switch is depressed, and instantly revert back top normal when the switch is released.

Again, I am not advocating this as an attribute that must be universally available for every switch.  But dang it comes in handy sometimes, so leave yourself that option.

[defaced]

I have also done something like this.  It's still in the Rev 0 phase (real boards made/populated, but not rigorously field tested).  Basically it's two PICs configured to be able to send/receive RS232 signals.  The PIC in the amp (this is for channel switching) sends high logic signals to an 8 channel darlington driver IC (ULN2803) which powers the relays I have for channel switching.  The PIC in the foot switch toggles LEDs to indicate which channel is active.  Connectivity between the two PICs is an ethernet cable.  Two conductors are used for communication, two are used to supply +5v to the PIC/MAX232 board in the foot switch.  I used Mikroelektronika's BASIC compiler for programming.  Their suite has libraries for switch debounce and 232 communication in addition to a very active/helpful users forum.  For my first PIC project that I actually got working, it wasn't too bad. 

[chillhuman]

That's actually a bit more complicated that I was thinking. What I'm thinking is to use stomp switches in the foot board in a 4x4 matrix, so I can use 8 pins to poll the inputs and build a 16bit word for state that I can put out on the network. Then the long term goal is to put the FX into 2 or 3 rack units, where all the wiring from the circuit board to switches, pots, the relays, etc is done through those little hanging connectors. That way you can switch boards in and out no problem. Maybe use a spare output pin on the slave devices and some dip switches to handle addressing.

For 232 the comms schema is then extremely easy. The foot switches generate a 16bit word, the bus master pushes that out onto the bus. The slave devices receive the word, and based on their internally set addressing, mask off the bits meant for them and set the relays accordingly. I really had planned on just using DPDTs to handle LED's on the foot controller and indications back to the foot controller pic. Now that you mention it, I could easily put in momentary switches for the effects that warrant it. Even though there would be delay b/w the momentary switch making contact and the relay being set, I don't see it being more than 10ms at the worst.

One of my main goals with this is to end up with a very modular design. I think that if I do it right, the board with the pic on it should be the exact same layout for the foot controller as the FX switching unit.

[potul]

If I would attempt to do this, I'll go to MIDI. Why? Because this is the standard in musical devices communication, and would make your units compatible with other stuff already available. And at the end it is a RS232.
I'm currently halfway,.. so I have build a programmable MIDI foot controller. In the next weeks/months/years (depending on available time) I'll probably work on a MIDI switch unit that would allow to control multiple effect loops and/or amp channels.

If you decide to go MIDI and want to see some sample code just ask. My pedalboard uses a PIC 16F88 with an integrated USART, so programming the serial communication is a piece of cake.

Regards,

Potul

[defaced]

One of my main goals with this is to end up with a very modular design. I think that if I do it right, the board with the pic on it should be the exact same layout for the foot controller as the FX switching unit.

That's how I did mine.  PIC/Max232 on one board, relay driver/DIP switches on another, and relays on their own boards located close to the signals they're switching.  It takes several boards for the system to work, but it's very flexible. 

If you decide to go MIDI and want to see some sample code just ask. My pedalboard uses a PIC 16F88 with an integrated USART, so programming the serial communication is a piece of cake.

I would be interested in seeing a snippet.  I am using a PIC 16F882 for mine, and wouldn't mind playing with MIDI.  What are you using to drive the signal between the footswitch and the unit? 

Here are what my routines look like.  The first is the channel selection, basically it just toggles output pins high/low based on the momentary logic low input or the RS232 communication signal.  The second is the alternate action stuff (like a solo or FX loop switch) which also works off the low logic or RS232 input.

'CH1 Routine
    if (Button(PORTB, 7, 1, 1)) then
      ch1 = 1
    end if
    if (ch1 and Button(PORTB, 7, 1, 0)) then
      ch1_UART = 48
      UART1_Write(ch1_UART)
      PORTA.0 = 1
      PORTA.1 = 0
      PORTA.2 = 0
      PORTA.3 = 0
      ch1 = 0
    end if
    if (received_byte = 48) then
      PORTA.0 = 1
      PORTA.1 = 0
      PORTA.2 = 0
      PORTA.3 = 0
      received_byte = 0
    end if

'SOLO Reoutine
    if (Button(PORTB, 3, 1, 1)) then
      solo = 1
    end if
    if (solo and Button(PORTB, 3, 1, 0)) then
      solo_UART = 52
      UART1_Write(solo_UART)
      PORTA.4 = NOT(PORTA.4)
      solo = 0
    end if
    if (received_byte = 52) then
      PORTA.4 = NOT(PORTA.4)
      received_byte = 0
    end if

[chillhuman]

If you decide to go MIDI and want to see some sample code just ask. My pedalboard uses a PIC 16F88 with an integrated USART, so programming the serial communication is a piece of cake.

I would like to see your code so far if you don't mind. I ordered a couple 16f87's which I am waiting for now. They are basically the 88's but without a comparitor or something. I'm glad that you are using the chip you are. It helps validate my initial plan!

[potul]

I would be interested in seeing a snippet.  I am using a PIC 16F882 for mine, and wouldn't mind playing with MIDI.  What are you using to drive the signal between the footswitch and the unit? 

Sorry, I don't get the question regarding driving the signal between the footswitch and the unit... Here you have the schematic and the code, so you can see how everything is done. The code is a little messy and it is reaaaally long (it's in ASM), but you will see that most of the coding is devoted to manage the LCD display, menus, expression pedal management and so on. The MIDI portion is really small, and I think you can get the idea.

code:
http://sites.google.com/site/potulfx/marketing-docs/midifoot_v1.17.asm?attredirects=0&d=1
schematic:
http://sites.google.com/site/potulfx/engineering-docs/midifoot_schem_0.1.png?attredirects=0

As a comment, the MIDI IN is not really something you would like to copy as is, because I'm using no interrupt or anything similar. As the only usage I do in this unit of the MIDI IN is to program the unit (send new configurations from the PC) and reprogram the firmware, I don't really need to be monitoring the MIDI IN. By the way, this is one nice feature of the code I wrote, I developed a MIDI bootloader, so I'm able to reflash the unit via MIDI.

Regards,

Potul

PD: You can see the unit in usage in this video (sorry guys, the speech is in spanish)

http://www.youtube.com/watch?v=vQyG3YAUAqg

[defaced]

Sorry, I don't get the question regarding driving the signal between the footswitch and the unit...

RS232 is a bipolar signal, so you have to have something to covert the Tx/Rx signals from the 0/+V signal from the MCU into a bipolar signal - the Max232.  Since you were saying that MIDI is a RS232 signal, I assumed you had something to do this conversion.  If I'm reading the stuff on the web right, MIDI is a 0/+V signal and doesn't require this conversion. 

[potul]

Sorry, I don't get the question regarding driving the signal between the footswitch and the unit...

RS232 is a bipolar signal, so you have to have something to covert the Tx/Rx signals from the 0/+V signal from the MCU into a bipolar signal - the Max232.  Since you were saying that MIDI is a RS232 signal, I assumed you had something to do this conversion.  If I'm reading the stuff on the web right, MIDI is a 0/+V signal and doesn't require this conversion. 

Oh, you are right. MIDI implementation from a PIC is really simple, you just need a couple of resistors for midi out, and an optocoupler for midi in.

[PRR]

> RS232 is a bipolar signal

GOOD RS232 has large bipolar swings.

Most RS232 input just slice at +2V, and will "work" with 0V/5V inputs.

Until you run long cables in hostile environments.

MIDI is not RS232 at the physical level: it is LEDs on/off and wires to carry such signals. Probably routinely done with 5V swings. It's been decades since I fell asleep over MIDI protocol docs, I don't recall if there's any RS232 legacy in the timings.

> RS232 starts to get messy once you start getting into multi-drop scenarios

Technically you can't do that.

However you do not need bi-directional signaling, do you? So flags and collisions are non-issues. You send blips out on a wire, daisy-chained through multiple recipients. In strict RS232 each terminal is terminated in a few-K resistance, and the driver is optimized for that load. But for low rates and short runs, you can build a beefier driver and hi-Z receivers, like classic "thin-net" EtherNet did (and without Bob's collision detection). To push MHz you want to terminate the end of the line; at KHz you can probably let the line impedance be 1K-10K (sum of several 50K inputs).

I skimmed the thread quickly. How are you going to break ground? You do not want low-level audio sharing ground with some bleeping digital signal system. You often do NOT want to tie all your audio grounds together some arbitrary way. That's the magic of MIDI: although the cables are cheap copper, the actual signal input is a flashing light, there is no ground interconnection. Alternatively you could run all control signals balanced/differential with no ground/common, but worst-case there may be several volts of common-mode.

[potul]

MIDI is basically a asynchronous 31250 bauds serial, 1 start bit, 8 data bits, one stop bit. hus, each data byte takes 10 serial bits, and is sent in 320 microseconds. The connection is a 1.5 mA current loop, and the receiver is opto-isolated, and requires less than 5mA to turn on. Logical 0 is current "on." Rise and fall times must be less than 2 microseconds.

(this is taken from some web page, not mine)

[chillhuman]

I had planned on using a max232 to drive the line. You get all sorts of goodies with it, including protection from static. I don't know if this will protect the actual audio circuits from whine or not. I actually never thought about it, but it sounds like I should. Programmer and pics get here on Friday! I'm going to try and have a schematic for PS and driver boards done this weekend. I'll post what I come up with.

Thanks!

[defaced]

However you do not need bi-directional signaling, do you?

I did.  The amp has to control the footswitch and vise/versa.  I hated that when I used my Mesa I had to either reach behind the amp (no footswitch) to change the channel, or solely use the footswitch.  With RS232, doing that with one cable was simple. 

I skimmed the thread quickly. How are you going to break ground? You do not want low-level audio sharing ground with some bleeping digital signal system. You often do NOT want to tie all your audio grounds together some arbitrary way.

Usually the switching element provides digital/audio ground isolation.  I used relays but optos would do the same thing.  I used relays in my circuit where relay coil ground is part of the switching/MCU ground scheme, audio grounds are separate and terminated locally to the signal as required.  Because the digital stuff it driven by its own SMPS, I let that circuit float.