How to configure an Arduino GPIO as an input

Try a small capacitor ( 10nF ) in parallel to the resistor. This is called de-bouncing an input.

Can also be done in software, there might even Arduino libraries for that.

- W.

It sounds like you are getting cross-talk as well as switch bouncing.

If you put a resistor in series with the switch and a capacitor at the digital input as wolfgangfriedrich mentioned, there won't be any sudden changes in voltage, which will reduce any coupling between signals and significantly smooth out any bouncing.

Thanks DW. I understand the goal of de-bounce. I haven't had to use the technique with Pi's and for the most part with the Arduino. I'm thinking it has to do with motors and relays I have started to deploy. I see on the Arduino site there is a de-bounce sketch to eliminate the issue.

I will give both solutions a try. I'm looking for consistent. Maybe the component is best.

Hi colporteur

The best option is to of course go for both hardware and software debouncing. Hardware debouncing can be done easily as mentioned already by wolfgangfriedrich , as for the software debouncing here is a simple piece of code which could help:

#define debounceDelay 100


int lastButtonState = 0;
int lastDebounceTime = 0;
int buttonState;




void setup() {


  pinMode(BUTTON_CENTER, INPUT);
  
}




void loop(){


  int reading = digitalRead(BUTTON_CENTER);
    if (reading != lastButtonState) {
      // reset the debouncing timer
      lastDebounceTime = millis();
    }
    if ((millis() - lastDebounceTime) > debounceDelay) {
      if (reading != buttonState) {
        buttonState = reading;
        if (buttonState == HIGH) {
          //Here you will know that the button was pressed
        }
      }
    }
    lastButtonState = reading;
  
  }

     I've found that this approach works great, and it's using millis instead of delay so there isn't any code flow blocking. I've put the debounce delay to 100ms in the code, but you can tweak it to your liking. I found it works great like this, though, maybe a touch slower. For how this code works, when we detect a button reading which was different from the last button reading we just remember at what point that occurred. If we keep the buttons pressed long enough (100ms in our case), lastDebounceTime won't change and our second if statement will be fulfilled. Once the buttons was On for 100ms at least, it still won't register the press until you release the button. Hope this helps you!

Milos

Thanks MR, I saw a code example https://www.arduino.cc/en/Tutorial/BuiltInExamples/Debounce  and wondered about the delay value.

I'm a code resurrectionist and not an programmer, so I tend to default to hardware for solution. Your code is slightly different than what I found. What advantage is

1. #define debounceDelay 100

verses unsigned long debounceDelay = 50;    // the debounce time; increase if the output flickers

100K and 47K are very weak pull-down (or up) resistors. If you're in a known noisy environment, you probably want something in the 1K to 4.7K range.

... and if you can afford it in your design, polling is more forgiving than triggering.

Triggers are excellent for digital signals. For mechanical switches they are problematic by design.

If you want to fully debounce a switch in hardware it is easy to achieve 100% instantaneous debouncing if you use a double throw switch. You don't need any other hardware if you feed 2 digital inputs from the the switch, but you can use a couple of inverters or NAND gates if you want to do it all in hardware.

Hi Sean,

I'd do the same as James mentions, heavily reduce the 47k resistor. Also, you could check with your 'scope if you're picking up electrical noise, since it's highly likely with model railroad that you've got mains wiring nearby, on the floor, for example mains cables and power supplies. Twisted pair might not be very effective for electric field based noise, coax would be better.

Also, it doesn't help that the threshold for logic high is quite low, perhaps just a fraction of a volt (with some 3.3V logic families, or a bit higher for 5V). There are more elaborate circuits for inputs, that could involve using a transistor and resistors arranged to switch at a higher threshold (e.g. several volts to be a logic '1'). In other words, behave more like (say) RS232 levels instead of 5V CMOS etc. Also, although technical overkill, the simplest way could just be to use an optocoupler if you just wanted a simple quick-to-build (but more expensive) life.

None of this addresses debouncing, but the methods mentioned by everyone above would work (or just do it in software). There are nice ways to combine hardware and software to have a hybrid approach, but that increases software development time and hardware time. But would be very rugged options. One hybrid approach is to use an I2C I/O expander. They have an interrupt pin. You can trigger on interrupt, and then read the inputs. Apart from the fact that it needs the I2C library, it actually simplifies the software structure since there's no need to do polling.

This suggestion is a first for me. I have seen typically 10K pullup or pulldown but not 4.7K or as low as 1K.

I used a 7ft piece of CAT6e to wire a  button panel to a distribution frame. One conductor provides 5VDC to all the buttons with the seven remaining wires individually connected to a button. The two spurious Nano's were each sharing one conduct from the same pair. I separated them to different pairs and haven't seen the problem.

The twists in the CAT6e cable pairs are pretty intense. I had worked with CAT5 but was taken aback at the construction of the CAT6e. I am using the cable as a cross connect wire which is not as it was designed for. I suspect the intense twists can't but help cross talk.

I like the resistor suggestion because of the simplicity. I will move the simulations to the same pairs again and try the lower resistor value to see what affect it has.