SSU Development Thread (2.0 to 3.0)

[GLS]

Does it also take the DV in account for the calculation of the MECO target velocity?

Yes, that's the whole point of it, to take into account the SSME tailoff thrust.

AFAIR, the time delay for the thrust to cease is included in the guidance as ILOAD.

That would be the Time to Zero Thrust, and AFAIK it's not related to this.

 

[Urwumpe]

Yes, that's the whole point of it, to take into account the SSME tailoff thrust.

That would be the Time to Zero Thrust, and AFAIK it's not related to this.

AFAIR, we had significant systematic errors in our MECO velocity by MECOTool. That is why I am asking. We also have strong differences on the OMS burns, which could also suggest a systematic problem with the guidance.

 

[GLS]

BTW Urwumpe, when making the release package, please update the readme file with the correct revision number (no need to commit), just so that has the correct number.

---------- Post added at 09:37 PM ---------- Previous post was at 09:26 PM ----------

AFAIR, we had significant systematic errors in our MECO velocity by MECOTool. That is why I am asking. We also have strong differences on the OMS burns, which could also suggest a systematic problem with the guidance.

I think the errors at MECO are caused by the c.g. moving, and as it moves, the engines can't immediately keep the vehicle rates down AND the thrust vector pointed in the right direction. That is probably caused by the lag in SSME TVC motion and the steps that the c.g. movement does, and their increasing size as the ET gets lighter.
Also, the fact that we only use "half" of the guidance algorithm, as we don't change to a constant acceleration mode at 3Gs, probably doesn't help matters in the last 60-50s before MECO.
I checked the math on MECOTool sometime ago and it all seems OK.
The OMS problems are most likely not related.

 

[Urwumpe]

I think the errors at MECO are caused by the c.g. moving, and as it moves, the engines can't immediately keep the vehicle rates down AND the thrust vector pointed in the right direction. That is probably caused by the lag in SSME TVC motion and the steps that the c.g. movement does, and their increasing size as the ET gets lighter.

I have doubts there - since the spacecraft does not wildly oscillate or the engines vibrate, any control losses should be minimal. At least not higher than for the big one.

My pet theory is something like taking the below (not accounting different thrust stages), adding something from the other end (the beginning of closed loop guidance is rather rough), and a wrong acceleration measurement routine in general, which also annoys the OMS burns.

Also, the fact that we only use "half" of the guidance algorithm, as we don't change to a constant acceleration mode at 3Gs, probably doesn't help matters in the last 60-50s before MECO.

Yes, but then, we do throttle down properly - also I think the errors in burn time are not the problem there.

 

[GLS]

I have doubts there - since the spacecraft does not wildly oscillate or the engines vibrate, any control losses should be minimal. At least not higher than for the big one.

My pet theory is something like taking the below (not accounting different thrust stages), adding something from the other end (the beginning of closed loop guidance is rather rough), and a wrong acceleration measurement routine in general, which also annoys the OMS burns.

There are some oscilations in pitch in the final seconds prior to fine count, just look at the ADI for the pitch "error" and rate. I think that's why we can't get the correct FPA, which in turn doesn't lead to the desired apogee.

Yes, but then, we do throttle down properly - also I think the errors in burn time are not the problem there.

Yes, we do throttle down, but the algorithm isn't expecting that, so it has to make a correction, then we throttle down somemore, and it corrects again, and as we get closer to the target, these corrections need to be greater. This on top of the c.g. steps.... doesn't help. I doubt the reason for inventing a constant acceleration version of the algorithm is just to get a correct burn time.

---------- Post added at 11:51 AM ---------- Previous post was at 11:50 AM ----------

About the release, we got the day correct, now what is the correct time?

 

[dseagrav]

It's LVDC++ IGM Reloaded! (AKA "Oh for f--k's sake, what the h--l is it doing now?")

Here there be dragons, abandon all hope ye who etc etc etc. Add your next-of-kin to your forums profiles so we can notify them when you stop posting.

(Never stop posting)

 

[Urwumpe]

About the release, we got the day correct, now what is the correct time?

Hakuna Matata

 

[asdad]

Urwumpe : please help me get to orbit because ITEM 27 is not reset for OMS2 Burn ok ?

 

[Urwumpe]

Urwumpe : please help me get to orbit because ITEM 27 is not reset for OMS2 Burn ok ?

What do you mean with ITEM 27 and reset?

 

[GLS]

Urwumpe : please help me get to orbit because ITEM 27 is not reset for OMS2 Burn ok ?

Simplyfied procidure for an OMS burn:
1) enter the time you want the burn to occurr (ITEM 10)
2) enter the delta V (ITEM 19, 20, 21)
3) enter ITEM 22 to load that info (check the target apogee and perigee in the box on the top right side, if you don't like the result go back to point 2)
4) enter ITEM 23 to start the timer (top right corner)
5) enable OMS engines by placing the OMS ENG switches in "ARM" or "ARM/PRESS"
6) enter ITEM 27 to maneuver to the burn attitude (DAP must be in AUTO, also this will take some time so you have to plan you burn well ahead)
7) when the timer gets to 15 seconds an "EXEC" message will start to flash, that means you must press EXEC to enable the burn
8) sit back and watch it happen

---------- Post added at 01:24 PM ---------- Previous post was at 01:17 PM ----------

BTW: we should make a tag of the current version for posterity.

 

[Urwumpe]

Who uploads it to Orbit-hangar?

 

[GLS]

Who uploads it to Orbit-hangar?

v2.0 had an external link ([ame="http://orbithangar.com/searchid.php?ID=6389"]http://orbithangar.com/searchid.php?ID=6389[/ame]), so we could keep the same system. We just need to remove the old one.

 

[Donamy]

I have goose bumps !!!

 

[Urwumpe]

Closed the thread for a new start towards 4.0.

If you have support questions for the released 3.0 version, open a new thread for your problem.