Searching \ for '[PIC] Which style encoder?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=encoder
Search entire site for: 'Which style encoder?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Which style encoder?'
2005\12\05@171802 by Josh Koffman

face picon face
Hi all. Armed with my new copy of USB Complete, I'm starting an
ambitious project. Not ambitious in its functionality, it's just that
this project will combine a number of things I've never done before -
USB, true keyboard scanning and debouncing, and encoders. In additon
I'm going to try to do this entirely with relocatable code, another
first for me.

At the moment I'm looking at a few encoders on Digikey. I kind of like
the idea of ones with no detent, which narrows my choice a lot. I
can't afford optical encoders.

In any case, I have to make some choices. Chief among them seems to be
whether I want Binary or Grey Code output. It seems like there is more
example code to get me with Binary stuff. I worked with a team on a
product that had one of these cheaper style encoders in it, outputting
Binary, and I remember there were a number of skips that sometimes
happened throwing off the result. Sometimes you'd be turning one way a
single detent at a time and the output would just jump the other way.
Very annoying. Would going with a Grey Code encoder and decoding
routine eliminate this? What happens with no detents, is it possible
to stop in between two positions?

Alternatively, if someone knows of a surplus vendor with cheap
encoders, please let me know. I'm only interested in a few (3-4). I
tried BG Micro, All Electronics, Alltronics, and Electronics Goldmine
to no avail.

Thanks!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2005\12\05@174133 by Wouter van Ooijen

face picon face
> Alternatively, if someone knows of a surplus vendor with cheap
> encoders, please let me know. I'm only interested in a few (3-4). I
> tried BG Micro, All Electronics, Alltronics, and Electronics Goldmine
> to no avail.

not surplus, and dented (although you could remove the dent):
http://www.voti.nl/shop/p/M-SW-ROT.html

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\12\05@174157 by Neil Baylis

picon face
Old mechanical mice are a good source of ultra-cheap optical encoders. But
they are incremental, not absolute. Do you need absolute encoding?

Neil

http://www.pixpopuli.com

2005\12\05@180217 by Jan-Erik Soderholm

face picon face
Josh Koffman wrote :

> At the moment I'm looking at a few encoders on Digikey. I kind of
like
> the idea of ones with no detent,...

Any special reason for non-detent types ?
I've found that the detent is there for a reason.
It helps keeping the encoder in a "known" position
with stable output. It also gives a nice tactile (?)
feedback for the user.

> Chief among them seems to be
> whether I want Binary or Grey Code output.

Are you talking about absolute position encoders ?
Or (as I thought first) rellative (up/down) encoders ?

> It seems like there is more
> example code to get me with Binary stuff. I worked with a team on a
> product that had one of these cheaper style encoders in it,
outputting
> Binary, and I remember there were a number of skips that sometimes
> happened throwing off the result.

That is very much up to the software decoding the output :-)

> What happens with no detents, is it possible
> to stop in between two positions?

I'd guess so. Worst case would be a some "race" condition.
Depending on the decoding logic it could just go up/down/up/down
or run to the max or min value. Depends also on th internal
design of the encoder, I guess.

> Alternatively, if someone knows of a surplus vendor with cheap
> encoders, please let me know. I'm only interested in a few (3-4). I
> tried BG Micro, All Electronics, Alltronics, and Electronics
Goldmine
> to no avail.

Actualy I got a bunch (5-10, don't remember) from a piclister,
(not Wouter) about a year ago. I made a decoding routine
for a PIC18 that workd just fine. Had a 400 Hz timer ISR
where the A/B inputs was read and decoded. It had an
"acceleration" feature where if you roteted the encoder over
a specific speed, the value incremented with larger steps.
Turn slowly, and you could fine adjust the value. Like an
PC mouse with a driver with an acceleration option...

Jan-Erik.



2005\12\05@181127 by Howard Winter

face
flavicon
picon face
Josh,

On Mon, 5 Dec 2005 17:18:01 -0500, Josh Koffman wrote:

{Quote hidden}

I'm not sure what you mean by "binary" - the main difference between encoders is that they are either
incremental and positional - the former says "I moved one step (anti-) clockwise", the latter "I am in
position 4".  Grey coding is used for positional coding, quadrature encoding for incremental (two signals
whose transitions indicate the and occurrance and direction of a step).  

If you need positional encoding you *can't* use binary coding because of the glitches associated with the
transitions.  Detents don't affect it, except to keep the shaft in particular places - moving from one detent
to the next will still give transitional errors if you don't use Grey coding.  By using Grey coding you always
know that the shaft is in a given position, and since only 1 bit changes at a time the transitions are
"clean".

If you use incremental encoders, you need to know where you started, and keep count from there.

What exactly are you using the encoders for?

Cheers,


Howard Winter
St.Albans, England


2005\12\05@181349 by Howard Winter

face
flavicon
picon face
On Tue, 6 Dec 2005 00:02:16 +0100 (MET), Jan-Erik
Soderholm wrote:

> Actualy I got a bunch (5-10, don't remember) from a
piclister, (not Wouter) about a year ago.

Spehro has rotary controls which give incremental
output, and have a "push" function on the shaft.  
They're rather nice, but I'm not sure that's the sort of
thing the OP wants...

Cheers,


Howard Winter
St.Albans, England


2005\12\05@183901 by Dennis J. Murray

picon face
Josh Koffman wrote:

>Chief among them seems to be
>whether I want Binary or Grey Code output.
>
>  
>
I'd go quadrature encoders, period!!!

I've had great success , primarily with optical encoders.  Most of my
encoder-related projects required a high degree of resolution (i.e. 256
pulses per channel per rev) at erratic rotation speeds (sometimes fairly
fast), so mechanical encoders weren't a viable option because I couldn't
guarantee enough processor time would be available to process debouncing
logic.  Using optical encoders would make this a perfect application to
use the "Interrupt on Change" feature (which I do).   Quadrature
encoders output a unique A-B bit pattern sequence that allows you to
determine which direction you're turning AND if you've dropped a pulse,
etc.  To my knowledge, I've NEVER - EVER- had the kind of "jump" in
output you're talking about.

In addition to Wouter's site, watch eBay.  Browse for "optical encoder",
etc. and watch closely.  I recently picked up 4 optical encoders with
256 ppi resolution for less than $20, including shipping!

Good luck!
Dennis

2005\12\05@185704 by Dwayne Reid

flavicon
face
At 03:18 PM 12/5/2005, Josh Koffman wrote:

>In any case, I have to make some choices. Chief among them seems to be
>whether I want Binary or Grey Code output. It seems like there is more
>example code to get me with Binary stuff. I worked with a team on a
>product that had one of these cheaper style encoders in it, outputting
>Binary, and I remember there were a number of skips that sometimes
>happened throwing off the result. Sometimes you'd be turning one way a
>single detent at a time and the output would just jump the other way.
>Very annoying. Would going with a Grey Code encoder and decoding
>routine eliminate this? What happens with no detents, is it possible
>to stop in between two positions?

The above behavior is caused by using improper decoding
techniques.  The easy way to read a quadrature encoder is to treat
one line as the clock line, the other as the direction
line.  However, it is easy to get false counts.

The "proper" way to read those encoders is to set up a state machine
that looks at both lines and ignores illegal transitions.  This
becomes a problem if you try to make it interrupt driven - simple
PICs have only 1 usable interrupt input (I'm deliberately ignoring
the port B Interrupt On Change because of its known
limitations).  The easy way to fix that problem is to use an XOR gate
to combine the lines into the INT pin.

The approach I plan to take the next time I need to read a quadrature
encoder is a little different: I'm going to use one of the tiny 10F
parts as a quadrature to step & direction convertor.  I figure that
it should be possible to poll the inputs fast enough if that's the
only thing the PIC is doing - all in a SOT23-6 package.

dwayne

--
Dwayne Reid   <spam_OUTdwaynerTakeThisOuTspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 21 years of Engineering Innovation (1984 - 2005)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

2005\12\05@195847 by olin piclist

face picon face
Dwayne Reid wrote:
> The "proper" way to read those encoders is to set up a state machine
> that looks at both lines and ignores illegal transitions.  This
> becomes a problem if you try to make it interrupt driven - simple
> PICs have only 1 usable interrupt input (I'm deliberately ignoring
> the port B Interrupt On Change because of its known
> limitations).

Huh?  It's always worked very well for me, and I don't remember any errata
on it.  It's just about what you'd want for quadrature decoding, and I've
used it for that.  In one project I had a 16F876 do proper quadrature
decoding as an in-line adapter to clean up the signal so that one of those
dedicated quadrature decoder chips would work right.  There were no issues
related to any port B interrupt on change problem.  In fact there were no
issues at all.  It worked great.

> The easy way to fix that problem is to use an XOR gate
> to combine the lines into the INT pin.

But then you only get an interrupt every second state change, which misses
out on resolution and makes noise and error detecting harder.  Proper
decoding software uses each new state change.  There are 4 states, so 2 are
adjacent to the current state.  One is a 1/4 cycle one way and the other a
1/4 cycle the other way.  In theory you can't jump straight to the remaining
state, but things aren't always perfect.  The problem then is that it can be
interpreted as both +1/2 and -1/2 step.  I had my software track the
previous step direction and assume the 1/2 cycle step was in the same
direction as the last step.  This is a good assumption because the most
likely cause for seeing a 1/2 cycle jump is that the input pulses are coming
too fast for the processor to handle.

By the way, some of the 30Fs have quadrature decoder modules, but I haven't
had an opportunity to use one yet.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\05@201657 by Stephen D. Barnes
picon face
Olin Lathrop wrote:

>By the way, some of the 30Fs have quadrature decoder modules, but I haven't
>had an opportunity to use one yet.
>
>Because I am a beginner, take what I say with a grain of salt.... I am using the dsPIC30F2010 quadrature encoder interface (QEI) with a US Digital optical encoder and have finally worked the bug out of my code. The QEI work great and has programmable filtering for the encoder inputs. Some of the 18F parts incluse the QEI as well. Just an FYI.
>
--
Regards,
Stephen D. Barnes

2005\12\05@203315 by Stephen D. Barnes

picon face
Stephen D. Barnes wrote:

>Olin Lathrop wrote:
>
>  
>
>>By the way, some of the 30Fs have quadrature decoder modules, but I haven't
>>had an opportunity to use one yet.
>>
>>Because I am a beginner, take what I say with a grain of salt.... I am using the dsPIC30F2010 quadrature encoder interface (QEI) with a US Digital optical encoder and have finally worked the bug out of my code. The QEI work great and has programmable filtering for the encoder inputs. Some of the 18F parts incluse the QEI as well. Just an FYI.
>>
>>    
>>
WOW, sorry about what Mozilla Thunderbird did to the ">" quoting! I did
not intend for it to appear that Olin had written that he is a beginner!
I think it worked correctly this time.

--
Regards,
Stephen D. Barnes

2005\12\05@235714 by Josh Koffman

face picon face
Well that was a flurry of answers. I'll answer most of them in this
email, rather than post a bunch of emails.

First of all, to clarify, I need incremental encoders. The end result
should be that as long as I'm turning one way, the PIC will send a
keycode to the computer. Different keycode for different direction.
Think somewhat similar to turning clockwise and having it transmit the
down key repeatedly. Not quite what I'm doing, but close enough for
illustrative purposes. I just need to know which direction the knob is
being turned.

I chose non detent because as a user I like the feel of it more. I'm
becoming concerned aobut the "getting stuck in between" problem
though. Perhaps I'll just stick with detented ones.

I was looking at Grey code encoders as a way to help eliminate skips
and jumps in the reading. I guess that with adequate software
filtering, the standard three pin binary one should be fine.

I am using a PIC18F4550, for USB, so I can't switch to a PIC with a
built in encoder interface.

Spehro - do you still have some encoders available? Remember, I'm
local to you. Plus I think it's ridiculous I've lived here for 5.5
years and we've still never met. Buying parts from you could be a good
excuse!

Jan-Erik - I'd love to see your routine for reading the encoders if
you're willing to share. This isn't a commercial project, just
something to teach me a bunch of new stuff.

Anyone have any further comments/gotchas I need to know? So far it
seems fairly straightforward, I just need to figure out if I should
poll or use an interrupt pin. Suggestions on that front?

Thanks!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2005\12\06@003207 by Spehro Pefhany

picon face
At 11:57 PM 12/5/2005 -0500, you wrote:


>Spehro - do you still have some encoders available? Remember, I'm
>local to you. Plus I think it's ridiculous I've lived here for 5.5
>years and we've still never met. Buying parts from you could be a good
>excuse!

Hi, Josh:-

;-) Yes, I do have more (with the push-switch shaft action).
Feel free to contact me off-list if you'd like.


>Jan-Erik - I'd love to see your routine for reading the encoders if
>you're willing to share. This isn't a commercial project, just
>something to teach me a bunch of new stuff.
>
>Anyone have any further comments/gotchas I need to know? So far it
>seems fairly straightforward, I just need to figure out if I should
>poll or use an interrupt pin. Suggestions on that front?

I very much prefer periodic polling, driven by a timer interrupt. With a
simple "state machine" you can prevent bounce in either channel from
causing unwanted counts. If you have to run the micro off of battery power
at a very low clock frequency, using an interrupt might be the way to do
it, but I've never been forced into that.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam@spam@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2005\12\06@051717 by Jan-Erik Soderholm

face picon face
Josh Koffman wrote :

> I chose non detent because as a user I like the feel of it more. I'm
> becoming concerned aobut the "getting stuck in between" problem
> though. Perhaps I'll just stick with detented ones.

Note that that "feel" of the detents is very much depending
on the size if the button/knob on the encoder. Larger knob gives
smoother "drive" with less feeling of the detents.


> Spehro - do you still have some encoders available?...

Yep, that's the ones *I* used... :-)

> Jan-Erik - I'd love to see your routine for reading the encoders if
> you're willing to share.

OK. Will be sent privately right wfter this post.
It's a project based on Olin's framework/environment.
It does a bunch of other stuff, but the encoder things are
in mainly D01_tmr.aspic and D01_enc.aspic.

Jan-Erik.



2005\12\06@161725 by Dwayne Reid

flavicon
face
At 05:58 PM 12/5/2005, Olin Lathrop wrote:
>Dwayne Reid wrote:
>>The "proper" way to read those encoders is to set up a state machine
>>that looks at both lines and ignores illegal transitions.  This
>>becomes a problem if you try to make it interrupt driven - simple
>>PICs have only 1 usable interrupt input (I'm deliberately ignoring
>>the port B Interrupt On Change because of its known
>>limitations).
>
>Huh?  It's always worked very well for me, and I don't remember any errata
>on it.  It's just about what you'd want for quadrature decoding, and I've
>used it for that.

Sigh.

Its not an errata, its a design limitation.  The port B Interrupt on
Change is not reliable if port B is either read or written.

Pretty much every 14 bit core PIC data sheet mentions the problem.

For example, section 9.4.3 of datasheet DS41190C
says:  "Note: If a change on the I/O pin should occur when the read
operation is being executed (start of the Q2 cycle), then the GPIF
interrupt flag may not get set."

Also note that any operation involving the port is always a R-M-W
operation, even if the operation is a write to the whole port (movwf RB).

So: yes: you can use the port pin Interrupt On Change if you do not
read or write any of the other pins on that port while you are
waiting for encoder transitions.  I consider that to be a limitation.

For that matter - its usually a show-stopping limitation when working
with a 12f675 - there is only a single port (GPIO).  Adding a
TinyLogic XOR gate to combine both quadrature signals into the
interrupt pin eliminates that problem.

Note that this does not require any extra pins into the PIC - either
of the quadrature signals plus the output from the XOR gate is all
that is needed to decode all 4 states from the encoder PLUS generate
an interrupt at every transition.


>>The easy way to fix that problem is to use an XOR gate
>>to combine the lines into the INT pin.
>
>But then you only get an interrupt every second state change, which misses
>out on resolution and makes noise and error detecting harder.

Read closely.  I said "XOR" gate.  That quite nicely combines both
signals and provides an indication of EVERY state change.  This
assumes, however, that you re-program the interrupt edge polarity
each time the interrupt occurs.

dwayne

--
Dwayne Reid   <dwaynerspamKILLspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 21 years of Engineering Innovation (1984 - 2005)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

2005\12\06@212138 by Timothy Weber

face picon face
Josh Koffman wrote:
>
> I chose non detent because as a user I like the feel of it more. I'm
> becoming concerned aobut the "getting stuck in between" problem
> though. Perhaps I'll just stick with detented ones.

I use and like the detented ones.  Without the detents, you *will*
sometimes have it flutter back and forth between two values.

> Anyone have any further comments/gotchas I need to know? So far it
> seems fairly straightforward, I just need to figure out if I should
> poll or use an interrupt pin. Suggestions on that front?

I poll.  It works.

I basically check for changes in a main loop and it works out to be fast
enough.

Another trick is to wait a little bit after detecting a 'forward' or
'back' event before acting on it.  If you get another opposite event in
the meantime, allow it to cancel out the first event without doing any
processing.  My notes say that debounces the encoder to a minimum
response period of 0.25 ms.  It seems to help smooth out the response
without limiting the "frobbing" speed too much.

I'd be happy to post my code (assembly) if anyone wants it.
--
Timothy J. Weber
http://timothyweber.org

2005\12\07@000035 by Josh Koffman

face picon face
On 12/6/05, Timothy Weber <.....twKILLspamspam.....timothyweber.org> wrote:
> I'd be happy to post my code (assembly) if anyone wants it.

I'd love to see it. When I'm learning something new I try and get as
many perspectives as possible. You may also want to put it up on the
http://www.piclist.com website. It's free, and then others can benefit
as well.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2005\12\07@215042 by ike, K8LH (sent by Nabble.com)

flavicon
face

On a somewhat related note (I hope), may I ask if anyone has good experiences and recommendations for a reasonably priced mechanical incremental rotary encoder with detents and built-in push-button switch?

I've tried two Bourn's PEC11 series, both of which broke down after a short time, and I just prototyped a board with an ITT/Canon NSE12 series which looks promising but doesn't have a threaded shaft collar for mounting to a front panel...

TIA guys...  Regards, Mike


--
Sent from the MicroControllers - PIC forum at Nabble.com:
www.nabble.com/-PIC-Which-style-encoder--t682945.html#a1844992

2005\12\08@202345 by Timothy Weber

face picon face
Mike, K8LH (sent by Nabble.com) wrote:
> On a somewhat related note (I hope), may I ask if anyone has good experiences and recommendations for a reasonably priced mechanical incremental rotary encoder with detents and built-in push-button switch?
>
> I've tried two Bourn's PEC11 series, both of which broke down after a short time, and I just prototyped a board with an ITT/Canon NSE12 series which looks promising but doesn't have a threaded shaft collar for mounting to a front panel...

Huh - I like the PEC11's, and they seemed cheap ($2.37 from Mouser).
Haven't exercised them for very long, though, as the project has yet to
be finalized and put into use.

The Piher CI-11 is the other one I've used.  The decoding is slightly
different from the Bourns encoders, and the detents don't have as nice a
feel to me, but other than that it's equivalent.  More expensive, though
- $5.38.  Also haven't stressed it very much.  Its shorter shaft fits
better in my project, so it may be the one I'll use.

(These prices were from August 2004.)
--
Timothy J. Weber
http://timothyweber.org

2005\12\08@204955 by Timothy Weber

face picon face
Josh Koffman wrote:
> On 12/6/05, Timothy Weber <EraseMEtwspam_OUTspamTakeThisOuTtimothyweber.org> wrote:
>
>>I'd be happy to post my code (assembly) if anyone wants it.
>
> I'd love to see it. When I'm learning something new I try and get as
> many perspectives as possible.

Good plan!  OK, it's up at <http://timothyweber.org/quadrature>.

> You may also want to put it up on the
> http://www.piclist.com website. It's free, and then others can benefit
> as well.

I tried, but couldn't get in - will keep trying.
--
Timothy J. Weber
http://timothyweber.org

2005\12\08@233934 by Josh Koffman

face picon face
On 12/8/05, Timothy Weber <twspamspam_OUTtimothyweber.org> wrote:
> Good plan!  OK, it's up at <http://timothyweber.org/quadrature>.

Just so you know, the link to QuadEncoder.inc isn't working. It tells
me I don't have permission.

I will check out the files tomorrow when I'm somewhat conscious. Thanks!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2005\12\09@093005 by Timothy Weber

face picon face
Josh Koffman wrote:
> On 12/8/05, Timothy Weber <@spam@twKILLspamspamtimothyweber.org> wrote:
>
>>Good plan!  OK, it's up at <http://timothyweber.org/quadrature>.
>
> Just so you know, the link to QuadEncoder.inc isn't working. It tells
> me I don't have permission.
>
> I will check out the files tomorrow when I'm somewhat conscious. Thanks!

I fixed the server error now that *I'm* somewhat conscious.  :)  Sorry!
--
Timothy J. Weber
http://timothyweber.org

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