Replacing SLS/Orion using Starship HLS and Crew Dragon

[TheRadicalModerate]

For Mars Global Surveyor they didn't retract the solar arrays during aerobraking. And standard LEO solar arrays are exposed to lots of atomic oxygen over their entire lifespan. Between the two, I expect it won't actually be an issue.

IIRC the MGS aerobraking was for orbit adjustment, wasn't it?  Not the actual capture?  They did many passes, shaving off just a bit at a time.

Aerocapture is at least one OOM more aggressive?

Well, you're already (usually) captured in a TEI; it's just a question of getting the apogee from lunar distance down to LEO.  That said, it will be a higher speed at perigee than MGS had, at least for a while.  But we're in no rush.  If it takes 3 months to get a depot or LLS-HLS back to LEO, that's no biggie, at least until Starship has super-high cadence.  So we can take very small bites of reduced delta-v at perigee.

[InterestedEngineer]

For Mars Global Surveyor they didn't retract the solar arrays during aerobraking. And standard LEO solar arrays are exposed to lots of atomic oxygen over their entire lifespan. Between the two, I expect it won't actually be an issue.

IIRC the MGS aerobraking was for orbit adjustment, wasn't it?  Not the actual capture?  They did many passes, shaving off just a bit at a time.

Aerocapture is at least one OOM more aggressive?

Well, you're already (usually) captured in a TEI; it's just a question of getting the apogee from lunar distance down to LEO.  That said, it will be a higher speed at perigee than MGS had, at least for a while.  But we're in no rush.  If it takes 3 months to get a depot or LLS-HLS back to LEO, that's no biggie, at least until Starship has super-high cadence.  So we can take very small bites of reduced delta-v at perigee.

Solar panels are going to have to retract for MARS EDL, so I don't see why you need to bother with 25 m/sec passes for aerobraking.  Just EDL the depot directly, or maybe in 2 passes, reusing whatever solar panel setup is being used for Mars

[TheRadicalModerate]

Solar panels are going to have to retract for MARS EDL, so I don't see why you need to bother with 25 m/sec passes for aerobraking.  Just EDL the depot directly, or maybe in 2 passes, reusing whatever solar panel setup is being used for Mars

Remember, this is all to answer the question, "What could we do with D2 and LSS, using what we know of them today, to replace SLS/Orion?"  Right now, there isn't a solar panel setup for Mars.  And depots and LSSes will probably have some thermal arrangement other than the standard EDL TPS.  That said, if SpaceX has some kind of deployable solar panel system that's under development for long-duration transits, that'd work fine--as long as it can stow and re-deploy reliably for a few hundred cycles.

If you had a deployable QD gender-bender (as opposed to one that was installed on the pad and launched), then an EDL-capable tanker could:

1) Launch
2) RPOD at a depot.
3) Pull a load of prop into itself.
4) Undock and deploy the gender-bender.
5) Boost to high orbit, where it acts as a temporary depot for a target LSS.
6) Stow the gender-bender.
7) Return directly to EDL.

As long as the transit to the high orbit is short, there shouldn't be major boil-off problems with the tanker, and you can save a bunch of delta-v with the direct EDL.  But if a real-live depot can aerobrake back into VLEO, it can shuttle prop to high orbit just as well.  It might even be better, because the dry mass penalty for low boil-off is likely to be lower than that for EDL.

I have no clue how tolerant (and aerodynamically stable) a no-TPS, no-elonerons depot would be to entry heating, but it's almost certainly going to be able to lose 25m/s of delta-v per pass, and might easily be able to lose a couple hundred m/s.  25m/s gets it back to VLEO in 2 months.  200m/s gets it back in 2 weeks.

Update:  I posted something over on the Starship on-orbit refueling thread about this.  Probably better discussed over there.

[sdsds]

Here's a concept of operations that might "close." It's based on the idea that a spacecraft doesn't want to being carrying propellant down to the lunar surface that it doesn't need.

HLS:
- fills at an LEO depot and performs TLI
- rendezvous with an NRHO depot and offloads excess propellant
- boards crew in NRHO and takes them to the lunar surface
- returns crew to NRHO
- rendezvous with the NRHO depot and reloads the propellant it previously offloaded
- performs TEI
- performs LEO insertion and rendezvous with the LEO depot to refill.

Does offloading and later reloading the propellant in NRHO enable the propulsive LEO insertion?

[OneSpeed]

Does offloading and later reloading the propellant in NRHO enable the propulsive LEO insertion?

Here's a spreadsheet you can download which has a number of mission profiles modelled, but uses LLO rather than NRHO for the depot. I've given the depots two prop payloads, so one can be loaded before lunar descent, and one after, or even both after if practical.

I can't get an HLS/Depot based on Starship 2 to close from LEO, but it just works from HEO. If based on Starship 3, TLI from LEO just barely closes. Only the Starship 3 HLS from HEO has a significant amount of excess propellant on arrival in LLO, but perhaps it should be retained for abort scenarios?

EDIT: fixed unintentional sandbagging in ft to m calculation.

[InterestedEngineer]

Does offloading and later reloading the propellant in NRHO enable the propulsive LEO insertion?

Here's a spreadsheet you can download which has a number of mission profiles modelled, but uses LLO rather than NRHO for the depot. I've given the depots two prop payloads, so one can be loaded before lunar descent, and one after, or even both after if practical.

I can't get an HLS/Depot based on Starship 2 to close from LEO, but it just works from HEO. If based on Starship 3, TLI from LEO just barely closes. Only the Starship 3 HLS from HEO has a significant amount of excess propellant on arrival in LLO, but perhaps it should be retained for abort scenarios?

Your Isp of 360 is low.

Use two SL main engines throttled to 50%.  3 Rvacs.   4 engines thrust total.

Rvac = 372
SL = 350

(3 * 372 + 1.0 * 350) / 4 = 366~367.

That's a little under 2% better deltaV than your calcs.  Which might be enough to meet margin in the corner cases.

[InterestedEngineer]

Does offloading and later reloading the propellant in NRHO enable the propulsive LEO insertion?

Here's a spreadsheet you can download which has a number of mission profiles modelled, but uses LLO rather than NRHO for the depot. I've given the depots two prop payloads, so one can be loaded before lunar descent, and one after, or even both after if practical.

I can't get an HLS/Depot based on Starship 2 to close from LEO, but it just works from HEO. If based on Starship 3, TLI from LEO just barely closes. Only the Starship 3 HLS from HEO has a significant amount of excess propellant on arrival in LLO, but perhaps it should be retained for abort scenarios?

Pretty neat. 

Here's one I came up off this spreadsheet, when I noticed that a standard Starship V3 can deliver 500t of fuel to LLO, and then EDL home.

That allows HLSv3 to top off before descent (a bit) and after ascent (a lot) and do a burn at earth to rendezvous with a D2, so we aren't subjecting humans to Starship EDL.  I dropped the cargo to 125t to do this but I don't think that's a stretch, I don't think they were shooting for 200t on the lunar surface.

So three full ships to luna

I still think one could delay the program one year to get Starship EDL certification, which lops off 3600 m/sec of deltaV coming back to Earth and drops this whole thing to one V3 tanker + V3 to LLO, and HLS stays in the Moon's SOI as a shuttle.

[TheRadicalModerate]

Does offloading and later reloading the propellant in NRHO enable the propulsive LEO insertion?

Here's a spreadsheet you can download which has a number of mission profiles modelled, but uses LLO rather than NRHO for the depot. I've given the depots two prop payloads, so one can be loaded before lunar descent, and one after, or even both after if practical.

I can't get an HLS/Depot based on Starship 2 to close from LEO, but it just works from HEO. If based on Starship 3, TLI from LEO just barely closes. Only the Starship 3 HLS from HEO has a significant amount of excess propellant on arrival in LLO, but perhaps it should be retained for abort scenarios?

1ft = 0.3048m not 0.3408m.  Those pesky transpositions.

Also, what's your source on the Apollo 11 numbers?  Here's a pretty hard to read and unsearchable copy of the flight plan numbers, which are substantially different--in some places.  Your numbers seem to jibe with the numbers in the detailed prop budgets starting on page 5-23, but those don't agree with the burn schedule delta-v numbers on page 1-8.

I have a hunch that the stuff starting on page 1-8 has the "flexibility" and "3σ dispersion" items amortized across the burns, but I haven't cranked things through.

The margins Apollo 11 had were massive, which is probably reasonable, given the unknowns.  We should probably come to some kind of consensus on what kind of flight performance reserve is reasonable with modern hardware and flight experience.  FWIW, I've just been adding 1.5% to all delta-v numbers, which may be way too optimistic. (It certainly is by Apollo standards.)  I also have sump losses, ullage gas, and sheer wild-ass guesses for boiloff rates and loiter times. 

When you add all this stuff in, things get a lot tougher.  You transposition error unintentionally adds a bunch of margin, but I don't recommend that as a methodology.

Your Isp of 360 is low.

Use two SL main engines throttled to 50%.  3 Rvacs.   4 engines thrust total.

Rvac = 372
SL = 350

(3 * 372 + 1.0 * 350) / 4 = 366~367.

That's a little under 2% better deltaV than your calcs.  Which might be enough to meet margin in the corner cases.

We don't really know what the gimbaling safety margins are here, so this is hard to answer.  On the optimistic side, you might get away with a single RSL throttled to 50%, which would give you 369s (which is what I usually use).  That's probably fine for big in-space burns, but for lunar descent and ascent, I'd expect them to use at least 2 RSLs with the 3 RVacs throttled to the point where the accelerations where controllable.  Or maybe they'll just use 3 RSLs, no RVacs, and have done with it.  That would make make Isp much lower.

This is another unknown that we should probably have some sort of consensus about.

BTW, where did you get the Isp=350s for the RSLs in vacuum from?  When I do the calculation, I get about 354s for RSL v2 vacuum performance, but I don't trust my calculations very much.

[OneSpeed]

1ft = 0.3048m not 0.3408m.  Those pesky transpositions.

Thanks, well spotted! Updated in the original post.

Also, what's your source on the Apollo 11 numbers?

My starting point was the graphic attached below, but where there were specific figures mentioned in the Apollo 11 flight plan, I used those instead. Apollo did have relatively large margins built in, but I don't think that brings into question their base ΔV numbers.

I would like to download your spreadsheet for comparison, but there are circular reference errors when I try to download the Excel format. Could you post it here as an attachment?

[TheRadicalModerate]

Also, what's your source on the Apollo 11 numbers?

My starting point was the graphic attached below, but where there were specific figures mentioned in the Apollo 11 flight plan, I used those instead. Apollo did have relatively large margins built in, but I don't think that brings into question their base ΔV numbers.

The question is which set of base delta-v numbers to use:  those starting on page 1-8, or the more detailed consumables numbers later on.  I've been using page 1-8.  Not a lot of difference, but some.

I would like to download your spreadsheet for comparison, but there are circular reference errors when I try to download the Excel format. Could you post it here as an attachment?

I must've turned on iterative calculation for something weird a long time ago and forgotten to turn it off.  Fortunately, the circular references were just a few copy-and-paste errors (never cut and paste in google sheets if you're used to Excel; it maintains pointers to the old relative references, which yields appalling results).  I think I have them fixed now.

I've never tried exporting the Google sheet into Excel, since it was born and raised in Google.  There are some array formulae that are fairly important in how the maneuver blocks work, and those will sometimes give you problems on import.  If you get it to work, let me know.

Here's the updated version.  I recommend just copying it to a google drive folder and going from there.  It does rely on a separate delta-v table, which may or may not give you permission problems when you make a copy.  If so, the whole sheet will go nuts, and you can get the delta-v table here.  You can copy it as well and then update the link in the "delta-v table" tab of the main set of sheets so it points to your copied version.

Be warned that it's a spreadsheet that only its author could love.  It's quite flexible and powerful when I use it, but it's... idiosyncratic.  The ReadMe is fairly up to date.

[clongton]

Also, what's your source on the Apollo 11 numbers?

My starting point was the graphic attached below, but where there were specific figures mentioned in the Apollo 11 flight plan, I used those instead. Apollo did have relatively large margins built in, but I don't think that brings into question their base ΔV numbers.

The question is which set of base delta-v numbers to use:  those starting on page 1-8, or the more detailed consumables numbers later on.  I've been using page 1-8.  Not a lot of difference, but some.

I would like to download your spreadsheet for comparison, but there are circular reference errors when I try to download the Excel format. Could you post it here as an attachment?

I must've turned on iterative calculation for something weird a long time ago and forgotten to turn it off.  Fortunately, the circular references were just a few copy-and-paste errors (never cut and paste in google sheets if you're used to Excel; it maintains pointers to the old relative references, which yields appalling results).  I think I have them fixed now.

I've never tried exporting the Google sheet into Excel, since it was born and raised in Google.  There are some array formulae that are fairly important in how the maneuver blocks work, and those will sometimes give you problems on import.  If you get it to work, let me know.

Here's the updated version.  I recommend just copying it to a google drive folder and going from there.  It does rely on a separate delta-v table, which may or may not give you permission problems when you make a copy.  If so, the whole sheet will go nuts, and you can get the delta-v table here.  You can copy it as well and then update the link in the "delta-v table" tab of the main set of sheets so it points to your copied version.

Be warned that it's a spreadsheet that only its author could love.  It's quite flexible and powerful when I use it, but it's... idiosyncratic.  The ReadMe is fairly up to date.

Nice find! Thanks

[Greg Hullender]

Here's a spreadsheet you can download which has a number of mission profiles modelled, but uses LLO rather than NRHO for the depot. I've given the depots two prop payloads, so one can be loaded before lunar descent, and one after, or even both after if practical.

I can't get an HLS/Depot based on Starship 2 to close from LEO, but it just works from HEO. If based on Starship 3, TLI from LEO just barely closes. Only the Starship 3 HLS from HEO has a significant amount of excess propellant on arrival in LLO, but perhaps it should be retained for abort scenarios?

Very nice!

A couple of questions: First, why are the Starship and the HLS the same? I thought the HLS would have a significantly lower dry mass.

Second, why do the depots have less fuel than the corresponding Starships? Shouldn't the depos have more propellant?

[OneSpeed]

A couple of questions: First, why are the Starship and the HLS the same?

I'm assuming all variants of each Starship version will have similar GLOW, and hence similar T/W, for similar mass to orbit. Starship has body flaps, whilst HLS has landing thrusters and additional thermal protection. Also, the internal fitouts could vary substantially at this stage, so for the moment I'm calling it a wash.

Second, why do the depots have less fuel than the corresponding Starships?

Prop load and payload for a tanker or a depot are interchangeable. I've calculated enough propellant for each depot to complete its LLO mission from HEO, and the balance is payload.

That said, the point of the spreadsheet is not to dictate numbers to anyone. The point was to allow anyone the opportunity to play with those numbers, and quickly see how those changes might propagate across a range of missions.

[sdsds]

The "Technical Annex" to a SpaceX FCC application, attached here, is worth reading. For example:

[...] crewed lunar missions will include a secondary propellant transfer in MEO/HEO, the Final Tanking Orbit (“FTO”). Operations in MEO/HEO will occur in an elliptical orbit of 281 km x 34,534 km and an altitude tolerance of +116,000/-24,000 km apogee and +/- 100 km perigee, with inclination between 28 and 33 degrees (+/- 2 degrees).

[clongton]

Bump

[TheRadicalModerate]

If this architecture were to be used, would it require building another D2?  A few reasons it might:

1) It's another kind of task to go onto the rota of things D2 (the crewed version) is used for.  Right now, it handles ISS crew transport and private crew missions. The 5-vehicle fleet seems to be capable of supporting these two categories of flight.  But if you add 2-3 missions a year to cislunar space (let's be optimistic), then the turnaround time, which I assume is substantial, could start impacting cadence.

1a) If we require two D2's to be ready to go per mission (one for getting the crew to LEO, and one to do the RPOD with the LSS in case of a contingency), then we're taxing the system even more.

2) There is some modest amount of modification to make the D2 fit for purpose as the first leg of the ES-NRHO-ES architecture, as we've enumerated up-thread.  I can't think of a reason why those mods would disqualify the modified D2 from flying ISS or other private missions, but it's possible.

3) If SpaceX and NASA settled on the "take D2 along to NRHO on the nose of the LSS" variant (a solution for the RAAN problem if a contingency requires the LSS to come home early, also discussed up-thread), then we're stressing the D2 in two specific ways that could affect its turnaround time:
a) We're subjecting its avionics to GCR and lot of solar protons.
b) We're putting a lot of stress on the docking hardware during Raptor burns.

If this architecture requires a sixth crew D2 to be built, that's something that would need to happen pretty soon, if there were to be little impact on the Artemis schedule.

[DanClemmensen]

If this architecture were to be used, would it require building another D2?

<sarcasm>
No additional D2 is needed, because Starliner will be flying more than half of the remaining CCP missions.
</sarcasm>

[LaunchedIn68]

If this architecture were to be used, would it require building another D2?

<sarcasm>
No additional D2 is needed, because Starliner will be flying more than half of the remaining CCP missions.
</sarcasm>

2020 Called.  It wants that comment back!

[Twark_Main]

Also, what's your source on the Apollo 11 numbers?

My starting point was the graphic attached below, but where there were specific figures mentioned in the Apollo 11 flight plan, I used those instead. Apollo did have relatively large margins built in, but I don't think that brings into question their base V numbers.

The question is which set of base delta-v numbers to use:  those starting on page 1-8, or the more detailed consumables numbers later on.  I've been using page 1-8.  Not a lot of difference, but some.

I would like to download your spreadsheet for comparison, but there are circular reference errors when I try to download the Excel format. Could you post it here as an attachment?

I must've turned on iterative calculation for something weird a long time ago and forgotten to turn it off.  Fortunately, the circular references were just a few copy-and-paste errors (never cut and paste in google sheets if you're used to Excel; it maintains pointers to the old relative references, which yields appalling results).  I think I have them fixed now.

I've never tried exporting the Google sheet into Excel, since it was born and raised in Google.  There are some array formulae that are fairly important in how the maneuver blocks work, and those will sometimes give you problems on import.  If you get it to work, let me know.

Here's the updated version.  I recommend just copying it to a google drive folder and going from there.  It does rely on a separate delta-v table, which may or may not give you permission problems when you make a copy.  If so, the whole sheet will go nuts, and you can get the delta-v table here.  You can copy it as well and then update the link in the "delta-v table" tab of the main set of sheets so it points to your copied version.

Be warned that it's a spreadsheet that only its author could love.  It's quite flexible and powerful when I use it, but it's... idiosyncratic.  The ReadMe is fairly up to date.

Anyone have a hard, downloadable copy of the spreadsheets?

Google has apparently decided to start putting up a hard loginwall when accessing any Google Docs file. Also it would be nice for our future-forum-readers if we had some version that won't vanish into the ether when Google decides to ban TRM's account and/or make breaking changes and/or discontinue yet another service. 

[TheRadicalModerate]

Anyone have a hard, downloadable copy of the spreadsheets?

Google has apparently decided to start putting up a hard loginwall when accessing any Google Docs file. Also it would be nice for our future-forum-readers if we had some version that won't vanish into the ether when Google decides to ban TRM's account and/or make breaking changes and/or discontinue yet another service. 

Yes, Google is failing pretty hard on the whole "don't be evil" mission statement.  But evil is always relative, which is why my last copy of Office is from 2016, and doesn't have the LET function in it, of which I've grown very fond.  So a naive export failed.