Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Double input #4

Open
SebDominguez opened this issue Dec 16, 2019 · 9 comments
Open

Double input #4

SebDominguez opened this issue Dec 16, 2019 · 9 comments

Comments

@SebDominguez
Copy link

I'm opening a new issue to hopefully get more visibility there...

Having a similar same issue:
inc_callback, dec_callback& chg_callback get called multiple time for each "steps" of my rotary encoder. sw_callback is called once as expected. I tried to change the polling_interval, but this seems to make things worst as if I keep turning the encoder clockwise I'll get the counterclockwise callback executed.

ezgif com-video-to-gif

Adding logger.info(self.polling_interval) on pyky040.py at line 47 and 133 give me the following output:INFO:root:5

Maybe this is due to the cheap construction of the rotary encoder module? I'm using those one (I thing you are using the same one)

iu-1

With the threaded example the callback get called only twice

2

this is the code I run

# Import the module and threading
from pyky040 import pyky040
import threading
import time

# Define your callback
def up_callback(scale_position):
    print("up")

def down_callback(scale_position):
    print("down")

def pressed_callback():
    print("pressed")

# Init the encoder pins
encoder = pyky040.Encoder(CLK=5, DT=6, SW=13, polling_interval=5)

# Setup the options and callbacks (see documentation)
encoder.setup(scale_min=0, scale_max=100, step=1, inc_callback=up_callback, dec_callback=down_callback, sw_callback=pressed_callback)

# Create the thread
my_thread = threading.Thread(target=encoder.watch)

my_thread.daemon=True

# Launch the thread
my_thread.start()

# Do other stuff
print('Other stuff...')
while True:
    print('Looped stuff...')
    time.sleep(10)
# ... this is also where you can setup other encoders!

Well I just received another rotary encoder (PEC16-4220F-S0024) and I still have this issue

Originally posted by @SebDominguez in #1 (comment)

@raphaelyancey
Copy link
Owner

raphaelyancey commented Jan 15, 2020

I'm currently working on a rewrite of the library using Linux device tree. It's got an instant response and doesn't miss anything anymore.

Downsides are that there will be a breaking change in the API, and that the encoders must be setup on the Pi before being available in Python scripts (i.e. they would have state).

Take a look at the evdev branch for a very early idea.

@raphaelyancey
Copy link
Owner

raphaelyancey commented Jan 22, 2020

@SebDominguez I just tested the code, and it seems it's your pins choice that is causing trouble. Try with CLK=26, DT=4, SW=21 and tell me what you get. If it's also working fine with these pins, maybe it's some kind of interference between neighbor pins?

@SebDominguez
Copy link
Author

Ok I'll try this ASAP. I choose those pins because I saw you also used them on your other project. I assumed they was safe to use then.

@raphaelyancey
Copy link
Owner

raphaelyancey commented Jan 22, 2020

You're right it did work on the radio, but somehow I also got erratic behavior with these pins on a RPi 3B with Raspbian Buster. Maybe something has changed (kernel, GPIO handling...) since I wrote the tutorial.

@SebDominguez
Copy link
Author

Yes I also experimented erratic behavior on buster (ghost triggering on GPIO using add_event_detect from RPi.GPIO) I didn't tested on stretch to see if this was caused by the update

@raphaelyancey
Copy link
Owner

If you still experience the issue after changing pins, I updated the library on the evdev branch with the new device mode. I'd love some feedback when you'll have the time to try it!

@SebDominguez
Copy link
Author

ezgif-6-70cd4a3c8746

sadly I've tried swapping the pins and also downgrading to stretch but unfortunately I'm still experimenting the double input from the rotary encoder

@raphaelyancey
Copy link
Owner

raphaelyancey commented Jan 22, 2020

Does the output make sense, apart from the fact that the callbacks get executed twice? In other words, do the right callbacks get executed (twice) each time you interact with the encoder?

@SebDominguez
Copy link
Author

Yes the up callback is executed twice for each clockwise steps and the down callback is executed twice on each counterclockwise steps. At no points a clockwise rotation called the down callback. same for the counterclockwise rotation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants