This episode of Real Engineering is brought to you by Brilliant, a problem solving website
that teaches you to think like an engineer.
Simple malfunctions have plagued space flight from its inception.
It goes without saying that pushing things into space with controlled explosions is a
treacherous affair, and many rocket launches have failed over simple problems.
The three crew members of Soyuz 11 became the first and only humans to die in space
after the explosive bolts holding the service module and descent module together fired,
a routine procedure, but the bolts were designed to fire sequentially, one after the other.
On this occasion they fired simultaneously and the combined explosive force loosened
a seal separating the crew from the vacuum of space, within a minute the crew were dead.
More recently, Space X’s first launch failed simply because they left their rocket exposed
to sea air for too long, allowing it to rust an aluminium nut securing the fuel pump inlet
When it failed fuel began to leak down the outside of the engine and thrust chamber,
and caught fire.
The fire caused a loss of pneumatic pressure, forcing valves to close, and thus cutting
Space X’s first rocket fell out of the sky over a simple oversight of aluminiums weakness
After this flight Space X switched to rust resistant stainless steel fasteners, which
are actually cheaper to begin with, but about 2 and a half times heavier.
There is very little margin for error in space flight.
Tiny oversights like this lead to catastrophic failure, and this is exactly what happened
to, what was intended to be the first successful planetary fly-by in human history, the Mariner
On July 22nd 1962.
Mariner 1 launched from Cape Canaveral.
On a mission intended to fly by Venus and collect data on its temperature and atmosphere.
But just 293 seconds into its flight the Range Safety Officer gave the command to self destruct
the rocket over an unpopulated area of the Atlantic, seeing that it’s trajectory was
taking it to a crash landing possibly in busy shipping lanes or land.
Despite the booster performing nominally, the rocket took an unprogrammed yaw-lift turn
and steering commands were unresponsive.
With just 6 seconds remaining before the Mariner 1 probe was scheduled to separate and ground
control would be lost, that officer made the decision to send the self destruct command.
To understand what went wrong we first need to learn a little about how the Atlas Agena
rocket, which the Mariner 1 probe was perched upon, worked.
The Atlas booster rocket used two radar systems to maintain its trajectory along it’s intended
A rate system, which measured it’s velocity using doppler shift measurements from a ground
based beacon , and a track system which measured it’s distance and angle relative to an antenna
located near its launch site.
Shortly into the launch the first problem occurred, the rate system failed.
The track system should have been capable of handling navigation by itself, the two
systems working together formed some redundancy in measurements, to allow for a small margin
This is why previous launches using the Atlas Agena rockets went off without a hitch, but
on this occasion the Rate System failed.
The code designed to interpret the distance and angle measurements had a simple error.
This is the notation the position measurement should have had, and this was the notation
it actually had in the code.
It was missing an overbar.
This dot stands for the first derivative of the position, which gives us the velocity,,
and the bar simply means to take the average of the values.
Giving a smoothed value for the velocity, which helps remove any fluxuations of measurement.
Because this bar was missing the rocket guidance computer was being fed erratic information
about the rockets velocity and it began trying to compensate for them, leading to actual
This was the point the range officer recognised something was wrong and initiated the self
An incredibly simple mistake that should have been caught, but these were the early days
We didn’t have fancy computer interfaces for writing code with compiling software and
The code for the guidance computer was mostly written in Fortran, an early coding language.
Fortran code, which stood for “Formula Translation” was used to translate mathematical equations
into code, and was handwritten or typed on a typewriter.
This is where punch cards came into play.
Punch cards are thick rectangular pieces of paper with long rows of repeating numbers,
0 through 9, running down their length in eighty columns.
Each card held one line of code, with each column representing 1 character of code in
To represent a number you simply punched out the corresponding number in the sheet.
To represent letters and symbols required you to punch out additional holes.
This sheet has all the possible hole punch combinations required for Fortran coding to
give you an example.
This was done on a card punch machine where you had to manually type out each line of
the code again.
Once you had converted all you code to punch cards, the cards would be sent through a compiler,
where they would be converted to binary.
If a hole was present, a circuit would be completed through a particular set of contacts,
and thus a binary signal was produced.
The compiler then produced a new set of cards that the computer could actually understand.
Obviously this method of coding is much more tedious and difficult to fact check when compared
to present day user interfaces.
It’s no excuse, but obviously mistakes were much easier to make and this particular mistake
ended up costing NASA 18.5 million dollars in 1962, which is about 150 million dollars
The code was corrected, and just a month later Mariner 2 was launched, on its 3 and a half
month flight to Venus.
On its way Mariner 2 detected solar wind for the first time, the constant stream of charged
particles emitted from the Sun.
It measured interplanetary dust levels, and during its flyby of Venus revealed information
about the planet’s temperature and atmosphere.
Mariner 2 is now floating somewhere in orbit around the Sun.
Learning from our mistakes is a common theme in human history, which is why I find Brilliant’s
style of teaching complicated subjects fantastic.
Take this course on classical mechanics.
It takes you through the fundamentals of the physics of motion, an essential skill for
any rocket engineer.
It will give you short digestible overviews of a problem, and then give you a problem
of your own to solve.
If you get it correct, you advance forward.
If you get it wrong however, it will tell you exactly why and teach you more about the
Allowing you to learn from your own mistakes, and hopefully not repeat them.
This is encapsulated in their principles of learning - by allowing for failure and acknowledging
it happens, one is open to correcting misconceptions and errors, which furthers understanding of
To support Real Engineering and learn more about Brilliant, go to brilliant.org/RealEngineering
and sign up for free.
The first 73 people to sign up with this link will get 20% off their annual premium subscription.
As always thank you to my Patrons and thank you for watching.
I recently featured on the Life Noggin channel as an animated version of myself to teach
you about what makes the perfect city, the link to that is on screen now.
If you would like to join the Real Engineering community, I have recently set up subreddit
and discord server where we discuss everything engineering related and more.
The link for those are in the description.