Akin's Laws of Spacecraft Design (2011) [pdf]
ece.uvic.ca
ece.uvic.ca
Not quite, and an interesting story that fits these engineering maxims better than you might think.
An analog channel with the bandwidth and SNR characteristics of a landline phone line has (IIRC) a Shannon capacity of 30-something kbit/s, which was closely approached with V.34, which used trellis coded modulation plus basically every other coding and equalization mechanism they knew of at the time to get to 33.6kb/s on a good day.
But... by the 80s or so the phone system was only analog for the "last mile" to the home - the rest of the system was digital, sending 8-bit samples (using logarithmic mu-law encoding) at a sampling rate of 8000 samples/s, and if you had a bunch of phone lines coming into a facility you could get those lines delivered over a digital T1 link.
Eventually someone realized that if your ISP-side modem directly outputs digital audio, the downstream channel capacity is significantly higher - in theory the limit is probably 64000 bit/s, i.e. the bit rate of the digital link, although V.90 could only achieve about 56000 b/s in theory, and more like 53kb/s in practice. (in particular, the FCC limited the total signal power, which means not all 64000 combinations of bits in a second of audio would be allowable)
I worked with modem modulation folks when I was a co-op student in the mid-80s. They had spent their lives thinking about the world in terms of analog channels, and it took some serious out-of-the-box thinking on someone's part to realize that the channel was no longer analog, and that you could take advantage of that.
A few years later those same folks all ended up working on cable modems, and it was back to the purely analog world again.
But why is it higher? It's still an analog channel (the last mile from the ISP to your house), right? Doesn't it get filtered? So isn't it still subject to the Shannon-Nyquist limit?
Here's an ASCII drawing of which parts are digital vs analog as I understood your explanation:
Rest of world<--- digital--->Telco<---digital--->ISPmodem<---analog--->HomeModem
I hope you can clear up my confusion.
> Couldn't you send data at megabits per seconds over a mile long copper wire without using modems at all (using just UARTs?).
No. The exchange is sampling the analog signal coming in over your phone line at 8kHz and 8 bits per sample. They just designed modems that sent digital data over that analog link, in a way that would line up exactly with the way the exchange will sample it.
4kHz/2*log2(1+10^(31dB/10)) ~ 60.3kBps
[0] https://www.ecfr.gov/current/title-7/subtitle-B/chapter-XVII...
Yes, but you need the bare copper wire without signaling. We operated a local ISP in the 90's and did exactly that by ordering so-called "alarm circuits" from the telco (with no dial tone) and placed a copper T1 CSU on each end. We marketed it as "metro T1" and undercut traditional T1 pricing by a huge margin with great success to the surrounding downtown area.
Traditionally both the ISP and you pay for analog phone lines from the telco. The telco uses digital internally (remember you and your ISP probably aren't at the same exchange), which puts a hard limit on data rate - there is no trick you can do to get more bits through than the bits used in the digital part of the call.
If you (as the ISP) buy enough lines you can get them delivered in digital format. A T1 is designed to carry 24 simultaneous phone calls, acting virtually as a bundle of 24 analog phone cables. So the obvious next stage was to have a modem that can handle 24 simultaneous connections on one cable.
Now you have ISP\_modem←Ax24→ISP\_muxer←Dx24→Telco←→Telco←A→User
The ISP's modem generates analog signals for up to 24 simultaneous incoming calls, and they pass into a multiplexer that connects 24 analog lines to a T1 line and they go through the telco digitally to users. The maximum bandwidth is still as before - the modem has to generate an analog signal that will still be receivable at the other end after A2D and D2A conversion. Even though the digital bandwidth for the digital part is 56kbps, the maximum achievable bandwidth through this digital-bottlenecked analog call was found to be 33.6kbps.
But the industry had an idea: by convincing the telco to install the modems into the user's exchange, the analog portion would only be between the telco and the user, without a digital segment in the middle of it, and therefore wouldn't be bottlenecked the same way. The same digital backhaul from the ISP through the telco was used, but instead of transmitting a digitised analog modem signal and therefore causing degradation of quality, it transmitted your actual internet traffic bits, up to 56kbps. The analog signal was made at the user's side of the telco and didn't have to fit within 56kbps when digitised.
Pedantically, the digital circuits are 64kbps but one bit in some bytes is used for call status signaling, which is okay for voice, but the ISP equipment can't predict which bytes have a bit overwritten (and it could be multiple if there are several hops) so it just used 7 bits in each byte.
Though the actual available bandwidth was very dependent on distance. People would lease dedicated pairs for high bandwidth across town (or according to a random guy I talked to at a cafe: just pirate an unused pair that happened to run between their two buildings). But once we start talking between towns, the 32kbit you could get from the digital trunk lines was almost always higher than what you could get on a raw analog line over the same distance.
Huh? The SotA for dial-up modems in the 1990s was indeed 56 kbps, achieved with various encoding and compression hacks in both domains including trellis coding.
Weirdly enough, you can apparently still buy them from US Robotics: https://www.usr.com/products/56k-dial-up-modems/
The problem is that the ADC in the telephone exchange is not clocked coherently to your modem. You're paying various companding, quantization (time and level), etc, losses-- it is not a nice linear channel.
An end-to-end analog connection could be capable of significantly more-- while there's noise, there's no "8KHz cliff." A 45dB SNR for 0-4KHz has a >60kbps Shannon bandwidth, and there's not exactly a 4KHz cliff even with loading coils present.
> "A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."
(Most VC funding is used to quickly produce a beefy market share, and sell it to those who think they can milk it, or to profitably butcher it.)
https://youtu.be/0-z1TaNx7TMWhen I was the one who presented something poorly, I've even had people who publicly shunned it privately tell me they support the idea but the group rejects is so they reject it publicly too. This is dumb.
I do, and I can tell you the result: you will be branded as a troublemaker.
Would you assign a large sum of money to a group that cannot present their design clearly, neatly, and concisely? If they are struggling even with that, would you trust them to be good at actually designing a spacecraft soundly, economically, and in a reasonable time?
"If you can't explain it to a five-years-old, you likely do not understand it yourself", said one of the greatest modern scientists, who also was notoriously good at explaining things.
The average person can understand anything ... at some level. Being able to match that level is positive evidence (but not proof) of competence.
Duality: Being unable to match that level is positive evidence (but not proof) of incompetence.
If the person you are explaining your project to is not interested in the technical side, presumably under the rather confused but popular theory that technical aspects are not relevant to technology ventures, you'll not be making headway. It's much better to just make up some dollar numbers and run with that.
This mentality seems very US-Amercian to me.
> "If you can't explain it to a five-years-old, you likely do not understand it yourself", said one of the greatest modern scientists, who also was notoriously good at explaining things.
OK, challenge: explain A1 homotopy theory to a 5-year old child: https://en.wikipedia.org/wiki/A%C2%B9_homotopy_theory
Lesson learned: very commonly you need a deep knowledge of a topic to understand advanced scientific theories.
"The underlying idea is that it should be possible to develop a purely algebraic approach to homotopy theory by replacing the unit interval [0, 1], which is not an algebraic variety, with the affine line A¹, which is."
In other words: it's a novel approach towards homotopy theory, which does have applications in the physical world.
Even better (Wikipedia article):
"[A¹ homotopy theory] has also recently revolutionized the theory of enumerative geometry problems."
Enumerative geometry does have applications in the physical world.
That’s not a good example. Neither is Beta vs VHS. The most they illustrate is a different law I am coining right here:
Canyon’s Law of Design Optimization: you will inevitably choose to optimize for different metrics than your customers would wish. Don’t try to convince them they are wrong.
(Nokia E70 not N95, but still)
The original iPhone was a promising proof of concept. It got the form factor and the interface right, but the actual device was underwhelming. It had no 3G, no GPS, no third-party apps, and a weak camera. iPhone 3G added all the features competitors already had (apart from a good camera) and became a much bigger commercial success.
But I'd be surprised if Apple didn't have a beefier profit with the IPhone compared to Nokia with the N95.
Then only a year later the iPhone 3G came out, and it was a rough wake-up for Nokia. Because that one was actually a well-built sane design.
It’s a great example. One can list a litany of technical specifications on which the N95 is superior. That, however, doesn’t make it a superior product.
I think we're in violent agreement.
https://web.archive.org/web/20031101212246/https://spacecraf...
"Ignore all the advise above and do the right thing Subtext: This will take multiple lifetimes to accomplish"
This is particularly important considering that some of the advice is at odds with each other and engineering is an unending juggling of tradeoffs. It's also by far the hardest to achieve both technically and socially but worth striving for.
“The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours.”
https://en.wikipedia.org/wiki/Wikipedia:Akin%27s_Laws_of_Art...
If anything, some of these early smartphones were pushing a lot of limits considering the hardware restraints. Its just by the time the iphone came out, these restraints were lessened and Apple did a good job using these technologies.
• Much of the design-conservative ethos permeates aerospace development. It's unsurprising that astronautics evolution has been slow at least until Elon came along. I wonder how Elon / SpaceX folks would respond to these laws esp. #39 (avoid designing launch vehicles).
• Also the one that was conspicuously maintained at the end across the different archived versions:
"Space is a completely unforgiving environment. If you screw up the engineering, somebody dies (and there's no partial credit because most of the analysis was right...)"
It's notable that the wayback machine's first crawl of Akin's list is late 2003 (so presumably when the source page went live) the year in which the Columbia disaster took place.
Perhaps, based on specific context, let the Law's vote!
> Law 11: Sometimes, the fastest way to get to the end is to throw everything out and start over.
> Law 16: The previous people [...] did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis [was optimal].
> Law 31 (Mo's Law of Evolutionary Development): [...] understand the fundamental limitations of [the existing] technology/approach.
IMHO: Law 31 is the kicker. That triggers Law 11. With general support from Law 16.
SpaceX has designed 3 (four if you include Falcon 1) launch vehicles: Falcon 1, Falcon 9, Falcon Heavy and Starship. The first three run the same engine family and are arguably in the same vehicle family.
SpaceX has absolutely embraced avoiding designing new launch vehicles (and even major components) until the fundamental limitations of the existing approach are exceeded.
Dragon 2 [1] looks like the Apollo and Gemini craft for the same reason it resembles Soyuz 3 [2]. Crewed disposable atmospheric reëntry vehicles launched in cylinders and soft landed or splashed down under parachutes are going to look similar.
[1] https://upload.wikimedia.org/wikipedia/commons/4/4e/Iss071e0...
The propellant storage shall be designed and located such that a catastrophic failure of propellant storage will not damage the passenger compartment.
The propulsion system shall be designed and located such that a catastrophic failure of the propulsion system will not damage the propellant storage or the passenger compartment.
The launch system shall be designed to ensure a minimum of two survivable abort alternatives at each phase of the flight. Each abort scenario shall be validated by a flight test before certifying the system for general use.
The re-entry system shall be designed so there are no single points of failure. If single points of failure are unavoidable, a method pf inspection or surveillance shall be developed to detect the failure prior to de-orbit.
In-orbit repair procedures for foreseeable types of damage shall be developed and validated prior to certifying the system for general use.
Yeah, this is all 20/20 hindsight. But we really need to avoid developing ANYTHING similar to the STS in the future. I truly believe it set us back by 50 years.
I like that he waved from the crowd in this way, if only for the "huh. Small world" moment I had reading his comment.
On this particular Wednesday the presentation was on a failed spacecraft program. It's been a long time, but I think it was probably this paper:
https://llis.nasa.gov/llis_lib/pdf/1009464main1_0641-mr.pdf
which is the initial failure analysis of the Mars Climate Orbiter (1999), which famously crashed into Mars during its orbital insertion burn because JPL specifications were in metric, but Lockheed wrote code in imperial units, and as a result there was a failure to properly convert between newtons and pounds. One fact of note was that the the team responsible for spacecraft navigation had already observed anomalous trajectory data but their reports were ignored because they didn't follow program guidelines for filling out the paperwork to document the observations, so the insertion burn went ahead heedless of what the spacecraft's behavior was trying to tell them.
Ultimately, the loss of mission was a result of unclear responsibility for ownership of the orbital maneuvering software, including the mission requirements that traced to the software, the development of the software derived from those requirements, tests to validate the software, and reports from users of the software that it was behaving unexpectedly.
I was trying to be funny, and turned the statement around from "clear lines of responsibility" to "clear lines of blame".
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction."
https://www.goodreads.com/quotes/14789-any-intelligent-fool-...
The most general problem cannot be solved. (If you don't limit scope, you will never finish. You won't even finish the design.)
If you want it bad, that's how you're going to get it. (That is, rushing a project means you get crummy results. This may be "Hanka's Law", because I first heard it from Steve Hanka, but it may not be original to him.)
Feels true, particularly in an era where LLMs make fast thinking cheap.
Not sure of the source for this. Nevertheless, this is ridiculously high percentage of projects that ever see an industrial angle, at least in basic sciences. Perhaps, this is restricted to engineering.
I definitely struggle with this. I run a math education site and I usually focus heavily on technical accuracy but underestimate the presentation.
Hard lesson that being "right" isn't enough if the delivery is clunky.
Adding "just a few fundamental equations" to a presentation won't make your case more compelling to business stakeholders. You lose roughly 10% of engagement for every greek letter in a slide.
Turns out it was mostly audience and presentation. Math/educational content just doesn't travel well on those channels unless it’s tailored very carefully. Being right wasnt enough if the delivery didn’t match how people consume it.
https://en.wikipedia.org/wiki/De_Havilland_Comet#Comet_disas...
The second, more depressingly, is that the Avro C102 was cancelled to redirect resources to the Avro Arrow: Canada's mythical last jet fighter, of which only a handful were produced before the program was (painfully) cancelled, and Avro wound up. IIRC, the Canadian government was the main-to-sole bankroller of the project, and ballistic missiles became increasingly more important.
I dont think the Comet was a materially worse design than the Avro C102 (both aircraft are similar) and the C102 may very well have had other unknown issues only to be found if it went into series production.
In the Navy-nuke world there was a saying, purportedly by Admiral Rickover, about non-technical "managers": There but for the grace of God goes God.
It's a nice reflection, but what is the origin of this? Can't find another reference to this "law" online.
Notes from the original author:
> I've been involved in spacecraft and space systems design and development for my entire career, including teaching the senior-level capstone spacecraft design course, for ten years at MIT and now at the University of Maryland for more than a decade. These are some bits of wisdom that I have gleaned during that time, some by picking up on the experience of others, but mostly by screwing up myself. I originally wrote these up and handed them out to my senior design class, as a strong hint on how best to survive my design experience. Months later, I get a phone call from a friend in California complimenting me on the Laws, which he saw on a "joke-of-the-day" listserve. Since then, I'm aware of half a dozen sites around the world that present various editions of the Laws, and even one site which has converted them to the Laws of Certified Public Accounting. (Don't ask...) Anyone is welcome to link to these, use them, post them, send me suggestions of additional laws, but I do maintain that this is the canonical set of Akin's Laws...
So will Musk finally be fired in 2026?
So he gives 4, which but 1 are all terrible, and is rightly criticized. Then he inserts hateful regressive politics into our collective culture as the secondary price of using/buying/supporting his brand and products. If anything, he's under-criticized and keeps failing up.
And no I'm not a fan of the Musk personna.
It's not a breakthrough, because it could have been done with the Soyutz (except the part of reusing the launcher), but it's enough for "He promises 10, gives the world 4, but everybody else has 1, and he's hated for it."
My favorite is still Mar’s law:
> Mar's Law) Everything is linear if plotted log-log with a fat magic marker.
Law 4 Bhargava’s Law: Only 1 out of 10 research ideas make it into industrial practice is wrong anecdotally particularly when it relates to software.
Law 13 is flat-out wrong in that there is a huge amount of potential SWaP trades & innovation trades to be made, and the changing requirements environment where it is easy to predict where a requirement will be, despite a space program with a legacy requirements baseline.
An example of Law 13 errors would be the JPSS security redesign campaigns, and a less ideal retrofit
Minimize negative(painful) notions as much as possible, ideally approaching zero, while maximizing positive (pleasurable) notions.
Minimize negative(painful) notions: Uncertainty, Risk, Chaotic behavior, Randomness, Non-deterministic, Instability, Cost, Energy losses, Time consumption, Resource usage, Excessive complexity, Failure modes, Noise
Maximize positive(Pleasure) notions: Reliability, Efficiency, Deterministic, Predictability, Precision, Accuracy, Verification, Validation, Safety, Stability, Simplicity (lower complexity), Robustness, Redundancy
There should be an Akin Exit Clause from said 3-year contracts. They have zero incentives to fix or improve _anything_ during those years of servitude.