Howdy, not quite sure how to ask this. What I am trying to achieve is like constrain but a little different. I would like to set a value, say 10, where any value read that is below 10 is changed to 0. I am getting some values of 2 or 3 when the potentiometer is moved quickly to the furthest position to off.
I want to ensure that anything below that delta of 10 is sent out as a 0 so it always sends an off value. I believe the delay function that I need to use may be adding to the problem if it's physically reading a 0 from the pot while inside the delay. (?)
Serial info goes to an XBee. The receiving XBee serial info is processed and a PWM LED will ghost if the las5t value seen is a 2 or 3 etc. along with a DAC. The sketch shows the use of constrain but the end result is still the same.
Thanks in advance for any simple ideas.
#include <SoftwareSerial.h>
SoftwareSerial mySerial(1, 0); // RX, TX
const int potPin = A1;
//Variables:
int potVal = 0;
int potValPrev = 0;
void setup() {
mySerial.begin(38400);
}
void loop() {
//Read the analog value from pot and store it to "value" variable
potVal = analogRead(potPin);
//Map the analog value to pwm value
potVal = constrain(potVal, 80, 1023); //????????? 80, 1023 for 802.
potVal = map (potVal, 80, 1023, 0, 255); // 80, 1023 for 802.
if (abs(potVal - potValPrev) > 2)
if (potVal != potValPrev) {
mySerial.print('<');
mySerial.print(potVal);
mySerial.println('>');
potValPrev = potVal;
mySerial.flush();
delay (6);
}
}
While it's inside the delay it's not reading anything from the pot, it's not doing anything at all, which is what delay does. Learn to code without using delay.
Yes, thank you. I am trying it now. I have raised the delta number value to 16 and it's gotten better. I need to keep the mapping in mind as well. I had convinced myself that it was going to be much more complex math.
Thank you. I am using millis on the receiving end of this so I am familiar with blink without delay. This is the entire code for this ATtiny 85 chip. There are no other functions being delayed by using this so I kind of just concentrated on the performance of the serial information being broadcast without overloading the serial buffer in the XBee's by adjusting the delay time.
I understand the potVal - potValPrev > 2 also reduces the number of integers being used.
Thanks for looking. I think I'm ok with having the resolution of this small area of the wiper being ignored. I will look at your second option.
The pots I use are quite good and I don't have a problem with any jitter beyond my current "magic number." I have used a higher number but I don't like how it feels when so many values are skipped while moving the pot.