V8 Release Work Thread

Status
Not open for further replies.

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,232
Reaction score
643
Points
128
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

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,232
Reaction score
643
Points
128
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!
 
Last edited:

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,232
Reaction score
643
Points
128
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

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,232
Reaction score
643
Points
128
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

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,712
Reaction score
1,408
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
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.

1720476431320.png

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:
1720491641488.png



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.

1720490016650.png


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 7Apollo 8Apollo 9Apollo 10Apollo 11Apollo 12
AddressOctalValueAddressOctalValueAddressOctalValueAddressOctalValueAddressOctalValueAddressOctalValue
CMPIPABIASX145232710.24145277766-0.00131452107550.64145274157-0.27145274267-0.261452775360
CMPIPASCALEX145373052-300145376575-76.57145375551-140145376270-10014530052040145374312-173
CMPIPABIASY145432710.241454131750.803145476462-0.1145477011-0.07145476133-0.13145477536-0.15
CMPIPASCALEY145574705-190145572466-329.14145572457-330145574166-230145576450-80145572207-243
CMPIPABIASZ145617540.141456106540.631145661230.441456772310.051456017540.14145677340-0.16
CMPIPASCALEZ145772333-340145774553-200.71145773322-280145776540-80145777403-30145771737-306
CMNBDX146077677-0.514604252.1814604612.41460630.4146077432-1.8146077762-0.9
CMNBDY14610014615152.62146100146177532-1.3146177663-0.61461777621.3
CMNBDZ146277663-0.614626323.2214624612.414622311.2146277746-0.21462000150.5
CMADIAX14632348.2146352417.88146313751463231146300435151463003676.7
CMADIAY146433411.6146477702-3.221464230814643671314640013751464000000.7
CMADIAZ146561320.81465103128.23146577251-181465321111465000231146577754-0.1
CMADSRAX14661123.9146677724-2.2414662057146627610146677615-6146677663-1.4
CMADSRAY146777767-0.41467401.6614672539146771-1.31467000713146777663-3.3
CMADSRAZ147077530-8.8147077702-3.22147077663-4147020571470001375147077615-3.5
LMPIPABIASX1452031310.31145273631-0.41145276612-0.12145277015-0.296
LMPIPASCALEX145360066-968145370750-430145374435-210145365137-649
LMPIPABIASY1454014540.191454016600.181454015730.17145400032-0.28
LMPIPASCALEY145560462-941145562171-840145574435-210145564147-681
LMPIPABIASZ1456000000145677542-0.031456005570.071456014550.54
LMPIPASCALEZ145762045-852145767241-530145760731-920145761325-885
LMNBDX1460011114.6146077150-3.21460002451.31460000150.6
LMNBDY14610117451461002771.5146177500-1.51461001460.8
LMNBDZ1462010754.5146277546-1.2146277415-1.91462005761.3
LMADIAX1463002025.414630003211463027125714630067210.6
LMADIAY146400000-0.314640101020146477627-4146477171-16
LMADIAZ14650101019.6146576617-241465010102014650052210.8
LMADSRAX146677745-0.514660020251466000642146677713-1.3
LMADSRAY14670064016.31467000642146701244261467001504.1
LMADSRAZ147077713-1.7147077745-1147077314-11147077713-0.3

Our Mission files now have these lines:
1720490830789.png


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.

1720491478555.png



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
 
Status
Not open for further replies.
Top