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

Active member
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

Member
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...

Last edited:

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

Tutorial Publisher
Donator
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

Member
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.

Last edited:

Miriam

Member
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

Tutorial Publisher
Donator
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

New member
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

Member
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

New member
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.

GLS

n72.75

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

Thymo

I like breaking things
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

I like breaking things
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

I like breaking things
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.

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

Thymo

I like breaking things
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

Tutorial Publisher
Donator
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.

C++:
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

C++:
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.

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