Let’s Talk About Elon Musk’s Submarine

July 17, 2018 by Tom Nardi 223 Comments

When word first broke that Elon Musk was designing a kid-sized submarine to help rescue the children stuck in Thailand’s Tham Luang cave, it seemed like a logical thing for Hackaday to cover. An eccentric builder of rockets and rocket-launched electric sports cars, pushing his engineering teams and not inconsiderable financial resources into action to save children? All of that talk about Elon being a real life Tony Stark was about to turn from meme into reality; if the gambit paid off, the world might have it’s first true superhero.

With human lives in the balance, and success of the rescue attempt far from assured (regardless of Elon’s involvement), we didn’t feel like playing arm-chair engineer at the time. Everyone here at Hackaday is thankful that due to the heroics of the rescuers, including one who paid the ultimate price, all thirteen lives were saved.

Many said it couldn’t be done, others said even saving half of the children would have been a miracle. But Elon’s submarine, designed and built at a breakneck pace and brought to Thailand while some of the children were still awaiting rescue, laid unused. It wasn’t Elon’s advanced technology that made the rescue possible, it was the tenacity of the human spirit.

Now, with the rescue complete and the children well on their way to returning to their families, one is left wondering about Elon’s submarine. Could it have worked?

Continue reading “Let’s Talk About Elon Musk’s Submarine” →

Freak Out Your Smartphone With Ultrasound

July 17, 2018 by Tom Nardi 13 Comments

There’s a school of thought that says complexity has an inversely proportional relation to reliability. In other words, the smarter you try to make something, the more likely it is to end up failing for a dumb reason. As a totally random example: you’re trying to write up a post for a popular hacking blog, all the while yelling repeatedly for your Echo Dot to turn on the fan sitting three feet away from you. It’s plugged into a WeMo Smart Plug, so you can’t even reach over and turn it on manually. You just keep repeating the same thing over and over in the sweltering July heat, hoping your virtual assistant eventually gets the hint. You know, something like that. That exact scenario definitely has never happened to anyone in the employ of this website.

So it should come as no surprise that the more sensors we pack into devices, the more potential avenues of failure we open up. [Julio Della Flora] writes in to tell us of some interesting experiments he’s been performing with the MEMS gyroscope in his Xiaomi MI5S Plus smartphone. He’s found that with a function generator and a standard speaker, he’s able to induce false sensor readings.

Now it should be said, [Julio] is not claiming to be the first person to discover that ultrasonic sound can confuse MEMS gyroscopes and accelerometers. At Black Hat 2017, a talk was given in which a “Sonic Gun” was used to do things like knock over self-balancing robots using the same principle. The researchers were also able to confuse a DJI Phantom drone, showing that the technique has the potential to be weaponized in the real-world.

It’s interesting to see more validation that not only is this a continuing issue with consumer devices, but that it doesn’t necessarily take expensive or exotic hardware to execute. Yet another reason to take ultrasound seriously as a potential threat.

Continue reading “Freak Out Your Smartphone With Ultrasound” →

CortexProg Is A Real ARM-Twister

July 17, 2018 by Elliot Williams 32 Comments

We’ve got a small box of microcontroller programmers on our desktop. AVR, PIC, and ARM, or at least the STMicro version of ARM. Why? Some program faster, some debug better, some have nicer cables, and others, well, we’re just sentimental about. Don’t judge.

[Dmitry Grinberg], on the other hand, is searching for the One Ring. Or at least the One Ring for ARM microcontrollers. You see, while all ARM chips have the same core, and thus the same SWD debugging interface, they all write to flash differently. So if you do ARM development with offerings from different chip vendors, you need to have a box full of programmers or shell out for an expensive J-Link. Until now.

[Dmitry] keeps his options open by loading up the flash-specific portion of the code as a plugin, which lets the programmer figure out what chip it’s dealing with and then lookup the appropriate block size and flash memory procedures. One Ring. He also implements a fast printf-style debugging aid that he calls “ZeroWire Trace” that we’d like to hear more about. Programming and debugging are scriptable in Lua, and it can do batch programming based on reading chip IDs.

You can build your own CortexProg from an ATtiny85, two diodes, and two current-limiting resistors: the standard V-USB setup. The downside of the DIY? Slow upload speed, but at least it’ll get you going. He’s also developed a number of fancier versions that improve on this. Version four of the hardware is just now up on Kickstarter, if you’re interested.

If you’re just using one vendor’s chips or don’t mind having a drawer full of programmers, you might also look into the Black Magic Probe. It embeds a GDB server in the debugger itself, which is both a cool trick and the reason that you have to re-flash the programmer to work with a different vendor’s chips. Since the BMP firmware is open, you can make your own for the cost of a sacrificial ST-Link clone, about $4.

On the other hand, if you want a programmer that works across chip families, is scriptable, and can do batch uploads, CortexProg looks like a caviar programmer on a fish-bait budget. We’re going to try one out soon.

Oh and if you think [Dmitry Grinberg] sounds familiar, you might like his sweet Dreamcast VRU hack, his investigations into the Cypress PSOCs, or his epic AVR-based Linux machine.