AUX Inputs are Sensitive to extraneous triggers

Our application uses a momentary contact push button connected to AUX2 on the Notecarrier F board to wake up our ESP32 Feather board and take an on-demand reading. We are getting extraneous wake ups or triggers when touch the case, or just approach our case without touching it.

The momentary contact push button is connected between AUX2 and GND on the Note Carrier F.

Any suggestions on how to wire the switch into AUX2 to prevent the extraneous triggers?

Here is the code for configuring the aux inputs:

        J *req = NoteNewRequest("card.aux");
        JAddStringToObject(req, "mode", "gpio");
        J *pins = JAddArrayToObject(req, "usage");
        JAddItemToArray(pins, JCreateString("off"));   // AUX1
        JAddItemToArray(pins, JCreateString("input-pullup"));   // AUX2
        JAddItemToArray(pins, JCreateString("off"));  // AUX3
        JAddItemToArray(pins, JCreateString("off")); // AUX4
        JAddBoolToObject(req, "sync", true);
        JAddStringToObject(req, "file", "statechange.qo");

The code we use to put the notecard/board to sleep:

        J * req = NoteNewCommand("card.attn");
        JAddStringToObject(req, "mode", "sleep,auxgpio");
        JAddNumberToObject(req, "seconds", seconds);

This may be related to these topics on the support board:

Question about the notecard carrier design

Best Method for Receiving Periodic Counter Values

Great details on the hardware and code! The wiring sounds fine, but I still have a couple of additional questions for you.

  1. What firmware are you running on the Notecard?
  2. How many seconds is seconds, in the code above?

I have actually built a similar application myself, but I did it just a bit differently.

  1. I used count-pullup to set the interrupt on card.aux,gpio.
    input-pullup is simply an input with a pull-up, not an interrupt. Using count-pullup will enable the interrupt functionality
  2. I added rearm to the list of mode parameters, on card.attn, but I’m not certain that is necessary since you are using sleep.

#1 is your main problem at this point, but also the firmware must be sufficiently recent to support it.

1 Like

Zach, Thanks for the quick response.

  1. We are running LTS v4.1.1 on production releases, and v3.5.1 on my development devices. I know we have to have the correct firmware, because if I don’t update the firmware, the wake button doesn’t work at all (most of the notecards shipped to us are running v3.2.1 or earlier.

  2. Seconds in the code is usually 3600 (one hour).

I will try using count-pullup instead of input-pullup and see if that makes any difference.

Thanks again,

1 Like


I ran two of our devices for the past week, one with input-pullup and one with count-pullup settings in the code.

I don’t see any difference in the number of extraneous triggers.

Any other suggestions?


Hi Karl,

Can you share a picture of your device? It may shed some light on bad assumptions I’ve made regarding your hardware configuration.

Once I better understand what you’re working with, then I can better diagnose and offer better solutions.



Here is a picture of our device:

The top is all the circuitry in the box with the cover removed. This unit uses RS-485 to talk to our sensors.

The bottom is our mounting plate and the notecarrierF board, showing the three wires (black - GND, yellow - AUX2, and Red - F_D9). We are using a momentary contact SPST switch with internal LED. I get the same response whether I use an pushbutton switch with an LED or without an LED.


Hey Karl,

Cool Gizmo!

I’m not familiar with the button in the picture, although it looks very cool. Can you share a link to the datasheet, or where it was purchased from?

Am I right to think that F_D9 is powering the LED on the button? Also, have you measured that pressing the button is pulling the AUX2 to GND (and not to F_D9) and it floats otherwise?

Finally, nothing appears to be soldered, and I can’t tell how snug the wires are tightened to the board. This makes me curious if you are catching a short with the interrupt on the AUX pins.

I can offer a workaround, not the solution. It would be worth putting a capacitor on the lines near your button to provide a hardware debounce, this would ensure you are definitely getting clean signals.

Also, this may be seen as good or bad news, but I use the AUX pins in a very similar way as you do in a product of my own creation. Fortunately, they have been quite reliable for me. I’m not trying to dismiss your trouble, only trying to provide hope that this will work as intended once we figure out what is causing this spurious signal.



The pushbutton is from CIT Relay and Switch ( we purchased from Digi Key.

We are pulling AUX2 to GND and AUX2 is high otherwise, since it is configured at input_pullup or count_pullup. I tried a capacitor and it didn’t make a difference.

It’s good to know what you’ve successfully used the AUX inputs the same way without any problem. Our office is at 7000 feet here in Colorado and we have very low humidity. That may be the biggest contributor to the problem, a high input impedance on AUX2 coupled with low humidity easily generates the ESD to trip the AUX input.

Thanks for all the help. I appreciate it.



I was thinking about it overnight. Since you’ve got such a clean hardware abstraction for the button, have you tried a different button (as in completely different form factor)? Maybe you could just breadboard (or dead bug) a simple momentary button.

Also, does it happen frequently enough that you can put an oscilloscope on the line and catch it in the act? It would be good to see how it’s behaving, voltage wise (e.g. sagging voltage, pure chaos, etc…).

Finally, there is a new version of the LTS (4.2.1), I don’t think it will resolve your issue, but please upgrade to that to eliminate the possibility of encountering a one-off regression.