Spinner-mouse: Arduino-based USB rotary controller for Arkanoid, Tempest, etc.
github.com
github.com
Yeah. I've gotten tired of replying to the myriad "how can I 3D print an enclosure for my project?" questions that electronic enclosures are a mature product category and there are literally hundreds of thousands of varieties available off the shelf at prices your 3D printer can't touch.
Need something with weird custom shapes that likely no one else has ever needed? Go ahead and 3D print.
Need a generic box-like thing, with or without a clear cover, made from a wide selection of materials, with or without ingress-protection ratings and/or hand held, wrist-mounted, rack-mounted, desktop or wall mounted, or clipped to a belt strap in enough variations and sizes to make your head spin? Buy it off the shelf.
I'm willing to bet that 9 times out of 10, for a hobbyist product, a Hammond-1551 variant will do just fine.
I need to find more resources for robust buttons, switches and knobs for building instruments for disabled musicians using the Instrument Maker framework. (https://instrumentmaker.org/)
The look and feel of these instruments it incredibly important for artistic performance, and we're hoping to find off-the-shelf options for various buttons/switches rather than fabricating our own.
can't beat how smooth it is.
* https://github.com/carlosefr/DisKnobUI
* https://www.youtube.com/watch?v=MvpPVjJnbao
It thought about using that (the spindle motor from a hard-disk) for this project. The issue is that it's not very precise at very low speeds. It sort of works, but it falls out of sequence too often.i often wonder how people tolerate it, but then i realize most people don't know what it was like playing vinyl and have nothing to compare to.
I think the product, back in the day, might have been called traktor scratch.
I ended up having to learn how to use the FreeRTOS interrupts. It was a bit harder but it was a much better play experience.
You should be using interrupts for encoders. The standard Encoder library uses interrupts.
https://www.arduino.cc/reference/en/libraries/encoder/
In my experience on an ESP8266, it can do over 300kHz. Probably faster on an ESP32. For ESP8266, just remember to set ICACHE_RAM_ATTR for the ISR. Not sure if ESP32 is the same, but it probably is.
So you'd need to be turning those encoders pretty damn fast for the interrupt speed to become a problem.
https://www.mikrocontroller.net/articles/Drehgeber is an excellent article (in German, Google translate is fine afaik. Check the interrupt section
The spinner on arcade Tempest can do the same. IIRC the quadrature signals feed the clock and direction pins on a 4 bit up-down counter on the board, and software probably polls the counter. If you spin it fast enough (I used Teflon spray on mine) you could wrap the counter around and get it to move backwards. Something like that, it's been a few years...
This library is hundreds of lines of assembly for implementing some jump table for all possible input combinaisons.
I propose instead to shift left the two inputs into a 8 bits accumulator. And then there are only 3 states to match. Inc, Dec, Invalid (happens if you jiggle the encoder in place, effectively doing halfinc/halfdec).
Something like that:
sw = A << 1 | B
if (state & 3 != sw)
state = (state << 2) | sw
state == 0b00101101 for increment
state == 0b01111000 for decrement
Any other state is ignored.If this code runs on interrupts, the conditional can be skipped if spurious interrupts are not possible.
Any switch bounce can be filtered either in hardware (capacitor + resistor), or in software by averaging over time.
The rotary encoder I bought simply applies pulses to one pin when spinning clockwise, and another pin when spinning counter clockwise, so I just attached the interrupts to two separate gpio pins, and sent the updates to the mouse stuff directly in the interrupt handler. I simply moved the mouse N units to the right or left if going clockwise or counterclockwise.
I’m sure it’s not ideal but it worked to play breakout. I’m still a little new to the world of microcontrollers so it’s possible that I did something dumb.
That said, they work very well.
I just checked and the LSI7366R (the version I use) is now available through Digi-Key. They have really expanded their Marketplace program. I used to have to buy them directly from LSI: it wasn't a big deal to setup an account with them, but it's nice to know that next time I can just piggyback it onto my Digikey order. Although if the delay is a couple weeks I'd have to plan ahead. They typically get them to me in a couple of days.
That would have saved me a chip :) as my project was basically an encoder-driven 8-bit binary counter.
My original design was based on an Arduino Nano with an AtMega328. Originally it was designed to read 0-10-0V position signals. This is from really old machine tools :-)
Processing encoder inputs was a much later change. With the rate of interrupts coming in from a high-resolution encoder turning at 3,000 RPM, there was no way it would keep up and still do all the processing needed.
The product volume wasn't high enough to make it worthwhile moving to a processor that had the timer/counter resources to handle it in hardware, so the simplest solution was adding a $6 chip (and a $2 differential interface chip to handle the differential encoder output channels).
https://www.tindie.com/products/bittradeone/rev-o-mate-bfrom...
Incredibly useful in my line of work.
Following the wikipedia link from the README: https://en.wikipedia.org/wiki/Incremental_encoder
helped me develop a little bit of understanding and it confirmed my suspicion about 96 = 24 positions * (2 output pins / 4 states).
Asking an LLM next, provided this sentence:
"Resolution Increase: By detecting both the rising and falling edges of both channels' signals, you effectively multiply the basic steps per turn. Each step in one channel can be subdivided into four phases (A rising, B rising, A falling, B falling), which leads to the increased resolution. Here’s the math: 24 steps * 4 (due to the four phases per step in quadrature encoding) = 96 steps per turn."
You put another LED/detector just a half-tooth out of phase with the first detector and you not only doubled the resolution, but you can tell direction as well.
I'm not sure why Arkanoid's spinner had so many steps. It can be to allow for pixel-by-pixel movement on its 336 pixel horizontal resolution, but it can also be because the way they were polling the encoder might miss some quadrature steps and they needed the extra resolution to ensure smooth control. Perhaps a combination of the two.