A photo of the various parts for this MSLA 3D printer

Build A 2K Resolution MSLA 3D Resin Printer For Cheap

Have an old Android device collecting dust somewhere that you’d like to put to better use? [Electronoobs] shows us how to make a Masked Stereolithography Apparatus (MSLA) printer for cheap using screens salvaged from old Android phones or tablets.

[Electronoobs] wanted to revisit his earlier printer with all the benefits of hindsight, and this is the result. The tricky bit, which is covered in depth in the video below the break, is slicing up the model into graphics for each layer, so that these layers can be rendered by the LCD for each layer during the print.

The next tricky bit, once your layer graphics are in hand, is getting them to the device. This build does that by installing a custom Android app which connects to a web app hosted on the ESP32 microcontroller controlling the print, and the app has a backchannel via a USB OTG adapter installed in the device. [Electronoobs] notes that there are different and potentially better ways by which this full-duplex communication can be achieved, but he is happy to have something that works.

If you’re interested in resin printer tech, be sure to check out Continuous Printing On LCD Resin Printer: No More Wasted Time On Peeling? Is It Possible? and Resin Printer Temperature Mods And Continuous IPA Filtration.

An RP2040 Powered ADS-B Receiver

If you’ve ever heard the sound of an aircraft passing overhead and looked at an online plane tracker to try and figure out what it was, then you’ve interacted with ADS-B. It’s a protocol designed to enable easier aircraft monitoring, and it just so happens you can decode it yourself with the right hardware and software — which is how [John McNelly] came to develop ADSBee, an open source ADS-B receiver based around an RP2040.

ADS-B uses on–off keying (OOK) at 1 Mbps, and operates at 1090 MHz. This might seem like a rather difficult protocol to decode on a microcontroller, but the RP2040’s PIO is up to the task. All it takes is a bit of optimization, and a some basic RF components to amplify and digitize the signals.

However, not all aircraft utilize the 1090 MHz ADS-B implementation, and instead use a related protocol called UAT. Operating at 978 MHz, a second receiver is needed for decoding UAT traffic data, which is where the CC1312 comes into play. ADSBee may even be the first open source implementation of a UAT decoder!

What’s quite impressive is the various form factors the module is available in. Ranging from small solder-down modules to weatherproof outdoor base stations, nearly every potential need for an ADS-B receiver is covered. With POE or ESP32 S3 options available, there is no shortage of networking options either!

ADSBees have been placed in numerous locations, ranging from base stations to drones. One user even built out a tiny flight display cluster complete with traffic indicators into an FPV drone.

This isn’t the first time we have seen ADS-B receivers used by drone enthusiasts, but this is certainly the most feature rich and complete receiver we have come across.

Powering On A 1985 Photophone CP220 Videoconference System

The concept of remote video calls has been worked on since Bell’s phone company began pitching upgrading from telegrams to real-time voice calls. It wasn’t until the era of digital video and real-time video compression that commercial solutions became feasible, with the 1985 Image Data Corporation Photophone CP220 being an early example. The CP220 is also exceedingly rare due to costing around $25,000 USD when adjusted to inflation. This makes the teardown and repair on the [SpaceTime Junction] channel a rather unique experience.

Perhaps the coolest part of the device is that the manual is integrated into the firmware, allowing you to browse through it on the monochrome CRT. Unfortunately after working fine for a while the device released the magic smoke, courtesy of the usual Rifa capacitors doing their thing. This is why a full teardown was necessary, resulting in the PSU being dug out and having said capacitors swapped.

After this deal the device powered on again, happily accepting a video input and saving screenshots to the floppy drive before it was replaced with a FDD emulator running FlashFloppy firmware. Unfortunately no video call was attempted, probably because of the missing camera and having to set up a suitable POTS landline for the built-in modem. Hopefully we’ll see that in an upcoming video to see what we common folk were missing out on back in the day.

Continue reading “Powering On A 1985 Photophone CP220 Videoconference System”

2025: As The Hardware World Turns

If you’re reading this, that means you’ve successfully made it through 2025! Allow us to be the first to congratulate you — that’s another twelve months of skills learned, projects started, and hacks….hacked. The average Hackaday reader has a thirst for knowledge and an insatiable appetite for new challenges, so we know you’re already eager to take on everything 2026 has to offer.

But before we step too far into the unknown, we’ve found that it helps to take a moment and reflect on where we’ve been. You know how the saying goes: those that don’t learn from history are doomed to repeat it. That whole impending doom bit obviously has a negative connotation, but we like to think the axiom applies for both the lows and highs in life. Sure you should avoid making the same mistake twice, but why not have another go at the stuff that worked? In fact, why not try to make it even better this time?

As such, it’s become a Hackaday tradition to rewind the clock and take a look at some of the most noteworthy stories and trends of the previous year, as seen from our rather unique viewpoint in the maker and hacker world. With a little luck, reviewing the lessons of 2025 can help us prosper in 2026 and beyond.

Continue reading “2025: As The Hardware World Turns”

The big white thing is is the CO2 exhaust bag.

Liquid CO2 For Grid Scale Energy Storage Isn’t Just Hot Air

There’s folk wisdom in just about every culture that teaches about renewable energy — things like “make hay while the sun shines”. But as an industrial culture, we want to make hay 24/7 and not be at the whims of some capricious weather god! Alas, renewable energy puts a crimp in that. Once again, energy supplies are slowly becoming tied to the sun and the wind.

Since “Make compute while the wind blows” doesn’t have a great ring to it, clearly our civilization needs to come up with some grid-scale storage. Over in Sardinia they’re testing an idea that sounds like hot air, but isn’t — because the working gas is CO2. 

The principle is simple: when power is available, carbon dioxide is compressed, cooled, and liquefied into pressure vessels as happens at millions of industrial facilities worldwide every day. When power is required, the compressed CO2 can be run through a turbine to generate sweet, sweet electricity. Since venting tonnes of CO2 into the atmosphere is kind of the thing we’re trying to avoid with this whole rigmarole, the greenhouse gas slash working fluid is stored in a giant bag. It sits, waiting for the next charge cycle, like the world’s heaviest and saddest dirigible. In the test project in Sardinia — backed by Google, amongst others — the gas bag holds 2000 tonnes and can produce 20 megawatts of power for up-to 10 hours.

Continue reading “Liquid CO2 For Grid Scale Energy Storage Isn’t Just Hot Air”

Xcc700: Self-Hosted C Compiler For The ESP32/Xtensa

With two cores at 240 MHz and about 8.5 MB of non-banked RAM if you’re using the right ESP32-S3 version, this MCU seems at least in terms of specifications to be quite the mini PC. Obviously this means that it should be capable of self-hosting its compiler, which is exactly what [Valentyn Danylchuk] did with the xcc700 C compiler project.

Targeting the Xtensa Lx7 ISA of the ESP32-S3, this is a minimal C compiler that outputs relocatable ELF binaries. These binaries can subsequently be run with for example the ESP-IDF-based elf_loader component. Obviously, this is best done on an ESP32 platform that has PSRAM, unless your binary fits within the few hundred kB that’s left after all the housekeeping and communication stacks are loaded.

The xcc700 compiler is currently very minimalistic, omitting more complex loop types as well as long and floating point types, for starters. There’s no optimization of the final code either, but considering that it’s 700 lines of code just for a PoC, there seems to be still plenty of room for improvement.

39C3: Liberating ESP32 Bluetooth

Bluetooth is everywhere, but it’s hard to inspect. Most of the magic is done inside a Bluetooth controller chip, accessed only through a controller-specific Host-Controller Interface (HCI) protocol, and almost everything your code does with Bluetooth passes through a binary library that speaks the right HCI dialect. Reverse engineering these libraries can get us a lot more control of and information about what’s going on over the radio link.

That’s [Anton]’s motivation and goal in this reversing and documentation project, which he describes for us in this great talk at this year’s Chaos Communication Congress. In the end, [Anton] gets enough transparency about the internal workings of the Bluetooth binaries to transmit and receive data. He stops short of writing his own BT stack, but suggests that it would be possible, but maybe more work than one person should undertake.

So what does this get us? Low-level control of the BT controller in a popular platform like the ESP32 that can do both classic and low-energy Bluetooth should help a lot with security research into Bluetooth in general. He figured out how to send arbitrary packets, for instance, which should allow someone to write a BT fuzzing tool. Unfortunately, there is a sequence ID that prevents his work from turning the controller into a fully promiscuous BT monitor, but still there’s a lot of new ground exposed here.

If any of this sounds interesting to you, you’ll find his write-up, register descriptions, and more in the GitHub repository. This isn’t a plug-and-play Bluetooth tool yet, but this is the kind of groundwork on a popular chip that we expect will enable future hacking, and we salute [Anton] for shining some light into one of the most ubiquitous and yet intransparent corners of everyday tech.