Fail Of The Week: Mistaking Units For Values

April 24, 2021 by Jenny List 93 Comments

Usually when we post a Fail Of The Week, it’s a heroic tale of a project made with the best of intentions that somehow failed to hit its mark. The communicator that didn’t, or the 3D-printed linkage that pushed the boundaries of squirted plastic a little bit too far. But today we’re bringing you something from a source that should be above reproach, thanks to [Boldport] bringing us a Twitter conversation between [Stargirl] and [Ticktok] about a Texas Instruments datasheet.

The SN65220 is a suppressor chip for USB ports, designed to protect whatever the USB hardware is from voltage spikes. You probably have several of them without realising it, the tiny six-pin package nestling on the PCB next to the USB connector. Its data sheet reveals that it needs a resistor network between it and the USB device it protects, and it’s this that is the source of the fail.

There are two resistors, a 15kO and a 27O, 15k ohms, and 270 ohms, right? Looking more closely though, that 27O is not 270 with a zero, but 27O with a capital “O”, so in fact 27 ohms.

The symbol for resistance has for many decades been an uppercase Greek Omega, or Ω. It’s understood that sometimes a typeface doesn’t contain Greek letters, so there is a widely used convention of using an uppercase “R” to represent it, followed by a “K” for kilo-ohms, an “M” for mega-ohms, and so on. Thus a 270 ohm resistor will often be written as 270R, and 270 kilo-ohm one as 270K. In the case of a fractional value the convention is to put the fraction after the letter, so for example 2.7kilo-ohms becomes 2K7. For some reason the editor of the TI datasheet has taken it upon themselves to use an uppercase “O” to represent “Ohms”, leading to ambiguity over values below 1 kilo-ohm.

We can’t imagine an engineer would have made that choice so we’re looking towards their publishing department on this one, and meanwhile we wonder how many USB devices have gone to manufacture with a 270R resistor in their data path. After all, putting the wrong resistor in can affect any of us.

Fail Of The Week: Roboracer Meets Wall

November 8, 2020 by Roger Cheng 52 Comments

There comes a moment when our project sees the light of day, publicly presented to people who are curious to see the results of all our hard work, only for it to fail in a spectacularly embarrassing way. This is the dreaded “Demo Curse” and it recently befell the SIT Acronis Autonomous team. Their Roborace car gained social media infamy as it was seen launching off the starting line and immediately into a wall. A team member explained what happened.

A few explanations had started circulating, but only in the vague terms of a “steering lock” without much technical detail until this emerged. Steering lock? You mean like The Club? Well, sort of. While there was no steering wheel immobilization steel bar on the car, a software equivalent did take hold within the car’s systems. During initialization, while a human driver was at the controls, one of the modules sent out NaN (Not a Number) instead of a valid numeric value. This was never seen in testing, and it wreaked havoc at the worst possible time.

A module whose job was to ensure numbers stay within expected bounds said “not a number, not my problem!” That NaN value propagated through to the vehicle’s CAN data bus, which didn’t define the handling of NaN so it was arbitrarily translated into a very large number causing further problems. This cascade of events resulted in a steering control system locked to full right before the algorithm was given permission to start driving. It desperately tried to steer the car back on course, without effect, for the few short seconds until it met the wall.

While embarrassing and not the kind of publicity the Schaffhausen Institute of Technology or their sponsor Acronis was hoping for, the team dug through logs to understand what happened and taught their car to handle NaN properly. Driving a backup car, round two went very well and the team took second place. So they had a happy ending after all. Congratulations! We’re very happy this problem was found and fixed on a closed track and not on public roads.

[via Engadget]

Fail Of The Week: Putting Guitar Strings On A Piano

October 12, 2020 by Sven Gregori 35 Comments

The piano is a bit of an oddball within the string instrument family. Apart from rarely seeing people carry one around on the bus or use its case to discretely conceal a Tommy Gun, the way the strings are engaged in the first place — by having little hammers attached to each key knock the sound of of them — is rather unique compared to the usual finger or bow movement. Still, it is a string instrument, so it’s only natural to wonder what a piano would sound like if it was equipped with guitar strings instead of piano wire. Well, [Mattias Krantz] went on to actually find out the hard way, and shows the results in this video.

After a brief encounter with a bolt cutter, the point of no return was reached soon on. Now, the average piano has 88 keys, and depending on the note, a single key might have up to three strings involved at once. In case of [Mattias]’ piano — which, in his defense, has certainly seen better days — a total of 210 strings had to be replaced for the experiment. Guitars on the other hand have only six, so not only did he need 35 packs of guitar strings, the gauge and length variety is quite limited on top. What may sound like a futile endeavor from the beginning didn’t get much better over time, and at some point, the strings weren’t long enough anymore and he had to tie them together. Along with some inevitable breakage, he unfortunately ran out of strings and couldn’t finish the entire piano, though it seems he still managed to roughly cover a guitar’s frequency range, so that’s an appropriate result.

We’re not sure if [Mattias] ever expected this to actually work, but it kinda does — there is at least some real sound. Are the results more than questionable though? Oh absolutely, but we have to admire the audacity and perseverance he showed to actually pull through with this. It took him 28 hours just to get the guitar strings on, and another good amount of time to actually get them all in tune. Did it pay off? Well, that depends how you look at it. It definitely satisfied his and other’s curiosity, and the piano produces some really unique and interesting sounds now — but check for yourself in the video after the break. But that might not be for everyone, so luckily there are less final ways to change a piano’s sound. And worst case, you can always just turn it into a workbench.

(Thanks for the tip, [Keith])

Continue reading “Fail Of The Week: Putting Guitar Strings On A Piano” →

Fail Of The Week: This SD Card Won’t Slot

June 29, 2020 by Jenny List 23 Comments

If you’ve got a few self-designed PCBs under your belt, you probably know the pain of missing some little detail and having to break out the bodge wires to fix it. So we feel for [Arsenio Dev], who placed an SD card slot next to an SoC, only to find that it was the wrong way round. Rather than tossing it in the bin, he decided to employ a particularly crafty set of bodge wires that curve over the board and connect to an SD card adapter on the other side.

Our attention was taken by the board itself, he’s posted little information about it and taken pains to conceal one of the pieces of text on it. Since it has an Octavo Systems BeagleBone-on-chip, a slot for a cellular modem, and a connector marked “CONNECT AERONET HERE” which we are guessing refers to the Aeronet sun photometry network, we’re guessing it might be a controller for remotely-sited nodes for that system. Either way it’s enough to have us intrigued, and we wish him every success with the next spin.

Meanwhile, this certainly isn’t the first PCB CAD fail we’ve brought you.

Fail Of The Week: How Not To Watercool A PC

June 17, 2020 by Dan Maloney 50 Comments

To those who choose to overclock their PCs, it’s often a “no expense spared” deal. Fancy heat sinks, complicated liquid cooling setups, and cool clear cases to show off all the expensive guts are all part of the charm. But not everyone’s pockets are deep enough for off-the-shelf parts, so experimentation with cheaper, alternatives, like using an automotive fuel pump to move the cooling liquid, seems like a good idea. In practice — not so much.

The first thing we thought of when we saw the title of [BoltzBrain]’s video was a long-ago warning from a mechanic to never run out of gas in a fuel-injected car. It turns out that the gasoline acts as a coolant and lubricant for the electric pump, and running the tank dry with the power still applied to the pump quickly burns it out. So while [BoltzBrain] expected to see corrosion on the brushes from his use of water as a working fluid, we expected to see seized bearings as the root cause failure. Looks like we were wrong: at about the 6:30 mark, you can see clear signs of corrosion on the copper wires connecting to the brushes. It almost looks like the Dremel tool cut the wire, but that green copper oxide is the giveaway. We suspect the bearings aren’t in great shape, either, but that’s probably secondary to the wires corroding.

Whatever the root cause, it’s an interesting tour inside a common part, and the level of engineering needed to build a brushed motor that runs bathed in a highly flammable fluid is pretty impressive. We liked the axial arrangement of the brushes and commutator especially. We wonder if fuel pumps could still serve as a PC cooler — perhaps changing to a dielectric fluid would do the trick.

Continue reading “Fail Of The Week: How Not To Watercool A PC” →

Fail Of The Week: Bright Idea For LED Signs Goes Bad

May 8, 2020 by Dan Maloney 43 Comments

Typically when we select a project for “Fail to the Week” honors, it’s because something went wrong with the technology of the project. But the tech of [Leo Fernekes]’ innovative LED sign system was never the problem; it was the realities of scaling up to production as well as the broken patent process that put a nail in this promising project’s coffin, which [Leo] sums up succinctly as “The Inventor’s Paradox” in the video below.

The idea [Leo] had a few years back was pretty smart. He noticed that there was no middle ground between cheap, pre-made LED signs and expensive programmable signboards, so he sought to fill the gap. The result was an ingenious “LED pin”, a tiny module with an RGB LED and a microcontroller along with a small number of support components. The big idea is that each pin would store its own part of a display-wide animation in flash memory. Each pin has two terminals that connect to metal cladding on either side of the board they attach to. These two conductors supply not only power but synchronization for all the pins with a low-frequency square wave. [Leo]’s method for programming the animations — using a light sensor on each pin to receive signals from a video projector — is perhaps even more ingenious than the pins themselves.

[Leo]’s idea seemed destined for greatness, but alas, the cruel realities of scaling up struck hard. Each prototype pin had a low part count, but to be manufactured economically, the entire BOM would have to be reduced to almost nothing. That means an ASIC, but the time and expense involved in tooling up for that were too much to bear. [Leo] has nothing good to say about the patent game, either, which his business partners in this venture insisted on playing. There’s plenty of detail in the video, but he sums it up with a pithy proclamation: “Patents suck.”

Watching this video, it’s hard not to feel sorry for [Leo] for all the time he spent getting the tech right only to have no feasible way to get a return on that investment. It’s a sobering tale for those of us who fancy ourselves to be inventors, and a cautionary tale about the perils of participating in a patent system that clearly operates for the benefit of the corporations rather than the solo inventor. It’s not impossible to win at this game, as our own [Bob Baddeley] shows us, but it is easy to fail.

Continue reading “Fail Of The Week: Bright Idea For LED Signs Goes Bad” →

Fail Of The Week: How Not To Die Of Boredom During Isolation

April 1, 2020 by Dan Maloney 26 Comments

They say you can’t actually die from boredom, but put a billion or so people into self-isolation, and someone is bound to say, “Hold my beer and watch this.” [Daniel Reardon]’s brush with failure, in the form of getting magnets stuck up his nose while trying to invent a facial touch reminder, probably wasn’t directly life-threatening, but it does underscore the need to be especially careful these days.

The story begins with good intentions and a small stack of neodymium magnets. [Daniel]’s idea for a sensor to warn one of impending face touches was solid: a necklace with magnetic sensors and wristbands studded with magnets. Sounds reasonable enough; one can easily see a compact system that sounds an alarm when a hand subconsciously crosses into the Danger Zone while going in for a scratch. Lacking any experience in circuits, though, [Daniel] was unable to get the thing working, so he started playing with the magnets instead. One thing led to another, and magnets were soon adorning his earlobes, and then his nostrils. Unfortunately, two magnets became locked on either side of his septum, as did two others meant to neutralize the pull of the first pair. So off [Daniel] went to the emergency department for a magnetectomy.

Of course it’s easy to laugh at someone’s misfortune, especially when self-inflicted. And the now-degaussed [Daniel] seems to be a good sport about the whole thing. But the important thing here is that we all do dumb things, and hackers need to be especially careful these days. We often work with sharp, pointy, sparky, toxic, or flammable things, and if we don’t keep our wits about us, we could easily end up in an ER somewhere. Not only does that risk unnecessary exposure to COVID-19, but it also takes medical resources away from people who need it more than you do.

By all means, we should be hacking away these idle hours. Even if it’s not in support of COVID-19 solutions, continuing to do what we do is key to our mental health and well-being. But we also need to be careful, to not stretch dangerously beyond our abilities, and to remember that the safety net that’s normally there to catch us is full of holes now.

Thanks to [gir.st] for the tip — you actually were the only one to send this in.