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.

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

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.

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.

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

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:

sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control

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:

ethtool -k eth0

Advanced network tuning is a bit beyond the scope of this post, but there are plenty of roadmaps down this rabbit hole.

The Lesson

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.

Now if you’ll excuse us, we’ve got to go warm up the UV printer.

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.

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

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.

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?

We’ve seen the Xiaomi Air purifier filter mentioned before, but under the auspices of hacking it’s filter DRM, an open source air filter designed by [Naomi Wu], and even an ESP32 pressed into service to plug an air purifier into Home Assistant.

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.

With the rocky status of the Roomba ecosystem, projects like this are more important than ever.

The cybersecurity-focused models, including GPT-5.6 Sol, broke out of a testing sandbox, exploited a zero-day, and gained access to the open internet to pull off the attack.

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.

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.

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:

find . -name '*.log' | xargs rm
find . -name '*.sh' -exec wc -l {} \;

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.

A new type of malware can worm deep into AI coding systems to steal data and logins—and can flip a “death switch” to destroy files and keep out real users.

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

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 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.

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.

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.

 

Dealerships installed alarms in millions of vehicles—and left them in even if the buyer didn’t want them. Now researchers warn they can be hacked to unlock, track, and disable cars.

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.”

If you want to step outside the algorithm mayhem, how about a good old-fashioned Web Ring? We’ve also addressed what’s an AI versus an algorithm, and Cory Doctorow advised us on how to reverse course on the current wave of enshittification.

Bats are remarkable creatures, able to fly at night or inside the confines of caves without light to guide their way. A team of researchers at Worcester Polytechnic Institute (WPI) has determined how to use low power ultrasonic sensors to guide drones in obscured environments.

While radar, lidar, and GPS are all great for navigation and sensing, they can run into issues when light is obscured or can take too much power to be practical for the limited battery life of a drone. The researchers found that a dual sonar array could be used to implement a much lower power sensing system for a drone that performs well in environments that would stymie a computer vision system.

A shield placed behind the array cuts down on the sound of the propellers that would otherwise drown out the signal, and further signal analysis via a neural net separates the echoes of objects in front of the drone from the background. The prototype could navigate in various simulated environments like forests, smoke, and snow. It looks like it even got a chance to go for a flight in the actual woods. All the code and hardware designs are Open Source, so have at it!

We’ve covered mosquito-inspired drone sensors before, and if you want to get into echolocation yourself, apparently humans can learn to do it too.

via Entertainment Engineering.

A little over a month ago, we featured a project from [Igor] who built 64 bits of DRAM from scratch using discrete components. Jokes about memory pricing aside, he did have a use case for such a small amount of memory — he is using it in a custom-built drum machine. But featuring the memory build and not the drum machine was perhaps putting the cart before the horse, so in this video, [Igor] shows off the construction of each part of his impressive 16- or 64-step sequence drum machine.

This isn’t Igor’s first drum machine, either, although his previous build was a bit more limited. It had fewer steps in the sequence and didn’t quite have the range of his newer model. The upgraded version can play more steps but also includes force-sensitive drum pads based on piezo sensors and more voices (drums) as well. Each voice is built electronically using various op-amps and passive components, and [Igor] has the schematics for each of them, as well as every other part of the drum machine, for those looking to recreate any part of this on their own. There’s a lot going on in this lengthy video as well, so for the musically inclined, it’s worth taking a look in full.

Now that our horse is in the correct position in front of the cart, it’s worth going back and looking at the memory build if you missed it when it first ran. A small amount of memory makes the machine programmable rather than just playable, and truly expands the capabilities of a machine like this in the recording studio.

These days, it is easy to think you always have access to the Internet. But some wonder if — in spite of its ARPANET, nuclear-war-planning heritage — you can actually count on it to be there when things go pear-shaped. [The Tech Prepper], as you might imagine, is quite concerned with that last question, and is flogging Reticulum over high-frequency radio as a post-internet network in a video embedded below.

Reticulum is a cryptographic network stack, fully decentralized and amazing from a cyberpunk/hacker/survivalist perspective. Unfortunately for [The Tech Prepper], until the you-know-what hits the ventilation unit and the FCC and its counterparts in other countries are too busy to be concerned with such trifles, encrypted signals are banned on ham radio bands just about everywhere. That’s why his demo is using a dummy load on the Mercury HF modem instead of an antenna: the feds don’t care if the signal doesn’t leave the building. The video shows how to replicate the setup using his EmComm Tools suite on Ubuntu.

Perhaps more interesting is his vision of a Post-Internet network, be it in a disaster scenario, as he envisions, or simply because we get sick of what the internet has become. The idea of easily hooking an open-source radio modem to a PC running modem73, open-source SDR software, has a certain appeal. Reticulum isn’t your only option there: modem73 will let you run a BBS in the clear — that is, unencrypted and legal to transmit — and let’s face it, wasn’t life online more fun in BBS days?

This isn’t the first time we’ve seen the Reticulum network stack, but last time it was operating at considerably shorter ranges over LoRA. 

Magnets are awesome, so it’s no wonder we love to add them to our 3D prints. Doing so in a way that will actually last is harder, with thermal creep being one reason a simple friction fit will loosen over time, and using super glue to hold a magnet in place can be messy. In a recent video, [Slant 3D] covers seven ways to install magnets in 3D prints without resorting to glue, along with the advantages and disadvantages of each.

With friction, the argument is that you can still use them, but you’d want to use something like cylindrical magnets rather than flat magnets to increase the friction with the thermoplastic. Using an arbor press rather than human primate hand power is also beneficial.

Rather than installing magnets halfway through a print with all the logistics that entails, you can use side slots to install said magnet into, which is much easier, but as with all embedded magnets, you get that plastic barrier between the magnet and its target.

Other methods involve using a bit of extra material that you need to push the magnet past, using something like an arbor press, so the magnets should never just fall out. A wildcard here: spherical magnets, which can be locked in using a similar method, while automatically orienting themselves to an opposing magnet.

The final tip is to never use two magnets in a magnetic lock. Instead, use a cheaper ball bearing or a similar plain metal part on one side instead. Magnets tend to be much more brittle than whatever stainless steel ball bearing or washer you can use on the other side.

Of course, people will always try to install magnets during an FDM print, but before they try to do that anyway, they really should learn about the fascinating ways in which magnets can ruin print beds, destroy nozzles, and otherwise make a total mess of a print. Magnets seem magical. Maybe they are.

One of the most crucial aspects of FDM 3D printing is ensuring sufficient material is extruded. Determining the right flow rate can be done manually, but some printers these days automatically perform this adjustment, which is very convenient. [Stefan] of CNC Kitchen investigates how to add similar functionality using existing bed-leveling sensors.

A major complication with extrusion in FDM printers is that the flow rate has to fit the printing speed. However, you can’t just immediately speed up or reduce the flow rate, as the melting filament is flexible and thus acts like a spring, especially as the extruder is exerting significant force on the filament, which adds compression.

The moment you reduce or increase the speed of the nozzle, you can get over- or under-extrusion, but the delayed response by the extruded filament means that you have to adjust for this change in advance. Ergo, the name ‘pressure advance’, also known as the K-value. Obviously, this is a parameter that differs with each material, printer, and other factors, so a direct measurement is always the best.

In the Bambu Lab X1 FDM printer, a Lidar scanner was used to scan various test patterns to automatically determine the optimal setting. This was later moved to the purge section of the extruder in newer Bambu Lab printers. On other FDM printers, the only available sensor in that area is typically the pressure sensor for bed leveling. Could this sensor make a similar measurement?

This wasn’t just an idle thought, but was inspired by the Snapmaker U1, which runs open-source Klipper, with tantalizing glimpses of how it does pressure-advance sensing in its extruder. This extruder also only contains a load cell, as do some Prusa printers. These much more open printers thus provided a test bed for some experimentation.

With load cell data available, [Stefan] measured how various extrusion rates affect the load cell, which can then theoretically be correlated with the appropriate K-values for specific transitions. He created a calibration tool for a range of Prusa printers that works with stock firmware, though this is definitely still a work in progress. There are also a couple of similar open-source projects, such as this Auto PA Calibration project by [Mark].

Overall, K-value presets tend to work pretty well, but adding a pressure-advance calibration feature to existing FDM printers is definitely an interesting idea. There’s also the prospect of lateral sensing using this same bed-leveling sensor, which could allow the printer to sense much more than just the bed.