ESP32 Adds Bluetooth To GameCube Controllers

While it might not be the most traditional design, there’s no debating that Nintendo created something truly special when they unleashed the GameCube controller on an unsuspecting world back in 2001. Hardcore fans are still using the controller to this day with current-generation Nintendo consoles, and there’s considerable interest in adding modern conveniences like USB support to the nearly 20-year-old design.

One particularly promising project is the BlueCubeMod created by [Nathan Reeves]. He’s developed a small custom PCB that can be installed into an official GameCube controller to turn it into a Bluetooth device. You do have to sacrifice the original cord and force feedback for this mod, but we think many will see the ability to use this iconic controller with their computer or phone as a pretty fair trade.

The PCB holds an ESP32-PICO-D4 which is operating as a standard Bluetooth HID controller for maximum compatibility with modern systems. Control signals are pulled directly from the controller’s original PCB with just two wires, making the installation very simple. Wondering where the power comes from? As the rumble motor isn’t supported anyway, that gets tossed and in its places goes a 700 mAh battery which powers the controller for up to six hours. Overall it’s a very clean modification that [Nathan] believes even beginners will be capable of, and he ultimately plans to turn this design into a commercial kit.

Currently you still need a receiver if you want to use the BlueCubeMod with the Nintendo Switch, but [Nathan] says he’s working on a way to get around that requirement by potentially switching out the ESP32 for a STM32 with a CC256x radio. He says this will give him more direct control over the Bluetooth communications, which should allow him to take into tackle the intricacies of talking to the Switch directly.

Of course, the GameCube did have an official wireless controller back in the day. We’ve seen modifications to get the WaveBird to get it talking to modern systems as well, but there’s something to be said for slimmer form factor of the original edition.

Continue reading “ESP32 Adds Bluetooth To GameCube Controllers”

Ask Hackaday: Is USB Robust Enough?

Earlier this month a single person pleaded guilty to taking down some computer labs at a college in New York. This was not done by hacking into them remotely, but by plugging a USB Killer in one machine at a time. This malicious act caused around $58,000 in damage to 66 machines, using a device designed to overload the data pins on the USB ports with high-voltage. Similar damage could have been done with a ball-peen hammer (albeit much less discreetly), and we’re not here to debate the merits of the USB Killer devices. If you destroy property you don’t own you should be held accountable.

But the event did bring an interesting question to mind. How robust are USB ports? The USB Killer — which we’ve covered off and on through the years —  is billed as a “surge testing” device and operates by injecting -200 volts DC on the data lines of the USB connection. Many USB ports are not protected against this and the result is permanent damage to the computer hardware. Is protection for these levels of abuse necessary or would it needlessly add cost to our machines?

A chip like the TPD4S014 has ESD protection on the data lines that is rated up to +/- 1500 volts, clamping to ground to dissipate the energy. It’s a solution that should protect against repeated spikes on the data lines, as well as short circuits on the power lines and over/undervoltage situations.

ADUM4160 Functional Diagram

The ADuM4160 is an interesting step up from this. It’s designed to provide isolation between a USB host and the device connected to it. Rather than relying on clamping, this chip implements isolation through air core transformers. Certainly this would be overkill to install in every product, but for those of use building and testing USB devices this would save you from “Oops, wrong USB cable” moments at the work bench.

Speaking of accidents at the bench, there is certainly a demand for USB isolation outside of what’s built into our computers. Earlier this year we saw a fantastic take on a properly-designed USB power strip. Among the goals were current limiting, undervoltage protection, and a proper power disconnect switch for each port. The very need to design your own reminds us that consumer manufacturers are often lazy in their USB design. “Use a USB hub” is bad advice for protection at the workbench since quality of design varies so wildly.

We would be interested in hearing from anyone who has insight on standards applying to equipment continuing to survive over current or over voltage events and remain functional. There are standards like UL-60950 that should apply to USB. But that standard includes language about failing safe for the operator, not necessarily remaining functional:

After abnormal operation or a single fault (see 1.4.14), the equipment shall remain safe for an OPERATOR in the meaning of this standard, but it is not required that the equipment should still be in full working order. It is permitted to use fusible links, THERMAL CUT-OUTS, overcurrent  protection devices and the like to provide adequate protection.

So, we’re here to ask you, the readers of Hackaday. Are our USB devices robust enough? Do you have a go-to USB protection chip, part, or other circuit you like to use? Have you ever accidentally killed a USB host device (if so, how)? Do you have special equipment that you depend on when developing projects involving USB? Let us know what you think in the comments below.

AI At The Edge Hack Chat

Join us Wednesday at noon Pacific time for the AI at the Edge Hack Chat with John Welsh from NVIDIA!

Machine learning was once the business of big iron like IBM’s Watson or the nearly limitless computing power of the cloud. But the power in AI is moving away from data centers to the edge, where IoT devices are doing things once unheard of. Embedded systems capable of running modern AI workloads are now cheap enough for almost any hacker to afford, opening the door to applications and capabilities that were once only science fiction dreams.

John Welsh is a Developer Technology Engineer with NVIDIA, a leading company in the Edge computing space. He’ll be dropping by the Hack Chat to discuss NVIDIA’s Edge offerings, like the Jetson Nano we recently reviewed. Join us as we discuss NVIDIA’s complete Jetson embedded AI product line up, getting started with Edge AI, and where Edge AI is headed.

join-hack-chat

Our Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, May 1 at noon Pacific time. If time zones have got you down, we have a handy time zone converter.

Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.

Easter Egg Turns Nintendo Switch Into A Development Platform

Like a lot of game developers [Amir Rajan] likes to put Easter Eggs into his creations. His latest Nintendo Switch title, A Dark Room, has a very peculiar one, though. Instead of a graphic or a Tetris game, [Amir] put a code editor and a Ruby interpreter in the game.

Ruby is a language that originated in Japan and is popular with Web developers, in particular. It has dynamic typing, garbage collection, and supports several different programming styles. We aren’t sure what you’d do with it on a Nintendo Switch, but any time we can program a gadget, it makes us happy.

Continue reading “Easter Egg Turns Nintendo Switch Into A Development Platform”

Lockheed Wants To Build The Next Lunar Lander

The United States is going back to the moon, and it’s happening sooner than you would think. NASA is going back to the moon in 2024, and they might just have the support of Congress to do so.

Getting to the moon is one thing, and since SpaceX launched a car to the asteroid belt, this future of boots on the moon after Apollo seems closer than ever before. But what about landing on the moon? There’s only ever been one Lunar Lander that has taken people down to the moon and brought them back again, and it’s doubtful that design will be used again. Now, Lockheed has their own plan for landing people on the moon, and they might be able to do it by 2024.

Continue reading “Lockheed Wants To Build The Next Lunar Lander”

Bike Computer Exploration Uncovers A Hidden Android

As a happy side-effect of the smartphone revolution, the world is now awash with tiny computers that are incredibly cheap thanks to the nearly unfathomable volumes in which their components are manufactured. There wouldn’t be a $10 Raspberry Pi Zero if the billions of smartphones that were pumped out before it hadn’t dropped the cost of the individual components to literal pennies. That also means that smartphone hardware, or at least systems that are very close to it, have started to pop up in some unexpected places.

When [Joshua Wise] recently took ownership of a Wahoo ELEMNT BOLT bike computer, he wondered how it worked. With impressive list of features such as Internet connectivity, GPS mapping, and Bluetooth Low Energy support, he reasoned the pocket-sized device must have some pretty decent hardware under the hood. With some poking and prodding he found the device was powered by a MediaTek SoC and incredibly had a full-blown install of Android running in the background.

So how does one find out that their lowly bike computer is essentially a cleverly disguised smartphone? If you’re [Joshua], you listen to who it’s trying to talk do when doing a firmware update over the Internet. He used mitmproxy running between his Internet connection and a WiFi access point setup specifically for the BOLT, from there, he was able to see all of the servers it was connecting to. Seeing the device pull some data down from MediaTek’s servers was a pretty good indication of whose hardware was actually inside the thing, and when it ultimately downloaded some Android .apk files from the Wahoo website, it became pretty clear what operating system it was running underneath the customized user interface.

Further examination of the Bolt’s software brought to light a few troubling issues. It turned out that the firmware made extensive use of Apache-licensed code, for which no attribution was given. [Joshua] contacted the company and was eventually referred to the Wahoo’s CEO, Chip Hawkins. Refreshingly, Chip was not only very interested in getting the licensing issues sorted out, but even had some tips on hacking and modifying the device, including how to enable ADB.

Before the publication of this article, we reached out to Chip Hawkins (yes, he really does respond to emails) for a comment, and he told us that not only has he made sure that all of the open source packages used have now been properly attributed to their original authors, but that his team has been providing source code and information to those who request it. He says that he’s been proud to see owners of his products modifying them for their specific needs, and he’s happy to facilitate that in any way that he can.

Open source license compliance is a big deal in the hacking community, and we’ve seen how being on the wrong side of the GPL can lead to lost sales. It’s good to see Wahoo taking steps to make sure they comply with all applicable licences, but we’re even more impressed with their positive stance on customers exploring and modifying their products. If more companies took such an enlightened approach to hacking, we’d all be a lot better off.

[Thanks to Roman for the tip.]

Reverse Engineering An Insulin Pump With An SDR And Decapping

Insulin pumps are a medical device used by people with diabetes to automatically deliver a measured dose of insulin into their bloodstream. Traditionally they have involved a canula and separate connected pump, but more recent models have taken the form of a patch with a pump mounted directly upon it. When [Pete Schwamb]’s daughter received  one of these pumps, an Omnipod, he responded to a bounty offer for reverse engineering its RF protocol. As one of the people who helped create Loop, an app framework for controlling insulin delivery systems, he was in a particularly good position to do the work.

The reverse engineering itself started with the familiar tale of using an SDR to eavesdrop on the device’s 433MHz communication between pump and control device. Interrogating the raw data was straightforward enough, but making sense of it was not. There was a problem with the CRC algorithm used by the device which had a bug involving a bitwise shift in the wrong direction, then they hit a brick wall in the encryption of the data. Hardware investigation revealed a custom chip in the device, and there they might have stalled.

But the international reverse engineering community is not without resources and expertise, and through the incredible work of a university researcher in the UK (whose paper incidentally includes a pump teardown) they were able with an arduous process supported by many people to have the firmware recovered through decapping the chip. Even once they had thus extracted the encryption code and produced their own software their problems were not over, because communication issues necessitated a much better antenna on the RileyLink Bluetooth bridge boards that translated Bluetooth from a mobile phone to 433 MHz for the device.

This precis doesn’t fully encapsulate the immense amount of work over several years by a large group of people with some very specialist skills that reverse engineering the Omnipod represents. To succeed in this task is an incredible feat, and makes for a fascinating write-up.

Thanks [Alex] for the tip.