SSU Development Thread (3.0 to 4.0)

[Urwumpe]

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.

I strongly disagree there - we can't do everything just by hotfix on hotfix. If you only want to go by small patches on the existing heap of mess, the project will be dead by version 5.0.

So. We have absolutely no urgency to fixate any ATVC or ATVC SOP feature before going into release mode. We have the time to do it right, take the time to resist the feature fever and better plan to have something good done in 4.0. We can do things in a sustainable order and avoid excessive top-down programming.


Especially since SRB and SSME TVC are too important for our already working features to permit regression.

That is the same reason why I want better logging in SSU soon - so we have this tool available for preventing problems early.

And again: I could also just implement it, commit it and ignore that there is no I in team. "After me the deluge" is not my kind of slogan.

 

[GLS]

I strongly disagree there - we can't do everything just by hotfix on hotfix. If you only want to go by small patches on the existing heap of mess, the project will be dead by version 5.0.

So. We have absolutely no urgency to fixate any ATVC or ATVC SOP feature before going into release mode. We have the time to do it right, take the time to resist the feature fever and better plan to have something good done in 4.0. We can do things in a sustainable order and avoid excessive top-down programming.


Especially since SRB and SSME TVC are too important for our already working features to permit regression.

That is the same reason why I want better logging in SSU soon - so we have this tool available for preventing problems early.

And again: I could also just implement it, commit it and ignore that there is no I in team. "After me the deluge" is not my kind of slogan.

Yes, duct-tape on top of duct-tape is not the way to go. But, if we get 100% behind that position, we would not have a finished version until it was perfect, because A depends on B which depends on C, ..., so would have to do everything, and have it done well, so all parts could work properly. So, IMO there has to be some "cheating" at times (like the current GPCs which will now be upgraded), so we can at least do something. Eventually we reach a point where the limitations are too great and we have to upgrade. It's a "pleasure and pain" cycle, as we implement something and then upgrade it, and yes, if we can do it right the first time then we should, but if we can't do it right, should we stop?

That said, right now I don't have need to change the way the ATVC SOP and the ATVC work and interact. What I would need (and if it's wrong or if it can be better, do tell) to change is instead of having them write "config X" in the scenario file, it would be "1Y -2.4", "1P 4.3", etc, explicitly stating the position instead of a choice of 4 or 5 "special" positions. Further downstream I would introduce an actuator class, so that the position is saved in a standard way across all actuators, not really caring (for now) about the hydraulic system. So the only real changes would be replacing the existing direct call from the ATVC to Atlantis::SetSSMEPositionWhatever with writing into a discrete port that would be read by the actuator. I don't think this collides with the GPC upgrade or your ATVC and actuator work, does it?

 

[Urwumpe]

Yes, duct-tape on top of duct-tape is not the way to go. But, if we get 100% behind that position, we would not have a finished version until it was perfect, because A depends on B which depends on C, ..., so would have to do everything, and have it done well, so all parts could work properly. So, IMO there has to be some "cheating" at times (like the current GPCs which will now be upgraded), so we can at least do something. Eventually we reach a point where the limitations are too great and we have to upgrade. It's a "pleasure and pain" cycle, as we implement something and then upgrade it, and yes, if we can do it right the first time then we should, but if we can't do it right, should we stop?

No, we should just avoid changing something, that is contradicting what we are planning for 4.0, we are redoing some lot of the DPS anyway according to what we have in mind, so why develop something for the old version, that will hinder the next step?

And again: It doesn't matter that we have your ATVC changes in 2 weeks. We need the changes in release 4.0, not earlier. We have the time to do things in order.

Also, I am not changing much about the GPCs. They are just resources. What I want to change is the software model. The only thing that will be GPC dependent is a part of the IO and the DPS display driver system. Some system software might even display something differently depending on which GPC is driving a display.

 

[GLS]

No, we should just avoid changing something, that is contradicting what we are planning for 4.0, we are redoing some lot of the DPS anyway according to what we have in mind, so why develop something for the old version, that will hinder the next step?

And again: It doesn't matter that we have your ATVC changes in 2 weeks. We need the changes in release 4.0, not earlier. We have the time to do things in order.

Also, I am not changing much about the GPCs. They are just resources. What I want to change is the software model. The only thing that will be GPC dependent is a part of the IO and the DPS display driver system. Some system software might even display something differently depending on which GPC is driving a display.

So I'm pretty much "locked out" of development, as I can't change anything related to the DPS until that is upgraded, and then I'll have to wait some more time for the ATVC to be done properly, so I can continue the launch state save work.

 

[Urwumpe]

So I'm pretty much "locked out" of development, as I can't change anything related to the DPS until that is upgraded, and then I'll have to wait some more time for the ATVC to be done properly, so I can continue the launch state save work.

There is more than enough stuff that needs to be done without waiting for the DPS changes. Alone integrating the upper stages into the trunk will take some work. The Ku Band antenna could also be done without relying on the DPS.

Next, it would be helpful to get mechanic systems sorted out, so we can finish star tracker doors and vent door animations.

I just want you to wait until there is a Virtual IOP for the new DPS and an equivalent IO stub for the old DPS model.

(And of course, there is the SSU Workbench. But since you already said you are out for C# work)

 

[GLS]

There is more than enough stuff that needs to be done without waiting for the DPS changes. Alone integrating the upper stages into the trunk will take some work. The Ku Band antenna could also be done without relying on the DPS.

I think I've done all I could in the upper stage department. I don't know how to make non-linear speed animations for the CISS pipes, the IUS umbilical is not done yet so I can't animate it, and I can't hide the SRM-1 nozzle cover as it isn't there. I won't even think about Centaur propellant dumps as that needs the GPCs. The only thing I could do is merge both branches to the trunk as they are (and I'd say they are +/- ready).
As for the Ku antenna... what would it do?

Next, it would be helpful to get mechanic systems sorted out, so we can finish star tracker doors and vent door animations.

I'd need the GPCs to control the vent doors....

I just want you to wait until there is a Virtual IOP for the new DPS and an equivalent IO stub for the old DPS model.

The only thing near the GPCs that I need to change is the state save/load callbacks of the ATVC SOP and ATVC classes. But I'll accept your request and put this whole state save and SRB thing in the back burner.

(And of course, there is the SSU Workbench. But since you already said you are out for C# work)

Until I upgrade VS, and the code there is far along that I can see how things work, yes I'm out of that .

 

[DaveS]

As for the Ku antenna... what would it do?

Track a TDRS in while in COMM mode and a rendezvous target when in RADAR mode. The RADAR mode would be the most useful mode right now as it is very much used during rendezvous up to about 400 ft. It's far more accurate than the star trackers which can only be used during night.

Not to mention the added visual accuracy of the dish actually moving. Currently the slewing of the gimbals to the Master Index Pulse (MIP) positions is implemented as part of the KU BAND DEPLOY procedure when it is really part of the KU BAND ACTIVATION procedure.

Ku band DA in action (1:45 into the video):

(22:10 into the video)

 

[GLS]

Track a TDRS in while in COMM mode and a rendezvous target when in RADAR mode. The RADAR mode would be the most useful mode right now as it is very much used during rendezvous up to about 400 ft. It's far more accurate than the star trackers which can only be used during night.

Not to mention the added visual accuracy of the dish actually moving. Currently the slewing of the gimbals to the Master Index Pulse (MIP) positions is implemented as part of the KU BAND DEPLOY procedure when it is really part of the KU BAND ACTIVATION procedure.

Ku band DA in action (1:45 into the video):
STS-118 - Endeavour/ISS DOCKING - YouTube

(22:10 into the video)
STS 41-G: Mission Highlights - YouTube

I haven't done any research yet, but the COMM mode needs GPCs, and the RADAR mode doesn't, right? So for RADAR, once given a target we could calculate the distance, and when it gets within range, have the antenna point to it and start outputting range and position data to panel A2. That's what the stuff there is for, right?

BTW: that 41G video proves that if RF fails, the TDRS also works with hand signals :rofl:.

 

[DaveS]

I haven't done any research yet, but the COMM mode needs GPCs, and the RADAR mode doesn't, right? So for RADAR, once given a target we could calculate the distance, and when it gets within range, have the antenna point to it and start outputting range and position data to panel A2. That's what the stuff there is for, right?

BTW: that 41G video proves that if RF fails, the TDRS also works with hand signals :rofl:.

Actually both require the GPCs, mainly for state vectors. Here's a bit of discussion between me and a MCC flight controller: http://forum.nasaspaceflight.com/index.php?topic=20425.msg541515#msg541515

http://forum.nasaspaceflight.com/index.php?topic=20425.msg541537#msg541537

For more information, I highly recommend the KU Band System workbook.

 

[GLS]

Actually both require the GPCs, mainly for state vectors. Here's a bit of discussion between me and a MCC flight controller: http://forum.nasaspaceflight.com/index.php?topic=20425.msg541515#msg541515

http://forum.nasaspaceflight.com/index.php?topic=20425.msg541537#msg541537

For more information, I highly recommend the KU Band System workbook.

If we need the GPCs then it probably won't work for now. Sadly I have a funeral to attend tomorrow, so I won't be able to do much reading on the subject.

 

[Urwumpe]

I think I've done all I could in the upper stage department. I don't know how to make non-linear speed animations for the CISS pipes, the IUS umbilical is not done yet so I can't animate it, and I can't hide the SRM-1 nozzle cover as it isn't there.

I can do that non-linear animation work, if that helps you.

As for the Ku antenna... what would it do?

Mostly we need the formulas for translating elevation and azimuth angles into gimbal angles and back.

I'd need the GPCs to control the vent doors....

Yes, but not for moving the doors. I had started a base class for all AC motor assemblies that control the various mechanic systems in the Shuttle, which would need some finishing work.

The only thing near the GPCs that I need to change is the state save/load callbacks of the ATVC SOP and ATVC classes. But I'll accept your request and put this whole state save and SRB thing in the back burner.

Not for much time. I think I will hurry a bit to at least give you an idea what I have in mind, so you can start upgrading the software in parallel. The important difference is really just that you no longer talk with the subsystem classes directly, but start I/O programs - theoretically, we could even modify the existing PASS software implementations so far, that there is no difference between single GPC mode and partition mode classes, except the IO model that it needs to use. So the old mode could still be used for performance or as fallback, but we only need to write software once.

But as you can see by the word "theoretically" - My gut tells me it is clearly possible, but my brain has no idea yet, how. Maybe I will use this week for some experimenting.

The goal for the partition based software should be something like saying:

fcos.startIO(io.gncTransferATVC);

(For PASS at least - but BFS could be done similar)

Until I upgrade VS, and the code there is far along that I can see how things work, yes I'm out of that .

No deal, I am happy I can learn some stuff from SiameseCat there.

---------- Post added at 10:39 AM ---------- Previous post was at 10:36 AM ----------

Actually both require the GPCs, mainly for state vectors.

Not for the low-level work. Its possible to control the Ku-band antenna directly by the panel, without GPC.

The GPC is needed for getting calculated data into the system or doing calculations with the Ku-Band data.

For example, once the antenna has acquired the TDRS, it no longer needs the GPC for maintaining the connection, it can track the satellite automatically.

EDIT: Also remember that there is the GCIL around - which requires the SM GPC for transferring data.

 

[DaveS]

Not for the low-level work. Its possible to control the Ku-band antenna directly by the panel, without GPC.

The GPC is needed for getting calculated data into the system or doing calculations with the Ku-Band data.

For example, once the antenna has acquired the TDRS, it no longer needs the GPC for maintaining the connection, it can track the satellite automatically.

EDIT: Also remember that there is the GCIL around - which requires the SM GPC for transferring data.

So what is the final verdict? Do we need the GPCs before we can implement the Ku band system? Especially if it relies on SM which don't even have right now (we only have GNC).

 

[Urwumpe]

So what is the final verdict? Do we need the GPCs before we can implement the Ku band system? Especially if it relies on SM which don't even have right now (we only have GNC).

I would say, we can test the Ku-Band antenna without the PASS SM, I can imagine a few test scenarios, where we just need to select PANEL for commanding the Ku-band antenna.

But for fully using the Ku-Band antenna, we need the ANTENNA display in SM.

I believe even the spiral search pattern is implemented in EA1, and not in PASS SM.

 

[DaveS]

I would say, we can test the Ku-Band antenna without the PASS SM, I can imagine a few test scenarios, where we just need to select PANEL for commanding the Ku-band antenna.

But for fully using the Ku-Band antenna, we need the ANTENNA display in SM.

I believe even the spiral search pattern is implemented in EA1, and not in PASS SM.

How are we going to accomplish KU BAND ACTIVATION since it is using two SM displays, ANTENNA and SM 76 COMMUNICATIONS? This procedure is the one that sets the entire system up for use either in COMM mode or RADAR mode. And even KU BAND MANUAL ACQUISITION (COMM) relies on SM.

 

[Urwumpe]

How are we going to accomplish KU BAND ACTIVATION since it is using two SM displays, ANTENNA and SM 76 COMMUNICATIONS? This procedure is the one that sets the entire system up for use either in COMM mode or RADAR mode. And even KU BAND MANUAL ACQUISITION (COMM) relies on SM.

Would need to check, but I am sure that these applications are only needed for displaying data, not for control.

As said above: a finished state would require the DPS. And since nothing on the shuttle works without a properly working DPS (and even the current DPS implementation being inadequate), we need some more priority there, unless we constantly want to either wait for the DPS or implement some throw-away code that looks nice in screenshots, but can't be used for following any checklist.

 

[DaveS]

Would need to check, but I am sure that these applications are only needed for displaying data, not for control.

As said above: a finished state would require the DPS. And since nothing on the shuttle works without a properly working DPS (and even the current DPS implementation being inadequate), we need some more priority there, unless we constantly want to either wait for the DPS or implement some throw-away code that looks nice in screenshots, but can't be used for following any checklist.

I'm willing to wait for a better DPS implementation if it means we get rid of these restrictions.

 

[Urwumpe]

I'm willing to wait for a better DPS implementation if it means we get rid of these restrictions.

How long is the question. Right now, it is clear it will be done by release 4.0. But now the question is, when is the last reasonable moment to finish the design of the better DPS - the longer we have to try and experiment, the better for the result. On the other hand, we have the pressure of many other subsystems and payloads requiring the DPS update or evolutionary dead-end code to get implement, which has to be replaced by new DPS code before release.

I would say, that a final DPS architecture before November (2015) is a good guess, so that the foundation of the new DPS can be done in December (2015) and the new software modes for SM and the transition of the GNC/BFS software can take place during the first quarter of 2016.

---------- Post added at 12:28 PM ---------- Previous post was at 12:23 PM ----------

Because of the significance, what about introducing a 3.1 milestone for the DPS tickets?

 

[DaveS]

How long is the question. Right now, it is clear it will be done by release 4.0. But now the question is, when is the last reasonable moment to finish the design of the better DPS - the longer we have to try and experiment, the better for the result. On the other hand, we have the pressure of many other subsystems and payloads requiring the DPS update or evolutionary dead-end code to get implement, which has to be replaced by new DPS code before release.

I would say, that a final DPS architecture before November (2015) is a good guess, so that the foundation of the new DPS can be done in December (2015) and the new software modes for SM and the transition of the GNC/BFS software can take place during the first quarter of 2016.

---------- Post added at 12:28 PM ---------- Previous post was at 12:23 PM ----------

Because of the significance, what about introducing a 3.1 milestone for the DPS tickets?

I would agree with that with one exception, 3.1 should be for a possible patch for issues discovered with 3.0. DPS sounds more like 3.5. I got a couple of issues that were unresolved by the time of the release of 3.0. I'd like to log these as official tickets so that they won't be forgotten.

 

[Urwumpe]

I would agree with that with one exception, 3.1 should be for a possible patch for issues discovered with 3.0. DPS sounds more like 3.5. I got a couple of issues that were unresolved by the time of the release of 3.0. I'd like to log these as official tickets so that they won't be forgotten.

Well, the in semantic versioning, the first patch would be numbered 3.0.1, I could make a special milestone for 3.0.1 as well to collect those.

 

[DaveS]

Well, the in semantic versioning, the first patch would be numbered 3.0.1, I could make a special milestone for 3.0.1 as well to collect those.

That sounds good. I just need a milestone to log the issues under.