Space Shuttle Ultra 1.25 Revision B development

[DaveS]

I just work on implementing panel A1U (Ku antenna controls).

Just wondering when you might have something testable ready.

 

[Urwumpe]

Just wondering when you might have something testable ready.

Depends on how much time I get for coding today.

Some time estimates:
Panel would take maybe around 3 hours of work including getting the coordinates and directions of switches and action areas right.

GCIL would be simpler, maybe one hour for a first incomplete version.

Finally, the EA1 would maybe take around 4 hours.

EA2 can wait a moment, since it is "only" radar, signal processor can wait since it is only Comms. Just the pure antenna.

The existing KubandSubsystem class would then get reduced on representing the DA. Would maybe need a few hours of work to fix and improve.

 

[Urwumpe]

Does somebody have a source for those training manuals?

"DPS FAM 21006"
"DPS HW/SW 21002"

I have found "DPS Overview Workbook 21002" on nasaspaceflight (via google), can put it in the repository if the interest is there. The DPS Overview contains some really good explanations on the differences between redundant and common set, or how the IPL process works.

---------- Post added 01-07-11 at 12:27 AM ---------- Previous post was 01-06-11 at 12:22 PM ----------

Is it possible to add panel R14 to the VC? It is below Panel R11 (with CRT4) and contains the circuit breakers for the Ku Band antenna (and also audio subsystem, TV cameras, RMS and some manifold valves)

I am slowly getting ahead here, getting the A1U switches added, next will be the signal strength meter.

 

[Donamy]

I could take a look at that.

 

[Urwumpe]

I could take a look at that.

Would be nice. I didn't care much for it so far, since it is one of those panels near the floor of the flight deck, but it is referred by nearly every checklist about communications.

Also, I have to advertise again the optimizations for the talkback, digit and light rendering. Would be great, since they would mean that we no longer need to paint on dynamic textures for these and we would get rid of one of our biggest FPS losses. We could have them all on a single big texture file, that can stay compressed in GPU memory. Every kind of object just needs to exist once then (eg, only one digit 9 for ALL seven segment display digits, or only one gray/barberpole talkback in the texture), all rendering in Orbiter would just happen by changing the texture coordinates of the mesh groups. We could then use really the same VC object class for all the same objects (currently we need to use different talk-back parameters for different background textures and drawing on the background textures costs a lot of FPS because the textures are often so large)

AFAIR, only the MDUs are then requiring dynamic textures (because of the higher resolution rendering cheat we use).

-------------------------------------------------------

BTW, about another construction place...anybody interested in adding a single spot light to each separated SRB, that illuminates the Shuttle stack during SRB separation, while the BSMs fire? Shouldn't be a too complex task, maybe something for a programmer who has interest joining SSU and feels overwhelmed by the bigger problems.

 

[Donamy]

Would every talkback need to be a seperate object ?

 

[Urwumpe]

Would every talkback need to be a seperate object ?

Yes, a single flat rectangle, just like the MFDs. The label in the panel drawings (as in the appendix of the SCOM) for talkbacks is "DS + number", so naming the objects panel code + "DS" + number would be perfect.

I don't know if this makes you feel better, but you practically just need to create all talk backs, lights, etc as such a flat object with the same texture as reference, but you don't even need to do proper UV mapping for it, we can do this after loading the mesh. Just create such a rectangle once, and copy it into every location of a talk back, maybe scale it for different object sizes.

All we then need to know is the order of the four vertices and the type of talkback, so we can insert the correct UV values there.

EDIT: I forgot the Pushbutton - indicators...these can be done in a similar way, but it is already too late here to explain this properly. Essentially having the illuminated front face of them separate from the rest of the pushbutton. but part of the same mesh group - the front face needs to be separate so the editing of the UV coordinates there does not affect the textures at the sides of the PBI.

 

[Donamy]

Was this how we did the ODS panel ?

 

[Urwumpe]

Was this how we did the ODS panel ?

No, that was still the old rendering method.

Well imagine for simplicity, you have a single texture for all gray/barberpole talkbacks. The top half of the texture represents gray, the other half barberpole.

At visual creation, we map the talkback mesh group (rectangle) to the gray half of the texture. if we switch to barberpole, we give each corner of the rectangle new texture coordinates (U,V) that make it switch to the lower half of the texture. This only changes the the mesh data, not the texture itself, which means much less data needs to be transfered between PC memory and GPU memory for rendering.

before 2010, this method was possible, but not very robust, now such kind of rendering is common place for the new Panel2D interface.

In the ODS, we had the different lights as extra bitmap in the DLL, and painted on the texture.

 

[Donamy]

I seem to recall a talkback texture early on. What was it used for ?

 

[Urwumpe]

I seem to recall a talkback texture early on. What was it used for ?

AFAIR, it is the source bitmap for painting.

Possible that I wanted to optimize things by having the talkbacks on their separate texture for painting, but as far as the code goes, this was never implemented. And now, with the "new" engine, it would be better to handle the drawing differently, pretty much like the Deltaglider draws most of its indicators now.

---------- Post added at 12:22 PM ---------- Previous post was at 11:02 AM ----------

BTW, here is a small flow chart for all those who feel discouraged to contribute to SSU:

It is no magic.

---------- Post added 01-08-11 at 12:31 AM ---------- Previous post was 01-07-11 at 12:22 PM ----------

Any suggestions or wishes for a Lua interface for the SSU orbiter?

I need to add some functions for debugging purposes anyway, no problem to do a few more.

One function that will come will permit querying the state of any discrete, so we can test if something works as advertised.

 

[DaveS]

How about a function that allows you to switch modes through Lua on the various systems? Like directly setting the ODS docking ring state to for example the Final position.

 

[Urwumpe]

How about a function that allows you to switch modes through Lua on the various systems? Like directly setting the ODS docking ring state to for example the Final position.

Can be done. I think we can even have a function to set switch positions, but this would not be that easy. I also look at a function to test the shuttle bus protocol stuff, so you can debug MDMs and IDP, etc from LuaConsole or by Lua scripts.

What would be nice is having more scenarios in which we have just the orbiter in Orbit... I currently use the STS-107 DO scenario for quick testing.

 

[DaveS]

Well, you could adapt the scenario to be MM201 instead of MM302 simulating a de-orbit prep back-out. For STS-107 that eas nearly the case on Feb. 1 due the thick ground fog at KSC with the second opportunity having strong xwinds in the forecast. EDW was not activated that day. The actual GO for the de-orbit burn was given less than 5 minutes prior to TIG.

 

[Urwumpe]

Well, you could adapt the scenario to be MM201 instead of MM302 simulating a de-orbit prep back-out. For STS-107 that eas nearly the case on Feb. 1 due the thick ground fog at KSC with the second opportunity having strong xwinds in the forecast. EDW was not activated that day. The actual GO for the de-orbit burn was given less than 5 minutes prior to TIG.

Ok, I'll try it. I'll also attempt making a scenario that starts at Post-insertion, so I can play a bit with the Post-insertion checklist.

 

[DaveS]

Ok, I'll try it. I'll also attempt making a scenario that starts at Post-insertion, so I can play a bit with the Post-insertion checklist.

Checked in a STS-107 post-insertion scenario. It starts shortly before planned PLBD opening.

 

[Urwumpe]

Checked in a STS-107 post-insertion scenario. It starts shortly before planned PLBD opening.

At T+0:50:00:00 ?

 

[DaveS]

At T+0:50:00:00 ?

You mean 50 hours or 50 minutes? The scenario should start at MET 000/00:85:00.

 

[Urwumpe]

You mean 50 hours or 50 minutes? The scenario should start at MET 000/00:85:00.

I meant at 50 minutes, sorry, my fault, did the order wrong.

000/01:25:00 is a bit late. I need to start at least at 01:00:00 for starting with "CONFIG FOR PLBD OPERATIONS", ideal would be 00:50:00, because the PL Bus activation happens at 00:55:00 and AFT STATION CONFIG begins at the same time. also I could then use the same scenario for testing the transition to SM OPS 201, for the final work on the Ku Band antenna.

(00:85:00 is not a correct time.. )

 

[DaveS]

I meant at 50 minutes, sorry, my fault, did the order wrong.

000/01:25:00 is a bit late. I need to start at least at 01:00:00 for starting with "CONFIG FOR PLBD OPERATIONS", ideal would be 00:50:00, because the PL Bus activation happens at 00:55:00 and AFT STATION CONFIG begins at the same time. also I could then use the same scenario for testing the transition to SM OPS 201, for the final work on the Ku Band antenna.

(00:85:00 is not a correct time.. )

Sorry about that, I wrote directly from memory of the FWD Event Timer. I'll check in a earlier revision of the scenario in a moment.

---------- Post added at 09:08 PM ---------- Previous post was at 09:04 PM ----------

An updated PI scenario has been checked in.