smartphone

Modern smartphones are highly integrated devices, bringing immense computing power into the palm of one’s hand. This portable computing power and connectivity has both changed society in innumerable ways, and also tends to lead to said powerful computers ending up dropped on the ground or into toilets. Repairs are often limited to screen replacement or exchanging broken modules, but it’s possible to go much further.

The phone is an iPhone 7, which a service center reported had issues with the CPU, and the only fix was a full mainboard replacement. [The Kardi Lab] weren’t fussed, however, and got to work. The mainboard is installed in a CNC fixture, and the A10 CPU is delicately milled away, layer by layer. A scalpel and hot air gun are then used for some further cleanup of the solder pads. Some conductivity testing to various pads is then carried out, for reasons that aren’t entirely clear.

At this point, a spare A10 CPU is sourced, and a stencil is used to apply solder paste or balls – it is not immediately obvious which. The new chip is then reflowed on to the mainboard, and the phone reassembled. The device is then powered on and shown to be functional.

It’s an impressive repair, and shows that modern electronics isn’t so impossible to fix – as long as you have the right tools to hand. The smart thing is, by using the CNC machine with a pre-baked program, it greatly reduces the labor required in the removal stage, making the repair much more cost-effective. The team are particularly helpful, linking to the tools used to pull off the repair in the video description. We’ve seen similar hacks, too – such as upgrading an iPhone’s memory. Video after the break.

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.

[Mark Rober] was fed up with packages going missing. He kept receiving notifications that his shipments had been delivered, but when checking his porch he found nothing there. Reviewing the CCTV footage revealed random passers-by sidling up to his porch and stealing his parcels. It was time to strike back. Over six months, [Mark] and his friends painstakingly designed, prototyped and iterated the perfect trap for package thieves, resulting in a small unit disguised as an Apple HomePod. The whole scheme is wonderfully over-engineered and we love it.

The main feature of the device is a spinning cup on the top which contains a large amount of glitter. When activated, it ejects glitter in every directions. You could say it’s harmless, as it’s just glitter. But then again, glitter has a way of staying with you for the rest of your life — turning up at the least expected times. It certainly leaves an emotional impression.

Activation is quite clever; the fake package sits on the porch until an accelerometer detects movement. At that point, GPS checks to see if the package has traveled outside a geo-fence around [Mark]’s house. A signal is then sent to the four smartphones to start recording — yes, that’s right, there are 4 phones inside, one on each side to capture the reaction of the thief.

How can [Mark] be so confident that he’ll be able to recover the four phones and their footage? That’s answered by GPS tracking and a can of fart spray actuated by a 3D printed cam and DC motor, ensuring the thief won’t want this package around for long. This actuator and the glitter motor are controlled by a custom PCB, which also triggers the phones to start recording through their headphone jacks and detects the opening of the package with some microswitches. This is truly a masterpiece that outsmarts the package thieves in a way that leaves an impression while still being playful.

(Editor’s Note 2: On 12/20/18 it was announced that two of the five thieves shown in the originally video were staged, apparently without [Mark Rober’s] knowledge. Here is his statement on the matter.)

The hottest new trend in photography is manipulating Depth of Field, or DOF. It’s how you get those wonderful portraits with the subject in focus and the background ever so artfully blurred out. In years past, it was achieved with intelligent use of lenses and settings on an SLR film camera, but now, it’s all in the software.

The franken-camera rig, consisting of five Pixel 3 smartphones. The cameras are synchronised over WiFi.

For the Pixel 2 smartphone, Google had used some tricky phase-detection autofocus (PDAF) tricks to compute depth data in images, and used this to decide which parts of images to blur. Distant areas would be blurred more, while the subject in the foreground would be left sharp.

This was good, but for the Pixel 3, further development was in order. A 3D-printed phone case was developed to hold five phones in one giant brick. The idea was to take five photos of the same scene at the same time, from slightly different perspectives. This was then used to generate depth data which was fed into a neural network. This neural network was trained on how the individual photos relate to the real-world depth of the scene.

With a trained neural network, this could then be used to generate more realistic depth data from photos taken with a single camera. Now, machine learning is being used to help your phone decide which parts of an image to blur to make your beautiful subjects pop out from the background.

It’s hard to believe, but the Raspberry Pi has now been around long enough that some of the earliest Pi projects could nearly be considered bonafide vintage hacks at this point. A perfect example are some of the DIY Raspberry Pi smartphone projects that sprung up a few years back. Few of them were terribly practical to begin with, but even if you ignore the performance issues and bulkiness, the bigger problem is they relied on software and cellular hardware that simply isn’t going to cut it today.

Which was exactly the problem [Dylan Radcliffe] ran into when he wanted to create his own Pi smartphone. There was prior art to use as a guide, but the ones he found were limited to 2G cellular networks which no longer exist in his corner of the globe. He’s now taken on the quest to develop his own 3G-capable Pi smartphone, and his early results are looking very promising.

Inside the phone, which he calls the rCrumbl, [Dylan] has crammed a considerable amount of hardware. A Raspberry Pi 3B+ with attached Adafruit touchscreen LCD is the star of the show, but there’s also a Pi camera module, battery charging circuit, and Adafruit FONA 3G modem (which also provides GPS). Powering the device is a 2500 mAh 3.7V battery, which reportedly delivers a respectable 8 to 12 hour runtime.

The case is 3D printed, and [Dylan] says it took a long time to nail down a design that would fit all of his hardware, keep things from shifting around, and still be reasonably slim. Obviously DIY phones like this are never going to be as slim as even the chunkiest of modern smartphones, but the rCrumbl looks fairly reasonable for a portable device. We especially like the row of physical buttons he’s included along the bottom of the screen, which should help with the device’s usability.

Speaking of usability, that’s where [Dylan] still has his work cut out for him. The existing software he’s found won’t work on 3G, so he’s going to have to come up with his own software stack to provide a proper phone interface. As it stands he’s made a call on the rCrumbl using command line tools, but while that might score you some extra geek points at the next hacker meetup, it’s not exactly going to fly for daily use. He mentions he would love to talk to any developers out there that would like to team up on the software side of the project.

When a project has outgrown using a small microcontroller, almost everyone reaches for a single-board computer — with the Raspberry Pi being the poster child. But doing so leaves you stuck with essentially a headless Linux server: a brain in a jar when what you want is a Swiss Army knife.

It would be a lot more fun if it had a screen attached, and of course the market is filled with options on that front. Then there’s the issue of designing a human interface: touch screens are all the rage these days, so why not buy a screen with a touch interface too? Audio in and out would be great, as would other random peripherals like accelerometers, WiFi, and maybe even a cellular radio when out of WiFi range. Maybe Bluetooth? Oh heck, let’s throw in a video camera and high-powered LED just for fun. Sounds like a Raspberry Pi killer!

And this development platform should be cheap, or better yet, free. Free like any one of the old cell phones that sit piled up in my “hack me” box in the closet, instead of getting put to work in projects. While I cobble together projects out of Pi Zeros and lame TFT LCD screens, the advanced functionality of these phones sits gathering dust. And I’m not alone.

Why is this? Why don’t we see a lot more projects based around the use of old cellphones? They’re abundant, cheap, feature-rich, and powerful. For me, there’s two giant hurdles to overcome: the hardware and the software. I’m going to run down what I see as the problems with using cell phones as hacker tools, but I’d love to be proven wrong. Hence the “Ask Hackaday”: why don’t we see more projects that re-use smartphones?

When Mr. Spock beams down to a planet, he’s carrying a tricorder, a communicator, and a phaser. We just have our cell phones. The University of California Santa Barbara published a paper showing how an inexpensive kit can allow your cell phone to identify pathogens in about an hour. That’s quite a feat compared to the 18-28 hours required by traditional methods. The kit can be produced for under $100, according to the University.

Identifying bacteria type is crucial to prescribing the right antibiotic, although your family doctor probably just guesses because of the amount of time it takes to get an identification through a culture. The system works by taking some — ahem — body fluid and breaking it down using some simple chemicals. Another batch of chemicals known as a LAMP reaction mixture multiplies DNA and will cause fluorescence in the case of a positive result.