Talk:Rotary encoder

message: This article needs more coverage of the simplest case -- show the innards of a standard computer mouse, and show the two-channel encoding and explain how it works, how the counters are interfaced.  This article needs to be a tech support base for the mouse articles.-69.87.203.252 13:45, 20 March 2007 (UTC)
replies: text: Yes.  Anybody have a good, clear photo of the inside of an optical encoder?  I put up a photo of a Hall-effect quadrature encoder (yes, that really is a quadrature encoder), but that's a sealed unit and you can't see how it works. --John Nagle (talk) 04:53, 11 December 2007 (UTC)
thread_title:  simple two-channel 

message: Is this image right? I think that there is something wrong with the numerical sequence: 0,1,3,2,6,7,5,4. Where did this image come from?--Drvanthorp 16:21, 5 September 2007 (UTC)
thread_title:  Encoder Disk Image 

message: A few items that need coverage:
* The "once per turn" signal on an encoder is called an "index pulse".  It's not enough for absolute positioning.  It's usually used in conjunction with some other means of low-accuracy position sensing, like a limit switch.  In such systems, startup calibration involves moving to a limit switch, then back to the next index pulse point.  
* Brush-type encoders are rare today.  
* Some "incremental encoders" are unidirectional, with only one Hall sensor. Automotive speedometer and tachometer inputs are single-sensor encoders, usually called tachometer sensors.
* Sometimes a resistive position sensor and an encoder are combined into a single unit, to obtain a position at startup.  Automotive steering position sensors work this way.  —Preceding unsigned comment added by Nagle (talk • contribs) 16:27, 10 December 2007 (UTC)
thread_title:  Items that need coverage 

message: Much of this article makes the fundamental mistake of essentially stating that the function of absolute encoders is true of all rotary encoders. This is further compounded by the fact that absolute encoders are the less common of the two types.   I plant to make a tweak or two regarding this but do not plan to do the major work needed to really fix this issue and the article.  Sincerely, North8000 (talk) 14:11, 6 March 2011 (UTC)
thread_title: Fundamental Flaws

message: Not all encoders of this type are rotary. Some are linear, consisting of straight strips.  — Preceding unsigned comment added by 192.139.122.42 (talk) 22:33, 27 May 2011 (UTC)
replies: text: But all rotary encoders are rotary! :-)  I guess it's the title that did it.  But we should mention that the same functions are available in a linear format. North8000 (talk) 23:10, 27 May 2011 (UTC)
thread_title: Why restrict to rotary

message: The "Battery backed incremental encoders" makes no sense.  I tried going to the referenced document to see what the editor intended to say but it a huge users manual which covers a huge range of products which makes no coherent statements regarding the material which cited it. North8000 (talk) 12:26, 9 February 2012 (UTC)
replies: text: I deleted it.North8000 (talk) 12:46, 15 February 2012 (UTC)
thread_title: Scrambled subsection

message: the text in the section Incremental rotary encoder seems bogus to me. It basically suggests that applications have to (or do) use lookup tables to decode the signal from the encoder - whereas a look at the diagram reveals that that's not necessary. If the shaft is rotated clockwise (imagine a line gliding over the diagram from left to right) every rising edge of A coincides with B being low. A CCW rotation would make B being high on every rising edge of A. So, all the application has to do is to track A's rising edges and B will invariably indicate the direction.
I'm not an electrical engineer (only an enthusiast), but I imagine this not only is simpler in terms of circuitry but also the way it's actually done in the real world.
Уга-уга12 (talk) 19:27, 1 May 2012 (UTC)
replies: text: The way that you describe it correctly describes a   way to do it and implements what is called "X1" logic.  It requires the occurence and direction of transitions.    It is common practice to do this for all four edges that occur for a quadrature signal in one signal to obtain "X4" logic, and get 4x the resolution. The tables in the section (and related description) seem to imply/describe another method which derives information from knowing the current and previous state of the outputs. I don't know whether or not that other method is actually used. North8000 (talk) 20:26, 1 May 2012 (UTC)
replies: text: Following is just a sidebar comment......there is no widely accepted standard for the phasing in relation to clockwise and CCW. And in the case of double shaft encoders, there really is not even a definition of clockwise vs. counterclockwise.  Sincerely, North8000 (talk) 11:42, 24 May 2012 (UTC)
thread_title:  bogus info 

message: A new type of absolute encoder has been developed. This uses a bar code that represents position, and is read by a camera IC, not a single sensor.  It takes some compute power, but it's a high-resolution absolute encoder. Available for both linear and rotary encoders. No news articles yet, so I'm not putting it in the article.  A design note from Taos suggested this idea in 2004  but apparently nobody picked up on the idea until recently. I'm surprised it took so long; the processing is simpler than that for an optical mouse.  --John Nagle (talk) 00:12, 3 September 2013 (UTC)
replies: text: I think that an independent article would be important.  The material that you linked (by the supplier) seems written to impress rather than really explain.  Sincerely, North8000 (talk) 11:26, 3 September 2013 (UTC)
replies: text:  These have been around for 30 years (at least). The Renishaw version is just an improved development, with improved performance to the read head and the idea of a single staring camera rather than the linear array of single sensors (although I did something similar myself with a line-scan camera, 20 years ago).  The idea of single-track non-repeating-code is important and deserves mention here, but it's quite old. At present the article seems to skip them and goes straight to the single track Gray code (i.e. only one bit changes per increment), which is much later. Andy Dingley (talk) 11:33, 3 September 2013 (UTC)
thread_title:  Bar-code type absolute encoder 

message: The page for the first citation has been deleted. The old content can be found from the wayback machine here: https://web.archive.org/web/20131005090254/http://www.canon.com/bctv/faq/rotary.html  — Preceding unsigned comment added by 122.107.192.94 (talk) 12:25, 12 March 2015 (UTC)
replies: text: Done, but it is a dubious reference. Glrx (talk) 17:04, 1 April 2015 (UTC)
thread_title:  First Citation (rotary encoder on canon lenses) 

message: There's an unreferenced mention of "sine encoders", which are analog quadrature devices. Here's a reference..  See also Resolver (electrical).  John Nagle (talk) 17:21, 15 February 2016 (UTC)
thread_title:  Analog encoders 

message: Reference is made to to the last couple edits.  An editor deleted the chart saying that it was incorrect.   I reverted, saying that the chart was correct and useful to help explain the derivation of direction of the quadrature signal. The same editor undid my restoration, in essence saying that direction could be derived from the previous and current state.  This is not relevant to either of the content issues being discussed.  Including no discussion on whether the deleted chart is correct or not.  Indeed, it is correct (which they did not challenge when they reverted my restoration) and it shows how very similar-appearing waveforms / sequences are different when the rotational direction changes. This is correct and useful content to help explain the topic.   Thoughts?   Sincerely, North8000 (talk) 23:21, 8 August 2017 (UTC)
replies: text: IP's edits were appropriate and should remain. Using two diagrams with different "phase" assignments is confusing. Glrx (talk) 02:41, 14 August 2017 (UTC)
thread_title: Deletion of chart and mini-discussion in edit summaries

message: Lambrton, you did a lot of good work.  But some of it has scrambled it a bit from an organization and naming standpoint. "Absolute" is duplicated and incremental is not necessarily digital. I didn't revert because I think you can resolve with further evolution. North8000 (talk) 12:14, 22 June 2018 (UTC)
replies: text: Thanks for the positive feedback -- and for collaborating on the clean-up. I realize it's disorganized and plan to work on that. I also see what you mean about duplicate titles (and other duplication) and will take a crack at fixing those too. Lambtron (talk) 12:58, 22 June 2018 (UTC)
replies: text: Cool! North8000 (talk) 17:49, 22 June 2018 (UTC)
replies: text: First pass completed. Let me know what you think, or feel free to modify it as you see fit. Lambtron (talk) 17:58, 22 June 2018 (UTC)
replies: text: Cool. Perhaps a bit more on the fundamental nature of the info they or their system put out?   Absolutes put out position. For incrementals they need the next stage to derive motion variables but this list is longer (position, velocity, RPM, distance moved etc.? North8000 (talk) 21:14, 25 June 2018 (UTC)
thread_title: Headings

message: Researching Gray code variants for our Wikipedia article I stumbled upon a code called "Royal Radar Establishment code" in a 1972 book, apparently used in some kind of displacement measurement devices (possibly linear or rotary encoders):
: 
The book states:
: "Other forms of code are also well known. Among these are the Royal Radar Establishment code; The Excess Three decimal code; Gillham code which is recommended by ICAO for automatic height transmission for air traffic control purposes; the Petherick code, and the Leslie and Russell code of the National Engineering Laboratory. Each has its particular merits and they are offered as options by various encoder manufacturers."
If you have any information about this code, please ping me/reply. Thanks.
--Matthiaspaul (talk) 21:10, 21 May 2020 (UTC)
thread_title:  Info on "Royal Radar Establishment code"?