IC that reads gray code from an encoder, keeps count, and gives current value - Page 1
Forum section: electronics / beginners

author: Watth
author_rank: Frequent Contributor
timestamp: December 05, 2021, 01:08:46 pm
content: Hey EEfolks,So is there a type of IC that works like a driver/peripheral (I'm not sure of the proper terminology) thatreads gray code data from an encoderkeeps count of the ups and downs (i.e. in a signed integer)can give the current value by series/parralel transmission to a µUCresets by %CU commandcan alret the master µCU by interrupt if the value is getting too high (or to low if negative) for the count variable?I explored the possibility to programm an ITtiny for this task, as it can be less expensive and perform the exact functions I want, but if there is any simple, cheap and even less voluminous solution, I'd wish to hear about it.Thanks for reading!

author: Doctorandus_P
author_rank: Super Contributor
timestamp: December 05, 2021, 02:00:20 pm
content: 30 years or so ago such chips were available via normal channels.Now they are completely obsolete, and the people who sell them also know that.But no worries.They're only obsolete because the world has moved on, and 2-bit grey encoders are still common.The hardware for such encoders is integrated many microcontrollers these days. (Most of?) the STM32 microcontrollers have gray encoder functions built in in their timers for example, but other manufacturers also similar peripherals in their microcontrollers.

author: Watth
author_rank: Frequent Contributor
timestamp: December 05, 2021, 02:41:21 pm
content: Well itischeaper to program a µCU that includes software de-bouncer.

author: voltsandjolts
author_rank: Unknown
timestamp: December 05, 2021, 03:00:53 pm
content: What is the electrical interface specification for your encoder?

author: ledtester
author_rank: Super Contributor
timestamp: December 05, 2021, 03:23:33 pm
content: What speed will the encoders be operating at?There was a recent discussion of reading multiple rotary encoders with an Arduino. Thread has lots of ideas including sample code:https://www.eevblog.com/forum/beginners/suggestion-of-methods-to-attach-8-rotary-encoders-to-an-arduino/QuoteIf you use a powerful enough MCU you can combine the encoder reading with your main application. Sometimes this is the best way to proceed.

author: Watth
author_rank: Frequent Contributor
timestamp: December 05, 2021, 03:31:30 pm
content: It's a simple ABC pin thing :https://www.ttelectronics.com/TTElectronics/media/ProductFiles/Datasheets/EN05.pdf.It would be manually operated.I'll see if I really need this when I start testing if it can be directly used by the µMC. I have no idea if monitoring the encoder would make it visibly slower, especially since the encoder would not be used most of the time, therefore ignored. Also, I still don't know if bounce management is needed at all (or can be suppressed by a simple RC circuit) with this particular encoder.

author: Watth
author_rank: Frequent Contributor
timestamp: December 05, 2021, 03:32:59 pm
content: Quote from: ledtester on December 05, 2021, 03:23:33 pmYup, I need to advance in my project to see if it anything more than the µCU is needed.

author: ledtester
author_rank: Super Contributor
timestamp: December 05, 2021, 03:48:46 pm
content: Quote from: Watth on December 05, 2021, 03:31:30 pmThat encoder only has 12 pulses per revolution so it can't change that fast if you are manually operating it. Given the bounce and chattering times listed the datasheet I would just poll the encoder inputs every 10 ms.

author: jmelson
author_rank: Super Contributor
timestamp: December 05, 2021, 09:25:16 pm
content: There's the LS7166 chip that has a 24-bit position counter with quadrature decode logic in front. I had a board with that chip and it seemed to have an issue with the rollover from signed -1 to 0, or zero to minus 1. I don't know if this was a fundamental problem with the chip or the board that it was on.Jon

author: Watth
author_rank: Frequent Contributor
timestamp: December 06, 2021, 10:48:44 am
content: Quote from: ledtester on December 05, 2021, 03:48:46 pmI think I'll simply implement the RC filters suggested in the datasheet.

author: rstofer
author_rank: Super Contributor
timestamp: December 07, 2021, 02:13:29 am
content: Quote from: ledtester on December 05, 2021, 03:23:33 pmIf you follow the link above to Reply 6, I post a link to a blog that has some nice interrupt driven code:http://blog.templaro.com/reading-a-rotary-encoder-demo-code-for-atmega328/The point of using interrupts on switch edges is to remove the issues of bounce. Sure, go ahead and implement the filters but the code should get the right answer anyway.I did the same kind of thing for 2 wheel encoders on an Atmega 128 and it worked well.The nice thing about using interrupts is that there is no polling and everything happens in the background.OTOH, that code is going to take some studying.I attached my code for what it is worth. It's easier to follow but it isn't made for an Arduino.

author: james_s
author_rank: Super Contributor
timestamp: December 07, 2021, 03:40:36 am
content: Quote from: Doctorandus_P on December 05, 2021, 02:00:20 pmHow does that work?

author: Dave8266
author_rank: Contributor
timestamp: December 08, 2021, 06:15:27 am
content: Quote from: rstofer on December 07, 2021, 02:13:29 amSwitch bounce is only going to be solved if your application code handles it - that's not something inherent that comes with interrupts.A person could have just as many (or even more) switch bounce problems with interrupts as with polling - it's all in what happens in your ISR, and what your application does when it detects a change.For example, say I have an application that sends a text message to a mobile phone on each change of position of the rotary encoder, indicating which direction, clockwise or counter-clockwise, it was rotated.An interrupt handler that dutifully responds to signal edges might queue up a flurry of "CW" "CCW" "CW" "CCW" "CW" "CCW" "CW" "CCW" "CW" "CCW" "CW" "CCW" "CW" messages during the bouncing. Sure it "got the right answer" at the end - a net change of +1 direction step - but thebehaviorwas not at all what was expected - actual debouncing was still needed.

author: Kjelt
author_rank: Super Contributor
timestamp: December 08, 2021, 07:06:51 am
content: Quote from: james_s on December 07, 2021, 03:40:36 amProbably an optical colour encoder with all the colours of the rainbow.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: December 08, 2021, 07:51:27 am
content: Quote from: ledtester on December 05, 2021, 03:48:46 pmRotary encoder knobs can generate several hundreds of pulses per second, so sampling at 100Hz would be too slow. For rotary encoders I would go with either an ISR based approach or with a grey code compatible timer, and this needs cleanup of the signal, so I would add RC filters to the encoders.It's quite important here that the switches of these encoders can not short the filter capacitor. Small ceramic capacitors can deliver high peak currents which can (and will) damage the encoders.I do wonder how the do this for the UI for oscilloscopes, which can have 10 or more of such rotary encoders.

author: Dave8266
author_rank: Contributor
timestamp: December 08, 2021, 09:44:06 am
content: Quote from: Doctorandus_P on December 08, 2021, 07:51:27 amThey can in a general sense... but for a tiny 5mm encoder with physical detents, only 12 steps per revolution, and specified bounce and chatter of up to 5mseach, I'm with ledtester on this one. This just isn't an encoder you would use for a "hundreds of pulses per second" type of application. One might choose to sample faster anyway, to give some extra data to work with for debouncing, but if you have to wait for it to stabalize, the mechanical limitations will ultimately dictate the maximum reliable rotation speeds.Quote from: Doctorandus_P on December 08, 2021, 07:51:27 amI've never studied a scope schematic, but shift registers and polling makes simple work of large numbers of encoders. The oscilloscope case is a favorable one too, because there is a presumption that the operator is human - ie, unlikely to turn any knob excessively fast, and unlikely to turn more than two knobs at a time. (That's a good scenario for something using interrupts as well.)

author: Watth
author_rank: Frequent Contributor
timestamp: December 08, 2021, 10:48:10 am
content: I'll test it when I'll receive the encoder, and in real use condition (with and without the proposed RC filters), and check on the oscilloscope at what typical frequency the signals appear, and if there are some extra debouncing to do.

author: james_s
author_rank: Super Contributor
timestamp: December 08, 2021, 08:18:59 pm
content: Quote from: Doctorandus_P on December 08, 2021, 07:51:27 amTektronix used a separate microcontroller on the front panel that reads the encoders, scans the buttons and operates the indicator LEDs. I don't know what other manufactures do. Haven't there been teardowns and examination of the some of the popular entry level scopes?

author: BeBuLamar
author_rank: Super Contributor
timestamp: December 08, 2021, 09:45:44 pm
content: The link for the datasheet is broken for me so I can't read it. Is it an absolute encoder or incremental? If it's incremental it wouldn't have gray code.

author: Watth
author_rank: Frequent Contributor
timestamp: December 08, 2021, 10:41:14 pm
content: Does it work now?https://www.ttelectronics.com/TTElectronics/media/ProductFiles/Datasheets/EN05.pdfIt is incremental with 2 bits Gray code.

author: BeBuLamar
author_rank: Super Contributor
timestamp: December 08, 2021, 11:53:04 pm
content: I have never heard of 2 bit gray code. Reading the datasheet I would call the output quadrature.

author: Dave8266
author_rank: Contributor
timestamp: December 09, 2021, 09:17:28 pm
content: Quote from: BeBuLamar on December 08, 2021, 11:53:04 pmIs this one of those "All thumbs are fingers, but not all fingers are thumbs" situations?Just like how a four-position quadrature encoder is both incremental and absolute...