SSU Orbit Ops - X,Y and Z DV's

[SiameseCat]

From what I can decypher, the different Maneuver displays use different I-loaded data initially and the settings of the previous mode are overridden in the moment you have a major mode transition (for example 104 -> 105).

You have to confirm the data by selecting ITEM 22/LOAD except for MM104, where LOAD is selected automatically. After the transition from MM104 to other modes, LOAD will flash as request to confirm the changed data. LOAD will also flash if a maneuver is up-linked from the ground or you do keyboard entries on the data after it was loaded.

The * next to MNVR will only appear if the error difference between current attitude and desired attitude is bigger than 8°, but the automatic maneuver will still be executed if the DAP is set to AUTO.

Also, you can only load the abort targets (ABORT TGT) in MM104 or MM105. Allowed entries there are 0 (No abort target), 1, 3, 4 and 5 in MM104 and 0 - 12 for MM105.

I suspect the abort targets are also I-Loads and stored in the OPS1 tapes.

Since we don't have I-Loads yet, what's the best way of handling the transitions? I'm leaning towards resetting everything to 0, but we could also use 'standard' initial values.

Donamy: I believe the WT entry is considered an input to the GPC, and does not change automatically after the maneuver if loaded.

 

[Urwumpe]

Since we don't have I-Loads yet, what's the best way of handling the transitions? I'm leaning towards resetting everything to 0, but we could also use 'standard' initial values.

What about just adding the I-Loads?

It did not take me much time calculating the burn targets for the 600 km test mission on a sheet of paper, we should be able to do this math before launch in SSU.

We just aim for a circular orbit with the right altitude, and as know the MECO targets, the default burn strategy can be found (one or two OMS burns).

Would be more realistic and we avoid having to look up the data if nothing went wrong.

 

[Donamy]

We'll need to add it to the checklist.

 

[SiameseCat]

What orbit would you want to calculate it for? Just take the apogee at MECO and circularize at that altitude, or do something more complicated? Another option would be to allow a secnario entry specifying the target orbit after the OMS burns. Also, are we going to take non-spherical gravity into account here?

 

[Urwumpe]

We'll need to add it to the checklist.

Like that?

At MECO:

1. Open Orbit MFD, pause and note:
   1. Time to Apogee in seconds (ApT)
   2. Apoapsis radius
   3. Periapsis radius
   4. Semimajor axis
2. Calculate apoapsis velocity of Post-MECO orbit.
3. If Apoapsis radius higher than 5 km below or higher than the target orbit radius:
   1. Calculate velocity of target orbit
   2. Calculate difference and convert the result into feet per second
   3. Use this for a single OMS-2 burn at Apoapsis (No OMS-1)
4. If Apoapsis radius more than 5 km below the target orbit radius:
   1. calculate transfer ellipse: New periapsis is current apoapsis, new Apoapsis is target orbit radius.
   2. Calculate the velocity change from Post-MECO orbit to Transfer ellipse as difference between predicted apoapsis velocity and the periapsis velocity of the transfer orbit
   3. Use this DV for OMS-1
   4. Calculate velocity difference between transfer orbit apoapsis velocity and target orbit velocity
   5. Use this second DV for OMS-2

Is very simple, I don't know what speaks against forging this algorithm into C++ code.


-----Post Added-----

Another option would be to allow a secnario entry specifying the target orbit after the OMS burns. Also, are we going to take non-spherical gravity into account here?

A single line with the target orbit height would be enough and non-spherical gravity is not needed IMHO - if we need final accuracy, we can always improve the algorithm afterwards.

 

[Donamy]

They'll have to change the title from "go play in space" to "go calculate in space".

 

[Urwumpe]

They'll have to change the title from "go play in space" to "go calculate in space".

Well, give me about 800 kg of steel and 2 years of time for working with it and I can implement the required math for this into an electro-mechanical computer. :rofl:

Theoretically, it should be possible to turn the math into a porkchop plot...

 

[DaveS]

How about a simple utility like the date utility that comes with Orbiter? Could also include the ability to calculate the proper MECO velocity for any given MECO trajectory.

 

[Urwumpe]

How about a simple utility like the date utility that comes with Orbiter? Could also include the ability to calculate the proper MECO velocity for any given MECO trajectory.

Would be a bit tougher as the perfect MECO altitude requires some experimental research, but I can give it a try, was a while since I last did MFC. How would you prefer the output? Copy and paste for including the data into the scenario file?

And if possible, would you also like to have all abort trajectories covered?

 

[Donamy]

I would like to enter things into the CRT, preferably.

 

[Urwumpe]

I would like to enter things into the CRT, preferably.

Hmm... realistic would be loading the I-loaded trajectories or uplink them from the ground, with the crew only correcting the values.

 

[Donamy]

What ever you want to do is fine with me.

 

[Urwumpe]

What ever you want to do is fine with me.

I think about the task.

What about making a mission file generator? As we already plan to use such files, maybe it would make sense to write a MFC application which handles all parameters which appear inside these files.

For example, we could also move the payload bay configuration into it and visually edit it.

 

[Donamy]

Sounds interesting