Masten Moon Rocket Has Landing Pad, Will Travel

May 20, 2020 by Tom Nardi 65 Comments

Because of the architecture used for the Apollo missions, extended stays on the surface of the Moon weren’t possible. The spartan Lunar Module simply wasn’t large enough to support excursions of more than a few days in length, and even that would be pushing the edge of the envelope. But then the Apollo program was never intended to be anything more than a proof of concept, to demonstrate that humans could make a controlled landing on the Moon and return to Earth safely. It was always assumed that more detailed explorations would happen on later missions with more advanced equipment and spacecraft.

Now NASA hopes that’s finally going to happen in the 2020s as part of its Artemis program. These missions won’t just be sightseeing trips, the agency says they’re returning with the goal of building a sustainable infrastructure on and around our nearest celestial neighbor. With a space station in lunar orbit and a permanent outpost on the surface, personnel could be regularly shuttled between the Earth and Moon similar to how crew rotations are currently handled on the International Space Station.

Naturally, there are quite a few technical challenges that need to be addressed before that can happen. A major one is finding ways to safely and accurately deliver multiple payloads to the lunar surface. Building a Moon outpost will be a lot harder if all of its principle modules land several kilometers away from each other, so NASA is partnering with commercial companies to develop crew and cargo vehicles that are capable of high precision landings.

But bringing them down accurately is only half the problem. The Apollo Lunar Module is by far the largest and heaviest object that humanity has ever landed on another celestial body, but it’s absolutely dwarfed by some of the vehicles and components that NASA is considering for the Artemis program. There’s a very real concern that the powerful rocket engines required to gracefully lower these massive craft to the lunar surface might kick up a dangerous cloud of high-velocity dust and debris. In extreme cases, the lander could even find itself touching down at the bottom of a freshly dug crater.

Of course, the logical solution is to build hardened landing pads around the Artemis Base Camp that can support these heavyweight vehicles. But that leads to something of a “Chicken and Egg” problem: how do you build a suitable landing pad if you can’t transport large amounts of material to the surface in the first place? There are a few different approaches being considered to solve this problem, but certainly one of the most interesting among them is the idea proposed by Masten Space Systems. Their experimental technique would allow a rocket engine to literally build its own landing pad by spraying molten aluminum as it approaches the lunar surface.

Continue reading “Masten Moon Rocket Has Landing Pad, Will Travel” →

ZRAM Boosts Raspberry Pi Performance

May 20, 2020 by Al Williams 18 Comments

Linux is a two-edged sword. On the one hand, there’s so much you can configure. On the other hand, there’s so much you can configure. It is sometimes hard to know just what you should do to get the best performance, especially on a small platform like the Raspberry Pi. [Hayden James] has a suggestion: enable ZRAM and tweak the kernel to match.

Although the post focuses on the Raspberry Pi 4, it applies to any Linux system that has limited memory including older Pi boards. The idea is to use a portion of main memory as a swap file. At first, that might seem like a waste since you could use that memory to, you know, actually run programs. However, the swap devices are compressed, so you get more swap space and transfers from these compressed swap devices and main memory are lightning-fast compared to a hard drive or solid state disk drive.

Continue reading “ZRAM Boosts Raspberry Pi Performance” →

Poking Around Inside Of A Linux Security Camera

May 20, 2020 by Tom Nardi 21 Comments

This deep dive into the Linux-powered Reolink B800 IP camera started because of a broken promise from its manufacturer. When [George Hilliard] purchased a kit that included six of the cameras and a video recorder, the website said they were capable of outputting standard RTSP video. But once he took delivery of the goods, and naturally after his return window had closed, the site was updated to say that the cameras can only function with the included recorder.

Taking that as something of challenge, [George] got to work. His first big break came when he desoldered the camera’s SPI flash chip and replaced it with a socket. That allowed him to easily take the chip out of the device for reading and flashing as he tinkered with modifying the firmware. After adding cross-compiled versions of busybox, gdb, and strace to the extracted firmware, he bundled it back up and flashed it back to the hardware.

If you think that’s the end of the story, it isn’t. In fact, it’s just the beginning. While getting root-level access to the camera’s OS would have potentially allowed for [George] to dump all the proprietary software it was running and replace it with open alternatives, he decided to take a different approach.

Instead of replacing the camera’s original software, he used his newly granted root powers to analyze it and figure out how it worked. This allowed for to sniff out some very suspect “encryption” routines built into the software, and eventually write his own server side in Rust that finally allowed him to use the cameras with his own server…albeit with a bit more work than he bargained for.

Projects like these are a fantastic look at real world reverse engineering, and a reminder that sometimes achieving your ultimate goal means taking the long way around. Even if you’re not in the market for a hacked security camera, there’s no doubt that reading the thorough write-up [George] has prepared will teach you a few things. But of course, we’d expect no less from a guy who runs Linux on his business card.