If you buy expensive computer speakers, they often have a volume knob you can mount somewhere on your desk so you aren’t dependent on the onboard volume control. [Kris S] decided to build his own version of the remote volume control. Not surprisingly, it uses an Arduino-compatible Digispark board and a rotary controller. The Digispark (that [Kris S] bought for $2) is compatible with the Adafruit Trinket. This is key because the Trinket libraries are what make it easy to send media keys over the USB (using the HID interface) to control the volume.
Really, though, the best part of the build is the good looking knob made out of a pill bottle (see the video below). The micro Digispark is small enough to fit in the lid of the pill bottle, and some wax and pellets add some heft to the volume control. Continue reading “USB Volume Control”
If you have used a 3D printer for any length of time, you’ve probably experienced a failed print caused by a clogged nozzle. If you’re not around to stop the print and the nozzle stays hot and full of filament for hours, the clog gets even worse. [Florian] set out to solve this issue with an encoder that measures filament speed, which acts as an early warning system for nozzle clogs.
[Florian] designed a small assembly with a wheel and encoder that measures filament movement. The filament passes under the encoder wheel before it’s fed into the 3D printer. The encoder is hooked up to an Arduino which measures the Gray code pulses as the encoder rotates, and the encoder count is streamed over the serial port to a computer.
When the filament slows down or stops due to a nozzle clog, the Python script plays a notification sound to let you know that you should check your nozzle and that your print might fail. Once [Florian] works out some of the kinks in his setup, it would be awesome if the script could stop the print when the nozzle fails. Have any other ideas on how to detect print failures? Let us know in the comments.
Over the last 20 years, [Martin] has been recording snowboarding runs with a standard helmet cam. It was good but he felt like he could improve upon the design by building his own version and logging additional data values like speed, temperature, altitude, and GPS. In the video shown after the break, a first person perspective is displayed with a GPS overlay documenting the paths that were taken through the snow. [Martin] accomplished this by using a python module called picamera to start the video capture and writing the location to a data file. He then modified the program to read the current frame number and sync GPS points to an exact position in the video. MEncoder is used to join the images together into one media file.
The original design was based on the Raspberry Pi GPS Car Dash Cam [Martin] developed a few months earlier. The code in this helmet cam utilizes many of the same functions surrounding the gathering of GPS data points, recording video, and generating the overlay. What made this project different though were the challenges involved. For example, a camera inside a car rarely has to deal with extreme drops in temperature or the wet weather conditions of a snowy mountain. The outside of the vehicle may get battered from the snow, but the camera remains relatively safe from exposure. In order to test the Raspberry Pi before venturing into the cold, [Martin] stuck the computer in the freezer to see what would happen. Luckily it worked perfectly.
Click past the break for the rest of the story.
Continue reading “A Raspberry Pi Helmet Cam with GPS Logging”
[Colin] loves his PicoScope, a USB based “headless” oscilloscope. While using it he found himself longing for a classic oscilloscope interface. Mouse clicks just weren’t a replacement for grabbing a dial and twisting it. To correct the situation he created his USB-Connected Box-o-Encoders. The box maps as a USB keyboard, so it will work with almost any program.
[Colin] started by finding encoders. There are plenty of choices – splined or flatted shaft, detents or no detents, panel, PCB, or chassis mount. He settled on an encoder from Bourns Inc. which uses an 18 spline shaft. His encoder also includes a push button switch for selection. With encoders down, knobs were next. [Colin] chose two distinct styles. The two knob styles aren’t just decorative. The user can tell which row of knobs they are on by touch alone. Electronics were made simple with the use of a Teensy++ 2.0. [Colin] used a ATUSBKey device running Teensy software, but says the Teensy would have been a much better choice in terms of size and simplicity.
Once everything was wired into the box, [Colin] found his encoders would “spin” when the knobs were turned. They are actually designed to be PCB mounted, and then screwed into a control panel. Attempts to tighten down the panel mounting nut resulted in a broken encoder. Rather than redesign with purely panel mounted encoders, [Colin] used a dab of epoxy to hold the encoder body in place.
Continue reading “A USB Connected Box-o-Encoders”
The bad thing about this type of hack is that now [Tomek Dubrownik] needs to cut a hole in his desk to house the thing. He got this military grade trackball working over USB. It’s old, and could be used as a blunt weapon. But as the video shows it still makes a great input device.
He found the hardware on Allegro — a Polish auction site similar to eBay — for just $20. The original circuitry didn’t make a lot of sense, but a bit of probing with the old oscilloscope let him establish connections to the encoders which are read by some TI 54xx parts. Apparently they use the same logic as 7400 parts but are military grade. He chose a ATmega32u4 development board for his replacement control board. That chip has native USB support so the rest is just a matter of passing data like an HID input device. His code even lets him use those pushbuttons to toggle between cursor movement and window scrolling.
[Tomek] translated his post into English after some prompting by friends at the Warsaw Hackerspace. Here’s the original in Polish if you’re interested.
Continue reading “Ditch that boring mouse for a military-grade trackball”
You can get your hands on a Brother thermal label printer for $65-75. But if you don’t want to buy the Brother branded continuous feed paper for it you’re out of luck. Unless you pull off this hack which lets you use any thermal paper you want with a Brother QL-500 printer.
The printer is tied to the OEM paper because of a pattern printed on the back of the roll. It’s basically an encoder strip made up of black rectangles spaced at regular intervals. Surely there are other brands that come with this pattern on them, but if you want to use paper without it the secret is in moving the sensor that reads that strip.
The brilliant solution is to use one of the white feed-gears as an encoder wheel. [CheapSkateVideo] used a magic marker to paint two opposite quarters of the gear black. He then removed the optical sensor and placed it on the side of the case facing the wheel. It needs to be adjusted along the radius of that gear until the timing is just right, but once it is you’re ready to go. The sensor is a safety feature to ensure there is media in the printer. If there’s not you can burn up the print head so keep that in mind. See the explanation in the video after the break.
Continue reading “Hacking a Brother thermal printer to use non-OEM continuous rolls”
For those of you that have a wireless keyboard laying around, you might be tempted to turn it into something else, like a wireless MAME controller. For those not familiar with it, MAME stands for “Multiple Arcade Machine Emulator” and is generally used to run older arcade games on a computer.
Encoders are available for this purpose, however, intending to save some money, and having an unused wireless keyboard, I decided to try to make one myself. As far as I know there are no wireless encoders available for this purpose, so that was part of the motivation for trying this.
In this post I go over my mechanical design for the cabinet as well as the electrical process of going from keyboard to MAME controller. I did eventually get the thing working, but if more than a couple buttons were pressed simultaneously, some presses were omitted. The conclusion I eventually came to was that it was better to use an encoder to control everything. Not wireless, but much more reliable. If I absolutely needed a wireless controller in the future, I would think modding an actual wireless controller (or two) in a similar manner would have worked better for my purposes.