SSU V1.25 Release

[DaveS]

I believe what Donamy and SiameseCat is seeing is rotation induced by the lone offset aft BSM.

I'm currently studying launch videos to see just what is causing the pitch-up of the SRBs at SRB sep. Current thinking based on numerous observations of SRB sep during the launch of STS-114 is that the FWD BSMs are responsible.

They can be seen still firing well after the aft BSMs have stopped firing.

I'm going to lengthen FWD BSM firing with about 1 second and see how that affects the SRBs.

 

[Urwumpe]

How could not applying dynamic textures, affect the SRB performance ? Please forgive my ignorance.

The trajectory of the SRBs depends on the performance of the orbiter engine - if the frame rates are abnormally low, the SRBs could be rotating faster than they move away for example.

 

[DaveS]

I'm going to lengthen FWD BSM firing with about 1 second and see how that affects the SRBs.

OK, this plan is not going so well due to the fact, even if I tell the FWD BSMs to use a different ISP from the aft BSMs, the FWD BSM ISP change affects the aft BSMs!

Any explanation for this behaviour?

 

[Donamy]

I'm getting about 28 FPS at SRB sep. I this abnormally low ?

 

[SiameseCat]

I don't think the SRB problem is related to frame rates. I just ran the SRB separation sequence at 0.1x time acceleration, and the SRBs still hit the wings.

 

[Donamy]

So, now what ?

 

[SiameseCat]

A couple of problems I've noticed in the SRB code:

The thrust vector for thBSM[1] is different between the left and right SRBs. For the left SRB, the BSM direction is
_V(0.339, 0.9347, -0.102); for the right SRB, it is
_V(0.9347, 0.339, -0.102).

As far as I can tell, the 3rd BSM is never actually fired. The other 2 BSMs start firing, but don't seem to be shut off. The code below is the code I can see where the BSMs are turned on/off.

[SIZE=2]if(srb_dt < 1.2)[/SIZE]
[SIZE=2]{[/SIZE]
[SIZE=2]   SetThrusterLevel (thBSM[0], 1.0-srb_dt * 0.583);[/SIZE]
[SIZE=2]   SetThrusterLevel (thBSM[1], 1.0-srb_dt * 0.583);[/SIZE]
[SIZE=2]}[/SIZE]

 

[Donamy]

Could you try and see if that cures it ?

 

[DaveS]

After some detective work, I have found that the position of the aft BSMs on our SRB meshes are wrong. I'll correct this and see if it will make any difference. I'll also check the positions of the FWD BSMs and make sure those are correct.

 

[Donamy]

It's got nothing to do with the meshes, it's in the code.

 

[SiameseCat]

I've fixed the problems I mentioned above, and it seems to have fixed the collision problem. I've checked the updated file in.

 

[Donamy]

Great job SC, Smooth roll program, clean SRB sep, and the ObSS MPMs are stowed at launch. Nice !!

Just one slight problem, I can't move the RMS, after grappling the S6 in the bay. Grapple sequence is fine, just can't move the arm.

 

[SiameseCat]

The grappling problem is because there's no way of releasing the graaple payload from the payload bay (the purge button on the RMS dialog is broken). There are 2 ways to fix this: update the RMS dialog and use that, or use the actual PDRS switches. I can fix the dialog within a day or two, but it'll take more time to get the PDRS switches working.

 

[Urwumpe]

I can fix the dialog within a day or two, but it'll take more time to get the PDRS switches working.

What would you need to get the PDRS switches working? I can do some work on the payload interface in the same time.

 

[SiameseCat]

As far as the panels are concerned, the main thing I need are the PDRS talkbacks and switches on panel A6. Most of the other code is already used by the RMS system, so I just need to move it into a centralized class.

 

[DaveS]

For visuals we're going to need the retention latch panels with the V-guides. If Donamy doesn't disagree, I could modify his 124bridgerail mesh to suit our needs.

 

[Urwumpe]

For visuals we're going to need the retention latch panels with the V-guides. If Donamy doesn't disagree, I could modify his 124bridgerail mesh to suit our needs.

Well, the problem is just: What are our needs?

I am not sure yet.

I think the best solution would be adding a maximum number of PRL mesh groups into a single "PRL mesh", and hide those, which we don't use.

When the payload bay is closed, camera not inside the bay or the aft windows not in use, we can hide the payload retention mesh completely, otherwise we just hide/disable groups as needed.

 

[DaveS]

Well, that would place the limit at 11 retention latch panels, as one panel occupies one section of the payload bay's 13 sections. Sections 1 and 2 are occupied by the External Airlock which is secured to the payload bay by standard passive latches.

 

[Urwumpe]

Well, that would place the limit at 11 retention latch panels, as one panel occupies one section of the payload bay's 13 sections. Sections 1 and 2 are occupied by the External Airlock which is secured to the payload bay by standard passive latches.

Well, we currently have 3 dynamic payloads and 4 static, if I remember correctly, with maximum being 5 latches (4 sill + 1 keel) per payload.

 

[DaveS]

Well, we currently have 3 dynamic payloads and 4 static, if I remember correctly, with maximum being 5 latches (4 sill + 1 keel) per payload.

Yes, and currently the STS-125/HST SM4 manifest is at our maximum for passive payloads(SLIC, ORUC, FSS and MULE). Could need one more for the MFR.