Need help getting to orbit with OMS burns

[Urwumpe]

Basing on what wiki says, isn't it 2/r and not 1/r?

No, it is 1/Apr and 1/Sma... because i already subtracted apogee velocity by the Vis Viva equation from the circular orbit velocity.

 

[Goth]

Are my values wrong then?
SMa: 6'567
ApR: 6'685
μ: 398600,4418

(1/SMa)-(1/ApR) = 0.000002687... so you can multiply it for what you want but it's too small to get a decent result.

 

[Urwumpe]

I get a 1 km/s velocity change with your numbers. And 6449 km is your perigee radius, so you are effectively doing a 250 km change in perigee radius.

 

[DaveS]

Checked in updated STS-107 files which should have the orbiter on a nominal Direct Insertion (no-OMS-1) trajectory following MECO.

 

[Goth]

Wait, I thought 1 was a bad result instead it's correct because it's in Km! :facepalm:

 

[Urwumpe]

How hard would it be implementing the I-loaded maneuver data for the maneuver display, so we could have OMS-1 and OMS-2 already initialized with targeting data to load and use?

 

[DaveS]

How hard would it be implementing the I-loaded maneuver data for the maneuver display, so we could have OMS-1 and OMS-2 already initialized with targeting data to load and use?

I guess it wouldn't be too hard. I guess adding the proper lines to the mission file code should suffice.

 

[Urwumpe]

I guess it wouldn't be too hard. I guess adding the proper lines to the mission file code should suffice.

I think MECOCalc does already deliver the needed data, it only needs to be implemented in the mission file then. (Or in the Mission Editor I wanted to make, but I am not sure when I can really start there. )

 

[DaveS]

I think MECOCalc does already deliver the needed data, it only needs to be implemented in the mission file then. (Or in the Mission Editor I wanted to make, but I am not sure when I can really start there. )

Yes, MECOCalc already calculates the TIG and dV targets for both OMS-1 and OMS-2.

 

[SiameseCat]

How hard would it be implementing the I-loaded maneuver data for the maneuver display, so we could have OMS-1 and OMS-2 already initialized with targeting data to load and use?

It should be pretty easy; like DaveS said, we just need to add lines to the mission file.

I also think we should rewrite the mission files to use JSON (we've been discussing this on and off, but nothing has ever been coded). The mission files are going to become increasingly complex, and this would make maintaining both the mission files and the associated code easier (IMHO). If we are going to do this, it'll be easier to do this now rather than later, when the mission files are more complex and more widely used.

I think we also need to start working on some sort of MCC which can perform burn planning/targeting. I-loading OMS-1/2 targets doesn't really help with other burns, which still have to be calculated by hand.

 

[Goth]

I did it, I'm in a stable orbit with 0.0070 eccentricity.
I got +315,5 as deltaVX.
I don't know how to get the correct TIG tough, so I just did some attempts.
How should I calculate the TIG?
Can I use that MECOCalc even if I'm already post-launch?

 

[Urwumpe]

I agree, we should either use JSON or XML there. Both is no problem in any language, especially in Java, which I want to use for the Editor.

My early idea was to leave the cfg-style mission file, but use it to refer to additional files in XML or JSON, so we can reuse common files and simply refer to them in our "mission file system".

---------- Post added at 06:16 PM ---------- Previous post was at 06:14 PM ----------

Can I use that MECOCalc even if I'm already post-launch?

Yes, but it does then not include your current state vector. Generally, you accept some minor differences there and only get corrections or apply corrections from checklist, if the differences are huge.

 

[Goth]

So how do I calculate it manually?

 

[SiameseCat]

I agree, we should either use JSON or XML there. Both is no problem in any language, especially in Java, which I want to use for the Editor.

My early idea was to leave the cfg-style mission file, but use it to refer to additional files in XML or JSON, so we can reuse common files and simply refer to them in our "mission file system".

I'd much rather use JSON instead of XML - XML is a pain to edit by hand.

I think referring to other files might just result in a big mess very quickly. Most of the parameters are mission specific in any case. I think the only possible exception to this might be to define the shuttle configuration (i.e. orbiter, ODS, RMS, etc.)

 

[Urwumpe]

I'd much rather use JSON instead of XML - XML is a pain to edit by hand.

I think referring to other files might just result in a big mess very quickly. Most of the parameters are mission specific in any case. I think the only possible exception to this might be to define the shuttle configuration (i.e. orbiter, ODS, RMS, etc.)

The ascent trajectory parameters are also pretty generic for many missions (eg for ISS missions), and could be defined externally. or the available landing sites, abort sites, etc.

so, we can agree on JSON? Then I will write it into a .odt about the architecture for the Mission editor and Mission File API.

BTW: Some "insider" knowledge from my company here:

http://arc42.de/

It is in German and a very useful introduction and help for software architects, it is written by coworkers of mine.

 

[DaveS]

Checked in updated STS-107 files which should have the orbiter on a nominal Direct Insertion (no-OMS-1) trajectory following MECO.

Turns out I missed checking in the updated scenarios, sorry about that :facepalm:! They have been checked in now and I have done a test run and have no issues, ascent is fine and good.

 

[Ghostly]

What would be a nice setup for the x-y-z for a 250km orbit?

 

[SiameseCat]

It depends on your initial orbit. The values entered in MM202 (the OMS MNVR display) are the changes in velocity, so you have to figure out the velocity required after the burn and subtract the velocity at TIG (Time of Ignition). (It's actually a bit more complicated, since the burn doesn't occur instantaneously, but this should be a good enough approximation).

 

[Urwumpe]

What would be a nice setup for the x-y-z for a 250km orbit?

Once my new Notebook is delivered, I will resume work on the mission editor/planner for SSU. This should replace the old and flawed MECOTool. Had written already some software architecture docs while my PC was already going the way of the Dodo, should be a fluid restart there.

(It is marked as shipped since Monday, I hope it will be delivered soon)

 

[Urwumpe]

"Orbital insertion burns and deorbit burns each typically require a velocity change of about 100–500 ft/sec
The velocity change required for orbital adjustment is approximately 2 ft/sec (0.61 m/s) for each nautical mile of altitude change"
thought this might help

Thank you, we do know the rules of thumb from the Shuttle Crew Operations Manual, which is one primary reference for SSU. No need for a necroposting there.

Also the problem is not finding an approximate solution to the problem, but a rather exact one.