2026-04-28 10:00:35
Solid state batteries, we are told, are the new hot battery technology that will replace lithium-ion batteries. Soon. Not that we haven’t heard that before. One reason it isn’t dominating the market today is that it’s prone to short circuits during charging. [Dr. Yuwei Zhang and others have published a paper detailing why the shorts happen, which could lead to strategies to improve the technology.
Solid state batteries employ a solid electrolyte and a lithium anode. It is known that, sometimes, lithium metal from the anode forms dendrites that penetrate the ceramic electrolyte and cause it to crack. This is somewhat of a mystery as the lithium is a soft metal (to quote [Zhang], “like a gummy bear.”).
There were two leading hypotheses for the observations. [Zhang’s] team showed that hydrostatic stress made the lithium dendrites act like a water jet, enabling them to penetrate the hard ceramic.
There is still work to figure out what to do about it, but understanding the root cause is certainly a step in the right direction. We’ve looked at these batteries before. We’ve also seen how changing the anode construction might help with the problem.
2026-04-28 07:00:08
Ultrasonic levitation is by now a familiar trick: one or more ultrasonic transducers create a standing wave, and small objects can be held in the nodes of this standing wave. With a sufficiently large array of transducers, it’s even possible to control the movement of the object. This isn’t the only form of ultrasonic levitation, however, as [Steve Mould] demonstrated with his ultrasonic air hockey table.
This less familiar form of levitation was discovered by [Bob Collins] while working on torpedo guidance systems: when he tried to place a glass lens on an ultrasonic transducer it immediately slid off. He found during further experimentation that an ultrasonic transducer would levitate over any sufficiently flat and smooth surface. It works by trapping a very thin layer of air between the transducer and the smooth surface. When the transducer moves sharply toward the surface, it compresses a layer of air in between, and forces some air out, and the reverse happens while pulling back. However, during the downstroke, the gap through which air can escape is narrower than during the upstroke, and there is more surface-induced drag, meaning that the inflow and outflow of air through a narrow gap isn’t completely equal. At a certain distance, inflow and outflow balance, and the transducer floats on a thin layer of air.
In [Steve]’s air hockey arena, the floor oscillates and the pucks levitate over this. Driving it using just one transducer didn’t work, since the floor formed standing waves, and the pucks would get stuck on node lines. Instead, he used two transducers, one at each end of the arena, and drove them out of phase with each other. This created a standing wave and minimized dead spots.
The arena was a bit small (having to be played using toothpicks), but it seemed to work well. If you prefer your air hockey a bit more human-scaled, we’ve seen a table build before. We’ve also seen ultrasonic levitation before, ranging from simple electronics kits to the driving force behind a full volumetric display or photography station.
2026-04-28 04:00:44
Springs are great, but making them out of plastic tends to come with some downsides, for fairly obvious reasons. Creating a compliant mechanism that can be 3D printed and yet which doesn’t permanently deform or wear out after a few uses is therefore a bit of a struggle. The complaint toggle mechanism that [neotoy] designed is said to have addressed those issues, with the model available on Printables for anyone to give a shake.
The model in question is a toggle, which is the commonly seen plastic or metal device that clamps down on e.g. rope or cord and requires you to push on it to have it release said clamping force. Normally these use a metal spring inside, but this version is fully 3D printable and thus forms a practical way to test this particular compliant mechanism with a variety of materials.
The internal spring is a printed spiral spring, with the example in the video printed in PETG. You can of course also print it in other materials for different durability and springiness properties. As noted in the video, PLA makes for a very poor spring material, so you probably want to skip that one.
We covered compliant mechanisms in the past for purposes like blasters, including some that you can only see under a microscope.
2026-04-28 02:15:48
When building a project to operate on battery power for long periods of time, having a microcontroller with a reliable and extremely low-power sleep mode is critical. When processing power isn’t needed, it should be able to wait around using almost no energy until an interrupt triggers it. Once triggered, the CPU performs its tasks and then puts itself right back to sleep, making sure the battery lasts as long as possible. Unfortunately, not every microcontroller has sleep capabilities or has an acceptably low level of power use for maximizing battery life. For these systems, a tool like this power manager might come in handy.
The small PCB, called the powerTimer, essentially acts as a middleman for power delivery to another microcontroller. On the PCB is an RV3028-C7 real-time clock, which uses a mere 45 nA of current and can interact with the second microcontroller through a timer or alarm. When commanded, the powerTimer uses an SR latch as its main control circuit, allowing single button presses to change the power state for the second microcontroller. Once the powerTimer powers up the second microcontroller, that microcontroller can communicate back to the powerTimer with a “DONE” signal, and once this signal is received, the powerTimer will cut power and wait for the next interrupt to occur.
The project’s creator, [Juan], had this idea for an ESP32 with a camera module. While it does have a sleep mode, the ESP32 wasn’t nearly low-power enough to get the battery life that he wanted. With a modular system like this, it can be used in many other applications as well. PowerTimer is one of the entries in our 2026 Green Powered Challenge.
2026-04-27 23:30:10
[Shreeyash] asks an interesting question: how many registers does your CPU have? The answer is probably more than you think. The reason? Modern CPUs — at least many of them — execute instructions out of sequence so they can perform multiple instructions per clock cycle. To do this, they may need to execute instructions that change registers that other instructions are still reading. In addition, you might be writing a result speculatively — a branch might make it where your result won’t wind up in the target register. The answer to both of these problems is register renaming.
The ARM CPU he looks at has many physical registers you can’t see. These get mapped to the registers you use on the fly. So when you read a register in software, you are really getting an underlying physical register. Which one? Depends on when you read it.
The RAT, or Register Alias Table, keeps track of the mapping between physical registers and the register names you use. Not only does this allow the CPU to run operations out of order, but it also lets results sit in unnamed physical registers until the time is right for it to become the real register. As a byproduct, moving one register to another becomes fast since you can just copy the alias of one physical register to another logical register.
Not clear? Try reading the post. There are other ways to get the same result (e.g., reservation stations), but the technique goes way back to mainframe computers. While it didn’t appear right away in microprocessors, modern ones often execute out of order and have to have some scheme to address this problem.
If you build your own CPUs with FPGAs, it is possible to do the same trick. There are also RISC-V variants that can do it.
2026-04-27 22:00:58
When it comes to software developers, there are a few distinct types. For example, the extroverted, chatty type, who is always going out there to share the latest and newest libraries and projects with everyone, and is very much into bouncing ideas off others, regardless of whether they know what you’re talking about. Then there is the introverted loner, who prefers to tackle programming challenges by bouncing things around inside their own minds and going on long walks to mull things over before committing to anything significant.
This leads to interesting scenarios when it comes to management-enforced ‘optimization’ strategies, like Pair Programming. This approach involves two developers sharing the same computer and keyboard, theoretically doubling the effective output by some kind of metric, but realistically often leading to at least one side feeling pretty miserable and disconnected unless you put two of the chatty types together.
As a certified introverted loner developer, the idea of using an LLM chatbot as a coding assistant naturally triggers unpleasant flashbacks to hours of forced awkward pair ‘programming’. However, maybe using an LLM chatbot could be more pleasant because you can skip the whole awkward socializing bit. In order to give it a shake, I put together a little experiment to see whether LLM-based coding assistants is something that I could come to appreciate, unlike pair programming.
Any good experimental setup features clear goals and parameters that define what will be tested and what the expectations are. Obviously I come from a somewhat negative angle into this whole experiment, so to make it easy I’ll be picking two fairly straightforward scenarios for the LLM to assist with:
These are topics that I’m fairly familiar and comfortable with, so that I know what questions I have here, and what I’m roughly expecting as output. I’ll be treating the chatbot for the most part as I would use StackOverflow or nag people on IRC, with my main fear being that it’ll be expecting pleasantries from me instead of brutal and cold professionalism. Ideally it’ll be a step above me hurling profanities at a search engine for clearly willfully misunderstanding what I am looking for.
My expectations are that it’ll have some answers for me for the questions I have about how to do certain aspects of the tasks, and may even produce half-way usable code that I can fairly easily understand and double-check using my usual documentation references.
This just leaves one big question, being which LLM chatbot to pick and how the heck any of it is supposed to work, since I have avoided the things like the proverbial plague.
Although I am aware that everyone who is into using LLM-assisted programming seem to like to promote LLMs like Claude, I’d ideally not be signing up to another service. This pretty much just leaves GitHub Copilot, which I have access to already. I have written about this particular LLM chatbot quite a bit since it was introduced, with my generally negative feelings towards these tools increasingly backed up by research.
Biased I may be, but to be a true scientist you have to be able to set aside your biases for an experiment and accept reality in the face of new evidence. Thus, with all biases and doubts firmly pushed aside in favor of the aforementioned cold professionalism, let’s get down to brass tacks.
My pet project for STM32-related programming has for a while been my Nodate project, involving the use of the CMSIS standard headers and the macros defined therein in order to write things ranging from start-up to running the Dhrystone benchmark and deciphering the various flavors of real-time clocks.
Much of this work entails digging through datasheets, reference manuals and piles of reference code, as well as throwing queries at search engines to see what potentially useful results percolate out of that particular resource. Coming across the trials and tribulations of fellow STM32 developers in forum threads and the like can be both heartening and disheartening, but all of it tends to condense into something that you can use to progress in the project.
Perhaps ironically, the moment that I tried to use the chatbot in the browser I got an error with the GitHub status page indicating that some of their systems are down, including those for Copilot.
This raises another interesting point: regardless of whether an LLM chatbot makes for a good programming partner, a human partner doesn’t generally randomly keel over or become unresponsive in the midst of trying to do some work together. If they do, however, that’s absolutely a medical emergency and you should call 911, 112, or your local equivalent emergency number stat.
Anyway, after waiting for services to be restored, I was eventually able to ask the chatbot how to properly set the clock speed on an STM32F411 MCU, after getting tripped up previously by the need to set the regulator voltage scaling (VOS) in the power control register (PWR_CR). This is a power saving feature whose adjusting is required for hitting specific and clearly power-wasting clocks.
Shockingly, the chatbot happily spits out ST HAL code and ignores the ‘CMSIS’ bit, although you could maybe argue that the ST HAL uses CMSIS inside. But then so does Arduino code for many MCUs.
To its credit, it does mention in a ‘Key CMSIS Requirements’ list that you need to set PWR_REGULATOR_VOLTAGE_SCALE1 yet without further detail on where to set it. There is also the tiny detail that this isn’t even the CMSIS macro, which would be PWR_CR_VOS to set both bits for the full range.
Fortunately we can do the digital equivalent of smacking the chatbot upside the head and tell it to do the thing we asked it to do. This being to provide the real CMSIS version. Doing so results in another gobsmacking moment when it happily spits out code that doesn’t bother to include the CMSIS headers, but simply copies every single used struct definition and more into the code as well, bloating it up massively:
This is of course very annoying when it should have used #define macros, and it clearly can generate include statements based on its inclusion of <cstdint>, but the absolutely deadly sin here is that his code isn’t even functional for an STM32F411, as can be observed here:
I’m not entirely sure where it got the PWR_CR_VOS_SCALE1 thing from, with asking a friendly search engine leading to just a handful of results, one of which is for an STM32F407 that runs at 168 MHz max. This is hilarious in light of the comments right above the code. It makes you wonder what example code it pilfered from.
At this point I could probably continue to pick at this generated code, but suffice it to say that my confidence level in its generated code and overall output hovers somewhere between ‘low’ and ‘bottom of a black hole’. I’m more than happy to flip this particular table, rage quit, and not lose what remains of my sanity.
Although I had intended to also do some fun porting to Ada together with my buddy Copilot of some C++ networking code in my NymphRPC remote procedure call library, I found my nerves to be sufficiently frayed and the bouts of near-hysterical laughter out of sheer disbelief worrisome enough to abort this attempt.
I also do not feel that it’d do much more than hammer home the point that GitHub Copilot at the very least doesn’t make for a good pair programming partner, nor as a programming tool, or a search engine, or much of anything. When the only thing that it got me was having to check its output for very obvious errors and shaking my head in disbelief when I found them, it beggars belief that anyone would voluntarily use it.
When we also got reports that the use of such LLM chatbots are likely to degrade human cognition and critical thinking skills, not to mention the worrisome prospect of cognitive surrender, then it’s probably best to avoid these chatbots altogether.
I also agree generally with Advait Sarkar et al. in their 2022 paper that you cannot really do pair programming as-such with an LLM chatbot, but that it offers something different. Something that’s very different from using a search engine and digesting various articles and forum posts along with reference material into something new.
Thus, after using an LLM chatbot for some coding ‘assistance’ I’ll be happily scurrying back to my boring references and yelling invectives at search engines.
