2026-04-02 04:00:11
Batteries are notoriously difficult pieces of technology to deal with reliably. They often need specific temperatures, charge rates, can’t tolerate physical shocks or damage, and can fail catastrophically if all of their finicky needs aren’t met. And, adding insult to injury, for many chemistries, the voltage does not correlate to state of charge in meaningful ways. Battery testers take many efforts to mitigate these challenges, but often miss the mark for those who need high fidelity in their measurements. For that reason, [LiamTronix] built their own.
The main problem with the cheaper battery testers, at least for [LiamTronix]’s use cases, is that he has plenty of batteries that are too large to practically test on the low-current devices, or which have internal battery management systems (BMS) which can’t connect to these testers. The first circuit he built to help solve these issues is based on a shunt resistor, which lets a smaller IC chip monitor a much larger current by looking at voltage drop across a resistor with a small resistance value. The Pi uses a Python script which monitors the current draw over the course of the test and outputs the result on a handy graph.
This circuit worked well enough for smaller batteries, but for his larger batteries like the 72V one he built for his electric tractor, these methods could draw far too much power to be safe. So from there he built a much more robust circuit which uses four MOSFETs as part of four constant current sources to sink and measure the current from the battery. A Pi Zero monitors the voltage and current from the battery, and also turns on some fans pointed at the MOSFETs’ heat sink to keep them from overheating. The system can be configured to work for different batteries and different current draw rates, making it much more capable than anything off the shelf.
2026-04-02 02:30:32
We’ve seen our fair share of audiophile tomfoolery here at Hackaday, and we’ve even poked fun at a few of them over the years. Perhaps one of the most outrageously over the top that we’ve so far seen comes from [Pierogi Engineering] who, we’ll grant you not in a spirit of audiophile expectation, has made a set of speaker interconnects using liquid mercury.
In terms of construction they’re transparent tubes filled with mercury and capped off with 4 mm plugs as you might expect. We hear them compared with copper cables and from where we’re sitting we can’t tell any difference, but as we’ve said in the past, the only metrics that matter in this field come from an audio analyzer.
But that’s not what we take away from the video below the break. Being honest for a minute, there was a discussion among Hackaday editors as to whether or not we should feature this story. He’s handling significant quantities of mercury, and it’s probably not over reacting to express concerns about his procedures. We wouldn’t handle mercury like that, and we’d suggest that unless you want to turn your home into a Superfund site, you shouldn’t either. But now someone has, so at lease there’s no need for anyone else to answer the question as to whether mercury makes a good interconnect.
2026-04-02 01:00:35
There’s a great debate these days about what the current crop of AI chatbots should and shouldn’t do for you. We aren’t wise enough to know the answer, but we were interested in hearing what is, apparently, Microsoft’s take on it. Looking at their terms of service for Copilot, we read in the original bold:
Copilot is for entertainment purposes only. It can make mistakes, and it may not work as intended. Don’t rely on Copilot for important advice. Use Copilot at your own risk.
While that’s good advice, we are pretty sure we’ve seen people use LLMs, including Copilot, for decidedly non-entertaining tasks. But, at least for now, if you are using Copilot for non-entertainment purposes, you are violating the terms of service.
While we know how it is when lawyers get involved in anything, we can’t help but think this is simply a hedge so that when Copilot gives you the wrong directions or a recipe for cake that uses bleach, they can say, “We told you not to use this for anything.”
It reminds us of the Prohibition-era product called a grape block. It featured a stern warning on the label that said: “Warning. Do not place product in one quart of water in a cool, dark place for more than two weeks, or else an illegal alcoholic beverage will result.” That doesn’t fool anyone.
We get it. They are just covering their… bases. When you do something stupid based on output from Copilot, they can say, “Oh, yeah, that was just for entertainment.” But they know what you are doing, and they even encourage it. Heck, they’re doing it themselves. Would it stand up in court? We don’t know.
Now it is true that probably everyone will give you a similar warning. OpenAI, for example, has this to say:
- Output may not always be accurate. You should not rely on Output from our Services as a sole source of truth or factual information, or as a substitute for professional advice.
- You must evaluate Output for accuracy and appropriateness for your use case, including using human review as appropriate, before using or sharing Output from the Services.
- You must not use any Output relating to a person for any purpose that could have a legal or material impact on that person, such as making credit, educational, employment, housing, insurance, legal, medical, or other important decisions about them.
- Our Services may provide incomplete, incorrect, or offensive Output that does not represent OpenAI’s views. If Output references any third party products or services, it doesn’t mean the third party endorses or is affiliated with OpenAI.
Notice that it doesn’t pretend you are only using it for a chuckle. Anthropic has even more wording, but still stops short of pretending to be a party game. Copilot, on the other hand, is for fun.
How about you? Do you use any of the LLMs for anything other than “entertainment?” If you do, how do you validate the responses you get?
When things do go wrong, who should be liable? There have been court cases where LLM companies have been sued for everything, ranging from users committing suicide to defaming people. Are the companies behind these tools responsible? Should they be?
Let us know what you think in the comments.
2026-04-01 23:30:03
Although the jogging stroller is a fixture of suburban life, allowing parents the opportunity to get some exercise while letting their young children a chance for some fresh air, it would seem like the designers of these strollers have never actually gone for a jog. Requiring a runner to hold their hands at fixed positions can be incredibly uncomfortable and disrupts most people’s strides and cadence — so [John] attempted to solve the problem after finding one of these strollers on the secondhand market.
While there are some purpose-built strollers that attempt to address these issues, they can be pricey. Rather than shell out for a top-dollar model, [John] got to work with his 3D printer and created a prototype device that allows him to attach the stroller at his waist while leaving his hands free. There were a few problems to overcome here, the first of which would cause the device to buckle under certain loading situations. This was solved with some small pieces of rope which act as flexible bump stops, keeping the hinge mechanism from binding up. Another needed to be solved with practice, which was that it took some time to be able to steer the stroller without using one’s hands.
As an added bonus, [John] also included a system that tracks the distance the stroller has traveled. Using a hall effect sensor and a magnet attached to the wheel, a small microcontroller is able to quickly calculate distance and display it on a tiny screen mounted near the handlebars. Although smartphones are handy, their GPS systems can be surprisingly inaccurate, so a system like this can be a better indicator since it’s being directly measured. All in all, not a bad few upgrades to a secondhand stroller.
2026-04-01 22:00:29
Nothing ever made is truly perfect and indeed, CPU architectures like x86, RISC-V, ARM, and PowerPC all have their own upsides and downsides. Today, I aim to make an architecture that learns from all these mistakes and improves architecture design for everyone.
I’ve consulted with many people opinionated on the matter, both from a software perspective, and from a hardware perspective. I have taken all their feedback in mind while creating this initial draft of the WheatForce architecture (PDF). It is inspired by pieces from many architectures: segmentation inspired by x86, hash table-like paging from PowerPC, dynamic endianness control from RISC-V and PowerPC, and more. Let’s look into each feature in a little bit more detail.
PowerPC’s hash table-like paging makes its paging vastly superior to the likes of x86, RISC-V and ARM by decreasing the number of required cache line fetches drastically. Much like a true hash table, the keys (or input addresses) are hashed and then used as an index into the table. From there, that row of the table is searched for a cell with a matching virtual address, which can be accelerated greatly due to superior cache locality of the entries in this row.
RISC-V and PowerPC both have some real potential for better compatibility with their dynamic endianness control. However, both these architectures can only change the endiannes from a privileged context. To make this more flexible, WheatForce can change the data endianness at any time with a simple instruction. Now, user software can directly interoperate between big-endian and little-endian data structures, eliminating the need for a costly byte-swap sequence that would need many instructions. Finally, you can have your cake and eat it to!
WheatForce has observed the mistakes of all architectures before it, and integrates parts of all its predecessors. You can read the full specification on GitHub. After you’ve read it, do let me know what you think of it.
2026-04-01 19:00:38
Some projects need no complicated use case to justify their development, and so it was with [Janne]’s BeamInk, which mashes a Wacom pen tablet with an xTool F1 laser engraver with the help of a little digital glue. For what purpose? So one can use a digital pen to draw with a laser in real time, of course!
Here’s how it works: a Python script grabs events from a USB drawing tablet via evdev (the Linux kernel’s event device, which allows user programs to read raw device events), scales the tablet size to the laser’s working area, and turns pen events into a stream of laser power and movement G-code. The result? Draw on tablet, receive laser engraving.
It’s a playful project, but it also exists as a highly modular concept that can be adapted to different uses. If you’re looking at this and sensing a visit from the Good Ideas Fairy, check out the GitHub repository for more technical details plus tips for adapting it to other hardware.
We’re reminded of past projects like a laser cutter with Etch-a-Sketch controls as well as an attempt to turn pen marks into laser cuts, but something about using a drawing tablet for real-time laser control makes this stand on its own.
