Hands-On With PineCube: An Open IP Camera Begging For Better Kernel Support

When the PineCube was announced by the Pine64 project in 2020, it created a fair bit of interest. Most of this was due to the appeal of a single-board computer (SBC) in a network-based (IP) camera form factor with integrated camera module, for a mere $29.99. Add an enclosure to it, and you would have a neat little package combining a 5 MP camera module with 100 Mbit Ethernet and WiFi. As a bonus, the system could be powered either via an optional battery pack as well as passive PoE, in addition to MicroUSB.

A few weeks ago I bought two of these boards, as part of a client project, and set out to use it for a custom IP camera implementation. With existing Linux-on-SBC and MIPI (CSI) camera experience on my end ranging from the Raspberry Pi to the Odroid, Orange Pi and Banana Pi boards, I felt fairly confident that I could make it work with minimal fuss.

Unfortunately, my experiences were anything but positive. After spending many hours with the PineCube, I’m not able to recommend it for those seeking an IP camera. There are many reasons for this, which I’ll try to explain in this article.

Continue reading “Hands-On With PineCube: An Open IP Camera Begging For Better Kernel Support”

Interesting Switch Autopsy

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 File Will Self-Destruct In 24 Hours

[menkveldj] built a service that encrypts files which self destruct in 24 hours. The download link can only be used once. If the wrong people were to get the link and download the file, they’d need many years on a pretty powerful computer to crack the 256AES encryption.

The sender shares a file that is encrypted client side using a password generated Pbkdf2 key to encrypt the data before uploading it to the s3 storage service. The sender is then provided the one-time-use link to share with the recipient. After the first download, or 24 hours, the link and the encrypted file are both deleted. The receiver must enter the same password to decrypt and recover the file. No one but the sharer and receiver know what the actual file is.

It’s still work in progress, so chime in with your comments and suggestions. To dig into the code, check out his repository on Github, which also has instructions to build and run it if you’d like to do your own version.

Oh, and you’ll like this. If want to thumb your nose at the powers that be, the site has a redirect for the whimsical domain: NSAfu.com.

Galaxy SIII Hack Puts Android In Your Dashboard

Here’s how you can have a hands-free, no worries about the battery, Android experience while you drive. [Steve] removed the head unit from his car and replaced it with a Samsung Galaxy SIII Android phone. The look is pretty nice, but we do have a few suggested improvements if you try this one for yourself.

It started simply by removing the factory stereo which left a double-height opening in the dashboard. [Steve] cut a piece of wood to fit the gaping hole, painting it a grey that would compliment the interior colors of the car. The phone is mounted on this plate, with plenty of room for the USB and audio cables. From there it is finished up with another wooden plate which has a cutout for the touch screen. See the final project, as well as glimpses of the installation, in the video after the break.

[Steve] demonstrates using the GPS features and playing music. We’d improve this in a couple of ways. First off, using something like the IOIO board you could add a physical volume knob, which we’re not interested in giving up for a touch screen quite yet. If you were willing to go the extra mile, a CAN-BUS chip could be added too that would monitor button presses from the steering wheel music controls.

Continue reading “Galaxy SIII Hack Puts Android In Your Dashboard”

Hackit: Network Attached Storage?


With each passing day the rate we acquire digital media increases (we don’t even bother unpacking our CDs when we move anymore). Large publishers have started moving away from DRM, which means we’ll be buying even more digital media in the future. Acquiring all of this nonphysical property puts importance on not just making it easily accessible, but also protecting it from destruction. Slashdot asked for reader suggestions of what NAS to buy; we’ve compiled some of the options below and want to know what you use.

Continue reading “Hackit: Network Attached Storage?”