Closed discoHR closed 6 years ago
The cheap encoders most people are using move through all four states in every click, ie both outputs are HIGH at every detent, and you merely look for which output goes LOW first to determine direction.
This 4-phase behaviour you observe seems to be a different style of encoder. Maybe I should support it. Perhaps it gives more accurate readings (the cheap ones can give odd results from time to time).
Can you send me one, or point me at a sale listing on Ebay, for example?
The one I have is an optical encoder of much better quality than the cheap ones like KY-040. You feel every click loud and clear. As you can see on the photo the signals are super clean. I have only one I'm using, got it from Mouser. There are similar Grayhill models on eBay but they're even pricier than this one at Mouser. Farnell doesn't have them. I can test it for you if you send me an UPD file. https://www.mouser.com/ProductDetail/706-62AG11-L5-060C
Try this updated firmware, with this line in FF.CFG: rotary = gray
Wow, you're fast. Thanks, will test it soon and report back.
It doesn't work properly. It reacts immediately on every click as it should but it looses track of direction. For instance, if I rotate in the same direction then selected slot behaves as this: 1, 2, 1, 0, 1, 2, 1, 0. Same issue with opposite direction, it's just in reverse order. If I alternate direction after every click (CW, CCW, CW, CCW, CW, CCW etc) then it goes up 1 slot at the time, every time. There are 7 folders in the current folder. Should be like this (starting from zero): 1, 2, 3, 4, 5, 6, 0, 1, 2, 3 etc.
So it does (just wrote a test harness).
Okay, try this one:
I just tried ff_50_2.zip, it works perfectly! Thank you so much.
Should I try ff_50_3.zip too? What's the difference?
I simplified the code a bit for ff_50_3. Please test it as that is what I will commit to master.
ff_50_3 is not good. It behavas the same as before this request: slot changes every 4 clicks. Yes, i have rotary = gray in FF.CFG.
Should have left it alone. Amusing I came up with a bug that would not occur in the test harness (on x86 system). Try this one.
Perfect! Feel free to commit it to master. Thanks again.
Thought this might have fixed an issue I was having with an encoder I purchased off ebay, but unfortunately not. I went for this encoder since it had a knurled spindle that works better with the various knobs that you can also buy cheaply off ebay:
edit - these are the ones that don't work:
and these are ones I bought later that do work:
with the original encoder I bought, FF steps back through the files no matter which direction I turn the dial. Sometimes FF misses the step altogether.
Decided to hook up my new scope to see what was happening. I'm still a bit new to the scope, so apologies if this is not right:
Clockwise rotation:
Anticlockwise rotation:
The yellow trace is connected to DK and the blue trace is connected to CLK.
Let me know if you would rather I raise a separate ticket for this query
@kgl2001 this ticket is fine, but needs to be reopened (now done).
Looks like there is only a phase difference on trailing edges of the signals, not on the leading edges (which is what FlashFloppy triggers on). I can add another rotary= option and get you to test it.
I'm probably not understanding the 'leading' / 'trailing' edge terminology correctly, but is it that there is a phase difference on leading edge for clockwise rotation, and phase difference on lagging edge for anticlockwise rotation?
Oh yes you're right, sorry. Normally there would be a phase difference on both edges, and which signal leads would indicate the direction the knob is turning.
Al the same I think it would work to trigger on rising edge rather than falling edge (as currently). But also... this is the first report I've had of this behaviour. Maybe the encoder is duff.. they are cheap and cheerful. You bought a bag of five so have you tried another?
Yeah. I've tried two encoders and both were the same. I've only hooked one up to the scope, though.
Ok, try this modified firmware. No need to configure anything in FF.CFG (yet):
Another suggestion: did you try swapping the CLK and DT connections?
yes. tried swapping CLK and DT around, but that didn't make any difference. Again. I never tried this with the scope hooked up, though. Will try the test firmware now...
I also have some very similar rotary encoders that I still haven;t tried out, but 15mm rather than 20mm handle. Perhaps I should give one a go.
Happy to send one of my encoders to you if it would help. Just tried the latest file, and it now steps up through the files when rotated in either direction (previously it would step down). It misses a few pulses along the way - it sometimes takes a few steps of the rotary encoder before anything is registered. This also happened before with the older firmware, so that's nothing new.
I'll try mine first and see how that goes. If they work, you may just have to try some other Ebay seller. I have heard no other reports like this, and there are quite a few people doing encoder mods.
Yeah. I agree. I ended up buying a different set, and they work fine.
Apologies - the link I posted above is for the set that actually works. The ones that didn't work were these:
EC1601? I don't have any like that... I might document that they don't work if I get any further reports on that specific model.
Currently FF waits for 4 edges/clicks of the encoder (complete code) to take action (move to previous/next slot). As result, it takes "forever" to get anywhere in a folder with hundreds of files and, to be honest, my hand starts to hurt. :)
This could be improved if the state was saved. For instance whenever there is a change on any of the two encoder outputs, remember which of the two signals toggled last and take appropriate action immediately. I've labeled clicks with numbers (1-4) on the photo.
It would be best to add a new config parameter which would specify after how many signal toggles FF takes an action. Value of 4 could be default so it doesn't mess with slow response people are used to.