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

[bluelagoon]

Peter Rutter has just launched an Indiegogo fund raising campaign to hopefully get the cash together to purchase the license rights to the Silent True Bypass Relay Switching code that programs all the PIC Microcontrollers used in the VFE effect pedals. To me these VFE PIC MCU's are one of the best for true bypass silent relay switching that are on offer, and while a little similar to the Free code offered by Coda for similar purpose, the VFE PIC works differently than the Coda and is useful in ways that the Coda cannot achieve.. I know that you can write your own code easy enough for a required switching situation, or you can pay someone to write it for you. But what Peter has in mind if he gets the funds together to purchase the PIC MCU license rights, is to make his particular PIC MCU code available for free to all DIY Pedal builders just like the Coda code is presently available.
This simplifies things a lot for those who don't wish the extra curricular of learning to Code Micro Chips.
This is very altruistic of Peter Rutter giving back yet again to the DIY community, so would encourage any and all with an interest in such things to have a look at the Indiegogo campaign and hopefully be inclined where able to support him in his quest.

https://www.indiegogo.com/projects/help-vfe-pedals-make-diy-available-to-everyone#/


Cheers, Trevor T.

[FiveseveN]

an Indiegogo [...] to purchase the license rights to the Silent True Bypass Relay Switching code

Where does he mention that?
I'm out of the loop() on the issue so excuse me if this should be obvious:
1. What exactly is the functionality that's missing from the Coda solution? It should be trivial to implement.
2. Did Peter write this firmware? If so, what's keeping him from releasing the binaries and/or source now?

[ElectricDruid]

1. What exactly is the functionality that's missing from the Coda solution? It should be trivial to implement.

+1 this.

The job is too simple to need money throwing at it.

[anotherjim]

If it was developed while an employee, the rights belong to the employer. That may be behind it.

[FiveseveN]

If y'all tell us what you need we can "develop" it in a lunch break.

[ElectricDruid]

If y'all tell us what you need we can "develop" it in a lunch break.

+1, we can indeed!

[bluelagoon]

an Indiegogo [...] to purchase the license rights to the Silent True Bypass Relay Switching code

Where does he mention that?
I'm out of the loop() on the issue so excuse me if this should be obvious:
1. What exactly is the functionality that's missing from the Coda solution? It should be trivial to implement.
2. Did Peter write this firmware? If so, what's keeping him from releasing the binaries and/or source now?

They fundamentally both work differently, With the Coda, it is designed to really only run a single sided relay, whereas the VFE PIC will run a single coil latching relay, which allows for less power usage if implemented right. Also the way in which each of them are setup to run the LED  and the momentary mute function both differ somewhat, overall straight out of the box with no extra circuitry than original Coda or VFE circuitry, the VFE is a lot quitter and more efficient where silent no pop click switch noise is concerned.

And No Peter did not write the firmware, that is exactly his point, that if indeed he did have the license to the firmware code, then it seems he would have long ago shared it already with the community. Thus his current Indiegogo appeal to raise funds to purchase that firmware code from the original source owner.

PS: If any one here is happy to write me a code not dissimilar even identical to the VFE PIC, then I would gladly take them up on the offer. Just let me know.

Cheers, Trevor

[bluelagoon]

If y'all tell us what you need we can "develop" it in a lunch break.

Hey FiveSeven, Thanks for your generous offer for the lunchbreak code work. What I would like is a code very much the same as the VFE code if you could implement that for me I will cover the costs for your Lunch Break Food Fare. Let me know, I could send you a VFE PIC already programmed if that would help, but I know the VFE code is locked up on them. Cheers, Trevor

[amptramp]

One of the few threads I started was for three methods of noiseless switching that do not need software:

https://www.diystompboxes.com/smfforum/index.php?topic=120006.msg1122294#msg1122294

One solution uses a 4007 as a switch, exactly as shown in the Motorola 14007 datasheet.

Another solution that isn't great for all pedals but would be useful for a fuzz is the diode switching method.

The final method is to use fast switches like a 4066 to switch suddenly but only when the input and the output of the pedal electronics is at the same level.

The advantage of avoiding a PIC is that all equipment that operates from the AC line and has an oscillator running at 9 KHz and above needs to be tested for electromagnetic compatibility concerning radiated and conducted emissions.  This kind of testing is thousands of dollars, so if you are a commercial producer, the three methods I have originated saves you that.

[matt_garman]

I haven't (yet!) used the VFE switching scheme, but have recently taken an interest in MCU-controlled relay bypass.  The Coda effects example is certainly very nice, but my issue with it is that it uses a non-latching relay.  That means the coil must be continuously energized in one state.  This certainly works, but due to current consumption, isn't really suitable for battery power (or if you're neurotic about optimization like me!).  I would argue that, if you're going to use a non-latching relay (and don't care about power consumption), that you can skip the MCU and just use an NE555.

Latching relays only consume power when they change state.  The NE555 uses a fair amount of current.  You can use CMOS logic ICs instead of an NE555, and lower power consumption considerably, as shown here.  If you read to the end of that thread, you can see an example of a PCB I built using that scheme.

I wanted to further simplify, and so took the time to learn a little MCU programming.  I implemented a basic on-off switching scheme for four small microcontrollers: ATtiny85, ATtiny13, pic12f675, pic10f322.  All these MCUs have an ultra low power sleep or "power down" mode, but can be programmed to wake up on a pin change.  So unless you're constantly switching the relay, the MCU spends most of its time in a micro-amp state.  (With my cheap multi-meter, I'm measuring current by looking at voltage drop across a 1R in series with the power supply, and I can't even see a difference between the MCU in sleep state versus MCU completely out of the circuit.)

My goal is to have a reference-quality, open-source implementation available for everyone.  I'm really just trying to make it easier for people who want to do this.  There's a lot of information out there, but it's somewhat scattered.  So here's my little contribution: mcu-relay-controller on GitHub.

[bluelagoon]

Hey Matt, Good work on those codes for the Attiny mcu switches, and thanks for sharing as much. Just wish some here blowing their horns earlier saying how easy it is to write code for these bypass switch MCU's would actually front up with their offers to do so in their lunch breaks or otherwise. It would be a great benefit to all DIY users to not have to search down 10,000 different rabbit holes seeking the means to achieve a simple bypass switch solution, nor have to go all out and learn coding.
I know a lot say its easily achieved coding these mcu's, sure it is if you got a university degree in computer science or something akin, but not every DIY pedal builder was so privileged or so pre disposed in their vocation, education or profession, to be availed with the know how.
I do realize sometimes that if you want something done you have to do it yourself, but the whole premise of these type DIY forums is for support to the enthusiasts in that area of interest.
I am greatly appreciative of all contributors here and elsewhere in such forums , people who support and educate along the way in the learning process, this is exactly where the internet and all its volumes of content is a blessing and benefit to those seeking to learn.

But even with all the support here for the countless number of different effects and the many re iterations and mods to these effects, there still seems to be a lack for a simple free to source code for a simple effective effects Relay True Bypass MCU triggered switching code to support the myriad of endless effect possibilities. To me this is a lack within the FX pedal DIY community, Hopefully someone may just contribute there lunch break sometime to such an endeavor.
The meanwhile, we still wait for the VFE effects MCU code disclosure from Peter Rutter of VFE pedals. I spoke with him not too long ago, and he said due to other commitments for the time being, he had to put the priority for the code license purchase on the back burner, but did still hope to get it over the line soon enough, proposing hopefully to be there by the end of Summer.

[ElectricDruid]

I've been hunting on the VFE site to see if I could find out what the Relay bypass does, but I can't even find a reference to relay bypass, let alone anything giving enough detail to code from:

https://www.vfepedals.com/diy

So...What's the requirements for this super-duper relay bypass code you'd like to see? I can think of various features:

1) Latching / non-latching relay support
2) Mute output that goes high slightly before the relay switches
3) Momentary/latching switch modes, so you can optionally add splashes of effect

Honestly, I think putting the microcontroller to sleep between switches is barely worth it. Perhaps just for style points, but practically? If there's a *relay* in the circuit, the current consumption of the microcontroller is going to be negligible by comparison, even if the relay is only using juice when it's switching. At least, that's my feeling about it - I haven't done the calculations. And maybe it's worth it for the style points alone, in a "well, why *not*?" kind of way.

So, have I missed anything? What else does the VFE code do?

[bluelagoon]

Hey Tom, Thanks for coming to the party on this one. Much Appreciated. As for the VFE MCU, the details and circuit for it can be found on the Madbeans Pedal website, under the VFE pedal project section, see the following links -

https://www.madbeanpedals.com/projects/_folders/VFE/pdf/VFE_SBv3.pdf

https://www.madbeanpedals.com/projects/_folders/VFE/schematics/VFE_SBv3.gif

https://www.madbeanpedals.com/projects/

If you are interested to do an equivalent type code as used in the VFE MCU bypass switch circuit. I would be happy to send you over an authentic VFE coded MCU, that you could put together in the same switching circuit as shown on the madbean website and which is used in the VFE commercial pedals. This way you could check all its voltages at every pin and all its parameter functions, and hopefully this would be enough for you to decode well enough to write a similar code to emulate the VFE MCU.

Its pretty much just a plain vanilla type switching arrangement, but when implemented within the circuit that its used it works well to give a clean no pop no click switch in and out, with a low power draw since it utilizes a single coil latching relay.

Let me know if you are up for it, and check the madbean website, pick out a VFE pedal project that interests you, as they all come inclusive with the pre coded MCU, and PM me your address and I'll get the VFE effect project board of your choice with the MCU sent over for you to dissect.

Cheers, Trevor

[matt_garman]

1) Latching / non-latching relay support
2) Mute output that goes high slightly before the relay switches
3) Momentary/latching switch modes, so you can optionally add splashes of effect

That's essentially my mental roadmap for my project.  Though right now I'm focusing on very simple on-off functionality for a latching relay, just so that I have a solid foundation on which to build.

Honestly, I think putting the microcontroller to sleep between switches is barely worth it. Perhaps just for style points, but practically? If there's a *relay* in the circuit, the current consumption of the microcontroller is going to be negligible by comparison, even if the relay is only using juice when it's switching. At least, that's my feeling about it - I haven't done the calculations. And maybe it's worth it for the style points alone, in a "well, why *not*?" kind of way.

I guess my question is: why not?  Those four MCUs I've worked with all have trivial compiler support for setting an ISR (interrupt service routine, i.e. "wake me up and run this code on pin change") as well as putting the device to sleep... it's truly a negligible amount of extra code.

Going from memory,the four MCUs I played with use maybe 1-3 mA when idle (but not asleep).  I'm measuring mV drop across a 1R in series with my supply, which allows me to trivially calculate current draw.  When I put the MCU to sleep, the mV drop is exactly the same as with the MCU removed from the circuit, i.e. too little for my cheap meter to recognize.

Currently, my design is for a 4v5 or 5v relay and 5v supply to the MCU.  On my next iteration, I'm going to 3v3 supply and 3v relay, that will reduce MCU current draw when not sleeping.  And most of these MCUs allow you to set their operating speed, and slower means less power draw.  That's actually the route I initially thought to go down (running at the lowest possible clock speed), but that actually looked non-trivial, to force these things to run below 1MHz.  Sleeping was easier and has lower power draw!

Anyway - I'm awaiting delivery of some PCBs I made for use with the ATtiny13 or 85.  These are small and simple, and designed to support only basic on-off functionality (i.e. a drop-in replacement for a 3PDT mechanical switch).  The circuit works on the breadboard, so unless I made a mistake in the PCB design it should just work.  I'm happy to send a few of these out for free to anyone who wants to help test or contribute to my project.

[ElectricDruid]

And maybe it's worth it for the style points alone, in a "well, why *not*?" kind of way.

I guess my question is: why not?

Yeah, entirely fair enough. Why not indeed? If we can and it's better, even if only marginally, then let's go for it.

Not sure why you had trouble running the chips at lower speeds though. I don't know the AVRs that well, but it's pretty simple on the PICs - mostly it's about setting up clock dividers correctly at start-up. It's a ball-ache until you've done it right once, and then after that you can simply copy what you did ever after, or tweak it slightly.
1MHz clock rate should be doable, and that would make various debouncing tasks less onerous too, as well as reducing the need for large counters to time relatively short intervals.Perhaps 500KHz or 250KHz would even be better, dunno. I never had a need to go *slower* much before. Mostly I was trying to squeeze as *much* as possible out of these little 8-bit chips, not throttle them back to almost nothing.

[matt_garman]

Not sure why you had trouble running the chips at lower speeds though.ack to almost nothing.

To be fair, I didn't actually try it, I just stumbled across some random forum posts suggesting there might be extra hoops to jump through to make it work.  That, combined with the ease of using sleep modes, was enough to leave underclocking off the table.

1) Latching / non-latching relay support
2) Mute output that goes high slightly before the relay switches
3) Momentary/latching switch modes, so you can optionally add splashes of effect

Not from VFE, but I think in general, other options to be considered, in terms of feature-completeness, would be:

• Not only support for latching and non-latching relays, but support for single- and dual-coil latching relays(*)
  
• Use the MCU's on-board non-volatile memory to remember the last state (see MAS Effects relay bypass for example)
  
• I'm not sure if this is possible, but maybe use the MCU's watchdog and/or brownout detection circuitry to have some kind of alert or even fancy "reset to state" feature.  For example, if voltage goes below X, then maybe have an another LED light up (or a bi-color LED change color, or the single LED starts blinking, etc).  And if voltage drops again below Y, then reset to some "failsafe" state, e.g. bypass
  
• A general "user interface" library, like the Anduril flashlight firmware, where you can have more functions than you ever imagined from a single momentary switch (e.g. double-tap, triple-tap, N-tap, press-and-hold... essentially Morse Code)

(*) For that first item: single- vs dual-coil latching relays.  I've done a little research (see here and here) on the topic of directly driving a relay from an MCU.  The general consensus seems to be, "Everyone does it, has been doing it forever, seems to work OK.  But it's probably not an ideal design."  I.e., ideally, the relay should be driven from a dedicated IC, or transistors plus protective flyback diodes.  I can't seem to come up with a simple circuit for the single-coil latching relay that uses transistors to drive the coil, and has flyback diodes to protect the transistors.  So I'm thinking of having two PCB designs, one that is smaller and simpler, for the single-coil relay, where it's driven by the MCU directly.  The other will use a use a double-coil relay and the added decoupling/protection components.

[ElectricDruid]

I can't seem to come up with a simple circuit for the single-coil latching relay that uses transistors to drive the coil, and has flyback diodes to protect the transistors.

No, I've been thinking about this too, and it's not immediately obvious or simple.

The VFE simply ignores the problem, and uses a relay with a 20mA coil current, which is within the 25mA a PIC can handle (not sure about AVRs, but I bet it's similar). Ultimately, it's not a critical application, so occasional failures aren't a big problem. This is not life-support, or the space shuttle!

[bluelagoon]

Following on in the quest for a workable decent MCU bypass circuit and code, -

I have slightly modified this Coda MCU bypass circuit. Trying to get it to function correctly using a Single Coil Latching Relay. While it works pretty flawlessly using a Non Latching, Single Side Stable relay. it does present an issue when trying to get it to function as well using the Latching Relay.

Reason for wanting to use the latching relay is that the current draw is around 20mA less for the non latching relay at around 6mA compared to around 26mA for the Non Latching relay.

Main issue is that every time the power is disconnected from the circuit, the relay stays in its last latched state.. But when power is applied back to the circuit it always starts up with the LED in a fixed state of OFF regardless to the last latched position of the relay when power was cut.
This makes power on startup always out of sync when power was last cut while the LED status was ON.
as the last setting before power out had it latched to the on setting according to LED status, but upon restart it starts up with relay in same ON status position, but with the LED unlit indicating the off position. It is easily toggled back to correct sequence after a couple of presses on the momentary, but initially it will always come up out of sync when shut down with LED lit on status.

Just wondering if someone with better electronics understanding than myself or even MCU coding knowledge would know a way to rectify this issue to allow the LED status to always sync correctly to the associated relay setting.

There is a way with circuitry to get the reset status to sync when using Schmitt triggers to run the relay, but not sure how that might fit here. see pics -

http://www.interfacebus.com/Glossary-of-Terms-power-on-reset-circuit.html

And I were reading also about reset controller IC's for use with MCU circuitry, was wondering if somehow that type extra circuitry could be implemented here. see following links -

https://www.edn.com/reduce-relay-coil-current-with-a-reset-controller-ic/

https://www.ablic.com/en/semicon/products/power-management-ic/voltage-detector-reset-ic/intro/

Or quite likely the best solution would be to modify the Coda code. I know that with the VFE type MCU circuit, it works flawlessly using a latching single coil relay, always being in sync with some kind of reset applied to see the pedal always startup same way each time with the relay synced to the LED status. Hoping someone can help. Thank You.

The Code for the Coda MCU circuit is -

Code Select Expand

/*
* File:   relayonpress.c
* Author: Benoit
*
* Created on 5/02/2017
*/

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <xc.h>
#include "header.h"

// Initialization
void main(void) {
   ANSEL = 0; // no analog GPIOs
   CMCON = 0x07; // comparator off
   ADCON0 = 0; // Analog to Digital and Digital to Analog convertors off
   TRISIO0 = 0; // output LED
   TRISIO1 = 1; // input footswtich
   TRISIO2 = 0; // output TGP222A
   TRISIO5 = 0; // output activation relay
   TRISIO4 = 0; // output ground relay
   TRISIO3 = 1; // input temporary switch

   GPIO = 0; // set outputs as low level (0V)
   
   // Variables definition
   uint8_t state; // on-off state of the pedal (1 = on, 0 = off)
   state = 0;
   
   uint8_t changestate; // to change status of the pedal
   changestate = 0;
   
   uint8_t temporary; // define the mode of the pedal : classic of temporary activation
   temporary = 0;
   
   uint8_t press_switch; // variable to detect if the switch is pressed
   press_switch = 0;
   
   // Main loop
   while(1) {
       if(GP3 == 0) { // By default: normal mode
          temporary = 0;
      }
      else { // If the "hold" mode is activated through the switch
          temporary = 1;
      }
       
       // Normal mode
       if(temporary == 0) {
           if(GP1 == 0) { // footswitch pressed
               __delay_ms(15); // debouncing
               if(GP1 == 0) {
                  press_switch = press_switch + 1; // switch is on
                  if(press_switch>10) {
                      press_switch = 10; // max value for press_switch
                  }
               }
           }
           if(press_switch == 1) { // switch is pressed : lets turn the pedal on or off
               changestate = 1;
               press_switch = 2; // avoid bugs if press_switch stays at 1
           }
           if(GP1 == 1) {
               __delay_ms(15); // debouncing
               if(GP1 == 1) {
                  press_switch = 0;
               }
           }
       }
       
       // Temporary mode
       if(temporary == 1) {
           if(GP1 == 0) { // if switch is pressed : temporary activation
               __delay_ms(15); // debouncing
               if(GP1 == 0) {
                  press_switch = press_switch + 1; // switch is on
                  if(press_switch>10) {
                      press_switch = 10; // max value for press_switch
                  }
               }
           }
           if(GP1 == 1) { // if switch is not pressed, turn it off
               __delay_ms(15); // debouncing
               if(GP1 == 1) {
                   state = 0;
                   press_switch = 0;
               }
           }
           if(press_switch == 1) {
               changestate = 1; // if switch is pressed, turn the pedal on
               press_switch = 2; // avoids bug
           }
       }
       
       // Changing state of the pedal
       if(changestate == 1) {
           if(state == 0) { // change to on
               GP2 = 1; // photoFET on
               __delay_ms(20);
               GP0 = 1; // LED on
               GP5 = 1; // relay on
               GP4 = 0;
               __delay_ms(20);
               GP2 = 0; // photoFET off
               state = 1;
           }
          else { // change to off
               GP2 = 1;
               __delay_ms(20);
               GP0 = 0; // LED off
               GP5 = 0; // relay off
               GP4 = 0;
               __delay_ms(20);
               GP2 = 0;
               state = 0;
           }
          __delay_ms(10);
          changestate=0; // reset changestate
       }
       
       // To let the pedal in the good state (on or off)
       if (state == 1) { // effect on
            GP0 = 1; // LED on
            GP5 = 1; // relay on
            GP4 = 0;
       }
        else { // effect off
            GP0 = 0; // LED off
            GP5 = 0; // relay off
            GP4 = 0;
       }
   }
}



[PRR]

{fixed}

[marcelomd]

Just brainstorming here.

There are three ways you can boot up with the correct LED status:

1- Read the relay status somehow (current sense, millenium bypass, etc.) and apply it to the LED or;
2- Store the last status in non volatile memory, like EEPROM or flash;
3- Never turn off the MCU, with a supercapacitor, or CR2032 battery.