SSU Development Thread (2.0 to 3.0)

Status
Not open for further replies.
Nearly done with the resized orbiter. Things left do before Orbiter integration begins is finalization of the new STs, repositioning of the PLBD drive linkages and texture finalizations.
 
Hi, I`m back after not posting anything a while...
Old PC worked 7,5 years (!) without issues, then some HDD and videocard problems, though not fatal, but decided get a new PC, ended up with
i5 4990 3,3 GHz Haswell refresh, 8GB RAM, video GF GTX 760 2GB with Win 7 -not extreme, but decent config these days.
And positive thing - SSU works quite succesfully! on previous PC, whatever I did SSU did not work...
I have a question - does SSU work in Orbiter BETA 2014? Because new BETA with D3D9
client looks amazing, worked well even on previous PC.
 
I have a question - does SSU work in Orbiter BETA 2014? Because new BETA with D3D9
client looks amazing, worked well even on previous PC.

Not sure if it does. Have you simply tested it? Would be interesting for finding out if we need to change something for 2014, but I think it is not top priority now... lets work on getting a release done for the Orbiter version that is available now
 
So I'm trying to finish (mostly) everything in the A/E PFD except the ADI and HSI, those will have to wait until January at least (this is the last week I'll be able to give to SSU for now :().
But I've encountered a problem when trying to do the Mach tape. I don't know what to make of the following text from SCOM
On ascent and on entry above Mach 0.9, the M/V
tape displays Mach number, relative velocity
(Vrel), or inertial velocity (Vi). Mach number is
the ratio of vehicle airspeed to the speed of
sound in the same medium. The Vrel is in feet
per second in relation to the Earth. Vi is in feet
per second and does not consider the rotational
speed of the surface. The actual parameter
displayed is always Mach number; the tape is
simply rescaled above Mach 4 to read Vrel (MM
102, 304, 305, 602 and 603 with the tape labeled
M/VR) or Vi (MM 103 and 601 with the tape
labeled M/VI). The scale ranges from 0 to 27.0K
feet per second, with a scale change at Mach 4
(4.0M).
It's just the tape that changes to feet, or is the tape and the number in the center? Anyone?
While we're on the subject: this thing is a NIGHTMARE of requirements and different versions: document A doesn't match document B, and then neither of them match the very few photos or videos. :shrug: I'm trying to do an "average" and hope I please everyone.

BTW: Wouldn't it be a good idea to create a Q&A thread so users can "interact" with us, instead of having them post in the dev threads?
 
Here's the description from the DPS dictionary, which is a bit clearer:
Alpha/Mach Indicator (AMI) – Provides NAV derived and barometric angle of attack (α) in
degrees, and velocity in Knots Equivalent Airspeed (KEAS) or Mach number. The source of the
data is determined by the AIR DATA switch (Left, Right, or NAV). Both tapes scroll up and down
within their respective windows, with the tape digital value provided in a white-on-black
background format in a box at the tape’s center. The tape displays the Mach value, and the
digital readout below the tape shows KEAS, for all major modes except MM 305 and 603. For
MM 305 and 603, the digital readout and tape values will swap at M < 0.9. The digital readout
label will also change from “KEAS” to “M”. Likewise, the label above the velocity tape changes
with major mode and RTLS flyback status. In MM 101, 102, 304, 305, 602, and 603, the label
will be “M/VR” indicating relative velocity is displayed. In MM 103 and 104, “M/VI” is displayed
indicating inertial velocity. During Powered RTLS (MM 601), prior to PPA, the label will be “M/VI”
indicating inertial velocity, and after PPA “M/VR” indicating relative velocity
So for most of entry, the tape shows Mach, and the display below the tape shows KEAS. For M < 0.9, the tape shows KEAS, and the display below the tape shows the mach number.
 
Thanks SiameseCat, but the "KEAS vs M/V" is the easy part, the problem is what to show above Mach 4, both on the tape and digital readout (the one in the middle of the tape, not the one below). This phrase
The actual parameter
displayed is always Mach number; the tape is
simply rescaled above Mach 4 to read Vrel
is the source of my doubts: is it always MACH in the readout and only the tape changes to feet at Mach 4? Does it all change to feet at Mach 4, but it's all a conversion from "measured" Mach to feet?
 
Thanks SiameseCat, but the "KEAS vs M/V" is the easy part, the problem is what to show above Mach 4, both on the tape and digital readout (the one in the middle of the tape, not the one below). This phrase is the source of my doubts: is it always MACH in the readout and only the tape changes to feet at Mach 4? Does it all change to feet at Mach 4, but it's all a conversion from "measured" Mach to feet?

You mean the mechanic tape indicator of the old cockpit there.

Think of a tape with numbers on it. Below the digit 4, it displays Mach. The next number, "5", is now placed slightly different on the same tape to display "5 Kfps" instead of Mach 5 (which is at 5500 fps)
 
You mean the mechanic tape indicator of the old cockpit there.

Think of a tape with numbers on it. Below the digit 4, it displays Mach. The next number, "5", is now placed slightly different on the same tape to display "5 Kfps" instead of Mach 5 (which is at 5500 fps)

Yes, I'm talking about the "tapes" and the digital value that shows in the middle of them.
So if we have the tape like you say (and that's my interpretation as well), what would the digital value indicate, feet or Mach? The text seems to indicate Mach, but it doesn't make much sense to me.
The actual parameter displayed is always Mach number
:shrug:

---------- Post added at 09:59 PM ---------- Previous post was at 05:29 PM ----------

Just to let you know, I've been reading an older SCOM and it seems to me that the "famous phrase" is a leftover from another display's description (like I said this has several versions), so I'm going to have the tape (and digital value) show Mach below Mach 4, and above that it's all Kft.
 
Just committed the "new" CRTMFD (mostly MDU) with the A/E PFD!
There's still lots to do, from small things like having the numbers all centered in the tapes, to large things like drawing the ADI and HSI. I'll try to finish the small things in this weekend and the rest will have to come later. If anyone has any questions like "why is this thing here when in this document is says it should be there?", please ask so I can explain the logic I followed.

---------- Post added at 10:23 PM ---------- Previous post was at 02:58 AM ----------

I knew this was going to happen some day...
I was committing a missing file, and I didn't hit the "None" label to deselect all the local changes, and so it committed all the changes. :facepalm:
I think I managed to revert everything, so my apologies for any inconvenience. To prevent future mistakes like this I found there's a (much safer) option to have unchecked files by default (see: https://stackoverflow.com/questions/14504102/tortoise-svn-commit-uncheck-by-default)

So back to business, if anyone launches from Vandenberg, with FWC SRMs, it's obvious that when they separate, they are still producing a lot of thrust and move forwards for a while. Did some research and the thrust (and chamber pressure) plot for them is pretty much the same as for the HPM/RSRM. So that leaves the empty mass as the cause, which of course is less in the FWC. The way to "fix" this would be to increase the SRB SEP PC50 timer, allowing the thrust to drop a bit more, compensating the smaller mass, so they move away from the stack.
There's 3 ways to do this: (1) adding an option in the mission file to differentiate between "FWC" and "non-FWC", (2) adding the timer length to the mission file (IMO the correct way), and (3) calling the SRB vessel and ask which version it is.
Any thoughts?
 
Just committed the "new" CRTMFD (mostly MDU) with the A/E PFD!
There's still lots to do, from small things like having the numbers all centered in the tapes, to large things like drawing the ADI and HSI. I'll try to finish the small things in this weekend and the rest will have to come later. If anyone has any questions like "why is this thing here when in this document is says it should be there?", please ask so I can explain the logic I followed.

---------- Post added at 10:23 PM ---------- Previous post was at 02:58 AM ----------

I knew this was going to happen some day...
I was committing a missing file, and I didn't hit the "None" label to deselect all the local changes, and so it committed all the changes. :facepalm:
I think I managed to revert everything, so my apologies for any inconvenience. To prevent future mistakes like this I found there's a (much safer) option to have unchecked files by default (see: https://stackoverflow.com/questions/14504102/tortoise-svn-commit-uncheck-by-default)

So back to business, if anyone launches from Vandenberg, with FWC SRMs, it's obvious that when they separate, they are still producing a lot of thrust and move forwards for a while. Did some research and the thrust (and chamber pressure) plot for them is pretty much the same as for the HPM/RSRM. So that leaves the empty mass as the cause, which of course is less in the FWC. The way to "fix" this would be to increase the SRB SEP PC50 timer, allowing the thrust to drop a bit more, compensating the smaller mass, so they move away from the stack.
There's 3 ways to do this: (1) adding an option in the mission file to differentiate between "FWC" and "non-FWC", (2) adding the timer length to the mission file (IMO the correct way), and (3) calling the SRB vessel and ask which version it is.
Any thoughts?
The best way would actually be to translate the thrust curve into actual PSI readings that the GPCs actually look at.
The SRBs are equipped with OPTs that are checked out prior to launch as these are the primary separation sequence initiator while there is a back-up timer which is set based on ground testing of the SRMs at which point the SRBs do not produce any thrust whatsoever.

Early in the program the crews reported on A/G that they had a Pc<50 text on the ASCENT TRAJ displays. This went away later in program along with the 1st stage performance call.
 
The best way would actually be to translate the thrust curve into actual PSI readings that the GPCs actually look at.

Yes, I'm planning to look into that in the future. Currently it is a bit of a hack, but I don't think it's far from the correct separation time. The problem here is not so much "we're not reading PC correctly", but is instead "when we separate the FWCs, because they are lighter than the metal ones, they are pushed forwards for a bit". The pressure/thrust plots for FWCs pretty much match the metal SRMs, so the PC<50 indication would come at the same thrust value. So the difference is the empty mass. To take this into account (and I don't see another way to do it), we need a SEP timer with a different value for FWC flights, so we wait a bit longer before separation.

---------- Post added at 11:04 PM ---------- Previous post was at 10:42 PM ----------

I'm looking at the FWC empty mass, and I think it's too light: the current value comes from the difference between inert and total mass for the DM-6 motor. But that motor, being a test motor, doesn't have the "SRB-side stuff" (parachutes, RSS charges, etc). That and paperwork putting the reduction in weight at ~25000lbs (vs our 76000+lbs), makes me believe our FWCs are a bit skinny...

---------- Post added at 11:29 PM ---------- Previous post was at 11:04 PM ----------

Further testing with an empty mass of 76263.84Kg makes the "separation problem" disappear (the mass being closer to the metal SRMs creates less difference in T/W at sep).

---------- Post added 09-28-14 at 02:30 AM ---------- Previous post was 09-27-14 at 11:29 PM ----------

While we're on SRBs: is there a reason to have different BSMs coordinates between the boosters?

Code:
if(Left)
	{
		thBSM[0] = CreateThruster(_V(0.752, 3.15, -19.5), _V(-0.219, -0.604, 0.765), 4*BSM_THRUST0, phBSM, BSM_ISP0);
		thBSM[1] = CreateThruster(_V(0.445, 1.22, 21), _V(-0.262, -0.719, 0.642), 4*BSM_THRUST0, phBSM, BSM_ISP0);
	} else 
	{
		thBSM[0] = CreateThruster(_V(-0.752, 2.06, -20.5), _V(0.219, -0.604, 0.765), 4*BSM_THRUST0, phBSM, BSM_ISP0);
		thBSM[1] = CreateThruster(_V(-0.445, 1.22, 21), _V(0.262, -0.719, 0.642), 4*BSM_THRUST0, phBSM, BSM_ISP0);
	}
 
Yes, one is for the FWD BSMs and the other is for the aft BSMs.
 
Yes, one is for the FWD BSMs and the other is for the aft BSMs.

I mean between left and right.
(0.752, 3.15, -19.5) vs (-0.752, 2.06, -20.5)
 
I mean between left and right.
(0.752, 3.15, -19.5) vs (-0.752, 2.06, -20.5)
Yes that's odd. The SRBs are mirror images of each other so different coordinates for Y and Z is wrong.
 
The left SRB rolls a bit at sep, so I think the correct numbers for the left would be (0.752, 2.06, -20.5). So shall I correct this and the FWC empty mass?
 
The left SRB rolls a bit at sep, so I think the correct numbers for the left would be (0.752, 2.06, -20.5). So shall I correct this and the FWC empty mass?
Yes.
 
Just committed what will probably be my last changes this year :(. I fixed a bug in AscentGuidance (that I caused) that made it impossible to launch into low inclination orbits from KSC, and in the process did a small upgrade (all with "programmers duct tape") to allow 28.45º from KSC instead of the previous 28.6º, so we can now launch Hubble into the correct orbit! :thumbup:

Three final questions/notes to the graphics department:

(1) in the picture above, isn't that vertical black line on the SRM ET attach ring segment supposed to be on the sides by the cable tray, instead of facing this view?
(2) also in the picture, looks like there's a problem with the SRB/ET attachment struts.
(3) the camera boxes for the cameras that look at the T0 umbilicals are currently in the middle of the SRB holes in the MLP instead of near the TSMs.

So, I'll still stop by from time to time, so if anyone has questions please ask. :tiphat:
 
Could you place a red circle, where you are focusing ?
 
Could you place a red circle, where you are focusing ?

srb_marked.PNG

The black lines inside the red rings are supposed to be there or should be where the green ring is?
And in the blue rings the struts don't match.
 
That the struts doesn't line up should be correctable by adjusting the attachment points on the FWC SRBs.

I'll add the FWCs to the list of things that need fixing.
 
Status
Not open for further replies.
Back
Top