Rotary encoders are critical to many applications, even at the hobbyist level. While considering his own rotary encoding needs for upcoming projects, it occurred to [Jan Mrázek] to try making his own DIY capacitive rotary encoder. If successful, such an encoder could be cheap and very fast; it could also in part be made directly on a PCB.
The encoder design [Jan] settled on was to make a simple adjustable plate capacitor using PCB elements with transparent tape as the dielectric material. This was used as the timing element for a 555 timer in astable mode. A 555 in this configuration therefore generates a square wave that changes in proportion to how much the plates in the simple capacitor overlap. Turn the plate, and the square wave’s period changes in response. Response time would be fast, and a 555 and some PCB space is certainly cheap materials-wise.
The first prototype gave positive results but had a lot of problems, including noise and possibly a sensitivity to temperature and humidity. The second attempt refined the design and had much better results, with an ESP32 reliably reading 140 discrete positions at a rate of 100 kHz. It seems that there is a tradeoff between resolution and speed; lowering the rate allows more positions to be reliably detected. There are still issues, but ultimately [Jan] feels that high-speed capacitive encoders requiring little more than some PCB real estate and some 555s are probably feasible.
Museum exhibits are difficult to make, and they’re always breaking down; especially the interactive ones. This is a combination of budget, building a one-off, and the incredibly harsh abuse they take from children.
My first exhibit is an interactive laser show that turns waveforms from music into laser patterns, and different types of music have very different patterns. I knew from talking to the museum staff that industrial buttons were a necessity, but it turns out that industrial buttons are made under the assumption that tiny creatures won’t be constantly mashing, twisting, and (ew ew ew) licking the buttons. After a while, the buttons (and poor knob) were trashed.
The second exhibit is also interactive, but in this case it’s just a simple button that turns on a thing for a while, then shuts it off. You can read more about the Periodic Table of Motion on the project page. Here I thought; let’s use capacitive touch, put the sensor behind two layers of acrylic for protection, and then there won’t be any moving parts to break. I built a bunch of units, tested it for weeks, then installed it. Instant failure despite my diligence.
Something is different about the installation from my test environment. It might be the second layer of acrylic contributing. Maybe it’s the power supply and a strange ground issue. Maybe the room’s fluorescent lights are creating an electromagnetic field that is interrupting the sensor, or the carpet is causing static buildup that is somehow causing the midichlorians to reverse polarity and discharge through the base plate of prefabulated aluminite. In some of the cells, the button doesn’t work. In other cells it is extremely sensitive. In one column of the table (columns share a common piece of acrylic among 5 cells), a single touch will trigger all 5.
The circuit is an ATtiny with a 2.2M resistor between two pins, one of which connects via a short wire to a soldered connection to a piece of copper tape on the underside of an acrylic piece. The ATtiny is using the capsense library, which has features for automatic recalibration. Because of the way it is installed, I can’t reprogram them to adjust their sensitivity while inside the enclosure, so tweaking them post-install is not an option. I thought I could isolate the problem and use an existing capacitive touch sensor breakout of the AT42QT1010 hooked up to just power, but it had the exact same issue, meaning it’s either the power supply, the enclosure, or the room.
There are three paths I can go down now:
Find the problem and solve it
Switch to a photoresistor
Petition Hackaday for a better solution
Finding the problem and solving it will be a long and difficult path, especially since the museum environment is somehow and inexplicably different from the test environment. The photoresistor option has promise; when the user puts their hand over the paper button the light level changes. Some early testing indicates that it is easy to detect instantaneous change, and a trailing average and adjusting threshold make it robust enough for changing lighting conditions throughout the day. Further, it’s a simple change to the code, and the existing circuit board will accommodate the adjustment.
As for the third option…
What have you done for child-compatible touch interfaces that are robust enough to handle uncertain environments and harsh abuse? What buttons, knobs, and other interactive elements have you used?
Cell biology professor [Mike] has created a way for blind students to decipher microscope slides using 3D prints and the magic of capacitive sensing. His write-up focuses on a slide showing the anaphase stage of mitosis in whitefish blastula, a popular choice for studying cell division. When a student touches a certain area of the print, the capacitive sensor triggers audio playback to tell them what they’re feeling.
[Mike] started by turning a 2D image of a cell into a 3D print. To do this, he made the image black and white, and then inverted the colors so that the 3D print’s topography will correspond correctly. The talking part is handled by an Arduino Duemilanove and a Spikenzie voice shield. The latter has a somewhat limited amount of space, but is more than adequate for the audio labels [Mike] made, which are all less than three seconds long.
A hard copy of the 2D file comes in handy for making sure the cap sensors are in the right places. To make those, [Mike] cut up some floor protector pads and covered the sticky side with copper tape. These are held on the 2D image with double-sided tape. The 3D print sits on top, separated by more furniture pads at the corners. He labeled this scientific sandwich model with a 3D printed Braille label that reads ‘anaphase’. [Mike] has made the referenced STL file along with a few others available at the National Institutes of Health’s 3D print exchange site.
Are you the mutant savior? Are you prepared for the robot uprising of 2084? Have you accepted robotron into your life? The Church of Robotron is now conducting training, testing, and confession at the new window altar in downtown Portland.
The Church of Robotron is the fake totally legit religion based on the classic arcade game prophecy Robotron 2084. In keeping with the church’s views on community outreach and missionary work, a Robotron altar has been installed at the Diode Gallery for electronic arts.
The altar consists of a system running Robotron 2084 with capacitive sensing controls built by DorkbotPDX’s own [Phillip Odom]. He’s using the same techniques featured in his capacitive sensing workshop, allowing the game to be played 24 hours a day. There are also monitors displaying the leaderboard and tenants of the Church of Robotron.
The office environment over at [Adam]’s place of employment has recently become one of the many IT-related offices with a ping pong table, a cliché that he readily points out. However, [Adam] and the other folks at the office decided to step up their game a little bit by making this automated ping pong table.
The table first keeps track of the players with specialized RFID tags that are placed in the handle of the paddles. The paddles are unique to each player, and when they are swiped past a reader on the table the scoring system registers the players at the table.
Small capacitive touch sensors on the underside of the table allow the players to increment their score when a point is made. The scoreboard is a simple but a very well-polished interface that has audio cues for each point. The system is also able to keep track of the winners and the overall records are tracked, allowing for office-wide rankings.
This is the best table-related game hack since the internet-connected foosball table, and should be welcome in any office for some extra break room fun at work! All of the code is available on the project site.
The pen is mightier than the sword, but the IBM Model M keyboard, properly applied, can knock teeth in. There are a few more IBM keyboards even better suited to blunt force trauma – the extremely vintage beam spring keyboards made for terminals and desktop publishers. Being so very old, there’s no easy way to connect these keyboards to a modern system, so when [xwhatsit] wanted to make his work, he needed to build his own controller.
The beam spring keyboards use capacitive switches, and with 122 keys, the usual method of reading capacitance – putting a capacitor in an oscillator – would be far too slow to be of any use in a keyboard. There is another method of reading capacitance: measuring the current going through the capacitive switch. This can easily be accomplished with an LM339 comparator.
[xwhatsit]’s keyboard controller uses this capacitive sensing circuit to read the four rows of keys, with a few shift registers taking care of the columns. An ATMega32u2 is the brains of the outfit, running LUFA to translate the key presses to USB.
If you’re lucky enough to have one of these ancient keyboards, [xwhatsit] is selling a few over on the usual mechanical keyboard forums. There’s also a controller for the Model F keyboard using the same basic circuit. If you need one just drop him a line or grab the gerbers and roll your own.
For the last few weeks we’ve mostly been improving our current PCBs and case design for the production process to go smoothly. The final top PCB shown above has been tweaked to improve his capacitive touch sensing capabilities, you may even see a video of the system in action in the Mooltipass project log on hackaday.io. We’ve also spent some time refining the two most popular card art designs so our manufacturers may print them correctly. We’ll soon integrate our updated USB code (allowing the Mooltipass to be detected as a composite HID keyboard / HID generic) into the main solution which will then allow us to work on the browser plugin.
It’s also interesting to note that we recently decided to stop using the GPL-licensed avrcryptolib. Our current project is CDDL licensed, allowing interested parties to use our code in their own project without forcing them to publish all the remaining code they created. The GPL license enforces the opposite, we therefore picked another AES encryption/decryption implementation. This migration was performed and checked by our dedicated contributor [Miguel] who therefore ran the AES NESSIE / CTR tests and checked their output, in less than a day.
We’re about to ship the first Mooltipass prototypes to our active contributors and advisers. A few weeks later we’ll send an official call for beta testers, just after we shown (here on Hackaday) what the final product looks like. Don’t hesitate to ask any question you may have in the comments section, you can also contact us on the dedicated Mooltipass Google group.