V8 Release Work Thread

[indy91]

To enhance the latest Virtual Cockpit update even further, a new type of rotational switch class has been implemented to allow lighting controls (and some others) to work more like the potentiometers they were and have finer control over them:

As you might be able to tell from the video, these switches are now operated by holding left click on the knob and pulling the mouse to the sides to rotate them. On the 2D panel the control has been made consistent to this changed VC behavior, although the finite number of bitmap states for the switches make this slightly awkward. I think the consistency of control between 2D and VC is more important though.

When updating to the latest NASSP Beta, the affected switches will sadly have the wrong switch positions in old scenarios, so be aware of that. The switches are:

-All flood, integral, numerics controls in the CSM and LM
-CSM high gain antenna and LM steerable S-band antenna pitch and yaw controls
-ORDEAL altitude selection in CSM and LM
-SPS gimbal trim thumbwheels (control hasn't changed for this, but saving/loading in scenarios at the 0.1° increments is fixed now, see https://github.com/orbiternassp/NASSP/issues/1209)

 

[indy91]

He has done it again!

Now available in NASSP is Comanche 67, the CMC software flown on Apollo 12. The software comes from the flight spare rope modules and was read by @thewonderidiot with his rope reader, as before for the Skylark modules and others.

There is only one major update from the Apollo 11 CMC software and a bunch of minor quality of life updates. The major update is Verb 79, a little program for automatic passive thermal control (PTC) and orbit rate pitch maneuvers. On previous missions these were accomplished with direct manipulation of DAP variables, which always seemed a bit scary to me. Comanche 67 puts these in an extended verb. Eventually, in Artemis (Apollo 15+), this feature got extended and incorporated into the universal pointing capabilities of P20.

The step from Apollo 12 to 13 is fairly small in terms of software changes, so it is probably possible for @thewonderidiot (and my usual 1% contribution for these things) to reconstruct the Apollo 13 CMC software from these newly found ropes. No promises though and it will definitely take several weeks, as the Comanche 67 source code will first have to be reconstructed. Until then our Apollo 13 scenario will keep using the Apollo 11 CMC software, to avoid changing this twice and potentially breaking/interrupting more missions that people are flying.

Thank you so much to Mike and the anonymous collector, who owns the rope modules, to preserve this software and make it possible to be used in NASSP!

 

[indy91]

As it turns out the Comanche 72 reconstruction might be a bit tricky. I also discovered that, due to the small number of differences between Comanche 67 and 72, old scenarios using Comanche 67 would not break when changing to Comanche 72 in the middle of a mission. You could just be in P00 and get a restart from the rope switch, but the lack of any relevant padload differences between the two ropes means you could continue as normal, without erasable memory edits in the scenario.

So considering these two facts, our Apollo 13 scenario(s) from now on uses Comanche 67! May it take a few days or months to get Comanche 72, as I said, it won't matter much for ongoing missions.

The switch from Comanche 55 (which our Apollo 13 scenarios were using until now) to 67 is not as painless though, so I cannot recommend doing that for an ongoing mission.

 

[indy91]

A reconstruction of Comanche 72 revision 3 is now available! So Apollo 13 in NASSP now uses the correct software for both CMC and LGC. Thanks again to @thewonderidiot for accomplishing this difficult feat. Going further than this is not really possible as Comanche 108 for Apollo 14 had too many changes, including changes that differ from Artemis for Apollo 15 and later. So this will be it for AGC updates in NASSP until more core rope modules are found.

 

[n72.75]

Time for another update:

NASSP now supports IMU drift and accelerometer bias!

WARNING: DON'T UPDATE NASSP MID-MISSION FOR THIS UPDATE
Also, you guys can't skip P52s any more.

Brief Intro

The Apollo IMUs are comprised of a reference platform to which 3 IRIGs (Inertial Reference Integrating Gyroscope), and 3 PIPAs (Pulsed Integrating Pendulous Accelerometer) are mounted. The platform is supported by 3 servo-powered gimbals, which actuate to keep the platform in a fixed reference attitude. The image below shows an overview of the platform and the sensing elements on it.

The X, Y, and Z gyros (IRIGS) detect angular accelerations in their respective Input Axis (IA), by spinning a gyroscope along the Spin Reference Axis (SRA), and producing an output torque in the Output Axis (OA). The torquing of the output is sensed, and used by the AGC to determine, how much it needs to drive the IMU servos, such that the IMU platform remains fixed in space. The actual IMU position is determined by measuring the resolver phase angles. (There is a longer version of this description that we can get into when we properly impliment CDUs)

IMU Drift

Because nothing is perfect, the IMU sensing elements are subject to accumulating errors over time. The IMU will experience a drift (angular movement out of a perfect alignment) from the gyros, and the accelerometers will introduce error into the measured DV.

The sources of error in the IMU come in 6 types (each of these have an X, Y, and Z component, so it's really 18)

• Null Bias Drift
  • This is the angular drift rate that the IMU experiences under no aceleration. It is a constant (but very slow) movement of the IMU about each of its principal axes.
• Aceleration Drift, Spin Reference Axis
  • Angular drift about each principal axis, as a result of aceleration along the spin-refereence axis.
• Aceleration Drift, Input Axis
  • Angular drift about each principal axis, as a result of aceleration along the input axis.
• Aceleration Drift, Output Axis (not simulated, neglegable effect)
  • Angular drift about each principal axis, as a result of aceleration along the output axis. This is neglegablly small, and we don't simulate it, nor do we have good data for values for flown IMUs
• PIPA Bias
  • Offset in where the "zero aceleration" reading is with respect to actual.
• PIPA Scale Error
  • Linear error in measured aceleration. (Span error)

If you've ever wondered why the IMU has special density-matched fluids in it, this is why:

Drift-rates are measured in MERU (Milli Earth Rate Unit, equal to 7.29211586E-8 radians/second, or 1/1000 the rate at which earth rotates) or MERU/g.
PIPA biases are in cm/sec.
PIPA Scale errors are in ppm.

This is all now simulated. Our IMUs for Apollo 7-12 have the correct (mission specific) drift-rate and biases, and over time will lose alignment. PIPA bias will be observiable when in P47 or V16N21.

***​

While introducing errors into the simulation on its own is certianly fun, its still not the best part of this update. The CMC and LGC ropes actually have software that is ment to compensate for these drifts and biases. The figure below actually shows a 1800 ft/sec SPS burn between ~250 and ~325 seconds. In these plots, you can see both the aceleration sensitive drift, and the null bias drift, allong with the AGCs corrections to compensate.

If you are interested in how this works see: https://www.ibiblio.org/apollo/listings/Comanche055/IMU_COMPENSATION_PACKAGE.agc.html

The values below come from flown padloads:

	Apollo 7			Apollo 8			Apollo 9			Apollo 10			Apollo 11			Apollo 12
	Address	Octal	Value	Address	Octal	Value	Address	Octal	Value	Address	Octal	Value	Address	Octal	Value	Address	Octal	Value
CMPIPABIASX	1452	3271	0.24	1452	77766	-0.0013	1452	10755	0.64	1452	74157	-0.27	1452	74267	-0.26	1452	77536	0
CMPIPASCALEX	1453	73052	-300	1453	76575	-76.57	1453	75551	-140	1453	76270	-100	1453	00520	40	1453	74312	-173
CMPIPABIASY	1454	3271	0.24	1454	13175	0.803	1454	76462	-0.1	1454	77011	-0.07	1454	76133	-0.13	1454	77536	-0.15
CMPIPASCALEY	1455	74705	-190	1455	72466	-329.14	1455	72457	-330	1455	74166	-230	1455	76450	-80	1455	72207	-243
CMPIPABIASZ	1456	1754	0.14	1456	10654	0.631	1456	6123	0.44	1456	77231	0.05	1456	01754	0.14	1456	77340	-0.16
CMPIPASCALEZ	1457	72333	-340	1457	74553	-200.71	1457	73322	-280	1457	76540	-80	1457	77403	-30	1457	71737	-306
CMNBDX	1460	77677	-0.5	1460	425	2.18	1460	461	2.4	1460	63	0.4	1460	77432	-1.8	1460	77762	-0.9
CMNBDY	1461	0	0	1461	515	2.62	1461	0	0	1461	77532	-1.3	1461	77663	-0.6	1461	77762	1.3
CMNBDZ	1462	77663	-0.6	1462	632	3.22	1462	461	2.4	1462	231	1.2	1462	77746	-0.2	1462	00015	0.5
CMADIAX	1463	234	8.2	1463	524	17.88	1463	137	5	1463	23	1	1463	00435	15	1463	00367	6.7
CMADIAY	1464	334	11.6	1464	77702	-3.22	1464	230	8	1464	367	13	1464	00137	5	1464	00000	0.7
CMADIAZ	1465	613	20.8	1465	1031	28.23	1465	77251	-18	1465	321	11	1465	00023	1	1465	77754	-0.1
CMADSRAX	1466	112	3.9	1466	77724	-2.24	1466	205	7	1466	276	10	1466	77615	-6	1466	77663	-1.4
CMADSRAY	1467	77767	-0.4	1467	40	1.66	1467	253	9	1467	71	-1.3	1467	00071	3	1467	77663	-3.3
CMADSRAZ	1470	77530	-8.8	1470	77702	-3.22	1470	77663	-4	1470	205	7	1470	00137	5	1470	77615	-3.5
LMPIPABIASX							1452	03131	0.31	1452	73631	-0.41	1452	76612	-0.12	1452	77015	-0.296
LMPIPASCALEX							1453	60066	-968	1453	70750	-430	1453	74435	-210	1453	65137	-649
LMPIPABIASY							1454	01454	0.19	1454	01660	0.18	1454	01573	0.17	1454	00032	-0.28
LMPIPASCALEY							1455	60462	-941	1455	62171	-840	1455	74435	-210	1455	64147	-681
LMPIPABIASZ							1456	00000	0	1456	77542	-0.03	1456	00557	0.07	1456	01455	0.54
LMPIPASCALEZ							1457	62045	-852	1457	67241	-530	1457	60731	-920	1457	61325	-885
LMNBDX							1460	01111	4.6	1460	77150	-3.2	1460	00245	1.3	1460	00015	0.6
LMNBDY							1461	01174	5	1461	00277	1.5	1461	77500	-1.5	1461	00146	0.8
LMNBDZ							1462	01075	4.5	1462	77546	-1.2	1462	77415	-1.9	1462	00576	1.3
LMADIAX							1463	00202	5.4	1463	00032	1	1463	02712	57	1463	00672	10.6
LMADIAY							1464	00000	-0.3	1464	01010	20	1464	77627	-4	1464	77171	-16
LMADIAZ							1465	01010	19.6	1465	76617	-24	1465	01010	20	1465	00522	10.8
LMADSRAX							1466	77745	-0.5	1466	00202	5	1466	00064	2	1466	77713	-1.3
LMADSRAY							1467	00640	16.3	1467	00064	2	1467	01244	26	1467	00150	4.1
LMADSRAZ							1470	77713	-1.7	1470	77745	-1	1470	77314	-11	1470	77713	-0.3

Our Mission files now have these lines:

Implications for Users
Because the AGC compensates for drift, for the most part the misalignment will be almost unnoticable, apart from slightly higher N93 values. That being said, if you've ever skipped a P52 "because our IMU is perfect, and doesn't drift", you can no longer do that.

If you're really hard-core you could try adjusting one of the rates, and using the mission technique I've linked in References, to try to calculate it only from N93 values (I'm not by any means saying this is easy).

Extras
We also now simulate the IMU resolver voltage outputs, and phase errors. These are downlinked over telemetry, and could be used to determine the orientation of the spacecraft. The image below is from our TCP telemetry client.

Thanks
The very beginings of this project were in December of 2022 and started over dinner and a few beers with @rcflyinghokie @thewonderidiot, and @CaptainSwag101 at Paddy's in Newton MA. I did not know what I was getting myself into at the time, and @indy91 has been a huge help checking my left-handed rotation-matric math, testing, and making sure I don't merge typos or stray debugging code, by reviewing all 122 files I changed for this project. @rcflyinghokie, @ThatRedMelon, @Max-Q, and a few others from the SFS Discord have also tested this extensively. Thank you.

References

https://www.ibiblio.org/apollo/Documents/stg_memo_1016.pdf

https://www.ibiblio.org/apollo/Documents/mission_techniques_memo_39b.pdf#page=36

https://www.ibiblio.org/apollo/Documents/System%20Test%20Determination%20of%20Apollo%20IRIG%20Drift%20Coefficients.pdf

https://www.ibiblio.org/apollo/Documents/improvement_of_gyro_drift_data.pdf

 

[rcflyinghokie]

Implement GSE cryo dewars, remove cabin heater boilers from cabin fans by rcflyinghokie · Pull Request #1311 · orbiternassp/NASSP

Project Apollo - NASSP. Contribute to orbiternassp/NASSP development by creating an account on GitHub.

github.com

Just a small little update to improve launchpad behavior, we have implemented cryo dewars to continuously top off the SM cryo tanks while on the pad. This has two big benefits, your cryo quantity doesn't decrease on the pad and your pressures will stay stable even with the fans/heaters off on the pad.

One caveat however, if you update this mid mission you might have open valves that will cause pressure drops, in which case you have to manually edit your scenario to close the cryo inlet valves changing the leading "1" to a "0" as shown below.

<TANK> O2TANK1 133.938700 1 0 1 0 0 0.00010000 0.00001000 0.00100000 1.00000000
<TANK> O2TANK2 133.938700 1 0 1 0 0 0.00010000 0.00001000 0.00100000 1.00000000
<TANK> H2TANK1 191.138700 1 0 1 0 0 0.00100000 0.00010000 0.00100000 0.00100000
<TANK> H2TANK2 191.138700 1 0 1 0 0 0.00100000 0.00010000 0.00100000 0.00100000

 

[CaptainSwag101]

I've made a minor quality-of-life change to make things easier for keyboard users.

For major maneuvers using the spacecraft engine, procedures call for you to enable the direct RCS coils (ROT CONTROL DIRECT in the CSM, ACA/4 JET in the LM). To oversimplify, the direct RCS coils bypass the logic in the RCS system and fire the jets regardless of other factors, such as the DAP or rotational rate limit. In the real spacecraft, the hand controllers had microswitches at the very end of the stick's travel, which was used to activate the direct RCS coils only when the appropriate cockpit switches were active AND the astronaut deflected their hand controller to its maximum angle. However, in NASSP, when you press a key on the keyboard, that's just an "on" or "off" signal, which was previously interpreted as a full deflection of the hand controller. This meant that, if you had the direct RCS system enabled via the cockpit switches, it would always fire any time you commanded rotation. This is frustrating because it wastes fuel and reduces your ability to maneuver in a controlled manner.

But, no more. Now, the default behavior for using keyboard attitude controls is that they command almost full deflection of the stick, just shy of triggering the direct RCS. If you want 100% stick deflection, simply hold the Alt key when commanding rotation.

Furthermore, you can now command "ACA out of detent" in the LM by holding Ctrl and Alt together and then commanding rotation. This moves the stick just a tiny bit (only 0.75 degrees from center) in order to zero the attitude deadband, and signal to the computer that the stick has moved without actually making the spacecraft fire its jets at all. This will be useful for LM activation procedures and RCS cold fire tests, as well as the "out of detent" step performed on Apollo 11 after touchdown.

Basically, you should now have better control over when (and how much) your RCS jets fire in both vehicles in certain situations when using the keyboard, and should otherwise not notice a significant difference.

 

[n72.75]

Please read: If you are in the middle of flying a mission, do not update NASSP without performing the fix listed below:

This change: https://www.orbiter-forum.com/threads/v8-release-work-thread.36128/post-621001 intruduced IMU drift rates and PIPA bias/scale error. Recently we discovered a bug in the PIPA scale code, wherein we were applying the scale compensation rather than the scale-error itself. This fix ended up being a simple sign change in the code, thankfully.

For NASSP Users:
If you are in the middle of flying a mission you will need to either: 1) wait until you finish the mission to update NASSP 2) edit your scenerio to delete the following lines:

Any lines that start with: "PSCALE", e.g. PSCALE_X:

NOTE: there will be 6 lines total for scenarios with LMs and C(S)Ms. You need to get all of them.

Save the scenario, and when you reload, NASSP will load the correct values in from the mission file. If you have any questions, please reach out here or on the SFS discord. I'm happy to help edit scenerios for people

 

[Tiny_Bob]

We now support the EASEP experiments and equipment for Apollo 11! This includes the TV camera, the Solar Wind Composition Experiment, the Passive Seismometer Experiment, and the Lunar Ranging Retro Reflector. Deployed with the "K" key. CDR does the camera, and LMP does the SWC, PSEP, and LRRR, in that order. ALSEP is coming soon.

 

[indy91]

Another major Virtual Cockpit update, mostly by @Jordan, is complete!

The major features are an improved system for floodlights, new digits for mission timers and new animated objects in the Command Module. These glareshades etc. were stowed on launch, but could be attached by the astronauts to various systems to improve visibility. Here are the 10 new animated CM VC elements:

-Panel 382 cover
-Waste disposal
-Altimeter cover
-Accelerometer cover
-Main DSKY glareshield
-EMS DV glareshield
-Mission timer glareshield
-Sextant eyepiece
-Telescope eyepiece
-Stowable ORDEAL

The click spots are usually right on top of the covers or on velcrospots. For the ORDEAL and the panel 382 cover a right mouseclick has to be used, as otherwise you might click one of the switches. The other new elements are used with left click.

Also various meter scalings have been corrected and probably many minor changes I am forgetting right now!

 

[rcflyinghokie]

Pressure relief valves have now been added to the CSM cryo system. This means if you leave your heaters/fans on too long, over pressurizing your H2/O2, you will start venting O2/H2 into space!

Be weary of leaving those on now, you will of course get a CRYO PRESS light before the valve opens. One more thing to keep an eye on!

 

[indy91]

There has been a major visual upgrade of the RTCC MFD. Most MFD pages had originally been adjusted to look correct on the 2D panel, with the specific MFD size we use in NASSP (300 something pixels). As we are transitioning more and more to the Virtual Cockpit we are using the External MFD more. And depending on the MFD size my old system of position data on the MFD display could lead to quite major overlapping of text. Here an example:

Many MFD pages are trying to replicate real displays that were available to flight controllers in the MOCR. And I recently found out a bit more about the font sizes that were used for the displays. They had a few sizes available, the most commonly used one showing 28 x 56 characters. Here of course occurs a problem that has long bugged me. MFDs in Orbiter are usually in the aspect ratio 1:1 while the MOCR TV displays had the common TV aspect ratio of 4:3. This made it impossible to have the exact same display format as the real displays, at least in some cases.

So to fix the overlapping text issue once and for all and to properly show all the MOCR displays we have I have done a major overhaul, with changes to all pages of the RTCC MFD. It now has the proper format for all the MOCR displays (where we know them) and no matter the External MFD size, there is no text overlapping.

This does have some downsides though. Some MFD pages are now using a really small font size, especially the MOCR displays. It is barely readable on the 2D panel in some cases. But as we are mostly moving to the VC where the External MFD has to be used and because the NASSP 2D panel MFDs have always been smaller than the "glass cockpit" ones or in other vessels (e.g. DeltaGlider 2D panel) I think this is an acceptable limitation.

Here is how the same MFD page is looking now:

One additional idea I had was to create a modified version of the External MFD that is in the 4:3 aspect ratio. This would be really nice for the MOCR displays because it allows a larger font size. So attached to this post is a very WIP version of this, which I call "Wide External MFD":

 

[rcflyinghokie]

We have added a few small under the hood features that in no way will impact your day to day missions. Now the crew generates urine and urine dumps will actually dump this overboard. If you dont have stored urine on board, you wont see the yellow spray when opening the valve. Additionally, the particle streams for urine and water dumps has been improved.

Also in this update, the PAMFD has been reorganized slightly, moving the ECS glycol debugging display to its own subsection and adding a UCD (urine containment device) percentage showing you how much stored urine you have on board. Also, when on the lunar surface, you can "jettison" this with the new JET button at the time of equipment jettison.

Right now there is zero harm having "full" urine or not dumping as before, but this gives a more realistic urine dump instead of just generating the dump particle effect whe the valve is open.

 

[n72.75]

We have merged a small update to improve O2 behavior today.

Back when we introduced realistic liquid substance densities that vary with pressure and temperature:

I chose some values for an updated liquid oxygen bulk modulus that were quite cold. The result of this was that the O2 could be quite stiff. And with full tanks, small changes in temperature would result in large changes in pressure. Well, no longer will this be the case. We now have improved bulk moduli for O2. This will eventually be added for other substances, but this was the most sensitive.

These are implemented as a 1000 element 1D lookup table plus a scaling factor, taken from NBS Technical Note 384
This is probably a significant performance bonus over my usual curve-fit 5th order polynomial approach.

 

[rcflyinghokie]

Normally I don't make a writeup here for a mission/MCC/checklist update, but I will in the case of Apollo 7. Being one of our oldest scenarios, it's checklist and MCC have not received any love like other missions have over the years. It was made difficult by not having a lot of documentation, the correct software, correct panels etc. for the 7 flight. However now it has a brand new checklist per the actual flight as well as new MCC pads and procedures appropriate to Apollo 7.

Hopefully this will make 7 more streamlined and less confusing for those of you who have flown 7 in the past. Enjoy!

 

[rcflyinghokie]

Following up on the Apollo 7 update, we have also released an update to Apollo 9's MCC and checklist that better supports the flown mission. Procedures, timelines etc have been updated with many corrections and improvements, adding improved (correct) LM procedures for the many powerup/powerdowns, CSM checklists for rendezvous, and you now can choose to do the EVA portion per the flight plan or as it actually was flown.

We hope this will make 9 more fun to fly and keep you on your toes!

 

[rcflyinghokie]

Just a quick PSA, those updating NASSP please make sure you delete the old scenario files before updating. They all have been updated but since many were removed they must be manually deleted if installing from the zip.

Easy way to do it is simply deleting the Scenarios/Project Apollo - NASSP folder before updating with the latest release zip.

As always if there are any questions or issues let us know!

 

[rcflyinghokie]

A little late to adding this, I apologize, but Apollo 8 now has an additional MCC state for a TLI+11 pad added per the actual flight. If you have a current Apollo 8 save between TLI and LOI-1 update pad, you will need to bump your mission state up by 1.

You can do this by editing your scenario file MCC_MissionState line and just incrementing the number by one.

 

[rcflyinghokie]

Another slight update FYSA, the AOT reticle knob can now be pushed in at zero degrees to "lock" it in place to prevent turning while using it for X/Y P52s. The click spot is the reticle knob in 2d and coming soon to the virtual cockpit.

If you are trying to rotate the AOT and it wont move, its a feature not a bug and check the reticle knob!

 

[rcflyinghokie]

We have made a few corrections to the CM flood circuitry. Not only is everything wired up and function (dim and flood switches) but there are a few quirks with the flood system added:

One significant one you will notice is floods don't engage until the knob is pushed passed half, that and your secondary floods have a much smaller dimmable range. Another feature not a bug is the lighting is dependent on bus voltage now, so increases and decreases in voltage will cause slight but noticeable dimming or brightening of the flood lights.