uC Latching Relay True Bypass - nearly!

[caldersm]

R.G.

Could you use a TLP222A Optical MOSFET...?  It contains back to back diodes, so the issue with it conducting is gone....I believe.  It also has an ON resistance of only 2 ohms.  I believe you could use that one to go to ground to mute the signal, but do you think it would work to bypass the relay in parallel..?

Also....do you separate the audio common from the attiny common...?  If you separate them in say a Looper enclosure....would you use isolated jacks or use the enclosure as a common...?  Just some questions I am pondering as I try to improve my 4 channel programmable looper.

And thanks for all your insight....you appear to be extremely competent in this subject area.

Steve

[tempus]

I would think that you could use the TLP222A, because although it contains the diodes, the only time the signal would ever see them is when the mute is on, when it wouldn't matter. I used a BS170 for a while, but realized that it was distorting the signal (after RG pointed it out) even when not in being used, because the signal was always presented to that diode. With the optical relay, you have the benefit of isolation, i.e., the signal is completely isolated from the relay when the relay is off.

As far as eliminating the popping, I'd like to point out that my BS170 mute didn't really improve my popping problems anyway. You can see in a previous post in this thread that I have a mute circuit similar to yours set up. It muted just fine, but for some reason didn't catch the pops. You may have to experiment with longer mute times to get rid of the pops altogether, which may interfere with the seamlessness of your patch changes.

Keep us posted; I'd love to hear if this works as a solution. I've been thinking about trying one of these SSRs myself.

[R.G.]

Could you use a TLP222A Optical MOSFET...?  It contains back to back diodes, so the issue with it conducting is gone....I believe.  It also has an ON resistance of only 2 ohms.  I believe you could use that one to go to ground to mute the signal, but do you think it would work to bypass the relay in parallel..?

If that's how the TLP222A is wired inside, I'd sure give it a try. That connection is how the body diode problem is solved in some MOSFET solid state relays. I'd sure like to see how this device works.

Also....do you separate the audio common from the attiny common...? 

Ideally, they'd be connected at one and only one point, perhaps even through a resistor. They need not to be completely floating, but not to have circulating currents from more than one connection.

If you separate them in say a Looper enclosure....would you use isolated jacks or use the enclosure as a common...? 

The enclosure ought to be a **shield**, not a common. I would isolate the jacks, then take one and only one wire to the enclosure from audio ground for lowest noise. You might get lucky with non-isolated jacks, or you might not.

And thanks for all your insight....you appear to be extremely competent in this subject area.

You're welcome to any help I can provide. I've fought grounding and noise for a long time.   

[tempus]

I've been thinking about ordering some of the TLP222A's the next time I place an order. There is one caveat to these - the turn on time is .8ms at an I_f of 5ma, moving up to about 70us at around 50 ma. I don't know how long a switch pop is or how long it takes to start after the switching action, but that seems a bit long to me. The switch pop may have come and gone before this thing even starts to turn on. I suppose that brings up another question - should you try to ramp up the voltage on a MOSFET like you would on a JFET? My understanding is that a MOSFET has more of a switching threshold than a JFET and doesn't really act like a variable resistor in the same way. As always, correct me if I'm wrong on that. Would you even have time to ramp up the voltage before the transient was over? These should work nicely for channel switching though.

Compare that spec to a H11F2M, which is 45us at 16ma.

Something else to think about...

[gritz]

I've been thinking about ordering some of the TLP222A's the next time I place an order. There is one caveat to these - the turn on time is .8ms at an I_f of 5ma, moving up to about 70us at around 50 ma. I don't know how long a switch pop is or how long it takes to start after the switching action, but that seems a bit long to me. The switch pop may have come and gone before this thing even starts to turn on. I suppose that brings up another question - should you try to ramp up the voltage on a MOSFET like you would on a JFET? My understanding is that a MOSFET has more of a switching threshold than a JFET and doesn't really act like a variable resistor in the same way. As always, correct me if I'm wrong on that. Would you even have time to ramp up the voltage before the transient was over? These should work nicely for channel switching though.

Compare that spec to a H11F2M, which is 45us at 16ma.

Something else to think about...

JFET switching (as seen in pedals) can more accurately be thought of as crossfading between the effected and dry signals, because the fets themselves are not simple on / off switches, but operate as (crude) variable resistors over a limited gate / body voltage. The switch driving circuitry might have a time constant (a slope) in the order of 10 - 50 milliseconds (although the actual fade time will depend on the Vgs(gutoff) of the fets themselves. In digital audio we also use crossfading to switch between signals to prevent pops and clicks. The reason for the click is the same for software as hardware - switching instantly between two different signals can cause a sudden step in the output, because it's likely that the two signals will be at very different levels at any time. The faster the "switch", the greater the high frequency content of the "step", so it's a real problem in software and we use crossfades of around 5 - 20 milliseconds (or a bit more if there's a lot of low frequency content). With mechanical switches (including relays) it's not quite so disastrous, possibly because mechanical switches tend to "bounce" for a millisecond or five (very roughly!) before reliably making contact.

With solid state (electronic) switching, a few milliseconds of fade twixt one and the other is a good thing imo.

[caldersm]

Ok....I got it working...!!  I have eliminated most all of the perceivable popping noises, when switching between effects.(Granted I only have two foot pedal effect, as I am not a music guy....just a hacked up EE type guy)  Also, I eliminated the noises when the LED's turned ON and OFF by having the Audio on a separate common, and by adding a 10uf Cap to the Load side of the +5V regulator.  Granted, I am not an Audiophile.....but I can't hear any tone difference with the TLP222A connected, but not turned on.

I went from my Attiny Output pin to a 100uf to ground with a series resistor to pin 1 of the TLP222A with pin 2 going to the power supply ground.  I then connected my output jack signal to pin 4, and the audio ground to pin 3.  Whenever I switch the relays, I run the MUTE code....Turning it ON then the Turning it OFF.  I found that a 5ms delay for ON and a 10ms delay for OFF is working great.

Snapshot of that part of the circuit from my 4 channel programmable looper.
http://imgur.com/eLQqwLz

Snapshot of the PCB board.
http://imgur.com/ef5aVZF

The code is pretty simple....turn it on before you doing anything....ie....turning on LED's or Relays.

Code Select Expand

if(time_delay >= 3 && time_delay <= 5 && Prg == 0) { //If switch is held >= 3secs and <= 5secs Then
     Prg = 1;  //Set Program Mode Bit to execute Program Mode Code when Switch is Released.
 Mute_ON(); //<<-------------MUTE
 PORTB &= 0b00001111; //Turn off
 Mute_OFF();  //<<-------------UNMUTE
   }

Code Select Expand

void Mute_ON() {
 bitSet(PORTA,1);
 delay(5);
}

void Mute_OFF() {
 delay(10);
 bitClear(PORTA,1);
}

[SmudgerD]

I blogged about this issue and posted a schematic and code for ATtiny13A and TLP222G.

http://stompville.co.uk/?p=423

[R.G.]

It's worth noting that the problems with capacitively-induced clicks are largely a result of the high impedance of the signal line.

You don't have to mute the signal line - just making it low impedance for a few milliseconds to eat the transient will also make it clickless and won't subject the audio to such rough treatment. The treble fades out for an undetectible fraction of a second.

Ideally... 

[caldersm]

Great write up Smudger...!!  I actually saw the opto on Pedalsync's Relay Bypass circuit, but your blog has much more meaningful information.

I didn't even think about the Coff when I bought the A version.....I was just looking at the On State resistance.

I was considering using using the analog PWM on the pin, instead of the cap, but the cap seems to work really well, so I didnt pursue it.  Did you actually try doing an Analogwrite out of the pin...?  If so, could you hear the PWM signal...?

R.G.....so you are saying that adding series resistance between the audio common and the output through the switch would work as well.....or is the 2 ohm On state resistance the same thing...?

Again...thanks for the info....and the write up.




Steve

[R.G.]

R.G.....so you are saying that adding series resistance between the audio common and the output through the switch would work as well.....or is the 2 ohm On state resistance the same thing...?

There is a fixed amount of energy to be transferred from the relay coil contacts through the leakage capacitors to the signal path. The leakage capacitors are in the few-pF range. We want that to transfer inefficiently to the signal path. The signal path is often held at 1M ohm or about, so the 5pf (just guessing) and 1M lowpass is 32 kHz. If we lower the impedance to 10K, the crossover point is 3.2MHz, so the energy is vastly attenuated in the audio range - the click signal does not couple well.

Two ohms might be better, but 10K may be enough.

[SmudgerD]

Great write up Smudger...!!  I actually saw the opto on Pedalsync's Relay Bypass circuit, but your blog has much more meaningful information.

I didn't even think about the Coff when I bought the A version.....I was just looking at the On State resistance.

I was considering using using the analog PWM on the pin, instead of the cap, but the cap seems to work really well, so I didnt pursue it.  Did you actually try doing an Analogwrite out of the pin...?  If so, could you hear the PWM signal...?

R.G.....so you are saying that adding series resistance between the audio common and the output through the switch would work as well.....or is the 2 ohm On state resistance the same thing...?

Again...thanks for the info....and the write up.




Steve

Hey Steve, thanks for the kind words. Regarding PWM control of the LED current, the datasheet for the TLP222G allows for 300us turn-on time and 100us turn-off time, giving a theoretical minimum pulse width of 400us and therefore a maximum switching frequency of 2.5kHz. I did try it and the sample I was experimenting with was faster than the datasheet. I managed to get about 4.5kHz switching frequency.

To be honest, I didn't do any experimenting with audio at all. Personally, I don't have a problem with clicks on any of my pedal designs and I only investigated the optofet mute option out of interest. I'm sure that a 5kHz tone would be audible, since it couples directly to the audio. However, it would only be two bursts of 20ms or so.

Also, I don't think it is particularly desirable to have soft mute - after all, the relay itself (or stomp switch if you're doing it the old-fashioned way) doesn't have soft mute.

SmudgerD

[R.G.]

To be honest, I didn't do any experimenting with audio at all.

That would be an important test to try.

Also, I don't think it is particularly desirable to have soft mute - after all, the relay itself (or stomp switch if you're doing it the old-fashioned way) doesn't have soft mute.

A lot depends on the specifics of the relay or stomp switch. Stop switches are sometimes audible. Relays have an additional problem in that there is a 5V to 9V fast waveform running the coil only a few mm or less away from the signal-carrying contacts. Whether this is coupled over or not depends on the relay's construction and the circuit layout.

It is only particularly desirable to have soft mute if your relay or layout give you clicks. And then it becomes more desirable.

I've never had a house fire, but I do have both fire insurance and fire extinguishers. Probably just wasted money, since my house has never had a problem.

[SmudgerD]

To be honest, I didn't do any experimenting with audio at all.

That would be an important test to try.

Also, I don't think it is particularly desirable to have soft mute - after all, the relay itself (or stomp switch if you're doing it the old-fashioned way) doesn't have soft mute.

A lot depends on the specifics of the relay or stomp switch. Stop switches are sometimes audible. Relays have an additional problem in that there is a 5V to 9V fast waveform running the coil only a few mm or less away from the signal-carrying contacts. Whether this is coupled over or not depends on the relay's construction and the circuit layout.

It is only particularly desirable to have soft mute if your relay or layout give you clicks. And then it becomes more desirable.

I've never had a house fire, but I do have both fire insurance and fire extinguishers. Probably just wasted money, since my house has never had a problem.

LOL. OK, I'm not sure if you're pulling my chain a little. As I said, I don't have a problem with audible clicks because I design those problems out. It seems that some people do have a problem with clicks because their effects designs have high impedance signal paths and/or no discharge resistors - or they really want to keep authentic designs from way back when. I decided I wasn't going to create a 'bad' design just to prove I can cure it using a mute function - which is why I didn't test with audio.

I published my findings (including schematic and object code for an ATTiny13A) so people who have been pestering me to do so can build the design and let us know if it works. As I said in my blog, I left a 20ms delay between calling for mute and switching the relay so people can experiment with the soft-mute function if they want to.

SmudgerD

[Beo]

I decided I wasn't going to create a 'bad' design just to prove I can cure it using a mute function - which is why I didn't test with audio.

Seems to me that most people will read your article with an interest towards applying it to audio. It wasn't clear to me in reading your article that you hadn't tested a switching audio signal. Probably my own presumption, since it was linked from a stompbox forum.

One thing I find curious is that most uC relay solutions I've seen out there do not have DC blocking/biasing on the relay channels. It's definitely quite a few more components to add. From my own recent testing of a uC relay solution (using H11F1 for mute), I'm getting very quite switching without adding DC blocking/biasing.

[SmudgerD]

Seems to me that most people will read your article with an interest towards applying it to audio. It wasn't clear to me in reading your article that you hadn't tested a switching audio signal. Probably my own presumption, since it was linked from a stompbox forum.

Others assert that optofets will effectively mute the signal (or get rid of the clicks, anyhow). For my part (as I have said) I have no need to test with audio because I don't have a problem with clicks and I can see from the test circuit whether or not (and when and how) the optofet is switching on and off.

The point of the exercise was to publish revised firmware for my true bypass relay circuit as requested of me by a number of people who want to experiment for themselves but are not in a position to write the code. I could have just added a mute signal with 20ms delay before switching the relay and not bothered to investigate at all, but I decided the pursuit of soft muting was worth a couple of hours tinkering.

If I had offered a PCB design, I would absolutely have tested it with audio before offering it to the world.

HTH
SmudgerD

[remmy]

I have come back to this after initially not having much luck getting no pop and there is still a pop, but I have narrowed it down.

I am using the below schematic and I have worked out that the pop is coming from when the mute is disabled after being active to mute any pops from the relay, I changed the C6 gradually up to a 220uF and the click slowly turned into thuds which are still noticeable.  Ideally I want to get that sorted and then get the mute down to as short as possible with the code.

I have a couple of questions, firstly why is there a pop when the mute disables and secondly is there a way to sort it?

[R.G.]

I have a couple of questions, firstly why is there a pop when the mute disables

Good question. Is the pop worse with or without the mute?

Clearly there is some path for the control signal to get into the audio path. One of those is through the MOSFET itself. I would first simply open the line from the controller and see if the pop is still there, or different.

and secondly is there a way to sort it?

Maybe. I would attack the edge rate on the control signal. With no resistance between the logic signal and C6, you're asking the controller output pin to go into current limiting while it tries to force the voltage on C6 to change instantly. I would either delete R4 or change it to maybe 1M or more, and then stick a 10K?47K?100K? in series from pin 3 to C6 and see what happens then.

[Transmogrifox]

Funny to see this post since I have just recently started thinking about this again.  I think it was somewhere in ... 2006 ... with a PIC12F683...where I last left off
http://www.diystompboxes.com/smfforum/index.php?topic=43400.0
Unfortunately my Geocities page died a long time ago, so the schematic is gone.  The computer with that schematic died so I still have to copy the page backup from the hard drive.  I never posted the assembly code that I developed from that original project, and have long lost it in the shuffle of deleting Windows forever.

I agree that the mute function should not be necessary.  If a plain DPDT mechanical switch works, then a latching relay should be the same if transient currents are properly handled and designed to stay out of the main audio circuitry.  As an aside, I wonder if the uC output pin could be used successfully for the mute function -- tri-state high-z mode for through-signal, logic-0 to mute, and AC coupled to the signal path.  Probably all depends if port protection diodes get driven too far...

Recently I wrote some code and tested it on a TI MSP430 (MSP430F2013, specifically).  The current design drives a resistor with the worst-case for the NEC 3.3V single coil latching relay.
The MSP430F2013 can supply the current needed to switch the relay as a package, but not for a single set of pins.  This design connects pins in parallel to get the current drive needed.
The main selling point is the switch debouncing and deglitching algorithm here.  It functions as a linear integrator for edge detection, then applies a timeout after a confident "on" state detection so that the caffeine-induced double-tap doesn't fool it.  It's still short enough that you can tap on/off pretty fast /on purpose/...it just aims to be immune to accidental double-taps or really bad or dirty momentary switches.

Here is yet-another-way-to-do-this.  In code below,
LATCH_DELAY
Is the only constant one may want to play with since this relates to how much time is actually needed to latch the relay.  It is more healthy than it needs to be in the current code, so chance of pops is greater.

Code Select Expand

//
//  Switch Debouncing and toggle latching relay state with LED indication
//

//
// Schematic
//                      MSP430F2013           N/C MOMENTARY
//                    -------------           SWITCH
//         <+3.6V>-++| 1         8 |++-<GND>---\___\-----<SW>
//      -----------++| 2         9 |++                 |
//      |  <RL_N>--++| 3        10 |++                 ----/\/\/\---<+3.6V>
//      |    <SW>--++| 4        11 |++                       10k   |
// R  C |----------++| 5        12 |++                             |
// E  O =  <RL_N>--++| 6        13 |++     <RL_N>----/\/\/\---|<;---
// L  I =          ++| 7        14 |++                470     LED
// A  L =             -------------
// Y    =
//      |
//      ---<RL_N>
//
//  Relay contacts not shown.  Nominal is a DPDT relay and true bypass switching
//  circuit without LED indicator since this is powered by the MSP430
//

#include <msp430x20x3.h>

//Port Output Register 'P1OUT, P2OUT':
#define P1OUT_INIT      0                       // Init Output data of port1
#define P2OUT_INIT      0                       // Init Output data of port2

//Port Direction Register 'P1DIR, P2DIR':
#define P1DIR_INIT      0xfb                    // Init of Port1 Data-Direction Reg (Out=1 / Inp=0)
#define P2DIR_INIT      0xff                    // Init of Port2 Data-Direction Reg (Out=1 / Inp=0)

//Selection of Port or Module -Function on the Pins 'P1SEL, P2SEL'
#define P1SEL_INIT      0                       // P1-Modules:
#define P2SEL_INIT      0                       // P2-Modules:

//Interrupt capabilities of P1 and P2
#define P1IE_INIT       0                       // Interrupt Enable (0=dis 1=enabled)
#define P2IE_INIT       0                       // Interrupt Enable (0=dis 1=enabled)
#define P1IES_INIT      0                       // Interrupt Edge Select (0=pos 1=neg)
#define P2IES_INIT      0                       // Interrupt Edge Select (0=pos 1=neg)

#define WDTCTL_INIT     WDTPW|WDTHOLD

//  
//  Timing Constants
//      These constants were experimentally tuned using an oscilloscope to watch
//      delay from input edge to state change.  This comes to something
//      between 10 ms to 15 ms, also depending on amount of switch bounce
//

#define POLL_RATE   0x002F
#define THRS        0x001F
#define HOLD_OFF    0x4FC2
#define LATCH_DELAY 0x0400

// OUTPUT pin states
#define LATCH_OFF   0x0009
#define OFF_STATE   0x0000
#define LATCH_ON    0x0012
#define ON_STATE    0x001B

// INPUT Pin
#define INPUT_MASK  0x0004

//
//  Delay function.
//  Sets crude basis for system tick and input polling
//

void delay(unsigned int d) {
   int i;
   for (i = 0; i<d; i++) {
       nop();
       nop();
       nop();
       nop();
   }
}

//
//  Toggle output states
//
//  Timing sequence to turn off:
//  P1OUT xxx11x11    <-Initial state when enters toggle function
//  P1OUT xxx01x01
//  delay
//  P1OUT xxx00x00
//  
//  Timing to turn on:
//  P1OUT xxx00x00    <-Initial state when enters toggle function
//  P1OUT xxx10x10
//  delay
//  P1OUT xxx11x11
//
unsigned int toggle(unsigned int on)
{
   if(on != 0)
   {
       P1OUT = LATCH_OFF;
       delay(LATCH_DELAY);
       P1OUT = OFF_STATE;
       return 0;
   } else {
       P1OUT = LATCH_ON;
       delay(LATCH_DELAY);
       P1OUT = ON_STATE;
       return 1;
   }
}

unsigned int run_poll_sequence()
{

   static volatile unsigned int onstate = 0;
   static volatile unsigned int edge = 1;
   static volatile unsigned int trgcnt = 1;
   static volatile unsigned int in_state = 0;
   
   //Start polling
   in_state = P1IN;    //copy it over where it can be
   in_state &= INPUT_MASK;   //manipulated without touching P1IN
                   
   // Switch bounce filtering
   // Ramp up or down.  Response time will be
   // determined by POLL_RATE and THRS
   if(in_state != 0) {
       trgcnt += 1;
   }
   else {
       trgcnt --;
   }
   
   //  This is the edge detection
   //  When trgcnt ramps up above 1, edge will be set to 1
   //  When trgcnt exceeds THRS, switch state will toggle
   //  then edge is reset so it doesn't toggle the switch
   //  for every cycle the input is high.  When input returns
   //  low and ramps to <1, then edge is reset
   if(trgcnt < 1) {
       trgcnt = 1;
       edge = 1;
   }
   else if (trgcnt > THRS) {
       if(edge == 1)
           onstate = toggle(onstate);
       edge = 0;
       trgcnt = THRS;
       delay(HOLD_OFF);  //don't do anything for a good bit
                       //so the jiggly foot doesn't retrigger
                       //immediately after positive state change
   }

   return 1;
}

//
//  System Initialization
//

void bootup_init()
{
   //Watchdog
   WDTCTL = WDTCTL_INIT;               //Init watchdog timer
   
   //Set up clock
DCOCTL = 0;
BCSCTL1 = CALBC1_1MHZ;
BCSCTL2 = 0x01;
DCOCTL  = CALDCO_1MHZ;

   //Initialize I/O
   P1OUT  = P1OUT_INIT;                //Init dataput data of port1
   P2OUT  = P2OUT_INIT;                //Init dataput data of port2

   P1SEL  = P1SEL_INIT;                //Select port function on port1
   P2SEL  = P2SEL_INIT;                //Select port function on port2

   P1DIR  = P1DIR_INIT;                //Init port direction register of port1
   P2DIR  = P2DIR_INIT;                //Init port direction register of port2

   //Interrupts
   P1IES  = P1IES_INIT;                //init port interrupts
   P2IES  = P2IES_INIT;
   P1IE   = P1IE_INIT;
   P2IE   = P2IE_INIT;

   //Initialize relay to known state
   P1OUT = 0x001B;
   toggle(1);
}

//
//  Main polling function
//

int main(void) {
   bootup_init();
   while(run_poll_sequence()) { //always returns 1, so this is forever loop
       // Crude loop timing
       delay(POLL_RATE);
   }
   
   //just to keep gcc happy
   return 0;
}



The ASCII schematic shows nothing about the 3.6V power supply other than it is there.  I suggest a tightly located 0.1uF cap for decoupling high frequency noise on the uC itself, then a good several 220uF bulk caps to supply relay switching current.  All of this can be fed by a 5.6V zener divided down to 3.6V since the MSP430 takes microamps current for normal operation, so the LED is the main power hog for the system.  Probably something clever could be done the power supply when the LED is turned on.  The output state generally follows this pattern:
<____> OFF
[Depress Switch]
<__--> LATCH ON
<----> ON
[Depress Switch]
<--__> LATCH OFF
<____> OFF  //LED on, so wire polarity on Relay so bypass state is consistent with relay.

The key elements to reducing pop are pretty well covered in this post.  I thought I'd just use the occasion to share the code in case anybody decides to try this with an MSP430.  

Other than specific initialization and device-specific references (like P1OUT) this would work on pretty much any uC.  I figure for those who want to figure it out for themselves, they will do it anyway, so I may as well share the code for somebody who wants to just copy/paste and do it.

[remmy]

Thank you for the reply RG, any help on this is much appreciated.

I would first simply open the line from the controller and see if the pop is still there, or different.

The pop in this situation appears to be the same, it is high in frequency and quite abrupt when I raise the gain up.

I changed the R4 for 1M and it didn't seem to make a difference, I then added an inline resistor as suggested and the pop changed in the same way as when I upped C6 before, in that the higher the resistor the pop became more of a kick drum compared to the original snare, that's the best analogy I can think of 

I have taken delivery of a oscilloscope today (about time I learnt how to use one) so once I have worked out how to measure the mute pop I will see if the findings help in trying to resolve the issue.  I will post what I find.

[remmy]

I suggest a tightly located 0.1uF cap for decoupling high frequency noise on the uC itself, then a good several 220uF bulk caps to supply relay switching current.

Thank you for all the info, really helpful.

How are you connecting the 220uF caps?  Is it one on each of the two relay connections?