Fail Of The Week: Mistaking Units For Values

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 schematic
The SN65220 schematic

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.

Hack The Cloud!

The obvious rants against software or services “in the cloud” are that you don’t own it, your data isn’t on your own hard drive, or that, when the interwebs are down, you just can’t get your work done. But the one that really grinds my gears is that, at least for many cloud services, you just can’t play around with them. Why does that matter? Well, as a hacker type, of course, I like to fool around, but more deeply, I feel that this invitation to play around is what’s going to grow up the next generation of hackers. Openness matters not just for now, but also for the future.

Of course, it’s unfair to pin all of this on the cloud. There are plenty of services with nice open APIs that let you play around with their systems as much as you want — witness the abundance of amusing things you can do with Twitter or Twitch. Still, every day seems to bring another formerly-open API that gets bought up by some wealthy company and shut down. I built a nice “is it going to rain today” display out of a meter-long WS2812 strip and an ESP8266, but Dark Sky API got bought up by Apple and is going dark soon (tee-hee!) leaving me thinking of how I’m going to get easy weather data in the next few months.

Whisper your tip in our earOr take my e-mail annunciator. I wrote a little script that, when I have new mail that’s work related or from my wife (read: important), it displays the subject line on a VFD that I have perched on my monitor. This works with Gmail, which I have to use for work, because they support IMAP so at least I can do cool things with the mail once it reaches my server. But can I do anything with Google Groups, which we use for the Hackaday Tip Line? Fat chance!

So there’s good “cloud” and there’s bad “cloud”. Good cloud is open cloud. Good cloud invites you to play, to innovate, and to come up with the right solutions for yourself. Good cloud gives you access to your data. Good cloud is hackable cloud. Let’s see more of that.

Taking Reverse Engineering To The Skies: Cheap Drone Gets PX4 Autopilot

Sometimes bad software is all that is holding good hardware back. [Michael Melchior] wanted to scavenge some motors and propellers for another project, so he bought an inexpensive quadcopter intending to use it for parts. [Michael] was so surprised at the quality of the hardware contained in his $100 drone that he decided to reverse engineer his quadcopter and give the autopilot firmware a serious upgrade.

Upon stripping the drone down, [Michael] found that it came with a flight management unit based on the STM32F405RG, an Inertial Measurement Unit, magnetic compass, barometric pressure sensor, GPS, WiFi radio, camera with tilt, optical flow sensor, and ultrasonic distance sensor, plus batteries and charger! The flight management unit also had unpopulated headers for SWD, and—although the manufacturer’s firmware was protected from reading—write protection hadn’t been enabled, so [Michael] was free to flash his own firmware.

We highly recommend you take a look at [Michael]’s 10 part tour de force of reverse engineering which includes a man-in-the-middle attack with a Raspberry Pi to work out its WiFi communication, porting the open-source autopilot PX4 to the new airframe, and deciphering unknown serial protocols. There are even amusing shenanigans like putting batteries in the oven and freezer to help figure out which registers are used as temperature sensors. He achieves liftoff at the end, and we can’t wait to see what else he’s able to make it do in the future.

Of course, [Michael] is no stranger to hacking imported quadcopters, and if you’re interested in PX4 but want something quieter than a quadcopter, take a look at this autopilot-equipped glider.

WSPR May Hold The Key To MH370 Final Position

The disappearance of Malaysia Airlines flight MH370 after an unexplained course change sent it flying south over the Indian Ocean in March 2014 still holds the mystery of the wreck’s final location. There have been a variety of efforts to narrow down a possible search area over the years, and now we have news of a further angle from an unexpected source. It’s possible that the aircraft’s path could show up in radio scatter detectable as anomalously long-distance contacts using the amateur radio WSPR protocol.

WSPR is a low-power amateur radio mode designed to probe and record the radio propagation capabilities of the atmosphere. Transmit beacons and receiving stations run continuously, and all contacts however fleeting are recorded to an online database. This can be mined by researchers with an interest in the atmosphere, but in this case it might also provide clues to the missing airliner’s flightpath. By searching for anomalously long-distance WSPR contacts whose path crosses the expected position of MH370 it’s possible to spot moments when the aircraft formed a reflector for the radio waves. These contacts can then either confirm positions already estimated using other methods, or even provide further course points. It’s an impressive demonstration of the unexpected data that can lurk in a trove such as the WSPR logbook, and also that while messing about on the airwaves the marks we leave behind us can have more benefit than simply bragging rights over the DX we’ve worked.

If this WSPR business intrigues you, then have a read of the piece in our $50 Ham series about it.

Header: Laurent ERRERA from L’Union, France, CC BY-SA 2.0.

[via Southgate ARC]

Building A Gas-Powered Pressure Washer

While you can always buy the tools you need, there’s something to be said for the satisfaction gained when you pick up a tool you built yourself. [Workshop From Scratch] has built a following out of building his own gear, the latest of which involved putting together a gas-powered pressure washer.

The key to the build was to keep things completely self-contained. All the consumables – water, soap, and wax – are kept onboard the washer to avoid having to run hoses and so on. A small gas engine is the heart of the build, hooked up to a high-pressure water pump. It even comes complete with a starter motor, making it a certified luxury garden tool. It’s also hooked up to two tanks holding cleaning solutions for car washing purposes, which feed into the pump via an auxiliary port for mixing. It’s all assembled on a custom steel frame welded together from rectangular hollow sections.

It’s a build that demonstrates how you can use your skills to build tools that suit your workflow, rather than just putting up with whatever is available off-the-shelf. We’ve seen his work before, too – building other tools like this motorised plasma cutter. Video after the break.

Continue reading “Building A Gas-Powered Pressure Washer”

Debug ARM Virtually

With the advent of super powerful desktop computers, many developers make use of some sort of virtual or psuedo-virtual machines (VM). We run Windows in a VM and do kernel development in a VM, too. If you are emulating the same kind of computer you are on then the process is simpler, but it is possible to run, say, ARM code on an x86 (or vice versa) but with possibly slower performance than running natively. QEMU is probably the best-known program that allows a CPU to run code targeting a different CPU, but — by default — it targets desktop, laptop, and server-class machines, not tiny embedded boards. That’s where xPack QEMU Arm comes in. It allows you to run and debug embedded Cortex-M devices in an emulated environment on a host computer.

The tool supports boards like the Maple — which means it should support bluepill, along with popular boards such as the Nucleo, some discovery boards, and several from Olimex. They have plans to support several popular boards from TI, Freescale, and others, but no word on when that will happen. You can see a decidedly simple video example from [EmbeddedCraft] of blinking a virtual LED in the video below, although you might like to mute your audio before playing it.

Continue reading “Debug ARM Virtually”

Modding A Hot Wheels Car Into A Radio Controlled Drift Weapon

Hot Wheels are some of the most popular diecast toy cars worldwide. The car bodies are faithful recreations of the real thing, though the models are mere stationary playthings. That wasn’t good enough for [Jakarta Diecast Project], who set about modifying a little BMW E30 M3 into an awesome radio-controlled drift car.

The build starts by disassembling the original car, and pulling out the original wheels. The baseplate is then modified to accept a new rear suspension and axle assembly. A small DC motor is mounted to the assembly to drive the rear wheels. A set of front steering knuckles are then installed up front, with their own suspension and hooked up to a tiny servo for steering. Everything’s controlled by a compact off-the-shelf RC receiver, which even features a gyro to help keep the tiny car straight under acceleration. The bodyshell is then stripped of paint, and given a sweet bodykit, before receiving a lurid orange paint job and decals. It’s reattached to the car’s baseplate via magnets, which make taking the car apart easy when service or modifications are required.

While the build doesn’t go into the nitty gritty on some of the harder parts, like the construction of the incredibly complex front knuckles, it’s nonetheless a great guide to building such a tiny and well-presented RC car. In looks and performance, the result trounces typical commercial offerings in the same scale, as you’d expect from such a hand-crafted masterpiece. It may not be the smallest RC car we’ve featured, but it is one of the coolest. Video after the break.

Continue reading “Modding A Hot Wheels Car Into A Radio Controlled Drift Weapon”