Help with fifo_full error on Espruino Wifi

I’ve read the other posts about the fifo_full error. I get why it throws but I need help getting around it.
I’m trying to build a circuit very similar to the Espruino guide for setWatch on analog inputs using the lm393.
I have a very simple script and circuit. The circuit uses a potentiometer and LM393 comparator. I setWatch on the digital output of the LM393 with the repeat option set to false.
When the potentiometer is over 50% The value goes high and powers an led. The callback function passed to setWatch is called many times and I get the fifo_full error.
I want the pot crossing over the 50% threshold to call the callback once. I’ll be implementing something similar to the guide on the lm393 (as I stated)
What’s going wrong and how do I get around it?

I assume that you have a hum or open wire somewhere that makes your comparator act like a multi vibrator around the switching point.

You would need something like a Schmitt trigger with - configurable - hysteresis. You even may use your comparator with some added components to avoid the 'vibrating' - see https://daycounter.com/Calculators/Compa­rator-Hystereses-Calculator.phtml

Could you show the setup of the circuitry in a uploaded picture?

Here’s a photo of the board

1 Attachment

There are several questions to answer and steps to take:

• SW1: What's the debounce value you use in the options of the setWatch() ?
  
• HW1: What's the value of the potentiometer?
  
• HW2: LM393 has two comparators, ground the inputs of the second one (pin 5 and 6).
  
• HW3: Put a current limiting resistor in series with the red LED.
  
• HW4: Minimize the number of breadboard connections connections (feed from same rails only).
  
• HW5: Put a decoupling capacitor on GND and VCC pins of comparator (w/ shortest connections)
  
  

Your RED LED has a forward voltage of about 1.8...2.2v... and you run it on an open collector on 3.3V. Since you obviously get information back from your Espruino, it does not take the 3.3 power supply down to make Espruino brown out, but for sure it stresses the the 3.3V rail and the comparator output, which can deliver max 18mA (datasheet https://www.fairchildsemi.com/datasheets­/LM/LM2903.pdf). The comparator can obviously handle the short-cut to ground, but usually weak connections in the breadboard become the current limiters and with that all the points start to 'jump' around... and that's where I guess the 'vibration' comes from:

• Comparator switches on
  
• LED draws current
  
• Current changes voltages relevant to comparison
  
• Change in voltages relevant to comparison makes the comparator to switch off
  
• ...and so on...
  
  

I may be totally off, but that's what I would do for sure as first thing is HW3... w/ a 100..200 Ohm resistor in the loop. To check if the LED is the (only) culprit, just run the circuitry without the LED.

@allObjects is likely spot on - it'd be interesting to see if just removing the LED fixes it.

But just to add to this, if you have an input that really does fluctuate a massive amount, debounce and repeat:false probably won't help you much since by the time they take effect the event queue could be full of events already.

It's not at nice, but you could just 'poll' the input:

var n=0;
function poll() {
  var newn = E.clip(n+digitalRead(...)-0.5,-20,20);
  if (newn==-20 && n!=-20) ...;
  if (newn==20 && n!=20)  ...;
  n = newn;
}
setInterval(poll,5);

Although the best solution is to try and 'clean up' the input. In your case you could add hysteresis by putting a high value resistor from the output of the comparator back into one of the two inputs (doing it to one will make it oscillate even more, the other should really sort it out).