[Sprite_tm] Gives Near Death VFD A Better Second Life

April 20, 2016 by Elliot Williams 16 Comments

[Sprite_tm] picked up some used VFD displays for cheap, and wanted to make his own custom temperature and air-quality display. He did that, of course, but turned it into a colossal experiment in re-design to boot. What started out as a $6 used VFD becomes priceless with the addition of hours of high-powered hacking mojo.

You see, the phosphor screen had burnt-in spots where the old display was left static for too long. A normal person would either live with it or buy new displays. [Sprite_tm] ripped off the old display driver and drives the row and column shift registers using the DMA module on a Raspberry Pi2, coding up his own fast PWM/BCM hybrid scheme that can do greyscale.

He mapped out the individual pixels using a camera and post processing in The Gimp to establish the degradation of burnt-in pixels. He then re-wrote a previous custom driver project to compensate for the pixels’ inherent brightness in firmware. After all that work, he wrapped the whole thing up in a nice wooden frame.

There’s a lot to read, so just go hit up his website. High points include the shift-register-based driver transplant, the bit-angle modulation that was needed to get the necessary bit-depth for the grayscale, and the PHP script that does the photograph-based brightness correction.

Picking a favorite [Sprite_tm] hack is like picking a favorite ice-cream flavor: they’re all good. But his investigation into hard-drive controller chips still makes our head spin just a little bit. If you missed his talks about the Tamagotchi Singularity from the Hackaday SuperCon make sure you drop what you’re doing and watch it now.

The Sincerest Form Of Flattery: Cloning Open-Source Hardware

April 19, 2016 by Elliot Williams 79 Comments

We’re great proponents (and beneficiaries) of open-source hardware here at Hackaday. It’s impossible to overstate the impact that the free sharing of ideas has had on the hacker hardware scene. Plus, if you folks didn’t write up the cool projects that you’re making, we wouldn’t have nearly as much to write about.

We also love doing it ourselves. Whether this means actually etching the PCB or just designing it ourselves and sending it off to the fab, we’re not the types to pick up our electronics at the Buy More (except when we’re planning to tear them apart). And when we don’t DIY, we like our electrons artisanal because we like to support the little guy or girl out there doing cool design work.

So it’s with a moderately heavy heart that we’ll admit that when it comes to pre-built microcontroller and sensor boards, I buy a lot of cheap clones. Some of this is price sensitivity, to be sure. If I’m making many different one-off goofy projects, it just doesn’t make sense to pay the original-manufacturer premium over and over again for each one. A $2 microcontroller board just begs to be permanently incorporated into give-away projects in a way that a $20 board doesn’t. But I’m also positively impressed by some of the innovation coming out of some of the clone firms, to the point that I’m not sure that the “clone” moniker is fair any more.

This article is an attempt to come to grips with innovation, open source hardware, and the clones. I’m going to look at these issues from three different perspectives: the firm producing the hardware, the hacker hobbyist purchasing the hardware, and the innovative hobbyist who just wants to get a cool project out to as many people as possible. They say that imitation is the sincerest form of flattery, but can cloning go too far? To some extent, it depends on where you’re sitting.

Continue reading “The Sincerest Form Of Flattery: Cloning Open-Source Hardware” →

The Predictability Problem With Self-Driving Cars

April 18, 2016 by Elliot Williams 93 Comments

A law professor and an engineering professor walk into a bar. What comes out is a nuanced article on a downside of autonomous cars, and how to deal with it. The short version of their paper: self-driving cars need to be more predictable to humans in order to coexist.

We share living space with a lot of machines. A good number of them are mobile and dangerous but under complete human control: the car, for instance. When we want to know what another car at an intersection is going to do, we think about the driver of the car, and maybe even make eye contact to see that they see us. We then think about what we’d do in their place, and the traffic situation gets negotiated accordingly.

When its self-driving car got into an accident in February, Google replied that “our test driver believed the bus was going to slow or stop to allow us to merge into the traffic, and that there would be sufficient space to do that.” Apparently, so did the car, right before it drove out in front of an oncoming bus. The bus driver didn’t expect the car to pull (slowly) into its lane, either.

All of the other self-driving car accidents to date have been the fault of other drivers, and the authors think this is telling. If you unexpectedly brake all the time, you can probably expect to eventually get hit from behind. If people can’t read your car’s AI’s mind, you’re gonna get your fender bent.

The paper’s solution is to make autonomous vehicles more predictable, and they mention a number of obvious solutions, from “I-sense-you” lights to inter-car communication. But then there are aspects we hadn’t thought about: specific markings that indicate the AIs capabilities, for instance. A cyclist signalling a left turn would really like to know if the car behind has the new bicyclist-handsignal-recognition upgrade before entering the lane. The ability to put your mind into the mind of the other car is crucial, and requires tons of information about the driver.

All of this may require and involve legislation. Intent and what all parties to an accident “should have known” are used in court to apportion blame in addition to the black-and-white of the law. When one of the parties is an AI, this gets murkier. How should you know what the algorithm should have been thinking? This is far from a solved problem, and it’s becoming more relevant.

We’ve written on the ethics of self-driving cars before, but simply in terms of their decision-making ability. This paper brings home the idea that we also need to be able to understand what they’re thinking, which is as much a human-interaction and legal problem as it is technological.

[Headline image: Google Self-Driving Car Project]

Sciencing DVD-RW Laser Diodes

April 18, 2016 by Elliot Williams 16 Comments

If you’ve played around with laser diodes that you’ve scavenged from old equipment, you know that it can be a hit-or-miss proposition. (And if you haven’t, what are you waiting for?) Besides the real risk of killing the diode on extraction by either overheating it or zapping it with static electricity, there’s always the question of how much current to put into the thing.

[DeepSOIC] decided to answer the latter question — with science! — for a DVD-burner laser that he’s got. His apparatus is both low-tech and absolutely brilliant, and it looks like he’s getting good data. So let’s have a peek.

First up is the detector, which is nothing more than a photodiode, 100k ohm load resistor, and a big capacitor for a power supply. We’d use a coin-cell battery, but given how low the discharge currents are, the cap makes a great rechargeable alternative. The output of the photo diode goes straight into the scope probe.

He then points the photodiode at the laser spot (on a keyboard?) and pulses the laser by charging up a capacitor and discharging it through the laser and a resistor to limit total current. The instantaneous current through the laser diode is also measured on the scope. Plotting both the current drawn and the measured brightness from the photodiode gives him an L/I curve — “lumens” versus current.

Look on the curve for where it stops being a straight line, slightly before the wiggles set in. That’s about the maximum continuous operating current. It’s good practice to de-rate that to 90% just to be on the safe side. Here it looks like the maximum current is 280 mA, so you probably shouldn’t run above 250 mA for a long time. If the diode’s body gets hot, heatsink it.

If you want to know everything about lasers in general, and diode lasers in particular, you can’t beat Sam’s Laser FAQ. We love [DeepSOIC]’s testing rig, though, and would love to see the schematic of his test driver. We’ve used “Sam’s Laser Diode Test Supply 1” for years, and we love it, but a pulsed laser tester would be a cool addition to the lab.

What to do with your junk DVD-ROM laser? Use the other leftover parts to make a CNC engraver? But we don’t need to tell you what to do with lasers. Just don’t look into the beam with your remaining good eye!

Are You In Bed?

April 17, 2016 by Elliot Williams 20 Comments

If you’re building an omniscient home-automation system, it’s ability to make decisions is only as good as the input you give it. [Petewill]’s self-made panopticon now knows when someone is in bed. That way, the [petewill]’s automatic blinds won’t open when he’s sleeping late on weekends.

[Petewill] didn’t take the easy way out here. (In our mind, that would be a weight sensor under one of the bed’s feet.) Instead, his system more flexible and built on capacitive sensing. He’d tried force sensors and piezos under the mattress, but none of them were as reliable as capacitance. A network of copper tape under the mattress serves as the antenna.

Continue reading “Are You In Bed?” →

Building A Taller Drillpress

April 16, 2016 by Elliot Williams 23 Comments

[BF38] bought a mid-range miniature drill-press, and discovered that it was just too short for some of his applications. “No problem,” he thought, “I’ll just measure the column and swap it out for a longer one.” It sounds foolproof on paper.

He discovered, after having bought a new 48.3 mm steel column, that the original was 48 mm exactly in diameter. He’d have to make it fit. But how do you bore out a 48 mm diameter hole, keeping it perfectly round, and only increase the diameter by 0.3 mm? A file is out because you’d never get it round. A lathe is out because [BF38] doesn’t have a lathe.

[BF38] ended up making a DIY honing head, which is a gadget that presses (in this case) two pieces of sandpaper evenly against the sides of the hole to be widened. The head in question is a little bit rough — it was made as a learning project, but it looks like it served the purpose admirably.

Milk-Based 3D Scanner

April 16, 2016 by Elliot Williams 32 Comments

3D scanners don’t have to be expensive or high-tech because all of the magic goes on in software. The hardware setup just needs to gather a bunch of cross-sections. In perhaps the lowest-tech of scanners that we’ve seen, [yenfre]’s GotMesh scanner uses milk.

Specifically, the apparatus is a pair of boxes, one with a hole drilled in it. You put the object in the top box and fill it with milk to cover the object. A camera takes pictures of the outline of the object in the milk as it drains out the hole, these get stitched together, and voilà.

There are limitations to this method. The object gets soaked in milk, so it won’t work for scanning sand-castles. (It’s optimally suited for chocolate-chip cookies, in our opinion.) If the camera is located directly above, the objects have to get wider as the milk drains out. You can do multiple takes with the object rotated at different angles or use multiple cameras to solve this problem. The edge-detection software will have issues with white objects in milk, so maybe you’ll want to scan that porcelain figurine in coffee, but you get the idea. More seriously, the rate of milk drain will slow down a bit as the amount of milk in the upper box decreases. This could also be handled in software.

In all, we’re not surprised that we don’t see commercial versions of this device, but we love the idea. It’s based on this experiment where they dip a guy in a tank of ink! If you just drank all your milk, but still have a line-laser lying around, maybe this build is more your speed. What’s your cheapest 3D scanner solution?