Searching \ for 'Encoder resolution?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/io/sensors.htm?key=encoder
Search entire site for: 'Encoder resolution?'.

Truncated match.
PICList Thread
'Encoder resolution?'
1997\03\03@234843 by Jeff 'n Kristen Kroll

flavicon
face
       I have been reading the PICLIST for about a month and have seen several
methods of doing quadrature decoding on a PIC. One method, the one in the
Microchip Applications Handbook suggests monitoring one channel and when it
changes check the other channel to determine direction. Doesn't this reduce
the resolution of the encoder by half?  This method would be great if it
didn't because the project I am working on, a six degree of freedom
trackball, needs to monitor three encoders, and the 16c65 chip I'm using
only has four interrupt on change pins. However I can't sacrifice
resolution.
       BTW, I just wanted to comment on how impressed I am at the helpfulness(?
)
of everyone on the PICLIST. Keep up the good work!

                                                       Jeff Kroll

1997\03\04@001048 by Jeff 'n Kristen Kroll

flavicon
face
       I have been reading the PICLIST for about a month and have seen several
methods of doing quadrature decoding on a PIC. One method, the one in the
Microchip Applications Handbook, suggests monitoring one channel and when
it
changes check the other channel to determine direction. Doesn't this reduce
the resolution of the encoder by half?  This method would be great if it
didn't because the project I am working on, a six degree of freedom
trackball, needs to monitor three encoders, and the 16c65 chip I'm using
only has four interrupt on change pins. However I can't sacrifice
resolution.
       BTW, I just wanted to comment on how impressed I am at the helpfulness(?
)
of everyone on the PICLIST. Keep up the good work!

                                                       Jeff Kroll

1997\03\04@005910 by Bob Blick

flavicon
face
Just poll the encoders. A trackball doesn't spin very fast, and it's
non-critical, so if it misses a count or two when busy, no big deal.
Pretend it's the mouse on a Macintosh :-)

I also hear that interrupt-on-change will miss interrupts. It's good for a
keyboard wakeup-from-sleep and not much else. Does Andrew Warren have
something on his "answers" page about this? I think so. If you read the
Microchip data sheets _very_carefully_ they actually say so, too.

-Bob

At 08:41 PM 3/3/97 -0800, you wrote:
>        I have been reading the PICLIST for about a month and have seen
several
>methods of doing quadrature decoding on a PIC. One method, the one in the
>Microchip Applications Handbook suggests monitoring one channel and when it
>changes check the other channel to determine direction. Doesn't this reduce
>the resolution of the encoder by half?  This method would be great if it
>didn't because the project I am working on, a six degree of freedom
>trackball, needs to monitor three encoders, and the 16c65 chip I'm using
>only has four interrupt on change pins. However I can't sacrifice
>resolution.
>        BTW, I just wanted to comment on how impressed I am at the
helpfulness(?)
>of everyone on the PICLIST. Keep up the good work!
>
>                                                        Jeff Kroll
>
>

http://www.bobblick.com/

1997\03\04@011444 by Steve Hardy

flavicon
face
> From: "Jeff 'n Kristen Kroll" <spam_OUTjkkrollTakeThisOuTspamJOSHUANET.COM>
>
>         I have been reading the PICLIST for about a month and have seen
several
{Quote hidden}

You can feed both quadrature inputs into an XOR gate and apply the
XOR gate output to the interrupt-on-change pin.  The output makes
a transition on each edge of either input.  You can look at the
XOR gate output and one of the 'raw' inputs to determine direction
info.

BTW, just in case you are under a misapprehension, one degree of
freedom counts both the forward and reverse directions as the
one DOF.  If you truly have a 6-DOF trackball, my mind is boggling
trying to imagine how one would drive such a beast, since you would
need X, Y and Z translation, plus pitch, roll and yaw! -- and 6
encoders, not 3.

Strap yourself in for a slight digression: did you know that you can
yaw (spin) a trackball using just pitch and roll?  To demonstrate
this, take a ball and sit it on a table.  Put your hand on the top of
the ball.  You can pitch the ball by moving your hand back and forth,
and you can roll it using side to side motion.  Now if you move your
hand in small circles, the ball yaws in the opposite direction to your
hand motion (albeit with some nutation).  Mathematicians will tell you
that this is a result of group theory, but I think it just works anyway
in spite of that lot...

Regards,
SJH
Canberra, Australia

1997\03\04@012048 by Andrew Warren

face
flavicon
face
Bob Blick <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU> wrote:

> I also hear that interrupt-on-change will miss interrupts. It's good
> for a keyboard wakeup-from-sleep and not much else.

   Yes, this is true for many of the 16Cxx parts... The newest ones
   have allegedly been fixed, but I haven't verified this.

> Does Andrew Warren have something on his "answers" page about this?
> I think so.

   Yeah, he does.  It's the answer to Question #88, in the
   "Microchip PIC" section of his "Answers" page.

> If you read the Microchip data sheets _very_carefully_ they
> actually say so, too.

   In the newest data books, you don't even have to read
   carefully... Microchip have been nice enough to put a shaded
   block around the applicable paragraph.

   -Andy

=== Andrew Warren - fastfwdspamKILLspamix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html

1997\03\04@022649 by Walter Banks

picon face
Jeff 'n Kristen Kroll wrote:
>
>         I have been reading the PICLIST for about a month and have seen
several
> methods of doing quadrature decoding on a PIC. One method, the one in the
> Microchip Applications Handbook suggests monitoring one channel and when it
> changes check the other channel to determine direction. Doesn't this reduce
> the resolution of the encoder by half?
Yes it does.

> This method would be great if it
> didn't because the project I am working on, a six degree of freedom
> trackball, needs to monitor three encoders, and the 16c65 chip I'm using
> only has four interrupt on change pins. However I can't sacrifice
> resolution.

Another way is to sample the port with a timer set to the fastest
expected quadrature speed it will have a lower interrupt overhead
and full resolution. The code on a PIC is quite abit shorter.

Walter Banks.

1997\03\04@030025 by John Dammeyer

flavicon
face
At 02:08 AM 04/03/1997 -0500, you wrote:
{Quote hidden}

That is somewhat similar to what I did more than a decade ago.  I used a
couple of one-shots that were re-triggered by the encoder edges.  Along with
a flip flop or two it prevented the false triggering as the encoder vibrated
back and forth around one edge.  As I recall the time period of the oneshot
was set to less than the maximum encoder rate.  The idea came out of EDN (I
think).  This was in late 1983.  I really do wish I still had that circuit.

Cheers,

John
Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc.      Ph. 1-250-544-4950
PO Box 20002                  Fax 1-250-544-4954
Sidney, BC CANADA V8L 5C9

1997\03\04@095520 by Andy Kunz

flavicon
face
At 08:41 PM 3/3/97 -0800, you wrote:

I did an encoder thingy by polling at high speed, keeping the previous value
read in in RAM, then XORing to find the deltas (a delta appears as a 1 bit).

You just need to poll fast enough to catch all the changes at the speed you
expect to move.

Kinda like below:

OldEnc  ds      1               ; Holds previous value read from encoder
NewEnc  ds      1               ; Holds current value
Deltas  ds      1               ; Holds deltas
EncPort equ     RB

ChkEnc  movf    EncPort,W
       movwf   NewEnc
       xorwf   OldEnc,W
       movwf   Deltas          ; A "1" signifies a changed bit
       btfsc   Z
       goto    ChkEnc          ; No changes, so loop, or go back to main
program
DoChg   ...                     ; Process each bit change manually


Andy




==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\03\04@234654 by Jeff 'n Kristen Kroll

flavicon
face
----------
{Quote hidden}

       Actually what I am working on is a 6DOF trackball. A coupla' months ago
I
moved next door to an inventor who has the patent on the whole arena of
6DOF trackballs( see http://gadgetland.com/globaldevices/trackball.html).
The guy is a mechanical genius and has a prototype that spins in all 3
directions and can translate in the other three. Fortunately for me he
didn't know alot about electronics and is supplying me with all of the
equipment I need (PICStart Plus, PC, chips, PC board design software, etc.)
in exchange for doing this project for him.
       The three rotational axes will be done with encoders and the translation
al
axes will have proportional control, but have a much better "feel" than
controllers currently on the market. This thing will ROCK the game
controller world!
       I didn't quite understand how you can get the yaw from just pitch and
roll. Does this mean I can do away with one of my encoders? If it does,
will I need to do intense computations? I would greatly appreciate any help
in finding out more about this (references, etc.).

                                               Thanx,
                                               Jeff Kroll

1997\03\05@180803 by Steve Hardy

flavicon
face
> From: "Jeff 'n Kristen Kroll" <@spam@jkkrollKILLspamspamJOSHUANET.COM>
>         Actually what I am working on is a 6DOF trackball. A coupla' months
ago I
> moved next door to an inventor who has the patent on the whole arena of
> 6DOF trackballs( see http://gadgetland.com/globaldevices/trackball.html).
> The guy is a mechanical genius and has a prototype that spins in all 3
> directions and can translate in the other three. Fortunately for me he
> didn't know alot about electronics and is supplying me with all of the
> equipment I need (PICStart Plus, PC, chips, PC board design software, etc.)
> in exchange for doing this project for him.
>         The three rotational axes will be done with encoders and the
translational
{Quote hidden}

It's not really suitable for your application - try rolling a ball as
described and you will see why.  Also, it is counterintuitive for the
user of the device.  Nevertheless, the principle has been applied to
CAD programs for 'rolling' 3-D objects around using a 2-D mouse or
trackball.  E.g. the user clicks on a special roll-mode button.  If the
mouse is then moved in the Y direction, the object rolls around the X
axis as if the mouse cursor is a 'hand' pushing on the top of the
object.  Similarly for the other axis.  Rolling the object around the Z
axis (pointing out of the screen) is performed by moving the mouse in
small circles.  No additional computation is required for this, as it
is a natural mathematical consequence of keeping track of the 3-D
orientation of the object.

This is explained in 'Graphics Gems' which is a set of books relating
to tricks for computer graphics, which is where I got my info.

Regards,
SJH
Canberra, Australia

1997\03\05@200113 by Prashant Bhandary

flavicon
picon face
At 11:58 PM 3/03/97 -0800, you wrote:
>That is somewhat similar to what I did more than a decade ago.  I used a
>couple of one-shots that were re-triggered by the encoder edges.  Along with
>a flip flop or two it prevented the false triggering as the encoder vibrated
>back and forth around one edge.  As I recall the time period of the oneshot
>was set to less than the maximum encoder rate.  The idea came out of EDN (I
>think).  This was in late 1983.  I really do wish I still had that circuit.

I designed(but never implemented) something similar in software. I had to
sense a digital signal on a port B line with the change on Port B interrupt
enabled and have a timer going at the same time for PWM. Jitter on the digital
signal was not important but constant interrupts could disrupt the PWM. So
on each change of digital signal, I disabled the Port B interrupt and enabled
it on the next timer interrupt.

The application was a DCC decoder in a model train(yes, that's all I do) which
senses the DCC signal on the track and controls the motor speed at the same time
using PWM. A dirty track can produce jitter inside the loco. You may lose the
data packet but that's OK. It could disrupt the PWM which will manifest itself
as
the loco shuddering when it hits the dirty patch.

Something similar could probably be used for the encoders. Handle jitter by
shutting off the Port B interrupt for a while. This ensures that you have enough
quiet time to do other processing. You would not lose resolution as the change
is still sensed, only at a slower rate. You would not accumulate error because
this time period is not long enough to miss an actual step.

Regards

Prashant
--------------------------------+---------------------------------
 Prashant Bhandary             | Tel:  +61-2-9662 5299
 Spatial Information Solutions | Fax:  +61-2-9662 5348
 Roads and Traffic Authority   | Email: KILLspamprashbKILLspamspamrta.nsw.gov.au
 Rosebery NSW 2018, AUSTRALIA  | "2b|!2b" - William Shakespeare
--------------------------------+---------------------------------

1997\03\05@232246 by John Payson

picon face
>
> At 11:58 PM 3/03/97 -0800, you wrote:
> >That is somewhat similar to what I did more than a decade ago.  I used a
> >couple of one-shots that were re-triggered by the encoder edges.  Along with
> >a flip flop or two it prevented the false triggering as the encoder vibrated
> >back and forth around one edge.  As I recall the time period of the oneshot
> >was set to less than the maximum encoder rate.  The idea came out of EDN (I
> >think).  This was in late 1983.  I really do wish I still had that circuit.

If you have two interrupt-on-change signals that can be enabled/disabled
seperately, it should be possible to design a jitter-resistant quadrature
decoder in software.  The key is to recognize the four states as 0x, 1x,
x0, and x1; any time one of the input changes and triggers an interrupt,
disable the interrupt on that input and enable it on the other one.  In
this way, you should be able to get excellent response while minimizing
overhead from contact jitter.  You will add one count worth of slop to the
current position report, but in many cases you'd want to add a count of
hysteresis anyway so it's a non-issue.

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...