Apple has for a very long time been a company that ploughs its own furrow when it comes to peripherals, with expensive proprietary hardware being the order of the day over successive generations of its products. One of its current line of proprietary interfaces is the Lightning connector, best thought of as an Apple-only take on the same ideas that the rest of the world knows as USB-C. There are a whole host of white dangly peripherals that can be hung from your iDevice’s Lightning port, including a pair of display adaptors that allow them to drive an HDMI or VGA monitor. [Lisa Braun] has subjected one that had failed to a teardown, and her analysis gives some insight into the way Apple creates its peripherals.
Where you might expect these to contain mostly the equivalent of a graphics card, in fact they have a fully-fledged SoC of their own that runs its own OS with the same Darwin kernel as its host. Unexpectedly this is not held upon the adapter itself, instead it is shipped with iOS and loaded dynamically. Thus the file containing it can be retrieved from iOS and unpacked, leading to some interesting analysis. In a fascinating twist for those of us unused to Lightning’s internals, it’s revealed that the device can be driven from a USB port with the appropriate cobbled-together adapter, allowing a full-size MacOS device to interrogate it. This many not be news to readers with a long memory though, we’ve told you in the past about reverse engineering the Lightning connector.
The origin story of software takes us back past punch card computers and Babbage’s Difference Engine to a French weaver called Joseph Marie Jacquard. Jacquard created a way to automate mechanical looms, giving weavers the ability to change a loom’s pattern by simply switching punch cards. This invention not only made it possible to produce detailed fabrics in a vastly simplified way, it was an extremely important conceptual step in the development of computer programming, influencing Babbage’s development of the Analytical Engine amongst many other things.
So, when [Kurt] saw his son’s enthusiasm for weaving on a simple loom, he started thinking about how he could pay homage to the roots of software by designing and building an open source computer controlled loom. He knew this was going to be difficult: looms are complex machines with hundreds of small parts. [Kurt] wrestled with wonky carriage movements, cam jams, hook size disasters and plenty of magic smoke from motor control boards. After a year and a half of loom hacking he succeeded in making a 60 thread computer controlled loom, driven by an iPhone app using Bluetooth.
As well as writing up the story of this build on his blog, linked above, [Kurt] has also has made all of his design files, PCB layouts, firmware and code available on GitLab.
While earlier smartphones seemed to manage well enough with individual applications that only weighed in at a few megabytes, a perusal of the modern smartphone software store uncovers some positively monstrous file sizes. The fact that we’ve become accustomed to mobile applications requiring 100+ MB downloads on what’s often a metered Internet connection in only a few short years is pretty crazy if you stop to think about it.
Seeing reports that the Nest app for iOS tipped the scales at nearly 250 MB, [Alexandre Colucci] decided to investigate. On his blog he not only documents the process of taking the application apart piece by piece to find out just what’s eating up all that space, but lists some potential fixes which could shave a bit off the top. Even if you aren’t planning a spelunking expedition into your pocket supercomputer’s particular variant of the Netflix app, the methodology and tools he uses here are fascinating in their own right and might be something worth adding to your software bag of tricks.
By passing the application’s files through a disk usage visualizer called GrandPerspective, [Alexandre] immediately identified some rather large blocks of content. The bundled Apple Watch version of the app takes up 23 MB, video and audio used to walk the user through the device setup weigh in at 22 MB, and localization files for various languages consumes a surprising 33 MB. But the biggest single contributor to the application’s heft is the assorted libraries and frameworks which total up to an incredible 67 MB.
Of course the question is, how much of it is really necessary? It’s hard to be sure from an outsider’s perspective, but [Alexandre] notes that a few of the libraries used seem to be redundant or obsolete. In some cases this could be the result of old code still lurking in the project, but the four different libraries used for user tracking probably aren’t in there by accident. It also stands to reason that the instructional videos could be offloaded to something like YouTube, so that only users who need to view them have to expend their bandwidth on it.
Getting a little deeper into things, [Alexandre] notes that some of the localization images appear to be redundant. As a specific example, he points to the images of the Nest itself displaying Fahrenheit and Celsius temperatures. While logically this should only be two image files, there are actually eight copies of the Celsius image, each filed away as language-specific. These redundant localization images could easily be stripped out, but with gains measured in only a few hundred kilobytes, it probably wasn’t considered worth the effort during development.
In the end there’s really not as much bloat as we might like to believe. There were some redundant files, maybe a few questionable library inclusions, and the Apple Watch version of the app could surely be separated out. All together, it might get you a savings of 30 – 40%, but still not enough to bring it down under 100 MB.
Why in the world does helium kill iPhones and other members of the Apple ecosystem? Enquiring minds want to know, and [Ben Krasnow] has obliged with an investigation of the culprit: the MEMS oscillator. (YouTube, embedded below.)
When we first heard about this, courtesy in part via a Hackaday post on MRI-killed iPhones, we couldn’t imagine how poisoning a micro-electromechanical system (MEMS) part could kill a phone. We’d always associated MEMS with accelerometers and gyros, important sensors in the smartphone suite, but hardly essential. It turns out there’s another MEMS component in many Apple products: an SiT 1532 oscillator, a tiny replacement for quartz crystal oscillators.
[Ben] got a few from DigiKey and put them through some tests in a DIY gas chamber. He found that a partial pressure of helium as low as 2 kPa, or just 2% of atmospheric pressure, can kill the oscillator. To understand why, and because [Ben] has a scanning electron microscope, he lapped down some spare MEMS oscillators to expose their intricate innards. His SEM images are stunning but perplexing, raising questions about how such things could be made which he also addresses.
The bottom line: helium poisons MEMS oscillators in low enough concentrations that the original MRI story is plausible. As a bonus, we now understand MEMS devices a bit better, and have one more reason never to own an iPhone.
Sometimes hacking isn’t as much about building something, it’s about getting to the root of a particularly difficult problem. [Erik Wooldrige] was facing a problem like that. He’s a system specialist at a hospital near Chicago. Suddenly a bunch of iPhones and Apple watches were failing or glitching. The only thing anyone could think of was the recent install of an MRI machine.
Sure, an MRI machine can put out some serious electromagnetic pulses, but why would that only affect Apple products? Everything else in the hospital, including Android phones, seemed to be OK. But about 40 Apple devices were either dead or misbehaving.
It took some detective work, but they think they know what was the cause. The MRI machine uses liquid helium to cool its powerful magnets. Turns out the helium had leaked and over 5 hours about 120 liters of liquid helium vented into the air. Helium is notoriously hard to contain because, like hydrogen, it is a tiny little atom even by atomic standards. It also expands about 750 times when it turns into a gas, according to the post’s analysis.
Gathering more data, they found that many of the phones would eventually recover and that all the devices were at least an iPhone 6 or an Apple Watch. So even older iPhones seemed to be immune. Some speculated that the helium is small enough to get into the MEMS devices like the accelerometer or gyroscope that is in most modern phones and affect its operation. But why would that effectively brick phones? And why wouldn’t that affect most phones Android or otherwise?
The best theory — and it seems plausible to us — is that Apple stopped using quartz crystals for the phone’s internal clocks. Instead, they are using MEMS oscillators from a company called SiTime. Supposedly the MEMS oscillators are smaller and work better at temperature extremes. If the mechanical clock element got gummed up with helium, that would explain all the observed evidence.
[Erik Wooldrige] reading about the issue on Reddit, did an experiment where he subjected an iPhone to helium in a plastic bag. Granted, this is a lot more concentration of helium than the hospital probably got. but they also had five hours of exposure. In the video, below, you can see Erik’s phone stopped keeping time just after the three-minute mark on the video, eight and a half minutes of exposure.
It turns out if you read the iPhone user’s guide it reportedly says:
“Exposing iPhone to environments having high concentrations of industrial chemicals, including near evaporating liquified gasses such as helium, may damage or impair iPhone functionality. … If your device has been affected and shows signs of not powering on, the device can typically be recovered. Leave the unit unconnected from a charging cable and let it air out for approximately one week. The helium must fully dissipate from the device, and the device battery should fully discharge in the process. After a week, plug your device directly into a power adapter and let it charge for up to one hour. Then the device can be turned on again.”
Apparently, SiTime also is aware of this problem and says its newer devices are “impervious to all small-molecule gasses.” But they admit older parts were not immune.
Unless you spend a lot of time blowing up balloon animals, this probably won’t affect you. Still, we thought it was an interesting piece of detective work and one of those things that you might remember in a few years when you have some wacky failure in your blimp fleet. Of course, we were supposed to be running out of helium, so if that were true, this problem would eventually take care of itself.
Part of the joy of hacking is the joy of discovery, of seeing how things go right as well as wrong. That’s one cool thing about this iPad Mini 2 case build by [Eric Strebel]: in the video, he details the things that went wrong as well as those that went right. For instance, he used glue on one version that melted the foam core he built the iPad holder from. The end product is wonderful, though. It combines an iPad Mini 2 case and a spiral-bound notebook so you can use both digital and paper mediums, with the iPad cleverly hidden behind a panel that both protects it and turns the screen off when not in use.
The case is made from a Pentalic 7 x 10 wire-bound sketchbook, with some of the pages removed. These are replaced by an iPad holder made from foam core and matte board, which should protect the iPad from drops and knocks. A notch at the bottom allows for a charging cable, and an additional notch at the top lets you lift out the iPad if needed.
It’s a great, clean build that looks as good as a commercial case, and is more practical. I love the idea of combining an iPad with a sketchbook with removable paper pages: sometimes, you just need that feel of pen or pencil on paper to work. My only suggestion for improvement might be a couple more indentations at the bottom of the iPad holder to allow the sound to escape from the speakers a little better.
We could watch cellphone teardown videos all day long. There’s something pleasing about seeing how everything is packed into such a small enclosure. From the connectors, to that insidious glue, to the minuscule screws, [Scotty Allen] has a real knack for giving us a great look at the teardown process. Take a look at his latest video which attempts to add wireless charging to an iPhone. I think there’s a lot to be said for superb lighting and a formidable camera, but part of this is framing the shots just right.
Now of course we’ve taken apart our fair share of phones and there’s always that queasy “I think I’m going to break something” feeling while doing it. It’s reassuring that [Scotty] isn’t able to do things perfectly either (although he has the benefit of walking the markets for quick replacement parts). This video is a pretty honest recounting of many things going wrong.
The iPhone 6 and 7 are not meant to have wireless charging, but [Scotty’s] working with a friend named [Yeke] who created an aftermarket kit for this. The flexible PCB needs to be folded just right, and adhesive foam added (along with a magical incantation) to make it work. That’s because the add-on is a no-solder job. Above you can see it cleverly encircles one of the mating connectors and relies on mechanical pressure to make contact with the legs of that connector. Neat!
In the second half of the video [Scotty] meets up with [Yeke] to discuss the design itself. We find it interesting that [Yeke] considers his work a DIY item. Perhaps it’s merely lost in translation, but perhaps [Yeke’s] proximity to multiple flexible PCB manufacturers makes him feel that this is more like playing around for fun than product design. Any way you look at it, the ability to design something that will fit inside that crazy-tight iPhone case is both impressive and mesmerizing. Having seen some of the inductive charging hacks over the years, this is by far the cleanest way to go about it.
