The world of custom mechanical keyboards is vibrant, with new designs emerging weekly. However, keyboards are just one way we interact with computers. Ploopy, an open-source hardware company, focuses on innovative user interface devices. Recently, [Colin] from Ploopy introduced their latest creation: the Ploopy Knob, a compact and thoughtfully designed control device.
At first glance, the Ploopy Knob’s low-profile design may seem unassuming. Housed in a 3D-printed enclosure roughly the size of a large wristwatch, it contains a custom PCB powered by a USB-C connection. At its core, an RP2040 chip runs QMK firmware, enabling users to easily customize the knob’s functions.
The knob’s smooth rotation is achieved through a 6705ZZ bearing, which connects the top and bottom halves and spans nearly the device’s full width to eliminate wobble. Unlike traditional designs, the Ploopy Knob uses no mechanical encoder or potentiometer shaft. Instead, an AS5600 magnetic encoder detects movement with remarkable precision. This 12-bit rotary encoder can sense rotations as fine as 0.088 degrees, offering 4096 distinct positions for highly accurate control.
True to Ploopy’s philosophy, the Knob is fully open-source. On its GitHub Page, you’ll find everything from 3D-printed case files to RP2040 firmware, along with detailed guides for assembly and programming. This transparency empowers users to modify and build their own versions. Thanks to [Colin] for sharing this innovative device—we’re excited to see more open-source hardware from Ploopy. For those curious about other unique human-machine interfaces, check out our coverage of similar projects. Ploopy also has designs for trackballs (jump up a level on GitHub and you’ll see they have many interesting designs).
I love the idea, but I’m interested in what everyone’s use cases are… plus where’s the love for kmk?
jog wheel for my video editor
I’d personally use rotating right for Tab, and rotating left for Shift+Tab
On their site:
“Everything is open-source
Source files for STEP files, PCB design files, […]”
Me: Ah cool, curious to see what CAD software they use… And no native CAD files!
Me: checking another product… Again no native CAD either,p only STEP/STL
Did I miss something?
Seriously anybody that has made a bit of CAD knows that designing or modifying a part is made possible via sketches, constraints, various tools, succession of tools in an order or another, parameters, etc. Fusion is called parametric CAD for a good reason. STEP/STL are compiled files, not the easy to edit (yes step is easier still not easy), and they remove all the logic and tooling that makes CAD design easier. Similarly you can export STL with OpenScad or STEP with CadQuery, doss it means the source code is the STEP/STL? Clearly no! As CAD become so easy that you can reverse engineer the STEP to make the modifications according to the rules/constraints/parameters set by the author? Clearly no (unless it’s a super easy design and then I’m ok with STEP!
Could we please share native CAD files (or source code in case of CadQuery/OpenScad) or stop calling those hardware project open source?
(And yes share STEP/STL in addition to native CAD for convenience and interoperability)
You are upset that they freely gave away their work in an industry standard format that you personally do not approve of is that what I am to understand. That is like saying a musician is giving away all their music in mp3 format but you are upset that it is not in a different format of your choosing. STEP IGES and STL are pretty much standard and if you do not like it i hate to say it sorry. and yes their project is open source.
I’m with Meeeee, the clue is in the SOURCE bit of open source, if you’re giving away precompiled binaries then the source is not open.
I may be wrong, but I think the UF2 is from their QMK fork which is just one level up on GitHub: https://github.com/ploopyco/qmk_firmware
Is there more to it than that?
Maybe it will appear in future, I did not find it there, just trackball and mouse firmware.
Although their mouse is intriguing, wonder if I could fix my old Razer mice with a custom PCB, (maybe even just soldering a PICO clone inside XD ). Between the hardware bug that makes it think a button is pressed, the lack of any settings stored onboard, and a huge driver that needs an online account to change simple settings I loath Razer. Build quality and sensors are OK though, hard to compete with a new working EVGA X12 mouse for $10-15.
Here’s the firmware branch for the knob:
https://github.com/ploopyco/qmk_firmware/tree/ploopyco/knob
Here’s the instructions for building the firmware:
https://github.com/ploopyco/knob/blob/master/docs/appendices/programming.md
I am going to guess that all the folks whining about “it’s not open source and I am too lazy to figure out it is” are never actually going to compile something or take advantage of something being open source. Ultimately this “gate keeping” stuff is detracting from the community and potential discouraging future open source contributors.
(PS: I took like a minute to find the code and instructions….)
Really? Where did you find the source code? Specifically for the Knob, specifically, you know, source code, as in C or C++ files? In what subdirectory? The “instructions for building” looks to me like instructions for uploading the compiled binary into the Pico.
@BrightBlueJim
Did you check out the links I posted? The second link provides instruction for BUILDING and COMPILING the firmware (not just up loading a compiled binary).
Do you need spoon-fed?
Well, here, this is Ploopy code:
https://github.com/ploopyco/qmk_firmware/tree/ploopyco/knob/keyboards/ploopyco
You can find a directory called “knob”, as well directories for all their other OPEN SOURCE products.
But you need C files or it can’t possibly be open source? Here is a C file for something important:
https://github.com/ploopyco/qmk_firmware/blob/ploopyco/knob/keyboards/ploopyco/common/as5600.c
You know, there’s a nice way to communicate.
Irox: To be clear, I asked because as much as I looked in the github tree for Knob, and also in qmk-firmware, I did NOT find the source code for the Knob. So yes, I guess I DO need to be spoon-fed, but I will also say that your response wasn’t helpful, in that I had already looked in those (obvious) directories, and you didn’t include a link to the actual knob.c (or whatever), suggesting that perhaps you didn’t find it either. Perhaps because it wasn’t worth your while, or maybe you did find it and are withholding it intentionally or spitefully?
I did see the “build” instruction, which apparently uses a utility included with qmk called qmk. I have never used qmk, so it’s hard to determine from this what other downloads are required. I apologize if I’m asking too much, but the case for me is that I like to download code that I think may be useful even if I don’t have an immediate application for it, and downloading code with obscure dependencies makes that code a waste of disk space, and if qmk requires specific configuration files, then this only leads me to wonder where I would look for the configuration file for the Knob. I see in the qmk-firmware tree lots and lots of examples, which ARE in the form of .c files, but still no “knob.c” or anything obvious like that. If I AM asking too much, I would not be offended if you simply declined to respond.
Thanks for your response BrightBlueJim. I’ll try to provide an information good faith response.
First off, some background info. QMK is a popular open source firmware (framework) for powering keyboards, mice, macro-pads, trackerballs and many other input devices. This comes with a whole bundle of tools for creating, configuring, compiling, debugging, etc. your DIY input device. It is a really cool project and removes a lot of the harder work when building an input device. Note, many of the QMK devices are just config files and header files (QMK abstracts away lots of work, so often now device.c file). QMK has also been featured on HaD a fair bit: https://hackaday.com/blog/?s=qmk
Second, the code part. The actual knob.c is more of a bunch of config files (see above). Probably most exciting body of code for you would be:
https://github.com/ploopyco/qmk_firmware/blob/ploopyco/knob/keyboards/ploopyco/ploopyco.c
The entry points for initialization are:
pointing_device_init_kb
keyboard_post_init_kb
keyboard_pre_init_kb
The main polling for the scroll wheel sensor is:
pointing_device_task_kb
These are all standard QMK (re)entry points, so folks don’t have to write all the boiler plate each time they make a custom device. It’s really neat. You can find the sensor interaction calls be searching for “get_rawangle” (this is in the as5600.c file I linked to earlier).
Third, Ploopy is awesome. I’ve been following Ploopy for a while (I’ve been designing my own trackball and thinking of using their hardware), they are true open source believers. They are definitely the good guys here, and backing our right to repair. They deserve praise, gratitude and positive attention.
Fourth, I apologize for my tone.
Even after I posted links to the source code, you still posted claims that Ploopy’s knob is not open source. So yeah, that ticked me off to see misinformation spread by people in the maker/hacker community. Especially when others start reposting the same false information. Again, I apologize for my tone. In the same spirit, please also review your tone. You jumped to conclusions without proper research, and doubled down on it when Al Williams and myself posted links to source code. You stated it was “pretend-open-source”, that “the sources aren’t actually provided”, and accuse Ploopy of deceitful business practices “people who wouldn’t consider it without being open source won’t find out until after they’ve bought it”. I certainly found that triggering. Maybe you can see how that comment about “nice way to communicate” may apply to your messages as well.
Best regards.
That old argument gets tiring…
It’s like releasing your source code as a jpeg.
Sure, it’s open but have fun making any edits.
If you can’t import a STEP file to your CAD package, I’d call that a skill issue.
The point remains true: STEP files are (almost certainly) not the SOURCE files.
It’s fantastic that they share them, and it would be great if all corporations shared some compiled 3D format of their housing shapes. But a source file would be better still!
I’m a software/electronics guy, so the equivalent in my world is:
If I publish a PCB design as Gerber files, it’s enough for you to send to a manufacturer, which is good. But it’s not enough to replace the 5V power supply section of the circuit with a 24V one, for example, which would be great.
HEY! This gift horse has imperfect teeth!
As with mechanics, there are no source files for software only UF2 files.
So no way to change software.
The Ploopy button is open to copy but cannot claim to be open source.
Oh wow I didn’t check that! Marvellous…
My impression is that the UF2 files are just the QMK firmware fork one level up on GitHub? Isn’t it? https://github.com/ploopyco/qmk_firmware
Perhaps not: in that project are subdirectories for many devices including some for Ploopyco, but I don’t see an entry for the Knob.
Well, you do have to open the “knob” branch. There are many branches in the repo.
@Al Williams: Opened the “knob” branch. Did not see anything but the UF2 binaries. Looked through every directory in the QMK firmware. Did NOT find source files for the knob; just for the other Ploopy products. Maybe it was an unintentional omission, but I’ve been burned before by “open-source” products I have purchased that as it turned out, I could NOT modify and build code for. So I’m a little sensitive about bogus open-source claims.
Okay, found it. https://github.com/ploopyco/qmk_firmware/tree/ploopyco/knob/keyboards/ploopyco/knob. Thanks SO much for the folks who were SO helpful about this.
Don’t conflate STEP with STL. STEP is universal and agnostic of platform, and plenty editable by cad professionals. Casual cad users dependent on parametricity might struggle, but that’s their own limitation of being stuck in a familiar modeler.
Describing parametric models as for “casual” users is about as accurate as considering use of variables in code a crutch for ‘casuals’.
If you’re modelling purely with static dimensions, you’re doing it wrong.
Frankly I find STEP files much easier to work with compared to some native CAD format that can only be used by that specific tool. Would you rather pay $$$ for a licence for Catia/Solidworks/Siemens NX just to be able to edit that “open source” design or open and edit the STEP files in FreeCAD?
If you know anything about CAD, you would rather go for the universal format.
Here is the issue, at first i did not see step so i thought there was only stl from your comment and thought “yeah it would be nice if source file is given as well” but after seeing there is step as well your argument is not valid. step is the standard for a reason. Let’s say he used solidworks 2025, less people will have access to it because it is not forward compatible (only backwards) so even if you have solidworks 2024, you wouldn’t be able to open it. Now is that better than step? You tell me…
awwww all the GPIO tied to GND its a recipie for disaster ….
Could you explain that or provide a link to an explanation? I am a hobby maker and would love to learn about that so that I don’t do the same mistakes.
Thanks
Connecting unused pins to ground on the PCB means that if you want to modify it and want to use some of those pins, you have to cut traces, which could potentially be internal ones. There is no good reason to do this anyway, since modern microcontrollers allow you to set all of your unused pins to weak pull-up or pull-down. In devices without this feature, it used to be good design practice to ground unused inputs since having them float would cause problems since they could float to an indeterminate state, which can among other things cause the chip to draw more current.
Really appreciate your answer, thanks.
The potential “disaster” is that you set those pins to outputs and write 1 to them, thus shorting them to ground, and resulting in total VDD current or dissipation that exceeds ratings.
I must confess to having high volume commercial products that connected multiple outputs together, and connected multiple output pins to gnd and vdd. The reason was so that we could get more output current from the device at lower voltage drops, and without dragging excessive currents around the on-die vss and vdd tracks. The output current for a pin, was being sourced from vdd or vss, via the adjacent output drivers and pins.
We were deeply into dirty deeds done dirt cheap. In the end, it didn’t go wrong.
Really appreciate your answer, thanks.
There is no source to be open…
This is a nice tool. But I’m annoyed it is only 3d printed. I would buy one if it were machined out of a nice piece of metal. I guess I could make my own since it’s open source, but would prefer if the manufacture offered an upgraded option that was nicer looking.
I’m actully working on a metal version of my KNOB that should be available soon if you’re interested: https://baselinedesign.tech/products/knobv21
Ooh! And your open-source project actually contains source code. Thank you!
I saw youtuber “Engineer Bo” create a high-res smooth scrolling knob like this 6 months ago:
https://www.youtube.com/watch?v=FSy9G6bNuKA
It’s nice to see the idea take on, and packaged in a more user/consumer friendly way as an open source project.
Love seeing more magnetic encoder KNOBs hitting the scene! This one looks great. Here’s the one I’ve been working on, definitely inspired to add a smooth scroll feature next: https://baselinedesign.tech/products/knobv21
Love seeing more magnetic encoder KNOBs hitting the scene! This one looks great. Here’s the one I’ve been working on, definitely inspired to add a smooth scroll feature next: https://baselinedesign.tech/products/knobv21
The thing that I’m not a fan of is that their “DIY” versions of most of their hardware (at least browsing their store) are just assembly kits – there’s no “just the PCB” or “just the non 3D printed parts” option. Seems wasteful to make me buy their kit only to trash their printed parts in favor of my own.