V8 Release Work Thread

[indy91]

Two big updates for the Lunar Module have been implemented, one for the ECS and one for the EPS. The updates can break old scenarios. For the EPS it will default to the liftoff power configuration with low voltage taps on for the descent batteries and all the ascent batteries off. So old scenarios before staging, with the LM powered up, will struggle to keep working with the low voltage. And old scenarios with only the ascent stage will have the EPS completely switched off. For the ECS, some valve states in CSM and LM have been changed, so old scenarios will have problems with that as well. rcflyinghokie will know that in more detail.

So if you are in the middle of flying a mission, don't update to the newest version of NASSP. I guess that is usually a bad idea haha. You can use one of the Mission Scenarios though, they have all been edited and updated.

 

[ggalfi]

CSM Optics visuals are improved:
1. Optics reticle patterns (both of SXT and SCT) are reworked to be more similar to the real ones. They could be used now for some angle estimation. Please refer to e.g. Apollo 15 Delco for the meaning of the lines on the reticle.
2. Reticle is now rotating with the shaft, as on the real hardware.
3. From now on, Viewport is not rotating, rather panning when either shaft or trunnion is changing. This is dictated by the rules of geometrical optics. This new feature could be confusing for anyone who has already got used to the original behaviour. However, the rotating reticle helps a lot here: changing the trunnion will result in a motion into the direction of reticle's Y axis (the numbered one in SCT), and similarly shaft into X axis. Additionally, you may use the resolved optics coupling mode (instead of direct), which automatically adjusts shaft and trunnion in a way that the center of viewport moves upward for pressing key 'W', moves down for 'S', etc. Despite the new complications with optics, on the other hand, you will find the maneuvering of CSM in any optics view much easier (e.g. in P23).

 

[indy91]

With the great update by ggalfi what now also works correctly is the Backup GDC Alignment technique. The angles for that are on all Maneuver PADs and would be used in case of an IMU failure before a critical burn. The RTCC calculation for it now give the same angles as on the historical Maneuver PADs.

The technique is the same as in the Apollo 11 Operations Checklist (https://history.nasa.gov/afj/ap11fj/a11csmoc/a11-csmoc-f9-02.jpg and https://history.nasa.gov/afj/ap11fj/a11csmoc/a11-csmoc-f9-03.jpg)

Set the three angles on the PAD on the attitude set control panel. Manually move the scanning telescope to 7.5° trunnion and 180° shaft. With that the 50° marking on the reticle now points towards one of the spacecraft axis, the one on the opposite site to the main windows. That means you can put the first star (Deneb) on the 50° mark and then yaw around until the other star (Vega) is also on the R-line of the reticle while the first star stays in its place if you only use yaw. And that is then the attitude to align the GDC to the PAD angles.

 

[indy91]

The Service Propulsion System in the CSM now has (fairly) realistic startup and cutoff behavior. It takes about half a second for the engine to start and then reaches 100% thrust within a tenth. For cutoff, it takes about 0.4 seconds for anything to happen and then thrust decays exponentially. The full cutoff impulse is equal to 0.6 seconds burn time at full thrust. There is also a small difference in behavior between using one or two banks (DV thrust switches). In reality the thrust would overshoot 100% if you start on two banks, but that isn't simulated. The recommended procedure is to start the engine on one bank and switch on the other one at TIG + 3 seconds, if the burn is that long.

The SPS is the last engine to get this update after the APS and DPS in the LM. For APS and DPS there wasn't really a choice as the cutoff impulse is hardcoded into the LGC memory. For the SPS in the CMC those numbers are mostly in erasable memory, so we had them set to 0 until now.

The main changes that were necessary for this update were the padloads in the launch and mission scenarios, so that the CMC can account for the cutoff impulse. In old scenarios you might still have that number set to 0. So e.g. if you fly the TEI burn then you would now get an overburn of up to 15 ft/s.

The other place where a change was required is the Maneuver PAD calculation. The DVC value (DV to be set into the EMS counter) is counting down to cutoff and doesn't have the total DV, so that if you perform an SPS burn with the SCS it will cut off the engine at the right time. I changed a few things in the Maneuver PAD calculation for this, so if you find some bugs let me know.

 

[Miriam]

The main changes that were necessary for this update were the padloads in the launch and mission scenarios, so that the CMC can account for the cutoff impulse.

That's setting EMEM address 3012 to 74 (octal), right? I'm just before DOI with Apollo 11 and not really inclined to fly everything again, just because of that...

 

[indy91]

That's setting EMEM address 3012 to 74 (octal), right? I'm just before DOI with Apollo 11 and not really inclined to fly everything again, just because of that...

Yes. Or address 3015 for Apollo 7-9.

 

[n72.75]

So, minor little change recently:

After watching this video and discussing with Mike

I decided to give our EL-displays a bit of an overhaul, form a color and shape perspective.

So, very minor update, but if you're wondering who broke your DSKY...that was me.

 

[Jordan]

So, minor little change recently:

After watching this video and discussing with Mike

I decided to give our EL-displays a bit of an overhaul, form a color and shape perspective.

View attachment 26148
View attachment 26149

So, very minor update, but if you're wondering who broke your DSKY...that was me.

Shouldn't the color, according to this report, be green?

https://history.nasa.gov/alsj/tnD7290Lighting.pdf

Page 6

"4 . Green EL lighting (at 15 ± 3 ft-L), for improved contrast in numeric readout displays"

and in the video from minute 2:45 the color is also greenish.

 

[Miriam]

Not quite. The same document, p 7:
"Alphanumeric readouts: green, dominant wavelength: 4900 to 5300 Angström"
In todays terms (Angström has been phased out in the 70's here in Germany): 490 to 530 nm. That's the color usually known as 'cyan', so that's about right.
I for myself just find the new font a little 'bulky'; the older one was 'crispier', especially on the 2D- panels. But that's just female sense of aesthetic and not to be taken too seriously by engineers.

 

[n72.75]

Not quite. The same document, p 7:
"Alphanumeric readouts: green, dominant wavelength: 4900 to 5300 Angström"
In todays terms (Angström has been phased out in the 70's here in Germany): 490 to 530 nm. That's the color usually known as 'cyan', so that's about right.
I for myself just find the new font a little 'bulky'; the older one was 'crispier', especially on the 2D- panels. But that's just female sense of aesthetic and not to be taken too seriously by engineers.

I just pushed a commit to revert the digit style to how it was before. It's still very 7-zegment-led-ish, so eventually I want to change it to the rectangular middle-segment, and tall upper right segment style that was actually used. Thank you for the feedback.

 

[thewonderidiot]

It's very difficult to pin down the color -- it's not quite like anything I've seen before. To try to convey that a bit, both of these pictures were taken of the exact same panel, but with different cameras and under different lighting conditions:

I will say that to my eyes, I've never seen it look quite as green as it does in the left picture. The closest I think I've seen is the close-up shot Marc put at the end of the video -- he spent a bit of time color-balancing that to try to capture the color as close as he could:

 

[Jordan]

It's very difficult to pin down the color -- it's not quite like anything I've seen before. To try to convey that a bit, both of these pictures were taken of the exact same panel, but with different cameras and under different lighting conditions:
View attachment 26160

I will say that to my eyes, I've never seen it look quite as green as it does in the left picture. The closest I think I've seen is the close-up shot Marc put at the end of the video -- he spent a bit of time color-balancing that to try to capture the color as close as he could:
View attachment 26161

You can see on this video of the Apollo 10 CSM, from minute 2:10, that the color is more light green.

 

[thewonderidiot]

Yes, I'm not disagreeing that it can appear that way on camera (as you can see in the first picture I posted). I'm just saying that when you see the screen in person, it does not look that green, at least in the lighting conditions in which I've seen it.

 

[n72.75]

Well I've ignited quite the controversy with this one...

 

[Thymo]

The cause of the "TELECOM: bind() failed: 10048" that has been popping up and breaking telemetry has been fixed.
People that had changed the Orbiter shutdown options to "Respawn Orbiter process" are now safe to change it back to de-allocate.

 

[Thymo]

You can see on this video of the Apollo 10 CSM, from minute 2:10, that the color is more light green.

You also get glimpses of the mission timer in that video. It looks way more cyan compared to the DSKY to me.

 

[Thymo]

For a long time NASSP had a bug that randomly triggered when rapidly switching between high level of time acceleration and realtime, for example when receiving a PAD from AGC. When this happened the state of the AGC would be corrupted causing computer restarts and other havoc to its erasable memory. The cause for this issue has now been found and is available from pre-release 1707 onward. All who use time acceleration and have multi-threading turned on in the Project Apollo configurator must update.

During periods of no time acceleration the AGC is run in the same thread as Orbiter along with all other systems. However, when enabled, for performance reasons the AGC is run in a separate thread when time acceleration is increased. The PIPAs need to write to one of the AGCs input channels but because they also need to use the Orbiter API they are run in the Orbiter thread. To allow access to the AGC state, access was regulated by a mutex (a gatekeeper, if you will, for non-programmers) that ensured the state was only accessed by one party at any one time. What was not considered was that the higher the time compression, the longer the timesteps take to complete. This could even be so high that when suddenly switching back to 1x acceleration the thread running the AGC hadn't yet finished its CPU cycles. Since time acceleration was stopped the new timestep would run the AGC in the Orbiter thread while there were still CPU cycles being executed. The fatal flaw was that the Orbiter thread did not check the mutex and would access the AGC's state without checking if the other thread was still using it leading to memory corruption and AGC restarts.

TL;DR Multi-threading is hard. Go update.

 

[Thymo]

A bugfix has just been released for the Apollo 8 mission scenarios (that are already in orbit). Thanks @indy91.

Due to updates in the RTCC these scenarios no longer knew the correct liftoff time and as a result state vectors and maneuvers were calculated approx. 12 hours into the future.
If you want to use an Apollo 8 mission scenario you must update.

 

[n72.75]

If you've ever had an issue with the FC C/W lights coming on when running the -4 hour prelaunch scenarios, that issue is now fixed.

SPSDK simulates radiative heat transfer, using the Stefan–Boltzmann law. This causes all hot objects to cool over time, until eventually the reach 2.7K, or in the case that heat is being added to them, some other equilibrium temperature.

Qr = rad * size * 5.67e-8 * dt * pow(Temp - 2.7, 4)

The reason the FC warning lights would come on, is that the EPS radiators would--without the full loads of the CSM electrical system on the fuel cells--cool down to -50°F or so. There is still some heat added to them the fuel cell heaters, but it isn't enough.

The fix for this was to add a simulation of convective heat transfer from the surrounding atmosphere

Qc = rad * (100 * size * (Temp - parent->Vessel->GetAtmTemperature()))*(parent->Vessel->GetAtmDensity() / 1.225)*dt;

This has the effect of adding heat to objects below atmospheric temperature, and removing heat from objects above atmospheric temperature. It's scaled by atmospheric density, normalized to the US STD. Atmospheric Density at sea level, for two reasons: It's a very convenient way to tail off convective heat transfer without discontinuities or risk of NaNs, if you're using the Jacchia71-Gill, or NRLMSIS-00 atmospheric models, than any time you're in Earth Orbit, you'd be cooked instantly by the 800-1100K temperatures, but since density is virtually zero, heat transfer is virtually zero in orbit.

I've tested this on the 7-11 pre launch scenarios, with and without time acceleration, and @Thymo and @rcflyinghokie13 have also tested parts of Apollo 8, and much of Apollo 16 (currently in progress) respectively. I did try the Apollo 5 -60sec scenario, with no temperature issues, so that appears to be good too.

Convective radiators by n7275 · Pull Request #636 · orbiternassp/NASSP

Attempt at a fix for EPS radiators cooling off on the pad to 0K. This seems to keep the ECS system semi-happy as well. I ran through the pre-launch on 7-11 (autochecklist, and time acceleration 10x...

github.com

If you encounter anything odd with temperatures, especially with EPS/ECS after you update to this, let me know and we'll fix it.

 

[indy91]

The SPS of the CSM has offset null positions of its pitch and yaw gimbal actuators to better point through the average center of gravity. That means at a pitch TRIM angle of 0° the ACTUAL angle relative to the centerline is -2.15°, and for yaw it is 0.95° actual angle at 0° trim. The CSM in NASSP has its center of gravity right on the centerline and it doesn't change with diminishing mass either. That means that we would always get +2.15° pitch trim angle and -0.95° yaw trim angle, for all CSM alone or CSM/LM maneuvers, to make the actual angles relative to the centerline zero.

But a long time ago the decision was made for NASSP to slightly move the location of SPS thrust application on the spacecraft to the sides. What that achieves is that the SPS thrust vector is pointing exactly through the center of gravity of the CSM at trim angles of 0°. For the CSM alone you then don't have to use +2.15° and -0.95° trim angles all the time.

That was before docked SPS burns were working in NASSP. With CSM/LM docked the combined center of gravity is shifted towards the LM and the thrust vector at 0° trim angles is not pointing through the CoG anymore. That's why right now we get non-zero trim angles only with CSM+LM.

This old decision has now been reversed. The SPS is located on the centerline of the spacecraft again, the SPS gimbal angles are now always 0° in pitch and yaw, for both CSM alone and CSM/LM docked. That gives us fixed trim angles of 2.15° and -0.95° in all cases. The main reason for this change is of course realism, the SPS thrust location shouldn't be shifted to a wrong location just because we get 0° trim angles then.

But this is just a first step towards a more realistic behavior in general. The LM ascent stage already has a shifting CoG in all axes, the full LM configuration has it shifting along the centerline only and now this will get implemented for the CSM as well. It will require setting the trim angles for each burn according to the Maneuver PAD, but that isn't really something new. The MCC and RTCC MFD have already been prepared for this upcoming change, so it will give the right angles once it has been implemented. This is what you can expect how the trim angles will move with the mass of the spacecraft changing. Should be coming to a NASSP build near you quite soon: