Your new topic does not fit any of the above??? Check first. Then post here. Thanks.

Moderator: igrr

User avatar
By alex_g
#67039
QuickFix wrote:Do you really have to use a software solution?
I'd rather solve the problem at the root and debounce the switching circuit itself (but hey: I'm originally an electronics guy). ;)

http://www.ganssle.com/debouncing.htm


Well, yes and no.

For the sake of practicality, I will certainly end up adding a physical circuit as well, especially when the thing is ready to be deployed. Thanks very much for the link. (Nice read, just what I was looking for)

For the sake of understanding Arduino (and ESP8266 in general - I see Lua users with similar problems), I definitely want a software solution that works acceptably well, at least less than 0.1% error, < 0.01% even better!

===

I am really intrigued why my code (latest below) is working so poorly - sometimes not at all. I suspect some sort of asynchronous functioning for the interrupt functions, but even adding a global flag to simulate mutex does not help.

Code: Select all/
/ ********* Send a 433 MHz signal  ***********************
// **** by triggering an interrupt on a pin ***************

const byte ledPin = 16;
const byte interruptPin = 4;
volatile long lastDebounceTime = 0;
const int debounceDelay = 500;
volatile boolean blockOthers = false;

#include <RCSwitch.h>
RCSwitch mySwitch = RCSwitch();

void setup() { 
  pinMode(ledPin, OUTPUT);
  digitalWrite(ledPin,LOW);  // HIGH by default
   
  pinMode(interruptPin, INPUT_PULLUP);
  // attachInterrupt(interruptPin, stoptx, RISING);
  attachInterrupt(interruptPin, transmit, FALLING);

  // Transmitter is connected to Arduino Pin #D5 (GPIO14) 
  mySwitch.enableTransmit(14);
}

void loop() {
  /*
  boolean pressed = !digitalRead(4);
  if(pressed){
    digitalWrite(ledPin,HIGH);
  } else {
    digitalWrite(ledPin,LOW);
  }
  */
}

void transmit() { 
  if (blockOthers) return;
  blockOthers=true;
 
  // Check to see if the change is within a debounce delay threshold.
  boolean debounce = ((millis() - lastDebounceTime) <= debounceDelay);

  // This update to the last debounce check is necessary regardless of debounce state.
  lastDebounceTime = millis();

 
  // Ignore reads within a debounce delay threshold.
  if(debounce) {
    blockOthers = false;
    return;
    }

  mySwitch.sendTriState("00000FFF0FFF");  // = 5397
  // mySwitch.send(5397, 24);

  blockOthers = false;
}

void stoptx() {
  mySwitch.send(5396, 24);
}
User avatar
By alex_g
#67074 A, ha!

Well, after some headscratching, I put an incremental signal code to be transmitted,
> mySwitch.send(++signal433, 24);

and the results were illuminating enough to indicate that debouncing is probably not the main problem, at least not the way I initially thought....

Here's a sample session.
Note that all the double sends have the same code, which makes me think that the problem is due to the transmitter sending duplicates, rather than any debouncing problems. Ho-hum, now to find someone knowledgeable with rc-switch...

Code: Select allunknown = (5000001) Tue Jun 13 01:24:15 BST 2017
unknown = (5000002) Tue Jun 13 01:24:17 BST 2017
unknown = (5000002) Tue Jun 13 01:24:17 BST 2017
unknown = (5000003) Tue Jun 13 01:24:19 BST 2017
unknown = (5000003) Tue Jun 13 01:24:19 BST 2017
unknown = (5000004) Tue Jun 13 01:24:21 BST 2017
unknown = (5000005) Tue Jun 13 01:24:23 BST 2017
unknown = (5000006) Tue Jun 13 01:24:30 BST 2017
unknown = (5000007) Tue Jun 13 01:24:31 BST 2017
unknown = (5000008) Tue Jun 13 01:24:33 BST 2017
unknown = (5000009) Tue Jun 13 01:24:42 BST 2017
unknown = (5000009) Tue Jun 13 01:24:43 BST 2017
unknown = (5000010) Tue Jun 13 01:24:44 BST 2017
unknown = (5000010) Tue Jun 13 01:24:44 BST 2017
unknown = (5000011) Tue Jun 13 01:24:45 BST 2017
unknown = (5000012) Tue Jun 13 01:24:46 BST 2017
unknown = (5000013) Tue Jun 13 01:24:47 BST 2017
unknown = (5000013) Tue Jun 13 01:24:47 BST 2017
unknown = (5000014) Tue Jun 13 01:24:49 BST 2017
unknown = (5000015) Tue Jun 13 01:24:50 BST 2017
unknown = (5000016) Tue Jun 13 01:24:51 BST 2017
unknown = (5000017) Tue Jun 13 01:24:52 BST 2017
unknown = (5000018) Tue Jun 13 01:24:54 BST 2017
unknown = (5000018) Tue Jun 13 01:24:54 BST 2017
unknown = (5000019) Tue Jun 13 01:24:55 BST 2017
unknown = (5000020) Tue Jun 13 01:24:57 BST 2017


At least I can deal with (i.e. bodge) this at the MQTT client end!
User avatar
By schufti
#67085 Hi,
from my expirience I see two points for trouble:

1) turn off (at least modem sleep) wifi if you don't need it.

2) your interrupt service routine seems to long (time consuming) to me
it is good practise on arduino esp8266 to only set flags in isr and act to it in main loop.

bear also in mind that a simple main loop can be run several times during the same millis() count on an esp8266!
User avatar
By alex_g
#67093 Thanks for the tips schufti.
As a complete noob to the Arduino ways of the world, any "style guide" tips are really appreciated!
Both are taken on board. I will rework it as you say, and see if that improves things (I'll also try it on Lua) although I pretty much expect to be visiting the rc github site at some point ;)

Good idea about the WiFi, since my app doesn't use it at all, at present. I didn't realise it was on if I didn't invoke it. Later on I'll be using it to add codes to the system remotely, but it's good to know it can be switched off when not in use.

====


PS. I removed ALL debounce code and it works just the same! Seems there wasn't any debounce problem at all with the cheap pushbutton switch. Either that, or ESP8266 handles it quite well on its own.
I'm impressed. Headache gone.

The problem seems to lie with RCSwitch, which just transmits twice whenever it feels like it.

PPS. Yup, the problem lies definitely with the RCSwitch code, I poked around a bit and managed to get it working, by using setRepeatTransmit(int n). Bizarrely it works right if you set it to 4 or 5. Won't work at all if set to 0, 1, 2 or 3. I'm definitely going to have to read that lot to see what's going on. Interesting code.

Thanks everybody.