-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Teensy 3.2 issue #27
Comments
This is very weird. It would be nice if the problem could be tested in a reproducible way, which is difficult if a pot is involved. I would suggest performing a test that does not depend on external hardware. Could you try running the sketch below on your Teensy? #include <ResponsiveAnalogRead.h>
ResponsiveAnalogRead analog(A0, true);
void setup() {
Serial.begin(9600);
}
void loop() {
analog.update(random(480, 544));
Serial.print(analog.getRawValue());
Serial.print("\t");
Serial.println(analog.getValue());
delay(20);
} Does it show the excessive jitter you experienced previously? If so, could you share here the program's output? |
No probs - when run it's just a random stream around the values you specified. Like: 18:51:27.058 -> 509 522 |
I modified my test program in order to feed the filter with the exact same inputs as you: #include <ResponsiveAnalogRead.h>
int inputs[] = {
509, 539, 532, 521, 502, 496, 490, 533, 484, 527, 502, 481, 535,
488, 533, 482, 512, 496, 492, 500, 522, 514, 514, 537, 542, 533,
510, 482, 539, 529, 536, 541, 540, 542, 483, 516, 491, 539, 539,
538, 512, 503, 528, 495, 533, 511, 523, 533, 500, 540, 526, 494,
521, 488, 539
};
const size_t INPUT_COUNT = sizeof inputs / sizeof inputs[0];
ResponsiveAnalogRead analog(A0, true);
void setup() {
Serial.begin(9600);
}
void loop() {
static size_t i;
analog.update(inputs[i++]);
Serial.print(analog.getRawValue());
Serial.print("\t");
Serial.println(analog.getValue());
delay(20);
if (i == INPUT_COUNT)
exit(0);
} I get slightly different outputs at the beginning of the run:
but then, starting from the 12th point, the outputs are identical. In both cases the output looks like a somewhat smoothed version of the input. I see nothing that looks like “crazy jitter”, only expected behavior. It would then seem that a pseudo-random input doesn't trigger the problem. Do you think you can provide a sequence of input numbers that, when fed to the filter, generates an output displaying the weird jitter you are experiencing? |
Yup, very odd - I dont have the chops to be able to speculate on it myself though, and not enough time to dig into it deeper! But anyway here is a section of the jitter using a pot (a few small moves, then in and out of the jitter region twice): 23:54:03.710 -> Analogue read:433 Rawvalue:433 Filtered:429 Looking at it again now, it looks like I was wrong and the analogueRead is mostly stable - but not always, just occasionally going outside the norm. I also note that adding 20 seems to be a favourite - on some runs, almost all the extra is 20. Very bizzarro. And this the code I was using (note does the same if I am not taking an analogueRead): #include <ResponsiveAnalogRead.h> int val; void setup() void loop() if(analog1.hasChanged()) { delay (50); |
There is a problem here: if(analog1.hasChanged()) { You are printing the data only when the library judges that the change in input is significant enough that it should be reflected on the output. We then don't see the real stream of data you are feeding to the filter, which makes it impossible to try to reproduce the problem.
What I do see is that the input makes jumps of 20. It is most clear in the section of the data from the 19th to the 215th data point, where the input fluctuates mostly between 555 and 535. As for the output, it just follows the input's fluctuations with a smaller amplitude. When the input drops to 535, the outputs starts going down. But then, the input rises again to 555, and the output responds by going up again: In my opinion this data set shows nothing wrong in the filter's behavior: this is exactly what you should expect from a smoothing filter. Your problem seems to be that the data you feed to the filter's input has an unusually high level of noise, with a weird bimodal density function. You could try to mitigate this problem by decreasing the “snap multiplier” in order to make the filter more aggressive. For example: // snapMultiplier defaults to 1e-2. Setting it to 3e-3 makes
// the filter more aggressive, but also somewhat more sluggish.
ResponsiveAnalogRead analog1(A0, true, 3e-3); which should result in only tiny fluctuations at the output, at the cost of some responsiveness. Alternatively, you could run a median filter upstream of ResponsiveAnalogRead. Median filters tend to be quite effective against the kind of “jumpy” noise you seem to have here. In any case, I would qualify this issue as invalid, as the problem lies in your data source, not in this filter's code. |
Your call, I was just raising it with you. But as I said, I made my own simple filter with exactly the same setup, and I see none of this jitter in the region shown. I average the current and last value, and the two values before that, and then check to see if jitter is greater than 2 between these two averages - which it never is unless I am moving the pot. My own version of ismoving is never erroneously flagged. Without your code, I can run a simple analogueread on its own, and this "high level of noise" is simply not present. |
Hi,
Just trying a very simple program to test the library on a teensy 3.2. It runs totally fine - apart from when in the range of around 480-560. The closer to the mid point I get, the more crazy it gets - continuous jitter up to 20 difference in value. I have tried it with two different pots (different makes), and I have also tested a simple analogue read program using exactly the setup, which it outputs normally (didnt have the filter lib included). I can run your filter library fine on an arduino nano though - no problems at all.
Very odd.
Not a big deal for me, as I've just made my own simple filter which is working fine, but flagging it up in case you feel like looking into it.
The text was updated successfully, but these errors were encountered: