This looks awesome. I’m going to try building one this evening. It’s interesting reading the comments from 14-15 years ago, the capacity for hobbyists to do such things today is so much greater, even just since 2010.
that's interesting. the switch from vinyl to any of the other controllers was a very long time for me because I did not like the feel of any of the control surfaces at the time. the CDJ100s feel like fisher price toys which is probably what kept the prices a fraction of the CDJ1000s which had a much more acceptable feel. some of the digital only devices have gone back to that cheap light plastic feel with just a horrible bit of resistance.
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 remember back in the day NI had a box that worked with traktor that came with some special vinyl records that had encoded signals built on it. You ran the output of the record players into the 'traktor box' and it would turn this into positional information for traktor .. seems like they still make the records: https://www.native-instruments.com/en/catalog/hardware/trakt...
I think the product, back in the day, might have been called traktor scratch.
I was just going to post about this! Not this particular project but the fact that most of us have old hard drives lying around that we could turn into rotary input device!
This is cool. I wonder how hard it would be to drive the motor just enough to compensate for friction so that it would spin forever at whatever speed you leave it instead of slowing down when you're not touching it.
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 made something like this pretty recently, though it was with an ESP32, and it was bluetooth, and I used a mouse driver. It was cool, though I did kind of grow a hatred for the Arduino "poll the pins in the loop" way of doing things. It would kind of work, but the problem would be that if you spun the knob too quickly, it would actually end up going backwards because you're effectively spinning faster than it can sync.
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 can set a gpio pin mode to PULLUP, and there’s a function built in to the freertos/arduino stuff for the ESP32 to convert that gpio pin signal to an interrupt. From there you can pass in a function pointer to run upon receiving the interrupt.
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.
There is also a very simple and straightforward chip that will convert quadrature to pulses. Ls7183n. It's kind of unnecessary if you can write your own interrupt handlers but it's useful if you're just working with discrete electronics
The LSI-Logic encoder interface chips are nice if your encoders are running at thousands of RPM. You also have to jump though a few more hoops than just an online order (I use an LSI device in a machine tool reconditioning product), so it's not particularly hobbyist-friendly. I'd be hard pressed to imagine anyone using them if they didn't absolutely have to.
Huh... I'm a hobbyist and I got them at digikey for about $5/chip. It ships in a couple weeks directly from LSI. My personal goal was to eliminate one microcontroller from my project. I would probably not use one in the future as long as my project had even a basic microcontroller.
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.
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).
It's a fun exercise in which I think you'll find polling to be fine for many Arduino cases. Not as much for raspi and higher level in my limited experience for various hardware reasons and overhead. And quickly when you do other stuff, especially blocking high level communication, polling does suffer. But interrupts exist and are a reasonable level 2 for people to learn.
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.
>> if you spun the knob too quickly, it would actually end up going backwards
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...
I might be missing something but I think the author of this library missed a very simple implementation.
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.
It was refreshing to see an off-the-shelf project box on the parts list rather than 3d printing it. I'm in the middle of a multi-day printing spree for a project and am learning to appreciate that not every generic box needs to be 3d printed.
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.
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."
If the encoder is like a wheel with 24 "teeth" a single LED/detector could tell you when it became blocked, when it became unblocked (by a tooth). There's 48 states already.
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've been eagerly awaiting the day when I can buy one of these: https://github.com/scottbez1/smartknob (or when building one myself doesn't require any soldering more advanced than thru-hole).
Nicely done. Back in the day, I actually used to convert the midi signals from a rotary encoder knob on one of my AKAI into a MAME input just so I could play Arkanoid.
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.
And Arkanoid had 486, which made me fear this project wouldn't have enough resolution for decent gameplay, yet it works perfectly (for my standards, at least).
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.
38 comments
[ 7.1 ms ] story [ 141 ms ] threadcan't beat how smooth it is.
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.
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.mikrocontroller.net/articles/Drehgeber is an excellent article (in German, Google translate is fine afaik. Check the interrupt section
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.
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...
https://www.pjrc.com/teensy/td_libs_Encoder.html
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:
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.
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.
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.
https://www.tindie.com/products/bittradeone/rev-o-mate-bfrom...
Incredibly useful in my line of work.
https://en.wikipedia.org/wiki/Kaboom!_(video_game)
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.
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.