SSU Development Thread (2.0 to 3.0)

[Wolf]

Sorry if this has been answered, but is there is suitable ISS addon that works well with the latest release of SSU?

And if so, would it just require altering the scn file?

I still have no idea how to translate info from other MFDs into parameters that the SSU GPC can use. So I'm a long way off from rendezvous and docking. And if anybody can also provide help on that, I'd really be grateful. I understand things like the default MFDs can be opened via the F4 menu (which is what I usually use), as well as IMFD and TransX.

I guess my problem is trying to find information on, as well as calculate, the NC/NH burns.

And finally, I know that none of the missions have payloads yet. Does this effect the OMS-2 burn data that comes with the FDF's? I've just been using those but without the added weight of payloads, I could see inaccurate burns happening. I looked everywhere to see if someone had developed a spreadsheet or anything but came up empty handed.


Sent from my iPhone using Tapatalk

Hi kerlix,
I posted here the same issue a while ago but it seems to be difficult to find those data
http://orbiter-forum.com/showthread.php?t=35409

The good news is that some (unfortnately not all) os the STS missions FDF include a section called "attitude timeline" where you can find all the info you need for orbit insertion and rendezvous (OMS2, NC, NH, etc).
You can try to feed the SSU GPC with those datas and see if they work.
Good luck with your ISS Rendezvous!

PS About your ISS question: I would definetly reccomend the ISS AtoZ, by far the best ISS currently available!

 

[Urwumpe]

I don't want to scare anybody, but if your inbox gets a lot of mails from SF in the next days, its because I start filing tickets for the 4.0 version.

For now, its just the tickets for the Mission Editor/Workbench, but there will be more tickets as we decide on future work for that milestone.

 

[Donamy]

Donamys ISS A to Z add-on is the best recommendation I can make there.

US ISS A to Z v.3

It uses parts of Thortons ISS add-on:

International Space Station v.3.2

Only the Russian parts, but I don't sssupply them.

 

[DaveS]

Donamy: Do you think you could redo the mechanical section thermal blanket texture of the ODS to match the appearance of the real ones as opposed to the mockup that was made for the Atlantis exhibit? If you need photos, there's plenty in the ODS reference package I linked to earlier.

 

[Donamy]

I darkened it. What do you mean ?

 

[DaveS]

I darkened it. What do you mean ?

Take a look at the roughness of it. It also has alot of small squares that are not present in our current version:

 

[Urwumpe]

Take a look at the roughness of it. It also has alot of small squares that are not present in our current version:

Yes, its typical Russian thermal blanket, like often used also on the Russian modules. I am not sure, if such a texture is really easily done.

 

[GLS]

I just added the main runways at White Sands (I'll add the TAL training runway in the future). The issues experienced in D3D9 should now be minimal or non-existing. The runway lights aren't perfect as the parameters don't allow for more customization. The marker boards are missing as the meshes of existing ones have boards for both sides of the runway, and here only one side of the runway has boards.
Don't forget to add the texture names to the Base.cfg file.

 

[Urwumpe]

I discovered a UNIV PTG or stuck thruster bug in STS-1/On Orbit, there is a constant increasing yaw to the right, if you switch from VERN to PRI, the yaw increases much more rapidly. At about 32% fuel left, the thruster firing ceases, the rotation rate stays constant.

Switching to AUTO was not possible on Orbit DAP panel.

Only pressing and holding 1 on the numeric keyboard stops the thruster firing - something wrong with the usage of the thruster groups.

 

[DaveS]

I discovered a UNIV PTG or stuck thruster bug in STS-1/On Orbit, there is a constant increasing yaw to the right, if you switch from VERN to PRI, the yaw increases much more rapidly. At about 32% fuel left, the thruster firing ceases, the rotation rate stays constant.

Switching to AUTO was not possible on Orbit DAP panel.

Only pressing and holding 1 on the numeric keyboard stops the thruster firing - something wrong with the usage of the thruster groups.

I can't replicate it here. Any exact steps to required to replicate the bug?

 

[Urwumpe]

I can't replicate it here. Any exact steps to required to replicate the bug?

Just starting the scenario as it currently is.

No source code differences between SVN repository and my local working copy, except the SSUWorkbench.

 

[DaveS]

Just starting the scenario as it currently is.

In that case, everything is fine for me. The RCS activity is perfectly normal only firing when the attitude hits the deadbands.

 

[Urwumpe]

In that case, everything is fine for me. The RCS activity is perfectly normal only firing when the attitude hits the deadbands.

Fixed it - had unplugged the flight stick after finishing some landing tests in SSU, but did not tell Orbiter about it, it instead selected the new first input device, which was the Warthog throttle block. Will do some second test in SSU if this really reduces to this explanation.

EDIT: Confirmed, turning flight controller power off instantly stops the rotation.

 

[SiameseCat]

I've checked in a clone of the MECOTool util to the SSUWorkbench project. This is meant to be a proof of concept for what can be done with WPF; the MECOTool is defined as a user control, with a separate class to store the data displayed in the controls. The code for the calculations is copied from the C++ MECOTool code,

 

[GLS]

I've checked in a clone of the MECOTool util to the SSUWorkbench project. This is meant to be a proof of concept for what can be done with WPF; the MECOTool is defined as a user control, with a separate class to store the data displayed in the controls. The code for the calculations is copied from the C++ MECOTool code,

As ATM I can't "play" with that, may a few changes be added to that code?
>> MU_EARTH should be a more accurate 398600439968871.19
>> RADIUS_EARTH should be 6371010 to match Orbiter's value
>> a selection of MECO altitude with the possible values: 52, 57, 59, 61 and 63NM

---------- Post added 08-24-15 at 07:53 PM ---------- Previous post was 08-23-15 at 11:39 PM ----------

So, is tomorrow the big day?

 

[Urwumpe]

So, is tomorrow the big day?

I see nothing yet that speaks against it.

About the parameters for Earth, etc. in SSUWorkbench - I'll put this into the application settings.

Also, I will make a new implementation with the new calculation features in parallel, but the classic MECOCalc function can stay for a while.

Anybody knowing how much DV is produced by the MPS shutdown?

 

[GLS]

Anybody knowing how much DV is produced by the MPS shutdown?

To adjust the MECO velocity? That has to be done "in real time" (and already is) as the number of engines running can change and also their power level, so there's no need to correct the current MECOTool math.
One thing that might be needed is to factor in the ~11fps deltaV from the MPS dump, and the 4fps +Z translation.

 

[Urwumpe]

To adjust the MECO velocity? That has to be done "in real time" (and already is) as the number of engines running can change and also their power level, so there's no need to correct the current MECOTool math.
One thing that might be needed is to factor in the ~11fps deltaV from the MPS dump, and the 4fps +Z translation.

Is it implemented like that in our case?

 

[GLS]

Is it implemented like that in our case?

Yes, it takes into account the number of engines running and the commanded power level for fine count.

 

[Urwumpe]

Yes, it takes into account the number of engines running and the commanded power level for fine count.

Does it also take the DV in account for the calculation of the MECO target velocity?

AFAIR, the time delay for the thrust to cease is included in the guidance as ILOAD.