The dark room at Maker Faire was loud, after all it’s where Arc Attack was set up plus several other displays that had music. But if you braved the audio, and managed not to experience a seizure or migraine from all the blinking you were greeted with these sharply glowing vector displays on exhibit at the TubeTime booth. We did the best we could with the camera work, but the sharpness of the lines, and contrast of the phosphorescent images against the black screen still seems to pop more if viewed in person.
This isn’t [Eric’s] first attempt at driving high-voltage tube displays. We previously covered his dekatron kitchen timer. But we’d say he certainly stepped things up several notches in the years between then and now. He blogged about Asteroids, which is running on the same hardware as the Flappy Bird demo from our video above. An STM32F4 Discovery board is running a 6502 emulator to push the game to [Eric’s] CRT vector driver hardware.
Just before we were done at the booth, [Eric] turned to us with a twinkle in his eye. He confessed his delight in purposely leaving out any button debounce from the Flappy Bird demo. As if it wasn’t hard enough it tends to glitch after passing just a few of the pipe gates. Muhuhahaha!
Besides a coffee pot, the most important tool on the electronic tinkerer’s workbench is the soldering iron. Surprisingly, though, we haven’t seen many people build their own soldering stations. [Pjkim] did, and went so far as to include an easter egg for our Fubarino contest.
A few years ago, [Pjkim] received a free Soldering Iron Driver from Dangerous Prototypes. This awesome kit provides everything you could want out of a soldering iron – USB and serial data logging, a 2×16 display, compatibility with a whole bunch of solder tips, and it’s completely reprogrammable.
[Pjkim]’s task for the Fubarino contest was to put an easter egg somewhere in the soldering iron. He did that by having the Hackaday URL display when the iron is ready for use. This isn’t the only firmware modification, either: the new firmware also debounces the button presses and adds auto repeat.
If you’re looking for some code, [Pjkim] put everything up on the Hackaday forums. There’s also a video showing off the easter egg available below.
This is an entry in the Fubarino Contest for a chance at one of the 20 Fubarino SD boards which Microchip has put up as prizes!
Continue reading “Fubarino Contest: Hackaday In Your Soldering Iron”
This wooden box is a wireless pinball controller and tablet stand. The idea is to set it on a workbench to give you some of the thrill of standing and playing the real thing. [Jeff] has been rather addicted to playing a pinball app on Android lately, and started the journey because he needed a way to give his thumbs some relief.
An Arduino monitors buttons on either side of this wooden controller. [Jeff] is new to working with hardware (he’s a Linux Kernel developer by trade) and was immediately struck with button debouncing issues. Rather than handle this in software (we’ve got a super-messy thread on that issue with our favorite at the bottom) he chose a hardware solution by building an SR latch out of two NAND gates.
With the inputs sorted out he added a BlueSMiRF board to the project which allowed him to connect a Nexus 7 tablet via Bluetooth. At this point he ran into some problems getting the device to respond to his control as if it were an external keyboard. His stop-gap solution was to switch to a Galaxy Tab 10.1 which wasn’t throwing cryptic errors. Hopefully he’ll fix this in the next iteration which will also include adding a plunger to launch the pinball, a part which just arrived in the mail as he was writing up this success.
We’ve embedded his quick demo video after the break.
Continue reading “Wireless pinball controller for tablet gaming”
[Hasbi Sevinç] is using perishable goods in his electronics project. The orange, tomato, and two apples seen above act as keys for the virtual piano. The concept is the same as the Makey Makey which is often demonstrated as a banana piano. This implementation uses an Arduino to read the sensors and to connect to the computer running the piano program.
You can see there’s a fair amount of circuitry built on the breadboard. Each piece of fruit has its own channel to make it into a touch sensor. The signal produced when your finger contacts the food is amplified by transistors connected in a Darlington pair. That circuit drives the low side of a optoisolator transmitter. The receiving side of it is connected the I/O pin of the Arduino. You can see the schematic as well as a demo clip after the break.
This use of hardware frees up a lot of your microcontroller cycles. That’s because projects like this banana piano use the timers to measure RC decay. [Hasbi’s] setup provides a digital signal that at most only needs to be debounced.
Continue reading “Fruit piano uses a different circuit than the Makey Makey”
[Steve] created an AVR programmer using an old USB keyboard. We feature a bunch of AVR programmers, but this one is made from parts that many people will have lying around. There are two components: the controller PCB from a USB keyboard, and an optocoupler for emulating key presses.
In order to send data to the AVR, [Steve] used the LED outputs on the keyboard. These LEDs can easily be toggled according to the HID device specification. They provide a 5 volt output with current limiting resistors, which means they can be connected directly to the target AVR.
Reading data is a bit more complex. The optocoupler tricks the keyboard into believing that a single key has been pressed, firing off a data transfer. The MISO pin on the AVR is connected to the row and column of the shift key, which is read by the driver.
On the software side [Steve] created an avrdude interface driver. This allows the programmer to be used with avrdude, just like any other programmer. [Steve] does point out that it isn’t the fastest programmer since the keyboard tries to debounce the MISO input, greatly limiting the speed. However, since it’s made from stuff you might have in your junk bin, it’s a neat hack.
[Jon] will be tapping away with his toes during gaming session thanks to this foot controller which is packed with buttons and sensors. It’s the second iteration of the build. The original had some solder joints break and the USB stopped working. He had also been experiencing some erratic behavior and so he decided to upgrade the control hardware and add a few more things in the process.
This version uses an Arduino Uno as the interface board. He did a bunch of prototyping to find the best way to hook up all the analog sensors, and how to properly debounce the buttons. Once he was happy with the inputs he set about finding a better way to use the USB HID standard with the device. We were surprised to hear that the ATmega16u2 (one of the new AVR chips which includes USB hardware) doesn’t play nicely with Linux. But [Jon] managed to hack his way around that issue and now he’s gaming with an even better foot controller than before.
[miceuz] has a friend that works as a theatre technician, and in the course of his job he often needs to jigger with various stage components while shows are in progress. As you can imagine, the lighting situation is far from ideal, so he asked [miceuz] to build him an adjustable lighting solution for his tool box.
The circuit itself is relatively straightforward, using an ATMega88 to provide the PWM required for dimming and color control. Input is taken from three different sources, a rotary encoder for color selection, a pot for brightness control, and a button to turn the light strip on and off.
[miceuz] says that while project came together pretty easily, it still presented some issues along the way which provide some useful design reminders for beginners (and some veterans) alike.
First and foremost: debounce, debounce, debounce. [miceuz] forgot this mantra and made a mad dash to add capacitors to his design after etching the PCB to ensure that his inputs were not bouncing all over the place. He also noted that one should always be sure to read the ADCL before the ADCH register when decoding ADC data. His final observation is that using thick traces is the best policy whenever possible – he ran into a lot of issues with traces detaching during assembly, which he had to rework with wire and solder.
In the end, his friend was happy with the result, and [miceuz] is a better hacker for having worked through his issues. What sorts of important/useful lessons have you learned through the course of your projects? Be sure to share them with us in the comments.