TechyMagThings

With multiple rovers currently scurrying around on the surface of Mars to continue a decades-long legacy, it can be easy to forget sometimes that repeating this feat on other planets that aren’t Earth or Mars isn’t quite as straightforward. In the case of Earth’s twin – Venus – the surface conditions are too extreme to consider such a mission. Yet Mercury might be a plausible target for a rover, according to a study by [M. Murillo] and [P. G. Lucey], via Universe Today’s coverage.

The advantages of putting a rover’s wheels on a planet’s surface are obvious, as it allows for direct sampling of geological and other features unlike an orbiting or passing space probe. To make this work on Mercury as in some ways a slightly larger version of Earth’s moon that’s been placed right next door to the Sun is challenging to say the least.

With no atmosphere it’s exposed to some of the worst that the Sun can throw at it, but it does have a magnetic field at 1.1% of Earth’s strength to take some of the edge off ionizing radiation. This just leaves a rover to deal with still very high ionizing radiation levels and extreme temperature swings that at the equator range between −173 °C and 427 °C, with an 88 Earth day day/night cycle. This compares to the constant mean temperature on Venus of 464 °C.

To deal with these extreme conditions, the researchers propose that a rover might be able to thrive if it sticks to the terminator, being the transition between day and night. To survive, the rover would need to be able to gather enough solar power – if solar-powered – due to the Sun being very low in the sky. It would also need to keep up with the terminator velocity being at least 4.25 km/h, as being caught on either the day or night side of Mercury would mean a certain demise. This would leave little time for casual exploration as on Mars, and require a high level of autonomy akin to what is being pioneered today with the Martian rovers.

Top image: the planet Mercury with its magnetic field. (Credit: A loose necktie, Wikimedia)

Most rhythm games have a community creating custom charts, and Trombone Champ is no exception. What is exceptional, however, [CraftedCart]’s osu! played in a Trombone Champ chart.

It all started as a challenge to make the most unserious chart possible. Among some other ideas, [CraftedCart] eventually decides to make an osu! chart but play it in Trombone Champ. Okay, not a problem, let’s just–oh, you can’t run arbitrary code without a making a mod. So instead, they decided to use shaders on the GPU. There are, of course, all sorts of problems with such an idea. Being stuck in the fixed render pipeline of a game, you can’t just add any resources to your shader you want. This leads to using textures as memory, both the game state and the osu! chart are actually textures. Another interesting one is getting user input into the shader. [CraftedCart] solves that by connecting the position of the game object the background is rendered to to the cursor; then, the shader reads the world to local transform matrix to determine the mouse position. Finally, the graphics the player ends up seeing are rendered using ray marching.

Video after the break.

After users of Battle Born LFP batteries encountered issues such as a heavily discolored positive terminal and other signs of overheating, multiple autopsies showed that the cause appeared to be the insertion of a thermoplastic between the bus bar and the terminal. Over time thermal creep loosened the connections, causing poor contact and melting plastic enclosures. According to Battle Born, this is actually part of an ingenious thermal safety design, and in a recently published article they explain how it works.

The basic theory appears to be that if there’s a thermal event, the ABS thermoplastic will soften and reduce the pressure on the bolted-together copper bus bar and brass terminal. This then allows for an aluminium-oxide layer to form on the aluminium connecting bolt courtesy of the dissimilar copper/aluminium interface. Aluminium-oxide is non-conductive and thus interrupts the flow of current.

Of course, there are countless issues with that theory, least of all the many reports of in-field failures. We recently covered [Will Prowse] studying the death of one of these 100 Ah LFP batteries from brand-new to failure under controlled circumstances. This clearly shows the thermal creep loosening up the connection and causing poor contact between the bus bar, the bolt and the terminal, with poor contact and thermal issues resulting.

Naturally, [Will Prowse] had to address this most recent statement by Battle Born, with the latter taking care to indirectly attack and dismiss his findings. Here Battle Born’s argument seems to hinge on the removal of the lid damaging this aluminium-oxide layer and preventing the ‘thermal safety’ from working, yet not addressed are the many batteries that failed in the field and showed loose connections due to thermal creep from the ABS layer.

It’s also never addressed why these LFP batteries cannot simply be equipped with a traditional thermal fuse rather than this convoluted contraption, among many other questions that remain. Correspondingly [Will] is rather incredulous at this response, as should anyone be who has been following this saga.

Machine screws aren’t made for wood or sheet metal, they make specific screws for those applications. You probably also know there are special screws for plastic. But did you know there are at least two distinct types? In a recent video, [Lost in Tech] show us different types of plastic screws, including thermal camera shots of screws driving into 3D printed parts, along with tests using a torque driver.

We have often used “any old” screw in printed parts, which usually works OK. We’ve also used threaded inserts or captive nuts, classic choices. One of the issues with screws or inserts is that you have to get accurately sized holes in your 3D prints.

In addition to learning about the types of screws and how best to accommodate them, he also developed a free web-based tool that does all the math for you.

Of course, there are cases when you do need a threaded insert. In particular, the plastic screws will tend to wear the plastic each time you insert them. If you expect the screw to go in and out many times, this might not be the right technique for you. On the other hand, if you think you might remove and replace the screws a few dozen times over the life of the part, this might be attractive.

We’ve covered self-tapping screws in plastic before, but, as the video shows, not all of them are created equal. And, of course, there are always heat-set inserts.

Modern technology builds on abstractions. Most application programmers today don’t know what a non-maskable interrupt is, nor should they have to. Even fewer understand register coloring or reservation stations for instruction scheduling, and fewer still can explain the physics behind the transistors in the CPU. Sometimes tech starts out where you need to know everything (programming a bare-metal microprocessor, for example) and then evolves to abstraction. That’s where [WerWolv] wants to get you for writing USB code using the recent post USB for Software Developers.

Many USB tutorials assume you want to know about the intricacies of protocol negotiation, information about the hardware layer, and that you are willing to write a Linux kernel module to provide a driver. But thanks to abstraction, none of this has been absolutely necessary for many use cases for a long time.

While the post focuses on Linux, there is libusb for Windows. We presume the same principles would apply, more or less.

Interestingly, the target device for the tutorial is an Android phone in bootloader mode. We thought that was strange at first, until we read the rationale. You can easily get your hands on an Android phone if you don’t already have one. The device is simple. Plus, it is unlikely you already have drivers installed on your system that would interfere with your tutorial driver. Makes sense.

After that, it is pretty straightforward to use libusb to find the phone, determine what you can do with it, and communicate with it. Sure, the phone’s “fastboot” protocol is simple, but that’s just like using a TCP socket. You may implement a fancy protocol on top of it, but that doesn’t mean sockets are hard to use.

We’ve looked at simplified USB drivers before. Of course, for some applications, you can bend a USB serial port to handle something a bit more complex.

One of the many problems you run into when you work with SMD parts is trying to probe the little tiny pins. While we usually watch [Kerry Wong’s] videos for the oscilloscopes, it makes sense that he’d also be looking for probes. The video below shows some cheap probes from China that can clamp onto tiny QFP pins.

The probes look a little like tiny needles, but the needle part isn’t conductive. When you push them, very tiny and rigid clamps come out. On the other end is a pin that will take a female header or, of course, you could connect another test lead to that pin.

As an example, he shows a decidedly dirty Arduino Due and probes the CPU with the tiny probes. Off camera, he put two probes on adjacent pins on the QFP, and it worked just fine. Definitely something we will add to our toolbox.

The probes appear to work with pitches as small as 0.5mm, which covers many common situations. We’ve looked at oddball probes before. Or try making your own solutions.

For some reason the newly introduced MacBook Neo appears to be the subject of a lot of modding, though a recent mod by [dosdude1] leans into the fact that this laptop has been assembled using what are effectively iPhone 16 parts inside a laptop case. This consequently means that there’s an overlap with certain iPhone 16 components, such as the NAND Flash. Incidentally storage on the Neo is limited to 512 GB when you purchase it from Apple, which is weird since the same SoC in the iPhone 16 Pro happily uses 1 TB.

Even if it was just a price point thing that Apple went for, there’s seemingly nothing standing between a Neo owner with a hot air gun and sheer determination. As long as you’re comfortable soldering a fine-pitched BGA NAND Flash package, natch.

Of course, there was always the possibility that Apple used a different NAND Flash package footprint, but the installed 256 GB model chip that comes installed matches the replacement 1 TB model K8A5 chip as hoped. This just left disassembly and preparing the PCB for a storage replacement. Removal of the BGA underfill and desoldering the old chip without taking out surrounding SMD parts is definitely the hardest part, but handled in the video with the equivalent of an IC spatula and a temporary removal of some capacitors.

Interestingly, the uncovered IC footprint shows a whole perimeter of unused pads that might target other NAND Flash packages. Regardless, the new chip installed fine, giving the Neo 1 TB of storage and a slightly faster read/write performance.