Post by thread:Encoder resolution?

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

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

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/

> From: "Jeff 'n Kristen Kroll" <spam_OUTjkkrollTakeThisOuTJOSHUANET.COM> > > I have been reading the PICLIST for about a month and have seen several {Quote hidden}> 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! 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

Bob Blick <.....PICLISTKILLspam@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 - fastfwdKILLspamix.netcom.com === Fast Forward Engineering - Vista, California === === Custodian of the PICLIST Fund -- For more info, see: === www.geocities.com/SiliconValley/2499/fund.html

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.

At 02:08 AM 04/03/1997 -0500, you wrote: {Quote hidden}>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. > 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

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!" ==================================================================

---------- {Quote hidden}> From: Steve Hardy <.....hardyKILLspam.....SWENG.STORTEK.COM> > To: EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU > Subject: Re: Encoder resolution? > Date: Tuesday, March 04, 1997 2:08 PM > > > From: "Jeff 'n Kristen Kroll" <jkkrollspam_OUTJOSHUANET.COM> >>the project I am working on, a six degree of freedom > > trackball > 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 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

> From: "Jeff 'n Kristen Kroll" <@spam@jkkrollKILLspamJOSHUANET.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}> 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 > 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

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: KILLspamprashbKILLspamrta.nsw.gov.au Rosebery NSW 2018, AUSTRALIA | "2b|!2b" - William Shakespeare --------------------------------+---------------------------------

> > 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.