Exposed inner copper on multilayer PCB. (Credit: mikeselectricstuff, YouTube)

LACED: Peeling Back PCB Layers With Chemical Etching And A Laser

Once a printed circuit board (PCB) has been assembled it’s rather hard to look inside of it, which can be problematic when you have e.g. a multilayer PCB of an (old) system that you really would like to dissect to take a look at the copper layers and other details that may be hidden inside, such as Easter eggs on inner layers. [Lorentio Brodeso]’s ‘LACED’ project offers one such method, using both chemical etching and a 5 Watt diode engraving laser to remove the soldermask, copper and FR4 fiberglass layers.

This project uses sodium hydroxide (NaOH) to dissolve the solder mask, followed by hydrogen chloride (HCl) and hydrogen peroxide (H2O2) to dissolve the copper in each layer. The engraving laser is used for the removing of the FR4 material. Despite the ‘LACED’ acronym standing for Laser-Controlled Etching and Delayering, the chemical method(s) and laser steps are performed independently from each other.

This makes it in a way a variation on the more traditional CNC-based method, as demonstrated by [mikeselectricstuff] (as shown in the top image) back in 2016, alongside the detailed setup video of how a multi-layer PCB was peeled back with enough resolution to make out each successive copper and fiberglass layer.

Continue reading “LACED: Peeling Back PCB Layers With Chemical Etching And A Laser”

Turning A Chromebox Into A Proper Power-Efficient PC

Google’s ChromeOS and associated hardware get a lot of praise for being easy to manage and for providing affordable hardware for school and other educational settings. It’s also undeniable that their locked-down nature forms a major obstacle and provides limited reusability.

That is unless you don’t mind doing a bit of hacking. The Intel Core i3-8130U based Acer CXI3 Chromebox that the [Hardware Haven] YouTube channel got their mittens on is a perfect example.

The Acer CXI3 in all its 8th-gen Intel Core i3 glory. (Credit: Hardware Haven, YouTube)
The Acer CXI3 in all its 8th-gen Intel Core i3 glory. (Credit: Hardware Haven, YouTube)

This is a nice mini PC, with modular SODIMM RAM, an NVMe storage M.2 slot as well as a slot for the WiFi card (or SATA adapter). After resetting the Chromebox to its default configuration and wiping the previous user, it ran at just a few watts idle at the desktop. As this is just a standard x86_64 PC, the only thing holding it back from booting non-ChromeOS software is the BIOS, which is where [MrChromebox]‘s exceedingly useful replacement BIOSes for supported systems come into play, with easy to follow instructions.

Reflashing the Acer CXI3 unit was as easy as removing the write-protect screw from the mainboard, running the Firmware Utility Script from a VT2 terminal (Ctrl+Alt+F2 on boot and chronos as login) and flashing either the RW_LEGACY or UEFI ROM depending on what is supported and desired. This particular Chromebox got the full UEFI treatment, and after upgrading the NVMe SSD, Debian-based Proxmox installed without a hitch. Interestingly, idle power dropped from 2.6 watts under ChromeOS to 1.6 watts under Proxmox.

If you have a Chromebox that’s supported by [MrChromebox], it’s worth taking a poke at, with some solutions allowing you to even dualboot ChromeOS and another OS if that’s your thing.

Continue reading “Turning A Chromebox Into A Proper Power-Efficient PC”

A Single-Pixel Camera Without Moving Parts Using Compressed Sensing

One of the reconstructed images, using all 4,096 matrix patterns as input, next to the original object. (Credit: okooptics, Jon Bumstead)
One of the reconstructed images, using all 4,096 matrix patterns as input, next to the original object. (Credit: okooptics, Jon Bumstead)

There’s a strange allure to single-pixel cameras due to the simultaneous simplicity and yet fascinating features that they can offer, such as no set resolution limit. That said, the typical implementations that use some kind of scanning (MEMS) mirror or similar approach suffer from various issues even when you’re photographing a perfectly stationary and static scene due to their complex mechanical nature. Yet there’s a way around this, involving a LED matrix and a single photoresistor, as covered by [Jon Bumstead] in an article with accompanying video.

As he points out, this isn’t a new concept, with research papers cited that go back many years. At the core lies the signal processing technique called compressed sensing, which is incidentally also used with computed tomography (CT) and magnetic resonance imaging (MRI) scanners. Compressed sensing enables the reconstruction of a signal from a series of samples, by using existing knowledge of the signal.

In the case of this single-pixel camera, the known information is the illumination, which is a Hadamard matrix pattern displayed on the 64 x 64 pixel LED matrix, ergo 4,096 possible patterns. A total of 4,096 samples are thus recorded, which are subsequently processed with a Matlab script. As pointed out, even 50% of the maximum possible matrices can suffice here, with appropriately chosen patterns.

While not an incredibly fast method, it is fully solid-state, can be adapted to use other wavelengths, and with some tweaking of the used components probably could cut down the sampling time required.

Continue reading “A Single-Pixel Camera Without Moving Parts Using Compressed Sensing”

PoE-powered GPIB Adapter With Ethernet And USB-C Support

In the world of (expensive) lab test equipment the GPIB (general purpose interface bus) connection is hard to avoid if you want any kind of automation, but nobody likes wrangling with the bulky cables and compatibility issues when they can just use Ethernet instead. Here [Chris]’s Ethernet-GPIB adapter provides an easy solution, with both Power over Ethernet (PoE) and USB-C power options. Although commercial adapters already exist, these are rather pricey at ~$500.

Features of this adapter include a BOM total of <$50, with power provided either via PoE (802.3af) or USB-C (5V-only). The MCU is an ATmega4809 with the Ethernet side using a Wiznet W5500 SPI Ethernet controller. There is also a serial interface (provided by a CH340X USB-UART adapter), with the firmware based on the AR488 project.

The adapter supports both the VXI-11.2 and Prologix protocols, though not at the same time (due to ROM size limitations). All design documents are available via the GitHub repository, with the author also selling assembled adapters and providing support primarily via the EEVBlog forums.

The Apple II MouseCard (Credit: AppleLogic.org)

The Apple II MouseCard IRQ Is Synced To Vertical Blanking After All

Recently [Colin Leroy-Mira] found himself slipping into a bit of a rabbit hole while investigating why only under Apple II MAME emulation there was a lot of flickering when using the (emulated) Apple II MouseCard. This issue could not be reproduced on real (PAL or NTSC) hardware. The answer all comes down to how the card synchronizes with the system’s vertical blanking (VBL) while drawing to the screen.

The Apple II MouseCard is one of the many peripheral cards produced for the system, originally bundled with a version of MacPaint for the Apple II. While not a super popular card at the time, it nevertheless got used by other software despite this Apple system still being based around a command line interface.

According to the card’s documentation the interrupt call (IRQ) can be set to 50 or 60 Hz to match the local standard. Confusingly, certain knowledgeable people told him that the card could not be synced to the VBL as it had no knowledge of this. As covered in the article and associated MAME issue ticket, it turns out that the card is very much synced with the VBL exactly as described in The Friendly Manual, with the card’s firmware being run by the system’s CPU, which informs the card of synchronization events.

Triggering Lightning And Safely Guiding It Using A Drone

Every year lightning strikes cause a lot of damage — with the high-voltage discharges being a major risk to buildings, infrastructure, and the continued existence of squishy bags of mostly salty water. While some ways exist to reduce their impact such as lightning rods, these passive systems can only be deployed in select locations and cannot prevent the build-up of the charge that leads up to the plasma discharge event. But the drone-based system recently tested by Japan’s NTT, the world’s fourth largest telecommunications company, could provide a more proactive solution.

The idea is pretty simple: fly a drone that is protected by a specially designed metal cage close to a thundercloud with a conductive tether leading back to the ground. By providing a very short path to ground, the built-up charge in said cloud will readily discharge into this cage and from there back to the ground.

To test this idea, NTT researchers took commercial drones fitted with such a protective cage and exposed them to artificial lightning. The drones turned out to be fine up to 150 kA which is five times more than natural lightning. Afterwards the full system was tested with a real thunderstorm, during which the drone took a hit and kept flying, although the protective cage partially melted.

Expanding on this experiment, NTT imagines that a system like this could protect cities and sensitive areas, and possibly even use and store the thus captured energy rather than just leading it to ground. While this latter idea would need some seriously effective charging technologies, the idea of proactively discharging thunderclouds is perhaps not so crazy. We would need to see someone run the numbers on the potential effectiveness, of course, but we are all in favor of (safe) lightning experiments like this.

If you’re wondering why channeling lightning away from critical infrastructure is such a big deal, you may want to read up on Apollo 12.

Hacky Shack? The TRS-80 Model I Story

The 1970s saw a veritable goldrush to corner the home computer market, with Tandy’s Z80-powered TRS-80 probably one of the most (in)famous entries. Designed from the ground up to be as cheap as possible, the original (Model I) TRS-80 cut all corners management could get away with. The story of the TRS-80 Model I is the subject of a recent video by the [Little Car] YouTube channel.

Having the TRS-80 sold as an assembled computer was not a given, as kits were rather common back then, especially since Tandy’s Radio Shack stores had their roots in selling radio kits and the like, not computer systems. Ultimately the system was built around the lower-end 1.78 MHz Z80 MPU with the rudimentary Level I BASIC (later updated to Level II), though with a memory layout that made running the likes of CP/M impossible. The Model II would be sold later as a dedicated business machine, with the Model III being the actual upgrade to the Model I. You could also absolutely access online services like those of Compuserve on your TRS-80.

While it was appreciated that the TRS-80 (lovingly called the ‘Trash-80’ by some) had a real keyboard instead of a cheap membrane keyboard, the rest of the Model I hardware had plenty of issues, and new FCC regulations meant that the Model III was required as the Model I produced enough EMI to drown out nearby radios. Despite this, the Model I put Tandy on the map of home computers, opened the world of computing to many children and adults, with subsequent Tandy TRS-80 computers being released until 1991 with the Model 4.

Continue reading “Hacky Shack? The TRS-80 Model I Story”