2026-04-23 13:00:04
There’s little point in setting up your own shed-based clean room for semiconductor purposes if you don’t try to do something practical with it. Something like responding to the RAMpocalypse by trying to make your own RAM, for example.
After all, what could be so hard about etching the same repeating structures over and over? In a recent video, [Dr. Semiconductor]’s experience doing exactly this are detailed, with actual DRAM resulting at the end.
We covered the construction of the clean room shed previously, which should provide at least the basic conditions to produce semiconductors without worrying about contaminating dies. From here the process is reminiscent of etching PCBs, with a prepared surface coated with photoresist. Using UV exposure through a mask, the pattern is etched into the photoresist and from there the pattern is subsequently etched into the wafer’s surface.
With the patterns formed, the next step is doping of the silicon in order to creative the active structures, i.e. the transistors and capacitors. Doping can be done in a variety of ways, with ion implantation being the industry standard method, but a bit too expensive and bulky for a shed fab. Instead a spin-on-glass method was used. After this the remaining functional structures can be built up.
If anyone was expecting to see a DDR5 DRAM die pop out at the end, they’re bound to be disappointed. The target here was to create a 5×4 array of DRAM cells, for a dizzying 20 bits. Still, the fact that it’s possible to DIY DRAM like this at home is already pretty awesome, with clearly plenty of room to push it towards and past fabrication nodes of the 1990s and beyond.
Although the produced DRAM cells have fairly leaky capacitors, they’re good enough for their purpose, and the plan is to scale up to a large DRAM array from here. Whether the DRAM control logic will also be implemented in hardware like this remains to be seen, but the video’s ending makes it clear that the goal is to attach it to a PC somehow.
2026-04-23 10:00:40
In the ongoing development of cancer immunotherapy, as well as our still developing understanding of the human immune system, there’s always been a bit of massive elephant in the room. The thing about human bodies is that they’re not just human cells, but also consist of trillions of bacteria that mostly live in the intestines. What effect these bacteria have on the immune system’s functioning and from there on immunotherapies was recently investigated by [Tariq A. Najar] et al., with an article published in Nature.
The relevant topic here is that of antigenic mimicry, involving microbial antigens that resemble self-antigens. Since these self-antigens are a crucial aspect of both autoimmune diseases and cancer immunotherapy there is considerable room for interaction with their microbial mimics. Correspondingly these mimics can have considerable negative as well as positive implications, ranging from potentially triggering an autoimmune condition to hindering or boosting cancer immunotherapy.
In this study mice were used to investigate the effect of such microbial interference, in particular focusing on immune checkpoint blockade (ICB), which refers to negative feedback responses within the immune system that some cancers use to protect themselves. In some immunotherapy patients ICB inhibiting using e.g. anti programmed cell death protein (anti-PD-1) treatment does not provoke a response for some reason.
For the study mice had tumors implanted and the effect of a particular microbe (segmented filamentous bacteria, SFB) on it studied, with the presence of it markedly improving the response to anti-PD-1 treatment due to anti-gens expressed by SFB despite the large gut-skin distance. Whether in humans similar mechanisms play a similarly strong role remains to be investigated, but it offers renewed hope that cancer immunotherapies like CAR T-cell immunotherapy will one day make cancer an easily curable condition.
2026-04-23 07:00:53
For those who haven’t been following along, [BPS.space] aka [Joe] is on a journey to launch a home-built rocket past the line where it will officially reach outer space. But one does not simply launch a rocket to outer space on the first try. The process is long and involves not only building a series of rockets, but designing and building propellant mixtures, solving aerodynamic problems, gaining several model rocket certifications along the way, and a whole host of other steps. He’s also documenting the entire process on video as well, which involves some custom camera work like this rocket selfie camera which will take an image of his rockets at apogee.
Like most problems in high-power rocketry, extremely tiny problems have a way of causing catastrophic failure, so every detail needs to be considered and planned for in the final design. For a camera that needs to jettison itself from the rocket at a precise moment after experiencing an incredible amount of forces, this is a complicated problem to solve. The initial design involves building a sled for a small deconstructed GoPro which uses springs and a servo to launch itself out of the rocket. The major problem with the design is that even the smallest torque on the sled will cause the camera to point in a random direction by the time it’s far enough from the rocket to take a picture. [Joe] tried a number of design iterations but could not get these torques to vanish.
One of the design limitations with this camera is that it won’t have any sort of parachute or tether itself to the rocket, so it will hit the ground at its terminal velocity. To keep that velocity down and improve survivability chances of the footage, the mass has to stay low. Eventually he settled on a semi-active control system by mounting a brass weight on a small motor, giving the camera module enough stability to stay pointed at the rocket long enough to take the video. Even though it hasn’t flown yet, admitting his first design wasn’t working at compromising on this solution which adds a bit of mass seems to be a good design change. We’ve been following along with his entire process so be sure to check out his actual rocket motor builds and teardowns as well.
2026-04-23 04:00:45
[Térence Grover] had a very special coin—a €1,000 commemorative piece only available to Monégasque nationals. If you want to flip one, normally you’d have to go snatch one up from somebody in Monaco—or you could just do it online!
Yes, he built an automated online coin flipper to flip this very special piece of coinage. A 12-volt solenoid is fired to flip the coin into the air. It then lands on its 3D-printed tray, where a Raspberry Pi-based computer vision system built with OpenCV and a TFLite model classifies whether the result is heads or tails via a machine learning algorithm. An iris mechanism operated by servo motor then centers the coin on the tray, so it sits back over the solenoid, ready to flip once again. [Térence] was eventually able to refine this simple homemade build to the point that it ran autonomously for a full 50,000 flips on a livestream without issue.
The mechanism in this build is not dissimilar to a coin flipper we’ve seen before. We’ve also explored the statistics involved, too. Video after the break.
2026-04-23 02:30:50
This week Jonathan chats with Johannes Millan about Super Productivity and Parallel Code! Those are two very different projects, but both aiming for helping us get our work done. Super Productivity is a scheduling and time tracking suite, while Parallel Code is an almost-IDE for managing and isolating AI coding agents. This episode has something for everybody, so check it out!
Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or have the guest contact us! Take a look at the schedule here.
Direct Download in DRM-free MP3.
If you’d rather read along, here’s the transcript for this week’s episode.
Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 4.0 License
2026-04-23 01:00:39
It’s a phrase we use a lot in our community, “Drink the Kool-Aid”, meaning becoming unreasonably infatuated with a dubious idea, technology, or company. It has its origins in 1960s psychedelia, but given that it’s popularly associated with the mass suicide of the followers of Jim Jones in Guyana, perhaps we should find something else. In the sense we use it though, it has been flowing liberally of late with respect to AI, and the hype surrounding it. This series has attempted to peer behind that hype, first by examining the motives behind all that metaphorical Kool-Aid drinking, and then by demonstrating a simple example where the technology does something useful that’s hard to do another way. In that last piece we touched upon perhaps the thing that Hackaday readers should find most interesting, we saw the LLM’s possibility as a universal API for useful functions.
When we program, we use functions all the time. In most programming languages they are built into the language or they can be user-defined. They encapsulate a piece of code that does something, so it can be repeatedly called. Life without them on an 8-bit microcomputer was painful, with many GOTO statements required to make something similar happen. It’s no accident then that when looking at an LLM as a sentiment analysis tool in the previous article I used a function GetSentimentAnalysis(subject,text) to describe what I wanted to do. The LLM’s processing capacity was a good fit to my task in hand, so I used it as the engine behind my function, taking a piece of text and a subject, and returning an integer representing sentiment. The word “do” encapsulates the point of this article, that maybe the hype has got it wrong in being all about what an LLM can make. Instead it should be all about what it can do. The people thinking they’ve struck gold because they can churn out content slop or make it send emails are missing this.
So we have an LLM, even a small one on our own computer, and looking at it in that light it’s immediately apparent that it can become a function to do almost any processing task, if you wrap the right prompt and API call in a function definition. Of course that’s dangerous, because if I may I would like to coin a new phrase: function slop.
As an example I can call an LLM to do simple numerical addition and it will perform the task, but doing so would be utterly pointless given the existence of the + operator. If you are going to use an LLM to perform a processing function it’s important that it be a function where doing so makes sense, otherwise your function is just function slop. A quick web search tells me that function slop is not yet a thing, so I would like to take this moment to apologise for what I may have unleashed upon the world.
Function slop aside though, using the LLM to do a processing task where it makes sense, shouldn’t be ignored as a useful tool. These things are very good at summarising and categorising information in the way a human might do it, a task that’s often hard in traditional programming, so if the job in hand fits those capabilities then it makes sense to use them.
This has been a three-part series, and unlike Star Wars or The Hitchhikers Guide To The Galaxy, it’s probably going to stay that way. I hope that in our explanation we’ve successfully looked beyond the hype and found something useful in all this. It’s odd though, as the one writing it you might think I would be bubbling over with new ideas, but aside from the previous article’s sentiment analysis I still find myself with not much I find the need to use an LLM for. Which is maybe the point, it’s one thing to know a bit about them, but just because they’re there doesn’t mean you have to use them.
