Sideways Engineering the SpaceX Dragon

[mrmorris]

Having taken my GX-3 intellectual exercise about as far as I think it can be stretched, and feeling a craving for some additional space-related brain activity, I was thinking that a reasonable successor would be for me to look into the Dragon spacecraft being developed by SpaceX. I'm curious just how much can be deduced about its specifications and capabilities from the information publicly available. Since the Dragon is still under development, I can't very well call this reverse-engineering. Instead, I'm going to try my hand at creating the Dragon sideways-engineering project. Unfortunately, as much as I miss posting, real-life still has me busy enough that I can't devote as much time to this as I did when working on the G-X3 thread. Hopefully I'll be able to post at a reasonable pace. Since the Dragon will (presumably) exist in a few years, it will be interesting to see just how close it's possible to get to the actual specs.<br /><br />The Dragon capsule has a *lot* in common with the G-X3. I plan to make use of a lot of my existing work from that thread and modify the calculations, equipment, etc. to match with the Dragon profile. In some ways, modeling Dragon should be easier than G-X3 -- after all, I have *some* hard specs and diagrams to work from. However, it will be harder in others, because I will have to guess at SpaceX's goals for the craft whereas I knew what my goals for G-X3 were. <br /><br /><br />SpaceX Stated Goals:<br />-- It will be launched from the proposed SpaceX Falcon-IX booster to LEO (185 by 300 kilometers) and have the internal propulsion capability to increase the orbit to 400km. <br />-- It must carry seven people. <br />-- It will have the ability to remain on station for six months. <br /><br />Goals I'm Assuming:<br />-- The craft is optimized for ferrying people from ground to a space-station and back again. <br />-- Given the very volume-restricted crew quarters, and a desire to minimize ECLSS requirements, the transit time from lau

 

[Boris_Badenov]

Welcome back mrmorris, I’m glad to see you return<img src="/images/icons/smile.gif" /> Your original GX-3 thread is the one that caught my eye & drew me to SDC. I owe you many thanks, & much gratitude. I followed the thread from about page 10 until it was completed, but did not begin to post until June of this year.<br /> <br /> I believe that Dragon weighs in at 16,000# unloaded.<br /><br /> This thread has some more info on the Dragon.<br /><br /><br />http://uplink.space.com/showthreaded.php?Cat=&Board=missions&Number=458327&page=1&view=collapsed&sb=5&o=0&vc=1<br /> <div class="Discussion_UserSignature"> <font color="#993300"><span class="body"><font size="2" color="#3366ff"><div align="center">. </div><div align="center">Never roll in the mud with a pig. You'll both get dirty & the pig likes it.</div></font></span></font> </div>

 

[mrmorris]

16,000 lbs is a reasonable beginning estimate. My (very) upper-end calculations on G-X3 were around 13, 300 lbs. One of the first things I want to try to do next is break out the components and come up with a rationale for using a particular mass figure.

 

[barrykirk]

great post mrmorris. I really enjoyed reading. Thank you for spending the time to make it.

 

[spacefire]

welcome back MrMorris!<br /><br />I plan to read this tomorrow at work when I'm actually bored <img src="/images/icons/smile.gif" /> <div class="Discussion_UserSignature"> <p>http://asteroid-invasion.blogspot.com</p><p>http://www.solvengineer.com/asteroid-invasion.html </p><p> </p> </div>

 

[mrmorris]

I hadn't really planned to critique the design of the Dragon -- certainly not this early in the thread. However, this is somewhat less of a critique than a prediction. I think that the mouse ears are likely to disappear. Here's the logic I'm using:<br /><br /> I already mentioned in my first post that given the deployment style, it doesn't appear that the ears are made to be used until just before docking with the station. Expanding on that -- they obviously <b>can't</b> be deployed until the Dragon is in orbit. Given the assumption that the launch-to-docking time is being minimized -- soon after the second-stage separation, the Dragon will be initiating a burn for the Hohmann transfer to ~400km. Having the nosecap open and panels extended at this time would change the c.g., so it's unlikely they would be deployed before then. The transfer orbit will only take ~45 minutes and since they'll want to dock in sunlight -- would likely largely occur in the Earth's shadow. All this says to me that the panels won't be deployed until just before the Dragon berths with the station.<br /><br /> Even if the above is completely off the mark and the panels *are* intended to be deployed as soon as the Dragon is in orbit -- I've taken the power calculations a bit further. In the first post, I calculated minimum and maximum power outputs from the panels. The maximum is *highly* optimisitic, and I believe even the minimum figure is somewhat high. However, we'll use the lower figure to compare a panels-to-batteries. The average output from the panels over the lighted portion of the orbit (~45 minutes) was .59 kW. Translating this into Watt-Hours, we get:<br /><br />590 W * .75 hours = 442.5 W Hrs<br /><br /> While researching the G-X3, I came up with the following figure for my battery mass. I didn't re-research this figure for the current calculation, so I have to hope I got it right the first time. <img src="/images/icons/smile.gif" /><br /><br />Li-Ion Batteries

 

[bitbanger]

With regards to the Dragon getting its power from the ISS, that assumes that the ISS is the only destination. Considering the published discussions between Bigelow and Musk, I doubt that assumption is correct.<br /><br />The larger than required panels may be driven by a desire to top off battery charge as quickly as possible in order to support rescue operations. Also having a minimum 11 day turnaround isn't very useful if you are providing a delivery service. Idle time is a major cost for any shipping concern.

 

[mrmorris]

<font color="yellow">Also having a minimum 11 day turnaround isn't very useful if you are providing a delivery service. </font><br /><br />You didn't follow the rest of the math to its conclusion. Admittedly, I implied it rather than working it out explicitly. From the post:<br /><br /><font color="orange">Let's say the panels only provided 200 Watt-hours per orbit. In this case, the excess would be about 50 Watt-Hours. The batteries would still fully recharge (given the same assumptions) in about eleven days. Added to that is the fact that while I haven't gotten to a full ascent power profile for the Dragon yet, 8850 Watt-Hours is very high. Given a 250W power usage (more than my *max* power usage assumption, much less nominal) and a ten-hour flight, the ascent power profile would be only 2500 Watt-hours. </font><br /><br />So the 11-day figure was for 8850 Watt-hours. If instead we assumed the ascent profile used 2500 Watt-hours, the turnaround for the '50-watt excess' becomes 3 days. I also noted that 2500 KWHrs is assuming more than my current maximum power usage estimate for the entire trip up. The figure should be much closer to the 'nominal' power usage, which I've estimated at about 175W. For a preliminary figure, I'd put the ascent power profile at about 2,000 KWHr which would give a 'top-off' time of about 2.5 days. This should not be a hardship.<br /><br />There's another factor to take into account as well. Your note refers to 'delivery service'. Likely you're thinking in terms of cargo. The power profile on the cargo version will be a good bit lower than the crewed version because ECLSS is a significant portion of the power usage. The cargo version would likely recharge in less than two days -- which would almost assuredly be less time than is required to unload the cargo and reload with downmass. <br />Even if the crew can turn the craft around in less time -- the cargo version wouldn't require a full charge in any case. For o

 

[mrmorris]

To get anywhere close to the specifications for Dragon, it's important to get into a reasonably small ballpark on the mass estimate. If I'm way off on the spacecraft mass, then I'll also be off on the dv propellant requirements for the RCS/OMS, the LES and de-orbit dv. It will also throw off my calculations for the landing/recovery elements. Fortunately, as has been mentioned -- the craft is similar enough to G-X3 that much of what I'd calculated there should be reasonably applicable here. This isn't surprising, as SpaceX's goal and mine are aligned extremely closely -- namely to create a capsule optimized for getting people (cargo is a sideline) from ground to station to ground. Efficiency in this context means cutting to the absolute minimum the passenger-to-mass ratio of the spacecraft. <br /><br />With that, they had to make many of the same decisions that I made for G-X3. The three biggest design points that fall out from this goal are to use a capsule design for the spacecraft; to pack the crew members in like sardines; and to minimize the ascent and descent flight times (in large part because of the 'sardine' factor). Given the same goals, convergent engineering gave the two designs many of the same features.<br /><br />Anyway -- working out the mass estimate. While SpaceX has indicated that the capsule is a cross between Apollo and Soyuz -- I haven't really been able to spot the Soyuzisms. Other than that it has a cargo-version like Soyuz/Progress -- none of the actual spacecraft features that I see seem to be pulled from that design style. Instead it seems to be a cross between Apollo and Gemini. The crew capsule is arranged in an Apollo-fashion, but the adapter/cargo section is from Gemini. The docking port at the front is pure Apollo but the shape of the capsule itself is more like Gemini (Apollo was essentially a cone with a 30-degree slope. Gemini was a truncated cone with a 15-degree slope -- as is Dragon). Whatever the differences, it's cle

 

[bitbanger]

The intent of the comment is that your analysis of the power requirements appears to assume that the Dragon capsule would only be used for missions to the ISS. There is no reason to believe that the capsule couldn't be used with two to three passengers along with experiments. It is also likely to be used to deliver passengers and cargo to Bigelow stations.<br /><br />I suspect that the size of the solar arrays are based on worst case power requirements plus a sizable fudge factor to account for unforseen requirements.<br /><br />Actually on the 'delivery service' reference I wasn't only considering cargo. If we assume a station being a tourist destination, is it likely that people would be returning in the same capsule that they were delivered in? I suppose its possible, but doing so might cause a bit of traffic congestion at the docking ports. I suspect that after things get into full swing that such flights will be operated more like airlines where the capsule would drop off one group of passengers and immediately load the returning group. <br /><br />Most of the above is speculation, and will continue to be such until the actual business is defined. The only real point I wanted to make is that SpaceX is most likely designing the Dragon to be multifunctional. Excess power capacity makes considerable sense in that case.<br /><br />

 

[mrmorris]

I really appreciate your input and I enjoy the analysis from a different viewpoint. My Gemini thread generated more of this back-and-forth in its early days than this one. I don't know if that indicates less interest in this thread or (hopefully) that my practice with G-X3 means that I'm leaving fewer gaps in my analysis to debate on. (Put another way -- I'm going to disagree with you again, but I hope you continue providing input).<br /><br />I agree 100% with your analysis of the assumptions inherent in my analysis. Dragon 1.0 is being built for the ISS. In fact NASA is paying SpaceX ~$500 million to do just that. Dragon 1.x or 2.x might well be designed for Bigelow's station or free-flying experiments, or as a bargain basement space-tourist attraction (for those poor people with only 5-million or so to blow on an orbital hop). However, the sugar daddy paying the bills at the moment for Dragon development is NASA, and they want an ISS shuttle. The note in my thread specifically indicates that the panels are unlikely to appear in Dragon 1.0 and that variant is going to be an ISS taxi. <br /><br /><b>Everything</b> in this thread is going to be predicated on that point. I'm positive that Elon would eventually like to have other customers besides NASA. However, SpaceX won't be (and most emphatically <b>shouldn't</b> be) spending any significant development time and money on pursuing options that are not relevant to the ISS until after they have a capsule that meets the needs of NASA. Given the ISS taxi variant -- I still say the best option technology and cost-wise for powering the Dragon while berthed is tapping the ISS electrical grid.

 

[mrmorris]

I saw an article recently on Spacedaily about a Surrey Satellite Technology Limited space GPS receiver and a little light bulb went on in my head. One of the big questions about the Dragon is what equipment Elon will be filling it with. Will SpaceX design most/all of the electronics themselves (impractical), or will they buy most/all of it (expensive). Most likely there will be a compromise between the two, with SpaceX designing in-house everything they can, and purchasing what they cannot from outside vendors. <br /><br />Where the light bulb came in (for anyone who hasn't yet made the connection), is that Elon bought a 10% stake in SSTL about a year back. The initial thought (or at least <b>my</b> initial thought) was that this was to match up a small satellite builder with his Falcon I launch capability. However, SSTL makes several pieces of equipment that could be of use to Dragon. This would neatly fit in to the inside/outside equation. With a 10% stake in the company, Elon should be able to get a pretty good price on hardware -- almost assuredly for less than it would take to develop and test an in-house equivalent.<br /><br />The immediate question that comes to mind involves reliability. This hardware was designed for low-cost microsatellites. Does it have the reliability for use in manned missions? After pondering the issue, I've concluded that this should not be an issue for a couple of reasons. First, despite being designed for small satellites -- this equipment was designed to be highly reliable for constant use over <b>multi-year</b> missions. By contrast, actual run-time of the equipment on Dragon missions will be on the order of days (even when the Dragon stays at the ISS for six months -- the equipment in question will be powered down). Second, while it's a given that critical equipment will need to have double and in some cases triple-redundancy, most of the equipment availabl

 

[mrmorris]

Well I just got around to looking at the SpaceX simulation of the Dragon docking operation to the ISS (better late than never). Four things immediately jumped out at me.<br /><br />1 -- Putting solar cells inside the nosecap of Dragon for trickle power while docked is right out. Assuming the simulation was accurate (I would expect this to be the case), while docked, the open end of the nosecap will be facing Earth. Ergo, no sun -- no solar power.<br /><br />2 -- Offsetting the above -- since Dragon will be docking at Node 2, and N2 *is* the connecting passageway for the three laboratories -- my preferred option of a power feed from the Destiny Laboratory is looking even better. Dragon is <b>right there</b>, so this would seem to be the optimum solution (to me).<br /><br />3 -- The simulation demonstrates the existence of another piece of electronics. One of the views in the simulation is from the 'Dragon Boresight Camera'. The SSTL camera in the previous post would likely serve quite well for this. <br /><br />4 -- There are docking lights for Dragon in the simulation that I should probably add to the equipment list. I can't imagine them being a serious power issue, but there are green, red, and strobing lights to provide navigation/visibility aids to the ISS crew during the berthing process. It appears that there are two each of green and red (starboard and port respectively one assumes) -- one set visible when the nosecap is closed, with both sets visible when it is open. The strobe is only visible when the nosecap is open and appears to be centered

 

[mrmorris]

I thought I'd make a quickie post about SpaceX's partners in the COTS contract and what they might be providing to the end product.<br /><br />Paragon Space Development<br />Paragon will be providing SpaceX with their ECLSS. Elon stated even before the COTS winners were announced that Dragon had 'on their factory floor' a 30-man-day life support system.<br /><br /><br />Odyssey Space Research<br />Odyssey's role will include support of the Dragon vehicle guidance, navigation and control (GN&C) development, selected simulation and test-bed development, related analyses, systems engineering and operations. Looks like no hardware from Odyssey, however. They're about research, simulations, and models. I assume they are the ones that made the ISS docking simulation. From their 'Expertise' page:<br /><br /><i>"Odyssey provides engineering research and analysis services in the core domain of Guidance, Navigation & Control (GN&C) design, analysis, integration, evaluation and test. We specialize in rendezvous, proximity operations and capture (including automated rendezvous and docking) and other in-space flight phases. We have expertise in crewed and un-crewed spacecraft, encompassing automated and manual flight design with emphasis on safety and mission success. <br />We perform spacecraft systems engineering functions from concept development, trade studies, and feasibility assessments to requirements development and analysis, and system/sub-system integration, evaluation and test. We build, use and deliver high-fidelity simulations and mathematical models of spacecraft systems as well as flight software. The team has experience working both nationally and internationally."</i><br /><br /><br />ARES Corporation<br />Based on the following, I assume ARES is tasked with ris

 

[mrmorris]

The thread earlier talked about this being a design for Dragon v1.0. It occurred to me recently that while I tend to think of the Dragon as a crew capsule that also happens to have a cargo configuration -- the NASA contract is for ISS cargo re-supply that 'might' be extended to crew rotation. Dragon v1.0 then is going to be the cargo version rather than the crew version.<br /><br />This immediately changes some of my sideways-engineering timeframe and raises a significant question. Work on the LES obviously drops to the end of the queue -- the cargo version doesn't need it. ECLSS likewise drops down the list. As to the question -- I have to wonder what degree of commonality there will be between the Dragon-Crew and the Dragon-Cargo? Will the two be completely interchangeable? Simply remove the cargo racks and throw in seats to switch from cargo to crew? This would obviously offer the most flexibility. However, it would certainly reduce economy. The cargo version would not require ECLSS, the battery requirements would be much lower, and the controls & displays are superfluous. Making two distinct capsules would allow for fine-tuning each to have the maximum payload to orbit. Of course, this might only be a significant issue if NASA is going to pay for cargo delivery on a per-pound basis.<br /><br />I'm going to assume that SpaceX will have two distinct capsule variants -- optimizing the cargo version for maximum payload to orbit. Their whole philosophy revolves around efficiency, so I can't see them intentionally taking a hit when it's not required. Looking at the RussianSpaceWeb site, the cargo stats on Progress are:<br /><br />Progress M1 payload capacity:<br /><br />Total payload limit: 2,230-3,200 kg <br />Maximum pressurized (dry) cargo: 1,800 kg <br />Maximum water: 300 kg in cargo module <br />Maximum oxygen: 40 kg <br />Amount of trash disposal in cargo module: 1,000 - 1,600 kg <br />Cargo volume: 6.6 cubic meters <br /><br />Progress also supplied exce

 

[bpfeifer]

"Progress also supplied excess propellant to the ISS, but I doubt this will be a Dragon capability -- at least initially."<br /><br />That's a pretty safe bet. I don't think NASA is currently interested in sending fuel up to the ISS. I don't think the Shuttle transfers fuel does it? I thought they've used the Shuttles engines to boost the ISS. On the Russian side, the Progress can transfer fuel, but that's directly connected to Russian modules. They've also used Progress engines to reboost.<br /><br />If anything, they may look for the eventual capability of the Dragon-Cargo to perform reboosts, rather than transfer fuel. <div class="Discussion_UserSignature"> Brian J. Pfeifer http://sabletower.wordpress.com<br /> The Dogsoldier Codex http://www.lulu.com/sabletower<br /> </div>

 

[mrmorris]

<font color="yellow">"That's a pretty safe bet..."</font><br /><br />Yeah -- I don't really want to get sidetracked on fuel transfer. I mentioned it mainly for completeness and so that Progress buffs wouldn't chime in saying that I forgot the fuel-transfer mass. Dragon will be docking (berthing) in a <b>completely</b> different location than Progress. This will likely preclude fuel-transfer operations *and* Dragon-> ISS reboost operations even if NASA were inclined to use it for either possibillity. The SpaceX simulation has the Dragon CBM pointing 'down' to Earth, so firing thrusters would act as a '<b>de</b>boost'.

 

[mrmorris]

I wanted to try to get a better feel for the equipment the Dragon might utilize. To start with, I simply swapped out my essentially 'random' equipment pieces that I Googled up for G-X3 spec estimates and replaced them with SSTL models as per the above post. However, I've also added new electrical draws that I've found (or estimate) that Dragon will require. A more complete list will help me to generate a power profile for launch and descent to size the battery bank more closely to requirements.<br /><br />For the G-X3 avionics, I simply used the Honeywell E-SIGI, as it included onboard GPS, Ring-Laser Gyros, Accelerometers & processor/memory. This allowed me to cover most of the avionics needs in a single package. From the reading I've done on SpaceX, they're developing avionics capability in-house. It's extremely improbable that they'll be building everything from scratch -- but rather will be likely to purchase individual components for INS, accelerometers, and processing capability. I'm going to pull a gyro unit from the Net -- I doubt it'll be the one they're using, but it should give me a starting point for the power profile. The VG700CB-200 available from Crossbow Technology Inc. is a reasonable choice, with a FOG-based inertial navigation system and MEMS accelerometers. They have several all-MEMS INS options, but I've read that MEMS gyros have high error rates. FOG technology, by contrast, is supposed to be even less susceptible to error than ring-laser gyros.<br /><br />The computer for Dragon is a big question mark. One article I found on the subject indicated: <i>"In avionics, rather than using an aerospace computer on the rocket, which could cost as much as $1 million, Falcon I will fly with the same kind of computer used in an automatic teller machine for a cost of $5,000. And rather than relying on the costly electronics that NASA and others are wedded to, F</i>

 

[scottb50]

You should have Diebolt do the programming. That way it would be simple to make changes on the fly. <div class="Discussion_UserSignature"> </div>

 

[mrmorris]

I just found this link on another blog. An interesting concept from LM for a capsule to launch tourists from an Atlas V. In particular, their LES is shade of what has been discussed for G-X3 and Dragon -- namely <b>beneath</b> the capsule and doubles as their OMS. The PDF is dated from May of this year... I would assume this is part of what Bigelow has been discussing with them. <img src="/images/icons/smile.gif" /><br /><br />I'l analyze this in a later post -- just wanted to make sure I had the URL handy. I have to wonder exactly how that OMS/LES generates enough thrust for an abort. From the artists' concept, I have to call it unlikely.

 

[barrykirk]

These processors are NOT rad hardened.<br /><br />How much will that affect things. I know that their is triple redundancy so that helps, but if a processor take a rad hit does it have the ability to recover and come back on line or is the damage permenant?<br /><br />I don't know what the expected failure rate for non rad hardened processors would be.<br /><br />Now the Dragon capsule is only scheduled initially for LEO where the rad environment is relativly beniegn.<br /><br />But in the future it would suck having to completely redesign the electronics to handle passing through the Van Allen Belts.

 

[mrmorris]

<font color="yellow">"These processors are NOT rad hardened... How much will that affect things."</font><br /><br />I didn't choose them, and as I indicated -- my source is a magazine article that might be incorrect or obsolete. As to how much effect we're talking about -- I really don't think that for the Dragon missions it matters much. The Dragon will only be <b>operating</b> in a space environment for a matter of hours on each trip. While berthed -- the avionics will be shut down and rad-hardening becomes a moot point.<br /><br /><font color="yellow">"But in the future it would suck having to completely redesign the electronics..."</font><br /><br />I'd say that argument is putting the cart before the horse -- except that it's more like bypassing the carts entirely and moving on to a Lambroghini. If the Dragon LEO craft is so incredibly successful that it needs to be redesigned for excursions beyond the Van Allen Belt, then it's a roaring success. Not only that, but the avionics are the <b>least</b> of the redesigns that would be required for such. Any such design would essentially be a brand-new spacecraft.

 

[mrmorris]

<br />Working up some quickie estimates on the Lockmart capsule based on the photos in the PDF and stats on the Atlas V 401, we get the following comparisons between it and the Dragon:<br /><br /><font color="orange">Dragon</font><br />Booster: Falcon 9 -- 9300kg to LEO <br />Crew Size: 7 <br />Length: ~4.25 m (based on proportion from SpaceX images) <br />Diameter: ~3.6 m (diameter of Falcon 9) <br />Total Volume: ~17.2 m3 (Top of heat shield to base of cap) <br /><br /><font color="orange">LM Capsule</font><br />Booster: Atlas V-401 -- 12500kg to LEO <br />Crew Size: 8 <br />Length: ~3 m (based on proportion from LM images) <br />Diameter: ~4.5 m (based on proportion from LM images) <br />Total Volume: ~30 m3 (<b>very</b> approximate) <br /><br />Given the larger width and shorter length of the LM Capsule, I'd assume that the crew seats will all be in a single bank rather then a bank of four then a second of three behind as the Dragon has. The disposable OMS/LES is obviously a replacement for the propulsive capabilities of the service module that would be present is this were the Orion capsule. The capsule will still require an internal RCS, of course. Even granting that the LM capsule is larger than the Dragon -- it would seem that the 401 is overpowered for getting it to orbit.<br /><br />I also still say it seems unlikely that an OMS/LES anything like the puny thing pictured could provide sufficient thrust to accelerate a 10,000+ kg capsule at the 10+ G's needed for an abort.

 

[mrmorris]

No one has supplied any power draws I'm missing so far. What I have still seems ridiculously low, but I'm going to run with it and do a power profile. I've used the ascent and descent profiles from the Apollo MODAP document -- somewhat modified where I think appropriate dur to tech upgrades. The phases and durations for the ascent and descent are:<br /><br />Ascent:<br /><br />Launch -- 15 minutes (T-5m to T+10m)<br />Orbit & Attitude Adjustment -- up to 6 hours<br />Hohman Transfer -- 45 minutes<br />Rendezvous & Docking -- 1 hour<br /><br />Descent:<br /><br />Departure -- 15 minutes<br />System Checkout -- 30 minutes<br />Orbit & Attitude Adjustment: 1 hour<br />De-Orbit -- 1 hour<br />Re-orientation -- 15 minutes<br />Re-Entry Control -- 15 minutes<br /><br />I've taken these and mapped in a table against the electrical draws I've already supplied. Table shown below (sorry about the vast blank space -- if there's a way to neatly display tables in here without it -- I haven't found it). If anything -- this makes the total power requirements seem even *more* ludicrously low. Nevertheless -- to date I don't see what is being left out, if anything.<br /><br /><br /><table border=""><br /><tr valign="bottom"><br /><td><b></b>

 

[mrmorris]

The low figure for Dragon power usage continues to bug me, so I decided to do a comparison with the MODAP power profile. The ascent power profile for the Apollo MODAP was 25.62 kWHr on ascent and 14.6 kWHrs used on descent. This then compares to my calculations of 1.06 and .48 kWHrs respectively for Dragon. That equates to 4% of the MODAPs ascent power usage and 3.3% of the descent usage, or an average of 3.8%.<br /><br />Frankly -- this makes me happier with the figures in the previous post. The power requirements for modern equivalents of the equipment used in the Apollo CM were almost invariably over an order of magnitude lower. In addition, I've reduced the times for Dragon ascent/decent from the MODAP profile a bit because of improved equipment specs, lower 'warm-up' periods, and faster/more automated vehicle health/checkout processes. The power profile therefore <b>should be</b> more than an order of magnitude less than that of the Apollo MODAP. My figures may still be low, but they shouldn't be hugely low.