Unless you’ve been living under a high voltage transformer, you’ve heard about the potential for Samsung’s latest phone, the Note7, to turn into a little pocket grenade without warning. With over 2.5 million devices in existence, it’s creating quite a headache for the company and its consumers.
They quickly tied the problem to faulty Li-ion batteries and started replacing them, while issuing a firmware update to stop charging at 60 percent capacity. But after 5 of the replacement phones caught fire, Samsung killed the Note7 completely. There is now a Total Recall on all Note7 phones and they are no longer for sale. If you have one, you are to turn it off immediately. And don’t even think about strapping it into a VR headset — Oculus no longer supports it. If needed, Samsung will even send you a fireproof box and safety gloves to return it.
It should be noted that the problem only affects 0.01% of the phones out there, so they’re not exactly going to set the world on fire. However, it has generated yet another discussion about the safety of Li-ion battery technology.
It was just a few months ago we all heard about those hoverboards that would catch fire. Those questionably-engineered (and poorly-named) toys used Li-ion batteries as well, and they were the source of the fire problem. In the wake of this you would think all companies manufacturing products with Li-ion batteries in them would be extra careful. And Samsung is no upstart in the electronics industry — this should be a solved problem for them.
Why has this happened? What is the deal with Li-ion batteries? Join me after the break to answer these questions.
[Marcel] was trying to shoehorn a few new parts into his trusty Nexus 5 phone. If you’ve ever opened one of these little marvels up, you know that there’s not much room under the hood to work with. Pulling out some unnecessary parts (like the headphone jack) buys some space, but then how to wire it all up?
[Marcel] needed a multi-wire connector that’s as thin as possible, but he wasn’t going to go the order-Kapton-flex route. Oh no! He built one himself from masking tape and the strands from a stranded wire. Watch the video how-to if that alone isn’t enough instruction.
An IMSI catcher is an illicit mobile phone base station designed to intercept the traffic from nearby mobile phones by persuading them to connect to it rather than the real phone company tower. The IMSI in the name stands for International Mobile Subscriber Identity, a unique global identifier that all mobile phones have. IMSI catchers are typically used by government agencies to detect and track people at particular locations, and are thus the subject of some controversy.
As is so often the case when a piece of surveillance technology is used in a controversial manner there is a counter-effort against it. The IMSI catchers have spawned the subject of this post, an IMSI catcher detector app for Android. It’s a work-in-progress at the moment with code posted in its GitHub repository, but it is still an interesting look into this rather shadowy world.
How them you might ask, does this app hope to detect the fake base stations? In the first case, it will check the identity of the station it is connected to against a database of known cell towers. Then it will try to identify any unusual behaviour from the base station by analysing its traffic and signal strength. Finally it will endeavour to spot anomalies in the implementation of the cell phone protocols that might differentiate the fake from the real tower.
They have made some progress but stress that the app is in alpha stage at the moment, and needs a lot more work. They’re thus inviting Android developers to join the project. Still, working on projects is what the Hackaday Prize is all about.
Back in the day, when wardriving was still useful (read: before WPA2 was widespread), we used to wander around with a Zaurus in our pocket running Kismet. Today, every cellphone has WiFi and a significantly more powerful processor inside. But alas, the firmware is locked down.
Enter the NexMon project. If you’ve got a Nexus 5 phone with the Broadcom BCM4339 WiFi chipset, you’ve now got a monitor-mode, packet-injecting workhorse in your pocket, and it looks a lot less creepy than that old Zaurus. But more to the point, NexMon is open. If you’d like to get inside what it took to reverse-engineer a hole into the phone’s WiFi, or make your own patches, here’s a great starting place.
But wait, there’s more! The recently released Raspberry Pi 3 has a similar Broadcom WiFi chipset, and has been given the same treatment, turning your RPi 3 into a wireless-sniffing powerhouse. How many Raspberry Pi “hacks” actually hack the Raspberry Pi? Well, here’s one.
The NexMon project is a standout, however. Not only do they reverse the WiFi firmware in the Nexus 5, but they show you how, and then apply the same methods to the RPi3. Kudos times three to [Matthias Schulz], [Daniel Wegemer], and [Matthias Hollick]!
We put a lot of trust into some amazingly cheap components, sometimes that trust is very undeserved. Long gone are the days when every electronic component was a beautifully constructed precision lab instrument. As [Rupert Hirst] shows, this can be a hard lesson to learn for even the biggest companies.
[Rupert]’s Nexus 5 was suffering from a well known reboot issue. He traced it to the phone’s power switch. It was always shorting to ground, even though it clicked like it was supposed to.
He desoldered the switch and pried the delicate sheet metal casing apart. Inside were four components. A soft membrane with a hard nub on the bottom, presumably engineered to give the switch that quality feeling. Next were two metal buckles that produced the click and made contact with the circuit board, which is the final component.
He noticed something odd and busted out his USB microscope. The company had placed a blob of solder on the bottom buckle. We think this is because steel on copper contact would lead to premature failure of the substrate, especially with the high impact involved during each switching event.
The fault lay in the imprecise placement of the solder blob. If it had been perfectly in the middle, and likely many phones that never showed the issue had it there, the issue would have never shown up. Since it was off-center, the impact of each switching event slowly deposited thin layers of solder onto the copper and fiberglass. Finally it built up enough to completely short the switch.
Interestingly, this exact problem shows up across different phone manufacturers, somewhere there’s a switch company with a killer sales team out there.
This scene replays quite often in our house: my wife has misplaced her cell phone so she asks me to call her. But where did I leave my cell phone? And the race is on! Who will find their phone first to call the other?
[Zapta] solves this problem with his Phone Finder. The system comes in two parts: a base station with WiFi that’s also connected to the house’s phone line, and an arbitrary number of Amazon Dash buttons that trigger dialing commands.
[Zapta] presses a Dash button, which connects over WiFi to the base station. The base station recognizes the MAC address of the button, looks up and dials the corresponding missing cell phone. This solves the need-a-phone-to-find-a-phone problem very neatly, and since Dash buttons are dirt cheap they can be scattered liberally around the house. They’re clearly marked “his” and “hers” suggesting a similar domestic dynamic.
If we were implementing the base station from scratch, we’d probably try to figure out how a single ESP8266 could do all of the heavy lifting, but browsing through [Zapta]’s GitHub and the included circuit diagram (PDF) demystifies the phone-line interface.
In the early days of cordless phones, we used to joke that a solution to losing them would be to attach a string and tie them to the wall. (Luddites!) We’re glad to see [Zapta] take this project in the opposite direction — using technological overkill to solve the unintended problems that arise from technological progress.
In the surest sign that hardware hacking is the new hotness, Motorola and Farnell/Element 14 have developed an add-on board and SDK that will let you connect virtually anything to your mobile phone. Motorola is calling it the “Moto Mods” system, and it looks like its going to be a dedicated microcontroller that interfaces with the computer inside the phone and provides everything from GPIOs to DSI (video). Naturally, I2C, I2S, SPI, UART, even two flavors of USB are in the mix.
The official SDK, ahem Mods Development Kit (MDK), is based on the open Greybus protocol stack (part of Google’s Project Ara open phone project) and it’s running on an ARM Cortex-M4F chip. It’s likely to be itself fairly hackable, and even if the suggested US $125 price is probably worth it for the convenience, we suspect that it’ll be replicable with just a few dollars in parts and the right firmware. (Yes, that’s a challenge.)
The initial four adapter boards range from a simple breadboard to a Raspberry-Pi-hat adapter (hence the title). It’s no secret that cell phones now rival the supercomputers of a bygone era, but they’ve always lacked peripheral interfaces. We wish that all of the old smartphones in our junk box had similar capabilities. What do you say? What would you build with a cellphone if you could break out all sorts of useful comms?