Help Needed: No-Soldering ESP8266 IFTTT Button

January 1, 2016 by Elliot Williams 18 Comments

We all love to see amazing hacks in their finished state and be dazzled by what our peers can do. But that’s just the summit of the hacker’s Everest. We all know that the real work is in getting there. Hackaday.io user [stopsendingmejunk] is working on an ESP8266-based IFTTT Button based on a simple breakout board so that anyone could rebuild it without having to do any soldering, and he’s looking for collaboration.

[stopsendingmejunk]’s project takes off from this similar project on different hardware. The board he’s chosen to use is the EZSBC ESP8266-07 breakout, which should have everything he needs, including an on-board button. It should be an easy enough job, but he’s having trouble getting the thing to stay asleep until the button is pressed.

We’ve seen more than a few hacks of the Amazon Dash button, but aside from hacking for hacking’s sake, we’re also happy to see a ground-up open redesign. Besides, this looks like it’ll be a great introductory project, requiring little fiddling around. With a little help. The code is up here on GitHub. Anyone game?

Hillbilly Lego Focus Puller

January 1, 2016 by Elliot Williams 10 Comments

There’s almost nothing you can’t build with the right set of Lego parts. [Rigjob] built up a Lego-based wireless remote follow-focus system that’ll give professional systems a run for their money.

Now [Rigjob] self-identifies as a hillbilly, but he’s not just a redneck with a camera. He’s set up the Lego controller to remember minimum and maximum focus positions as well as mark points along the way. The controller simply won’t turn the lens outside of the focus range, and an interactive graph shows you where you are within the range. For a focus wheel, he uses (drum-roll please!) a Lego off-road wheel. It looks really comfortable, usable, and actually quite professional.

There’s a lot of tech in the Lego controller and motors that make this “simple” hack simple. Under the hood, there’s a Bluetooth connection, a geared stepper motor with a position sensor, a communication protocol, and a whole ton of programming in the Lego controller that makes it all drag-and-drop programmable. But to a long-bearded hillbilly cameraman, it all looks like child’s play. And that’s the hallmark of good design. Kudos, Lego.

If you can’t get enough Lego camera tech, check out this DIY slit-scan stargate rig, or (what else?) a Lego 3D chocolate printer.

Continue reading “Hillbilly Lego Focus Puller” →

EZ-Spin Motor Spins “Forever”

January 1, 2016 by Elliot Williams 90 Comments

Now this isn’t a perpetual motion machine, but it’s darn close. What [lasersaber] has done instead is to make the EZ Spin, an incredibly efficient motor that does nothing. Well, nothing except look cool, and influence tons of people to re-build their own versions of it and post them on YouTube.

The motor itself is ridiculously simple: it’s essentially a brushless DC motor with a unique winding pattern. A number of coils — anywhere from six to twenty-four — are wired together with alternating polarity. If one coil is a magnetized north, its two neighbors are magnetized south, and vice-versa. The rotor is a ring with permanent magnets, all arranged so that they have the same polarity. A capacitor is used for the power source, and a reed switch serves as a simplistic commutator, if that’s even the right term.

As the motor turns, a permanent magnet passes by the reed switch and it makes the circuit. All of the electromagnets, which are wound in series, fire and kick the rotor forwards. Then the reed switch opens and the rotor coasts on to the next position. When it gets there the reed switch closes and it gets a magnetic kick again.

The catch? Building the device so that it’s carefully balanced and running on really good (sapphire) bearings, entirely unloaded, and powered with high impedance coils, leads to a current consumption in the microamps. As with most motors, when you spin it by hand, it acts as a generator, giving you a simple way to charge up the capacitor that drives it. In his video [lasersaber] blows on the rotor through a straw to charge up the capacitor, and then lets it run back down. It should run for quite a while on just one spin-up.

The EZ Spin motor is absolutely, positively not perpetual motion or “over-unity” or any of that mumbo-jumbo. It is a cool, simple-to-build generator/motor project that’ll definitely impress your friends and challenge you to see how long you can get it running. Check out [lasersaber]’s website, this forum post, and a 3D model on Thingiverse if you want to make your own.

Continue reading “EZ-Spin Motor Spins “Forever”” →

32C3: My Robot Will Crush You With Its Soft Delicate Hands!

January 1, 2016 by Elliot Williams 2 Comments

In his talk at 32C3 [Matthew Borgatti] talked both about his company’s work with NASA toward developing robotic spacesuits and helping people with Cerebral Palsy better control their limbs. What do these two domains have in common? “One-size fits all pneumatic exoskeletons.”

[Matthew] makes a tremendously compelling case for doing something new and difficult in robotics — making robotic systems out of squishy, compliant materials. If you think about it, most robots are hard: made of metal and actuated by motors and gears, cables, or (non-compressible) pneumatic fluid. If you want to build suits that play well with soft and squishy people, they’ll need at least a layer of softness somewhere.

But [Matthew]’s approach is to make everything soft. In the talk, he mentions a few biological systems (octopus arms and goat’s feet) that work exactly because they’re soft. Why soft? Because soft spreads force around automatically and accommodates uneven terrain. And this makes it easier on the people who wear robotic suits and on the designers of the robots who don’t need to worry about the fine detail of the ground they’re walking on.

The talk ended up being very short, but there’s a fantastic Q&A at the end. It’s a must-see. And if you can’t get enough of [Matthew] or squishy robots, we’ve covered his robots before and he even had an entry in the Hackaday Prize.

Art For Planespotters

December 31, 2015 by Elliot Williams 6 Comments

We don’t know art, but we know what we like. And this gizmo by [Johan Kanflo] is right up our alley.

First, [Johan] gutted an old Macintosh Classic computer and stuffed a Raspberry Pi inside. Now this is not really a new idea, but [Johan] did a very nice job with the monitor and his attention to detail shows in the rebuilt floppy-drive eject mechanism. He gives it back that characteristic “schlurp” noise.

Then he outfitted the Raspberry Pi with an RTL dongle running dump1090 software to listen to the ADS-B radio signals. The data extracted from the SDR is piped off to an MQTT server with all sorts of data about the airplanes overhead. Another script subscribes to the MQTT topic and figures out which is the closest and runs an image search for the plane type in question, publishing the results back to another MQTT topic. One final script subscribes to this last topic and displays the relevant images on the screen. Pshwew!

The end result is a Macintosh Classic that’s continually updated with whatever planes are closest to being overhead. We’re not at all sure if this is fine art, or part of the useful arts, or maybe even none of the above. But we really like the nice case job and think that using MQTT as a back-end for coordinating multiple concurrent Python scripts (on the same computer) is pretty cool.

32C3: So You Want To Build A Satellite?

December 31, 2015 by Elliot Williams 46 Comments

[INCO] gave this extremely informative talk on building a CubeSat. CubeSats are small satellites that piggyback on the launches of larger satellites, and although getting a 10 cm³ brick into orbit is cheap, making it functional takes an amazing attention to detail and redundant design.

[INCO] somehow talks through the entire hour-long presentation at a tremendous speed, all the while remaining intelligible. At the end of the talk, you’ve got a good appreciation for the myriad pitfalls that go along with designing a satellite, and a lot of this material is relevant, although often in a simpler form, for high altitude balloon experiments.

CubeSats must be powered down during launch, with no radio emissions or anything else that might interfere with the rocket that’s carrying them. The satellites are then packed into a box with a spring, and you never see or hear from them again until the hatch is opened and they’re pushed out into space.

[INCO] said that 50% of CubeSats fail on deployment, and to avoid being one of the statistics, you need to thoroughly test your deployment mechanisms. Test after shaking, being heated and cooled, subject to low battery levels, and in a vacuum. Communication with the satellite is of course crucial, and [INCO] suggests sending out a beacon shortly after launch to help you locate the satellite at all.

Because your satellite is floating out in space, even tiny little forces can throw it off course. Examples include radiation pressure from the sun, and anything magnetic in your satellite that will create a torque with respect to the Earth’s magnetic field. And of course, the deployment itself may leave your satellite tumbling slightly, so you’re going to need to control your satellite’s attitude.

Power is of course crucial, and in space that means solar cells. Managing solar cells, charging lithium batteries, and smoothing out the power cycles as the satellite enters the earth’s shadow or tumbles around out of control in space. Frequent charging and discharging of the battery is tough on it, so you’ll want to keep your charge/discharge cycles under 20% of the battery’s nominal capacity.

In outer space, your satellite will be bombarded by heavy ions that can short-circuit the transistors inside any IC. Sometimes, these transistors get stuck shorted, and the only way to fix the latch-up condition is to kill power for a little bit. For that reason, you’ll want to include latch-up detectors in the power supply to reset the satellite automatically when this happens. But this means that your code needs to expect occasional unscheduled resets, which in turn means that you need to think about how to save state and re-synchronize your timing, etc.

In short, there are a ridiculous amount of details that you have to attend to and think through before building your own CubeSat. We’ve just scratched the surface of [INCO]’s advice, but if we had to put the talk in a Tweet, we’d write “test everything, and have a plan B whenever possible”. This is, after all, rocket science.

32C3: Dieselgate — Inside The VW’s ECU

December 31, 2015 by Elliot Williams 67 Comments

[Daniel Lange] and [Felix Domke] gave a great talk about the Volkswagen emissions scandal at this year’s Chaos Communication Congress (32C3). [Lange] previously worked as Chief architect of process chain electronics for BMW, so he certainly knows the car industry, and [Domke] did a superb job reverse-engineering his own VW car. Combining these two in one talk definitely helps clear some of the smog around the VW affair.

[Lange]’s portion of the talk basically concerns the competitive and regulatory environments that could have influenced the decisions behind the folks at VW who made the wrong choices. [Lange] demonstrates how “cheating” Europe’s lax testing regime is fairly widespread, mostly because the tests don’t mimic real driving conditions. But we’re not sure who’s to blame here. If the tests better reflected reality, gaming the tests would be the same as improving emissions in the real world.

As interesting as the politics is, we’re here for the technical details, and the reverse-engineering portion of the talk begins around 40 minutes in but you’ll definitely want to hear [Lange]’s summary of the engine control unit (ECU) starting around the 38 minute mark.

[Domke] starts off with a recurring theme in our lives, and the 32C3 talks: when you want to reverse-engineer some hardware, you don’t just pull the ECU out of your own car — you go buy another one for cheap online! [Domke] then plugged the ECU up to a 12V power supply on his bench, hooked it up, presumably to JTAG, and found a bug in the firmware that enabled him to dump the entire 2MB of flash ROM into a disassembler. Respect! His discussion of how the ECU works is a must. (Did you know that the ECU reports a constant 780 RPM on the tacho when the engine’s idling, regardless of the actual engine speed? [Domke] has proof in the reverse-engineered code!)

The ECU basically takes in data from all of the car’s sensors, and based on a number of fixed data parameters that physically model the engine, decides on outputs for all of the car’s controls. Different car manufacturers don’t have to re-write the ECU code, but simply change the engine model. So [Domke] took off digging through the engine model’s data.

Long story short, the driving parameters that trigger an emissions reduction exactly match those that result from the EU’s standardized driving schedule that they use during testing — they’re gaming the emissions tests something fierce. You’ve really got to watch the presentation, though. It’s great, and we just scratched the surface.

And if you’re interested in our other coverage of the Congress, we have quite a collection going already.