Debouncing Serial.Read

Hello:

Using the following code to read the button presses from a remote control. The codes from the remote control are interpreted by a decoder module which passes incoming byte(s) to the Arduino RX pin. Works fine except multiple presses of a button can call the same function multiple times which is something I don't want. I am wondering if there is a way of debouncing or flushing the serial.read

void loop() {
 

     while (Serial.available() > 0) {    // is a character available?
      incomingByte = Serial.read(); // get the character
        if (incomingByte != 0x20) {   // Throw out character header 32

         // Serial.println(incomingByte);
          if (incomingByte ==28)Power();
          if (incomingByte ==29) SetFan(LOW);
          if ( incomingByte ==16)SetFan(HIGH);
          if (incomingByte ==17 )DisplayOnOff();
          if (incomingByte ==25 )IncDecSetPoint();
         }

      } 
     
}

Serial.read() can NOT possibly bounce. Bouncing is a physical characteristic of mechanical switches.

Flushing the serial buffer is possible. Just read and discard the data.

That's a stupid idea, though. How will you know that any given input represents a valid new packet to be acted on, vs. one to be discarded?

You can use millis() to ignore the messages in the serial line during a certain time.

luisilva:
You can use millis() to ignore the messages in the serial line during a certain time.

However, during this time, characters will accumulate in the buffer.

aarg:
However, during this time, characters will accumulate in the buffer.

Then you can read it and do nothing with it or you can use flush.

luisilva:
Then you can read it and do nothing with it or you can use flush.

flush is for output, no?

Yes flush is only on the output.

Mark

aarg:
flush is for output, no?

Yes, you’re right.
https://www.arduino.cc/en/Serial/Flush

@Bryanpl, are you referring to the phenomenon that some IR remotes have keys that send repeatedly if the button is held down?

aarg:
@Bryanpl, are you referring to the phenomenon that some IR remotes have keys that send repeatedly if the button is held down?

Correct, if the remote button is pressed and held it will send repeatedly. I only want the code to act on one press otherwise flush, discard everything else from the remote until the particular function is finished.

PaulS:
Serial.read() can NOT possibly bounce. Bouncing is a physical characteristic of mechanical switches.

Yes poor choice of words, What I want to do throw away any subsequent serial data received from the remote AFTER a button on the remote is pushed, so that rapid re clicks or if the remote button is held doesn't continually loop through the functions. Brute force I suppose is to use serial.end () and restart serial once the function is finished.

In serial input basics I have included a bit of code that can be used to empty the serial input buffer

However it may be more reliable to use one the examples to read all the data and analyze what was received before deciding what should be discarded.

...R

What I want to do throw away any subsequent serial data received from the remote AFTER a button on the remote is pushed, so that rapid re clicks or if the remote button is held doesn't continually loop through the functions. Brute force I suppose is to use serial.end () and restart serial once the function is finished.

How will you determine that a byte represents new data and is to be retained vs. representing a duplicate code that is to be discarded?

The usual approach is to read ALL data as though it was good. Then, compare the current packet to the last packet processed. If not the same, process this packet. If they are the same AND the time between two events is small, discard the packet.

PaulS:
Serial.read() can NOT possibly bounce. Bouncing is a physical characteristic of mechanical switches.

We can all read; capitalising words is not required.

There's no need for your angst on this forum - stop being a grumpy old fart.

sbaratheon:
We can all read; capitalising words is not required.

In this case I believe it was.

It was at the tip of my fingers to type the same thing but Paul beat me to it.

...R

stop being a grumpy old fart.

Not likely to happen.

PaulS:
How will you determine that a byte represents new data and is to be retained vs. representing a duplicate code that is to be discarded?

The usual approach is to read ALL data as though it was good. Then, compare the current packet to the last packet processed. If not the same, process this packet. If they are the same AND the time between two events is small, discard the packet.

Thanks, that gives me some ideas.