SSU Development Thread (2.0 to 3.0)

[DaveS]

But to do that the MECO targets would not match the historical data...

The MECO data was a best guess based on the OMS-2 data. So the MECO data is most likely off.

Question about the OMS/RCS mass change in r2090: where did those numbers come from? I'm asking because 38% OMS load seems WAY too little, it should be 70% at least for an ISS mission plus with the OMS assist (for STS-114 OMS load was 95.7%).

I got that from an internal NASA JSC post-flight report on STS-114. According to it OMS loaded total was 11224.434 kg. So I simply forgot to double the number (I only looked at the data for the LOMS pod, forgot to add in the prop loaded into the ROMS pod).

It also states that the preflight load for RCS was 1991.2068 kg for oxidizer and 1245.4329 kg for a total of 3236.6397 kg.

 

[GLS]

The MECO data was a best guess based on the OMS-2 data. So the MECO data is most likely off.

Another thing that probably isn't helping in the OMS-2 burn is that we don't know if that is as fully posigrade burn. We have the dV but we don't know in which direction that went.

I got that from an internal NASA JSC post-flight report on STS-114. According to it OMS loaded total was 11224.434 kg. So I simply forgot to double the number (I only looked at the data for the LOMS pod, forgot to add in the prop loaded into the ROMS pod).

It also states that the preflight load for RCS was 1991.2068 kg for oxidizer and 1245.4329 kg for a total of 3236.6397 kg.

I got my OMS % from the ascent checklist. Please save all that info because we are going to need it in the OMS/RCS update.

 

[DaveS]

Another thing that probably isn't helping in the OMS-2 burn is that we don't know if that is as fully posigrade burn. We have the dV but we don't know in which direction that went.

According this: http://web.archive.org/web/20050727...tions/Post/JavaSSOP/orbit/SHUTTLE/SVPOST.html the OMS-2 burn was fully posigrade.

 

[Urwumpe]

According this: http://web.archive.org/web/20050727...tions/Post/JavaSSOP/orbit/SHUTTLE/SVPOST.html the OMS-2 burn was fully posigrade.

By definition, the OMS-2 burn is ALWAYS fully posigrade, unless you load an abort target. The OMS-2 burn happens always on apogee.

 

[GLS]

According this: http://web.archive.org/web/20050727...tions/Post/JavaSSOP/orbit/SHUTTLE/SVPOST.html the OMS-2 burn was fully posigrade.

HOLY COW! I had totally forgotten about that website. That has the "post MPS dump / pre OMS-2" orbit data (and all the others). Thanks! I'll look at that, and also add the dump and translation dVs to the MECOTool when I have time (probably not soon ).

 

[Urwumpe]

HOLY COW! I had totally forgotten about that website. That has the "post MPS dump / pre OMS-2" orbit data (and all the others). Thanks! I'll look at that, and also add the dump and translation dVs to the MECOTool when I have time (probably not soon ).

Would it help you if I make a XAML/C# version of MECOTool for the beginning? I could do that after the Centaur stuff... I just know since yesterday that the next, at least 80% free weekend is in two weeks... otherwise its already stuffed with university and car stuff.

 

[GLS]

Would it help you if I make a XAML/C# version of MECOTool for the beginning? I could do that after the Centaur stuff... I just know since yesterday that the next, at least 80% free weekend is in two weeks... otherwise its already stuffed with university and car stuff.

If it's something that in the future could be included in (or already part of) the Mission Editor, than yes that would be a step forward.

 

[Urwumpe]

If it's something that in the future could be included in (or already part of) the Mission Editor, than yes that would be a step forward.

Not sure if I would include this later, really... I would just make a straight-forward version of the old MFC stuff, so that the historic ballast is finally gone and everybody with a express version of visual studio can join in.

IF I would engineer the software properly and have some MVVM style architecture behind, yes, we should be able to easily include it later, especially if SOLID is followed.

 

[GLS]

Not sure if I would include this later, really... I would just make a straight-forward version of the old MFC stuff, so that the historic ballast is finally gone and everybody with a express version of visual studio can join in.

IF I would engineer the software properly and have some MVVM style architecture behind, yes, we should be able to easily include it later, especially if SOLID is followed.

Is it worth to make "a straight-forward version" of it? It would be work just for this release... we are still using the next version for the Mission Editor and configuration development, right?

 

[Urwumpe]

Is it worth to make "a straight-forward version" of it? It would be work just for this release... we are still using the next version for the Mission Editor and configuration development, right?

Yeah, I think that the pain is there to have a proper tool to make this all easier.

But then, why I am not sure if it is a good idea to plan for using it:

It is right now a very specialized tool with very specialized requirements. A mission editor would have different requirements, which include the requirements of MECOTool. It might be tempting to do it all right now, but as I see it, it is also a development delay.

As little as MECOTool really does: Is it really a problem to redo it then from ground up? After all, all it does are three small calculations right now.

Which would mean, if aiming at proper reuse later: Three classes should implement the calculations, one model class is needed for describing the intermediate orbits, one model class describes MECO parameters, another model class the OMS PEG7 targets.

Add an yet unknown number of view model classes for binding the model data to the view.

And now the classic problem: Do we want to spent the needed effort now before release? Or later after release?

Considering the many open questions in my analysis, I feel like I want to do this later, but feel free to convince me of the alternative.

Also as another factor there: Starting after release would make it easier to instantly push towards a continuous delivery development process for the mission editor, so that it should always be possible to include a version of the mission editor as soon as the Orbiter add-on is ready for release. But that's no show stopper for doing this before release, since we could at least find the time for doing the commit stage properly already.

 

[DaveS]

But to do that the MECO targets would not match the historical data...


Question about the OMS/RCS mass change in r2090: where did those numbers come from? I'm asking because 38% OMS load seems WAY too little, it should be 70% at least for an ISS mission plus with the OMS assist (for STS-114 OMS load was 95.7%).
A word of caution: currently the OMS shares the same propellant resource as both ARCS. The way I updated those masses a while back was I calculated the OMS mass and then added a full ARCS load mass (standard, right?), and then calculated the % of the OMS prop resource. Yes, it's a major simplification/limitation to have a shared resource, but I vote to keep things as they are for this release. Fixing it now would probably break every scenario, and we will have to do that for the OMS/RCS update after this release, so this is something I can live with for now.

Of the 14538.0 kg of propellant defined in ParameterValues.h for OMS, how much of is actual OMS propellant and how much is ARCS propellant?

---------- Post added at 06:23 PM ---------- Previous post was at 06:20 PM ----------

Yeah, I think that the pain is there to have a proper tool to make this all easier.

But then, why I am not sure if it is a good idea to plan for using it:

It is right now a very specialized tool with very specialized requirements. A mission editor would have different requirements, which include the requirements of MECOTool. It might be tempting to do it all right now, but as I see it, it is also a development delay.

As little as MECOTool really does: Is it really a problem to redo it then from ground up? After all, all it does are three small calculations right now.

Which would mean, if aiming at proper reuse later: Three classes should implement the calculations, one model class is needed for describing the intermediate orbits, one model class describes MECO parameters, another model class the OMS PEG7 targets.

Add an yet unknown number of view model classes for binding the model data to the view.

And now the classic problem: Do we want to spent the needed effort now before release? Or later after release?

Considering the many open questions in my analysis, I feel like I want to do this later, but feel free to convince me of the alternative.

Also as another factor there: Starting after release would make it easier to instantly push towards a continuous delivery development process for the mission editor, so that it should always be possible to include a version of the mission editor as soon as the Orbiter add-on is ready for release. But that's no show stopper for doing this before release, since we could at least find the time for doing the commit stage properly already.

I'm no coder but I think that having at least a working ascent profile generator, would be nice to have. As it is for me at least, finding a proper profile that matches up with the historic data is currently a trial&error process.

 

[GLS]

I'm not sure but I think each RCS pod has the same prop mass, so that number is: OMS + (2 * RCS).

On the MECOTool, my concern was we spending (our precious) time re-writing something, that in 3 months or so goes out the window. If it was possible to do it as a "get ahead" for the MissionEditor, then it would be better.

 

[DaveS]

I'm not sure but I think each RCS pod has the same prop mass, so that number is: OMS + (2 * RCS).

Do you have a total number on total OMS propellant capability?

 

[GLS]

Do you have a total number on total OMS propellant capability?

Not really, but judging from the OMS loads I have its probably within 100lbs of (for 2 pods) 24936lbs (11310.78Kg).

 

[DaveS]

Revised launch scenarios for STS-107 and STS-114 have now been checked in. The loads should now be accurate.

---------- Post added at 08:25 PM ---------- Previous post was at 07:39 PM ----------

Revised launch scenarios for STS-107 and STS-114 have now been checked in. The loads should now be accurate.

The launch scenarios for STS-1, STS-120 and STS-126 now also sports accurate propellant loads for OMS/ARCS/FRCS.

 

[Urwumpe]

DaveS: About the textures in the Centaur branch, had these been modified for the T-0 umbilicals?

I just work on updating the Centaur branch with the latest changes from the trunk and have to check which modifications in Centaur are meant to persist.

 

[DaveS]

DaveS: About the textures in the Centaur branch, had these been modified for the T-0 umbilicals?

I just work on updating the Centaur branch with the latest changes from the trunk and have to check which modifications in Centaur are meant to persist.

If you are talking about the T0 umbilicals on the orbiter, then there's nothing to keep. All the relevant mods are in the mission kit mesh file.

 

[Urwumpe]

If you are talking about the T0 umbilicals on the orbiter, then there's nothing to keep. All the relevant mods are in the mission kit mesh file.

OK, so I can overwrite everything conflicted with the latest versions from the trunk?

 

[DaveS]

OK, so I can overwrite everything conflicted with the latest versions from the trunk?

Yes, everything but the Centaur scenarios as I think the ones in the branch has more accurate data than the ones in the trunk.

 

[Urwumpe]

Yes, everything but the Centaur scenarios as I think the ones in the branch has more accurate data than the ones in the trunk.

OK, will be done When this is done, I can take the notebook with me for some extra coding hours during the saturday.

---------- Post added at 10:52 PM ---------- Previous post was at 09:49 PM ----------

OK, STS-61G seems to work, just the Ku-band antenna is still not deployed... will commit the merged version now.

---------- Post added at 10:58 PM ---------- Previous post was at 10:52 PM ----------

For the centaur Branch: Do we have a Galileo mesh that we can use in SSU as proper stand-in? The Carina looks a bit misplaced.