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.
NYC beaches are where tropical beaches addicted to meth go to die. So says [Vije Miller] in his write-up for his Arduino sand matrix printer. It’s a clever idea, five servo-operated cardboard plungers that indent a pattern of dots in the sand as the device is pulled forward, resulting in something not unlike a dot matrix printer that can write messages in the sand.
He’s submitted it to us as a Fail Of The Week, because it doesn’t do a very good job of writing in the sand, and it’s burned out a servo. But we feel this isn’t entirely fair, because whether or not it has delivered the goods it’s still an excellent build. Cardboard isn’t a material we see much of here at Hackaday, but in this case he’s mastered it in a complex mechanism that while it may have proved a little too flexible for the job in hand is nevertheless a rather impressive piece of work.
You can see a brief video below the break showing it in action. He tells us his motivation has waned on this project, and expresses the hope that others will take up the baton and produce a more viable machine.
So I made an awful, kludgey, “there I fixed it” level repair, and I need to come clean. This is really a case of an ill-advised ground.
My thirteen-year-old daughter asked for help repairing her Macbook charging cable. Macbook chargers really aren’t meant to flex around a lot, and if you’re the kind of person who uses the laptop on, well, the lap, with the charger in, it’s gonna flex. Sooner or later the insulation around the plug housing, where it plugs into the laptop, cracks and the strands of wire can be seen. This type of cable consists of an insulated lead wire surrounded by a stranded ground wire. The problem with this configuration is that the stranded ground also gets flexed until it breaks, one strand at a time, until the cable stops working.
So it was with my daughter’s Macbook cable. I didn’t have the money to buy her a new one, and I figured we could repair the break. We busted out her WLC100 and sat down to get our solder on. She started off working while I supervised, then I took over later on.
We began by using an Xacto to cut away enough insulation to expose about half an inch of the stranded wire. We pulled the wire away from the insulated lead wire and twisted it into a single stranded wire parallel to the lead wire. Grabbing for the iron, we tinned the ground and soldered a length of 22-gauge solid wire to it. The way the ground connects to the plug is by passing through a conductive ring. My idea was to solder the other end of the 22-gauge wire to the metal ring. Here’s where things started to go wrong. This is, by the way, the part where I took over so you can blame me and not my kid.
My daughter was using the WLC100’s default tip. I should have grabbed my own iron, a WES51, or at least swapped in its ninja-sharp tip. The WLC100’s default tip is a big fat wedge and it was too big to put next to the plug, and the conductive ring quickly got covered in melted plastic and I couldn’t solder anything to it. Worse, I had accidentally burned through the insulation protecting the lead wire, and had to cover it in electrical tape.
What now? We were left with not being able to use the cable at all. One option was to wait until the goop had cooled and burnish it clean with a Dremel, then attempt to re-solder using an appropriate tip. However, that sounded like a lot of work. The solid wire was still securely soldered to the ground, so instead of trying to attach it to the cable side of the plug, I could connect it to the computer side, by shoving it into the socket alongside the plug. The business end of the plug has a big silver ground surrounding small gold positive leads, and touching the ground with the wire should work just fine, right?
It did. The computer charged up as happy as you’d like. And yet, I was left with the distinct feeling the solution could have been, I don’t know, cleaner. Certainly, the iFixit route shown here comes out much cleaner by sliding off the housing, clipping the damaged wire, and beginning anew. Clean as this is, it’s just waiting to happen the same way again.
So, brethren and sistren, lay on with brickbats and tell what I did wrong. What approaches have you used to fix cables broken where they meet the plug housing, and how do you improve the situation for the future?
Is this a case of a good design gone wrong in the build phase? Or is this DIY prosthetic arm a poor design from the get-go? Either way, [Will Donaldson] needs some feedback, and Hackaday is just the right place for that.
Up front, we’ll say kudos to [Will] for having the guts to post a build that’s less than successful. And we’ll stipulate that when it comes to fully articulated prosthetic hands, it’s easy to fail. His design is ambitious, with an opposable thumb, fingers with three phalanges each, a ball and socket wrist, and internal servos driving everything. It’s also aesthetically pleasing, with a little bit of an I, Robot meets Stormtrooper look.
But [Will]’s build was plagued with print problems from the start, possibly due to the complex nature of the bosses and guides within the palm for all the finger servos. Bad prints led to creaky joints and broken servos. The servos themselves were a source of consternation, modified as they were for continuous rotation and broken apart for remotely mounting their pots in the hand’s knuckles. The video below relates the tale of woe.
If you are a regular at creating printed circuit boards, it is likely that somewhere in your shop there will be a discard pile of boards on which you placed a component in the wrong orientation such that it would not work. It’s easily done, and don’t be shy to admit it if it’s happened to you.
[Bill] was making his own ARM developer board, taking inspiration from the ARM Pro Mini. He produced his PCB design and sent it off to the board house, and in due course received and reflow soldered a batch of beautiful dev boards. On power-up though, something was wrong! No USB device detected on his computer, a disaster. A lot of studying board and schematic led to the discovery that his push-button switches had been placed at 90 degrees to the orientation it should have had, leaving them in a permanently “on” position.
The PCB bug makes this is a Fail Of The Week post, but he transformed into a win with some experimentation with the switch outline in KiCAD before finding a way to mount the switches on the pads at 45 degrees, covering three of the pads. Well done, and well done for admitting the error.
[Editor’s note: been there, done that. One way to prevent the error is to only connect to diagonally opposite pins of the tact switch, so the rotation doesn’t matter.]
Having earlier asked others to come clean with their PCB mistakes, it’s probably appropriate to admit that Hackaday scribes are just as fallible as [Bill] when it comes to PCB layouts. Somewhere there may still be a board on this bench with a QFN microcontroller bodged on at 90 degrees to its original orientation, with cut tracks and tiny wire runs.
It’s not hard to detect meteors: go outside on a clear night in a dark place and you’re bound to see one eventually. But visible light detection is limiting, and knowing that meteors leave a trail of ions means radio detection is possible. That’s what’s behind this attempt to map meteor trails using broadcast signals, which so far hasn’t yielded great results.
The fact that meteor trails reflect radio signals is well-known; hams use “meteor bounce” to make long-distance contacts all the time. And using commercial FM broadcast signals to map meteor activity isn’t new, either — we’ve covered the “forward scattering” technique before. The technique requires tuning into a frequency used by a distant station but not a local one and waiting for a passing meteor to bounce the distant signal back to your SDR dongle. Capturing the waterfall display for later analysis should show characteristic patterns and give you an idea of where and when the meteor passed.
[Dave Venne] is an amateur astronomer who turns his eyes and ears to the heavens just to see what he can find. [Dave]’s problem is that the commercial FM band in the Minneapolis area that he calls home is crowded, to say the least. He hit upon the idea of using the National Weather Service weather radio broadcasts at around 160 MHz as a substitute. Sadly, all he managed to capture were passing airplanes with their characteristic Doppler shift; pretty cool in its own right, but not the desired result.
The comments in the RTL-SDR.com post on [Dave]’s attempt had a few ideas on where this went wrong and how to improve it, including the intriguing idea of using 60-meter ham band propagation beacons. Now it’s Hackaday’s turn: any ideas on how to fix [Dave]’s problem? Sound off in the comments below.
Museum exhibits are difficult to make, and they’re always breaking down; especially the interactive ones. This is a combination of budget, building a one-off, and the incredibly harsh abuse they take from children.
My first exhibit is an interactive laser show that turns waveforms from music into laser patterns, and different types of music have very different patterns. I knew from talking to the museum staff that industrial buttons were a necessity, but it turns out that industrial buttons are made under the assumption that tiny creatures won’t be constantly mashing, twisting, and (ew ew ew) licking the buttons. After a while, the buttons (and poor knob) were trashed.
The second exhibit is also interactive, but in this case it’s just a simple button that turns on a thing for a while, then shuts it off. You can read more about the Periodic Table of Motion on the project page. Here I thought; let’s use capacitive touch, put the sensor behind two layers of acrylic for protection, and then there won’t be any moving parts to break. I built a bunch of units, tested it for weeks, then installed it. Instant failure despite my diligence.
Something is different about the installation from my test environment. It might be the second layer of acrylic contributing. Maybe it’s the power supply and a strange ground issue. Maybe the room’s fluorescent lights are creating an electromagnetic field that is interrupting the sensor, or the carpet is causing static buildup that is somehow causing the midichlorians to reverse polarity and discharge through the base plate of prefabulated aluminite. In some of the cells, the button doesn’t work. In other cells it is extremely sensitive. In one column of the table (columns share a common piece of acrylic among 5 cells), a single touch will trigger all 5.
The circuit is an ATtiny with a 2.2M resistor between two pins, one of which connects via a short wire to a soldered connection to a piece of copper tape on the underside of an acrylic piece. The ATtiny is using the capsense library, which has features for automatic recalibration. Because of the way it is installed, I can’t reprogram them to adjust their sensitivity while inside the enclosure, so tweaking them post-install is not an option. I thought I could isolate the problem and use an existing capacitive touch sensor breakout of the AT42QT1010 hooked up to just power, but it had the exact same issue, meaning it’s either the power supply, the enclosure, or the room.
There are three paths I can go down now:
Find the problem and solve it
Switch to a photoresistor
Petition Hackaday for a better solution
Finding the problem and solving it will be a long and difficult path, especially since the museum environment is somehow and inexplicably different from the test environment. The photoresistor option has promise; when the user puts their hand over the paper button the light level changes. Some early testing indicates that it is easy to detect instantaneous change, and a trailing average and adjusting threshold make it robust enough for changing lighting conditions throughout the day. Further, it’s a simple change to the code, and the existing circuit board will accommodate the adjustment.
As for the third option…
What have you done for child-compatible touch interfaces that are robust enough to handle uncertain environments and harsh abuse? What buttons, knobs, and other interactive elements have you used?
There’s trouble in the Kingdom of Random – the smithies of the realm are having trouble sand-casting copper. And while [King Grant] might not be directly asking for help, we think the Hackaday community might have plenty to say about his efforts.
We’ve all seen plenty of sand casting efforts before, including attempts to make otherwise unobtainable engine parts. And “lost foam” casting, where a model of the part is constructed of polystyrene foam that flashes off when the molten metal is poured, is a relatively new twist on the technique that’s been used to good effect on a recent Gingery lathe build. But most backyard foundries work in aluminum, which is apparently much easier to work with than the copper that [Grant Thompson] is working with. Ironically, his first pour worked the best — not perfect, but at least the islands defining the spokes of his decorative piece didn’t break off and float away as they did in every pour shown in the video below. That leads us to think that the greensand is too dry by the second video. Or perhaps the density of copper just makes it more likely for the sand to float. Maybe a cope and drag mold is in order to keep the islands in place and direct the flow of the copper better.
We know there’s a lot of expertise out there, so sound off in the comments about what you think is going on with these pours.