Linux Fu: The USB WiFi Dongle Exercise

The TX50U isn’t very Linux-friendly

If you’ve used Linux for a long time, you know that we are spoiled these days. Getting a new piece of hardware back in the day was often a horrible affair, requiring custom kernels and lots of work. Today, it should be easier. The default drivers on most distros cover a lot of ground, kernel modules make adding drivers easier, and dkms can automate the building of modules for specific kernels, even if it isn’t perfect.

So ordering a cheap WiFi dongle to improve your old laptop’s network connection should be easy, right? Obviously, the answer is no or this would be a very short post.

Plug and Pray

The USB dongle in question is a newish TP-Link Archer TX50U. It is probably perfectly serviceable for a Windows computer, and I got a “deal” on it. Plugging it in caused it to show up in the list of USB devices, but no driver attached to it, nor were any lights on the device blinking. Bad sign. Pro tip: lsusb -t will show you what drivers are attached to which devices. If you see a device with no driver, you know you have a problem. Use -tv if you want a little more detail.

The lsusb output shows the devices as a Realtek, so that tells you a little about the chipset inside. Unfortunately, it doesn’t tell you exactly which chip is in use.

Continue reading “Linux Fu: The USB WiFi Dongle Exercise”

Success With FreeDOS On A Modern Platform

Last summer we took a look at FreeDOS as part of the Daily Drivers series, and found a faster and more complete successor to the DOS of old. The sojourn into the 16-bit OS wasn’t perfect though, as we couldn’t find drivers for the 2010-era network card on our newly DOS-ified netbook. Here’s [Inkbox] following the same path, and bringing with it a fix for that networking issue.

The video below is an affectionate look at the OS alongside coding a TRON clone in assembler, and it shows a capable environment within the limitations of the 16-bit mode. The modern laptop here can’t emulate a BIOS as it’s UEFI only, and after trying a UEFI-to-BIOS emulator with limited success, he hits on a different approach. With just enough Linux to support QEMU, he has a lightweight and extremely fast x86 BIOS platform with the advantage of legacy emulation of network cards and the like.

The point of Daily Drivers is wherever possible to use real hardware and not an emulator, as it’s trying to be the machine you’d use day to day. But we can see in a world where a BIOS is no longer a thing it becomes ever more necessary to improvise, and this approach is better than just firing up an emulator from a full-fat Linux desktop. If you fancy giving it a try, it seems less pain than the route we took.

You can read our look at FreeDOS 1.4 here.

Continue reading “Success With FreeDOS On A Modern Platform”

New Artemis Plan Returns To Apollo Playbook

In their recent announcement, NASA has made official what pretty much anyone following the Artemis lunar program could have told you years ago — humans won’t be landing on the Moon in 2028.

It was always an ambitious timeline, especially given the scope of the mission. It wouldn’t be enough to revisit the Moon in a spidery lander that could only hold two crew members and a few hundred kilograms of gear like in the 60s. This time, NASA wants to return to the lunar surface with hardware capable of setting up a sustained human presence. That means a new breed of lander that dwarfs anything the agency, or humanity for that matter, has ever tried to place on another celestial body.

Unsurprisingly, developing such vehicles and making sure they’re safe for crewed missions takes time and requires extensive testing. The simple fact is that the landers, being built by SpaceX and Blue Origin, won’t be ready in time to support the original Artemis III landing in 2028. Additionally, development of the new lunar extravehicular activity (EVA) suits by Axiom Space has fallen behind schedule. So even if one of the landers would have been ready to fly in 2028, the crew wouldn’t have the suits they need to actually leave the vehicle and work on the surface.

But while the Artemis spacecraft and EVA suits might be state of the art, NASA’s revised timeline for the program is taking a clear step back in time, hewing closer to the phased approach used during Apollo. This not only provides their various commercial partners with more time to work on their respective contributions, but critically, provides an opportunity to test them in space before committing to a crewed landing.

Continue reading “New Artemis Plan Returns To Apollo Playbook”

Creating An Ultra-Stable Lunar Clock With A Cryogenic Silicon Cavity Laser

Phase-coherent lasers are crucial for many precision tasks, including timekeeping. Here on Earth the most stable optical oscillators are used in e.g. atomic clocks and many ultra-precise scientific measurements, such as gravitational wave detection. Since these optical oscillators use cryogenic silicon cavities, it’s completely logical to take this principle and build a cryogenic silicon cavity laser on the Moon.

In the pre-print article by [Jun Ye] et al., the researchers go through the design parameters and construction details of such a device in one of the permanently shadowed regions (PSRs) of the Moon, as well as the applications for it. This would include the establishment of a very precise lunar clock, optical interferometry and various other scientific and telecommunication applications.

Although these PSRs are briefly called ‘cold’ in the paper’s abstract, this is fortunately quickly corrected, as the right term is ‘well-insulated’. These PSRs on the lunar surface never get to warm up due to the lack of an atmosphere to radiate thermal energy, and the Sun’s warm rays never pierce their darkness either. Thus, with some radiators to shed what little thermal energy the system generates and the typical three layers of thermal shielding it should stay very much cryogenic.

Add to this the natural vacuum on the lunar surface, with PSRs even escaping the solar wind’s particulates, and maintaining a cryogenic, ultra-high vacuum inside the silicon cavity should be a snap, with less noise than on Earth. Whether we’ll see this deployed to the Moon any time soon remains to be seen, but with various manned missions and even Moon colony plans in the charts, this could be just one of the many technologies to be deployed on the lunar surface over the next few decades.

Front and back of the prototype phone

Neither Android Nor IOS: DIY Smartphone Runs On ESP32!

You may or may not be reading this on a smartphone, but odds are that even if you aren’t, you own one. Well, possess one, anyway — it’s debatable if the locked-down, one-way relationships we have with our addiction slabs counts as ownership. [LuckyBor], aka [Breezy], on the other hand — fully owns his 4G smartphone, because he made it himself.

OK, sure, it’s only rocking a 4G modem, not 5G. But with an ESP32-S3 for a brain, that’s probably going to provide plenty of bandwidth. It does what you expect from a phone: thanks to its A7682E simcom modem, it can call and text. The OV2640 Arducam module allows it to take pictures, and yes, it surfs the web. It even has features certain flagship phones lack, like a 3.5 mm audio jack, and with its 3.5″ touchscreen, the ability to fit in your pocket. Well, once it gets a case, anyway.

Continue reading “Neither Android Nor IOS: DIY Smartphone Runs On ESP32!”

Old Desk Phone Gets DOOM Port

Old desk phones are fairly useless these days unless you’re building a corporate PBX in your house. However, they can be fun to hack on, as [0x19] demonstrates by porting DOOM to a Snom 360 office phone. 

The Snom 360 is a device from the early VoIP era, with [ox19] laying their hands on some examples from 2005. The initial plan was just to do some telephony with Asterisk, but [ox19] soon realized more was possible. Digging into a firmware image revealed the device ran a Linux kernel on a MIPS chip, so the way forward became obvious.

They set about hacking the phone to run DOOM on its ancient single-color LCD. Doing so was no mean feat. It required compilation of custom firmware, pulling over a better version of BusyBox, and reworking doomgeneric to run on this oddball platform. It also required figuring out how the keyboard was read and the screen was driven to write custom drivers—not at all trivial things on a bespoke phone platform. With all that done, though, [0x19] had a dodgy version of DOOM running slowly on a desk phone on a barely-legible LCD display.

Porting DOOM is generally a task done more for the technical thrill than to actually play the game on terribly limited hardware. We love seeing it done, whether the game is ported to a LEGO brick or a pair of earbuds. If you’re doing your own silly port, don’t hesitate to notify the tipsline—just make sure it’s one we haven’t seen before.

Inside SKALA: How Chornobyl’s Reactor Was Actually Controlled

Entering SKALA codes during RBMK operation. (Credit: Pripyat-Film studio)
Entering SKALA codes during RBMK operation. (Credit: Pripyat-Film studio)

Running a nuclear power plant isn’t an easy task, even with the level of automation available to a 1980s Soviet RBMK reactor. In their continuing efforts to build a full-sized, functional replica of an RBMK control room as at the Chornobyl Nuclear Power Plant – retired in the early 2000s – the [Chornobyl Family] channel has now moved on to the SKALA system.

Previously we saw how they replicated the visually very striking control panel for the reactor core, with its many buttons and status lights. SKALA is essentially the industrial control system, with multiple V-3M processor racks (‘frames’), each with 20k 24-bit words of RAM. Although less powerful than a PDP-11, its task was to gather all the sensor information and process them in real-time, which was done in dedicated racks.

Output from SKALA’s DREG program were also the last messages from the doomed #4 reactor. Unfortunately an industrial control system can only do so much if its operators have opted to disable every single safety feature. By the time the accident unfolded, the hardware was unable to even keep up with the rapid changes, and not all sensor information could even be recorded on the high-speed drum printer or RTA-80 teletypes, leaving gaps in our knowledge of the accident.

Continue reading “Inside SKALA: How Chornobyl’s Reactor Was Actually Controlled”