Space Shuttle Ultra 1.25 Revision B development

[Urwumpe]

Checked an new IUS ASE mesh that has the correct distance between the aft and the forward ASE frames. BTW, how will the ASE be controlled as we currently doesn't have the ASE SSPs?

How about a dialog? The panels would be nicer, but we can't do miracles, right?

 

[DaveS]

How about a dialog? The panels would be nicer, but we can't do miracles, right?

I guess a dialog similar to the ones we have for R13L would be the best recourse until we have the IUS ASE SSPs.

 

[Donamy]

Any good pictures of those panels ?

 

[DaveS]

Any good pictures of those panels ?

If Urwumpe still has the STS-93 IUS Deploy Checklist, he could check it in as I believe it has schematics of the IUS panels. They go on the left aft station as they're designated L11 and L12.

 

[Urwumpe]

If Urwumpe still has the STS-93 IUS Deploy Checklist, he could check it in as I believe it has schematics of the IUS panels. They go on the left aft station as they're designated L11 and L12.

Yes, I have just found it...saved the STS-93 docs outside the STS folder, that made it harder to find it again :hail:

I'll put it into the Docs folder. Don't forget the L10 "IUS POWER" panel. This one also allows control over the ASE tilt.

PS@DaveS: If you search for useful mesh details on the ASE, there seems to be a large scale on it that shows tilt table angle and safety zones.

 

[Donamy]

Got it !! Thanks !

 

[DaveS]

How's the IUS coming along?

 

[Urwumpe]

How's the IUS coming along?

Not that much today, had been busy. Will first do the IUS stage as standalone (deployed) vessel, so it can be tested.

 

[DaveS]

Something I forgot to mention: I checked in start up and shut down sounds for th Crawler V16 Alco-Diesel motors. The noise the Crawler makes(CrawlerEngine.wav) is made continuously as long as the V16's are running, even when the Crawler is stationary.

 

[DaveS]

The CT driver cab panels are nearly done. Just need to do the various gauges and PBIs and add the LDS display.

 

[DaveS]

After watching this morning's launch of STS-131, I noticed a couple of items that would be nice to have:

• A blue/purple contrail texture for OMS exhaust, was very noticeable in the ET cam during OMS Assist
• A blueish-white SSME nozzle base texture during SSME burn

The OMS exhaust can be clearly seen in this video:

http://www.youtube.com/watch?v=yKF9FHZRPYw

 

[DaveS]

I just did a check of the Ku band antenna deployed angle and according to this chart from the Ku-band Operations Workbook, we have the correct angle. I know there was some debate when I changed this from the previous 113° to the current 150°s.

 

[SiameseCat]

The code for using the ET/SRBs as attached vessels during launch has been checked in. I've also checked in a launch test scenario. I'll fix the other launch scenarios once we confirm that everything is working properly.

 

[Donamy]

Would this allow the use of the new SSME thrust mesh ?

 

[DaveS]

The code for using the ET/SRBs as attached vessels during launch has been checked in. I've also checked in a launch test scenario. I'll fix the other launch scenarios once we confirm that everything is working properly.

Any update on why the CRTMFD is producing CTDs when you turn it off and then turn it on again?

 

[Urwumpe]

I did some more work on the "SimpleGPC" model, well...simple for a GPC, when the last concept errors are fixed, it should be possible to use HAL/S data types, COMPOOLS, processes and other features of the GPCs.

class INTEGER: public Symbol
        {
            word16* m_var;
        public:
            INTEGER();
            INTEGER(const std::string& name, word16 hw_addr);
            INTEGER(const INTEGER& copy);
            virtual ~INTEGER();

            virtual word32 Resolve(GPC* gpc, word32 base_addr);

            INTEGER& operator =(const INTEGER& b) const;
            bool operator ==(const INTEGER& b) const;
            bool operator >=(const INTEGER& b) const;
            bool operator <=(const INTEGER& b) const;
            bool operator >(const INTEGER& b) const;
            bool operator <(const INTEGER& b) const;
            INTEGER& operator -(const INTEGER& b) const;
            INTEGER& operator +(const INTEGER& b) const;
            INTEGER& operator *(const INTEGER& b) const;
            INTEGER& operator /(const INTEGER& b) const;
            INTEGER& operator &(const INTEGER& b) const;
            INTEGER& operator |(const INTEGER& b) const;
        };
...
...
...

class FCOS: public GPCSoftware {
        PROCEDURE FPMSVC;
        PROCEDURE FPMSCHED;
        PROCEDURE FPMCHPCT;
        PROCEDURE FPMCVTFX;
        PROCEDURE FPMEVENQ;
        PROCEDURE FPMEVAL;
        PROCEDURE FPMSWITCH;
    public:
        FCOS(GPC* gpc);
        virtual ~FCOS();
        virtual word16 operator()(word16 instr_addr);
    };

Still not completely free of design flaws, but I think the concept makes sense. The software would still be hard-coded in C++, but would be close enough to HAL/S to behave like the original software. The variables could be shared by different active processes (up to 30 when using the PASS standards), without having complex data passing and sharing between local and global data.

 

[DaveS]

The new code works nicely here! No issues, launch autopilot is just as smooth as before. Donamy: On the SSME exhaust mesh, please check in SSMEstream.dds, it's missing.

---------- Post added at 01:37 AM ---------- Previous post was at 01:35 AM ----------

Also where do we stand on getting the Ku up and running? I think it would be a prime candidate along with the RMS for our new attachment philosophy to enable them to be jetted.

 

[Urwumpe]

Also where do we stand on getting the Ku up and running? I think it would be a prime candidate along with the RMS for our new attachment philosophy to enable them to be jetted.

I think making the Ku-band antenna attached would be too much, since it is usually not jettisoned and a rather standard part. A loading gap when the Ku-Band antenna is jettisoned would be tolerable, if this means simpler implementation of the antenna.

 

[DaveS]

I think making the Ku-band antenna attached would be too much, since it is usually not jettisoned and a rather standard part. A loading gap when the Ku-Band antenna is jettisoned would be tolerable, if this means simpler implementation of the antenna.

Having attached would mean a correct representation of the first 6 missions when no orbiter had it. Challenger was delivered with it but it was removed during the OPF flow for STS-6. Was reinstalled for STS-7. Columbia's first mission with the Ku band antenna was STS-9.

 

[Urwumpe]

Having attached would mean a correct representation of the first 6 missions when no orbiter had it. Challenger was delivered with it but it was removed during the OPF flow for STS-6. Was reinstalled for STS-7. Columbia's first mission with the Ku band antenna was STS-9.

Yes. So we can do it by making the Ku-Band mesh invisible for the first launches and disable the subsystems of it.