rotaryio does not work properly with half-cycle-per-detent encoders

[evildave666]

They are not as common as other types, but encoders with a half cycle per detent do exist and I have actually picked up a few recently (in my defense all documentation from the seller was in japanese, which though I can read it, isn't my native language).

With the current rotaryio they only advance once every 2 clicks.

It would be nice to be able to support them with an option in the constructor.

[dhalbert]

We support rotary encoders that do Gray code output (the two outputs change alternately). This allows reliable detection of transitions without debouncing. I don't know about yours, but perhaps it does Gray code every other click. A link to the datasheet for yours would help us figure it out.

[dhalbert]

This may be a dupe of #1677.

[evildave666]

I've managed to find the original (chinese) documentation, and indeed it is a half-cycle encoder (30 detent, 15 cycles).

https://img.alicdn.com/imgextra/i4/2452639374/O1CN015RoFrP2J7LDRRvmY3_!!2452639374.png

To properly support it, rotaryio would need to output on both 00 and 11 states, not just 00. I understand there would be a loss in debounce reliability in such a mode.

I posted this in discord but this may help illustrate the H mode this particular encoder is operating in:

[ladyada]

this is kinda more like a motor encoder than a rotary encoder (rotary encoders are a subset of motor encoders that can stop at any point)

[evildave666]

Yes, this does seem to be a duplicate of at least part of that earlier issue (though that one seems to be muddled with people reporting unrelated problems.

FWIW, the encoder I'm trying to use is supposedly an exact replacement of the one used in Panasonic car stereo volume knobs, so its definitely being purposed as a regular rotary encoder.

Looking deeper I see that rotaryio is implemented per-architecture which seems to make this a major undertaking.