Soyuz Failure Leaves Questions Unanswered

The Russian space program experienced its first serious incident on a manned mission in 35 years when Soyuz MS-10 failed during ascent on October 11th, 2018. The abort system worked as designed, and crew members Aleksey Ovchinin and Nick Hague landed safely approximately 430 km from the launch site in Baikonur. Beyond being put through unusually high G forces, the two men suffered no injuries and will have their mission recycled for a future flight.

From an abort standpoint, the event went as well as could possibly be expected. The fact that the crew walked away unharmed is a testament to the emergency systems on the rocket and spacecraft, and serve as a reminder of why these functions are designed into manned rockets even if they are rarely (if ever) used. The success is especially impressive considering the Soyuz’s launch abort tower, the solid fuel rocket designed to pull the spacecraft away from the failing booster rocket, had already been jettisoned before the event occurred. The spacecraft was instead pulled to safety by the secondary abort thrusters, which were added to the vehicle’s design in 1975 as a contingency and until now had never been used in a real-life scenario.

What Went Wrong?

But while the safe return of the crew was naturally the first priority for all agencies involved, the questions soon turned to the Soyuz itself. What caused the loss of the rocket? Is it a defect which could be present in the other Soyuz rockets currently under construction? Perhaps most importantly, when could the Soyuz fly again? As it’s currently the only way to put humans into space, the International Space Station is completely dependent on regular Soyuz flights, and a delay in the program could endanger the orbiting outpost.

Now, with the initial findings of the Russian incident investigation being made public, we’re starting to get answers on some of those questions. The official report so far agrees with the conclusions many “Armchair Astronauts” made watching the live stream of the launch, and the evidence suggests that the core issue is the same which doomed previous Russian vehicles.

Continue reading “Soyuz Failure Leaves Questions Unanswered”

It Happened At Supercon: Six Days Of Fun In A Three Day Con

A weekend for people who love hardware, by people who love hardware. It’s a simple recipe and it makes a delicious event that we call the Hackaday Superconference. If you made it to Pasadena last weekend, I’m sure going back to work on Monday was difficult after three days of far too little sleep and way too much fun. (It was for me.) If you didn’t make it to the con, set a reminder for July 1st to start watching for next year’s early bird tickets. Don’t believe me? Okay, let’s step through the hype of a weekend we’ll all remember.

Check out the recap video above and then join me after the break for a photo-heavy expose of the weekend’s highlights.

Continue reading “It Happened At Supercon: Six Days Of Fun In A Three Day Con”

The Dual In-Line Package And How It Got That Way

For most of human history, our inventions and innovations have been at a scale that’s literally easy to grasp. From the largest cathedral to the finest pocket watch, everything that went into our constructions has been something we could see with our own eyes and manipulate with our hands. But in the middle of the 20th century, we started making really, really small stuff: semiconductors. For the first time, we were able to create mechanisms too small to be seen with the naked eye, and too fine to handle with our comparatively huge hands. We needed a way to scale these devices up somewhat to make them useful parts. In short, they needed to be packaged.

We know that the first commercially important integrated circuits were packaged in the now-familiar dual in-line package (DIP), the little black plastic millipedes that would crawl across circuit boards for the next 50 years. As useful and versatile as the DIP was, and for as successful as the package became, its design was anything but obvious. Let’s take a look at the dual in-line package and how it got that way.

Continue reading “The Dual In-Line Package And How It Got That Way”

Inventor Services – Maybe Right For You – Maybe

You’ve no doubt been exposed to the ads for various inventor services; you have an idea, and they want to help you commercialize it and get the money you deserve. Whether it’s helping you file legal paperwork, defending your idea, developing it into a product, or selling it, there’s a company out there that wants to help. So which ones are legit, which ones are scams, and what do you really need to make your millions?

Continue reading “Inventor Services – Maybe Right For You – Maybe”

Warnings Are Your Friend – A Code Quality Primer

If there’s one thing C is known and (in)famous for, it’s the ease of shooting yourself in the foot with it. And there’s indeed no denying that the freedom C offers comes with the price of making it our own responsibility to tame and keep the language under control. On the bright side, since the language’s flaws are so well known, we have a wide selection of tools available that help us to eliminate the most common problems and blunders that could come back to bite us further down the road. The catch is, we have to really want it ourselves, and actively listen to what the tools have to say.

We often look at this from a security point of view and focus on exploitable vulnerabilities, which you may not see as valid threat or something you need to worry about in your project. And you are probably right with that, not every flaw in your code will lead to attackers taking over your network or burning down your house, the far more likely consequences are a lot more mundane and boring. But that doesn’t mean you shouldn’t care about them.

Buggy, unreliable software is the number one cause for violence against computers, and whether you like it or not, people will judge you by your code quality. Just because Linus Torvalds wants to get off Santa’s naughty list, doesn’t mean the technical field will suddenly become less critical or loses its hostility, and in a time where it’s never been easier to share your work with the world, reliable, high quality code will prevail and make you stand out from the masses.

Continue reading “Warnings Are Your Friend – A Code Quality Primer”

How The Sony PlayStation Was Hacked

Playgrounds were the comment sections of their day. Every weekday from exactly 1:17 PM until 1:43 PM there were swings to be swung, rumors to be spread, and debates to be settled by whomever was the loudest (some things never change). Allegiances were formed and battle lines were drawn based solely on what video game console you supported. It was this playground system that perpetuated the urban myths of the time.

For PlayStation fans there was the myth that you could save Aerith from her fate in Final Fantasy VII if you just cast the right spell, or the secret code in Tomb Raider that would let you see all of Lara Croft. There was the myth that no one could possibly copy a PlayStation game because all the bottoms of the discs were black. Even the very existence of the first PlayStation, the Super Nintendo PlayStation prototype, was an urban legend. The difference was that last one turned out to be true.

Let’s jump in and take a look at the cat and mouse game between modchip makers looking to defeat the original PlayStation’s copy protection, and Sony’s efforts to protect their castle.
Continue reading “How The Sony PlayStation Was Hacked”

The Linux Throwie: Powering A Linux Server With A 0.3W Solar Panel

Have you ever had one of those moments, when you’re rummaging through your spare parts heap, and have a rather bizarre project idea that you can’t quite get out of your head? You know, the ones that have no clear use, but simply demand to be born, of glass and steel and silicon?

This time, the stubborn idea in question was sort of like a solar-rechargeable LED throwie, but instead of a blinking light, it has a fully cloud-accessible embedded Linux server in the form of a Raspberry Pi 3 Model B+. Your choice of embedded Linux board should work — I just happen to have a lot of these due to a shipping error.

There were two main challenges here: First, it would have to combine the smallest practical combination of solar panel, power supply, and Li-ion cell that could run the Raspberry Pi. Second, we’ll need to remotely activate and access the Pi regardless of where it is, as well as be able to connect it to WiFi without direct physical access. In this article we’ll be dealing with the first set of problems — stay tuned for the rest.

Continue reading “The Linux Throwie: Powering A Linux Server With A 0.3W Solar Panel”