TechyMagThings

Paper as a substrate for electronic circuits is not very common, but promising for flexible circuits with low cost and easy recyclability. That said, paper is not an easy material to work with when printing traces, as the cellulose material is both absorbent and irregular, limiting the resolution and accuracy of so-called papertronics. Even when using higher-quality paper with wax-based masks this resulted in poor resolution issues, so [Zahra Rafiee] et al. opted to approach the problem from the other direction, by using hydrophobic parchment paper as the base combined with a laser.

The nice thing about the inks used with papertronics that they aren’t just traces, but can also be functional elements like resistors, which is also demonstrated in the paper. The channels for the inks are created using a 50 Watt CO₂ laser, which etches away the silicone coating on the parchment paper. The achieved resolution in the article is around 250 µm for line widths and 300 µm line spacing, which is much better than that for wax-based alternatives.

Providing conductivity in the inks was PEDOT:PSS, which, when mixed with dimethyl sulfoxide (DMSO), creates resistors. Capacitors can be printed by creating interlocking PEDOT:PSS ‘fingers’, with a Poly Vinyl Alcohol (PVA) based gel overlaid as electrolyte. These combinations were used to create RC low- and high-pass filters.

The degradation of these papertronic circuits was also tested, with them buried in soil under typical conditions. Only the silicone coating was rather immune to degradation. Since silicone is considered chemically and biologically inert, it’s claimed to not be an issue. For situations where such easy decomposition is not desirable, encapsulation with polydimethylsiloxane (PDMS) is offered as an option.

Avian Visitors is a lovely project by [Teddy Warner] that uses a Raspberry Pi and microphone to keep track of which birds have been visiting your home, and creates a colorful illustration of recent visitors on top of it all.

It reports on a web interface of its own making, but what really takes things to a new level is an optional, stylish E-Ink panel that shows the last 24 hours’ worth of visitors at a glance in a collage.

The key to identification is BirdNET (GitHub here), a deep learning classifier from Cornell that can reliably identify and classify more than 11,000 species worldwide based on sound alone.

Based on that information, the system pulls bird images from a reference set for the region and creates a collage representing the breadth and frequency of visitors in a single image. The larger the image of a bird, the more frequently it was heard.

That’s a cool project, but [Teddy] took things one step further by setting up a color E-Ink display to show a running summary of all the avian visitors the system identifies. [Teddy] has a knack for leveraging projects into wall-mounted art, as we saw with his generative art wall plotter.

Got ideas of your own? Avian Visitors even has options for sending the latest detection to Home Assistant or over MQTT, allowing automation triggers based on specific bird species. If you decide to try it out and put your own spin on it, be sure to let us know by sending us a tip!

The GitHub repository for Avian Visitors has everything you need to get set up, and the basic system needs little more than a Raspberry Pi and a USB microphone. There’s a build video embedded just below, so give it a shot if you want to get a better idea of what birds come visiting.

If you’ve ever worked with produce, you might know about grading. In addition to deciding if, say, a strawberry is good or not, they also have to sort them by color. Turns out, you don’t care if one package of berries is a bit redder than another, but you do care if one package has too much color variation. [Pmalfa31] applied an ESP32 and machine learning to grading tomatoes.

The system knows in advance if you are processing standard tomatoes or cherry tomatoes and uses two different sets of learned data depending on which you select. The program receives raw data from an optical sensor and then processes it to remove empty belt images, compute statistical information, and group readings for a single fruit together.

One thing we liked was the program’s heuristic checking of validity. It knows the approximate size of the tomato, so the code notes if the fruit seems too big for a cherry tomato or too small for a standard tomato. This reduces, but doesn’t eliminate, miscategorizations.

The code is a stack hog, so the program has to request a much larger stack. If you want to try it yourself, there is a simulator on the web available, so you don’t even need any hardware or tomatoes to try it.

Computers have lots of uses on a modern farm.

If you’re water cooling a PC, it’s generally accepted that you need some interface between the coolant and the chips — a water block of copper or aluminum that carries the heat-removing fluid. What if you just…didn’t? That’s what [TrashBench] asked with his direct water cooling experiment. Instead of integrated pump or copper water block, he just epoxied a 3D printed pipe fitting onto his bare GPU and CPU.

The results are interesting: while the directly-cooled GPU outperforms the professional system by a decent margin, the same technique fails when applied to the CPU. It also leaks and nearly ruins his hardware, but those are the risks you take when doing mad science, and it’s nothing more epoxy can’t fix. In any case, the fact that directly exposing chips to liquid can cool them down isn’t exactly a revelation. People have been dunking computers in oil for years, but the fact that he sees such a difference between CPU and GPU is quite interesting. [TrashBench] has his own theory in the video, but what do you think is going on here?

In any case, if he continues his direct cooling experiments he’s still going to need a radiator, and if we may be so bold, we would like to recommend a giant metal snake.

Sandboxing a Linux process usually means spending a lot of effort deciding what it isn’t allowed to see. You might put it in a mount namespace, bind-mount a few directories into place, hide some others, add a chroot, and generally construct a carefully restricted version of the filesystem. But a new Linux kernel feature is about to change all of that. Instead of carefully hiding most of the filesystem, why not just take the filesystem away?

That’s essentially the idea behind FailFS, a tiny pseudo-filesystem expected to land in Linux 7.3. As the name suggests, it doesn’t do very much. In fact, that’s the point: every operation that reaches FailFS returns EOPNOTSUPP, meaning “operation not supported.”

The interesting bit is what happens when a process uses FailFS as its root or current working directory. At that point, normal pathname lookup essentially ceases to work. Absolute paths fail. Absolute symbolic links fail. Relative paths using the normal current-directory mechanism fail. If the application tries to open /etc/passwd, there simply isn’t a useful /etc to find.

Instead, the process has to start filesystem operations from an explicit file descriptor it already owns. For example, a sandbox manager could open a directory, hand that descriptor to the application, and the application could access files below it using calls such as openat(). Anything not reachable from one of those deliberately supplied descriptors might as well not exist.

Instead of starting with an entire filesystem and constructing rules that say, “not that, not that, not that,” you start with nothing and explicitly hand over the pieces the program needs.

There are some interesting consequences. At present, putting a process completely inside FailFS also prevents it from launching ordinary dynamically linked executables. ELF binaries generally specify their dynamic loader using an absolute pathname such as /lib64/ld-linux-x86-64.so.2. Absolute paths don’t work, so neither does the loader.

FailFS also has an interesting sibling called NULLFS, introduced earlier. NULLFS is another deliberately useless filesystem, but it behaves slightly differently: it contains a permanently empty directory and failed lookups return ENOENT, as though the requested file simply doesn’t exist. It was originally introduced to provide an immutable bottom layer beneath the real root filesystem and make operations such as pivot_root() cleaner.

Neither replaces all the other pieces needed for a secure sandbox. Processes still have system calls, networking, IPC, inherited descriptors, and plenty of other ways to cause trouble. But for controlling filesystem access, FailFS has a nice, simple philosophy.

Of course, if your file system is unwritable, that works, too.

Having a fully automated cotton candy vending machine in your possession is a great thing, but not if you do not have full access to its software. With [Block’s Retro Repairs] getting ghosted by the manufacturer on regaining account access to the machine he bought used for $300, there was little left but to try and break into the system.

We previously covered the journey in getting the vending machine back into a state where it’d actually reliably produce cotton candy again, a process which is quite tedious and temperamental. After a lot of fiddling with sensors and temperature settings this was fixed, but still left the issue that as a vending machine it should allow the owner to set prices and such. Sadly this could only be done remotely via a special account, which access to had been left with the previous owner.

Despite the very custom exterior, the vending machine runs what is effectively an Android system, consisting of an industrial computer board wired into a lot of stepper drivers and other control boards. To the extreme delight of everyone involved, it was possible to access the Ct Terminal application with adb and its product database on the device’s storage. Unfortunately writing back a changed database file didn’t change anything in the UI, so for a few months the project languished.

After nearly bricking the system and ending up factory resetting the control software including temperatures, it actually improved the performance of the machine and produced cotton candy, so that was one win. Ultimately the solution was to modify the original app, but a combination of weak coding skills and the app being in Chinese  led him to use free LLM coding chatbots to assist here.

This resulted in a custom settings menu being added with the ability to modify pricing, no need for online access any more and a very nice cotton candy vending machine for the private arcade where presumably friends and family can enjoy cheap or even free cotton candy. Finally having the machine sealed against ant intrusion was also a major improvement.

When the Chernobyl Nuclear Power Plant’s #4 reactor experienced an extreme criticality event on that infamous day in 1986, the resulting steam explosion and lack of any kind of containment building meant that parts of the core were scattered throughout the site. In an extensive update to the original 2023 video, the [Chornobyl Family] covers the mad scramble to design robots to perform on-the-ground measurements, and ultimately remove all this debris for safe disposal.

This essentially took the form of a hackathon, involving teams from all over the USSR and allied nations, creating the most diverse range of robots that 1980s Soviet technology and later Western technology could muster.

Many of these robots didn’t perform very well, or at all, mostly due to the bypassing of any kind of testing before deployment. Especially at the beginning of the clean-up the robots were being pushed into the high-radiation zones as soon as they were finished, with not only mechanical issues being a problem, but also with e.g. inaccurate radiation measurements by the RR-1 robot, that overstated measurements by more than a factor of ten. Meanwhile the RR-2 and RR-3 were too top-heavy and after deployment by helicopter simply tipped over. Eventually manual measurements proved to be faster and safer.

Early debris removal robots like the TR-1A were rather simplistic, with successive generations of robots over the next weeks and months improving on it. The use of a combustion engine instead of batteries provided to be a boon, as combustion engines are far less affected by radiation.

The BAER Beloyarets used an airport cart as the basis, with its electronics relying on vacuum tube technology and relays, with an internal combustion engine. This proved to be one of the most reliable designs and it’s been largely preserved on display in the Chornobyl Exclusion Zone, with many others of these robots also being on display around the nuclear plant or in the city of Chornobyl.

Overall an absolutely dizzying number of robotic designs were invented on the spot, adapted from existing designs or repurposed for operation in a high-radiation zone. Eventually bulldozer designs like the STR-1 helped to push radioactive debris off the roofs into containers, massively reducing the radioactive contamination of the area.

The fact that following #4’s RUD the other three RBMK units were able to keep operating safely without risks to its operators, and with the zone now safe for tourists, is a real testament to the success of the worst hackathon imaginable. Many of the lessons learned are relevant today, including during the decommissioning of Fukushima Daiichi’s melted-down cores.