dead spot at max and min boundaries when wrap set to false

[Cat30Mk3]

Using your example "BasicRotaryEncoder.ino", with wrap set to false, when counter reaches max or min boundary, the first step in opposite direction does not generate an interrupt. This applies to both max and min boundaries.

[Cat30Mk3]

Hi Mathew, I just discovered your "LeftOrRight.ino" example, and confirmed it presents the same issue:
stepping the encoder clockwise functions correctly, (continuously raising interrupts and reporting "Right ->") but the first step counterclockwise IS LOST EVERY TIME. Then, as I continue counterclockwise it functions correctly raising interrupts and reporting "<- Left". Then the first step clockwise IS LOST EVERY TIME. I'm using a basic encoder without VCC pin, and an ESP32-WROOM-32E. EncoderType::FLOATING

[cwkowalski]

I just setup this library to test an EC11J rotary encoder (a 5-pin with a switch) on an ESP32-S3. I have a similar, but not identical issue-- it only counts every other rotation of the encoder. Otherwise, it's a brilliantly easy and lightweight library. Perhaps this is because of the encoder type, I'll investigate further.

[MaffooClock]

@Cat30Mk3: Interesting observation.

I've got a couple of commits to push, and there's a chance that this would be fixed in those (I haven't investigated thoroughly), so I'll take care of those and then test for this...

[MaffooClock]

@Cat30Mk3:

I was able to observe exactly what you reported: the first turn in the opposite direction of the previous turn was being ignored. But before I could begin investigating, I noticed that a proposed change in issue #4, which turned out to be invalid, seemed to magically resolve this issue.

I didn't take the time to understand why it fixed the problem, though. But as I mentioned in my comment, the resolution was repeatable: the "dead spot" behavior returned after reverting the change, and resolved again after re-applying the fix. Of course, I'd like to know why this seems to have fixed it, but I'll just take the win 😎

@cwkowalski:

I looked at the EC11J rotary encoder datasheet and compared it to the KY-040 I've been using. Other than physical form, the only difference seemed to be the number of detents/pulses, which wouldn't matter to this library (it only cares about the transition from one detent to the next).

If you have the raw encoder instead of a pre-built module, I assume you added the pull-up resistors to the A and B pins (to 3v3) and C is grounded. So I wouldn't have any idea why it would behave in the way you describe.

Regardless, I'm going to assert that the problem you are experiencing is not the same as what was originally reported in this issue.

[Cat30Mk3]

Hi Mathew! That’s really good news! I will give it a go over the next week and let you know. John From: Matthew Clark ***@***.*** Sent: Friday, January 31, 2025 10:17 AM To: MaffooClock/ESP32RotaryEncoder Cc: Cat30Mk3; Mention Subject: Re: [MaffooClock/ESP32RotaryEncoder] dead spot at max and min boundaries when wrap set to false (Issue #5) @Cat30Mk3 <https://github.com/Cat30Mk3> : I was able to observe exactly what you reported: the first turn in the opposite direction of the previous turn was being ignored. But before I could begin investigating, I noticed that a proposed change in issue #4 <#4> , which turned out to be invalid, seemed to magically resolve this issue. I didn't take the time to understand why it fixed the problem, though. But as I mentioned in my comment <#4 (comment)> , the resolution was repeatable: the "dead spot" behavior returned after reverting the change, and resolved again after re-applying the fix. Of course, I'd like to know why this seems to have fixed it, but I'll just take the win 😎 @cwkowalski <https://github.com/cwkowalski> : I looked at the EC11J rotary encoder datasheet <https://cdn-shop.adafruit.com/product-files/5454/5454_1837001.pdf> and compared it to the KY-040 <https://www.amazon.com/dp/B06XQTHDRR> I've been using. Other than physical form, the only difference seemed to be the number of detents/pulses, which wouldn't matter to this library (it only cares about the transition from one detent to the next). If you have the raw encoder instead of a pre-built module, I assume you added the pull-up resistors to the A and B pins (to 3v3) and C is grounded. So I wouldn't have any idea why it would behave in the way you describe. Regardless, I'm going to assert that the problem you are experiencing is not the same as what was originally reported in this issue. — Reply to this email directly, view it on GitHub <#5 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACDDBDCCUZSWQ7P4MFGTVI32NOHVNAVCNFSM6AAAAABVXSEMCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMRXGU4TCMBZHE> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/ACDDBDCDTX3IUZPS5JFXEGT2NOHVNA5CNFSM6AAAAABVXSEMCOWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTU4TXN3W.gif> Message ID: ***@***.***>