SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

Status
Not open for further replies.

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
I have Zo460 for the structural ring. I've attached two schematics that should help. As for ODS total height, well that varied between versions. The interim Shuttle/Mir version used by Atlantis was 18" taller than the final version that Discovery/Endeavour flew with and Atlantis eventually was equipped with starting with STS-101.

Here's where I mention the differences in the ODS versions: https://www.orbiter-forum.com/showthread.php?p=595601&postcount=2573
 

Attachments

  • ODS_station_figures.jpg
    ODS_station_figures.jpg
    185.7 KB · Views: 152
  • ODS_station_figures2.jpg
    ODS_station_figures2.jpg
    230.1 KB · Views: 145
Last edited:

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,873
Reaction score
2,868
Points
188
Website
github.com
I have Zo460 for the structural ring. I've attached two schematics that should help. As for ODS total height, well that varied between versions. The interim Shuttle/Mir version used by Atlantis was 18" taller than the final version that Discovery/Endeavour flew with and Atlantis eventually was equipped with starting with STS-101.

Here's where I mention the differences in the ODS versions: https://www.orbiter-forum.com/showthread.php?p=595601&postcount=2573

Zo460 it is! :cheers:
As for the 18'' difference, I don't see how that's possible... if we add the ~0.25'' gap (between the retracted position of the capture ring and the docking interface) to the 462.73'' from the schematics book (Mir version) it would put the docking interface somewhere at Zo463. I doubt the ExtAL was changed, so 0'' spent there, so if there is a difference, it is only 3''.
Actually, except for a shift in the keel pin, the Xo positions of the pins and docking centerline all work exactly as advertised with the same ExtAL, so IMO it only reinforces the idea that nothing structural changed in it between Mir and ISS.
Anyway, I'll position the top of the ODS to the Zo460 ISS number, and then shift the top of the ExtAL to fill the gap, and that can be corrected later when the correct heights of the parts get figured out. IMO, the most important thing is to have the docking port in the correct place so users have the correct interface. Where the ODS ends and the ExtAL starts is pretty much eye-candy compared to it.

BTW, the ring extensions don't match between the 2 diagrams. The smaller one has translations similar to the Mir one (except for a ~3'' difference in absolute position).
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Zo460 it is! :cheers:
As for the 18'' difference, I don't see how that's possible... if we add the ~0.25'' gap (between the retracted position of the capture ring and the docking interface) to the 462.73'' from the schematics book (Mir version) it would put the docking interface somewhere at Zo463. I doubt the ExtAL was changed, so 0'' spent there, so if there is a difference, it is only 3''.
Actually, except for a shift in the keel pin, the Xo positions of the pins and docking centerline all work exactly as advertised with the same ExtAL, so IMO it only reinforces the idea that nothing structural changed in it between Mir and ISS.
Anyway, I'll position the top of the ODS to the Zo460 ISS number, and then shift the top of the ExtAL to fill the gap, and that can be corrected later when the correct heights of the parts get figured out. IMO, the most important thing is to have the docking port in the correct place so users have the correct interface. Where the ODS ends and the ExtAL starts is pretty much eye-candy compared to it.

BTW, the ring extensions don't match between the 2 diagrams. The smaller one has translations similar to the Mir one (except for a ~3'' difference in absolute position).
The 18" height difference was in the vestibule of the ODS, not the external airlock. The vestibule is the cylindrical "neck" on which the APDS unit sits on. Atlantis initial interim ODS had this longer vestibule section probably to help create further clearance between the orbiter forward fuselage and Mir's Kristall module. Remember, Kristall was originally intended as the docking place for Buran which had an extensible vestibule, not a fixed one like what was eventually flown on the US orbiters. Starting with STS-74, the longer ODS vestibule was no longer required as the Docking Module provided that extra clearance. And on ISS they have always had the PMAs.

Edit:
I've attached a schematic of the External Airlock/ODS configuration as flown on STS-71, note the extra cameras on the truss and the second TCS box.
 

Attachments

  • ODS_structures.jpg
    ODS_structures.jpg
    82.1 KB · Views: 147
  • ODS dessin 03.jpg
    ODS dessin 03.jpg
    59.7 KB · Views: 137
Last edited:

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,873
Reaction score
2,868
Points
188
Website
github.com
The 18" height difference was in the vestibule of the ODS, not the external airlock. The vestibule is the cylindrical "neck" on which the APDS unit sits on. Atlantis initial interim ODS had this longer vestibule section probably to help create further clearance between the orbiter forward fuselage and Mir's Kristall module. Remember, Kristall was originally intended as the docking place for Buran which had an extensible vestibule, not a fixed one like what was eventually flown on the US orbiters. Starting with STS-74, the longer ODS vestibule was no longer required as the Docking Module provided that extra clearance. And on ISS they have always had the PMAs.

Edit:
I've attached a schematic of the External Airlock/ODS configuration as flown on STS-71, note the extra cameras on the truss and the second TCS box.

I thought it was all the Mir flights with a tall ODS...

---------- Post added 11-06-19 at 12:29 AM ---------- Previous post was 11-05-19 at 12:30 AM ----------

Orbiter.msh, line 73211, has an L too many: "LLABEL Bay8_longeron"
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
So I'm working on the orbiter and I'm a little bit confused about the landing gear item on the list. I thought we had already dealt with it a while back. I even found on an old document on NTRS that had the relevant figures and we changed the landing gear to match those. Have you found something that contradicts those? And I have fixed that extra "L" for the Bay8_longeron mesh group.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,873
Reaction score
2,868
Points
188
Website
github.com
Diagram 13.1-1 has the positions of both the gear deploy axis and of the wheel axis when stowed. There are also (some) positions for the wheel wells. From that we can check gear position and also total length (we already have the correct gear rotation angle).
I remember checking the MLG axis position in the mesh and it was wrong. (Just checked the NLG position in the code and it's off by ~10cms in one axis and ~20 in another.)

Small note: there is no need to create new gears with all the moving parts. IMO the existing gears are enough for now, as long as things are in the right place.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,873
Reaction score
2,868
Points
188
Website
github.com
Made new SRB hole water bags, more like the real ones and by half the graphics cost. :hailprobe:
That, and some final smoke position corrections leave, IMO, the ground vessels ready for release.
The MLP is still heavy, despite the very hard and time-consuming diet it went thru. It's now 5MB smaller, but still above 20MB. Further reductions are still possible, but that can now only be achieved with remaking parts. It's probably a good idea to start with the heaviest: SRB IOP pipes and the 2 T0 umbilicals, as those 3 groups cost about 40% of the total mesh.

One item that is bothering me for a long time is the SRB smoke "explosion" at liftoff. I think it has to be with us defining the smoke particle source some distance below the vehicle. When on/near the ground, that point is below the surface and that makes the particles *crazy*. I'll probably add some altitude check before creating that PS, so it only exists above the ground.

Speaking of SRBs, those meshes are the next ones on the list... :uhh:
After that (or during that, if I get bored) will come some corrections on the IUS ASE, which quick checks revealed to be way off position. No data on the CISS, but the pins aren't far from real attachment locations, so that's fine with me.

Gave a quick look at the latest Orbiter.msh changes, and the "middeck" addition is somewhat useless... IMO there's no point in having the full-blown middeck loaded in the external view, but something needs to be inside to avoid the see-thru effect in the hatch window. A simple 5-sided box is enough for that, or more cheap even, a triangle a bit inboard of the window. The only requirement is to cover the field of view of the hatch window. Whatever the solution, that new bit can be added to the "external view vc mesh", so no code change should be needed.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
I'm currently working on the CISS. It was actually something I was doing before being called away to work on the orbiter. This is an opportunity for me to fix some things on it that I'm not too happy with. Maybe we could work in the actual pre-launch/deploy venting of the Centaur?
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,873
Reaction score
2,868
Points
188
Website
github.com
I'm currently working on the CISS. It was actually something I was doing before being called away to work on the orbiter. This is an opportunity for me to fix some things on it that I'm not too happy with. Maybe we could work in the actual pre-launch/deploy venting of the Centaur?

Right now I'm in the "bug fix mode", so we can release sometime in the next decade.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Maybe we could work in the actual pre-launch/deploy venting of the Centaur?


I suspect, unless you (almost) code it yourself, it won't happen soon, GLS is the last man standing here at the C++ side.



Also I think the Centaur is right now good enough compared to the rest of the spacecraft.



if you want to have something visually improved without having the C++ implementation as bottleneck... what about improving the TDRS satellites or the IUS?



And do we have generic/empty spacelab pallets right now, which could be implemented as pure cfg file right now?
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Also I think the Centaur is right now good enough compared to the rest of the spacecraft.
Well, we already do have everything we do need to make the Centaurs really come alive in the form of the Shuttle MPS. Remember, exactly the same propellants (LH2/LOX) coming from the exactly the same sources (the two propellant spheres at the pad(s)). Hydrogen venting would have been at the same site as the ET hydrogen venting (the large flare stack). The Centaur LOX F/D was branched off the MPS LOX F/D line on Side 1 of the MLP(s), still ending up at the LOX TSM T0 carrier plate.

So we're talking alot of commonalities here. But I understand wanting to downsize the coding aspect of things.

if you want to have something visually improved without having the C++ implementation as bottleneck... what about improving the TDRS satellites or the IUS?
We don't even have any TDRS right now, but I'd be glad to make the TRW-Gen-1 SVs if we implemented Ku band antenna tracking of them. Right now our Ku activation procedures end at KU BD PWR ON of KU -BD ACTIVATION in the generic ORBIT OPS FDF. There's several more steps we're currently missing including the part where the Ku system is actually taken into the comm mode.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,873
Reaction score
2,868
Points
188
Website
github.com
But I understand wanting to downsize the coding aspect of things.

It's not downsizing, it's having priorities, to focus our very limited resources. It would be nice to have the full ground flow, but IMO flight has priority. It would be nice to have full systems in the upper stages, complete with guidance, but having their meshes in the right place and having them deliver the expected performance to the user has priority. Etc, etc, etc...
Before we add a more sophisticated Centaur simulation (c.g. position shift, thermal rolls, etc), we could "hack" the PAM-D and PAM-D2, and we have the Centaur so why not the PAM-A as well. Even a simple standard switch panel à la Centaur, to control them would be a start. :shrug:
But before all that, we still need to "get there", and work has to be done on the ascent guidance and FCS* (so the MECOTool stops getting blamed for somebody elses errors), as well as the Orbit and Trans DAPs.
Plus, tons of small things, and details, performance increases**, reorganizations, etc...

If this wasn't enough, there is still the SSUWorkbench to finish... :facepalm:
PSA time: if anyone knows C#, your knowledge is welcome here. :hello: There is no need to know anything about the shuttle (or even Orbiter). It's just logic to load and write text files, show options in a window and make some calculations somewhere in there, and I can deal with that math, so there's no need to even know what 1+1 is. :lol:

*) having the FCS effectors and the correct command flow, will then make aborts possible, and some will have to dump the Centaur, so here's the way to that.
**) btw, still need to figure out if having the aero data in binary files is faster on loading.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
We don't even have any TDRS right now, but I'd be glad to make the TRW-Gen-1 SVs if we implemented Ku band antenna tracking of them. Right now our Ku activation procedures end at KU BD PWR ON of KU -BD ACTIVATION in the generic ORBIT OPS FDF. There's several more steps we're currently missing including the part where the Ku system is actually taken into the comm mode.


Well, we still make no use of communications yet. But unless I am wrong, we could already use them as historic payload.



The trick question is getting some balance without much code work: More meshes in orbit, but not more code. We have too much detail on the ground right now, but the orbital end is less complete.



AFAIR, we still can't easily dock to a space station, because the orbital GNC is lacking its sensors and software.



Adding sensors and software requires coding.



I could do some easy C# work, but I can't test it just like any C++ code, and that is a real annoyance. :facepalm:



On loading the aerodynamic data: Since we only need to do it once per session, does it really matter? How long does it take, 200 ms?
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,873
Reaction score
2,868
Points
188
Website
github.com
On loading the aerodynamic data: Since we only need to do it once per session, does it really matter? How long does it take, 200 ms?

The number I measured once is some somewhere in the forum, but I think it was about 4s, and there are more files now, but on the other hand I've changed them to avoid having to rotate lift and drag to axial and longitudinal forces (or the other way around...).
Anyway, 4s is maybe 10% of the load time, so IMO that is a good area to invest. Other options are: binary files or shift the data into the code and avoid the loading altogether. :shrug: Both options require a small conversion program to be written.

---------- Post added at 12:03 PM ---------- Previous post was at 04:26 AM ----------

2 questions on FWCs:
1) did the segment lengths really differ from the metal SRMs?
2) what should be the diameter at the field joints? (currently we have several...)
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
And one question from my side - what kind of computer or notebook was used on the Shuttle before the first Thinkpads?

I know that the Thermal printer of the past in the middeck was replaced by a rather standard office printer, but what was before the Thinkpads, which appeared first in 1993?
 
Last edited:

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire


Thank you, I didn't know how to find the model, now with the GRiD compass as keywords, there are many articles about the first one.


http://oldcomputers.net/grid1101.html


Here is also a reference to the NASA software of it:


https://blog.adafruit.com/2016/09/03/grids-compass-os-bootable-nasa-spoc-software-on-your-pc/

Sadly, the disk image link is broken. Maybe I can find some leads to the SPOC software.

EDIT:

Here it is on github:

https://github.com/robertely/SPOC-VirtualBox
 
Last edited:

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
2 questions on FWCs:
1) did the segment lengths really differ from the metal SRMs?
2) what should be the diameter at the field joints? (currently we have several...)
1)While the two center segments had the same length (320") both the forward and aft segments had different lengths (FWC FWD was 364.847" vs steel SRM 327.5", FWC aft was 383.72" vs steel SRM 498").
2)This is an interesting question! Unlike the steel SRMs the FWC field joints are very different. Looking a close-up hi-res photos of the FWCs mated to the MPTA-ET, it is clear that they're actual indented from the outside diameter of the actual cases. So looking at them in profile view gives them a bucket-like appearance.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,873
Reaction score
2,868
Points
188
Website
github.com
1)While the two center segments had the same length (320") both the forward and aft segments had different lengths (FWC FWD was 364.847" vs steel SRM 327.5", FWC aft was 383.72" vs steel SRM 498").
2)This is an interesting question! Unlike the steel SRMs the FWC field joints are very different. Looking a close-up hi-res photos of the FWCs mated to the MPTA-ET, it is clear that they're actual indented from the outside diameter of the actual cases. So looking at them in profile view gives them a bucket-like appearance.

Where did those FWC lengths come from? The numbers aren't "round" like the metal SRM ones... could those lengths be of the composite part alone, without the metal joint ends?
The ET attach segment was the same from the SRMs, so that has to be in the same place, as well as the fwd skirt, so the SRB connects to the ET and pad in the same way. So that would make the aft segment (from joint to HDPs) the same length, and the sum of the lengths of the two center and fwd segments would be the same, although they could have different individual lengths.

On the joints diameter, I'd say it's the same because of the ET attach metal segment.
 
Status
Not open for further replies.
Top