A couple of years ago I designed a DDS generator which required a rotary encoder and it was important that the device recognised the encoder direction without fail, and didn't matter too much if it missed the odd pulse, e.g. if you turn the control really fast. I tried all sorts of 2 wire approaches but never seemed to get exactly what I want. The solution which eventually worked perfectly was to have the encoder set either one of a pair of D flip flops (74HC74) depending on direction, this generated an interrupt (port B on a PIC18F4620), the interrupt routine reads the state of the flip flops (01 or 10 depending on direction) drives a 3rd I/O line to reset the 7074 to a 00 state and re-enables interrupts. This approach worked, did not generate false readings, and can get encoder info very fast if that is required. The only downside is you need one extra I/O line to reset the 7074. As an aside port B also reads a 4x4 keypad using interrupts, the 7074 outputs are coupled via an RC network to RB7 & RB6. Charles -----Original Message----- From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of Josh Koffman Sent: 06 September 2009 00:55 To: Microcontroller discussion list - Public. Subject: [PIC] Encoder Oddness Hi all. I've been working on a new project using mechanical rotary encoders. I wrote a new encoder reading routine based on the info I found in this document: http://www.tufts.edu/programs/mma/emid/RotaryEncoder.pdf. The method is to compare the LSB of the current reading to the MSB of the last reading, XOR them together, and from there you will be able to determine an up or down motion. It works quite well. A bit too well in fact... For each movement of the encoder I'm getting too many events in my code. From my understanding of the datasheet it should be one detent = one pulse. For each detent I currently get about 4 events. I've written the manufacturer of the encoder just to double check, but I'm guessing the problem lies in my work somewhere. I'm currently in Brazil so I don't have access to my scope or analyzer so I can't verify if I'm actually getting more pulses than I should be. Is it possible I'm getting contact bounce on the encoder and my code is reading those as turns? What's interesting is that it's almost always 4 events. I call the routine in a timer trigger interrupt, and I've played with the values just to see what would happen. I expected that the number of extra events would change, but it seems to always be 4. Occasionally it's 3, but only rarely. Does anyone have any suggestions on what might be going on and how I might be able to fix it? 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 -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist