In-space manufacturing is a big challenge, even with many of the same manufacturing methods being available as on the ground. These methods include rivets, bolts, but also welding, the latter of which was first attempted fifty years ago by Soviet cosmonauts. In-space welding is the subject of a recently announced NASA collaboration. The main aspects to investigate are the effects of reduced gravity and varying amounts of atmosphere on welds.

The Soviets took the lead in space welding when they first performed the feat during the Soyuz-6 mission in 1969. NASA conducted their own welding experiments aboard Skylab in 1973, and in 1984, the first (and last) welds were made in open space during an EVA on the Salyut-7 mission. This time around, NASA wants to investigate fiber laser-based welding, as laid out in these presentation slides. The first set of tests during parabolic flight maneuvers were performed in August of 2024 already, with further testing in space to follow.

Back in 1996 NASA collaborated with the E.O. Paton Welding Institute in Kyiv, Ukraine, on in-space welding as part of the ISWE project which would have been tested on the Mir space station, but manifesting issues ended up killing this project. Most recently ESA has tested in-space welding using the same electron-beam welding (EBW) approach used by the 1969 Soyuz-6 experiment. Electron beam welding has the advantage of providing great control over the weld in a high-vacuum environment such as found in space.

So why use laser beam welding (LBW) rather than EBW? EBW obviously doesn’t work too well when there is some level of atmosphere, is more limited with materials and has as only major advantage that it uses less power than LBW. As these LBW trials move to space, they may offer new ways to create structure and habitats not only in space, but also on the lunar and Martian surface.

Featured image: comparing laser beam welding with electron beam welding in space. (Source: E. Choi et al., OSU, NASA)

Within the world of CAD there are the well-known and more niche big commercial players and there are projects like FreeCAD that seek to bring a OSS solution to the CAD world. As with other OSS projects like the GIMP, these OSS takes on commercial software do not always follow established user interactions (UX), which is where Ondsel sought to bridge the gap by giving commercial CAD users a more accessible FreeCAD experience. This effort is now however at an end, with a blog post by Ondsel core team member [Brad Collette] providing the details.

The idea of commercializing OSS is by no means novel, as this is what Red Hat and many others have done for decades now. In our article on FOSS development bounties we touched upon the different funding models for FOSS projects, with the Linux kernel enjoying strong commercial support. The trick is of course to attract such commercial support and associated funding, which is where the development on the UI/UX and feature set of the core FreeCAD code base was key. Unfortunately the business case was not strong enough to attract such commercial partners and Ondsel has been shutdown.

As also discussed on the FreeCAD forum, the Ondsel codebase will likely be at least partially merged into the FreeCAD code, ending for now the prospect of FreeCAD playing in the big leagues with the likes of AutoCAD.

Thanks to [Brian Harrington] for the tip.

In a new installment on computer history, [Bradford Morgan White] takes us through the sordid history of Cyrix, as this plucky little company created the best math co-processors (FasMath) and then a range of interesting x86-compatible CPUs that would give competing x86 CPUs a run for their money. Even though Cyrix played by the rules of licensing agreements, Intel would keep suing Cyrix repeatedly since the 1980s well into 1990s, for a total of seventeen times until Cyrix counter-sued for patent violations in May of 1997.

This case was settled between Cyrix and Intel, with a cross-licensing agreement established. Unfortunately these mounting legal costs and the stresses of keeping up with the competition (i.e. Intel) was proving too much and Cyrix was sold off to National Semiconductor, who wasn’t enthusiastic about competing with Intel. After this Cyrix got split up into Geode (sold to AMD) and Cyrix Technologies (sold to VIA). Interestingly, VIA’s x86 patent licenses and patents ended up being the foundation of Zhaoxin: a joint venture between VIA and Shanghai’s government which produces x86 CPUs for primarily the Chinese market.

We looked at the Cyrix Cx486DLC processor a while ago, and why their 386 upgrade options were perhaps not that great. Their later CPUs have however left a strong legacy that seems to endure in some way to this day.

On November 5th, the United States launched an LGM-30G Minuteman III ICBM from Vandenberg Space Force Base in California. Roughly 30 minutes later the three warheads onboard struck their targets 4,200 miles (6,759 km) away at the Reagan Test Site in the Marshall Islands. What is remarkable about this test is not that one of these ICBMs was fired — as this is regularly done to test the readiness of the US’ ICBMs — but rather that it carried three warheads instead of a single one.

Originally the Minuteman III ICBMs were equipped with three warheads, but in 2014 this was reduced to just one as a result of arms control limits agreed upon with Russia. This New Start Treaty expires in 2026 and the plan is to put three warheads back in the 400 operational Minuteman III ICBMs in the US’ arsenal. To this end a validation test had to be performed, yet a 2023 launch failed. So far it appears that this new launch has succeeded.

Although the three warheads in this November 5 launch were not nuclear warheads but rather Joint Test Assemblies, one of them contained more than just instrumentation to provide flight telemetry. In order to test the delivery vehicle more fully a so-called ‘high-fidelity’ JTA was also used which is assembled much like a real warhead, including explosives. The only difference being that no nuclear material is present, just surrogate materials to create a similar balance as the full warhead.

Assuming the many gigabytes of test data checks out these Minuteman III ICBMs should be ready to serve well into the 2030s at which point the much-delayed LGM-35 Sentinel should take over.

We usually think of a hydraulic system as fully self-contained, with a hydraulic pump, tubing, and actuators filled with a working fluid. This of course adds a lot of weight and complexity that can be undesirable in certain projects, with the Saturn V Moon rocket demonstrating a solution to this which is still being used to this day. In a blast-from-the-past, a December 1963 article originally published in Hydraulics & Pneumatics details the kerosene-based hydraulics (fueldraulics) system for the S-1C stage’s gimbal system that controlled the four outer engines.

Rather than a high-pressure, MIL-H-5606 hydraulic oil-based closed loop as in the Saturn I, this takes kerosene from the high-pressure side of the F1 rocket engine’s turbopump and uses it in a single-pass system. This cuts out a separate hydraulic pump, a hydraulic reservoir, which was mostly beneficial in terms of reducing points of failure (and leaks), ergo increasing reliability. Such was the theory at the time at least, and due to issues with RP-1 kerosene’s relatively low flash point and differences in lubricity properties, ultimately RJ-1, RP-1 and MIL-H-5606 were used during checkout leading up to the launch.

In hindsight we know that this fueldraulic system worked as intended with all Saturn V launches, and today it’s still used across a range of aircraft in mostly jet engines and actuators elsewhere of the Boeing 777 as well as the F-35. In the case of the latter it only made the news when there was an issue that grounded these jets due to badly crimped lines. Since fueldraulics tends to be lower pressure, this might be considered a benefit in such cases too, as anyone who has ever experienced a hydraulic line failure can attest to.

Featured image: Gimbal systems proposed for the F-1, oxygen-kerosene engine with a fueldraulic system. (Source: Hydraulics & Pneumatics, 1963)

After extracting all the useful stuff from a mine, you are often left with a lot of empty subterranean space without a clear purpose. This was the case with the Bethany Falls limestone mine, near Kansas City, Missouri, which left a sprawling series of caverns supported by 16′ (4.9 meter) diameter pillars courtesy of the used mining method. As detailed by [Benjamin Hunting] in a recent article on the Hagerty site, this made it a fascinating place for a  business complex development now called SubTropolis that among other things is used for car storage by Ford and long-term stamp storage by the US Post Office. (Check out their cool period photos!)

The reason for this is the extremely stable climate within these man-made caverns, with relative humidity hovering around a comfortable 40% and temperatures stable year-round at about 21 °C (70 °F), making it ideal for storing anything that doesn’t like being placed outdoors, while saving a lot on airconditioning costs. With Ford one of the biggest companies in SubTropolis, this means that many companies providing customization services for vehicles have also moved operations inside the complex.

With the only negative being a lack of daylight, it seems like the perfect place for many businesses and (evil) lairs, assuming electrical power and constant air circulation are provided.

Featured image: “Subtropolis” by [ErgoSum88]

Building a paper tape reader by itself isn’t super complicated: you need a source of light, some photoreceptors behind the tape to register the presence of holes and some way to pull the tape through the reader at a reasonable rate. This latter part can get somewhat tricky, as Usagi Electric‘s [David Lovett] discovered while adding this feature to his vacuum tube-era DIY reader. This follows on what now seems like a fairly simple aspect of the photosensors and building a way to position said photosensors near the paper tape.

As the feed rate of the paper tape is tied to the reading speed, and in the case of [David]’s also contains the clock for the custom tube-based UE1 computer, it determines many of the requirements. With 8 bits per line, the tape forms the ROM for the system, all of which has to be executed and used immediately when read, as there is no RAM to load instructions into. This also necessitates the need to run the tape as an endless loop, to enable ‘jumping’ between parts of this paper-based ROM by simple masking off parts of the code until the desired address is reached.

For the motor a slot car motor plus speed-reduction gear was chosen, with a design to hold these then designed in FreeCAD. Courtesy of his brother’s hobby machine shop and a CAD professional’s help, producing these parts was very easy, followed by final assembly. Guides were added for the tape, not unlike with a cassette player, which allowed the tape to be pulled through smoothly. Next up is wiring up the photodiodes, after which theoretically the UE1 can roar into action directly running programs off paper tape.

It is a fact of life that 3D-printed parts from an FDM (fused deposition modeling) printer have weaknesses where the layers join. Some of this is due to voids and imperfect layer bonding, but you can — as [Geek Detour] shows us — work around some of this. In particular, it is possible to borrow techniques from brick laying to create a pattern of alternating blocks. You can check out the video below.

The idea of ‘brick layers’ with FDM prints was brought to the forefront earlier this year by [Stefan] of CNC Kitchen. Seven months after that video you still can’t find the option for these layers in any popular slicers. Why? Because of  a 2020 patent filed for this technique by a 3D printing company which offers this feature in its own slicer. But is this patent even valid?

Considering the obviousness and that FDM printing hardly began in the 2000s, it’s no surprise that prior art already exists in the form of a 1995 Stratasys patent. The above image shows an excerpt from the 1995 Stratasys patent, covering the drawings of FDM layers, including brick layers. This covered all such ways of printing, but the patent expired in 2016. In 2019, a PrusaSlicer ticket was opened, requesting this feature. So what happened? A second patent filed in 2020 assigned to Addman Intermediate Holdings: US11331848B2.

This 2020 patent turns out to cover effectively the same claims as the Stratasys patent. Hilariously, the 2020 patent references the Stratasys patent but proceeds to give the wrong patent ID, a pattern that persists with other referenced patents in the same text, making one question who wrote (and verified) the patent.

Clearly, the patent offices involved did not do due diligence, and this new patent is obviously invalid. Yet unless it is invalidated, presumably by challenging it in court, we will have to wait until 2040 before we, too, can print brick layers with our FDM machines.

This isn’t the first time patents have blocked 3D-printed innovation. Or given credit to the wrong inventor.

A characteristic of any thermal power plant — whether using coal, gas or spicy nuclear rocks — is that they have a closed steam loop with a condenser section in which the post-turbine steam is re-condensed into water. This water is then led back to the steam generator in the plant. There are many ways to cool the steam in the condenser, including directly drawing in cooling water from a nearby body of water. The most common and more efficient way is to use a cooling tower, with a recent video by [Practical Engineering] explaining the physics behind these.

For the demonstration, a miniature natural draft tower is constructed in the garage from sheets of acrylic. This managed to cool 50 °C water down to 20 °C by merely spraying the hot water onto a mesh that maximizes surface area. The resulting counter-flow means that no fan or the like is needed, and the hyperboloid shape of the cooling tower makes it incredibly strong despite having relatively thin walls.

The use of a natural draft tower makes mostly sense in cooler climates, while in hotter climates having a big cooling lake may make more sense. We covered the various ways to cool thermal plants before, including direct intake, spray ponds, cooling towers and water-free cooling solutions, with the latter becoming a feature of new high-temperature fission reactor designs.

Generally when assuming a chaotic (i.e. random) system like an undirected graph, we assume that if we start coloring these (i.e. assign values) with two colors no real pattern emerges. Yet it’s been proven that if you have a graph with a certain set of vertices, coloring the resulting lines in this manner will always result in a clique forming. This phenomenon has been investigated for nearly a century now after its discovery by British mathematician [Frank P. Ramsey].

The initial discovery concerned a graph with 6 vertices, providing the lowest number of vertices required. Formally this is written as R(3, 3), with subsequent cases of these Ramsey numbers discovered. They are part of Ramsey theory, which concerns itself with the question of what the underlying properties are that cause this apparent order to appear, which requires us to discover more cases.

Finding the number for a particular instance of R(m, n) can be done the traditional way, or brute-forcing it computationally. Over the decades more advanced algorithms have been developed to help with the search, and people from different fields are mingling as they are drawn to this problem. So far the pay-off of this search are these algorithms, the friendships created and perhaps one day a deep insight in the causes behind this phenomenon that may have implications for physics, chemistry and other fields.

We have seen a recent surge of interest in whether it’s possible to grow potatoes and other plants in Martian soil, but what is the likelihood that a future (manned) lunar base could do something similar? To that end [Space Lab] is developing the LEAF project that will be part of NASA’s upcoming Artemis III lunar mission. This mission would be the first to have Americans return to the Moon by about 2028, using the somewhat convoluted multi-system SLS-Starship-Lunar Gateway trifecta. The LEAF (Lunar Effects on Agricultural Flora) science module will feature three types of plants (rape (Brassica Rapa), duckweed and cress (Arabidopsis thaliana) ) in an isolated atmosphere.

The main goal of this project is to find out how the plants are affected by the lunar gravity, radiation and light levels at the landing site at the south pole. This would be the equivalent of a hydroponics setup in a lunar base. After about a week of lunar surface time the growth chamber will be split up into two: one returning back to Earth for examination and the other remains on the surface to observe their long-term health until they perish from cold or other causes.

This is not the first time that growing plants on the lunar surface has been attempted, with China’s Chang’e 4 mission from 2019. The lander’s Lunar Micro Ecosystem featured a range of seeds as well, which reportedly successfully sprouted, but the project was terminated after 9 days instead of the planned 100 due to issues with heating the biosphere during the brutal -52°C lunar night. Hopefully LEAF can avoid this kind of scenario when it eventually is deployed on the Moon.

It’s been about a decade since Amazon began to fly its delivery drones, aiming to revolutionize the online shopping experience with rapid delivery of certain items. Most recently Amazon got permission from the FAA to not only start flying from its new Arizona-based location, but also to fly beyond-line-of-sight (BLOS) missions with the new MK30 drone. We reported on this new MK30 drone which was introduced earlier this year along with the news of the Amazon Prime Air delivery service ceasing operations in California and moving them to Arizona instead.

This new drone has got twice the range as the old MK27 drone that it replaces and is said to be significantly quieter as well. The BLOS permission means that the delivery drones can service areas which are not directly visible from the warehouse with its attached drone delivery facility. With some people within the service range of the MK27 drones having previously complained about the noise levels, we will see quickly enough whether the MK30 can appease most.

As for the type of parcels you can have delivered with this service, it is limited to 2.27 kg (~5 lbs), which is plenty for medication and a range of other items where rapid delivery would be desirable.

Each year millions of old smartphones are either tossed as e-waste or are condemned to lie unloved in dusty drawers, despite the hardware in them usually being still perfectly fine. Reusing these little computers for another purpose once the phone’s manufacturer drops support is made hard by a range of hardware and software (driver) issues. One possible way to do so is suggested by [Doctor Volt] in a video where a Samsung Galaxy S4 is combined with a USB-connected FT232R board to add external GPIO.

The idea is pretty simple: the serial adapter is recognized by the existing Android OS and within the standard Android development environment this module can be used. Within this demonstrator it’s merely used to blink some LEDs and react to inputs, but it shows how to reuse one of these phones in a non-destructive manner. Even better is that the phone’s existing sensors and cameras can still be used as normal in this way, too, which opens a whole range of (cheap) DIY projects that can be programmed either in Java/Kotlin or in C or C++ via the Native Development Kit.

The only wrinkle is that while the phone is connected like this, charging is not possible. For the S4 it’s easy to solve as it has a removable battery, so an external power input was wired in with a dummy battery-sized bit of perfboard. With modern phones without removable batteries simultaneous USB/audio dongle and charging usage via the USB-C connector is claimed to be possible, but this is something to check beforehand.

How easy is it to build your own Digital to Analog Converter (DAC)? Although you can readily purchase a wide variety of DACs these days, building your own can be very instructive, as the [Sine Lab] on YouTube explores in a recent video with the construction of a discrete 14-bit DAC. First there are the different architectures you can pick for a DAC, which range from R-2R (resistor ladder) to delta-sigma versions, each having its own level of complexity and providing different response times, accuracy and other characteristics.

The architecture that the [Sine Lab] picked was a String DAC with interpolator. The String type DAC has the advantage of having inherently monotonic output voltage and better switching-induced glitch performance than the R-2R DAC. At its core it still uses resistors and switches (transistors), with the latter summing up the input digital value. This makes adding more bits to the DAC as easy as adding more of these same resistors and switches, the only question is how many. In the case of a String DAC that’d be 2^N, which implies that you want to use multiple strings, as in the above graphic.

Scaling this up to 16-bit would thus entail 65,536 resistors/switches in the naive approach, or with 2 8-bit strings 513 switches, 512 resistors and 2 buffers. In the actual design in the video both MOSFETs and 74HCT4051 multiplexers were used, which also necessitated creating two buses per string to help with the input decoding. This is the part where things get serious in the video, but the reasoning for each change and addition is explained clearly as the full 6-bit DAC with interpolator is being designed and built.

One big issue with discrete DACs comes when you have to find matching MOSFETs and similar, which is where LSI DACs are generally significantly more precise. Even so, this discrete design came pretty close to a commercial offering, which is pretty impressive.

Artificial intelligence has always been around us, with [Timothy J. O’Malley]’s 1985 book on AI projects for the Commodore 64 being one example of this. With AI defined as being the theory and development of systems that can perform tasks that normally requiring human intelligence (e.g. visual perception, speech recognition, decision-making), this book is a good introduction to the many ways that computer systems for decades now have been able to learn, make decisions and in general become more human-like. Even if there’s no electronic personality behind the actions.

In the book’s first chapter, [Timothy] isn’t afraid to toss in some opinions about the true nature of intelligence and thinking. Starting with the concept that intelligence is based around storing information and being able to derive meaning from connections between stored pieces of information, the idea of a basic AI as one would use in a game for the computer opponent arises. A number of ways of implementing such an AI is explored in the first and subsequent chapters, using Towers of Hanoi, chess, Nim and other games.

After this we look at natural language processing – referencing ELIZA as an example – followed by heuristics, pattern recognition and AI for robotics. Although much of this may seem outdated in this modern age of LLMs and neural networks, it’s important to realize that much of what we consider ‘bleeding edge’ today has its roots in AI research performed in the 1950s and 1960s. As [Timothy] rightfully states in the final chapter, there is no real limit to how far you can push this type of AI as long as you have more hardware and storage to throw at the problem. This is where we now got datacenters full of GPU-equipped systems churning through vector space calculations for the sake of today’s LLM & diffusion model take on ‘AI’.

Using a Commodore 64 to demonstrate the (lack of) validity of claims is not a new one, with recently a group of researchers using one of these breadbin marvels to run an Ising model with a tensor network and outperforming IBM’s quantum processor. As they say, just because it’s new and shiny doesn’t necessarily mean that it is actually better.

Many MacOS users are probably used by now to the annoyance that comes with unsigned applications, as they require a few extra steps to launch them. This feature is called Gatekeeper and checks for an Apple Developer ID certificate. Starting with MacOS Sequoia 15, the easy bypassing of this feature with e.g. holding Control when clicking the application icon is now no longer an option, with version 15.1 disabling ways to bypass this completely. Not unsurprisingly, this change has caught especially users of open source software like OpenSCAD by surprise, as evidenced by a range of forum posts and GitHub tickets.

The issue of having to sign applications you run on MacOS has been a longstanding point of contention, with HomeBrew applications affected and the looming threat for applications sourced from elsewhere, with OpenSCAD issue ticket #880 from 2014 covering the saga for one OSS project. Now it would seem that to distribute MacOS software you need to have an Apple Developer Program membership, costing $99/year.

So far it appears that this forcing is deliberate on Apple’s side, with the FOSS community still sorting through possible workarounds and the full impact.

Thanks to [Robert Piston] for the tip.

While most operating systems are written in C and C++, KolibriOS is written in pure x86 assembly and as a result small and lightweight enough to run off a standard 1.44 MB floppy disk, as demonstrated in a recent video by [Michael].

As a fork of 32-bit MenuetOS back in 2004, KolibriOS has since followed its own course, sticking to the x86 codebase and requiring only a modest system with an i586-compatible CPU, 8 MB of RAM and VESA-compatible videocard. Unlike MenuetOS’ proprietary x86_64 version, there’s no 64-bit in KolibriOS, but at this level you probably won’t miss it.

In the video by [Michael], the OS boots incredibly fast off both a 3.5″ floppy and a CD-ROM, with the CD-ROM version having the advantage of more software being provided with it, including shareware versions of DOOM and Wolfenstein 3D.

Although web browsers (e.g. Netsurf) are also provided, [Michael] did not get Ethernet working, though he doesn’t say whether he checked the hardware compatibility list. Quite a few common 3Com, Intel and Realtek NICs are supported out of the box.

For audio it was a similar story, with the hardware compatibility left unverified after audio was found to be not working. Despite this, the OS was fast, stable, runs DOOM smoothly and overall seems to be a great small OS for x86 platforms that could give an old system a new lease on life.

Most of us will probably have seen Nintendo’s latest gadget pop up recently. Rather than a Switch 2 announcement, we got greeted with a Nintendo-branded alarm clock. Featuring a 2.8″ color LCD and a range of sensors, it can detect and respond to a user, and even work as an alarm clock for the low, low price of €99. All of which takes the form of Nintendo-themed characters alongside some mini-games. Naturally this has led people like [Gary] to buy one to see just how hackable these alarm clocks are.

As can be expected from a ‘smart’ alarm clock it has 2.4 GHz WiFi connectivity for firmware and content download, as well as a 24 GHz millimeter wave presence sensor. Before [Gary] even had received his Alarmo, others had already torn into their unit, uncovering the main MCU (STM32H730ZBI6) alongside a 4 GB eMMC IC, as well as the MCU’s SWD pads on the PCB. This gave [Gary] a quick start with reverse-engineering, though of course the MCU was protected (readout protection, or RDP) against firmware dumps, but the main firmware could be dumped from the eMMC without issues.

After this [Gary] had a heap of fun decrypting the firmware, which seems to always get loaded into the external octal SPI RAM before execution, as per the boot sequence (see featured image). This boot sequence offers a few possibilities for inserting one’s own (properly signed) contents. As it turns out via the USB route arbitrary firmware binaries can be loaded, which provided a backdoor to defeat RDP. Unfortunately the MCU is further locked down with Secure Access Mode, which prevents dumping the firmware again.

So far firmware updates for the Alarmo have not nailed shut the USB backdoor, making further reverse-engineering quite easy for the time being. If you too wish to hack your Alarmo and maybe add some feline charm, you can check [Gary]’s GitHub project.

We have probably all seen the marketing blurbs on packaging and elsewhere promoting the amazing lifespan of LED lighting solutions. Theoretically you should be able to install a LED bulb in a fixture that used to hold that incandescent lightbulb which had to be replaced annually and have it last a decade or longer. Yet we seem to replace these LED bulbs much more often than that, with them suffering a range of issues. To get to the root cause of this, [The Doubtful Technician] decided to perform an autopsy on a couple of dead lightbulbs which he got from a variety of sources and brands.

One lamp is an Amazon-bought one from a seller who seems to have vanished, but was promised over 3 years of constant use. Other than the fun of blinding of oneself while testing, this one was easy to diagnose, with a dodgy solder joint on a resistor in a MELF package. The next one from Lowes was very dim, and required popping open with some gentle force, which revealed as likely culprit a shorted SMD resistor. Finally a more substantial (i.e. heavier) bulb was tested which had survived about 7 years in the basement until it and its siblings began to suddenly die. Some might consider this the normal lifespan, but what really failed in them?

The electronics in this last bulb were the most impressive, with a full switch mode power supply (SMPS) that appears to have suffered a failure. Ultimately the pattern with these three bulbs was that while the LEDs themselves were still fine, it were things like the soldering joints and singular components on the LED driver PCB that had failed. Without an easy way to repair these issues, and with merely opening the average LED lightbulb being rather destructive, this seems like another area where what should be easy repairs are in fact not, and more e-waste is created.