The automotive industry is rolling more and more tech into their offerings. This is great for us because replacement or salvaged parts are great for projects. Here’s one component to look for. [MikesElectricStuff] tears apart the thermal imaging camera form an Audi. [via Hacked Gadgets]
Give your valentine an analog love note on the big day. [Tom’s] LED heart chaser design does it without any coding. It’s a 555 timer with CD4017 decade counter. The nice thing about the setup is a trimpot adjusts the chaser speed.
[Jan] is overclocking his Arduino to 32 MHz. For us that’s kind of an “eh” sort of thing. But his statement that you need to use a clock generator because the chip won’t work with an oscillator at that frequency raised an eyebrow. We saw an AVR chip running from a 32MHz crystal oscillator in the RetroWiz project from yesterday. So do we have it wrong or does [Jan]? Share your opinion in the comments.
Download a copy of the Apple II DOS source code… legally. Yay for releasing old code into the wild! The Computer History Museum has the DOS source code and a bunch of interesting history about it. [via Dangerous Prototypes]
While we were prowling around DP for the last link we came across [Ian’s] post on a new version of Bus Pirate cables. We’ve got the old rainbow cables which are pretty convenient. But if you’ve used them you’ll agree, hunting for the correct color for each connection isn’t anywhere near a fool-proof method. The new cable uses shrink tube printed with probe labels. They sound like a huge pain to manufacture. But this makes connections a lot easier. In our experience, when it doesn’t work its always a hardware problem! Hopefully this will mean fewer botched connections.
Make your tiny LiPo cells last longer. Not capacity wise, but physically. The delicate connections to the monitor PCB break easily, and the plug is really hard to connect and disconnect. [Sean] shows how he uses electrical tape for strain relief, and a bit of filing to loosen up the connector.
KerbalEdu: Kerbal Space Program for education. That’s right, you can play Kerbal as part of school now. Some may shake their heads at this, but school should be fun. And done right, we think gaming is a perfect way to educate. These initiatives must be the precursor to A Young Lady’s Illustrated Primer method of education. Right?
Developed in the very late 60s and through the 70s, the PDP-11 series of minicomputers was quite possibly the single most important computer ever created. The first widely distributed versions of Unix and C were developed on the PDP-11, and it’s hardware influence can be found in everything from the Motorola 68000 to the MSP430.
When [Dave Cheney] saw the recent 8086 simulator written in 4kB of C code, he realized simulating entire computer systems doesn’t actually require a whole lot of resources outside a big chunk of memory. Armed with an Arduino Mega clone, he set out on one of the coolest projects we’ve seen in a while: simulating a PDP-11 on an AVR.
[Dave] used an ATMega2560-powered Arduino Mega clone with an Ethernet module for the hardware of this build. Attached to it is a shield filled up with a pair of RAM chips that expand relatively limited amount of RAM on the ‘Mega.
So far, [Dave] has his simulated system booting Unix V6 off an SD card. For PDP-11 storage, he’s also simulating an RK05 disk drive, a massive 14 inch platter containing 2.5 Megabytes of data. Compared to the original PDP-11/40, [Dave] estimates his machine is about 10 times slower. Still, an original 11/40 system fills multiple server racks, and the most common installations consume several kilowatts of power. The Arduino Mega can fit in a pocket and can be powered over USB.
Future developments for this system include improving the accuracy of the simulator, running more advanced operating systems and the DEC diagnostic programs, and possibly speeding up the simulation. We’d suggest adding some switches and blinkenlights on an additional shield, but that’s just us.
All the code can be found on [Dave]’s git, with a description of his SPI RAM shield coming shortly.
The lowly Arduino, an 8-bit AVR microcontroller with a pitiful amount of RAM, terribly small Flash storage space, and effectively no peripherals to speak of, has better speech recognition capabilities than your Android or iDevice. Eighty percent accuracy, compared to Siri’s sixty.Here’s the video to prove it.
This uSpeech library created by [Arjo Chakravarty]
uses a Goertzel algorithm to turn input from a microphone connected to one of the Arduino’s analog pins into phonemes. From there, it’s relatively easy to turn these captured phonemes into function calls for lighting a LED, turning a servo, or even replicating the Siri, the modern-day version of the Microsoft paperclip.
There is one caveat for the uSpeech library: it will only respond to predefined phrases and not normal speech. Still, that’s an extremely impressive accomplishment for a simple microcontroller.
This isn’t the first time we’ve seen [Arjo]’s uSpeech library, but it is the first time we’ve seen it in action. When this was posted months and months ago, [Arjo] was behind the Great Firewall of China and couldn’t post a proper demo. Since this the uSpeech library is a spectacular achievement we asked for a few videos showing off a few applications. No one made the effort, so [Arjo] decided to make use of his new VPN and show off his work to the world.
Continue reading “An Arduino With Better Speech Recognition Than Siri”
Ideally, technology is supposed to enhance our lives. [Shane and Eileen], two seniors at Cornell have found a great way to enhance the lives of visually impaired individuals with their acoustic wayfinding device. In brainstorming for their final project, [Shane and Eileen] were inspired by this Hackaday post about robots as viable replacements for guide dogs. They sought to provide wearable, hands-free guidance and detection of (primarily) indoor obstacles—namely chairs, benches, and other inanimate objects below eye level.
The wayfinder comprises two systems working in tandem: a head-mounted navigation unit and a tactile sensor worn on the user’s finger. Both systems use Maxbotix LV-MaxSonar-EZ0 ultrasonic rangefinder modules to detect obstacles and vibrating mini-disc motors to provide haptic feedback at speeds proportionate to the user’s distance from an obstacle.
The head unit uses two rangefinders and two vibrating motors. Together, the rangefinders have a field of view of about 120 degrees and are capable of detecting obstacles up to 6.45 meters away. The tactile sensor comprises one rangefinder and motor and is used in a manner similar to a Hoover cane. The user sweeps their hand to detect objects that would likely be out of the range of the head unit. Both parts are ergonomic and size-adjustable.
At power up, [Shane and Eileen]’s software performs a calibration of the tactile sensor to determine the distance threshold in conjunction with the user’s height. They’ve used an ATMega 1284 to drive the system, and handled real-time task scheduling between the two subsystems with the TinyRealTime kernel. A full demonstration video is embedded after the break.
Continue reading “Acoustic Wayfinder for the Visually Impaired”
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.