How to map 10-bit ADC value to a range with restrictions
This is 'hypothesis testing in the presence of noise'. 

When we are hypothesis testing, we define a pair of conditions we want to discriminate between, then define a test to best do that.

You have defined a condition 'is stationary', and a test |(current_avg - previous_avg)| &lt; delta. Implicit in that definition is another two conditions, moving up and moving down.

While the definition of 'is stationary' is not well defined, if we reverse engineer the test you've devised to find out what that really means, the change in average position taken between the first 1000 and the next 1000 of a 2000 long sample of positions, we find it's quite a reasonable thing to do.

The average of 1000 samples is the best way to compute an average position, if we assume the noise on each sample is independent. It's also quick, uses low resources, is easy to understand, and uses low memory (does not need to store all the inputs).

The difference between the first and second set gives you the best estimate of the mean speed of the pot over that time.

Now consider this test case. For the first 1000 samples, the pot is slewing quickly up, for the next 1000 it's slewing quickly down. The mean movement over that period, as computed by your estimator, will be zero. 

Are you happy that this condition would be detected as stationary? If no, then we have to change our definition of stationary. According to your comment, you are not happy with something. But what?

As you see, the problem is not with the test itself, but with (a) your poor definition of what 'stationary' means and (b) your poor definition of what you find unsatisfactory about the performance of the present test.

The test you have defined is the most reasonable test there is for detecting average velocity in the presence of noise. Whether this works well with your real world physics and user behaviour is another matter.

If you find you actually need to detect acceleration, to make it better in your case, then it's quite easy to take three successive averaged samples, compute both deltas, then compute the delta-delta.

If you find that a change of average size, to change the rate at which it can detect changes, works better, then do that. 

There are other alternatives that test different hypotheses. The first would be to compute two running means with different time constants. This is a common filter to use as an edge detector in image processing, but will also detect 'edges' in one dimensional data. As the filters are recursive, this is quite cheap to implement. However, you would have to tune the two time constants to your situation, so how would you get it tuned better than the one time constant of your present tester?

The second is to do a FFT of your samples. You can then compare the energy in the DC bin (amount of stationary) with the energy in the low frequency bins (amount of movement, acceleration, change of acceleration ... ) while discarding the energy in the high frequency bins (reading noise). But that needs significant memory and processing power, and seems like overkill.

A third, based on your comment about latency being the problem, would be to simultaneously estimate the position and the slope of the line by linear regression. There is a recursive formula for this, so it's relatively efficient for you to compute in real time with no more memory. This would allow you to 'correct' for the delay in collecting the data by extrapolating both estimates forward to get the averaged position 'now'. Note that linear regression can have dynamic range problems if done for large data sets, and as you're using integer arithmetic, you'd have to think carefully about implementation. One way to improve things would be to decimate, and run linear regression at a much lower sample rate, more consistent with the speed that your real world pot is being moved, and the response time you want the program to have.