Bogus function call

Projects Programming
1

Alright, so I have a code snippet that recognises a couple knock on a piece of wood and when it does it lights up a neopixel LED strip. Problem is, as soon as the double tap has been recognised, there seems to be a problem with the sensor, as it keeps repeating the LED light-up part. When I comment out the neopixel snippet, and try simply serial printing, it works just fine.

Code below:

#include <Adafruit_NeoPixel.h>

#define sensorPin A0
#define wake_knockTime 100

#define threshold 3
#define knockFadeTime 150

#define PIN 6
#define numPixels 15

#define col 100
#define animate 10

unsigned long wakeStamp;
uint16_t sensorValue;
bool knockedOnce = 0;

Adafruit_NeoPixel strip = Adafruit_NeoPixel(numPixels, PIN, NEO_GRB + NEO_KHZ800);

void setup() {
  strip.begin();
  strip.show();
  Serial.begin(9600);
}

void loop() {
  sensorValue = analogRead(A0);

  if (millis() - wakeStamp >= wake_knockTime) knockedOnce = 0;

  if (sensorValue >= threshold) {
    knockDelay();
    if (knockedOnce) {
      knockedOnce = 0;
      wakeUp();
    }
    else {
      wakeStamp = millis();
      knockedOnce = 1;
    }
  }
}

void knockDelay() {
  uint8_t iterations = (knockFadeTime / 20);
  for (uint8_t i = 0; i < iterations; i++) {
    delay(10);
    analogRead(sensorPin);
    delay(10);
  }
}

void wakeUp() {
  Serial.println("AWAKE!!");
  //*
  for (uint8_t i = 0; i < numPixels; i++) {
    for (uint8_t j = 0; j < col; j += col / animate) {
      strip.setPixelColor(i, j, j, j);
      strip.show();
      delay(animate);
    }
  }
  //*/
}
2

What do you mean by it keeps doing the lighting up part? What do you expect it to do and what is it not doing?

3

For starters, stop 'calling strip.show()' on EVERY iteration of your nest 'for' loops. Move that call and the 'delay(animate)' between the 2 loops so that is called ONCE every time the inner loop completes.

4

Qdeathstar:
What do you expect it to do and what is it not doing?

It's supposed to run the light-up function once when two knocks have been registered. Through Serial readings I see that for some reason when returning to the loop the knock sensor gives readings without any knocking, and so consequently it keeps registering knocks, and keeps calling the light-up function. What weirds me out is that it doesn't behave like that when I comment out the neopixel snippet and run Serial print.

gfvalvo:
For starters, stop 'calling strip.show()' on EVERY iteration of your nest 'for' loops. Move that call and the 'delay(animate)' between the 2 loops so that is called ONCE every time the inner loop completes.

I call both the delay(animate) and the strip.show() to ensure more of a dimming effect per pixel, instead of having each of them going from 0 to full-on. Why would that be a problem, though? From Serial reads it seems the sensor is the problem, the light up function works and finishes just fine.

5

A threshold of 3 for your analogRead values seems to be very small. If you print your sensorValues out to serial, you could use Tools->Serial plotter to display a chart of them and see how they look over time.

What's the rationale for the analogRead in knockDelay?

BTW, the point of the bool type is to be able to use the helpful identifiers true and false instead of anonymous numbers.

6

flaggermann:
I call both the delay(animate) and the strip.show() to ensure more of a dimming effect per pixel, instead of having each of them going from 0 to full-on. Why would that be a problem, though?

OK, if your desired effect is to run the brightness change from 0 to 100 one pixel at a time before moving on to the next pixel. Then what you have will do it. If you want all pixels to fade up at the same time, then interchange the two loops and put the call to the show() method between them.

7

arduarn:
A threshold of 3 for your analogRead values seems to be very small. If you print your sensorValues out to serial, you could use Tools->Serial plotter to display a chart of them and see how they look over time.

I tried experimenting with the threshold quite a bit, but still, even when upping the threshold to the point of pretty much banging on the lid till my knuckles were sore it didn't do much difference

arduarn:
What's the rationale for the analogRead in knockDelay?

To be honest, I tried a couple of different codes, and this one, that I got as a part of a longer code from Adafruit seemed to do the best, so I can't really answer that.

arduarn:
BTW, the point of the bool type is to be able to use the helpful identifiers true and false instead of anonymous numbers.

Isn't using bool = 0 and bool = 1 the same as bool = false and bool = true? I mean the bool can only be 1 and 0, aka true and false, or am I completely mistaken?

8

flaggermann:
I tried experimenting with the threshold quite a bit, but still, even when upping the threshold to the point of pretty much banging on the lid till my knuckles were sore it didn't do much difference

Print the sensorValues to serial and see what you are getting with and without the NeoPixel enabled. Then you should be able to get a good idea of what threshold is reasonable, or discover if you maybe need to improve your circuit. You may even need to average the signal over a short period of time to smooth any noise.

flaggermann:
To be honest, I tried a couple of different codes, and this one, that I got as a part of a longer code from Adafruit seemed to do the best, so I can't really answer that.

In that case, I would just scrap knockDelay for a simple delay(knockFadeTime). Less code - less errors.

flaggermann:
Isn't using bool = 0 and bool = 1 the same as bool = false and bool = true? I mean the bool can only be 1 and 0, aka true and false, or am I completely mistaken?

What's good for the compiler is not necessarily what's good for the developer. Using true and false makes it immediately obvious that it is a boolean variable and not some other numeric type; it also sets an expectation about what should be in the variable. That's good for people here trying to help you, but also for you in 3 months time when you might look back at the code and have to understand it again. Ok, for such a small sketch it is not so critical, but good habits and all that.

9

arduarn:
What's good for the compiler is not necessarily what's good for the developer. Using true and false makes it immediately obvious that it is a boolean variable and not some other numeric type; it also sets an expectation about what should be in the variable. That's good for people here trying to help you, but also for you in 3 months time when you might look back at the code and have to understand it again. Ok, for such a small sketch it is not so critical, but good habits and all that.

That's a good point. I've just kinda always been using 0 and 1, so it's more a habit than anything else. I'll remember it next time though.

As for everything else, I tried both removing the knockDelay() and experimenting with the threshold. The noise from the neopixels pretty much always matches the knock. It did help some to up the resistor value (I was initially using a 1M Ohms pull-down resistor, and changed it to a 10M), but ultimately, what did the trick was to change the analog reference to the 3,3 V pin. That cleared out any noise!

Thank you so much for all input and help!