ASM - Variable rate rotary encoder routine idea's

[augustinetez]

I'm looking for opinions on whether this is likely to work or not (flow chart below) please.

It is for a VFO (Variable Frequency Oscillator) which is AD9850 DDS based and the purpose is to increase the rate at which the frequency changes depending on how fast the encoder is turned.

The encoder is a proper optical 360 ppr one (not those horrible cheap mechanical things), geared down from the tuning knob (I'm waiting to find out the ratio).

The encoder is polled, not interupt driven - nothing happens in software until the encoder moves - so the current software just sits in a loop polling the encoder.

Currently, the change in how fast the frequency changes is done by a push button that selects 1 of 3 frequency step rates so I am thinking along the lines of counting how many steps/pulses there are from the encoder in a set time period and using this count in a comparison routine to automatically set the step rate.

This will be coded for a 16F1827 running at 32MHz (in Assembly ), I haven't started with any actual variable rate code yet, just toying with different ideas.

 

[danadak]

Thats how I would approach it, by sample rate with a frame of time and comparing it to the
prior frame measured.

You could also measure freq of encoder pulses I would think to establish a trend and use
that in a table lookup to set freq increment. I would average a few measurements to remove
human inconsistences.

Regards, Dana.

 

[Ian Rogers]

I use an encoder and I do not like to miss a pulse...

I use a tiny pic12 as a state machine, then I pass it onto another pic for processing
The lil pic runs at full whack just monitoring the pins.. Then a pulse with direction is passed to the biggy..

Of course you can do it all in one.. I use 4 bits.. two old and two new.
then the nibble is processed..
0000, 0101, 1010, 1111 no movement
0001, 0110, 1011, 1110 going one way.
0010, 0101, 1001, 1101 going the other.

Anything else is garbage so do nothing..

It works well for me..

 

[jpanhalt]

Interesting project. My first impression was to use capture and TMR1. Then just poll the TMR1IF without enabling the interrupt (assuming you are set on not using an interrupt). That would be similar to the common way of measuring duty cycle or frequency. However, since you also need to detect direction, it gets a little more complicated, but I believe is still easily doable.

The problem I see with your flow chart is how to stop an action. Let's say a rapid move to the right starts incrementian in MHz. Does one have to move at the same velocity to the left to stop it? Does is stay incrementing at a high rate until it is stopped or is it a one-shot burst? Spinning a knob could get tedious when making big changes. Having to stop it would also be tricky. Given the two options, I would go with a one-shot burst like flipping pages with a mouse.

You did not mention whether your encoder was absolute or incremental. I assume the latter, but if you can use an absolute encoder, then I would consider something like is used on model airplane transmitter controls called, "exponential." That is, the further the control stick is moved from center/zero the greater the control moves per degree of movement. That is, the amount of movement is proportional to position not acceleration or velocity of the encoder. That could also be done with a incremental encoder, but the zero position would keep moving.

The idea would be at or near center/zero, no change in VFO. as you get further from center, the rate of change would increase. That would be simple to program. As a side benefit, it would allow someone who doesn't have Vladimir Horowitz's speedy fingers to get the same result as someone who does. While on that subject, I suspect the 1 ms timer was just something to put down. In reality, I think you will need a much longer time for most people.

John

 

[augustinetez]

My first impression was to use capture and TMR1. Then just poll the TMR1IF without enabling the interrupt (assuming you are set on not using an interrupt). That would be similar to the common way of measuring duty cycle or frequency.

I've already got stuff happening in interrupts and I was thinking of using one of the Timers for this.

However, since you also need to detect direction, it gets a little more complicated, but I believe is still easily doable.

The polling routine already handles this, so should be OK.

The problem I see with your flow chart is how to stop an action. Let's say a rapid move to the right starts incrementian in MHz. Does one have to move at the same velocity to the left to stop it? Does is stay incrementing at a high rate until it is stopped or is it a one-shot burst? Spinning a knob could get tedious when making big changes.

It's a bit simpler than it looks - when the routine in the flow chart exits at the end of the time period, the count variable will hold a number.

This number is then compared to set points eg 10, 20 & 30 in another routine.
If the number is under 10, then step size = 10Hz
If the number is between 10 and 20, step size is = 1000Hz
If the number is over 20, then step size = 10kHz

Thus it 'auto-resets' to 10Hz until the next time it does a compare - the range of frequency is 5MHz to 5.5MHz so there isn't much spinning to do to get from one end to the other - think old school VFO's.

You did not mention whether your encoder was absolute or incremental.

Incremental quadrature like this (this one is 100 ppr)


Re the 1mS timer value, yes that is just a number to fill in the hole until I actually get some code written and have a play.

The two conflicting problems here are not slowing down the DDS update rate while getting a reasonable turn rate count.

Thanks Ian & Dana - point noted about the inconsistent turn rate - I'll start with a simple routine and modify if needed to check that.