hello,
I have a mcu(MSP432e401y) thats interfacing with a rotary encoder(PEC16-4025F-N0024) the encoder is there to only scroll a selection bar depending on rotation direction,and use the momentary switch in the encoder to select on a tft display screen.Iam using the mcu's built in rotary encoder module to read its inputs,the module also has a programmable filter circuit which iam using.The encoder module has drivers that will get the rotation the encoder is spinning in my case a -1 is read when the encoder is rotated CCW and a +1 is read when the encoder is rotated CW.

The problem iam having is the reliability of reading a encoder value, i get a ghost trigger values which say i rotate the encoder CW one click i get +1,-1 per click it also does this when the encoder is rotated CCW expect the values are -1,+1.Iam not sure exactly were to start iam pretty new to interfacing mechanical devices to electronics.I dont know if it would be software related or my hardware circuit also note iam prototyping it on a mps launchpad,and breadboard.So far i have only tried debouncing the piece of code but with no success,i havent changed much on the circuit.Any input is appreciated it thanks

 

Contact Bounce (15 RPM)........................................................................................................................................................................5.0 ms. maximum**

Be sure your debounce code meets this spec and there are pull-up resistors (configured via the gpio or externally) to the normal input high voltage on the A/B pins. This looks to be a dry switch that doesn't supply a voltage signal from the encoder.

 

I don't know this particular encoder, thanks for the link I had a look,
its a real low cost mechanical switch type encoder.

as @nsaspook says, these type of encoder are a very good source of bounce on a switch.
a switch bounces because its mechanical, a bit of metal under tension, as it clicks between '1' and '0' , it bounces, leading to multiple short '1' '0' till it settles down,

Try the highest level of debounce the MCU lets you, and work back ,

Just to highlight, the encoder direction is determined by the difference between the two outputs of the encoder,
you do have both connected to the decoder, and the decoder is in the right mode ? There are multiple types of encoders that the MCU can normally support, and if you have the wrong type, that could also account for the ghost pulse.

 

Thanks for the replies i forgot to mention my circuit uses bourns suggested filter circuit in the diagram in the part datasheet,i've set the debounce delay past its recommened 5.0ms the max i tried is in the range of 100ms and still get the false triggers.The QEI module is setup to use its phase a,and phase b pins.

 

which mode do you have the decoder set for

 

I do not have a full solution to the task, but 10+ years ago I wrote programs for this type of mechanical contact encoders. And it was without hardware quadrature support and with full four count quadrature decoding.

I no longer have access to the C code samples from that time, but it was something about making a software hysteresis on one count from the signal to the counter variable. This allows the quadrature signal to be tilting between two values without the counter changing value.

 

I've just checked on the Ti forum site for the MCU,
there are a few other mentions of difficulties setting up the built in rotary decoder of the MCU,
may be try out there,

At least with the built in decoder, you don't need bunch of C code and interrupts to get it to work.

 

I've just checked on the Ti forum site for the MCU,
there are a few other mentions of difficulties setting up the built in rotary decoder of the MCU,
may be try out there,

At least with the built in decoder, you don't need bunch of C code and interrupts to get it to work.

The hardware module seems almost wasted for this application. A two-bit state with two-bit memory machine doing 1X decoding from 1 IOC pin and one state pin should work.
https://en.wikipedia.org/wiki/Incremental_encoder#State_transitions

 

@nsaspook,
If its built in , does all the denouncing, and interrupts for you, why not use it.

 

@nsaspook,
If its built in , does all the denouncing, and interrupts for you, why not use it.

I use the QEI module when it's an option on the controller but usually for the full high speed encoder suite that needs position, velocity and speed registers for programming parameters but this is just CW/CCW at finger turn speed. I suspect it's just a module config option or setup not quite right as most of the time the QEI module works at the default settings on most systems.