A desire for automated PCB inspection has led [charliex] down some deep rabbit holes. He’s written his own inspection software, he’s mounted his PCB vise on a stepper-controlled table, and now he’s hacked his digital microscope camera to allow remote and automated control.
Eakins cameras have become a relatively popular, relatively inexpensive choice for electronics hobbyists to inspect their small-scale work. The cameras have a USB port for a mouse and overlay a GUI on the HDMI output for controlling the camera’s various settings and capturing images to the SD card. Using the mouse-based GUI can feel clunky, though, so users have already endeavored to streamline the process to fit better in their workflow. [charliex] decided to take streamlining a few steps further.
One issue in microscope photography is that microscopes have an extremely tight focus plane. So, even at the minuscule scales of an SMD circuit board, the components are simply too tall. Only a sub-millimeter-thick layer can be in focus at a time. If you take just a single image, much of what you want to see will be lost in the blurry distance. Focus stacking solves this problem by taking multiple pictures with the focus set at different depths then combining their focused bits into a single sharp image.
This takes care of the focus issue, but even the most streamlined and intuitive manual controls become tedious given the multitude of pictures required. So [charliex] searched for a way to remotely control his camera, automating focus stacking and possibly even full PCB scans.
Continue reading “Hacking A Digital Microscope Camera For Fun And Automated PCB Inspection”
As open as the Raspberry Pi Foundation has been about their beloved products, they would be the first to admit there’s always more work to be done: Getting a Pi up and running still requires many closed proprietary components. But the foundation works to chip away at it bit by bit, and one of the latest steps is the release of a camera stack built on libcamera.
Most Linux applications interact with the camera via V4L2 or a similar API. These established interfaces were designed back when camera control was limited and consisted of a few simple hardware settings. Today we have far more sophisticated computational techniques for digital photography and video. Algorithms have outgrown dedicated hardware, transforming into software modules that take advantage of CPU and/or GPU processing. In practice, this trend meant bigger and bigger opaque monolithic pieces of proprietary code. Every one a mix of “secret sauce” algorithms commingling with common overhead code wastefully duplicated for each new blob.
We expect camera makers will continue to devise proprietary specialties as they seek a competitive advantage. Fortunately, some of them see benefit in an open-source framework to help break up those monoliths into more manageable pieces, letting them focus on just their own specialized parts. Leveraging something like libcamera for the remainder can reduce their software development workload, leading to faster time to market, lower support cost, and associated benefits to the bottom line that motivates adoption by corporations.
But like every new interface design borne of a grandiose vision, there’s a chicken-and-egg problem. Application developers won’t consume it if there’s no hardware, and hardware manufacturers won’t implement it if no applications use it. For the consumer side, libcamera has modules to interop with V4L2 and other popular interfaces. For the hardware side, it would be useful to have a company with wide reach who believes it is useful to open what they can and isolate the pieces they can’t. This is where the Raspberry Pi foundation found a fit.
The initial release doesn’t support their new High-Quality Camera Module though that is promised soon. In the short term, there is still a lot of work to be done, but we are excited about the long term possibilities. If libcamera can indeed lower the barrier to entry, it would encourage innovation and expanding the set of cameras beyond the officially supported list. We certainly have no shortage of offbeat camera sensor ideas around here, from a 1-kilopixel camera sensor to a decapped DRAM chip.
[Ge0rg] got himself a fancy new Samsung NX300 mirrorless camera. Many of us would just take some pretty pictures, but not [Ge0rg], he wanted to see what made his camera tick. Instead of busting out the screwdrivers, he started by testing his camera’s security features.
The NX300 is sold as a “smart camera” with NFC and WiFi connectivity. The NFC connectivity turns out to be just an NXP NTAG203 tag embedded somewhere in the camera. This is similar to the NFC tags we gave away at The Gathering in LA. The tag is designed to launch an android app on a well equipped smartphone. The tag can be write-locked, but Samsung didn’t set the lock bit. This means you can reprogram and permanently lock the tag as a link to your favorite website.
[Ge0rg] moved on to the main event, the NX300’s WiFi interface. A port scan revealed the camera is running an unprotected X server and Enlightenment. Let that sink in for a second. The open X server means that an attacker can spoof keystrokes, push images, and point applications to the camera’s screen.
In a second blog post, [Ge0rg] tackled attaining root access on the camera. Based on the information he had already uncovered, [Ge0rg] knew the camera was running Linux. Visiting Samsung’s open source software center to download the open source portions of the NX300 confirmed that. After quite a bit of digging and several red herrings, [Ge0rg] found what he was looking for. The camera would always attempt to run an autoexec.sh from the SD Card’s root folder at boot. [Ge0rg] gave the camera the script it was looking for, and populated it with commands to run BusyBox’s telnet daemon. That’s all it took – root shell access was his.
[Image via Wikimedia Commons/Danrok]
Network engineer [Mario Giambanco] recently purchased a cable to move his flash off camera. Unfortunately, it ended up way too short for his purposes. Instead of purchasing a slightly longer proprietary cable, he decided to employ what he had around him: a lot of cat5e cable and ethernet jacks. He cut the cable close to the center in case things didn’t work out and he’d need to repair it. His post on building the custom ethernet flash extension cable goes into heavy detail to make sure you get it right the first time. He’s tested it using both five and 50 foot pieces of cable with no apparent lag.
This isn’t the first time we’ve seen cat5 repurposed: composite video through cat5, vga cat5 extension, and cat5 speaker cables.