A render of the moon, on a circular display.

Put The Moon On Your Desk

Most people take the Moon for granted, not considering its slow cycle where the sun gradually illuminates different parts of it. A recent project from [Karsten Mueller] helps you keep our nearest celestial neighbor in mind by putting a tiny version on your desk. (German)

The device itself is made with a circular display, an ESP32-S3, and a simple 3D printed case. But the interesting part is the software — it’s not just a moon phase display, it actually takes your local time, latitude and longitude into account. The resulting image is an approximation of what the moon looks like if you were to look at it, even if you wouldn’t actually be able to see it, such as when it is obscured by the Earth or barely visible during the daylight sky. Initially the project actually used a photograph of the Moon that [Karsten] personally snapped, but there’s also an option to pull the imagery from NASA.

The original write-up is in German, but there’s also an English page for the project on Hackaday.io, and the source is available on GitHub if you’d like to put one together yourself.

Two printed circuit boards made from 3D prints and copper foil. One white and one black substrate.

Using 3D Printers To Make Circuit Boards

Custom printed circuit boards have become more and more accessible to the average hobbyist over the last decade. But one problem still remains: your circuits will take at least a couple days to make. But what if you needed some really rapid prototypes? [The Raccoon Lab] shows us how to do it with a 3D printer.

You start with the usual hobby PCB pipeline: take your idea, make a schematic, and then lay it out in KiCad. That’s where the changes start: to keep traces strong, they are made very thick. The PCB is then exported and opened in 3D CAD software, where the traces are extruded to be 2 mm tall. Off to the printer! The newly printed “circuit board” is made conductive by applying copper tape to it, and traces are cut out along their raised edges.

The result is a very quick and dirty PCB. Sure, it isn’t exactly production-ready, but for just about any simple microcontroller project it’ll do just fine, and it’s a whole lot more accessible than milling one using a CNC! We’ve seen a few variations on this approach recently, including some custom software designed to help along the process.
Continue reading “Using 3D Printers To Make Circuit Boards”

2026 Green Powered Challenge: Solar-Powered Pollution Monitor

As we learn more about all the nasty stuff floating in the air, it becomes more compelling to monitor the air for pollution levels. [Aleksei Tertychnyi] does just that with pollutagNode2, a solar-powered pollution sensor.

The device uses a Seeed Studio Wia-E5 module for its built-in LoRa low power long-range communication capabilities. Pair that with a cheap 2 watt solar panel and a Li-ion battery, and you have a monitoring device that can stay up indefinitely — or until harsh weather gets the better of it. Even if the solar panel were to be omitted, a full charge would last you about two weeks!

It comes on an open-hardware PCB; no need for giant wire messes, just solder the solar panel, battery, sensor, and anything else you want onto the convenient pads on the side. It also integrates into the existing sensor community nicely via existing LoRa infrastructure. All this combined makes it easy for anyone to deploy one.

Itanium: The Great X86 Replacement That Never Was

Itanium was once meant to be the next step in computing, to compete with the likes of IBM, Sun and DEC, but also for Intel to have an architecture that couldn’t be taken from it, as the PC was from IBM by its clones. Today, however, Itanium is a relic of the past. [Asianometry] tells us the story of Itanium.

By the ’90s, servers were an established market dominated by RISC architectures and Unix-like operating systems. Intel wanted to compete in this market, due in part to worries of losing control over x86. So, when Hewlett Packard came to Intel in late ’93, Intel eventually agreed to collaborate on a new project in EPIC (Explicitly Parallel Instruction Computing).
Continue reading “Itanium: The Great X86 Replacement That Never Was”

How One Line Of TF2 Code Ruined This Simple Feature

Ever encountered a minor annoying bug in a video game? How about one dating back to 2018? Usually, you have no hope of fixing it, but this time is different. [Joey Cheerio] shows the first-time programmer approach to (with great difficulty) fixing a bouncy ball prop turning invisible when shot in Team Fortress 2.

It starts with a band-aid solution that hides the problem: just turn off jiggle physics! While that works, it also affects many other models in the game, and doesn’t tackle the root cause. Time to investigate. Because this ball often goes overlooked, [Joey Cheerio] didn’t even realize that it was supposed to have jiggle physics, accidentally removing it. Turns out, after scouring the internet for old footage, it’s supposed to jiggle after all.

Back to square one, [Joey Cheerio] infers that the jiggle bone accidentally removed was related to the problem, eventually figuring out that the specific type of jiggle bone used (is_boing) caused the issue. Time to dig in the code. Tracking down the problem is no small feat for someone who’s never programmed before, even with the help of LLMs, but eventually, at 4 in the morning, a breakthrough! The ball no longer turned invisible but retained the intended jiggle.

At the limits of his knowledge on the subject, [Joey Cheerio] posts his partial progress so far to GitHub, where [ficool2] tracks down the real problem and turns this second band-aid into a proper fix. [Joey Cheerio] finishes up by explaining the math of what exactly went wrong.

Continue reading “How One Line Of TF2 Code Ruined This Simple Feature”

FRED Comes To Hobby Operating Systems (and Linux)

Those who have worked on a hobby operating system for x86 will have interacted with its rather complex and confusing interrupt model. [Evalyn] shows us why and how to use Flexible Return and Event Delivery (FRED), a new standard by the x86 Ecosystem Advisory Group.

Of course, it would be silly to omit the fact that Linux received patches first. But that isn’t the interesting part; after all, Linux is often the first place to have support for this kind of thing. No, what’s interesting is [Evalyn]’s implementation, to our knowledge among — if not the first — non-Linux operating system to support it.

Part of the startup log of EvalynOS
The kernel confirming that FRED has been detected and enabled

To know why we should switch to FRED, we must first understand what it replaces. The Interrupt Descriptor Table (IDT) tells the CPU what code to run when certain interrupts or faults happen. The big problem that the IDT has is inconsistency, most egregiously the fact that the stack layout depends on which interrupt happened. To solve the issues with the IDT, FRED was created.

[Evalyn] shows us the process, starting at the documentation, then finding an emulator capable of it and culminating in a demo where DOOM runs in EvalynOS with FRED enabled.

Pentium II die shot. Martijn Boer, Public domain.

FPGA Powers DIY USB Scope And Signal Generator

Oscilloscopes and to lesser extent signals generators are useful tools for analyzing, testing and diagnosing circuits but we often take for granted how they work. Luckily, [FromConceptToCircuit] is here to show us how they’re made.

[FromConceptToCircuit] starts by selecting the hardware to use: an Artix-7-based FPGA and an FT2232 USB-serial converter. RS245 in synchronous FIFO mode is selected for its high bandwidth of about 400 Mbps. Then, they show how to wire it all up to your FPGA of choice. Now it’s time for the implementation; they go over how the FT2232 interfaces with the FPGA, going through the Verilog code step-by-step to show how the FPGA makes use of the link, building up from the basic transmission logic all the way up to a simple framed protocol with CRC8-based error detection. With all that, the FPGA can now send captured samples to the PC over USB.

Now it’s PC-side time! [FromConceptToCircuit] first explains the physical pipeline through which the samples reach the PC: FPGA captures, transmits over RS245, FT2232 interfaces that with USB and finally, the software talks with the FT2232 over USB to get the data back out. The software starts by configuring the FT2232 into RS245 mode, sets buffer sizes, the whole deal. With everything set up, [FromConceptToCircuit] explains how to use the FT2232 driver’s API for non-blocking communication.

As a bonus, [FromConceptToCircuit] adds a signal generator feature to the oscilloscope using an I2C DAC chip. They start by explaining what exactly the DAC does and follow up with how it’ll be integrated into the existing system. Then it’s time to explain how to implement the I2C protocol bit-for-bit. Finally combine everything together for one final demo that shows a sine wave on the DAC’s output.