Exciting discoveries in particle physics are one of those things that it can be easy to get blase about. Some people get caught up in the obvious excitement, while others yawn: “Oh, you found the Higgs Boson, just like Higgs predicted. Call me when you have something new.” Well, if you’re in category B, prepare to yawn while the rest of us break out champagne, because it looks like we’ve finally found the glueball. 

The glueball has got to be one of the oddest particles to fall out of the Standard Model. It’s not a fundamental particle, but its makeup contains no quarks– those itty bits that make up protons and neutrons– nor any leptons like electrons or muons. No, the glueball is a hadron made entirely of baryons: specifically, gluons, the force-carrying particles of the strong nuclear force. It’s also been called gluonium or a gluon-ball, but glueball is more fun.

Try and imagine a proton without any quarks. Remember that inside the proton there are three quarks, held together with force-carrying gluon particles. If you have zero quarks, but enough of those gluons tangled up in the right ways, and you get a tangible, if short lived particle. That’s the glueball, a neutral particle that will decay almost immediatly in to Pions. It works because gluons have ‘colour charge’– the strong nuclear force’s answer to electric charge.

It’s also one of those things that will probably never be seen in nature: odds are, even in the hottest collisions, you’re going to get a quark or two mixed up with your gluon soup. That’s okay; the gluonic state is what we’ve been looking for. As long as the particle is mostly gluons, and behaves as the Standard Model predicts it should, physicists are inclined to call it good enough. The latest candidate to hit “good enough” is X(2370), which fell out of a collision in the Beijing Electron–Positron Collider II (BEPC II), as detected by the Beijing Spectrometer III (BES III). The paper hit ArXiv at the end of July. It’s taken the collaboration this long to make sure of what they were looking at, as they sorted through the terabytes of data an instrument like this generates.

Is this likely to affect you in any way? No. It confirms what we already thought we knew about the universe, and the particle itself is too short-lived to ever exist outside of some very extreme– mostly man-made– environments. On the other hand, it’s an excuse to celebrate scientific discovery, and we’ll take any of those we can, just like when the Muon Magnetic Moment measured in at the expected value, or neutrinos transmuted elements in exactly the way the models said they would. Besides, if we’re really lucky this result will turn out not to be a glueball, but something new and interesting. Then even the most jaded nerds will have reason to celebrate.

Header image: The Bejing III Spectrometer, BESII.

It’s likely many of us have been in the position of first set-up on a machine such as a Raspberry Pi, and had keyboard problems. Either no spare keyboard is to be found, or a cluttered desk has to find extra space for a full-size keyboard. [Henk] has a handy solution, use the existing keyboard on your laptop.

His approach is both ingenious and simple, as it’s only the K part of a KVM. On the laptop end, it’s a serial terminal, without the receiving side. The serial port in question is an RP2040 board which implements a USB-to-serial port. This serial connection goes to another RP2040, which does the ingenious bit. It’s a serial-to-USB HID keyboard. All of this means that keystrokes on the laptop are sent down the serial connection, and appear on the Pi or whatever computer as a USB keyboard as though typed locally. The mildly annoying first set-up can be done, and then it can be run via SSH or whatever other remote access protocol as normal. The code is provided, so anyone with a couple of RP2040 boards can do it.

We like this hack, because we’ve had the annoyance of needing a keyboard to set up what would otherwise be a completely headless machine too many times. It’s one to store away at the back of your mind, for those rare improvisational need-an-extra-keyboard moments.

One of the great things of Linux as an ecosystem is that there is so much choice. Yet this is also its greatest weakness, as unlike on MacOS and Windows this means that simple questions often do not have a simple answer. The topic of distributing software is one of these vexing topics that never really goes away, with [Noam Lewis], as author of the Fresh editor, recently expressing their frustrations on this topic.

This is a familiar topic that we have covered before, mostly in the context of cross-platform installers. Whereas on MacOS and Windows you just pick any of a handful of standard installer frameworks that do roughly the same thing, on Linux you are dealing with a dizzying number of package managers, including distro-specific ones, NPM, Homebrew, Rust crates, third party repositories like Arch Linux’s AUR or stray APT repositories for Debian, and of course AppImage and Flatpak along with a host of other options.

After going through the entire list with help from the Fresh community, [Noam] ended up creating packages for all of them, and has a lot of thoughts. Since Fresh is a TUI-based editor, something like Flatpack is not a really good fit, while AppImage is just very slow due to mounting the image, which is annoying.

Overall, distro-specific solutions are just unpleasant in general, as they mean repeating the same work over and over, even if you can even get into a distribution channel. Ultimately the solution that [Noam] ended up at was to have a static binary with the musl runtime, along with an integrated updater, which is a solution that should be quite familiar for Windows users. Yet even if it fails some kind of purity test for certain Linux users, is it really a bad solution if it works for users of the software?

Now that MCUs like the ESP32-S3 are quite capable computer systems including USB host functionality, it only makes sense that you can connect USB peripherals like Logitech racing wheels to them. Of course, these aren’t basic HID USB devices, so they require a bit of setup to make them start spitting out the data updates which we’re interested in. Making this process easy is the goal of the LogiWheelHost project for ESP32-S3 by [Joel Kometz].

This single-header library supports the G29, G923, G920, G27, G25, DFGT, Driving Force Pro wheels, building on top of the EspUsbHost project. As explained in the README, these racing wheels do not start streaming all updates to their controls once powered on, but boot into a restricted mode in which only neutral or combined-axis data is sent.

To change this you need to trigger the so-called native mode switch in which far more detailed information as well as updates on extended features like separate pedals, all buttons and the gear shifter become available. This is done by sending a HID output report to the USB device, which is easy enough.

In addition to handling this detail the library also provides an API using which obtaining and using these controller states in your own code should be quite easy. Presumably the library will work on or can be ported to other ESP32 MCUs that support host USB mode, so this might be good news for anyone who is looking to do more with that old Logitech racing wheel.

A few weeks ago, we put out the call for participation for this year’s 2026 Hackaday Supercon, taking place in Pasadena, CA this November. Today was going to be the deadline, but like you, we often let things pile up and put things off, so we’re extending another two weeks until August 26th.

Which is not to say that we haven’t heard from a ton of you! We’re psyched to see so many familiar Supercon regulars on the list, but we also love to see first-timers give talks. We try to make sure that new folks get their time to shine, so if you’ve never given a Supercon talk before, or if it’s been a few years, take this as your cue to present in front of the friendliest audience of like-minded hackers around.

This year is Hackaday’s tenth in-person Superconference, and to celebrate we’ve gotten a larger venue, so more folks can watch the talks live. We’ll be running two tracks as always, and you have your choice of a 20-minute or 40-minute slot. Presenters get in free, and we’ll get you an early-bird ticket rate the submission, so don’t delay and register for your slot today! Or at least before August 26th, because we won’t extend the deadline twice.

Oh, and if you’re interested in tickets, swing by Hackaday about this time tomorrow — we’ll have some news for you.

In a few hours, there is a solar eclipse that will be visible with a track that goes from Spain up through Greenland. Too late to travel for it, but thanks to [jonty], you can find all the webcams that will have a view.

This may be ideal. No funny glasses. No looking at a projected image on a card. Of course, many, if not all, of these cameras aren’t looking directly at the sun, so it isn’t clear if you’ll be able to see the actual eclipse or just the effect it has on the surroundings.

If you prefer more science, try the NASA feed below.

Or, you could see what ESA is broadcasting from Javalambre, Spain:

Or, try the telescope view version:

Want to know what it might look like from a particular spot? Harvard has you covered. If you want to feel more realistic, try wearing some regular sunglasses while watching just for the fun of it.

We wish we could watch our eclipses from the lunar surface. Of course, you can always make your own eclipse.

When we last left off, I had just set up a new SLA resin printer and was on the verge of doing the initial round of printing to see just how resin printing in 2026 compares to way back in 2020. Surely SLA printing had to be easier and less fussy than it was in 2020?

During these weeks of printing, setting up printers and taking a gander at the various workflows that certain printers and their manufacturers try to push you into I have both produced a series of not too shabby prints and some delightful spaghetti. I also flipped a few proverbial tables and formed some strong opinions on 3D printing workflows, of which some can considered to be family-friendly.

Without further ado, let’s get into some updates, a bit of ranting, and even some printing results.

Going With The Flow

Although workflows are a fairly personal thing in terms of preferences, we’re all creatures of habit with a strong tendency towards laziness. We also tend to prefer workflows that are easier for that reason. This is where after the very manual approach of the Ender v2 I really liked much about the Neptune 4, ranging from its much faster and open source Klipper firmware to a semi-automatic bed-levelling procedure, and of course the Fluidd web interface.

With this I can just pop open an interface in a browser tab and manage the printer, watch the webcam view, etc. from there. Somehow there’s now a third option that seems to be taking over, however. Although a web interface seems straightforward and easy for the average user, there’s been this move towards requiring the use of the slicer via a special API or such that leads to fun access situations as we have recently seen with Bambu Lab printers.

Out of a sense of morbid curiosity I decided to look at what I’d be dealing with if I were to upgrade to the latest & greatest Elegoo (CoreXY) printer if I ever grew tired of my Neptune 4, and noticed that they seem to have gone more in the direction of Bambu Lab. The firmware is Klipper-like but closed, with the most recent FDM printers like the Centauri Carbon series also requiring access via a slicer and/or a special mobile app with a lot of Cloud things mixed in.

To me this seems hugely cumbersome, since one of the things I like with the Neptune 4 is that I can access it from anywhere on a system with a slightly modern browser and print models that are stored on the internal memory. This is where the the GK3 Ultra scores pretty well in my book, too.

Certainly, this resin printer doesn’t do fancy web UIs or APIs, or much in terms of remote-anything. You do get Ethernet, a Wi-Fi USB dongle and the rather nifty ability to set up an SMB file share that you can dump sliced models onto before waddling over to the SLA printer. It’s low-tech yet also universally supported and open, while more convenient than plain Sneakernet, though that’s also an option using the front-mounted USB-A port.

Can I just briefly say how much I love having a USB-A port for Sneakernet purposes, rather than a tiny USB-C port or microSD slot? The Ender 3v2 offered either microUSB or microSD for inputs, none of which really made me like that printer more.

Finally Some Printing

For this first printing round, I printed the same parts on the Neptune 4 in white PLA and black PLA. For the GK3 Ultra I just used the ABS-like (AL) clear-blue resin, to not have to switch resins just yet. The prints include a range of items like bottles, some figurines and a bunch of LEGO Technic-compatible parts. The latter two serve to give dimensional accuracy a good workout, along with basic durability testing.

Starting with FDM printing, this was largely uneventful, though I upped the difficulty challenge with the N4 by using a spool of extra-brittle white PLA. Somehow even that came out fine, aside from an unfortunate spaghetti incident that required some PVA glue to be slathered onto the PEI build plate.

On the resin side of things, it was pretty much as I remembered it from my LD-002R days, just with an absolutely massive build plate, the auto-feeding of resin and of course the use of this rather nice transparent blue ABS-like (AL) resin.

On the slicer side of things I kept things as boring as possible, with OrcaSlicer for FDM, and ChituBox’s free version for SLA. I did look at Lychee as well, but they require registration for even the ‘free’ version, so that one was out for now. I’ll also say that ChituBox got a bit heavier resource-wise than since I used it six years ago, and somehow its UI still feels rather unintuitive, though that’s a bit of a central issue with slicers.

To be fair to Uniformation, they also provide their own slicer on the USB stick and as a download, but since the latter involves a random Google Drive, it triggered my system security-related anxiety. It’s probably a perfectly cromulent slicer, but using ChituBox was the less exciting option for me here as a first try.

Comparing Parts

Since both Elegoo FDM printers come with an example model in the form of this happy Buddha figurine, I figured that I’d also print it with the GK3 Ultra. Here you can see how these compare in a sloppy smartphone photo for which I apologize:

The model was clearly intended to be printed on FDM printers, so the SLA version doesn’t really add a lot, other than a lot of weight. Unlike FDM prints where you have aspects like ‘infill’, an SLA printer can print everything 100% solid with zero time penalty. In fact you want to do this so that you don’t need to drill a hole in it for liquid resin to leak out.

Of course, you can totally hollow out models to save resin and weight, but in that case you do need to add those drain holes lest you end up with liquid resin sloshing inside forever.

Moving on, I also printed a miniature knight figurine on the N4 and GK3 Ultra, which was a bold decision for the former:

Removing supports on this approximately 32 mm tall model was a bit of a nightmare with the SLA version, and I still need to clean it up better, while also rethinking ChitBox’s insistence on angling it upside-down for some reason.

I didn’t even bother with removing supports on the FDM version, although I was somewhat surprised at how much detail it still had when pushing layer height to its ‘super fine’ 0.12 mm setting, though the SLA printer with the ‘sloppy’ 0.1 mm layer height preset is simply in another universe when it comes to preserving fine details.

Clearly layer heights between SLA and FDM are at best the fuzziest of all overlaps, with even the knight’s cape in the SLA version capturing the flow of the fabric and details in the helmet that the FDM version had obliterated.

Finally there are the LEGO Technic-compatible shenanigans:

There is obviously a lot of variability and improvement possible simply by the orientation you print things in, the type and placement of supports. SLA has the massive advantage here that support points on models can be made absolutely tiny and correspondingly leave almost no mark. This made e.g. printing LEGO-compatible parts a snap on SLA, but a nightmare on FDM where I struggled to find an orientation and support/brim configuration that didn’t lead to misprints and/or interfered with the part’s functionality.

The thing where ChituBox really did me dirty, however, was that it went crazy on supports, even adding lots of supports inside these latter parts that still have to be painstakingly poked out if I want to actually properly use them. This is however a slicer issue and potentially a skill issue on the side of yours truly.

Flipping Of Tables

Even after just this first round of printing there’s quite a bit to unpack. On the FDM side of things the workflow is definitely the easiest, especially in terms of post-processing. I did have some bed-adhesion issues, however, which is where SLA tends to be significantly less fussy with just the long-exposure first layer. For the FDM side of things I had a few misprints as a result, which was annoying.

On the SLA side of things there wasn’t too much to upset me, other than some table-flipping at the automatic resin feeding system which I mentioned in the first article. After starting the print, the system seemed to work and began filling the vat with resin, albeit very slowly. At some point I got a ‘material in/out time-out’ error, following which I retried printing, with the resin system again trying to fill the vat for a long period of time.

Ultimately I decided that since I only needed just over 60 mL for the print, and it had already poured in about half the resin bottle, I’d just cancel it. It’s likely that I missed a step here, such as I’m not sure whether you need to pop open the bottle for this to work, but the manual did not mention such details.

Popping over into settings I disabled this auto-feed system and tried to printing again, which worked without issues, other than the backstabbing by ChituBox and a persistent resin smell. This latter issue I tracked down to the slot for the resin bottle, which may or may not be related to the auto-feed issues. After sealing up the gaps the resin smell faded quickly, making it seem at least plausible that the active-carbon system of the machine does something.

After printing I did the usual post-processing, just with a scraper to knock the supports loose instead of something more gentle with a flex plate. The parts were tossed into IPA for a quick clean, including a trip through the ultrasonic cleaner. This was followed by another quick IPA rinse and finally some tanning with a UV lamp in a water bath. This latter step is to keep oxygen away from the curing process and thus speed up the curing, which is one of those details that have worked well for me in the past.

First Conclusions

Despite some flipping of tables, it’s been a fairly positive experience that at least has allowed me to set a bit of a baseline. My overarching feeling at this point in time is that FDM is rather okay for large parts with little detail, such as a CD rack that I already printed in PLA. Not having to deal with smelly resin and involved post-processing is also generally nice.

That said, the sheer quality and level of detail you get with SLA is just a whole other ballgame than FDM. Although it’s been a few years since I previously printed with resin, I still have quite a few prints from that time, including an absolutely miniscule fox figurine that I scaled down on the LD-002R for fun and which still is very much recognizable. The SBC cases and such printed in resin from back then have this level of smoothness and solid feeling to them that you just don’t get with FDM.

An elephant in the room remains that of ABS and ABS-like printing. Such engineering-grade materials are essential for anything in production, and I definitely have to give this Uniformation ABS-like material a good workout. That said, I’m still very hesitant about printing ABS and ASA filaments with FDM, due to the health hazards this poses, mostly caused by the release of styrene.

Although I already wear a respirator with A1 filters backed up by P2 prefilters against VOCs and kin while processing SLA prints, styrene pushes the hazard levels a few notches higher, since unlike most organic vapors it’s not just an irritant, but a known mutagenic toxin. Here an active carbon filter in a closed-chamber FDM printer would seem to be at best optimistic.

To me this aspect alone makes the idea very appealing to use SLA to print high detail models and production parts, while using FDM for sloppy prototyping in PLA, PETG and of course TPU, but this is something that I’ll have to poke some more at. Any input here would be most welcome so that I can do even better with the next article.