I try to control the cutoff of the filter by an potentiometer with 10 k.
My question: is it normal, that the jitter is so big? For example: on the disp/dial b the numbers are quickly changing from 9.10 up to 9.9.
I tried to solder a 100nF Cap from the slider to gnd. But the jitter is still the same.
My cables are only 50 cm long.
With the drj/math/mov_avg it is better.
Do i have cheap pots?
Thanks for help.
do you have any other pots connected? try grounding nearby analog ins if not, it may make a difference. or are there pull-ups on the Axoloti?
Hi @arunarush,
you can try
noiseGPIO.axp (4.2 KB)
First, do "File -> sync Libraries" as I have updated my "kfilter/median " object (it works up to 37 taps).
Change the analog gpio in my patch to the one you use (PB1) and see if this works.
(you can post a snapshot).
This patch takes a gpio inputs and substracts its DC and amplifies it by 256 so that the scopes shows the noise component scaled x256 !
ive seen quite a bit of jitter on the axocontrol circuit too...
@SmashedTransistors is this from a pot you have attached?
it would be interesting to see different users results when configured the same, to get some idea of what is 'normal' noise, and what is abnormal (eg. due to circuit design/implementation)
(your median objects, takes a rolling median of N samples?)
i would first try to eliminate all possible noise before trying to minimise it by means of software. what power supply do you use? is the pot enclosure grounded? there are many things to take into account when dealing with low-level noise...
Yes. In my case, all the, 15 analog inputs are connected to 10k pots with wires ~20cm long. I added a 47uF cap between gnd and vda and a few 100nF caps. This reduced the noise.
I did not perfected shielding/grounding of enclosures nor used shielding audio wires as suggests @lokki , maybe, this could help. Now, for this project it's too late. I will certainly try that on my next Axoloti project.
Maybe it's not too late for @arunarush 
@arunarush, maybe you can post a snapshot of my patch running on your input so that we can see if it is different from mine.
I've read somewhere that the analog -> digital converters are based on switched capacitors and that the proximity of the converters may be accountable for part of this noise.
Yes.
The input sample is put in the list x[] (it replaces the older sample).
x[] is indexed by the sorted[] table. sorted[] is bubble sorted.
Note: The "gch" output is the "glitch" output corresponding to what have been removed.
Ok now here is my screenshot:
Its without caps and no shielding. I just connected all the gpios with pots, switches and leds. So all the gpios are connected to ground or over an resistor to vdda.
I have some jitter on every analog in. I will try to solder the caps near the pots.
It seems consistent with the noise I have.
I think that the noise amplitude is around 4 bits, we have a raw 8 bit accuracy instead of 12.
I'm quite interested with the improvements you will get with caps.
coming from analog guitar pedal soldering i can tell you that shielding i.e. an aluminium case (grounded) can make a huge difference when dealing with noise. also things like star form ground system can improve things
As this topic interests me, I had to run some tests. I get better noise/jitter suppression with an average filter than with a median filter. I tried average filter of length 64 and 128 and two stages of median filtering of length 37. Not knocking the median filter, it's a very handy object to have in the arsenal, but for this application a moving average seems to perform better with less memory usage and far less CPU usage. A longer median filter will perform better, but the CPU usage increases with length, as opposed to the constant time average filter.
noise_supression.axp (4.1 KB)
The median filter tend to jump to a new value when enough samples are consistent.
So, I think it is more efficient with spiky noise than white noise.
The averaging filter seem to work great with the GPIO noise.
One drawback of all software filtering is that they induce delay and/or slow response to changes.
I think it's OK for pots, but it would not be OK for realtime controllers.
@lokki, as you stated, it is better to have clean, shielded and "capped" hardware inputs. it would be great to have a snapshot of the noise you get.
Yes, there is the lag with these filters. There may be better methods. In a similar thread here (https://sebiik.github.io/community.axoloti.com.backup/t/object-that-passes-value-only-if-change-between-previous-number-is-more-than-x/2592), I posted about Andrew Simper's dynamic smoothing algorithm, purpose made for this application. Here's the write up by him;
http://cytomic.com/files/dsp/DynamicSmoothing.pdf6
It would be cool to see an object implementing this. Perhaps somebody wants to have a go at that?
as of now i have no Axoloti in a case or anything connected to the gpio's. my comments are purely based on findings with arduinos and general things i learned when designing guitar/bass effect pedals. it would very much surprise me if the Axoloti is different in this regard. i will post some samples here if i put one in a case 
For my current project it is too late... I used more glue than screws and i am not able to add caps nor shielded wire.
Hi,
my approach to dealing with this is 2 fold.
1) I am experimenting with putting a electolytic cap between the pot center and ground, this reduces the noise and givse a natural easing to the sweep, based on the value.
Currently i'm testing 22uF with good results.
2) If you look at midi, the value's range from 0-127. I created a custom gpio_in which reduces the accuracy with bitshifting.
Currently the value can be set from 0-127 to 0-1023. The code can be found on Github: https://github.com/krizroring/Axoloti_Custom_Libs
Greetings,
Kriz
