Ceramic 3D printers, despite using the same fundamental mechanism as standard FDM printers, are much harder to find. Part of this comes down to the material properties of fired ceramics versus thermoplastics, but they’re also significantly harder to build; for example, in his ceramic printer build, [Joshua Bird] had to deal with severe material shrinkage, collapsing bridges, and the surprisingly abrasive effects of clay.

The centerpiece of the printer is the clay extruder: an air compressor pushes clay along a tube into the extruder, which uses an auger to squeeze the clay through the nozzle, while a gap at the top lets trapped air escape. The extruder has enough control for successful retractions, but rheology remained a challenge: the clay needed to be soft enough to flow through the nozzle, but stiff enough to form bridges without collapsing. [Joshua] thus pressurized the clay as much as possible, making it possible to use stiffer clay mixtures. The extruder’s greatest challenge was longevity: [Joshua] tried many 3D-printed plastic augers, but the clay abraded them all much too quickly, often in under an hour of use; a 3D-printed stainless steel extruder solved this.

Printing in ceramic isn’t a simple process: for each part, [Joshua] had to mix the clay, load it into the tube, clean the extruder, actually print the object, let it dry, fire it, apply glaze, and fire it again. The clay’s shrinkage during drying and firing destroyed many prints, but [Joshua] was nevertheless able to print a double-walled cup, a decorative climbing-themed cup, and even a chain-mail mesh.

The 3D printer’s motion system is a polar design, an adaptation of his earlier non-planar 3D printer, which might eventually make it easier to print overhangs. We’ve previously seen a similar auger-based clay extruder, an approach reminiscent of direct-granule FDM printing.

youtube.com/embed/ajfrOBs_mNk?…

hackaday.com/2026/07/11/clay-e…

Ceefax was the BBC’s broadcast teletext service that ran until 2012, providing text and rudimentary graphics that were broadcast invisibly with the TV signal. In order to get this teletext data merged into the analog TV signal, special equipment was needed, of which [Nathan Dane] has a 1997-era unit on his bench to take a gander at.

Interestingly, until this time the Ceefax signal had been generated centrally in London, meaning that regional TV broadcasts might have Ceefax issues on occasion due to retransmission glitches. This makes this Ceefax Inserter system so much more interesting, as it was one of the early examples of what these regional stations would end up installing in their racks.

At their core these units are regular PCs, running MS-DOS 6.22 on a 486-class CPU and all the typical bits and bobs that go with a PC. The speculation here is that these are essentially rebranded industrial PCs, which would make a lot of sense. As for how [Nathan] got his hands on these units, it required a deal with the company scrapping them, preventing him from showing details of the software configuration.

Following a booting demonstration, we get the teardown of a typical 1990s rackmount PC, revealing a rather interesting backplane with the mainboard being one of the cards on it. Of these, two ISA cards provide the special Ceefax sauce as well as a timing signal in the form of a PDC card featuring a Lattice CPLD or FPGA that VCRs could use to automatically start recording.

The Ceefax main event comes in the form of the inSERT Teletext Encoder card. This is pretty much its own computer system, featuring a TI TMS34010 CPU and its own RAM as well as IO. Compared to modern takes on teletext generators, this card appears to directly mix the analog signals, without any kind of conversion.

Although teletext systems have been largely shutdown now at this point due to the transition to digital TV broadcasting, there’s still a lot to be said for having such a service available for basic news and information.

youtube.com/embed/myqe_EYdZJY?…

hackaday.com/2026/07/11/a-look…

After previously fixing an overly bright picture from a Voodoo graphics card with a simple resistor on one of the RAMDAC’s pins to correct its faulty internal Vref, [Bits und Bolts] got called out for not taking component drift into account. Thus in an update video he shows how instead to use an adjustable AMS1117 voltage regulator to hopefully prevent either the original issue or something new and exciting from cropping up later.

The basic idea here is to use the external voltage reference (Vref) pin for this ICS5342 RAMDAC and supply it with a constant 1.235V. If unused – as on this Orchid-branded Voodoo card – it is connected via an 0.1 microFarad capacitor to ground. This fortunately means that the pin is routed to easily accessible pads that make this modification relatively straightforward.

Basically this is where the AMS1117-ADJ chip comes into the picture, as a widely available adjustable LDO option, even if the 0.8A current rating is very much overkill for this application. With the supplied voltage the lowest voltage this LDO can output is around 1.25V, which is within the 1.10 – 1.35 V range of the datasheet.

Of course, with the PCB never having had a provision for this part, much of the rest of the video is about planning out where to place and route the components. After that tedious work and testing that nothing explodes, the new voltage is used for the RAMDAC’s Vref pin, fixing the brightness issue.

While one could argue that this RAMDAC is likely simply defective and already beginning to break down inside, this should at least give it a bit longer on what seems to be a little used card anyway.

youtube.com/embed/QQEO4e0rt2g?…

hackaday.com/2026/07/10/fixing…

We’re not exactly sure how old [SnailMail] is, but he’s probably a member of Generation Alpha considering that to our wizened eyes the lad looks only slightly older than a fetus– which makes it all the more impressive that he’s written his own text editor, from scratch, in C– on a 386. See, [SnailMail] tried to learn the modern way, with IDEs that have code completion and AI integration, but his thoughts couldn’t gel in the modern environment. So he went online and bought an old IBM-compatible complete with monochrome amber monitor, and a whole 4MB of RAM. Big spender that he is, [SnailMail] upgraded that to 8MB.

Rather than fall victim to the siren song of Wolfenstien 3D or SimCity, he set out to learn to code: C, specifically, since that language bridges four decades between [SnailMail] and his new PC. Even more specifically, he got ahold of disks for Borland Turbo C and Turbo C++, which brings back memories for some of us. Of course the lad also had to learn how to use a DOS PC at the same time, but a teen in the 80s with a fresh box would have climbed the same steep learning curve. Some of you probably remember doing so yourselves. Just like you–or the hypothetical teen in the 80s–[SnailMail] did it not by googling or begging Claude for answers, but by digging into books. Many books.

After all the reading, he started with a text editor, something we remember being a pretty big project not given to first year students. Video evidence suggests he pulled it off. He describes how his solution works from about 8:00 in the video, so you greybeards in the audience can judge his work for yourself.

If you’re a member of Gen Alpha reading this and looking to learn to program, we cannot recommend this technique highly enough– [SnailMail] is going to have a better understanding of the underlying logic of computer science than a lot of CS grads being frocked today. Especially when you consider he ends by promising to learn assembly, something we heartily endorse.

youtube.com/embed/I7CeqmFiWYY?…

hackaday.com/2026/07/10/reject…

Having a pump in a remote location where you aren’t constantly monitoring it is a common scenario, which can be unfortunate when said pump runs into problems like a dry well, jammed impeller or power issues. This is where pump monitors like the older SymCom (now Littelfuse) PumpSaver Plus 233P will protect the pump if such conditions are detected. Of course, the infrared communication port on it uses an undocumented protocol that was meant to be used with a long-since discontinued handheld device. Ergo [Elizabeth Camporeale] saw fit to reverse-engineer this protocol.

In the installation manual for this device this Informer unit is briefly mentioned along with the information it will display on its screen, making it clear that it’s quite literally just there to act as a display for the information that’s constantly generated on this interface. Naturally, this is incredibly useful if you wish to tie the system into a wider monitoring and automation system.

Somewhat unusual, this IR interface on the used 233P-1.5 unit turned out to be use a 5,000 baud NRZ, MSB-first protocol, with the juicy details fully documented and a Python-based decoder implementation provided.

Naturally [Elizabeth] didn’t just reverse-engineer this for the fun of it, but also for ESPHome integration. This uses a setup as can be seen in the top image, with an ESP32-C6 module providing the processing power and Wi-Fi, with a standard phototransistor recording the data pumped out by the pump monitor.

hackaday.com/2026/07/10/docume…

If you’re not aware, there is such a thing as adorable little three digit LCD 7-segment displays. They come in a ten-pin DIP package and are just begging to be integrated into a project. The catch is they are just a tiny bit weird. Luckily for us all, [Nagy Krisztián] spells out exactly how to use them.

The first odd thing about these ten-pin LCD displays have a footprint that doesn’t quite mesh with standard 0.1 inch spacing, meaning they will not cleanly fit into a breadboard. Luckily, one can solve this with a bit of force. It’s a small part, and the pins don’t seem to mind.
These little LCDs are adorable, but a bit unusual to interface with.
The second odd thing is wrapping one’s head around the pin mapping. Figuring out which pins activate which segments in the digits is easier if one keeps in mind that each segment of each digit is the product of two different pins. For example, “2A” is digit two, segment A, and is the product of pins 3 and COM4.

That’s not all. Electrically speaking, driving this LCD isn’t nearly as straightforward as an LED.

With an LED display, the COM pins are either common anode or common cathode, which tells one whether lighting up a segment means holding the COM pin at GND with voltage applied to the segment pin, or the other way around. But in the case of this LCD display, the polarity applied is swapped every cycle. Oh, and inactive COM pins need to held at half-voltage. Neat!

[Nagy] drives the whole thing with little more than an ATtiny84 microcontroller and a few resistors. A switchable half-voltage signal is cleverly created by combining a simple voltage divider and taking advantage of the fact that the ATtiny84’s pins can be in one of three different states depending on how they are configured: high, low, or high-impedance (pin configured as an input). Each COM pin on the display gets connected to both an ATtiny84 pin, and to the supply voltage via two resistors forming a voltage divider. When the ATtiny drives the pin high, the LCD pin sees about 3 V. When the pin is driven LOW, the LCD pin sees 0 V. When the ATtiny configures the pin as an input, the LCD pin receives about 1.5 V.

The bulk of the software is defining which pins and states equal which digits, and cycling the LCD at a rate of vaguely 60 Hz which delivers flicker-free results.

We appreciate the clever combination of voltage divider with pin configuration to create three switchable voltage levels. If you liked that and want to see more serious leveraging of pin configuration on a microcontroller, check out how to drive seven LEDs with only two pins.

hackaday.com/2026/07/10/how-to…

You’ve doubtlessly seen the current crop of robot dogs and, if you are like us, thought about getting one to play with. The problem is that the cheap ones are toys, and the serious ones cost serious money. But now you can experiment with a mid-range cost one for free in your browser. The sponsor will be happy to sell you a robot in kit or assembled form, although it is the OpenCat robot (we’ve covered it before), so you could simply build a real one yourself if you wanted to.

The code is all in a Web-based IDE, and the main file is deceptively simple. However, the real work is in read_serial (in the src/moduleManager.h file, for some reason) and reaction in the aptly-named src/reaction.h file. If you just want to play, you can use the buttons in the simulator or enter serial commands (documented elsewhere). For example, ksit will make the dog sit down.

You can change as much code as you like. You might consider starting simple and just sending commands programmatically, but you can dive as deep as you like. Press compile up at the top right, and it will load and run your code in the virtual robot. If you run it off the desk (of course, we did), you can reset and try again.

Here’s a quick example to get you started:

//***********************
#define BITTLE // Petoi 9 DOF robot dog: 1 on head + 8 on leg

#define BiBoard_V1_0
//***********************

#include "src/OpenCat.h"

void setup() {
Serial.begin(115200); // USB serial
Serial.setTimeout(SERIAL_TIMEOUT);

while (Serial.available() && Serial.read())
; // empty buffer

Serial.println("Hello Hackaday!");
initRobot();
}

unsigned int loopct=0;
unsigned int phase=0;

#define cmdtokenEOF 0xFFFF

// commands (token + argument)
char *cmd[] =
{
"sit", // good boy
"up", // stand up
"bf", // back flip
"ff", // forward flip
"EOF" // string doesn't matter here
};

unsigned int cmdtoken[] = {
T_SKILL,
T_SKILL,
T_SKILL,
T_SKILL,
cmdtokenEOF
};

#define LOOPDELAY 1000 // number of loops between actions

void loop() {
// This code runs repeatedly
// Put any change here if you want to change behaviors
if (loopct % 1000 == 0 )
{
loopct=0;
if (cmdtoken[phase]==cmdtokenEOF) phase=0;
strcpy(newCmd,cmd[phase]);
token=cmdtoken[phase++];
newCmdIdx=1;
}
loopct++;

reaction();
}

The robot is better than the cheap toys, but it still lacks many sensors. You can add on a few simple sensors that appear to mount in the dog’s mouth, or you can replace its head with an arm if you opt for beefy enough servos.

Of course, we’ve seen plenty of robot dogs. We want one, but we don’t know what we’d do with it. Any ideas?

hackaday.com/2026/07/10/robot-…