Space Shuttle Ultra 1.25 Revision B development

[SiameseCat]

What I'm really looking for are the MECO targets: altitude, speed and flightpath angle and MECO.

Urwumpe: do you want the launch data in a separate text file, or in the main Orbiter log file? Also, is this something you want included in the next release, or is this just for development use? Finally, I'm not quite sure what you mean by 'samples from the guidance loop'

 

[DaveS]

What I'm really looking for are the MECO targets: altitude, speed and flightpath angle and MECO.

MECO Altitude: Nominal Peformance Enhancement, 105 km
MECO: Velocity, inertial: 7818.66 m/s
FPA: No idea

 

[Urwumpe]

Urwumpe: do you want the launch data in a separate text file, or in the main Orbiter log file? Also, is this something you want included in the next release, or is this just for development use? Finally, I'm not quite sure what you mean by 'samples from the guidance loop'

Orbiter Log would also be OK, but it is so quickly erased if nothing crashes.

Better a file of its own, created every time (we can make it optional later).

Samples from the guidance loop: Some numbers from the PEG calculations, not every timestep, but maybe once every minute.

 

[GLS]

Hi, I was passing by and noticed the SSME talk.
Regarding the SSME 104.5% Pc value: basically I have no clue how that works. :shrug: I'm pretty sure that originally it wasn't "supported", because anywhere I look it says: "the engine is controllable in 1% increments, blah blah blah". I'm almost certain that "limitation" comes from the GPCs talking to the controller, because the more range you want to have the more bits you need (or they just wanted to keep it simple).
So I don't know what changed to allow the 104.5%, it could be the formula in the GPC command changed and it now allows 0.5% ou 0.1% precision, it could be that the SW in the controller changed so that when the engine is commanded to 104% it actually goes to 104.5%, or something else.
At the moment the GPC command sends a value that is (desiredPC - MPL) * 10, and that of course gives 0.1% precision.
If anybody has further info on this please share.

Would it be a big distraction from release, to write a launch AP performance report in a text file? Something like: Where was it supposed to go, where it was on MECO, which event triggered MECO, booster separation event... maybe also a few samples from the guidance loop.

Not sure if I already uploaded that, but I added an output to the orbiter log for "MECO", "MECO Low Level Cutoff", and "MECO Confirmed" (and I already save all of the VDTs from the engines). I was thinking about adding more stuff (LH2 dump valves open, etc) but then I ran out of time... I'll continue in December/January.

 

[Urwumpe]

Not sure if I already uploaded that, but I added an output to the orbiter log for "MECO", "MECO Low Level Cutoff", and "MECO Confirmed" (and I already save all of the VDTs from the engines). I was thinking about adding more stuff (LH2 dump valves open, etc) but then I ran out of time... I'll continue in December/January.

I also want to add the OI system pretty soon (not in this release), which could be used for recording various data not displayed to the flight crew.

 

[DaveS]

The new Orbiter mesh is now done. Everything has been added and closed out for the "ferry-flight" back to KSC. The only things missing is the OMS pods.

 

[SiameseCat]

How much work is required to use the new mesh? I'm almost done fixing the scenarios and other assorted bugs, so we should be ready for a release in a few days.

BTW, if you want to check the new meshes in, it might be a good idea to check the meshes in in a new branch, instead of checking it in to the trunk.

 

[DaveS]

How much work is required to use the new mesh? I'm almost done fixing the scenarios and other assorted bugs, so we should be ready for a release in a few days.

The main changes would be to offsets. There would be new animation components for the ET Door Drive Mechanisms(DDMs).

Other than that, there's no other work.

---------- Post added at 12:33 AM ---------- Previous post was at 12:29 AM ----------

For all the log stuff: How about we move that into a dedicated SSU.log file? It's sometimes hard to find Orbiter log errors among all the SSU log messages.

 

[Urwumpe]

For all the log stuff: How about we move that into a dedicated SSU.log file? It's sometimes hard to find Orbiter log errors among all the SSU log messages.

Would be better. I would also use an OV-specific log file, so we have less collisions if ever multiple orbiters are in a scenario.

 

[DaveS]

Have we made a decision on the new orbiter mesh yet? Are we going to use it or not?

 

[SiameseCat]

As far as I'm concerned, the latest revision (rev. 1529) can be released. It would be nice if someone else could spend some time testing the current code to make sure there aren't any undetected bugs.

I'd prefer to get the release out now, then add the new meshes.

 

[Urwumpe]

Then release this weekend... I can do some testing this weekend. University is just 3 hours, got an "excellent" in B.A.

After the release, we should start a dev branch for the new features, tag the release and make sure we can still patch this release quickly.

 

[DaveS]

Anyone mind testing this release package I have put together? It should be good to go, minus the external requirements.

https://dl.dropboxusercontent.com/u/24122088/SSU release.zip

 

[Donamy]

Then release this weekend....

If it's not on a Tues. that will confuse everybody.:facepalm:

 

[SiameseCat]

I haven't actually tested the package properly, but the Docs/SSU folder is missing from the zip, and there's an empty Data folder. I've uploaded the compiled manual at https://dl.dropboxusercontent.com/u/64239213/Space_Shuttle_Ultra_Manual.pdf It might be a good idea to delete the "SSU Ops Manual V1.XX Rev. B.pdf" file from the release package, because that's an old version of the manual.

Also, the SSRMS scenarios should be deleted from the release package; it might be confusing to include these with the release.

 

[Urwumpe]

If it's not on a Tues. that will confuse everybody.:facepalm:

Damn, you are right. But we should still release this weekend and confirm it again on Tuesday, because everybody will think we are joking.

 

[SiameseCat]

Anyone mind testing this release package I have put together? It should be good to go, minus the external requirements.

https://dl.dropboxusercontent.com/u/24122088/SSU release.zip

There are a lot of files in SVN that are not included in the release package. If these were omitted intentionally because they're no longer used, I think we should delete them from the repository as well. Fixing problems in the release will be a lot easier if the release files correspond exactly to a particular SVN revision.

 

[Urwumpe]

There are a lot of files in SVN that are not included in the release package. If these were omitted intentionally because they're no longer used, I think we should delete them from the repository as well. Fixing problems in the release will be a lot easier if the release files correspond exactly to a particular SVN revision.

I agree... we should also move some many files into feature branches, since they are often only needed for one feature.

 

[DaveS]

There are a lot of files in SVN that are not included in the release package. If these were omitted intentionally because they're no longer used, I think we should delete them from the repository as well. Fixing problems in the release will be a lot easier if the release files correspond exactly to a particular SVN revision.

Yes, I deleted the files that to me appear to be unused/obsolete. I also did not include the Chandra/IUS files as they're a while off to be used, same for the Centaur G Prime files.

But the rest could be deleted. As for the Docs folder, it just adds unnecessary MBs that are of no use to end-users, just for us devs. Tell me, is there anything of actual end-user use in it?

 

[Urwumpe]

But the rest could be deleted. As for the Docs folder, it just adds unnecessary MBs that are of no use to end-users, just for us devs. Tell me, is there anything of actual end-user use in it?

We are doing open-source development, so the end-user IS dev as well possibly. Not all people who work with the SSU source code are SSU developers.