Although it’s commonly suspected that migratory birds fly in a ‘V’ formation due to this saving energy for the birds in the slipstream, understanding the exact aerodynamics behind this and how it affects the way that the birds use their wings to maintain this optimal pattern. After all, unlike airplanes and cars, our feathered avian dinosaur friends need to flap their wings if they want to have any chance of staving off plummeting back to Earth. Recent research by Brown University researchers now have provided a simulated model that answers many questions.
The major question was how this would work in the up- and down-wash zones created in this type of formation, with every bird following the lead bird dealing with the vortices created by the flapping of the wings of the bird before them. These wake vortices are quite complex, and thus required careful modelling to make sense of them.
As described in the paper by [Olivia Pomerenk] et al., the model is based on northern bald ibises, taking into account live-bird measurements for validation of the model. The main effect that can be observed is a reduced flapping amplitude, leading to an 11% energy savings for the birds in the leader’s wake.
The main advantage of having such a model is of course that it provides insight into the kinematic and aerodynamic mechanisms, meaning the ability to model virtual flocks of birds, predict the efficiency of specific in-flight configurations, and apply the lessons to swarms of drones, or whatever else we want to put in the air.
Have you ever been looking up a recipe for something new and been stymied by the directions being a wall of text, especially to find that one detail right when you’re in the middle of making the dish? Recipe Lanes by [bohemian-miser] leverages an LLM to create flow charts to make the process more straightforward.
As someone who has mostly avoided LLM use thus far, I found the examples in the Gallery helped inform what the LLM was expecting for prompts as my first attempts were unsuccessful. Once you know the language expected from the computer, you can get it to generate icons for each ingredient and a flow chart of the steps to cook the food. While it does organize the chart when it is generated, each element can be independently moved across the canvas to put things in a more sensible order, especially as I found it can generate elements with overlapping text.
The 8-bit icon style and button text on the site give it a fun bit of flair that adds to the overall experience. The tool is still in its infancy, but it’s Open Source, so we hope to see it improve over time. If you’d like to see some more interesting kitchen hacks, how about ramen in edible packaging, this rotary phone kitchen timer, or these automated Arduino splash guards.
This week Jonathan chats with Michael Meeks about Collabora! What’s the origin story in this consulting company, why do they have an outstanding office suite, and where is the world headed to accomplish digital sovereignty? Watch to find 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.
Car enthusiasts want to know how quickly they can make a quarter mile. Weightlifters are forever trying to add one more plate to the bar. Internet denizens have their own favorite number to brag about: the result from a speed test.
The ritual is familiar. Close a few browser tabs, click the big “Go” button, and watch the needle climb. Perhaps you pay for gigabit service and see 940 megabits per second, which produces a satisfied nod. Perhaps you see 299 megabits and begin obsessing over network hardware. But before you get too excited either way, try another test. There is a fair chance it will give you a different answer.
That does not necessarily mean one test is lying. “Internet speed” is not a single physical quantity waiting to be measured. A speed test measures the performance of a particular device, over a particular local connection, through a particular ISP route, to a particular server, at a particular time using a particular test method. Change any of those things and the answer can change too.
The Usual Suspects
Ookla on a WiFi connection to a 1Gbit Ethernet network. The limiting factor is the 802.11s WiFi link between the computer’s Ethernet port and the router’s.
Speedtest by Ookla is probably the best-known test. It selects a nearby server, although you can choose another. It attempts to saturate the connection with multiple simultaneous transfers. That makes it good at answering the question most consumers are asking: approximately how much aggregate bandwidth can this Internet connection deliver?
Running several connections matters. A single TCP connection must gradually increase its sending rate while reacting to round-trip time, packet loss, receive-window limits, and congestion-control behavior. On a high-bandwidth or high-latency path, one connection may not fill the available pipe. Several parallel connections can ramp up independently and make it easier to reach the link’s aggregate capacity. That number is valid, but it represents something like a busy household, a large segmented download, or several applications operating at once. It does not necessarily predict the speed of one file transfer from one distant server.
Google’s built-in search speed test (search “speed test”) uses Measurement Lab’s Network Diagnostic Tool, or NDT. M-Lab describes NDT as a single-stream measurement of bulk-transport capacity. That makes it an interesting counterpoint to Ookla. A single flow may expose latency, loss, or TCP-window limitations that a multi-stream test can partially conceal. You can also use M-Lab’s own speed test directly.
While you may get similar numbers between the two approaches, you also may not get similar numbers, especially on high-latency connections where Ookla’s multiple streams will help hide latency.
Netflix’s Fast.com is deliberately simple. Open the page, and it immediately begins transferring data from Netflix infrastructure. By default it emphasizes download performance, since its original purpose was to answer a practical question: can this connection deliver Netflix video properly? Selecting “Show more info” adds upload speed and both unloaded and loaded latency.
Fast is barebones and measures speed to Netflix.
The use of Netflix servers is significant. Fast.com measures the route between you and Netflix’s content-delivery network, while Ookla may test against a server operated by your ISP only a few network hops away. A superb Ookla result and a poor Fast.com result do not prove deliberate throttling, but they do tell you that the destinations — or the routes to them — are behaving differently.
Cloudflare offers two related tests. Its Radar Network Quality Test provides a quick summary, while speed.cloudflare.com gives an extremely detailed breakdown. The latter reports download and upload throughput, idle and loaded latency, jitter, packet loss, server location, and application-oriented quality estimates.
Cloudflare provides a wealth of stats and graphs.
Loaded latency is especially useful. An otherwise fast connection can become miserable when a large upload or download fills an oversized queue in the modem or router. Your idle ping might be 12 milliseconds, but under load it may jump to several hundred milliseconds. That is the classic symptom usually called bufferbloat.
If you want more options, there is testmy.net, which allows you to test upload and download speeds separately, and speedof.me, which keeps a history for you, among others. It isn’t always obvious which ones are measuring a single connection vs multiple ones, so you may have to dig through whatever documentation you can find.
Your WiFi Is Part of the Test
A browser speed test cannot automatically tell you what’s hurting your speed. A laptop connected through marginal WiFi may report 180 megabits per second even though the router has a flawless gigabit Internet connection.
In fact, once incoming Internet service reaches several hundred megabits per second, WiFi is frequently the limiting factor. The link rate displayed by the operating system is not the same thing as usable throughput. Wireless protocols have framing overhead, acknowledgments, contention, retransmissions, and half-duplex operation. The advertised 866, 1200, or 2400 megabit link rate is therefore not a promise that application data will move at that rate.
The numbers printed on WiFi boxes add another layer of optimism. A router sold as “AC1800,” for example, does not provide an 1800-megabit connection to one device. The figure is normally the sum of the maximum advertised PHY rates on separate radios — perhaps 1300 Mb/s on 5 GHz plus 450 Mb/s on 2.4 GHz — with some rounding for marketing. A conventional WiFi client connects to one band at a time, so it cannot combine those rates. The total is better understood as the router’s theoretical aggregate capacity while serving multiple devices across both bands. Even then, protocol overhead, contention, signal quality, and client limitations make actual data throughput considerably lower. Newer WiFi 7 equipment can sometimes combine links using Multi-Link Operation, but that exception does not make the old ACxxxx arithmetic any less misleading.
WiFi also uses shared airtime. Devices on the same channel — including neighboring access points that can hear one another — must contend for opportunities to transmit. A slow or distant client takes longer to send a given amount of data and can consume disproportionate airtime while doing so. Modern access points may provide airtime fairness and other mitigations. One old device does not invariably drag every client down to its rate, but it can still reduce the capacity available to the rest of the network. Interference has a similar effect. A weak signal, a crowded channel, microwave noise, or an overlapping neighboring network causes frames to be delayed or retransmitted. Those retries consume airtime without delivering additional data.
Repeaters and wireless mesh backhaul add another complication. A simple same-channel repeater must receive each packet and then transmit it again over the same shared medium. In the worst case, each repeated hop can roughly halve the available throughput. Modern tri-band mesh systems can avoid much of that penalty by using a dedicated backhaul radio, and Ethernet backhaul avoids it almost entirely.
This means it is entirely reasonable to buy gigabit Internet service and obtain only 300 or 500 megabits per second from a WiFi laptop. Whether that represents a problem depends on the client, radio band, channel width, signal level, backhaul, and local RF environment.
For a meaningful ISP test, begin with a computer connected directly to the router by Ethernet. Stop large transfers and temporarily disable any VPN. Record the chosen server, latency, upload speed, and download speed rather than preserving only the most flattering number. Then run the same tests over WiFi. The difference is an approximate measurement of what the wireless portion of the network is costing you.
Remove the Internet From the Experiment
OpenSpeedTest running on an OpenWRT node.
Better still, remove the ISP from the test completely. OpenSpeedTest is a self-hostable, browser-based test. Run its server on a wired computer, NAS, or container, then visit it from laptops, phones, and tablets around the house. Because the traffic remains on your LAN, a slow result points toward WiFi, switching, cabling, or the client rather than the Internet connection.
It is possible to run this on the uhttpd server used with OpenWRT, although you’ll need to coax it to measure upload speeds since the server can’t handle the default method. The trick is to create a CGI script that accepts a large amount of data successfully and then configure uhttpd to run that.
A browser-based local test is convenient, but for serious diagnosis it is hard to beat iperf3, the client/server tool we recently used while testing mesh routers. On one machine (say, 192.168.1.100), start the server:
iperf3 -s
From another machine, run:
iperf3 -c 192.168.1.100
By default, iperf3 uses one TCP connection. Add -P 4 to try four parallel streams, or -R to reverse the direction so that the server sends and the client receives. Those variations can tell you something. If four streams are much faster than one, the network may have enough aggregate capacity but a single TCP flow is being limited by latency, loss, window growth, CPU performance, or offload behavior. If the reverse test is much faster, examine the weaker machine’s transmit path, drivers, antennas, or CPU.
iperf3 can also generate UDP traffic at a specified rate and report packet loss and jitter. That is often more informative for evaluating a wireless link than merely chasing the largest TCP number.
Can Linux Make It Faster?
Linux offers an impressive array of network tuning knobs, which naturally tempts us to turn them. But first, you need to understand what needs tweaking.
Check the negotiated Ethernet rate and interface counters:
ethtool eth0
ip -s link show eth0
A gigabit adapter that has negotiated 100 megabits per second usually has a cabling, connector, or switch-port problem. Increasing TCP buffers will not repair it. Rising interface errors and drops point toward a physical, driver, or congestion problem. TCP retransmits (view with ss -ti) may indicate loss elsewhere on the path.
You can inspect the active queue discipline with:
tc qdisc show
Linux supports queue disciplines such as fq_codel, which combines per-flow queueing with active queue management. It attempts to prevent one large transfer from building an enormous queue and delaying unrelated interactive packets. The kernel documentation specifically lists fq_codel as a sensible queue discipline that works without extensive configuration.
It can be selected as the default for newly created interfaces with:
sudo sysctl -w net.core.default_qdisc=fq_codel
That may improve queueing on traffic leaving the Linux machine. It does not, however, fix a large queue in the cable modem or Internet router. Queue management must be applied at the bottleneck. If the ISP link is limited to 20 megabits upstream, controlling a queue on a gigabit Ethernet interface after it has already handed packets to the router is too late.
For a home connection, the most effective bufferbloat treatment is usually Smart Queue Management on the router. OpenWrt’s SQM system supports both fq_codel and CAKE. CAKE generally provides better performance. However, fq_codel requires less CPU overhead.
High-latency paths introduce a different problem. TCP must keep enough data in flight to fill the bandwidth-delay product. Modern Linux generally autotunes TCP buffers, so the old advice to assign enormous fixed values to tcp_rmem and tcp_wmem is less universally useful than it once was. Before changing them, use ss -ti during a transfer and look for retransmissions, round-trip time, congestion-window size, and whether the receiver window is actually limiting the connection.
Linux also supports selectable TCP congestion-control algorithms:
Algorithms such as BBR can improve throughput and queue behavior on some long-distance or lossy paths. But changing the algorithm affects connections sent by that Linux machine; it does not control the remote speed-test server, repair poor WiFi, or eliminate a queue in the router. Congestion-control tuning is therefore a useful experiment for a server, VPN endpoint, or long-haul transfer machine — not a universal solution to slow networking.
Finally, inspect hardware offload features when a Linux system cannot keep up with a fast LAN:
The lesson here is that there is no universally correct speed-test result. Ookla tests how effectively multiple transfers can fill a route to one of its servers. M-Lab examines a single bulk flow. Fast.com tests the path to Netflix. Cloudflare pays unusual attention to latency under load and overall connection quality. OpenSpeedTest and iperf3 can determine whether the Internet connection is even the problem.
Run enough tests, and you will eventually obtain a number worth bragging about. Run the right tests, though, and you may find ways to truly increase real-world performance. If you want to chase that extra 1 kbit per second speed, be our guest — we know how it is. But the truth is that if the Internet is doing what you want it to do, then it is fast enough.
The combination of hardware required to make use of this project is specific enough that we imagine only a relatively limited number of readers will actually be able to try it out. But if you do happen to own a YubiKey and either a laser engraver capable of marking it or a fancy UV printer, [madeinoz67] has put together an awesome tool for adding some visual flair to your two-factor authentication device.
Running it is as simple as opening a web page, because that’s exactly how it’s implemented. You can either host it yourself or just launch it right from the GitHub repository. After opening the HTML file, you’re presented with a fairly intuitive user interface that lets you draw on top of a 2D outline of the YubiKey itself so you can get a better idea of what the final product will look like.
You can pick from an array of vector icons, upload your own images, and add custom text. There’s a pull-down at the top that lets you pick which specific YubiKey you want to work with, and there are different views depending on whether you plan on blasting your handiwork onto the device with a laser, doing a full-color UV print, or cutting it out of vinyl with something like a Cricut.
Even if you don’t have a YubiKey that’s begging for some custom artwork, we think there’s a lot to learn from this project. Obviously there are some very valid reasons to be concerned about how much of our modern software can only be accessed through a browser. If you’re going to use web technologies to create a piece of software, the least you could do is make it offline and self-contained like [madeinoz67] has.
In a recent post, I mentioned that I wanted to build some tools for a stripped-down Linux running on a 3D printer with a MIPS CPU. I had two options: build a toolchain to cross-compile, or use Zig, which, in theory, has built-in toolchains for MIPS. I had to jump through hoops to get Zig to work, and I did mention Crosstool-Ng, so you might wonder why I didn’t start there. Turns out, it had its own set of hoops to work through.
What is Crosstool-Ng?
Crosstool-NG is a build system for making cross-compilation toolchains: compilers, assemblers, linkers, C libraries, kernel headers, and all the other pieces needed to build software on one machine that will run on a different kind of machine. Instead of manually matching a particular GCC version with the right binutils, glibc, or musl release, Linux headers, patches, and configuration options, you select the target architecture and let Crosstool-NG download, patch, configure, and build the stack. The result is a self-contained toolchain with commands such as mipsel-linux-musl-gcc or arm-none-eabi-gcc, ready to produce binaries for the target system.
Stock? Zig? Crosstool-Ng? No way to tell from this picture.
The four-part name is in a particular format that is often used in the cross compiling world. For example, consider arm-none-eabi-gcc. The tool here is gcc and, as you might expect, there will also be arm-none-eabi-as and arm-none-eabi-ld, among other things. The first part, arm in this case, will be the target architecture.
The second part of the name can mean a few different things. In theory, it is a vendor name but it is sometimes “none” which often means “generic” or, in the case of a linux target, “linux,” which isn’t technically a vendor.
The third part is the calling convention and, often, some idea of the library. For example, arm-linux-gnueabihf-gcc would mean the GNU library using the ARM EABI and hardware floating point. These are sometimes called “target triples” because, historically, it was CPU-VENDOR-OS, but now there are usually four or even five parts if the calling convention includes the OS, like linux-musl, for example.
That sounds simple, but cross-toolchains are unusually sensitive to version combinations and ABI details. Endianness, floating-point conventions, instruction-set variants, threading support, and C library choices all have to agree. So saying “Arm” or “MIPS” doesn’t mean much. You need to account for all the possible variations in the CPU and the libraries. Crosstool-NG does not eliminate those decisions, but it turns them into a reproducible configuration rather than a long sequence of hand-built components. I had two problems that I eventually resolved.
Problem One: Versions
One nice thing about Crosstool-Ng is that it pulls the right versions of everything for you. The problem is, when you install it from your system repositories, you are probably getting a crazy old version of the tool itself. I couldn’t find the right entries in the configuration when I did that, so I eventually uninstalled and picked up the latest version right from the source.
If that was the only problem, I would have been lucky.
Problem Two: Infinite Combinations
The CPU on the printer is an odd bird. As I noted last time, the executables use the r2 instruction set but also use the nan2008 convention which is usually found in r6. While Crosstool-Ng is good at letting you specify exactly what you want, it isn’t always clear on how you specify every detail.
To be fair, just like with Zig, some of that may be on me. I don’t use Crosstool-Ng or Zig every day, so maybe I was making either or both of them too hard. The bad news: It took me three or four attempts to get the right toolchain. The good news: It was a lot easier than manually downloading a bunch of stuff, trying to fix it up, building it, and still having to do it three or four times.
Configuration
Most, but not all, of the necessary changes were here.
Sort of like buysbox or building a custom kernel, the configuration for Crosstool-Ng uses the command: ct-ng menuconfig. This gives you a menu where you can set options about what you want and where you want it stored.
The problem is that the nan2008 setting I needed isn’t part of a standard mips32r2 setup. I suspect that if I had needed mips32r6, everything would have just worked. But, of course, I’m not that lucky.
In the target settings, I needed to match all the specifications, of course, but I also needed to add -mnan=2008 to both the CFLAGS and LDFLAGS as you can see in the figure.
So what’s so hard about that? Just those changes won’t produce a working toolchain for my printer. The C compiler also needed --with-nan2008 (in the C Compiler options screen under extra target CFLAGS) and the same option needed to be placed in the C Library screen, too.
Of course, it is like a word search puzzle. Once you see the answers, they look obvious. But when you are searching through pages of options, it is easy to miss one. It isn’t like there is a checkbox for “Use nan2008” that does it all for you because using nan2008 with mips32r2 is “strange.”
The Proof is in the Build
Once everything was set correctly, I was able to produce a toolchain (ct-ng build) that could compile busybox and even a small text editor. Everything ran fine on the printer.
To build busybox, I used:
make V=1 CC="mipsel-unknown-linux-musl-gcc -march=mips32r2 -msoft-float -static -Os" STRIP='mipsel-unknown-linux-musl-strip' -j6
Unlike Zig, no patching needed. The Zig version was about 9 kB larger than this version, so not much different there. Both were just over a megabyte total. I could probably have used hardware floating point to get a smaller executable, but given that I don’t think any of this is using much floating point at all, it didn’t seem to matter very much.
I had also threatened to compile a text editor. Turns out most have dependencies on things like ncurses, which are a pain to bundle. So I grabbed a copy of the tutorial editor kilo and extended it to look a little like emacs. Works great. Great place to start if you need a static editor that doesn’t take much space.
Lesson Learned
If the CPU on the printer had been more conventional, I think either approach would have worked fine. I prefer the Crosstool solution in this case, because I’m not lying by patching the ELF header. In this case, I don’t think that lie hurts anything, but a program that did a lot of floating-point math might not work correctly, whereas I think the one produced by Crosstool would be fine even for a floating-point program.
On the other hand, like most Unix and Linux things, there are always more ways to solve any problem. If your problem is wedging executables on an alien Linux box, there are two perfectly fine ways to solve it.
Just because you probably shouldn’t make a DIY X-ray machine, doesn’t mean nobody would. [mircemk] shows off his DIY unit, how it works, how to use it safely and of course, some pretty X-ray photos of household objects.
The machine repurposes a DY86 vacuum tube from old CRT TVs to emit X-ray radiation. To drive the tube without blowing it up, a rather specialized series of power supplies is needed; a low-voltage DC power supply powers a high-voltage AC inverter, which is then sent through first a transformer, and then a Crockfort-Walton voltage multiplier, to reach the incredibly high voltages needed for such a vacuum tube’s radiation emission to reach X-rays. Naturally, this didn’t go to plan first try, leading to the unfortunate demise of three vacuum tubes (as well as another three which had already lost their vacuums).
Now how do you capture an image with X-rays for a light source? With dental X-ray photo films of course! The dental film is placed behind the object to be scanned, the transmitted X-rays making up the resulting image. After going through the standard process of developing for about 30s, washing, fixing for about half an hour, and washing again, the photos become clearly visible. The best results were obtained at a distance of 10-15 cm an an exposure time varying from 15 minutes to an hour depending on material hardness.
At least in theory, video games are more resistant to becoming lost media thanks to their digital nature — they’re easy to copy and emulators have saved many titles that are otherwise locked in corporate vaults. But emulators give us something beyond simple preservation: they can also be used to enhance games well beyond the capabilities of the original systems while still preserving the souls of the games, as this NES emulator manages to do.
The emulator is called Anemoia-ESP32, and as its name suggests is a re-write of the Anemoia emulator specifically built for the ESP32. By modern standards these little chips don’t pack much of a punch, but compared to original NES hardware they’re more than up to the task of gaming. This project aims to recreate the Nintendo Entertainment System experience as faithfully as possible, hitting 60 FPS in most instances, as well as maintaining full audio emulation. Running on an ESP32 enables some truly small handheld options that would be difficult to achieve with more traditional platforms for emulation. There are some PCBs available here as well, but aren’t required to explore this project with.
As far as extra features compared to original NES hardware, the emulator does support save states and has a number of other settings improvements. Installation is as easy as flashing any other firmware image onto an ESP32, which these days can even be done from the browser. No word on whether or not it will eventually support emulating dual Picture Processing Units, but we can hope.
As predominantly indoor creatures, it’s important to maintain a healthy habitat for the hacker. [Kishan Pratap Singh] designed a clever solution in AirSense, an ESP32-powered air filter.
If you’re thinking of cleaning the air in your environment, you might also want to know some properties about the air coming out of the filter. AirSense measures PM2.5 dust concentration, Air Quality Index (AQI), temperature, humidity, and atmospheric pressure. The various sensors are mounted along the exhaust path of the filter, which lets your know what kind of air it’s pumping out.
The system drives a 150 mm exhaust fan mounted in a 3D printed cap that pulls air through a cylindrical Xiaomi HEPA filter inside a perforated metal trash can enclosure. The ESP32 and an LCD readout of the environmental data also live in the cap, giving the device a sleek look. While [Singh] chose to run the filter continuously, we wonder if it might be interesting to set it up to only filter the air if air quality drops below a certain level to conserve power, especially if you’re on a time-of-use power plan. That would require redesigning the sensor assembly (or running the unit in reverse), so maybe it’s over-complicating things?
As more and more of the technology that we paid for turns becomes a subscription, there’s slowly been a momentum shift in the open source world of building replacements for these intrusive rent-seekers. We see this all of the time for self-hosted media and communications servers, but now we’re starting to see it in hardware as well. The OOMWOO robotic vacuum cleaner is completely open source, from hardware to software, and requires no cloud services whatsoever.
Although it’s open source, not every component is something one could buy off the shelf. It does require a 3D printer for most of the parts, but assuming that requirement is met most of the rest of the build comes together easily enough. For compute it relies on a Raspberry Pi running ROS 2 software and is set up to integrate easily with other existing open tools and projects such as Home Assistant. Like its proprietary cousins it can sense and map the rooms its placed in, but this platform uses an inexpensive 2D lidar system to keep costs down.
Right now the project is not quite complete, so we’ll all have to keep our eyes on this one as the team building it progresses. But they do have most of the software development done and the bill-of-materials is in progress. As an open project it’s being developed by many volunteers and there are a lot of areas available to contribute to as well, all currently set up on the project’s GitHub page. Right now many of those areas of effort are adapting the 3D printer files to off-the-shelf parts.
One of the biggest “David versus Goliath” stories in tech right now is the towns beset by AI data center projects they may or may not have asked for. Powered By Who is tracking data center development in the US on this convenient map.
Currently, there are over 2,100 data centers being tracked by the project ranging from proposals to sites fully up-and-running. While you have to build bypasses data centers to keep the internet running (which we’re partial to here at Hackaday), there are certainly questions around the amount of power and water consumed by these sites, the emissions they’re sending into the surrounding community, and who exactly is reaping the benefits.
Whether you’re pro, against, or ambivalent about the proliferation of “AI” data centers, the map offers an engaging way to look at what projects are happening around the nation, especially when you start looking at clusters and how that interacts with the power generation and political makeup in a region. It’s particularly interesting how only three states account for roughly 70% of all the projects. Let us know if there’s a similar tracker in your area if you’re from one of the other parts of the globe!
Sometimes that retro gaming itch strikes, and you just have to source components for a Pentium 4 build, like [Computer Retro Bus] did recently. Unfortunately, along the way he learned that you can actually get counterfeit mainboards. Case in point the purported ‘Asrock P4i45GV’ that was purchased as the core of this Pentium 4 build, which turned out to have many issues that included a fake AGP slot.
The mainboard was bought off Facebook Marketplace, with the first sign of trouble being spotty GPU support for the AGP slot, and an inability to install a driver for a card that seemed to work. Following this, issues with the installed Soundblaster soundcard popped up, with the use of Windows ME as OS being of course a factor, but even ME is generally not this sketchy.
Warning on fake AGP slot on genuine Asrock mainboard. (Credit: The Retro Web)
At some point he decided to actually dig into this Socket 478 mainboard that he had purchased, only to find out that there was a reason why there were no real markings on it. After an image search it turned out to be a clone of the aforementioned Asrock mainboard, including the original’s ‘feature’ of connecting the ‘AGP’ slot to the PCI bus. This explained why only the AGP GPUs that are compatible with PCI worked with this mainboard, as it’s actually Asrock’s ‘AGI’ slot.
Effectively just a way to scam buyers into believing that they bought a mainboard with an AGP slot when it was just a regular PCI slot cosplaying as an AGP slot. This doesn’t just mean lower speeds and spotty support with AGP cards, but also also potentially dead GPUs, as this mainboard inherited the same 3.3V-only card support.
Unlike PCI slots that are keyed for 3.3/5V voltage support, AGP slots are keyed for either 3.3V or 1.5V, or no key for universal support. These ‘AGI’ slots are sadly keyed for 1.5V AGP cards and thus will expose 1.5V-only AGP cards to potentially fatal voltages.
On the bright side, these are at least genuinely old mainboards, using the same AGP-less Intel chipsets, made back in the day to sell to unsuspecting buyers. Clearly the pain that these fake boards as well as genuine Asrock boards that these ripped off caused back in the day continues in 2026. Caveat Emptor, as they say.
In an ideal world, the role of technology would be to make all of our lives easier. And although all the ads suddenly appearing in our smart TVs and gaming systems might make it seem otherwise, some technology can still improve our lives if we work hard at it. For [Cian], that meant training a neural network to read his gas meter so he wouldn’t have to do it himself.
The root issue here is twofold, first that [Cian]’s gas company hasn’t upgraded their own technology to modern, remote-readable meters, and second that the meter can’t be read by a gas employee because it’s hidden in the depths of [Cian]’s basement. This latter fact requires him to delve into Moria-like depths to get to the meter, so the solution here was to place a Raspberry Pi in this location instead. With a camera pointed at the meter, it’s not quite capable of discerning digits on its own so a neural network was trained in order to get accurate readings of the dial. And, finally, since the machine is networked already [Cian] set it up to automatically notify the gas company of its reading so he is now completely out of the loop.
For automating tedious tasks like these, the Raspberry Pi with something like OpenCV as a computer vision tool is a fairly mature platform for light machine learning duties like these. We’ve seen license plate readers as well as neighborhood traffic surveys built on these platforms to help automate human labor away, making our lives easier one single-board computer at a time.
Have you ever found out that something you remember from your youth is now gone, and you didn’t even notice? If you are a certain age, you might feel that way when I deliver the news: You haven’t been able to buy International Reply Coupons (IRCs) at a US Post Office since early 2013. By the end of 2026, you won’t be able to buy them anywhere. The age of the IRC is over.
What’s an IRC?
An IRC from 1978 (public domain).
If that didn’t mean anything to you, you might be too young to remember, or maybe you just weren’t into shortwave listening or ham radio. Although there were other reasons to get IRCs, a radio hobby is the most likely reason a Hackday reader would have bought an IRC.
For radio purposes, here’s the problem. You’ve worked on your station for months, and one winter night, you finally pull in that rare station from Luxembourg. They’ll send you a QSL card to verify that you heard them. You only have to send them a letter telling them what time you heard them, what frequency, and some details about the program you heard. But they probably don’t want to pay the postage required to send hundreds or thousands of cards overseas.
While this is a radio-specific problem, you might find the same issue with pen pals or when trying to buy things from an overseas company.
SASE
If everyone were in the same country, the solution would be easy. Take a stamp, put it on an envelope that has your address on it, and stuff it in with the letter. Or, you could just drop a stamp or two in the letter you sent.
The problem is, US postage won’t help Radio Luxembourg. On the other hand, the effort required for you to buy postage that works in Luxembourg would have been a nightmare.
Enter the UPU
The Universal Postal Union is a UN agency that is effectively an association of post offices in 192 countries. Their charter is to facilitate mailing things worldwide.
The IRCs date back to 1906. The idea is you buy an IRC at your post office. You send it to Radio Luxembourg, or wherever. There, the mail person at the radio station could go to their post office and trade the coupon for enough local postage to send a surface letter worldwide.
Slow Death
A more recent IRC (UPU).
As demand has dwindled, post offices worldwide have quit selling IRCs. As of last year, Australia still did. But Germany, Britain, the United States, and many other countries gave up on them long ago. In fact, Britain’s Royal Mail claimed that the average post office sold less than one IRC per year at the time it threw in the towel.
UPU decided to end IRCs altogether by December 31, 2026. The end of an era and, apparently, not just for radio hobbyists. It is telling that the UPU’s recent editions of IRCs had print runs of 1,000 or even 500. So they obviously weren’t selling very many.
IRCs Other Claim to Fame
If you’ve heard of these before and you aren’t interested in radio, then it might have been in economic history. Have you heard of the Ponzi scheme? It has become a generic term for any business scheme that relies on raising money from new investors to service debt owed to old investors.
However, the original Ponzi scheme dates back to 1920, when Charles Ponzi realized he could buy IRCs in a country where they were cheap and sell them for more in another country. He was happy to accept investors, of course.
The problem is that profits are thin, and the costs of acquiring and transporting large numbers of IRCs quickly swamp most potential profits. Fluctuations in currency exchange rates take the rest.
Goodbye!
So the end of the IRC marks a closed chapter for ham radio and swindling. There were probably other uses, too, that are now consumed by electronic mail, payment systems, and the like.
You have to wonder what adventures IRCs went on during their global travels. The video below shows one’s story.
What if you want to do something in Linux for a lot of files? [Numerator] was tired of using xarg and other ways to handle this job and created bashumerate.
Some examples in the post of the “other ways” include:
You can, also, use a for loop, and if you are a programmer at heart, you may well do this:
for f in *.txt; do
wc -l "$f"
done
Bashumerate handles all of the common cases in one tool and uses the same syntax for multiple kids of enumerations.
For example, the above translates to:
enumerate -f '*.sh' -- 'wc -l {}'
The -f means enumerate files. You can also enumerate lines, numbers in a range, or lists. What’s even more interesting is that you can add your own source. As an example, there’s an add-in function that enumerates running docker containers.
The source is all in bash, so it should be very portable. Will you try it? What’s your favorite way to enumerate in shell? Let us know in the comments. You know how we love strange bash tricks.
My initial experience with a 3D printer came in 2020, when I got access to a buddy’s Creality LD-002R SLA printer. This was one of those awkward transition phases for SLA printers, where inefficient RGB LCDs finally got replaced by monochrome LCD panels, thus massively reducing the required exposure time and increasing the LCD panel’s lifespan.
The closely related Creality LD-002H is a monochrome SLA printer, but as this wasn’t the one that this friend opted for we had to learn the ropes on this more old-school printer. In terms of specifications this meant a build volume of 119 mm x 65 mm x 160 mm to play with and a claimed 26.1 µm resolution. Despite some struggles along the way, this machine churned out impressively high levels of detail with whatever cheap resin we threw at it, and even the post-printing processing became easy once we added a flex plate to the build plate and tweaked the cleaning and curing steps.
Despite all these positives, we both drifted away from resin printing, mostly due to the still messy and smelly printing process. FDM printers seemed like a better deal, especially after said buddy got his mittens on a used IDEX FDM printer. I would eventually go through a rather loathsome Creality Ender V2 experience before ending up with my current-day Elegoo Neptune 4, and resin printing seemed to be a thing of the past for me. Until recently, that is.
Things Have Changed
The Creality LD-002R MSLA 3D printer from 2020. (Credit: Creality)
Despite not having access to a resin printer any more, I still kept up to date on newly released hobbyist-level 3D printers of any type, as well as progress in technologies. Here I rather liked the digital light processing (DLP) types of resin printers, as they ditched the LCD and UV light source for a MEMS micro-mirror and laser setup for big power and weight savings. Unfortunately DLP resin printers appear to have fallen by the wayside again due to a variety of reasons, one of them apparently being scaling limitations with available DLP light engines and the manufacturers for the latter seemingly uninterested in this market.
Thus consumer SLA printing is still generally done with mono LCDs, which do not quite have the same efficiency and crisp edges for individual pixels as DLP, but which otherwise have come a long way, with better optics and light sources. A big push has also been towards larger build volumes, so despite new SLA printers tacking on more ‘K’s to their display resolution, the effective resolution isn’t that much better than a 2020 budget model. The real question is probably whether that’s even needed based on my own experiences printing fine details.
Perhaps the most exciting change is that with overall user-friendliness, such as easier bed levelling, the preventing of resin smells wafting out of the printer into the room, heated resin vats for reliable print results and UV-blocking lids that you can flip open instead of having to gently lift off the printer with dirty gloves while you desperately try not to drop it whilst scrambling to find a free spot to put it safely down.
Although the Creality LD-002R lists air filtration with a carbon filter, this was more filtration of the homeopathic variety. Instead of filtering anything, the tiny, noisy fan effectively blasted unfiltered, resin-rich air into the room. Thus one of the first thing we did was disabling this ‘feature’ by turning off the fan and sealing the air hole. This immensely improved the printing experience even with less optimal airflow in the room.
Picking A Resin Printer
The Anycubic Photon D2, the largest Anycubic DLP printer. (Credit: Anycubic)
The selection of resin printers to pick from these past years has been nothing short of overwhelming, even if you ignore the veritable flood of slightly different variations from certain manufacturers. Here DLP printers seemed different enough even with their small build space, to the point that I almost got one. Of course the long-awaited successor DLP printers never appeared, and the small build space was somewhat rough and put me off from an impulse buy.
Thus getting an SLA printer as a friend for my FDM printer seemed like the only option, but lacking real project motivation that idea got put on the backburner. It’s really hard to justify a purchase if you cannot justify such a financial expense, after all.
That’s when I suddenly got motivation shoved into my face, in the form of Uniformation contacting me about giving their GK3 Ultra SLA printer a shot. This would be a no-strings-attached chance to have a poke at what looked to be a rather nice and capable printer, even if its price tag of around $1,300 makes it something for people who really know that this is the resin printer they want.
I had heard of this Uniformation company before, as a smaller company that scored a pretty big hit with the somewhat-troubled-but-very-interesting GKtwo SLA printer, which had also featured on my shortlist at one point. The GK3 successor to the GKtwo had been baking in the resin printing community for more than a year by the time I got contacted, with gradual improvements over that time based on community and reviewer feedback.
This is quite different from most 3D printer companies who generally push out a new model in a take-it-or-leave-it sense, so I took them up on their offer for this printer to either play with or use as a very fancy coffee table, whatever I wanted. Based on the sheer verbal abuse I have read aimed at Uniformation during the GK3 development phase on especially sub-reddits, it makes me fairly confident that all major issues were fixed, and that at the very least it’ll be a massive upgrade over the LD-002R that’s pretty much my reference point.
Setting Up
In the world of 3D printers, it would seem that the idea of a flatpack parcel with your new 3D printer – as with my Ender 3 v2 and Neptune 4 bed slingers – has come to an end. A modern CoreXY kinematics FDM printer arrives fully assembled with only few exceptions – like Prusa 3D’s DIY kit offerings – so you’re looking at a very big box that weighs a lot. The similarly priced Prusa CORE One+ for example comes in at a cool 22.5 kg without packaging.
Super easy to move, barely an inconvenience. (Credit: Maya Posch)
The GK3 Ultra ups that to 35 kg, so I had a rather unhappy delivery bloke lug the ~40 kg box up a few steps from his van to where I could use furniture rollers to walk it over to its new home, next to the FDM printer in a sturdy rack. Lifting the printer into the rack was consequently also a bit of a chore, though less due to the weight and more due to the lack of any good places to grip it. I had to put on some good gloves for extra grip and to prevent the aluminium case from cutting into my flesh.
With that chore done, I could finally admire the fine mess that I had gotten myself into. First of all, the build volume is pretty massive, at 300 x 160 x 300 mm, almost fully beating the Neptune 4’s 225 x 225 by 265 mm. The GK3 Ultra is notably quite deep, at about 40 cm before adding space for the power and Ethernet cables, not to mention the provided Wi-Fi dongle if that’s more your thing.
Much of this extra space is taken up by the resin dispenser system, which I’ll cover more later. Within the rack you’ll need at least 85 cm between the two shelves if you want to put a resin bottle into the slot that’s conveniently placed on the top. Fortunately you can also pour resin directly into the vat and even make the flippy lid removable, but it’s a pretty hefty unit either way.
After liberating a lot of foam and goodies from the inside of the printer, I was finally able to start commissioning it. This involved removing a lot of protective film, running the exposure test to verify that the LCD and UV light source are working, and best of all a quick confirmation that the pre-levelled build plate was still level. Compared to the faffing about with four bolts on the LD-002R’s build plate assembly and sheets of A4 paper that I was used to, this was a massive improvement.
Time To Print
The resin that got sent along with the printer uses a special bottle style, which fits in the GK3’s resin feeding system. You slot the entire bottle into the hole on the top of the printer, from where it should automatically slot into all the tubing and widgets that are supposed to handle the resin flow. My only misgivings with this design is that each of these special cartridge-like bottles are only rated for ten insertion/removal cycles, after which you have to buy a new one.
Bottom of the Uniformation resin bottle, with the ports visible. (Credit: Maya Posch)
If you use non-Uniformation resin and are pouring resin into a special bottle, then this can be a bit of a pain, if only to keep track of just how many times you have inserted said bottle before you suddenly have it start draining fully into the vat, or whatever the failure mode here is. Fortunately you can also disable this feature if you’d rather pour the resin directly into the vat, which is probably what I’ll end up doing with typical resin bottles rather than use the provided empty special bottle.
Since the only bottles of non-expired resin that I have lying around use this automatic resin feeding system, I’ll be be giving it a shot. A total of two resin types are available to me, one is the water-washable type that’s supposedly not as smelly as the standard resin that I have always used, and which can be cleaned with plain water instead of IPA.
The other type of resin is ABS-like, which as the name suggests is a ‘tough’ kind of resin, targeting similar use cases as ABS, ASA and kin. For the test I’ll print everything with both WW and ABS, as well as in PLA on the FDM printer, to test both overall workflow, printing of fine detail, water-tight parts, heat-resistance and durability.
Test Setup
For a first printing round, I have so far printed a range of parts on the Neptune 4 in white PLA, and for the GK3 Ultra I will initially just use the ABS-like (AL) clear-blue resin, to not have to switch resins just yet, which is another fun topic to cover. These prints include a range of items like bottles, a miniature figurine and a bunch of LEGO Technic-compatible parts. The latter two serve to give dimensional accuracy a good workout, along with basic durability testing.
The print results and my initial findings will be in the next article, as this one is getting on in words. I’m also more than happy to consider any requests for aspects to test and questions to answer here. Although I have so far printed FDM parts in PLA, I’ll probably also be printing some parts in PETG and conceivably also TPU. Since I only have an open style FDM printer, engineering-grade materials such as ABS, ASA, etc. are naturally not available to me, for both practical and health-related reasons.
Back in the late 90s when absolutely everybody knew that Java was going to become the one programming language to rule them all, the Java Ring was handed out to folks at Java developer conferences as an example of how it was going to revolutionize smart wearable devices. Recently [Daisuke Yamazaki] got his mittens on one of these collector’s items to see about reviving it.
We talked about these rings and associated iButton devices before, with their intended use being primarily to act as authentication keys. For the Java Ring, this use was mostly just used as a kind of gag, whereby visitors to these conferences could specify their coffee preferences at a terminal, having this programmed into the ring so that they could get their desired cup of literal java at various bean juice dispensers around the conference site.
Talking to one of these iButton devices requires a so-called Blue Dot adapter, which [Yamazaki-san] purchased along with the ring. Although the device happily responded on the 1-wire bus, figuring out how to interact with the original Java-based firmware and answering the question of how much of the original information of someone’s coffee preferences in ’98 were retained would require more sleuthing.
Welcome to the Java wearables future of 1998. (Credit: Internet Watch, Impress)
After recovering an installer for the Dallas Semiconductor’s IB-DE IDE from the Wayback Machine, this posed the next problem. As it was a 32-bit Java binary, which didn’t play nice with the modern Java 25 runtime and belying the ‘write once, run anywhere’ marketing phrase of back then. Downgrading to 32-bit Java 1.8 with since removed communication APIs helped here.
With the IDE in place, the traffic between the Java Ring and the PC-based software could be analyzed to figure out what was going on. This revealed CRC errors that pointed to the built-in lithium backup battery having expired. Unfortunately the stainless steel case is meant to be sealed and thus turn into e-waste the moment said battery calls it quits. Here fortunately a Japanese TV program picked up on these efforts and featured his efforts on national TV.
This led to the happy ending, with some help with others in replacing this battery. This also answered the question of which parts of the firmware and data were in the battery-backed RAM and which in ROM. Although full details of the findings here are a bit scarce, it seems that the original data was lost along with the dead back-up battery, but the ROM retained the JVM and allowed for a new program to be eventually written to the device and retained across reader sessions.
Although these days the various NFC standards have made bulky devices like iButtons rather obsolete, they’re still a fun look at an era when it was thought that lugging a tiny computer as a (key) ring around for authentication was the future. Of course these days we mostly lug an entire 6″ smartphone for that purpose, so maybe the joke is on us after all.
If electronic paper displays have one downside, it’s generally refresh rate. Earlier versions of the tech might only have been able to do single-digit frames per second, while modern, mid-range devices can sometimes manage 10-20 FPS — and that’s not including the frames needed to blank the display. Getting up past that double-digit barrier typically requires higher-end displays, more powerful processors or FPGAs, and more money. On the other hand, [Tony] was recently able to get 20 FPS out of an ESP32-based device without using any extra processing power.
The key to improving e-paper performance is understanding how the display actually works. The “ink” consists of microscopic charged pigment particles that physically move in response to electric fields, making the display much slower than LCD or OLED panels. Rather than fully erasing and redrawing every frame, the software takes advantage of the particles’ existing state by generating optimized driving waveforms that only move the particles needed to produce the next image. On the software side, an MPEG-like encoding is used so only changes between frames are transmitted and converted into these waveforms, reducing unnecessary data transfers and allowing much higher frame rates.
Tony’s method is able to drive 960×540 panels, like those found in the Lilygo or M5PaperS3, to 20 FPS, and these platforms are based on nothing more than the capable but limited ESP32 chip. It’s an impressive push, and worth checking out the video in the linked project page. We assume you’d need a little more to drive something like the massive e-paper display found in this home automation setup, though.
We all know that Google and other big players pick and choose what information people see, but we sometimes overlook it outside of the search and social media space. [Lauren Leek] decided to take a look at how Google Maps picks winners and losers in the restaurant scene in London.
Building a machine learning model to determine a new restaurant recommendation (as one does), [Leek] uncovered interesting, and perhaps concerning, elements of how Google Maps ranks restaurants. Broken down by relevance, proximity, and prominence, many new restaurants face the issue of not drawing traffic without reviews and vice-versa causing a vicious cycle. Relevance and proximity are fairly straightforward, but what goes into “prominence?”
[Leek] found that “it is not just what people think of a place – it is how often people interact with it, talk about it, and already recognise it.” This leads to chains and high foot traffic areas awash in reviews while more out-of-the-way places find it more difficult to draw traffic. Some of this is expected and would be happening even when word of mouth was the primary way to find out where to eat, but as with many things, the algorithm amplifies this, along with the undisclosed paid placement of restaurants in Maps results.
While still in its infancy, [Leek] built a public dashboard where people can sort restaurants in the city. The machine learning algorithm is designed to identify places that are hidden gems that punch above their Google Maps weight and may make you look like the trendy one (if you live in London).
Zooming out further, [Leek] found larger clusters that revealed restaurant “diversity, in other words, is not just about taste. It is about where families settled, which high streets remained affordable long enough for a second generation to open businesses, and which parts of the city experienced displacement before culinary ecosystems could mature.”
Although life tends to find a way, something first has to kickstart said lifeforms. Exactly how the first biological cells formed on Earth – and potentially on other worlds – remains an enduring mystery. Some theories point to the early Earth’s surface conditions as a viable laboratory for the self-assembly of the first viable membranes, RNA, DNA and associated molecular machinery, while seeding of the Earth’s primitive atmosphere by sugars and other precursors from asteroids and kin is required in other theories.
Recently [Izaskun Jiménez-Serra] et al. added to this debate with the reported detection of four-carbon sugars in the form of erythrulose in the interstellar medium. Using the 40 meter radio telescope at Yebes and the 30 meter radio telescope at Granada the signatures of this sugar was detected in a molecular cloud near the center of the Milky Way.
These sugars likely form on these interstellar dust grains from more basic two-carbon aldehydes and alcohols, with them providing conceivably a source of energy for early metabolic processes of developing lifeforms. This specific type of sugar is highly prevalent in Earth’s fruits, and thus its prevalence in interstellar space is at the very least an interesting coincidence, if not another puzzle piece in the overarching question of abiogenesis.
Login
