News:

SMF for DIYStompboxes.com!

Main Menu

Arduino/Attiny85 code help

Started by patrick398, July 08, 2020, 06:13:14 PM

Previous topic - Next topic

patrick398

Ah yes sorry i've left the GND connection off pin 12 of the relay. This should make more sense  :icon_lol:

The relay connections are the same as when i was controlling it with a 555 which worked well, so hoping it still works ok with the uC




Firesledge

#21
It would be safer to put the whole load on the collector side (and therefore tie the relay pin 12 to +5V, and flip the diodes). Otherwise the emitter potential will be floating. Reaching the saturated zone will be not as straightforward and you might not get enough voltage to activate the relay. Then you could use a higher value for the base resistor, to avoid drawing too much current from the ATtiny pin.
Pédale Vite, multi-FX pedalboard

patrick398

Continuing with my arduino adventures and the theme of head meeting wall....
is there anything about this code that would cause the muting not to work as expected. I'm wondering if there's something about the button debounce that is not compatible with the delay on opto pin.
The opto should turn on and ground the output 30ms before the relay flips and turn off 30ms after but i don't think i can detect any muting and it sounds pretty much identical with or without the opto in place.

//CHANGE PIN NUMBERS FOR ATTINY85

#include <ezButton.h>


const int BUTTON_PIN = 3; // footswitch connected to attiny (2)
const int RELAY_PIN  = 0; // relay connected to attiny (5)
const int OPTO_PIN = 1; // opto connected to attiny pin (6)
int onTime = 30;

ezButton button(BUTTON_PIN);  // create ezButton object that attach to pin 7;

// variables will change:
int relayState = LOW;   // the current state of relay
int lastButtonState;    // the previous state of button
int currentButtonState; // the current state of button

void setup() {
  pinMode(BUTTON_PIN, INPUT_PULLUP); // set arduino pin to input pull-up mode
  pinMode(RELAY_PIN, OUTPUT);        // set arduino pin to output mode
  button.setDebounceTime(40); // set debounce time to 50 milliseconds
  digitalWrite(RELAY_PIN, relayState);
}

void loop() {
 
  button.loop(); // MUST call the loop() function first

  if (button.isPressed()) {
   
    digitalWrite (OPTO_PIN, HIGH);
    delay (onTime);
   

    // toggle state of relay
    relayState = !relayState;

    // control relay arccoding to the toggled state
    digitalWrite(RELAY_PIN, relayState);
    delay(onTime);

  digitalWrite (OPTO_PIN, LOW);

  }
}


Thanks! (again)

ElectricDruid

Seems pretty straightforward. I can't see anything obvious.

Some possibilities occur to me:

1) The relay switching just isn't that noisy, hence no difference with or without the opto
2) The opto muting isn't doing what you think it's doing in the hardware for some reason. How long does the opto take to turn on? (30msecs or more is going to make it useless)
3) The PIN numbers are wrong so the opto is never getting switched

potul

First of all, the delay() instructions you use ARE affecting the button debouncing, but in a "good way". What happens is that you add 2 delays of 30ms in the loop, so in reality, the debouncing routing will only be called  60ms after the button press is detected. I'm not familiar with ezButton inner code, but I would say this should not affect your code, as the button press is already detected and debounced.

What I could try in order to debug the whole system is:

-Try longer delays
-Add an LED or similar to the opto, to check that it's really activating

What opto are you using? It can be tricky sometimes to get an opto to fully mute your signal.

I have an unfinished project that uses an opto to change the volume of a signal sending it to ground, and I can tell I had to light the LED in the opto reaaaaaally bright to make it "almost" mute the signal, and still it's not really 0.






patrick398

I've tried a few different things. The code is definitely doing what it should, i've hooked up the relay bypass on a breadboard with a hand rolled opto and it's working, pretty quietly. There's more of a fade in/out which i guess is down to the response time of the LDR. When i try it with the TLP222A though it's pretty indistinguishable from when it's not in circuit at all. I started to think the optp itself was causing some noise but the pop is basically identical with or without it.
Even more frustratingly, the pop is worse with the TLP222 on the PCB, and even using the hand rolled opto on the PCB i'm still getting pop. These results are so inconsistent i'm not even sure where to look. I thought it could be a layout problem, admittedly there's an output trace which runs between the relay coil  :icon_redface: but i cut that trace and wired the output with a piece of wire avoiding the relay and got the same result.
More fiddling required...

patrick398

Seems as though the button itself is causing the noise? I've changed the code so everything happens slowly. Button is pressed, i hear a pop instantly, opto lights, delay of 100ms, relay flips, no noise, delay for 1000ms, opto off, signal unmutes.

Without the opto: button is pressed, i hear a pop instantly, delay of 100ms, relay flips, pop!

So the opto is definitely covering the relay switching noise, but there's a pop upon button press which can't be caused by the opto because it's present with and without the opto.

So when everything is running real time i think i'm getting two pops, very close together. The first upon button press, and the second as the relay flips (which i can cancel with the opto).
But where the hell is that first pop coming from?

ElectricDruid

Good work on the debugging. That seems to clear up a lot of things.

Quote from: patrick398 on September 29, 2020, 07:44:52 AM
But where the hell is that first pop coming from?

The pin is set up as "INPUT_PULLUP", isn't it? Does that set it up *both* as an input *and* with a pull-up? And the button is then connecting the pin to ground? No other possible short from the pin?

The only thing I can think of is that the button is yanking the power rail around somehow, probably by shorting something. Like might happen if the button input had the output driver still turned on and driving the pin high (which you wouldn't notice when you read it, since it's *supposed* to read high with the pull-up anyway).


patrick398

Quote from: ElectricDruid on September 29, 2020, 09:39:59 AM
Good work on the debugging. That seems to clear up a lot of things.

Quote from: patrick398 on September 29, 2020, 07:44:52 AM
But where the hell is that first pop coming from?

The pin is set up as "INPUT_PULLUP", isn't it? Does that set it up *both* as an input *and* with a pull-up? And the button is then connecting the pin to ground? No other possible short from the pin?

The only thing I can think of is that the button is yanking the power rail around somehow, probably by shorting something. Like might happen if the button input had the output driver still turned on and driving the pin high (which you wouldn't notice when you read it, since it's *supposed* to read high with the pull-up anyway).

Good shout. I did try putting a 1k resistor in between the switch and ground so that it's not connecting straight to ground but the result was the same. I should upload a schematic and maybe the layout too, i think it's pretty sound but maybe there's something in there i can't see

patrick398

Had some more time to fiddle with this, putting the PCB in an enclosure seems to make it a lot quieter. In terms of switching noise it's actually basically silent now, there's little to no relay noise. But when i press the switch there is a bit of crackling noise, not especially loud but it can be heard even when playing guitar so not ideal obviously. I'm stumped as to why this is happening though. Somehow some noise from the switch contacts is making its way into the audio path. I tried changing the switch but same issue. It's not being generated from the relay switching because i can hear it if i press the switch and wiggle it and it's there even before and after the relay flips. It kind of sounds like some DC is getting onto the audio path somewhere. Anything obvious come to mind? Or anybody had similar issues before?

Thanks