SSU Development Thread (3.0 to 4.0)

[Urwumpe]

Correct, but for some reason only the the PLT side. Why is that I don't know. Maybe Endeavour was more prone to right hand S-turns during reentry? :lol:

I am sure, DaveS will correct this for me, but I suspect the black tile actually is required because of the assymmetry of the nose: The Star tracker doors, which alter the airflow, are on the CDR side.

 

[Wolf]

I am sure, DaveS will correct this for me, but I suspect the black tile actually is required because of the assymmetry of the nose: The Star tracker doors, which alter the airflow, are on the CDR side.

I am sorry, I meant Discovery...
Urwumpe you could be right since the only asymetrical item on the nose are the Star trackers.
But still the question reamains: why only Discovery??..

 

[Urwumpe]

I am sorry, I meant Discovery...
Urwumpe you could be right since the only asymetrical item on the nose are the Star trackers.
But still the question reamains: why only Discovery??..

Not only that - the others also had asymmetric TPS there. Only Columbia and Challenger lacked it. But Discovery was maybe special because it was the third oldest Space Shuttle: Columbia and Challenger had been designed earlier, Atlantis and Endeavour had been largely different to the first two.

Maybe NASA discovered the asymmetric heating at the windows only later, because you can't simulate it, you can only detect faster aging of the tiles. Remember also, that the Discovery tear is only a single large tile: Maybe the TPS of the later orbiters had a different geometry and allowed using smaller heavy tiles there.

 

[GLS]

Not only that - the others also had asymmetric TPS there. Only Columbia and Challenger lacked it. But Discovery was maybe special because it was the third oldest Space Shuttle: Columbia and Challenger had been designed earlier, Atlantis and Endeavour had been largely different to the first two.

Maybe NASA discovered the asymmetric heating at the windows only later, because you can't simulate it, you can only detect faster aging of the tiles. Remember also, that the Discovery tear is only a single large tile: Maybe the TPS of the later orbiters had a different geometry and allowed using smaller heavy tiles there.

It's not jsut one tile. I just found this http://www.jacook.name/discovery/discoverysteardrop.html.
Also, IMO there's a very low probability that is related to the star trackers as they are on the other side.
Discovery and Atlantis were constructed +/- at the same time, and are probably the most similar orbiters.

 

[Urwumpe]

It's not jsut one tile. I just found this http://www.jacook.name/discovery/discoverysteardrop.html.
Also, IMO there's a very low probability that is related to the star trackers as they are on the other side.

Exactly that on the other side. Every change in cross section causes shock waves. The airflow is likely much more smooth, closer and faster on the PLT side, because it lacks the features that modify the airflow at supersonic speeds.

But since it is just an accident... :facepalm:

 

[GLS]

Exactly that on the other side. Every change in cross section causes shock waves. The airflow is likely much more smooth, closer and faster on the PLT side, because it lacks the features that modify the airflow at supersonic speeds.

Still, to put those tiles on the 3º vehicle, after maybe 5 flights or so, and not put them on the orbiters that were flying at the time... doesn't seem a very air tight argument...
My bet is there was some kind of damage in that area during assembly and those black tiles just add a bit more protection to the repair. That or there's some sort of antenna of sensor there.

 

[Urwumpe]

Still, to put those tiles on the 3º vehicle, after maybe 5 flights or so, and not put them on the orbiters that were flying at the time... doesn't seem a very air tight argument...
My bet is there was some kind of damage in that area during assembly and those black tiles just add a bit more protection to the repair. That or there's some sort of antenna of sensor there.

Well, your source said, that in essence, the manufacturer had produced the tiles by a different material and instead of returning them and going into a lengthy legal process, Rockwell just installed the too good tiles there, since it did not perform worse.

 

[GLS]

Well, your source said, that in essence, the manufacturer had produced the tiles by a different material and instead of returning them and going into a lengthy legal process, Rockwell just installed the too good tiles there, since it did not perform worse.

The expression "most likely answer" is used, so I'm not fully convinced... but I'm not saying that it isn't true.

 

[Urwumpe]

The expression "most likely answer" is used, so I'm not fully convinced... but I'm not saying that it isn't true.

Well, it makes sense. But yes, it is no definite answer.

 

[DaveS]

Well, it makes sense. But yes, it is no definite answer.

Tile R&R is a time-consuming task. The priority goes to first repair the tile. If that is not possible, then a R&R is performed. Since they have never gotten damaged to the point that a R&R was required, they just left them alone. That's why 80% of the tiles on any given orbiter was still original build.

 

[GLS]

So, I got myself into a deep hole, but one that needs to be dug up: attaching the SRBs to the ET instead of to the OV. Sooner or later it would have to be done for stacking and I think for a 3 EO contingency abort where the OV separates from the ET/SRB stack at SRB tailoff. And so this came up because for the launch state save to work well, the nozzle positions (and/or commands) need to be saved or there will be a big "attitude excursion". So now it makes sense to have a better ATVC and actuator implementation so we're not changing the scenarios again in the future, and then why not move the SRB gimbal stuff to the SRB vessel, yada yada yada... let's update the SRB.
So one thing we are missing is separate thrust/mass/pressure data for all 4 types: SPM, HPM, FWC and RSRM. If anybody has data about this it would help in having the correct specs for all SRB/SRM versions.

 

[Urwumpe]

So, I got myself into a deep hole, but one that needs to be dug up: attaching the SRBs to the ET instead of to the OV. Sooner or later it would have to be done for stacking and I think for a 3 EO contingency abort where the OV separates from the ET/SRB stack at SRB tailoff. And so this came up because for the launch state save to work well, the nozzle positions (and/or commands) need to be saved or there will be a big "attitude excursion". So now it makes sense to have a better ATVC and actuator implementation so we're not changing the scenarios again in the future, and then why not move the SRB gimbal stuff to the SRB vessel, yada yada yada... let's update the SRB.
So one thing we are missing is separate thrust/mass/pressure data for all 4 types: SPM, HPM, FWC and RSRM. If anybody has data about this it would help in having the correct specs for all SRB/SRM versions.

Some lot of necessary work... but you are right. We would likely also need the aft MDMs working properly soon then.

Can you file a ATVC ticket there with your requirements? I started working on them before, but paused to study hydraulic system theory for a few weeks then.

Also, can you file a ticket for a subsystem implementation of each type of sensor that we can find in ET and SRB? Even if the sensor is only polled by instrumentation subsystem? By using proper sensor classes instead of just variables in another subsystem, we can detach and reattach the SRBs and ET easier later, since there is no direct binding between the measured quantity and the systems that consume the data anymore.

EDIT: In case it is needed, I have found a design pattern for an interface pair between two vessels for exchanging the voltages of a cable bundle, which works fast enough and with some extensions even reliable enough for a simple electrical system simulation.

Maybe we can further move the SRB simulation away from the orbiter to allow LRBs.

 

[GLS]

I was thinking of having the 4 ATVC boxes being fed data directly by the ATVC_SOP (by function call as the buses don't seem to work), then each ATVC box would put the appropriate value in a discrete bundle "wire" so it could be read by the appropriate servovalve in each actuator, and the actuator would change the thrust vector accordingly.
As for the sensors I created a simple sensor class that is currently used in the ET. You just put the value in it, and it is sent to the destination on a "wire". I think that for the SRB we only need 2 PC sensors per SRM (plus the actuator command and data).

edit: LRBs?! That's way down the road... Let's first separate this (which is going to take some days at least) and leave the LRB for SSU v7.0 :lol:.

 

[Urwumpe]

I was thinking of having the 4 ATVC boxes being fed data directly by the ATVC_SOP (by function call as the buses don't seem to work), then each ATVC box would put the appropriate value in a discrete bundle "wire" so it could be read by the appropriate servovalve in each actuator, and the actuator would change the thrust vector accordingly.
As for the sensors I created a simple sensor class that is currently used in the ET. You just put the value in it, and it is sent to the destination on a "wire". I think that for the SRB we only need 2 PC sensors per SRM (plus the actuator command and data).

I am no fan of "directly feeding data somewhere from an often changing software to often changing hardware".

The data bus stuff is the least of the worries there, can you wait for the SOP until I have a virtual IOP model ready for explaining the concepts?

---------- Post added at 08:41 PM ---------- Previous post was at 08:40 PM ----------

edit: LRBs?! That's way down the road... Let's first separate this (which is going to take some days at least) and leave the LRB for SSU v7.0 :lol:.

I know. But then, we also need to separate our concerns anyway in the software source code. If it makes it possible to have LRBs in SSU 7.0 instead of SSU 8.0, I like it. :thumbup:

 

[GLS]

I wasn’t going to change much of the ATVC_SOP. It was pretty much just changing the way the actuator commands are saved. I was just going to add the 4 ATVC boxes to enable the (correct) actuator implementation, so it’s all saved in the right places, minimizing the need for future scenario changes. The big thing here, for me at least, is the moving all the SRB stuff to its vessel, and making sure that all things using the SRBs (mass/cg calc, thrust vector direction calc, data/cmd flow) work well. This way the SRB actuator positions are saved in the SRB vessel block, thus making everything more organized.
So, SRBs aside, I think the actuators are the only big change I’d like to make.

 

[Urwumpe]

I wasn’t going to change much of the ATVC_SOP. It was pretty much just changing the way the actuator commands are saved. I was just going to add the 4 ATVC boxes to enable the (correct) actuator implementation, so it’s all saved in the right places, minimizing the need for future scenario changes. The big thing here, for me at least, is the moving all the SRB stuff to its vessel, and making sure that all things using the SRBs (mass/cg calc, thrust vector direction calc, data/cmd flow) work well. This way the SRB actuator positions are saved in the SRB vessel block, thus making everything more organized.
So, SRBs aside, I think the actuators are the only big change I’d like to make.

Well, the actuator positions should be in the SRB, the actuator commands in the ATVC.

Still, the idea of using the shuttle bus system is to separate software and hardware simulation, so we are no longer mixing both systems with separate influences into an uncontrollable mess.

Also, what do you think about putting a "per-orbiter" logging function into SSU 4.0?

 

[DaveS]

So, I got myself into a deep hole, but one that needs to be dug up: attaching the SRBs to the ET instead of to the OV. Sooner or later it would have to be done for stacking and I think for a 3 EO contingency abort where the OV separates from the ET/SRB stack at SRB tailoff. And so this came up because for the launch state save to work well, the nozzle positions (and/or commands) need to be saved or there will be a big "attitude excursion". So now it makes sense to have a better ATVC and actuator implementation so we're not changing the scenarios again in the future, and then why not move the SRB gimbal stuff to the SRB vessel, yada yada yada... let's update the SRB.
So one thing we are missing is separate thrust/mass/pressure data for all 4 types: SPM, HPM, FWC and RSRM. If anybody has data about this it would help in having the correct specs for all SRB/SRM versions.

The document linked in this post has some data on the FWC SRM. And I believe our current steel SRM is for RSRM which is a HPM with modified steel cases.

 

[GLS]

Well, the actuator positions should be in the SRB, the actuator commands in the ATVC.

Yes, the commands will all be saved in the ATVC and/or ATVC_SOP, and the positions would be saved in each actuator (wherever they are located).

Still, the idea of using the shuttle bus system is to separate software and hardware simulation, so we are no longer mixing both systems with separate influences into an uncontrollable mess.

Even if there's no bus system working, parts have to talk somehow. When the buses come online, we'll upgrade the communication paths.

Also, what do you think about putting a "per-orbiter" logging function into SSU 4.0?

What do you mean?

---------- Post added at 08:26 PM ---------- Previous post was at 08:25 PM ----------

The document linked in this post has some data on the FWC SRM. And I believe our current steel SRM is for RSRM which is a HPM with modified steel cases.

The problem is pretty much the SPM and HPM data.

 

[Urwumpe]

What do you mean?

That we no longer log vessel specific data into Orbiter log, but into something like "SSU-Endeavour.log", so the large heap of data that we write is going through our own logging functions, also for reducing the redundancy in the code by having lots of statements for oapiWriteLog.

Also, the shuttle bus system has the advantage that missing data faults by powering down the MPS could also be properly included as channel I/O result word.

 

[GLS]

That we no longer log vessel specific data into Orbiter log, but into something like "SSU-Endeavour.log", so the large heap of data that we write is going through our own logging functions, also for reducing the redundancy in the code by having lots of statements for oapiWriteLog.

It's something we could do in the future, but right now I'd put that low in the list of priorities.

Also, the shuttle bus system has the advantage that missing data faults by powering down the MPS could also be properly included as channel I/O result word.

I'm not saying we don't need the buses, but while we don't have them, we have to do what we can with what we have.