See Voyager’s 1990 ‘Solar System Family Portrait’ Debut

It’s been just over 48 years since Voyager 1 was launched on September 5, 1977 from Cape Canaveral, originally to study our Solar System’s planets. Voyager 1 would explore Jupiter and Saturn, while its twin Voyager 2 took a slightly different route to ogle other planets. This primary mission for both spacecraft completed in early 1990, with NASA holding a press conference on this momentous achievement.

To celebrate the 48th year of the ongoing missions of Voyager 1 and its twin, NASA JPL is sharing an archive video of this press conference. This was the press conference where Carl Sagan referenced the pinpricks of light visible in some images, including Earth’s Pale Blue Dot, which later would become the essay about this seemingly insignificant pinprick of light being the cradle and so far sole hope for the entirety of human civilization.

For most people in attendance at this press conference in June of 1990 it would likely have seemed preposterous to imagine both spacecraft now nearing their half-century of active service in their post-extended Interstellar Mission. With some luck both spacecraft will soon celebrate their 50th launch day, before they will quietly sail on amidst the stars by next decade as a true testament to every engineer and operator on arguably humanity’s most significant achievement in space.

Thanks to [Mark Stevens] for the tip.

Continue reading “See Voyager’s 1990 ‘Solar System Family Portrait’ Debut”

Hosting A Website On A Disposable Vape

For the past years people have been collecting disposable vapes primarily for their lithium-ion batteries, but as these disposable vapes have begun to incorporate more elaborate electronics, these too have become an interesting target for reusability. To prove the point of how capable these electronics have become, [BogdanTheGeek] decided to turn one of these vapes into a webserver, appropriately called the vapeserver.

While tearing apart some of the fancier adult pacifiers, [Bogdan] discovered that a number of them feature Puya MCUs, which is a name that some of our esteemed readers may recognize from ‘cheapest MCU’ articles. The target vape has a Puya PY32F002B MCU, which comes with a Cortex-M0+ core at 24 MHz, 3 kB SRAM and 24 kB of Flash. All of which now counts as ‘disposable’ in 2025, it would appear.

Even with a fairly perky MCU, running a webserver with these specs would seem to be a fool’s errand. Getting around the limited hardware involved using the uIP TCP/IP stack, and using SLIP (Serial Line Internet Protocol), along with semihosting to create a serial device that the OS can use like one would a modem and create a visible IP address with the webserver.

The URL to the vapeserver is contained in the article and on the GitHub project page, but out of respect for not melting it down with an unintended DDoS, it isn’t linked here. You are of course totally free to replicate the effort on a disposable adult pacifier of your choice, or other compatible MCU.

Going Native With Android’s Native Development Kit

Originally Android apps were only developed in Java, targeting the Dalvik Java Virtual Machine (JVM) and its associated environment. Compared to platforms like iOS with Objective-C, which is just C with Smalltalk uncomfortably crammed into it, an obvious problem here is that any JVM will significantly cripple performance, both due to a lack of direct hardware access and the garbage-collector that makes real-time applications such as games effectively impossible. There is also the issue that there is a lot more existing code written in languages like C and C++, with not a lot of enthusiasm among companies for porting existing codebases to Java, or the mostly Android-specific Kotlin.

The solution here was the Native Development Kit (NDK), which was introduced in 2009 and provides a sandboxed environment that native binaries can run in. The limitations here are mostly due to many standard APIs from a GNU/Linux or BSD environment not being present in Android/Linux, along with the use of the minimalistic Bionic C library and APIs that require a detour via the JVM rather than having it available via the NDK.

Despite these issues, using the NDK can still save a lot of time and allows for the sharing of mostly the same codebase between Android, desktop Linux, BSD and Windows.

Continue reading “Going Native With Android’s Native Development Kit”

Reverse-Engineering Aleratec CD Changers For Archival Use

Handling large volumes of physical media can be a bit of a chore, whether it’s about duplication or archiving. Fortunately this is a perfect excuse for building robotic contraptions, with the robots for handling optical media being both fascinating and mildly frustrating. When [Shelby Jueden] of Tech Tangents fame was looking at using these optical media robots for archival purposes, the biggest hurdle turned out to be with the optical drives, despite these Aleratec units being primarily advertised for disc duplication.

Both of the units are connected to a PC by USB, but operate mostly standalone, with a documented protocol for the basic unit that makes using it quite easy to use for ripping. This is unlike the larger, triple-drive unit, which had no documented protocol. This meant having to sniff the USB traffic that the original, very limited, software sends to the robot. The protocol has now been documented and published on the Tech Tangents Wiki for this Aleratec Auto Publisher LS.

Where [Shelby] hit a bit of a brick wall was with mixed-media discs, which standalone DVD players are fine with, but typical IDE/SATA optical drives often struggle with. During the subsequent search for a better drive, the internals of the robot were upgraded from IDE to SATA, but calibrating the robot for the new drives led [Shelby] down a maddening cascade of issues. Yet even after making one type of drive work, the mixed-media issue reared its head again with mixed audio and data, leaving the drive for now as an imperfect, but very efficient, ripper for game and multimedia content, perhaps until the Perfect Optical Drive can be found.

Continue reading “Reverse-Engineering Aleratec CD Changers For Archival Use”

Reverse-Engineering The Milwaukee M18 Diagnostics Protocol

As is regrettably typical in the cordless tool world, Milwaukee’s M18 batteries are highly proprietary. Consequently, this makes them a welcome target for reverse-engineering of their interfaces and protocols. Most recently the full diagnostic command set for M18 battery packs were reverse-engineered by [ToolScientist] and others, allowing anyone to check useful things like individual cell voltages and a range of statistics without having to crack open the battery case.

These results follow on our previous coverage back in 2023, when the basic interface and poorly checksummed protocol was being explored. At the time basic battery management system (BMS) information could be obtained this way, but now the range of known commands has been massively expanded. This mostly involved just brute-forcing responses from a gaggle of battery pack BMSes.

Interpreting the responses was the next challenge, with responses like cell voltage being deciphered so far, but serial number and the like being harder to determine. As explained in the video below, there are many gotchas that make analyzing these packs significantly harder, such as some reads only working properly if the battery is on a charger, or after an initial read.

Continue reading “Reverse-Engineering The Milwaukee M18 Diagnostics Protocol”

3D Modeling With Paper As An Alternative To 3D Printing

Manual arrangement of the parts in Pepakura Designer. (Credit: Arvin Podder)
Manual arrangement of the parts in Pepakura Designer. (Credit: Arvin Podder)

Although these days it would seem that everyone and their pets are running 3D printers to churn out all the models and gadgets that their hearts desire, a more traditional approach to creating physical 3D models is in the form of paper models. These use designs printed on paper sheets that are cut out and assembled using basic glue, but creating these designs is much easier these days, as [Arvin Poddar] demonstrates in a recent article.

The cool part about making these paper models is that you create them from any regular 3D mesh, with any STL or similar file from your favorite 3D printer model site like Printables or Thingiverse being fair game, though [Arvin] notes that reducing mesh faces can be trickier than modelling from scratch. In this case he created the SR-71 model from scratch in Blender, featuring 732 triangles. What the right number of faces is depends on the target paper type and your assembly skills.

Following mesh modelling step is mesh unfolding into a 2D shape, which is where you have a few software options, like the paid-for-but-full-featured Pepakura Designer demonstrated, as well as the ‘Paper Model’ exporter for Blender.

Beyond the software used to create the SR-71 model in the article, the only tools you really need are a color printer, paper, scissor,s and suitable glue. Of course you are always free to use fancier tools than these to print and cut, but the bar here is pretty low for the assembly. Although making functional parts isn’t the goal here, there is a lot to be said for paper models for pure display pieces and to get children interested in 3D modelling.

Running Code On A PAX Credit Card Payment Machine

The PAX D177 PoS terminal helpfully tells you which tamper points got triggered. (Credit: Lucas Teske)
The PAX D177 PoS terminal helpfully tells you which tamper points got triggered. (Credit: Lucas Teske)

These days Points of Sale (PoS) usually include a digital payment terminal of some description, some of which are positively small, such as the Mini PoS terminals that PAX sells. Of course, since it has a CPU and a screen it must be hacked to run something else, and maybe discover something fun about the hardware in the process. Thus [Lucas Tuske] set out to do exactly this with a PAX D177 PoS, starting with purchasing three units: one to tear apart, one to bypass tamper protections on and one to keep as intact reference.

As expected, there are a few tamper protections in place, starting with pads that detect when the back cover is removed and a PCB that’s densely covered in fine traces to prevent sneaky drilling. Although tripping the tamper protections does not seem to affect the contents of the Flash, the firmware is signed. Furthermore the secrets like keys that are stored in NVRAM are purged, rendering the device effectively useless to any attacker.

The SoC that forms the brains of the whole operations is the relatively obscure MH1903, which is made by MegaHunt and comes in a dizzying number of variants that are found in applications like these PoS terminals. Fortunately the same SoC is also found on a development board with the AIR105 MCU that turns out to feature the same MH1903 core. These are ARM Cortex-M3 cores, which makes targeting them somewhat easier.

Rather than try to break the secure boot of the existing SoC, [Lucas] opted to replace the SoC package with a brand new one, which was its own adventure. Although one could say that this is cheating, it made getting a PoC of custom code running on one of these devices significantly easier. In a foll0w-up article [Lucas] expects to have Doom running on this device before long.