[sdiy] digital control of CV

[Tom Wiltshire]

On 4 Sep 2007, at 08:26, jure zitnik wrote:
>
> david: encoders have *low* resolution. a few tens of values per
> revolution. while they're useful for some things, they feel quite
> lousy for let's say cutoff control, try to imagine. 24 values per turn
> mean that either you'll have terrible stepping (if you want to cover
> the entire range in one turn) or that you'll have to spin the knob
> like crazy to get to the other end. i know some implement
> "intelligent" acceleration, that is if you turn the encoder faster,
> the steps will be bigger (i'm talking about software of course)... but
> it just doesn't feel as good as a pot.

After a previous thread and discussion with Edward King, I got an  
alphanumeric LCD display, a pot, a rotary encoder, and a PIC  
processor together to do some experiments.

With a pot connected to an A2D input, I was able to pick an exact  
value at 10-bit resolution. Eg: "I want 500!" twiddle, twiddle,  
nudge, nudge. You can get to any value in a few movements. 12-bit  
resolution was a bit too much, both because of increased AD jitter,  
and the difficulty of moving a pot with such accuracy. It is hard to  
set a pot at this resolution, and I wasn't able to reliably get to a  
particular value.

The rotary encoder was a 24-detent affair, like Jure mentions.  
Obviously single stepping through over a thousand values is possible  
but very slow. So then I started experimenting with measuring the  
time between detents, the rotational velocity, and incrementing the  
count proportionally (as suggested above). This was a disaster.  
Whilst the count goes up a lot if you turn fast, and slowly if you  
turn slowly, getting to any particular value is more or less  
impossible. I found I couldn't control or judge accurately how fast I  
had to turn to get a given increment. For example, if I want a value  
of 500, and the current value is 400, I need to turn at a speed that  
gives me an increment in the tens, say. How fast is that? I had no idea.
Obviously having the increment directly proportional to velocity  
wasn't getting me anywhere, so then I added a velocity curve table  
between the encoder and the increment, and experimented with various  
curves to try and improve the response. Again, no real success.  
Getting this software right is crucial, but difficult , it seems.

I'm sure this has to be possible, but I really didn't get any  
encouraging results. Does anyone know any nice commercial examples or  
has anyone tried this sort of experiment?

Regards,
Tom