3D Printering: Making A Thing In Blender, Part I

January 3, 2014 by Brian Benchoff 52 Comments

In case you weren’t aware, having a 3D printer is nothing like owning a real-life Star Trek replicator. For one, replicators are usually found on Federation starships and not hype trains. Secondly, the details of how replicated objects are designed in the 24th century is an issue completely left unexplored by TNG, and DS9, and only a minor plot point in a few Voyager episodes. Of the most likely possibilities, though, it appears replicated objects are either initially created by ‘scanning’ them with a teleporter, or commanding the ship’s computer to conjure something out of the hologrid.

No, with your own 3D printer, if you want a unique object you actually have to design it yourself. Without a holodeck. Using your hands to move a mouse and keyboard. Savages.

This series of ‘Making a Thing’ tutorials aims to fix that. With this post, we’re taking a look at Blender, an amazing 3D modeling and animation package.

Because we still haven’t figured out the best way to combine multiple blog posts together as a single resource − we’re working on that, though − here’s the links to the previous “Making a Thing” posts:

This list is sure to grow thanks to your suggestions on what 3D modeling software to feature, but for now let’s make a thing in Blender.

Continue reading “3D Printering: Making A Thing In Blender, Part I” →

Fire At The Geek Group

January 3, 2014 by Brian Benchoff 121 Comments

The Geek Group, an absurdly large and well stocked hackerspace in Grand Rapids, Michigan caught fire yesterday.

You may recall The Geek Group from their many over-the-top projects that include a quarter shinker, a 200,000 Watt Tesla coil, enough capacitors to kill a demi-god, and a giant robot that crushes TVs. From what TGG has shown on their website and their YouTube, they have an amazing space that could still be the home of quite a few amazing builds.

According to Geek Group head honcho [Chris], the fire was caused by an overheated electric motor. No one was at the space at the time, but the fire was hot enough to crack the exterior brick and melt porcelain insulators in their high voltage lab. To add insult to injury, this was only TGG’s second day of being open to the public.

The folks at The Geek Group are looking for volunteers for their cleanup, so if you’re around the Grand Rapids area and would like to pitch in, head on over around noon today.

Spoofing Pokemon Trades

January 2, 2014 by Brian Benchoff 16 Comments

[Adan] had an old Game Boy sitting around, and without anything better to do decided to investigate the link cable protocol with a microcontroller. He had a Stellaris Launchpad for the task, but initially had no project in mind. What he came up for this adventure in serial protocols is a first gen Pokemon trade spoofer that allows him to obtain pokemon without having two Game Boys, or for the weird ones out there, “friends.”

The Game Boy link protocol is extremely well documented (dead link, try Internet Archive), so getting data from the Game Boy to the Launchpad was as simple as a soldering up an old link cable connector to a piece of perf board. After figuring out the electronics, [Adan] looked at what happened when two Pokemon games tried to trade pokemon. When two Game Boys are linked, there are two in-game options: trade or battle. Looking at the data coming after the ‘trade’ option, [Adan] found something that could possibly be the data structure of the Pokemon being sent. He reverse-engineered this all by himself before discovering this is also well documented.

Bringing everything together, [Adan] figured out how to trade non-existent Pokemon with a small dev board. Right now he’s only transmitting Pokemon that are hard-coded on the Launchpad, but it’s very possible to transmit the Pokemon values in real-time over USB.

Thanks [Dan] for sending this in, and no, we don’t know what’s up with the influx of Pokemon posts over the last week. Video of the spoof below.

Continue reading “Spoofing Pokemon Trades” →

Controlling Ten Thousand RGB LEDs

January 2, 2014 by Brian Benchoff 51 Comments

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?

Continue reading “Controlling Ten Thousand RGB LEDs” →

Reverse Engineering HitClips

January 1, 2014 by Brian Benchoff 31 Comments

hitclipz

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.

Continue reading “Reverse Engineering HitClips” →

Building An Engine Control Unit With The STM32F4

January 1, 2014 by Brian Benchoff 60 Comments

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.

Continue reading “Building An Engine Control Unit With The STM32F4” →

Gotta Catch ‘Em All, With An Arduino

January 1, 2014 by Brian Benchoff 13 Comments

PKMN

For every pokemon you encounter on your adventure to become the world’s greatest trainer, you have about a 1 in 8000 chance of that pokemon being ‘shiny’, or a different color than normal. Put an uncommon event in any video game, and of course a few people will take that feature to the limits of practicality: [dekuNukem] c reated the Poke-O-Matic , a microcontroller-powered device that breeds and captures shiny pokemon.

We’ve seen [dekuNukem]’s setup for automatically catching shiny pokemon before, but the previous version was extremely limited. It only worked with a fishing rod, so unless you want a ton of shiny Magikarp the earlier setup wasn’t extremely useful.

This version uses two microcontrollers – an Arduino Micro and a Teensy 3.0 – to greatly expand upon the previous build. Now, instead of just fishing, [dekuNukem]’s project can automatically hatch eggs, search patches of grass for shiny pokemon, and also automatically naming these new shiny pokemon and depositing them in the in-game pokemon storage system.

The new and improved version works a lot like the older fishing-only automated pokemon finder; a few wires soldered on to the button contacts control the game. The Teensy 3.0 handles the data logging of all the captured pokemon with an SD card and RTC.

What did [dekuNukem] end up with for all his effort? A lot of shiny pokemon. More than enough to build a great team made entirely out of shinies.

Video below, with all the code available through a link in the description.

Continue reading “Gotta Catch ‘Em All, With An Arduino” →