TechyMagThings

While in aquatic environments microplastics can be filtered out relatively easily, in soil it’s much harder to get to these microscopic particles. While you can certainly strip mine an entire area to process its soil, a less invasive method would involve something like the magnetic flakes proposed and demonstrated by [Jeonghyo Kim] et al. in a recent article in npg asia materials.

The Ti₃C₂T_x flakes, referred to as MXene microparticles, were designed to attract target microplastics. These were then combined with ferromagnetic nickel nanoparticles to make structures that can be propelled through soil using an external magnetic field.

During tests under laboratory conditions the researchers managed to remove about 81% of polystyrene and 72% of PET particles this way from soil, with a correspondingly higher percentage in water. After having the flakes rummage about for a while through the target material, they are removed with a strong magnetic field, which should recover most of them.

Naturally, the question with any such system is how it’ll perform once exposed to real world conditions and its myriad of soil types and conditions.

The Raspberry Pi line of single-board computers are great little devices, and they can do great things with cameras and video. However, there can be a fair bit of latency involved in these tasks depending on the board you’re using and just what you’re doing. You need to have things set up just so to get peak performance. [MattKC] has tangled with this issue in a personal project, and recently had somewhat of a breakthrough.

The issue came up during [MattKC’s] work on cloning the WiiU gamepad. The idea was to receive the video stream from the WiiU console and display it using a Raspberry Pi Zero 2W. He had some problems with latency, wherein there was a strange 3 frames of latency in the video pipeline that just wouldn’t go away. Even substituting in some dummy frames into the pipeline and ignoring them at output time didn’t work—the latency stuck around. Eventually, [MattKC] realized the delay wasn’t about a certain number of frames—it was about time. About 50 milliseconds, in fact.

Drilling down further revealed that there was a problem in the way frames were being fed into and received from the decoder. The first frame would take about 50 ms to decode, while later frames would take far less—as little as 5ms. However, [MattKC’s] code wasn’t set up to grab frames as soon as they were done, so the lag carried forward. The video explains it in greater detail, and how polling the decoder regularly helped solve the issue. The final result was a Raspberry Pi Zero 2W that could process and display the WiiU video feed as quickly as the original Nintendo WiiU gamepad.

If you dug this, it’s worth going back and checking out where the WiiU gamepad project started, too. Video after the break.

Most hackers and makers end up with a cheap pair of calipers in the toolbox at some point or another. [DiodeGoneWild] decided to take a particularly cheap plastic pair and tear them down to see what makes them tick measure.

The electronics is, unsurprisingly, all contained inside the carriage which slides along the ruler. The ruler itself has an etched copper strip inside, underneath the scale sticker, with repetitive T-shaped sections. Meanwhile, the PCB in the carriage has a series of plates for capactive sensing. As the carriage slides along the copper strip inside the ruler, the capacitive sensing plates pick up varying capacitances which are directly proportional to how far the carriage has moved, allowing for precise measurement of relative position. Zeroing is a job for the user, via the ZERO button. We get to see how this works on the bare hardware level, and [DiodeGoneWild] even breaks out the oscilloscope to help show us what’s going on.

[DiodeGoneWild] also notes that these calipers are particularly frustrating for how quickly they discharge batteries while in storage. This may be down to the convenience feature, wherein moving the caliper switches the display on. There’s no hard off switch here—so the caliper is always drawing some juice even when it’s just in the cupboard. This is why these things are forever turning up dead when you need them.

If you’ve never pulled apart one of these cheap tools, this is a great way to see what’s actually going on under the hood. We’ve seen some other great teardowns lately, like this deep dive into a cheap pair of smartglasses. Video after the break.

The Tasmota firmware is a popular choice for flashing to a range of Espressif microcontrollers to turn them into smart home devices. If you have such devices in your house, you might wish they were easier to integrate with the Apple Home platform. As it turns out, though, there’s a convenient app for that.

[Christof Müller] built an app called Tasmoshelf for just this purpose. Its primary claim to fame is that it can easily help port a Tasmota-based setup into the Apple Home universe. It can achieve this without requiring a Home Assistant server or MQTT broker or any other workarounds. This is thanks to the fact that Apple Home is compatible with Matter technology, as are ESP32 devices running Tasmota 13 firmware or newer. They can natively jump on an Apple Home setup, and even act as a bridge for older ESP8266 devices that can’t speak Matter themselves. The device is able to run network scans to automatically discover devices and advise whether they can hook up directly to Apple Home, or whether a bridge is needed.

If you’re running Tasmota devices and want to easily integrate them, you might find Tasmoshelf a useful addition to your smart home setup. Just note that it does require a one-off purchase if you intend to use it beyond three devices, a limit which some might find somewhat restrictive.

We’ve looked at Tasmota in detail before; it’s a great way to whip up a smart home to suit your own desires. Meanwhile, if you’re whipping up your own nifty integrations, don’t hesitate to let us know on the tipsline.

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?