Silent True Bypass Relay Switching, VFE Indiegogo Campaign for PIC MCU Code

[bluelagoon]

Yes, sorry bout that, fixed with the correct link.
As for the millennium bypass , not sure how that might work for this, will have a closer look at it later.
Nor would I know how to store an extra setting in an eeprom flash to sought this out,
And would definitely not be too interested in a supercapacitor, they sound like pretty large size caps, and not too interested in the secondary power source CR2032 battery.
What it basically needs, is either a reset pulse right at the point of power disconnect, or a reset pulse right at the point of power on, this is how the VFE MCU seems to achieve the syncing in right alignment.
Its likely just some code written in, either that or a way to achieve same with only a few extra small components, preferred.
Sometimes all it takes is just a reasonable size capacitor placed right to discharge and trigger the extra pulse needed to reset the relay at power on or power off.

[matt_garman]

If you only need basic on-off functionality, I'm increasingly confident in what I have here: mcu-relay-controller.

I've been using the same MCU code (tagged "v0.1" on the GitHub repo) for a while now without any issue on several of my daily-use pedals.  Here's a little writeup I did on the PedalPCB Forum: Custom microcontroller-based relay bypass.  I had a few people take me up on my offer to send them PCBs and pre-programmed MCUs, so hopefully we'll have some more reports from the field before too long.

I still have a few boards available (though am running low on MCUs), I'm happy to send out some more.  PM me if interested.

I have two boards currently, both are designed around the ATtiny13 or ATtiny85:

• v1.0 is the smallest/simplest board.  Uses either Takamisawa AL5WN-K or Panasonic TQ2-L-5V relays (5v, single-coil, latching).  The MCU directly powers the relay coil.  Per the ATtiny datasheet, it should be OK to drive the relay coil; see the details here.
  
• v2.0 decouples the relay coil power from the MCU.  It uses a Kemet EC2-3TNU relay (3v, double-coil, latching).

The MCU code is the same for both boards.

I just placed an order for a v3.0 board, which uses a fancy footprint that can accommodate either the EC2 or the TQ2-2L relay.  It also adds a "board power" wire hole (for use with AionFX boards), and some cosmetic improvements.  I'm designing this around the pic10f320, just so I can get some more actual under-the-foot testing time with a PIC MCU.

@bluelagoon - I know you're looking for a more feature-filled bypass, e.g. temporary on and a muting circuit.  I intend to add those features in the future, but I really want to have a longer validation period with the core functionality before I start tweaking.  (Now that I write that, I suppose I can create a git branch for alpha/prototype code with the added functionality.)  But if you can get by with simple on-off, you might enjoy my design.  Low power consumption was a design goal: latching relays use no power except when they change state, and the MCU goes into sleep mode (micro or maybe even nano amp current draw) when not switching.  And I have it set to always start up with the LED off and in bypass.

Edit: Check out this link: A Guide to Soft-Latch Relay Bypass by Silver Blues.  This kind person reached out to me to help test and validate my design.  He's a fellow relay bypass enthusiast.

[marcelomd]

Yes, sorry bout that, fixed with the correct link.
As for the millennium bypass , not sure how that might work for this, will have a closer look at it later.
Nor would I know how to store an extra setting in an eeprom flash to sought this out,
And would definitely not be too interested in a supercapacitor, they sound like pretty large size caps, and not too interested in the secondary power source CR2032 battery.
What it basically needs, is either a reset pulse right at the point of power disconnect, or a reset pulse right at the point of power on, this is how the VFE MCU seems to achieve the syncing in right alignment.
Its likely just some code written in, either that or a way to achieve same with only a few extra small components, preferred.
Sometimes all it takes is just a reasonable size capacitor placed right to discharge and trigger the extra pulse needed to reset the relay at power on or power off.

The millenium bypass can either be used to drive the LED directly or to signal the MCU via an input pin to drive the LED.

A capacitor, big enough to supply the current to the initial state is ok. Needs an extra pin to read the power supply status and some kind of interrupt or polling routine to detect the power loss. Maybe a supervisor IC can help here.

[bluelagoon]

Hi Matt, Thanks for your offer on the PCB and the MCU for beta testing, I may PM you later on that.
Just for now though I thought since you seem pretty adept with coding, a whole lot more so than myself, I were wondering if you could possibly just put in place the right coding added to or reconfigured in the CODA HEX file code, all it needs is same ability that you have placed within your own code, to start up with the LED off and in bypass, with the relay synced to the same.

Also with your own code, why don't you add the same type code for temporary mute function as incorporated withing the CODA code, this works well enough with the Coda when set up to  temporarily ground the signal output with a short pulse at every change on the relay, and allows sufficient anti click anti pop to the function.
Cheers, Trevor

[ElectricDruid]

I've also done some work towards this, which I'll publish once I'm done. I'm short by some relays for testing, and I want to try it out with a few different types before I open it up for everyone to see.

I've used one pin on the MCU as a configuration option, so the voltage on that pin lets you select whether the relay is latching or non-latching, how long the pulses are, and whether it starts up on or bypassed. You can also select toggling on/off or momentary on/off on the footswitch. I tried to cover as many of the common options as I could to make it really versatile.

I've also got a pile of schematics showing use cases with different relay types. That's the bit that I need more relays for so I can do some proper testing. It should be ok, but we'll see. Nothing ever goes totally smoothly.

[bluelagoon]

That sounds great Tom, Look forward to viewing your results, Cheers.

[mark2]

Nor would I know how to store an extra setting in an eeprom flash to sought this out,

If you decide to go that route, here's an example that stores the bypassed/engaged state in EEPROM: https://github.com/mstratman/relay-bypass/blob/main/relay-bypass/relay-bypass.ino#L205-L242
The important bit is that you cycle the address (wear leveling) rather than read and write the setting to the same memory location every time. It'll increase its life exponentially.

[matt_garman]

Hi Matt, Thanks for your offer on the PCB and the MCU for beta testing, I may PM you later on that.
Just for now though I thought since you seem pretty adept with coding, a whole lot more so than myself, I were wondering if you could possibly just put in place the right coding added to or reconfigured in the CODA HEX file code, all it needs is same ability that you have placed within your own code, to start up with the LED off and in bypass, with the relay synced to the same.

I understand, at a high level, what you want the code you posted to do.  But I don't understand the thought process behind the implementation.

The schematic shows pin2/GP5 and pin3/GP4 connected to the relay coil.  But I don't know what you're trying to do with that 100uF C3 cap in series with pin2 and the relay coil.  Also, the code never shows pin3/GP4 being set to 1... the way the code is written, it has the effect of not using pin3/GP4 at all, and connecting that end of the relay coil directly to ground.

Because you and I have discussed this prior, I'm guessing you're trying to mimic what this circuit does (with that series capacitor to the relay coil).

As you probably know, a latching relay coil only needs a current pulse to change the relay (in contrast to a non-latching relay, that needs constant current to remain in the set state).  In that other circuit, the series capacitor provides the pulse.  Current flows during the capacitor's charge or discharge state, and thus activates the relay.  Once the capacitor is fully charged (or fully drained), no more current flows.

However, one of the benefits of using a microcontroller is that you can explicitly control the current pulse time.  (Side note: this is in fact one reason I'm not terribly hot on that other design - even if you do the math to get the capacitor sized just right for the relay, you have to build in a fairly big margin because electrolytic capacitors are typically only 20% tolerance.  Ultimately, that means you're probably providing too high a voltage and/or too long a current pulse to the relay most of the time, which could shorten its lifespan.)

So I would drop C3 entirely from the circuit.  Then, in pseudocode, the relay activate/deactivate code looks like this:

Code Select Expand


assumed initial conditions:
    pin2/GP5 set low
    pin3/GP4 set low

activate:
    set pin2/GP5 high
    sleep X milliseconds
    set pin2/GP5 low

deactivate:
    set pin3/GP4 high
    sleep X milliseconds
    set pin3/GP4 low


Where X is the the relay coil activate/deactivate time, plus some margin.

Since you're using pin5/GP2 for the photoFET muting circuit, we can extend the pseudocode to look like this:

Code Select Expand


assumed initial conditions:
    pin2/GP5 set low
    pin3/GP4 set low
    pin5/GP2 set low

activate:
    set pin5/GP2 high
    sleep Y milliseconds
    set pin2/GP5 high
    sleep X milliseconds
    set pin2/GP5 low
    sleep Z milliseconds
    set pin5/GP2 low

deactivate:
    set pin5/GP2 high
    sleep Y milliseconds
    set pin3/GP4 high
    sleep X milliseconds
    set pin3/GP4 low
    sleep Z milliseconds
    set pin5/GP2 low


Where Y is the time you want to mute before activating the relay, and Z is the time to continue to mute after the relay has changed state (Y and Z might be equal; optimal values likely need to be experimentally determined).

You could go through a similar iteration of adding the LED pin activate/deactivate to the code.  (But you turn it on and leave it on for activate, and turn it off and leave it off for deactivate.)

And then once you have the code in place to reliably activate and deactivate, you simply invoke either block at startup (before entering the main loop).

Hopefully that's enough to set you on the right path... the real code isn't too different from the pseudocode.

Also with your own code, why don't you add the same type code for temporary mute function as incorporated withing the CODA code, this works well enough with the Coda when set up to  temporarily ground the signal output with a short pulse at every change on the relay, and allows sufficient anti click anti pop to the function.

I do plan to do that.  And the code is pretty trivial - I just walked through the pseudocode version above.  But as I said before, I want to make sure the most essential functionality works reliably before I go adding features.

The main thing I am concerned about is switch debouncing: it's arguably the most crucial part of the code - if that doesn't work reliably, then all the extra features are moot.  The way I think about it: when you're at a gig, and it's time for your solo, and you hit your boost pedal and it doesn't turn on, suddenly mute functionality or temporary-on or any of the other fancy features don't matter; or what if you're in the song's quiet part, but some stray RF makes it into your octave-fuzz and is mistaken for a switch press; what if it worked reliably for months and now you've got your first outdoor gig in the middle of the summer, and the heat causes tolerances to shift just enough that it no longer works reliably...  I was recently corresponding with someone who was using yet another MCU relay implementation, and despite using the Arduino's bounce2 library, the switching was unreliable for him (not saying the Arduino bounce2 library is bad, just that switch debouncing is a nuanced problem).

[bluelagoon]

Hi Matt, thanks for your reply. As for the 100uF onto the relay, that is only in place, because the Coda MCU will not drive a 5V single coil latching Relay from the GPIO on its own, and it needs the extra stored energy of the cap to activate, This is another drawback compared to the VFE MCU which does it all correctly straight from the GPIO pins. The Coda would likely activate a 3.3V latch Relay and possibly a 4.5V latch Relay, but does not want to play ball with the 5V latch Relay..

The Coda does however work well with 5 volt single side stable non latching relays.
As for getting the Coda up to par with the VFE, have not had a thorough look at the code you presented last post, will do so when I get a chance.

What the Coda still needs is the syncing to be right as explained previously, one suggestion which could possibly be implemented as mentioned earlier was to use the eeprom, if I only new coding better I probably could, still have some learning to do.

an example that stores the bypassed/engaged state in EEPROM: https://github.com/mstratman/relay-bypass/blob/main/relay-bypass/relay-bypass.ino#L205-L242
The important bit is that you cycle the address (wear leveling) rather than read and write the setting to the same memory location every time. It'll increase its life exponentially.

Another idea that you suggested sounds feasible also, to write in the code -

block at startup (before entering the main loop).

Which if possible could somehow leave the LED switched at power up in same state as was at last power off, if that's what I take your meaning to be there.

Anyhow still hoping to hear from Tom on this, that he may have something good to share, and ultimately still hoping that Peter from VFE comes through with his proposal to share open source on the VFE code.

I like the Coda MCU mainly because I am able to burn the code to the chips myself, with very little coding knowledge, its pretty close to the VFE type MCU but just needs a few tweaks, mostly one to allow for use of a Single Coil Latching Relay, then it would be close enough on Par with the VFE, Still hoping that eventually Peter at VFE will get licensing rights purchased for that code that he would then put out as open source, this would less complicate my life.
Aside from that, the author and creator of the VFE Code was Jack Orman, He does sell his own coded chips which do get a bit pricey, but then I guess they may well be the best representation of the VFE type coded MCU's
http://www.muzique.com/pcb.htm#dyp
He may also if approached possibly program and sell a batch with same code as the VFE type.
Something to consider.

Another pre programmed MCU I recently stumbled upon, at the Forum over on PedalPCB, where I see you are quite active., is the "Intelligent Relay Bypass Module" These seem very versatile in what they are capable, hope to order some eventually and give them a go, just always gets costlier, when you are paying up for the pre programmed convenience.

Thanks, Best Regards, Trevor

[R.G.]

Just kibitzing here.
I've done several MCU-relay switchers over time. I'm pretty much with Tom - it's too simple to need a whole lot of coding effort.

Taking a step back from the details, the most important part of all of this is to write down >explicitly< what the relay does when you press the switch, and when power goes off and back on. Once you can state clearly what is to happen, the rest is a matter of twiddling the bits.

I vastly prefer two-coil latching relays. The lack of constant power needed is a big advantage; plus, you never need to worry about what state they come up in, or saving/memorizing the state. You just whack them with a reset (i.e. "off") pulse at every power up. The relays then always power up in the "off" condition.

Remembering the power down state in EEPROM is fraught with some issues. First, there is the issue of wearing out the EEPROM and leveling, but a bigger problem is that EEPROM writes slowly, so you have to ensure that there is enough power left for the EEPROM section of the MCU to finish its write cycle at every power off. Drop power during the writing process and the EEPROM gets confused. There are other remember-the-state tricks (good one on using the Millenium!) but its easiest if you just force the issue and set the relay to "off" when power comes up.

Seriously, funding a purchase of code rights for a switch/relay driver is a little like using nuclear weapons to swat flies.

[matt_garman]

Hi Matt, thanks for your reply. As for the 100uF onto the relay, that is only in place, because the Coda MCU will not drive a 5V single coil latching Relay from the GPIO on its own, and it needs the extra stored energy of the cap to activate, This is another drawback compared to the VFE MCU which does it all correctly straight from the GPIO pins. The Coda would likely activate a 3.3V latch Relay and possibly a 4.5V latch Relay, but does not want to play ball with the 5V latch Relay..

The Coda does however work well with 5 volt single side stable non latching relays.

I assume you are using the PIC12F675, since that is what Coda is using, right?

Which relay(s) have you tried?  And what leads you to the conclusion that the pic12f675 will not drive a 5v single coil latching relay?  I can assure that the the pic12f675 can directly drive the Takamisawa AL5WN-K or Panasonic TQ2-L-5V, as I have done that (whether or not it's a good idea is a separate conversation).  At least in the Panasonic TQ2-L series, per the datasheet, most of the different voltage relays actually require the same power: lower voltage relays use more current; higher voltage relays use less current.  The pic12f675 should put out it's supply voltage when you set a GPIO pin high(*).  So if you're running the MCU at 5v, the GPIO set high should be approximately 5v.

(*) I have more familiarity with the AVR (ATtiny) MCUs, but their GPIO pin "high" voltage will actually be a bit below supply voltage (and likewise, the "low" voltage will be a bit above 0v).  Furthermore, the voltage drops as current increases, and 20ma (as needed by TQ2-L-5V or AL5WN-K) actually results in a non-negligible voltage drop.  I was unable to find similar detail for the pic12f675 in it's datasheet, but I think we can assume the behavior is reasonably similar to the AVR chips.  Fortunately, the activation tolerances on these relays is pretty generous so it works.

[bluelagoon]

Hey RG, Thanks for chiming in. very appreciated. I know it does sound overkill like a nuclear weapon to swat flies, but alas some of us Coding deprived individuals are getting desperate for something seemingly simple in the order of a reliable silent relay bypass system.
Thus all the comotion.
As for the dual coil latching relays, that seems realistic in the sense they are less fuss easier to control, but I do believe the cost of the dual coil latch relays runs at a premium over costs on the single coil latch relays, which makes them less desirable.

Your suggestion to -

set the relay to "off" when power comes up.

Makes the most sense of all, Can somebody please just add that line or 2 whatever it takes to the Coda code already on this thread, that might just be all it takes to keep me quite.
Cheers.

[bluelagoon]

Hi Matt,
Come to the conclusion that the 12F675 will not drive a 5V single coil latching relay, simply by the fact of trying it in the Coda circuit and finding out that it will not drive it, just to much under current to initiate the relay activation on a 5V latch relay.
Have a feeling have tried several different 5V latch relays, most recent can confirm will not work directly is the HFD31/5-L1, and just tested with the EA2-5SNJ single coil latch relay, and same again does not work without the cap included, All using exact same components as Coda original circuit.
Can also now confirm the Coda circuit wont even directly drive a Fujitsu FTR-B3GB003Z 3Volt single coil latching relay,
unless you add the electro cap into the circuit.

I do still have some Panasonic TQ2-L-5V, but they are on pcb's, shall extract one later for testing, but pretty sure have already done so and concluded as much the same.
Perhaps the solution is not a smaller voltage relay in same circuit but only alternative is to put an electro cap in to boost the current needed. it works with the electro, and don't believe that it can harm the relay any, since it is such a short term burst of power, not exceeding the voltage requirement nor likely any over current concerns, its only put there to get the required result, as in a working latching relay.
If someone comes along with something easier and more user friendly that I can simply burn on to a MCU chip with C Code through a Pickit3 programmer, then I will happily snap it up.
I did see something just today that grabbed my attention as what looks a very good relay bypass pre programmed MCU, more reasonable priced also, its from the MAS effects website -

https://shop.mas-effects.com/collections/all/products/relay-controller?variant=39274001531041

https://shop.mas-effects.com/collections/diy/products/relay-bypass

https://mas-effects.com/relay.pdf

https://github.com/mstratman/relay-bypass

These look most promising, he even has his earlier versions over on Github as open source code,
but it seems it is for ATtiny, maybe I need to learn to program ATtiny now.

The Quest continues.

[matt_garman]

As for the dual coil latching relays, that seems realistic in the sense they are less fuss easier to control, but I do believe the cost of the dual coil latch relays runs at a premium over costs on the single coil latch relays, which makes them less desirable.

From my experience, the dual-coil latching relays are only slightly more expensive than single-coil latching (assuming same manufacturer and relay family).  Further, what I found is that if you drive the relay directly from the MCU, the single-coil latching is easier to implement; but if you want to decouple the MCU from the relay coil via transistors, the dual-coil is easier to implement.

Hi Matt,
Come to the conclusion that the 12F675 will not drive a 5V single coil latching relay, simply by the fact of trying it in the Coda circuit and finding out that it will not drive it, just to much under current to initiate the relay activation on a 5V latch relay.
Have a feeling have tried several different 5V latch relays, most recent can confirm will not work directly is the HFD31/5-L1, and just tested with the EA2-5SNJ single coil latch relay, and same again does not work without the cap included, All using exact same components as Coda original circuit.

According to the datasheet, the single-coil latching 5V HFD31/5-L1 requires 100mW of power to activate.  At 5v, that's 20mA, which the pic12f675 can definitely do.  In fact, this is exactly the same power as the TQ2-L-5V, which I know works.

I suspect you are thinking the 12f675 can't drive the relay coil because the code is incorrect.  The reason it "works" with that series capacitor is because you are emulating the behavior of the other circuit (i.e. using the capacitor charge/discharge behavior to get your two-way current pulse).  Get rid of the series capacitor and fix the code.

I can't promise this will work, but off the cuff, something like this should get closer.  You should be able to see the similarities to the pseudocode I wrote above.

Code Select Expand


       // Changing state of the pedal
       if(changestate == 1) {
           if(state == 0) { // change to on
               GP2 = 1; // photoFET on
               __delay_ms(20); pre-relay-switch mute time ("Y" in my pseudocode)
               GP0 = 1; // LED on
               GP5 = 1; // start positive relay pulse to activate relay
               //GP4 = 0; // unneeded, should already be low
               __delay_ms(20); // relay change and settle time  ("X" in my pseudocode)
               GP5 = 0; // stop positive relay pulse
               __delay_ms(20); // post-relay switch mute time
               GP2 = 0; // photoFET off; post-relay-switch mute time  ("Z" in my pseudocode)
               state = 1;
           }
          else { // change to off
               GP2 = 1;
               __delay_ms(20);
               GP0 = 0; // LED off
               GP4 = 1; // start negative relay pulse to reset relay
               //GP5 = 0; // unneeded, should already be low
               __delay_ms(20);
               GP4 = 0; // stop negative relay pulse
               __delay_ms(20);
               GP2 = 0;
               state = 0;
           }


Obviously, I only edited the "relay activate"/"relay reset" block of code.  I didn't look closely at your startup/init code.

I did see something just today that grabbed my attention as what looks a very good relay bypass pre programmed MCU, more reasonable priced also, its from the MAS effects website -

https://shop.mas-effects.com/collections/all/products/relay-controller?variant=39274001531041

https://shop.mas-effects.com/collections/diy/products/relay-bypass

https://mas-effects.com/relay.pdf

https://github.com/mstratman/relay-bypass

These look most promising, he even has his earlier versions over on Guithub as open source code,
but it seems it is for ATtiny, maybe I need to learn to program ATtiny now.

I haven't used that, but from my perspective, indeed it appears to do everything right (keeping RG's concerns about writing state in mind, though earlier revisions of the code don't have this).  (I personally prefer the AVR (i.e. ATtiny) chips, as you can do compiling and programming from the commandline with a nice open-source tool chain.  No proprietary GUI necessary.  Plus the programming tool is called "avrdude", that alone makes it better!  )

Your suggestion to -

set the relay to "off" when power comes up.

Makes the most sense of all, Can somebody please just add that line or 2 whatever it takes to the Coda code already on this thread, that might just be all it takes to keep me quite.

If my hack above is enough to get the relay (the 5V relay, without the series cap) actually switching, then just take either block of code (between the curly brackets), i.e. for whichever you want as the startup state (activate or bypass) and copy-paste it to just before the main while(1) loop.  (That's to get it to always start in one state.  Remembering the last state at power off requires a fancier solution).

[bluelagoon]

Hi Matt,
Thanks for the code will look into programming that in a bit later and giving it a go.
At a closer look at prices on the Dual Coil latch relays, seems they are available similarly priced not much difference. Probably a stretch to say otherwise, was mainly basing on here say from others who stated as much.
And no, I don't particularly blame the code for the 5V latch relays not working, could well be the inefficiency of the MCU output, but then again it may be something to do with the code, As the VFE does it all correctly, running a single coil latch Relay always in sync with the LED status and no qualms on its reliability, plus it needs no extra electro cap on the relay to jolt it into action.
It does use a different MCU in the PIC12F509, but I think they are pretty similar to each other.
So something ain't particularly right with the Coda as compared. It would be preferred to omit a sizable 100uF or more electro to save space and cost of components, but if that's what it takes to get a free source coded MCU to work with a lower power drain latching relay, its not a bad trade off.
Will check your code later and try and implement it into the Coda circuit with some new instructions for the startup state, then we might have something more substantial. We live in hope!

[mark2]

(keeping RG's concerns about writing state in mind, though earlier revisions of the code don't have this)

To be clear, the MAS code doesn't try explicitly to write at power off. Instead it writes with each press of the foot switch. If you press the foot switch then immediately pull the plug you will have unexpected behavior.

Fortunately the worst case scenario is that it doesn't properly remember your foot switch state in that instant. And you're no worse off than 90% of the "soft touch" pedals out there on the market. But then it goes right back to remembering correctly again.

[bluelagoon]

I see the MAS writes to eeprom, I think you may have stated earlier, but it does it in such a way as to not wear it out so prematurely, writing to different location each new write.
Wouldn't mind grabbing some from MAS just to try out the other features that its capable of.

Just curious are you the same Mark that runs the MAS website?

[mark2]

Just curious are you the same Mark that runs the MAS website?

Yeah, that's mine. Happy to answer any questions about the code. Not to derail the original discussion (though I share others' belief that it's overkill to pay for relay code), just wanted to weigh in on the EEPROM aspect.

[R.G.]

Some useful background info you may or may not have already found:
Low-signal relays tend to be rated in milliwatts - that is, the power needed to energize the coil to move the relay. This reflects that a certain power is needed to move the mechanical parts. As such, the lower the rated voltage to the coil, the higher the current. For the popular Panasonic TQ series in 140mW rating, the 5V rated relays have a 178 ohm coil and the 3V rated ones have a 64 ohm coil. The 5V ones are listed as needing 28.1ma and the 3V ones need 47ma. PIC controllers have I/O current rating and internal limiting at about 25ma. So although PICs can sometimes drive a 4V or 3V coil, you need to be luckier with each drop in relay coil voltage rating. You can get around this to some extent by paralleling up extra I/O pins on the controller, but that quickly runs you into a more-pins controller.

Here's the datasheet for the TQ2 series: https://www.mouser.com/datasheet/2/315/4514_fileversion-1855604.pdf

The premium for two-coil latching isn't much. Mouser lists the non-latching TQ2 at about $1.85, the two-coil version for $2.30, so the premium for a dual coil latching is about $0.45.

There are a couple of issues which favor higher voltage relays. First, the current is lower, so dealing with coil current induced noise is easier, and also if the coil voltage rating is roughly the same as the total unit power supply, you don't have to regulate the relay coil current. nYou trade off the cost/complexity of the two driver transistors for the cost of a voltage regulator chip for the PIC. PICs are so low in current drain that you can often use just a resistor and zener for regulating their power.

Using external drivers also lets you play tricks with the coil current another way. I used a resistor and 100uF cap to supply the relay, not the main circuit power. The cap trickle fills over time. Humans are pretty slow, so refilling the cap to whack the relay into action over 50mS to 100mS means that humans probably will never press the switches fast enough to notice the operation lag, and that the current from/to the power supply can't peak in the supply and ground wires to cause current clicks. The cap re-fills before the human can press the switch again. This also has the advantage that you can snub the flyback pulse into the coil voltage capacitor, not the whole power supply.

Good layout of the coil power supply and driver current paths to keep the coil currents out of the signal ground of the whole pedal is crucial.

You don't need an opto or discrete MOSFETs to mute. The standard old CMOS analog switch chips, CD4016 or CD405x, attached to the signal wire through a DC blocking cap and to a middle-of-power-supply bias voltage/cap effectively shunts the signal to AC "ground" through a sub-100 ohm resistor. You can get much the same effect by using a P-channel JFET - if you can find a reliable supply of them. They're mostly only available in SOT23 packages now. This also saves you the 5ma to 20ma of current for an LED driven muting opto, that again cuts the amount of current that has to be from a regulated voltage through the MCU.

Hmmm. Now that I think of it, I wonder if you could construct a fake muter from MCU pins by making a 100K/100K/0.1uF bias voltage with a cap to the signal line, and 100 ohm resistors to two I/O pins of the MCU. The MCU pins would be driven simultaneously, one high and one low, and make the impedance of the bias voltage go from 50K to 50 ohms as long as both pins were on. Turning mute off would involve just tri-stating both pins. This would depend heavily on the matching of the I/O pins in both voltage drive and timing; using both pins in a single port is probably mandatory.

Once the physics of the relay power supply, coils, and current paths are taken care of, any fancy stuff with the MCU programming is icing on the cake. Conversely, if the coil drive and current paths are not well done, it puts a much bigger reliance on that muting circuit, pushing it close to being noticeable to humans.

I used to use assembly and C, but I find that the free Great Cow Basic package for PIC and AVR makes coding very, very fast and nimble. I make fewer coding mistakes in basic, as it's not as syntax-fancy.

[marcelomd]

Released just now:  ".hex code for VFE switching MCU" https://www.vfepedals.com/product-page/hex