#### indy91

The update I was talking about in the last post is now released. The CSM now has a center of gravity that shifts depending on (mainly) SPS propellant mass being burned. That means that for all SPS burns you now need to use SPS trim gimbal angles that are non-zero. The MCC and RTCC MFD should be able to provide the right numbers in all cases. The same applies to docked DPS burns. The trim angles are in all cases very close to the actual numbers from the transcript. I guess that makes sense as the SPS propellant makes up such a large part of the CSM and the CG of the SPS tanks are well known, so this wasn't difficult to simulate.

What also behaves a little bit different now is transposition and docking. Previously the CG of the CSM was always in front of the SM RCS quads. That means a translation up was causing a small pitch down moment. So the advanced technique was to thrust in one direction and then wait until the attitude rate has settled before judging how much of a translation the RCS firing actually caused. Now the effect is the other way around, as the CG is now in most cases behind the SM RCS quads. Also, the moments of inertia are updated dynamically, too, based on mass. The mass normalized principal moments of inertia (PMI) are smaller for a heavy CSM now (about 3.6 instead of 4.6 in pitch and yaw), although for a light CSM there shouldn't be a big difference. But the smaller PMI make the rotation caused by a translation effect during TD&E a bit stronger than before. So TD&E is a little different now, just something to get used to.

As part of this update I discovered that the empty masses of the Apollo 8 and 10 CM and SM included the SM RCS and CM RCS. That made the CSM about 700 kg too heavy at launch for those missions, which is now fixed. Old mission scenarios have been edited to implement this, too, although the CMC might still have the old mass loaded. The SPS trim gimbal angles have been correctly loaded in the CMC in the mission scenarios though.

#### indy91

Orbiter's main engine controls have been disabled in NASSP. Previously you could still throttle up and down like any other vessel in Orbiter. Or start and stop the engines with the plus and minus key on the numpad. That applied to the SPS, APS, DPS and all main engines of the Saturn stages. Now instead of defining the engines with main or hover thruster groups they are user defined thruster groups, to which Orbiter has no direct access. So you can't accidentally cut off an engine manually, or, what might have happened to Max-Q on his Apollo 12 mission, a noisy throttle lever causing an early shutdown of the J-2 engine during TLI.

The throttle control of the DPS isn't affected, as that has already been custom code. Orbiter Sound treats these user defined thruster groups differently than main or hover engines, so it now uses a slightly different sound file for those engines. But it sounds enough like the old engines to be an acceptable difference. We could always customize the engine sounds in the future.

#### indy91

As requested by user STS some very old code has been enabled again so that you can put the astronauts in a boat after splashdown.

I looked at some old NASSP code and it seems like this used to be done by pressing the R key in NASSP 6. As that is taken up by Orbiter itself I have decided to use ALT + R for this. So now after the last step of a complete mission in NASSP, opening the hatch, has been done you can press ALT + R and get this:

#### Max-Q

##### 99 40
Would it be possible to map a keypress to the abort handle? I am building a THC for NASSP and would like to have this functionality. Sorry if this is not the correct place to ask this, I didn’t want to start a new thread just for this.

#### rcflyinghokie13

##### LM Junky
Would it be possible to map a keypress to the abort handle? I am building a THC for NASSP and would like to have this functionality. Sorry if this is not the correct place to ask this, I didn’t want to start a new thread just for this.
Keyboard - and = should work for it, we should add those to the keyboard commands sticky thread.

#### indy91

Done, no idea why that was missing.

#### ggalfi

##### Active member
Would it be possible to map a keypress to the abort handle? I am building a THC for NASSP and would like to have this functionality. Sorry if this is not the correct place to ask this, I didn’t want to start a new thread just for this.
A few month ago I pushed a configurable joystick interface into the Orbiter2016 branch of NASSP. I've merely focused on the LM to make it flyable during P64-66 solely by a many button device like an X-Box controller or my VKB Gladiator stick. However I also implemented the most important controls for the CSM as well (rotational and translational stuff), so the THC is already ready in the Vesim module except the CW/CCW functionality. It is already on my ToDo list, together with the addition of the SPS Valve mappings as well, tough not with the top priority. But if you consider to use this module together with your THC device, I quickly add these as well. It will not interfere with Indy's addition as you can switch on or off Vesim up to your discretion in the PA Config, and it is up to you, how you map a certain functionality to the keyboard or to some DirectInput compatible device.

#### Max-Q

##### 99 40
I use the prebuilt releases of NASSP, is this included in the basic releases?
My THC is actually a cheap 2 axis joystick modified so the push/pull is actually rigged up to the throttle axis... can I remap the throttle axis to +/- translation in Vesim?
To simplify the whole THC rig, rotating the THC would probably be handled simply through two buttons.

#### Thymo

##### I like breaking things
It is included but it's not really easy to find the documentation if you don't know where to look as there is no user-friendly way to set it up you need to manually create a file that is then read by this module.

You can find a description in Doc/Project Apollo - NASSP/VESIM.txt

#### ggalfi

##### Active member
I use the prebuilt releases of NASSP, is this included in the basic releases?
My THC is actually a cheap 2 axis joystick modified so the push/pull is actually rigged up to the throttle axis... can I remap the throttle axis to +/- translation in Vesim?
To simplify the whole THC rig, rotating the THC would probably be handled simply through two buttons.
As Thymo mentioned, it is included, and yes, you have to adjust the config files manually (GUI for that is also on my ToDo list, the problem is that I'm a less then moderate and less then enthusiastic UX developer ). Technically the PA Configurator can create the config files for each attached devices and also creates the rows in it for each available functionality. But you have to manually edit these lines to map a button or axis to a functionality. At the moment, you have to find out, what is the ID number of a certain button, but if you are the one who creates the device, surely you will know it. There was another guy here in the forum (I cannot recall his name), who made some custom devices for NASSP, once he tested VESIM with 10 devices simultaneously attached. After some bugfixing, it worked as far as I remember. If you have problems with the configuration of VESIM for your device, certainly I'm happy to help with it.

#### MishutkAviation

##### New member
Hi there, I have a little problem - in NASSP V8 I can't see anything trough CM 3D cockpit windows when I'm on ground - it works in 2D and in 3D, when I'm in space. Is it a bug or did I do something wrong?

Here are screenshots showing how it looks like - with the opened hatch there's some weird texture too.

#### Attachments

• 1633362925813.png
105 KB · Views: 32
• 1633362946012.png
383.7 KB · Views: 31

#### indy91

Well the Boost Protective Cover doesn't have a window over the right rendezvous window of the CM, that is always going to be covered. Hence the line from Michael Collins during launch after tower jettison:

000:03:36 Collins: Yeah, they finally gave me a window to look out.

The side windows are covered, too, I think. I can see through the side hatch window just fine, when it's not dark outside or the crew access arm is on the CM. Maybe the access arm is the weird textures? The only issue I am seeing is that the left rendezvous window is also covered with the BPC on. Not sure why that is, our BPC mesh does have a window there, maybe it doesn't align properly or something, I will take a look.

#### Max-Q

##### 99 40
As of the latest build (1741), it appears that the CM postlanding float bags are broken. They inflate inside the CM cockpit! This probably got broken with the big CSM CG shifting update... every version I have installed since then has had this problem.

#### DDasng1352

As of the latest build (1741), it appears that the CM postlanding float bags are broken. They inflate inside the CM cockpit! This probably got broken with the big CSM CG shifting update... every version I have installed since then has had this problem.
Yup I have the same issue, I think I've had it since 1738 I forgot. Here is a photo from an Apollo 8 attempt I recently completed:

Last edited:

#### indy91

Should be fixed in the latest version. At apex cover jettison there is a 1.2 meter shift of the center of mass. It used to be done by an outdated Orbiter API function (ShiftCenterOfMass), now it gets done by a better function (ShiftCG) but that shifts the attachment points as well. So the float bag attachment point stayed in the position where the CG of the CM is located before the apex cover jettison and chute deployment. You can see that in the picture above. It's not the perfect long term solution, but the attachment point now gets reset to the same place as the origin of the CM (that's where it says "AS-503" in the picture above).

#### rcflyinghokie13

##### LM Junky
With the latest release comes a small addition of functional CM RCS injector valves. Now they will heat and cool in space and be measurable on the systems test meter 5C 5D 6A 6B 6C 6D. Additionally, the CM RCS heaters now are functional and are properly implemented by energizing the direct coils. This also will be visible with the system test meter.

#### n72.75

Tutorial Publisher
Donator
After a few months of testing my update to NASSP's systems simulation (a heavily modified SPSDK) is ready to be pushed.

What this update does is change how vapor pressure and enthalpy of vaporization are calculated. Figure [1], below shows a comparison of the old and new methods for calculating vapor pressure. The old method was a linear approximation, which worked well enough at the pressures and temperatures that the systems containing these substances were normally at, but once temperatures and pressures strayed too far from where these linear approximations were originally created, noticeable inaccuracies were inevitable; the case that comes to mind, is my attempt to simulate--using SPSDK, the fuel cell reactant chambers--and having 450°F 60PSI oxygen, still partially in the liquid phase. The new model is based on an adjusted version of the Antione Equation, and the Clausius-Clapeyron relationship..

In addition to vapor pressure, the method for calculating enthalpy of vaporization has been greatly improved. the previous method, used a constant value, chosen at the pressure-temperature values, where each particular substance would normally boil. Again, in existing NASSP code, this rarely causes issues, but it does prevent us from doing more advanced. This is based on:

G.F. Carruth, R. Kobayashi, Extension to low reduced temperatures of three-parameter corresponding states: vapor pressures, enthalpies and entropies of vaporization, and liquid fugacity coefficients, Industrial & Engineering Chemistry Fundamentals, 11 (1972) 509-517.

Old vapor pressure model:

$P_v = P_{v_0} - (T_0-273.15)\frac{dP_v}{dT}$
New vapor pressure model:

$P_v = {e}^{(A-\frac{B}{T_{abs}})}$
Old vapor enthalpy of vaporization model:

Constant value.​

New vapor enthalpy of vaporization model:

$H_{vap} = \frac{R}{T_{critical}}7.08 \left ({1 -\frac{T}{T_{critical}}} \right )^{0.354} + 10.95\omega \frac{\left ({1 -\frac{T}{T_{critical}}} \right )^{0.456}}{M}$

Figure [1].

Figure [2].
This shouldn't break any existing scenarios, but you may get a brief "O2 Flow High" alarm. This update should facilitate improvements in systems accuracy, and leaning more heavily on the systems simulation for things like propellant, fuel cells, etc.

As always, if you find any bugs please let us know, and we'll work to correct them as quickly as we can.

#### indy91

A small but useful new feature in the CSM. The multiply button on the numpad, which in standard Orbiter controls causes the main and retro engines to cut off, now sets both DV Thrust switches to off. This is useful for manual SPS engine cutoffs, especially in the Virtual Cockpit. The Apollo 7 SPS-5 burn specifically was cut off in this way, but if you first have to move the mouse to both those switches, or even worse, you were zoomed in to the FDAI and the switches weren't even in view, then you now have a way to stop the engine on time.

#### sw34669

##### Active member
is it me or has the agc turned cyan/blue. How can I turn it back to original green ? Is this an option somewhere ? thanks im running v1759
I watched the ealier video and am a child of the late 60's / 70's LEDs are green or red My first red led ti calculator would drain a PP9 in an hour. Luxury managed to retire my log tables.
What a splendid bunch of improvements have come the addons way thanks for all the hard work from the usual suspects

Last edited: