SSU Development Thread (2.0 to 3.0)

[DaveS]

I discovered a UNIV PTG or stuck thruster bug in STS-1/On Orbit, there is a constant increasing yaw to the right, if you switch from VERN to PRI, the yaw increases much more rapidly. At about 32% fuel left, the thruster firing ceases, the rotation rate stays constant.

Switching to AUTO was not possible on Orbit DAP panel.

Only pressing and holding 1 on the numeric keyboard stops the thruster firing - something wrong with the usage of the thruster groups.

I can't replicate it here. Any exact steps to required to replicate the bug?

 

[Urwumpe]

I can't replicate it here. Any exact steps to required to replicate the bug?

Just starting the scenario as it currently is.

No source code differences between SVN repository and my local working copy, except the SSUWorkbench.

 

[DaveS]

Just starting the scenario as it currently is.

In that case, everything is fine for me. The RCS activity is perfectly normal only firing when the attitude hits the deadbands.

 

[Urwumpe]

In that case, everything is fine for me. The RCS activity is perfectly normal only firing when the attitude hits the deadbands.

Fixed it - had unplugged the flight stick after finishing some landing tests in SSU, but did not tell Orbiter about it, it instead selected the new first input device, which was the Warthog throttle block. Will do some second test in SSU if this really reduces to this explanation.

EDIT: Confirmed, turning flight controller power off instantly stops the rotation.

 

[SiameseCat]

I've checked in a clone of the MECOTool util to the SSUWorkbench project. This is meant to be a proof of concept for what can be done with WPF; the MECOTool is defined as a user control, with a separate class to store the data displayed in the controls. The code for the calculations is copied from the C++ MECOTool code,

 

[GLS]

I've checked in a clone of the MECOTool util to the SSUWorkbench project. This is meant to be a proof of concept for what can be done with WPF; the MECOTool is defined as a user control, with a separate class to store the data displayed in the controls. The code for the calculations is copied from the C++ MECOTool code,

As ATM I can't "play" with that, may a few changes be added to that code?
>> MU_EARTH should be a more accurate 398600439968871.19
>> RADIUS_EARTH should be 6371010 to match Orbiter's value
>> a selection of MECO altitude with the possible values: 52, 57, 59, 61 and 63NM

---------- Post added 08-24-15 at 07:53 PM ---------- Previous post was 08-23-15 at 11:39 PM ----------

So, is tomorrow the big day?

 

[Urwumpe]

So, is tomorrow the big day?

I see nothing yet that speaks against it.

About the parameters for Earth, etc. in SSUWorkbench - I'll put this into the application settings.

Also, I will make a new implementation with the new calculation features in parallel, but the classic MECOCalc function can stay for a while.

Anybody knowing how much DV is produced by the MPS shutdown?

 

[GLS]

Anybody knowing how much DV is produced by the MPS shutdown?

To adjust the MECO velocity? That has to be done "in real time" (and already is) as the number of engines running can change and also their power level, so there's no need to correct the current MECOTool math.
One thing that might be needed is to factor in the ~11fps deltaV from the MPS dump, and the 4fps +Z translation.

 

[Urwumpe]

To adjust the MECO velocity? That has to be done "in real time" (and already is) as the number of engines running can change and also their power level, so there's no need to correct the current MECOTool math.
One thing that might be needed is to factor in the ~11fps deltaV from the MPS dump, and the 4fps +Z translation.

Is it implemented like that in our case?

 

[GLS]

Is it implemented like that in our case?

Yes, it takes into account the number of engines running and the commanded power level for fine count.

 

[Urwumpe]

Yes, it takes into account the number of engines running and the commanded power level for fine count.

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

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

 

[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?