Ultimate Steve

I have to be a bit vague here for NDA reasons. But as far as programming languages go, the ones I know look a little bit like this: Professionally Relevant Professionally irrelevant I've done professionally relevant projects C, Python, Matlab processing.js I haven't made professionally relevant projects C++, C# Lua, MIPS At some point or another all of those languages had been on my resume, though the trend has been towards including fewer and fewer of them, as space is limited, and I can't really justify keeping on something that's not relevant and that I'm not actually good at. So I have to figure out which languages to include. There's the obvious ones, that are relevant and that I've done cool things in: C: CubeSat Flight Software (Command and data handling, general random embedded stuff, interfacing with a number of serial connections, file management, RTOS and task prioritization, etc) Python: Other CubeSat Flight Software and CubeSat Ground Software, two video games I'm working on, and an interstellar gas cloud interaction simulator for sci-fi FTL spaceships. Also some amount of internet networking stuff. Matlab/Simulink: Solar panel angle controller for orientation constrained satellites with single axis rotatable solar panel arrays, orbital simulation with includes perturbational effects from Earth's oblateness, and a satellite solar power simulation (all three of those are in the same program btw). Also was the language the first 2/3 of the major used for general stuff so a lot more minor projects. Then there's the stuff that I kind of want to have on my resume if possible but isn't as important: C++. I've only ever done like 2 smallArduino projects using it. But it is important and widely used so on the resume it goes, cross my fingers that nobody asks about it, and if they do, maybe I can stretch "I made like 6 buttons work" into an impressive sounding answer. C#: I don't know C#. I've had to write several config files for C#. I have no idea why I ever put this on my resume but I have since taken it off. I should learn C#, it seems like it is pretty commonly used. processing.js: The language/library I originally learned to code in. Completely irrelevant but I've made some fun little small games in there. Then there's the stuff that I've done some really cool stuff in, but that stuff is completely irrelevant to the aerospace industry and was done for completely non professional reasons: MIPS: Only used from the game Stationeers to program airlocks and other simple automated things, but got me interested enough in assembly enough to try making my own simple redstone computer in Minecraft (which has its own assembly language too, I even tried to make a compiler for it at one point). It's not even real MIPS. Just a video game's implementation of MIPS on in-game computers. No longer on the resume. Lua: Before this week I had only seen it used for Roblox scripting and as a language used by the ComputerCraft mod for Minecraft. I've made a few neat ComputerCraft Lua scripts, one that was a note block jukebox that could play music from a custom file format, and one that allowed me to play a pipe organ made from the Create mod whistles using my real life MIDI keyboard using another program as a bridge. I removed it from my resume fairly early on as I had deemed it to be pretty professionally irrelevant, and the few projects I had made in it equally professionally irrelevant. I proceeded to then get a job that only requires programming once in a blue moon. So yesterday at work I was assigned to, in vague NDA compliant terms, develop a script for a piece of equipment. Does that equipment speak C? No. Python? No. Matlab? No. Not even C++ or C#? Not that I know C# or anything? Absolutely not. ...It uses Lua. The language I removed from my resume as I had deemed it to have little to no professional relevance. If it was still on my resume it would be basically the only thing from my resume I actually use here besides Microsoft office. You heard it here, folks, modded Minecraft prepared me for a career in the Aerospace industry better than my Aerospace Engineering degree did! (jk but I do find it funny)

Thank you for the throwback. My high school unironically had a big chungus themed after prom party. No April Fools. No I wasn't hallucinating.

Even worse this was back when you couldn't pick crew if I remember right. You could cheese it by launching pods with the first few crew in the list to the runway and then launching with the crewman in the next position on the list. And I was on an old laptop wholly unsuited for playing ksp at the time, so having multiple craft like that was a non starter.

It's a bit sad to think, but that save file was so long ago that I honestly don't remember. It was probably Jeb, as it would have been a 1 person craft in a time before the astronaut complex allowed you to pick your crew, and in an era where I didn't have the heart to let Kerbals stay dead (I would restart every failed flight). I remember the vague outline of the craft. I don't remember the top stage (possibly LV-909 upper stage), but the core stage was probably an orange tank with a mainsail engine, with three hammer SRBs. It would have been something in the "Toddler steps" series.

Bill Kerman has been launched to the Mun in 36:01. In short, my strategy relied on 2 main ideas. Firstly, minimize the mass of the final stage. Secondly, focus on high TWR stages. It doesn't matter much if you get up to, say, 10km/s if you only achieve that briefly in the middle. This ship is designed to get up to 6.6km/s in 6-7 minutes and slow down to zero in three. Its top speed isn't near the practical limit but it spends the majority of its journey at that speed. Not sure if this approach will win out in the long term though. The mission could easily be 1-1.5 minutes faster if I had been quicker on the draw clicking on the VAB when I started the save, more aggressive with my top speed (I had a few hundred m/s left), and if I had managed my suicide burn better (I EVA'd out of the ship to land because I undershot and the ship didn't have reaction wheels to turn around with). The center of thrust was also not properly aligned, adding complexity and inefficiency to the descent. It is called the Delta-V, it costs 246,135, and masses 474.168 tons. This idea can be further pursued, there is plenty of room for moar boosters. More pictures:

I asked Grok 3 the following: "On a non rotating planet, launching from the equator, how much larger must a rocket be to place a satellite into a polar orbit relative to an equatorial orbit?" Which is obviously a trick question. If the planet is not rotating, there is no equatorial boost, and thus there is no difference in the size of the rocket required. The relevant part of Grok's response: While it does correctly calculate the Delta-V to make a plane change of 90 degrees once you are in orbit, it fails to grasp that a plane change is not needed, then makes up everything after that point, including what appears to be an arbitrary multiplication by the square root of two to correct an "overestimation" of cost which actually ends up 5 m/s higher. To its credit it does use real formulas everywhere, correctly reasons the orbital velocity, correctly describes the difference between an equatorial and polar orbit, and then afterwards has a wonderful long section where it does successfully reason through the rocket equation to find the required mass ratios to meet its (incorrect) Delta-V numbers. However it then divides these mass ratios by each other to come up with the answer. I guess that is true when the only extra thing you need to add is fuel and you only have a single stage. But it is a little misleading, though I could have phrased the question a little better. I did then remind Grok that the launch azimuth is not restricted to a specific direction and then it proceeded to absolutely nail the answer (though I specifically restricted the answer to Delta-V only). I would still hesitate to use it for complex things I know nothing about because I have no way of knowing it was correct. But to be honest I had a big "Oh no" moment there. The last time I used AI it couldn't even add up Delta-V numbers correctly or comprehend that landing on an atmospheric world took far less Delta-V than taking off from it. Before I asked this question I asked it about how shockwaves influence hypersonic heat shield design, and I couldn't actually tell if it was right or not. It was outside my ability. When I asked it about this I saw my entire profession flash before my eyes as I saw correct formula after correct formula pop onto the screen. I was relieved when I read through it. But it couldn't do anything near this a year ago, and right now it made one bad assumption towards an admittedly poorly worded question. Maybe this is the practical limit, but if it makes the same level of improvement next year...

Hypersonic aerothermodynamics is hard and counter intuitive. Granted I only have an undergraduate's perspective on it (basically nothing) but I know enough to know that you are not going to get a good accurate answer by just using wing loading and whatever a large language model gives you.

To be clear, my point was less about Elon himself and more about a general trend I've noticed. People seem to want to put people into boxes these days. "This person did something good so therefore this other thing this person did is probably good" and "This person did something bad so therefore this other thing this person did is probably bad." I see this happening with Elon a lot in both directions, which is part of why I talked about him. But my point in general is not about Elon, though I could have worded this a lot better. There seems to be an ongoing death of nuanced thinking and a draw towards the black and white. If the person is important enough there's also an endless stream of media supporting either side, and algorithms mean that you would really only ever see one side unless you went out looking for the other. Will Lockett's articles would absolutely convince someone who knew nothing about spaceflight that Starship is doomed to fail and assuming they were already on that side of the debate this would in their eyes reinforce their biases. To rephrase: I believe that it is okay to have a positive or negative opinion of someone. I do not believe that it is okay to make that opinion pre-emptively decide your perception of that person's other actions. I strongly believe that it is abhorrent to write articles that use misleading or hogwash claims to reinforce people's perception and contribute to polarization.

BONUS TIME! I went through this article, the seven deadly sins of Starship as described by Will Lockett (https://www.planetearthandbeyond.co/p/starship-will-simply-never-work). The amount of misinformation and bad math in here is so laughably absurd that I almost want to make a video out of it. However I've now wasted like 1/4 of my entire weekend free time on Will Lockett and I have little desire to continue. Will's Starship Deadly Sin #1: Thrust Steve's verdict on Deadly Sin #1: Hogwash. There are nuggets of truth in here. TWR is very important for this architecture and there is evidence where one of the possible conclusions is Raptor making a little less thrust than advertised. However, Will assumes the worst, pins all of the underperformance on Raptor, connects the vibration problems to 4-8 tons of payload, and baselessly assumes that 45 tons is the expendable number (based solely on how he believes that the ship's vibration problems were caused by the 4-8 tons of starlink simulators). That doesn't compute as those vibration problems would happen in expendable mode also but I think that's what he's saying. Will's Starship Deadly Sin #2: Safety Factor Steve's Verdict on Deadly Sin #2, Safety Factor: Complete hogwash. Will's Starship Deadly Sin #3: Human Space Flight Certification Steve's verdict on Deadly Sin #3, human space flight certification: Bad-faith. I share many of his concerns but he goes out of his way to twist the facts to make it seem like the problem is represented in as damning of a light as possible, and to make it seem like the problem is an immediate showstopper, rather than one that simply needs addressing before Starship flies with crew in several years time. Will's Starship Deadly Sin #4: Price Steve's verdict on Deadly Sin #4, Price: Hogwash. Will consistently pulls numbers out of thin air that are not sourced nor likely to be correct and assumes Starship will fail to even meet the bar set by Falcon 9. There is some validity to the method of total cost divided by number of flights but at best that is a flawed methodology and is only particularly relevant for finding the marginal cost of another mission once the system is mature, fully developed, and flying often. Will's Starship Deadly Sin #5: Economics And Demand Steve's Verdict on Deadly Sin #5, Economics and Demand: Somewhat true, but misleading. I have no problem with Will's assertion that the claimed long term figures are only possible with the demand of a Mars colony, but I do take issue with how Will implies that Starship cannot work for any level of demand. All it takes is Starship beating Falcon in launch costs and the Starship economics will work out. Will seems to believe this is impossible and I believe that Starship's sticker price will never be higher than Falcon 9's sticker price (currently $69.75 million). Time will tell who is correct. Will's Starship Deadly Sin #6: Past Orbit Steve's Verdict on Deadly Sin #6, Past Orbit: Hogwash. There is an interesting discussion to be had about the reliability and feasibility of large scale orbital refilling but he generously assumes that's a given and instead, not only does garbage-in, garbage-out math with mission cost, but assumes a Starship must be fully refilled in order to go to the Moon or Mars. If we correct for the refueling error, even his garbage cost numbers come out ahead of SLS and Saturn V by significant margins. Will's Starship Deadly Sin #7: No Backstop Steve's Verdict on Deadly Sin #7, Past Orbit: My words are too strong for a PG rated forum. I don't need to tell you how ridiculous this guy's conclusions are.

Seeing this makes me think I could honestly become a space journalist if this is where the bar is at.

Buckle up. TLDR: This guy is either deeply uneducated on the basics of aerospace engineering or is actively misleading people to further an agenda. Some finer points include: Starship is designed to scam the federal government Starship made up for its decreased payload capacity by reducing its factor of safety Starship is attempting to reduce heat shield mass by saving fuel to slow down (???) Starship costs 500 million dollars per launch and $10,000 per kg Starship's re-entry is fundamentally impossible to do without baking the ship's interior (Un)fortunately for me, Will Lockett has his own website where he posts all the articles he writes. I think this paragraph is important and I'll try to be on the light side but I 100% understand if it gets removed: Just at a first glance - There seems to be, at best, a lot of logical fallacies in play, at worst a lot of playing to a particular crowd. His collection of articles is very Anti-Trump and Anti-Elon. That isn't a problem in itself but Will seems to be either unintentionally falling for or maliciously parroting the idea that because someone does something bad that everything they ever touch must be bad. It is a very attractive idea that we can divide people into "good" and "evil" piles. But the world does not work like that. The closest analogue is Henry Ford. Henry Ford started a company that revolutionized the automotive industry. Henry Ford published a newspaper designed to spread antisemetic conspiracy theories. Both of these can be true. With that out of the way, on to the article (https://www.planetearthandbeyond.co/p/starship-was-doomed-from-the-beginning): The thesis is generally "Starship was doomed from the start and SpaceX might never be able to fix it." He pins this on a number of reasons. Firstly he talks about flights 7 and 8 failing for the same way. He talks about the vibration problem, calling it a "pathetic excuse" and linking back to an article where he talked about that. In that article (https://www.planetearthandbeyond.co/p/spacex-has-finally-figured-out-why) he goes through some reasons: Back to the first article, that was a massive tangent. Gee, it couldn't have been, I don't know, that they only anticipated needing ten Starlink simulators and didn't want to make that many more on short notice? No, it must be that reducing the rocket's mass from 358 tons to 354 tons was an attempt to reduce the loads on the fuel lines! Of course! (350 tons is a rough ballpark number which should be within 100 tons of Starship's mass at that point in the flight) He also doesn't mention any of the actual changes they made to prevent this issue from recurring. Granted those didn't work either, but he chose something completely unrelated, that sounds stupid and obviously won't work, as his example of how they attempted to fix the problem. Now he does get into how the flaw may be fundamentally baked into the v2 design. This is an important thing: If the fuel lines are fundamentally flawed and the problem can't be fixed by whatever reinforcements you can construct to fit inside of the tank hatches (if those even still exist), or by altering throttle profiles, you have to either cut the current ships open or build new ones. I noted this in an earlier post of mine. This has the potential to be a problem that takes a long time to solve. They may be able to alter throttle profiles, or build some reinforcements inside the existing ships, but this might be something that requires them to make significant structural changes to the current ships, that might possibly require them to scrap all existing ships if the problem proves to be on the extreme side. Now instead of saying that, he jumps straight beyond "We have to wait for new ships to be built from the ground up" and lands on "They will never fix this problem because the solution would be too heavy." At this point he links another article (the fourth one) but in the interest of time I will not dive deep into it. This is the second paragraph: First implying that the distinction matters. Second implying that SpaceX is obligated to disclose that. Third implying that the two options are mutually exclusive. Fourth ignoring that when this has happened in the past, we have a pretty good idea of what happens, it tips over, explodes, and the bottom half stays on the drone ship and the top half sinks into the ocean. That tells me everything I need to know about that article, so back to the actual article. So, his argument is that future Starships will never fix the issue that destroyed Flights 7 and 8. This is not an exaggeration, here is a direct quote: He argues that the previous version (v1) of Starship had major fuel delivery issues causing engines to fail repeatedly. This is untrue. Flight 2 failed because of a vent causing a fire if I remember right. If you stretch it, this is technically a fuel feed issue causing the engines to fail. But not repeated. He may be referring to the atmospheric hop tests in which they had a lot of issues with the fuel feed systems causing the engines to fail during the landing burn. However it is apparent that these have been long since solved. He then says that the fuel feedline changes (which are for the vacuum Raptors) were an attempt to fix this issue that made the problem worse, and that somehow this is the complete opposite of iterative design. This is bonkers. Anyway he then goes on to talk about mass. ? "The craft repeatedly spiraled out of control" That happened on flight 3 and to my knowledge never again on block 1. "Control surfaces failed" Yes, burn through of control surface hinges has been a major problem on block 1. This is a valid point, though I will point out that in all cases, Starship survived and all control surfaces remained operational. "Reportedly, the inside of the craft got hot" There is that leaked shot from flight 4 showing a glowing bay. We do not know if this has since been fixed but the simplest explanation is heat shield issues. "On top of that, these tests confirmed that Raptor can't produce enough thrust" What is this guy talking about? Is there some Raptor thrust conspiracy I'm not aware of? Ok here's this guy's opinion. WHAT WHATTTTTTTTT God, please forgive me for wasting this Sunday arguing with someone who has no idea what he's talking about. This guy is basically saying that instead of putting mass towards atmospheric protection, mass should go towards a massive de-orbit burn to reduce heating loads. "This should make landing more viable" Bruh the landing burn was like not a problem "The craft should be more controllable" What "The lower heating loads can allow the TPS to be shrunk" sure if this were the case at all "saving weight" Generously, let's say you can make your TPS 10 tons lighter this way. At best 10 tons of fuel is like 400m/s. That isn't doing jack squat up against re-entry. "Lower thrust means you need to bring more fuel" that's an isp thing not a thrust thing "Block 2 is larger and heavier than block 1" I have not seen heavier justified. But I will get into this later. "Ah yes, we need more fuel flow to feed the same six engines that there was on block 1!" (For the record, vacuum jacketing the feedlines is to reduce boiloff) "Landing would be harder with the bigger fuel lines" I mean slightly? This is a very small amount of additional mass. Okay so, skipping to the punchline: This guy believes that SpaceX's only solution is to save mass is by reducing the factor of safety. Now what I've heard in my circles is that the planned mass reductions are largely coming from better integration of systems they had previously tacked on as temporary fixes. Throughout block 1 they kept tacking on temporary fixes to problems, and added permanent solutions to future blocks. Some examples include the detachable hot stage ring, the massive "pasta strainer" 9m wide ice filter that is rumored to exist, and, if they end up doing it, struts inside the fuel tank to deal with fuel line resonances. And those are just some of the obvious ones we know about. In the future these will all be lighter, less "brute force" fixes. That and general iteration. Raptor didn't get light by just sitting around. Switching to Raptor 3 should enable a massive amount of mass savings for a variety of reasons. This guy then says "You can never achieve iterative design with a full scale prototype." Uhhhh.... They are? Also, Falcon 9? To a lesser extent, of course. But F9, especially the reuse program, has been a very iterative process. He then proceeds to argue for a 1/10 scale test Starship to help "determine the best compromise from bellyflop and retro-rockets." Firstly... What compromise? The landing burn is the same regardless. The mass of beefing up the heat shield to handle higher re-entry stresses will always (within sane bounds, LEO methalox re-entry) be lighter than the mass of the fuel required to slow down to what the heat shield can handle. There is no compromise. Secondly, you cannot test re-entry dynamics with a 1/10 scale model. The distance between a shockwave and the surface of your spacecraft, a factor which heavily influences heating, depends on the curvature of the spacecraft body. Blunter objects push the shockwave back further, and that is why re-entry vehicles tend to be very blunt. You are not going to get a particularly meaningful result out of the box with a 1/10 scale re-entry test article. Maybe with some extensive computer analysis. I'm sorry, what? 1/10 scale versions, which wouldn't be large enough for even a single Raptor, being able to say "Oh Raptor isn't making enough thrust" despite the fact that even if that were true you could figure that out on the ground, and that TWR is the dominant driving factor for payload capacity? Despite the fact that even Raptor 2 is like the second or third highest TWR rocket engine ever, behind only Merlin 1D and possibly the RD-276???????? 1. Falcon 9 was not initially meant to be fully reusable. Falcon 9 was initially meant to be expendable to my knowledge, and then had a brief period where they thought they could do full reuse, and then went with partial reuse. 2. Just making the rocket larger is one of the things necessary to solve this. As I mentioned earlier, a higher radius of curvature will make surviving re-entry easier. The square cube law also helps a lot with larger things. Larger rockets in general get better mass ratios to orbit because of this, leaving a lot more "Oh this was harder than we expected, I will use 2 tons of mass to fix this" margin before the payload drops to unusable levels. 3. This told them that Falcon 9 full reuse wasn't practical. Not that Starship is impossible. If this was the plan, then it isn't working very well and SpaceX would be hemorrhaging money. HLS is like 2.9 billion and by the author's own numbers that only covers less than 1.5 years of Starship dev. To my knowledge this is most of the current government funding for Starship. If I was trying to fleece the federal government, I wouldn't build an entirely new launch site and conduct several suborbital tests with my own money, underbid on (and agree to self fund part of) a Moon lander contract for 2.9 billion dollars, build out much of the hardware for that moon lander (individual systems are deep into testing), launch eight full scale rockets, and do a lot more dev work. I would instead do what Bechtel is doing and charge NASA 2.7 billion dollars for a launch tower. https://oig.nasa.gov/wp-content/uploads/2024/08/ig-24-016.pdf Do be aware that I am flirting with whataboutism in that last paragraph. So, TLDR: Will Lockett is either misguidedly or dishonestly pushing an Elon Bad agenda. "Elon Bad" is a justifiable thing to think. "Elon Bad, therefore anything Elon does is Bad" is not a justifiable thing to think. Will's articles at best seem like someone who doesn't understand aerospace falling for confirmation bias and finding evidence that on the surface appears to support his agenda. Will's articles at worst seem like someone trying to push an "Elon Bad" agenda to a group of people who know nothing about aerospace, with just enough technical fluff that someone who doesn't know any better could believe every word of this despite it being utter nonsense. He asserts that Starship is a scheme to scam the federal government. He asserts that Starship v2 is a failure and will never be a success because Starship's mass growth problems necessitated dipping into a factor of safety. He asserts that Starship V2 is attempting to reduce re-entry loads and save mass by slowing down with rockets first. Which makes no mathematical sense if you've ever played KSP RO/RP-1. He makes several basic factual and reasoning errors. He claims Starship is expensive by dividing the estimated annual program cost by the amount of flights in that year. Yes, each individual starship flight is expensive right now. But he holds this up as the number that customers will be charged. This is almost as bad as saying that Artemis 1 cost 26.5 billion dollars because that's the total SLS expenditure up to that point divided by the number of flights. I would not trust a word out of this guy's mouth.

This is very much in "trust me bro" territory but the word on the street is that the "extremely long" v3 is postponed or dead and what is now being called "v3" is the same size as v2 and is expected to have about the same payload capacity. I haven't been keeping up with AI but the last time I checked, which was admittedly like a year ago, ChatGPT couldn't even do delta v addition correctly, and could not get it through its head that aerobraking reduces delta v requirements. Though it has advanced a lot in a year presumably, I would not trust it to do that sort of math, especially when there isn't enough information in your query to actually do that calculation.

I think they are going to take their time with this one. They ran into (what is likely, from what I know as an outsider) the same problem twice after they thought they had done enough to mitigate it or fix it. I think they would strongly prefer to make sure they understand the issue before proceeding as if they dump 100 tons of debris over the Caribbean a third time it really, really wouldn't be a good look. Though on second thought I'm not sure that anyone who has the power to raise this as an issue would actually want to stop them but that's off topic. If they can't perform a temporary fix for the fuel line resonance with a different throttle profile or some struts that are small enough to get into the tanks, this might be the sort of thing that requires heavy modification, either opening the ship back up or skipping a few ships if the problem really is that deeply entrenched.

Here is my Starship terminal velocity spreadsheet, I recommend you mess around with it yourself: https://docs.google.com/spreadsheets/d/1u6JzCNra7bFj1BVYvQm_XSVkjNFsqdjO9h5TVaydp9Q/edit?usp=sharing I would not put any stock in the results as there are too many unknowns. However I'm confident in it enough to put an extreme upper bound on block 1 landing (not dry) mass at 350 tons with a more reasonable value at 250 tons. The methodology is using the telemetry from flights 4, 5, and 6 during the terminal phase of descent, just before engine startup, and estimates of the in-stream area and drag coefficents of Starship's various components to calculate the mass at that point in flight. I do not think that even with Starship's substantial mass growth, that the actual dry mass is above 200 tons as that was what Mk 1 was waaaay back in 2019. As you can see, this analysis does very little but state the obvious. Unless for some reason I'm correct and Starship really is that heavy at landing. There are many sources of error: Area errors: Starship's exposed areas were calculated through pixel counting. They are likely somewhat wrong due to perspective and human error. Thus the flap areas are wrong. My estimation of the exposed area of the Starship nose cone is likely off by somewhat. I did not account for the flap covers at all. I assumed the flaps were flat plates, 100% of the area of which moved if I remember correctly (I did this math a while ago). We do not really know what the average flap angle is during descent. If the area increases, starship's mass increases and vice versa. Drag coefficient errors (BIG DEAL, a lot of errors here): The drag coefficient of something you build out of shapes is not simply the area-weighted average of those shapes. They interfere and you can't just look up the drag coefficient of a Starship. I did the weighted average approach which is quite error prone. For all of my calculations I pulled the first number for "Shape drag coefficeint" off of google. The open bottom of the cylinder is expected to increase drag. The lack of an exposed face on the other side of the cylinder is expected to decrease drag. The drag coefficient for an angled plate is less than a flat one but there's no easily googleable way to figure that out. I used to know the math for that sort of stuff but that notebook is currently several states away and I don't want to re-learn flat plate compressible aerodynamics right now. I am likely overestimating the drag coefficient of the nose cone. If the actual CD is higher, it will translate to an increase in Starship's dry mass. Velocity errors (who knows): SpaceX telemetry reports one velocity scalar. Vertical velocity is not listed separately, and I expect that Starship will have some horizontal velocity - e.g. It may "glide" in with an extremely steep glide slope. If it does this, there's also lift to take into account, meaning the drag calculations are way off. Starship going crossrange (actual downwards velocity is lower than listed velocity) will significantly lower Starship dry mass. At the upper end, 2m/s of difference is like 7 tons lighter (IFT 4 102m/s -> 100m/s) SpaceX telemetry may not be perfectly accurate (the least of our worries) Atmospheric conditions: I assumed 1.175kg/m3 atmospheric density at the landing site. This varies, and while Starship is below 1km or so (if I remember right), the atmospheric pressure may not be that high. A lower atmospheric pressure will linearly correspond to a decrease in Starship landing mass. Flight by flight error sources and data: Flight 4 missed the target by 6 kilometers (I think this was from a CEO tweet or interview or something) and may have been booking it crossrange to attempt to get to its landing site. It also had a massive gaping hole in one of (at least that we know of) its flaps. Therefore I would not put too much stock into how its terminal velocity of 102.22m/s corresponded to a landing mass of 339 tons. Flight 5 had a terminal velocity of 92.2m/s and an estimated landing mass of 276 tons. Landing was onsite so crossrange velocity errors should be lower than flight 4. Flight 6 had a terminal velocity of 84.17m/s and an estimated landing mass of 230 tons. Landing was onsite so crossrange velocity errors should be lower than flight 4. General errors: The calculation used was subsonic flow. Distinguishing estimated landing mass from dry mass: Starship has an unknown propellant load at this point in the flight. The header tanks and feedlines contain the landing propellant but it is unknown exactly how much is used during the landing burn or how full they are (though I presume they are pretty full). Unsure if remaining propellant is vented or not. Depending on temperature, the mass of the remaining ullage gas in the tank could range from like 5 tons to like 40 tons depending on temperature and tank pressure. Starship displaces somewhere around 3.5ish tons of air at sea level and will "appear" that much lighter than it actually is from this analysis Is the nose cone pressurized? If so, with what and how much pressure? Conclusions: This is an extremely bad way to estimate Starship's dry mass. There are very many numbers which you can slightly tweak and they would still fall within the reasonable range that jump Starship's landing mass up or down by more than ten tons. I doubt we will get anywhere with this model but if you have any ideas let me know. Two things that would really help are if someone with CFD experience could try to figure out a vague estimate of Starship's actual drag characteristics, and when we get a ship catch in some number of months, we might get a long range tracking shot showing the ship's approximate glide angle.

@tater re: Starship dry mass. This is not a particularly good estimation method as there are far too many variables but I did make an attempt a few months back to estimate it using the terminal velocity of a belly flopping starship. If I remember and have time I can share my results when I get home though there is so much uncertainty they are pretty much worthless. Maybe I might get some ideas about how to refine them from yall.