Hack a Day's Journal
[Most Recent Entries]
[Calendar View]
[Friends View]
Thursday, January 2nd, 2014
Time |
Event |
12:00a |
Building An Engine Control Unit With The STM32F4 http://feedproxy.google.com/~r/hackaday/LgoM/~3/Zo_H-7_G48U/ http://hackaday.com/?p=111361
If you’re looking to soup up your whip, the first place you’ll probably look is the engine control unit. This computer shoved in the engine compartment controls just about every aspect of your car’s performance, from the air/fuel ratio, the ignition timing, and the valve controls. Upgrading the ECU usually means flashing new firmware on the device, but [Andrey] is taking it one step further: he’s building his own ECU using the STM32F4 Discovery dev board.
[Andrey]‘s ride is a 1996 Ford Aspire, but while he was developing his open source ECU, he wanted to be able to drive his car. No problem, as going down to the junkyard, picking up a spare, and reverse engineering that was a cheap and easy way to do some development. After powering this spare ECU with an ATX supply, [Andrey] was able to figure out a circuit to get sensor input to his microcontroller and having his dev board control the fuel injector.
With a few additional bits of hardware [Andrey] has his open ECU controlling the fuel injection, ignition, fuel pump, and idle air valve solenoid. Not a bad replacement for something that took Ford engineers thousands of man hours to create.
[Andrey]‘s ECU actually works, too. In the video below, you can see him driving around a snow-covered waste with his DIY ECU controlling all aspects of the engine. If the engine sounds a little rough, it’s because a wire came loose and he was only using two cylinders. A bit of hot glue will fix that, though.
Filed under: ARM, transportation hacks | 3:00a |
Reverse Engineering HitClips http://feedproxy.google.com/~r/hackaday/LgoM/~3/qqGCfiAzm5E/ http://hackaday.com/?p=111375
After a quick review of the Hackaday viewer demographics, we need to say the late 90s were weird. Even portable audio players were downright bizarre: MP3 players existed, but you loaded up your songs (all eight of them) over your PC’s parallel port. While helping a cousin move some furniture, [Ch00f] found a huge collection of one of the oddest music formats ever: HitClips, a tiny plastic encapsulated bit of circuitry that stores 60 seconds of terrible-sounding mono audio. Yes, this was a thing, but so was the pet rock. With no HitClips player, [Ch00f] decided he would take a swing at reverse engineering these tiny, tinny songs.
After taking apart the plastic enclosure, [Ch00f] found a very simple circuit: a few resistors, a cap, and an epoxy blob that enclosed an die with the musical data. On the back of the clip, there are eight pads for connecting to the player. With nothing to go on, [Ch00f] started poking around and found connecting one of these pins to ground caused circuit to draw 300uA of current for about 60 seconds – the same length of time as the recorded sample.
[Ch00f] originally thought the HitClip would provide audio data over an SPI or other digital protocol. What he found was much more interesting: two of the pins on the HitClip correspond to the push and pull FETs of a class D amplifier. The audio on the HitClip is digital audio, but it’s encoded so it can directly drive an analog circuit. Pretty clever engineering for a happy meal toy, if you ask us.
After dumping this data with a logic analyzer, [Ch00f] turned all the values in to .WAV file. It was, amazingly, music. A little refinement to the process to nail down the timing resulted in a 60-second clip seen (heard?) after the break.
Since [Ch00f] doesn’t want to spend $40 on eBay for a vintage HitClips player, he’s right about at the limit of what he can reverse engineer out of these cheap, crappy music chips. He has put up all his documentation, though, so if you’re up for improving on [Ch00f]‘s methods, have a go.
Filed under: classic hacks | 6:00a |
| 9:01a |
Glowing Balloon Blimps http://feedproxy.google.com/~r/hackaday/LgoM/~3/DhLarUe3BC4/ http://hackaday.com/?p=111399
Looking for a neat decoration for your next soirée? How about floating fleet of glowing balloon blimps?
[Kensho Miyoshi] — an avid reader of Hack a Day — needed an art installation project in Tokyo, he came up with these clever glowing balloon blimps.
They feature a mini gondola hanging from the bottom of a regular balloon which holds a small motor with a propeller, an Arduino Pro Mini, LEDs, an ultrasonic sensor and of course, a battery. They float up to a certain height with the LEDs shining bright, and when the ultrasonic sensor trips, it all turns off and the balloon sinks gently back to the ground. The process repeats, and in a completely dark room it looks like a series of glowing bubbles forming and floating away, again and again.
To see the floaty, glowy, balloon blimps, stick around for a video after the break.
We’ve also covered a similar project recently on how to make a $13 remote-controlled balloon blimp using those micro-scale RC cars, a great project for young hackers. Filed under: toy hacks | 12:01p |
Once, Twice, Three Times a Nixie http://feedproxy.google.com/~r/hackaday/LgoM/~3/QI1SfuzccB4/ http://hackaday.com/?p=111369
Try as he might, [Localroger] can’t seem to throw away a certain board that started life in one of the first digital industrial scales, the NCI DigiFlex model 5775. He recently gave it a third career as a nixie clock with an alarm.
[Localroger] says the board dates to about 1975. It’s all TTL, no microprocessor anywhere. He was headed to the Dumpster with it in the mid-1980s, but realized that he could hack it into something useful. Since the display wasn’t multiplexed, it would be fairly easy. He used it as a BCD tester for about 10 years until the method fell out of fashion.
After a decade on the shelf, [Localroger] started off for the Dumpster once more with the board. The nixie tube display cried out for another chance to glow, so he decided to repurpose it into a remote-controlled bedside clock with an alarm. He installed a Parallax Propeller Protoboard with headers for easy removal and subsequent servicing of the 5775 board. He added a few things to the protoboard: a piezo element for the alarm, a SparkFun RTC module, an IR receiver, and vertically-oriented header so the PropPlug can be plugged in from the top. But that’s not all. [Localroger] designed a custom melamine-finished MDF enclosure and laser cut it, giving the edges a nice contrast. It’s so tough, he can put his ceramic lamp on top of it to save space on the nightstand.
Nixie tubes are becoming more scarce all the time. If you can’t find any, we humbly suggest rolling your own.
[Thanks Localroger!] Filed under: clock hacks, Microcontrollers, misc hacks | 3:01p |
QtLedTest – Software to Evaluate OLED Displays http://feedproxy.google.com/~r/hackaday/LgoM/~3/4fC7DXaOZ4o/ http://hackaday.com/?p=111397
A few days ago we featured the USBPass, an offline password keeper made with very few components. At the end of our write-up we mentioned that [Josh] was already working on another version of his hardware, which involved adding an OLED screen to the platform. To help him pick one he created QtLedTest, a Qt-based tool that simulates different OLED displays and GUI layouts for them. Internally QtLedTest is composed of QLedMatrix (a widget that simulates LED matrices), an SSD1306 OLED controller simulator, a simple graphics drawing library and some functions to draw text on the simulated screen. [Josh] used Fontbuilder together with a program he made in order to convert fonts he had found on the internet to C files. All the source code [Josh] made can be found on Github and should be updated in coming weeks as the final program is a bit slow to render the simulated screens. Filed under: software hacks | 6:01p |
Fail of the Week: AFSK Build Doomed by Rail Noise http://feedproxy.google.com/~r/hackaday/LgoM/~3/w_YnMfoiw08/ http://hackaday.com/?p=111473
[Scott] and his buddies were having some fun with their handheld transmitters one day when they decided it was time to build some add-on hardware that could transmit and receive location data. They set their sights on a set of Audio Frequency Shift Keying units that could each encoded and decipher location from the counterpart.
The build got off to an easy start, centering around an Arduino board with a GPS module for capturing precise location data. Next it was time to implement AFSK. On the transmitting side this was done by bit banging the output pins. After a look at the resulting signals on an oscilloscope the team was able to tune the firmware for a pretty tight 1200 and 2200 Hz output. But trouble was brewing on the decoding side of the equation.
The first decoding attempt used the FreqMeasure library written by [Paul Stoffregen]. After no success they moved to a hardware solution in the form of the XR-2211 FSK Demodulator chip. It should have been simple, feed it the signals and read the digital output pins to capture the desired data. This is the point at which you need to click the project link at the top to soak in all of the gory details. Long story short, a noisy power rail was causing sporadic performance of this chip. By the time this issue was discovered interest had waned and the project was ditched as a failure. Was there a quick fix that could have salvaged it such as adding a filtering circuit for that chip? Let us know how you would get this back on track by leaving a comment below.
[Thanks Lewin]
Fail of the Week is a Hackaday column which runs every Wednesday. Help keep the fun rolling by writing about your past failures and sending us a link to the story – or sending in links to fail write ups you find in your Internet travels. Filed under: Hackaday Columns, radio hacks | 9:00p |
Controlling Ten Thousand RGB LEDs http://feedproxy.google.com/~r/hackaday/LgoM/~3/8LNCoynHjBA/ http://hackaday.com/?p=111457 RGB LEDs are awesome – especially the new, fancy ones with the WS2812 RGB LED driver. These LEDs can be individually controlled to display red, green, and blue, but interfacing them with a microcontroller or computer presents a problem: microcontrollers generally don’t have a whole lot of RAM to store an image, and devices with enough memory to do something really cool with these LEDs don’t have a real-time operating system or the ability to do the very precise timing these LEDs require. [Sprite_tm] thought about this problem and came up with a great solution for controlling a whole lot of these WS2812 LEDs.
[Sprite] figured there was one device on the current lot of ARM/Linux boards that provides the extremely precise timing required to drive a large array of WS2812 LEDs: the video interface. Even though the video interface on these boards is digital, it’s possible to turn the 16-bit LCD interface on an oLinuXino Nano into something that simply spits out digital values very fast with a consistent timing. Just what a huge array of RGB pixels needs.
Using a Linux board to drive RGB pixels using the video output meant [Sprite_tm] needed video output. He’s running the latest Linux kernel, so he didn’t have the drivers to enable the video hardware. Not a problem for [Sprite], as he can just add a few files to define the 16-bit LCD interface and add the proper display mode.
[Sprite_tm] already taken an oscilloscope to his board while simulating 16 strips of 600 LEDs, and was able to get a frame rate of 30 fps. That’s nearly 10,000 LEDs controlled by a single €22/$30USD board.
Now the only obstacle for building a huge LED display is actually buying the RGB LED strips. A little back-of-the-envelope math tells us a 640×480 display would be about $50,000 in LEDs alone. Anyone know where we can get these LED strips cheap?
Filed under: ARM, led hacks |
|