Hosting a New Year’s Eve party, but don’t want to be stuck behind the bar all night? You could set out a bowl or two of
spiked punch, but where’s the hack? Free yourself from drink slinging duties with the Automated Drink Mixer created by Cornell University students [Justin] and [Austin]. Their design uses a 14″ diameter lazy Susan powered by a 12V bi-directional motor attached to a 2″ rubber wheel. The motor is capable of 70RPM, so the glass ultimately rides around at 10RPM. Orders are entered on a push-button menu. As this is a school project that should adhere to IEEE standards, all libations are non-alcoholic.
The software uses an overarching state machine, so the system polls for input from the menu at idle. When it receives an order, the lazy Susan rotates the glass to the right spout or series of spouts and then returns it to the starting point. [Justin] and [Austin] controlled the position of the glass with an IR emitter and phototransistor. This pair detects the black strips of tape around the edge which are spaced 60° apart. A comparator digitizes the signal and triggers an interrupt in the software, which counts the number of 60° slices. A full demonstration is waiting for you after the jump. Before you jump: drink responsibly, kids. If you aren’t up to that particular challenge, make yourself an alcohol-aware LED ice cube. If you need more LEDs in your life, whip up the Inebriator.
Continue reading “Automated Drink Mixer Is the Life of the Party”
Candle flicker LEDs are a one part replacement for a real candle. They contain both a yellow LED and a control chip that modulates the light to create a candle effect. [Cpldcpu] took a deep look into reverse engineering one of these LEDs.
To analyze the circuit, which is potted into the LED itself, a shunt sense resistor was connected to the LED. By connecting this resistor to a logic analyzer, the control signal could be observed.
This control signal looked like pulse width modulation, with some randomness to the duty cycle. [Cpldcpu] determined that a linear feedback shift register was most likely used to generate a pseudeorandom bitstream, and some shaping was applied to make the LED look more like a real candle.
It turns out a blinking LED can be quite complex, and this takes a deep look into it by analyzing the signal. [Cpldcpu] took the lessons learned and wrote an implementation of the algorithm for AVR.
[Ralph] has been working on an extraordinarily tiny bootloader for the ATtiny85, and although coding in assembly does have some merits in this regard, writing in C and using AVR Libc is so much more convenient. Through his trials of slimming down pieces of code to the bare minimum, he’s found a few ways to easily trim a few bytes off code compiled with AVR-GCC.
To test his ideas out, [Ralph] first coded up a short program that reads the ATtiny85′s internal temperature sensor. Dissassembling the code, he found the a jump to a function called __ctors_end: before the jump to main. According to the ATtiny85 datasheet, this call sets the IO registers to their initial values. These initial values are 0, so that’s 16 bytes that can be saved. This function also sets the stack pointer to its initial value, so another 16 bytes can be optimized out.
If you’re not using interrupts on an ATtiny, you can get rid of 30 bytes of code by getting rid of the interrupt vector table. In the end, [Ralph] was able to take a 274 byte program and trim it down to 190 bytes. Compared to the 8k of Flash on the ‘tiny85, it’s a small amount saved, but if you’re banging your head against the limitations of this micro’s storage, this might be a good place to start.
Now if you want to hear some stories about optimizing code you’ve got to check out the Once Upon Atari documentary. They spent months hand optimizing code to make it fit on the cartridges.
After seeing [Dimitry] build the most minimal Linux computer ever, [Kyle] decided he needed one for himself. In true hacker fashion, he decided to take this build for the worst Linux PC one step further: he would add I2C to his version, making it somewhat useful, considering the number of I2C peripherals out there.
This build is based on [Dmitry]‘s ARM Linux computer emulated on an 8-bit AVR. It’s a full-blown Linux computer with 16 MB of RAM courtesy of a 30-pin SIMM, a lot of storage provided by an SD card, all running on an emulated ARM processor inside a lowly ATMega1284p. [Kyle] built this clone over the course of a few months, but from the outset decided he wanted to implement an I2C protocol on this terribly under specced computer.
After booting his computer, [Kyle] eventually got an I2C module loaded by the kernel. With an I2C module and a few spare GPIO pins, he set out to create something to attach to this terribly slow computer – an ancient LED dot matrix display. With a real-time clock, this display became a clock with the help of a homebrew program written in C. Considering the speed of the emulated processor, the program takes nearly three seconds to read the RTC and display the current time to the display. We’re thinking it was a wise choice to only implement hours and minutes in this clock.
If having a useful computer running at about 10 kilohertz isn’t enough, [Kyle] also compiled the classic text-based adventure Zork. It actually runs, proving you don’t need Megahertz of power to do something useful and fun.
[Firewalker] has designed a great pellet burning boiler (translated). Wood and biomass pellets have gained popularity over the last few years. While freestanding stoves are the most popular method of burning the pellets, [Firewalker] went a different route. He’s converted a boiler from what we assume was oil to pellet power. An Arduino controls the show, but don’t hold it against him. [Firewalker] is just using the Arduino as an AVR carrier board.The software is all written in C using AVR studio. The controller’s user interface is pretty simple. A two-line character based LCD provides status information, while input is via buttons. Once the system is all set up, thermostats are the final human/machine interface.
Burning pellets requires a bit of prep. A cleanup of the burn chamber must be performed before each burn. The AVR is programmed to handle this. Once the chamber is clean, new pellets are fed in via an auger system. The burner is monitored with a standard flame sensor. When the fire is up the pellets feed in until the boiler gets up to temp. Then the system enters a standby mode where it feeds in just enough pellets to maintain the flame. When the thermostats stop calling for heat, the whole system shuts down, ready for the next burn.
Continue reading “DIY Pellet Fed Boiler is Hot Stuff”
If you happened to be wandering the hall of science during MakerFaire NY, you may have noticed a woman walking around with a rather odd boombox strapped around her neck. That was [Sophi Kravitz] with her HeartBeat Boombox. Thankfully [Sophi] lives within driving distance of Makerfaire, and didn’t attempt to get through airport security with her hardware. She started with three medical grade pulse oximeters. These oximeters output a “beep” for every beat of your heart. [Sophi] rolled her own AVR board running Arduino firmware to capture pulses on their way to the oximeter audio transducer. The AVR uses a sound board to convert the pulses into various percussion sounds. The pulse indicators also activate one of three LED strips.
[Sophi’s] biggest frustrations with the hack were the JST connectors on the LIPO batteries powering the entire system. She found that they fell apart rather easily. We’ve used JST connectors in the past with no problem, so we’re guessing she ended up with one of the many knock off connectors out there. [Sophi] tied the entire system together with a custom milled acrylic plate mounted to the front of the boombox.
The final result was very slick. With three people connected to the finger inputs of the pulse oximeters, some complex beats could be formed. We thought we were listening to dubstep when she first walked by. One feature we would like to see implemented would be the ability to record and play back some of the beats created by the boombox.
Perfection is achieved not when there is nothing more to add, but when there is nothing left to fail. Going by that metric, [Stian]‘s three-chip 6502 homebrew computer is the epitome of perfection. It’s a real, working, homebrew retrocomputer using only three chips: a CPU, some RAM, and a microcontroller to bootstrap the computer and provide a video output,
The key to this minimalist build is having the entire boot process controlled by an ATMega16 microcontroller, This interfaces to the 6502 through a dual-port SRAM, a 1 kilobyte Cypress CY7C130. This dual-port RAM allows the CPU and microcontroller to access the same bit of memory, making it easy to bootstrap a computer from a bit of AVR code.
Output is provided with [Stian]‘s ATMega video text generator putting a 37×17 characters on any television with an RCA jack. While input isn’t handled yet, [Stian] says it should be possible with his AVR PS/2 keyboard library.
While other 6502 homebrew computers such as [Quinn Dunki] Veronica can reach unparalleled heights of complexity, there is a lot to be said about the minimalism of [Stian]‘s three-chip computer. With some clever coding and a modified parts list, it may well be possible to put a retrocomputer in the hands of everyone with a bare minimum of cost and parts.