#### indy91

A long-term project of mine is finally done, a big update of the Saturn V LVDC. It's mostly a reorganization of the code, but there are some new features. In a way this update to the LVDC code is the same one that happened to the actual LVDC software between Apollo 11 and 12. They called it the "generalized flight program" and its goal was to "
facilitate easier program modification and promote economical utilization of LVDC core memory". To quote the astrionics handbook:

The generalized Flight Program System is composed of two basic parts or subsystems; the application subsystem and the control subsystem. The application subsystem is a collection of programs whose sole purpose is to perform the individual actions or functions which comprise the task of an LVDC flight program for a given mission or missions. The control subsystem, however, is mission independent and is itself divided into three parts; an executive control program. a common utility package, and a common communications and data area. The primary purpose of the control subsystem is to control the sequence and order of operation of all programmed functions specified for a particular mission task.

So you could say this update implements a more modern coding standard in the LVDC++, instead of using one large timestep function with lots of goto/label. The most obvious new feature is a minor loop support routine, that calculates attitude increments for the attitude control in the minor loop. In short, it makes the steering smoother.

This update causes the LVDC to not work in old scenarios anymore, so I have created new mission scenarios for the missions where we had scenarios. Old scenarios before liftoff are fine (except Apollo 9) and scenarios after having left behind the S-IVB are also fine, this update causes no CTDs or so. There could be many new bugs, so if you see something unusual, please report it.

#### n72.75

Tutorial Publisher
Donator
Clogging for the fuel cells has been enabled again. If you have updated in the last two weeks it's suggested you update to the latest snapshot.
With today's patch the clogging has been tuned a bit so you don't have to do a purge every couple of hours.
If you forget to purge you will eventually get a master alarm due to a main bus undervolt, ignoring that the fuel cell will eventually fail due to being completely clogged,

n7275 is also doing a complete redo of the ways our fuel cells work using proper physics and chemistry to get the behaviour even closer to a real fuel cell so that, eventually, we can do things like fuel cell activation on the pad and fuel cell failure due to the electrolyte melting or solidifying.

In case anyone is interested, here's the output of the new fuel cell voltage model, rendered in Matlab (okay, Octave,):
The labeled contours show isopotentials across the cell terminals.

The data for this model comes from this figure (4.1-10 of the CSM Operational Databook):

If you're interested the model itself is:

C++:
loadResistance = (829.44) / (power_load); //829.44 = 28.8V^2 which is the voltage that DrawPower() expects. use this calculate the resistive load on the fuel cell
Volts = 31.0; //inital estimate for voltage

//coefficients for 5th order approximation of fuel cell performance, taken from:
//CSM/LM Spacecraft Operational Data Book, Volume I CSM Data Book, Part I Constraints and Performance. Figure 4.1-10
double A = 0.023951368224792 * Temp + 23.9241562583015;
double B = 0.003480859912024 * Temp - 2.19986938582928;
double C = -0.0001779207513 * Temp + 0.104916556604259;
double D = 5.0656524872309E-06 * Temp - 0.002885372247954;
double E = -6.42229870072935E-08 * Temp + 3.58599071612147E-05;
double F = 3.02098031429142E-10 * Temp - 1.66275376548748E-07;

for (int ii = 0; ii < 5; ++ii) //use an iterative procedure to solve for voltage and current. with our guess of 31 volts these should converge in 3~5 steps
{
Volts = A + B * Amperes + C * Amperes*Amperes + D * Amperes*Amperes*Amperes + E * Amperes*Amperes*Amperes*Amperes + F * Amperes*Amperes*Amperes*Amperes*Amperes;
}

My next project is adding ALL of the EPS radiators (we had 4, now we'll have all 8), and their glycol loops, and then some of the fuel cell internals: pressure regulators, reactant, pre-heaters, and a condenser on the H2 side. It's fairly complicated with a lot of interacting systems (NASSP uses a heavily modified version of @Radu094's SPSDK for its systems. Which is the same SDK upon which the Dragonfly is built), and some of it may get simplified if it's too unstable or resource intensive, or breaks time acceleration with stiff systems.

#### Attachments

• fuel cell performance model.png
84.4 KB · Views: 623
Last edited:

#### indy91

Another incredible AGC reconstruction project has finished, this time it is the Apollo 10 CMC software, Comanche 45 revision 2. It is now used in NASSP for Apollo 10.

The main sources for the reconstruction were Colossus 249, the Apollo 9 CMC software, and Comanche 055 revision 2, the Apollo 11 CMC software. We have banksums for Comanche 44, 45, 45 revision 2 and 51, all of which were manufactured at some point, so we can be nearly 100% sure if the reconstructed code is correct. Some time ago already Comanche 51 had been reconstructed from 55. So how hard can it be to go back six more revisions? Well...

The original release for Apollo 10 was Comanche 44. This was reconstructed after some time. With the help of some Comanche anomaly reports from the MIT museum we were able to figure out that Comanche 44 had a terrible bug that had to be fixed. It basically has a broken P30 to P40/P41 interface. An important number to determine the burn direction is not getting transferred to P40/P41 correctly, so the burn direction could be random. There is a workaround the astronauts could have done, but obviously this is far less than ideal so a rope module was manufactured with a fix for this issue.

The problem to determine the exact fix (the step from Comanche 44 to 45) is that only one rope module (out of 6) was manufactued again, so they couldn't just squeeze in the fix into the P40 code, or else the addresses that the code in the other rope modules were calling in the newly made module would be off. So the fix had to involve a jump to the end of a bank and then a jump back, leaving the fixed routine at the same number of words as before. We didn't have much information about the nature of the fix, so this involved a lot of trial and error. Here is the what the fix looked like in the end:

Comanche 44:
Code:
SETPD    VLOAD
0
VTIG
STORE    VINIT

Comanche 45:
Code:
SETPD    CALL
0
S40.1A
STORE    VINIT

The fix:

DELVSIN
STOVL    DELVSAB
VTIG
RVQ

After this was done, the step from Comanche 45 to 45 revision 2 was easy. This was an improvement of the lunar gravity model that the Apollo 11 software also got (Comanche 55 to 55 revision 2) and had already been the subject of another reconstruction project (Apollo 10 LGC software, Luminary 69 to Luminary 69 revision 2). So yes, they built some rope modules three times for the Apollo 10 CMC...

Many thanks to thewonderidiot who did the majority of the work for this reconstruction!

#### kuddel

##### Donator
Donator
Wonderful! Please let thewonderidiot know how much I love the work he does. It's amazing!
And BTW, I'm always extremely impressed every time CuriousMarc releases an Apollo-Era video showing off some AGC (or related) discovery!

#### n72.75

Tutorial Publisher
Donator
Well, it's been a bug-fixing kind of week. Only bugs I've caused, so far, but one's fixed and the other's very close.

This one was easy to fix, and was caused by placing code needed to enable/disable the VHF ranging system on the LEM side after the "return" that only occurs in the low-bit rate mode of the PCM system. If you're in HBR you can turn it on and off, but in LBR it was stuck in whatever state it was last in, due the code never being executed. Resolution is here, and Build 1598 has the fix.

Also reacq mode wasn't working properly all the time. Here's a quick video demonstrating a fixed version. Need to do a bit more work before this goes live.

#### sw34669

##### Active member
In case anyone is interested, here's the output of the new fuel cell voltage model, rendered in Matlab (okay, Octave,):
The labeled contours show isopotentials across the cell terminals.

View attachment 23454

The data for this model comes from this figure (4.1-10 of the CSM Operational Databook):

View attachment 23453

If you're interested the model itself is:

C++:
loadResistance = (829.44) / (power_load); //829.44 = 28.8V^2 which is the voltage that DrawPower() expects. use this calculate the resistive load on the fuel cell
Volts = 31.0; //inital estimate for voltage

//coefficients for 5th order approximation of fuel cell performance, taken from:
//CSM/LM Spacecraft Operational Data Book, Volume I CSM Data Book, Part I Constraints and Performance. Figure 4.1-10
double A = 0.023951368224792 * Temp + 23.9241562583015;
double B = 0.003480859912024 * Temp - 2.19986938582928;
double C = -0.0001779207513 * Temp + 0.104916556604259;
double D = 5.0656524872309E-06 * Temp - 0.002885372247954;
double E = -6.42229870072935E-08 * Temp + 3.58599071612147E-05;
double F = 3.02098031429142E-10 * Temp - 1.66275376548748E-07;

for (int ii = 0; ii < 5; ++ii) //use an iterative procedure to solve for voltage and current. with our guess of 31 volts these should converge in 3~5 steps
{
Volts = A + B * Amperes + C * Amperes*Amperes + D * Amperes*Amperes*Amperes + E * Amperes*Amperes*Amperes*Amperes + F * Amperes*Amperes*Amperes*Amperes*Amperes;
}

My next project is adding ALL of the EPS radiators (we had 4, now we'll have all 8), and their glycol loops, and then some of the fuel cell internals: pressure regulators, reactant, pre-heaters, and a condenser on the H2 side. It's fairly complicated with a lot of interacting systems (NASSP uses a heavily modified version of @Radu094's SPSDK for its systems. Which is the same SDK upon which the Dragonfly is built), and some of it may get simplified if it's too unstable or resource intensive, or breaks time acceleration with stiff systems.
excellent stuff. I was reading the other day about the issues in running an AFCs in space ... what will this change in the model in how they are checklisted and managed on-board. Or is that done automatically by the controls built around the cells ?

#### n72.75

Tutorial Publisher
Donator
excellent stuff. I was reading the other day about the issues in running an AFCs in space ... what will this change in the model in how they are checklisted and managed on-board. Or is that done automatically by the controls built around the cells ?

It probably wont change much by way of checklists and procedures. If you were running a test case where you were simulating failures (when we impliment those for stuff like this), you would see more realistic temperatures. Adding and removing loads from the cells in a 2-cell or 1-cell operating scenario would also require careful timing to avoid transients and over/under-voltages.

As far as nominal operations, the goal is just more accurate behavior on the gauges and of course, I'm an engineer so I love making graphs of things, so better graphs, when we get a telemetry logger working.

Some of this is also facilitating starting the cells, cold-and-dark on the pad with GSE (this is a looong way off though).

#### indy91

A fairly large RTCC update is done. For quite a while the way MFDs are saving their data in scenarios has annoyed me, at least for the RTCC MFD. You have to have the MFD open or else it doesn't save. So if you save while in the outside view or on a panel that doesn't show the MFD all the data is lost. And if you have the MFD open multiple times when you close the simulation then the MFD data gets saved multiple times, which is unnecessary in most cases. To fix this I wanted a more permanent saving/loading solution. The solution I came up with is using the MCC vessel, which gets used by our MCC to permanently save numbers for its use.

So the way the MCC/RTCC is structured is that there is a RTCC class, which contains all the calculations and parameters of the RTCC. The MCC class (previously identical to the MCC vessel in the simulation) owns an instance of the RTCC class. The RTCC MFD also had an instance of the RTCC class, but it was its own instance, not shared with the MCC.

The way it works now is that there is a MCCVessel, which always has an instance of the RTCC and optionally an instance of the MCC class. The MCC instance is only loaded for the MCC scenarios. The RTCC MFD, when it is first opened, will check if there already exists a MCCVessel. If not, it gets created. All the relevant RTCC numbers are stored, saved and loaded in the RTCC class. So now, even if the MFD isn't open when the scenario is saved, the RTCC data is saved in the MCCVessel and nothing can be lost that way.

Because I didn't want to create multiple MCC vessels the instance of the RTCC class is actually shared between the MCC and the RTCC MFD now. I think this is a bit of a downside to this update as it is possible to screw up the MCC calculations by changing things in the RTCC MFD. I've tested a bunch and if you only do harmless things like uplinking a new state vector from the RTCC MFD then it doesn't mess up the MCC. But I guess we have to be slightly careful now if we use the RTCC MFD in MCC scenarios. Another issue I had was an output stream CTD caused by the RTCC MFD (in the RTCC MFD module) using the RTCC in the MCC vessel (MCC module) via a pointer. I had to change a build setting to make this work. Seems all fine now though.

With this update I also changed the MCC for Apollo 8 to use the latest TLI, LOI and midcourse correction calculation functions, so if you had an Apollo 8 mission in progress this update would break it. I created new scenarios up to LOI-2 so that the scenarios that come with NASSP aren't broken.

#### indy91

My update for Apollo 10 is done. A lot of MCC/RTCC changes, so old scenarios using the MCC are likely broken. I added mission scenarios, which we didn't have yet for Apollo 10, through docking after rendezvous. I'll add scenarios for the rest of the mission soon-ish. Also a few checklists fixes, but no major changes there.

Next up will be Apollo 11, which also still needs the same type of MCC/RTCC updates. Then I'll be able to delete old versions of the TLMCC, LOI and DOI processors in the RTCC. The RTCC MFD hasn't used those for a while now, but the MCC still did.

#### sw34669

##### Active member
After just arriving on the moon, the only thing i noticed that appears to be missing from the MCC pads is TLAND, needed, prior to PDI. There's the odd missing V2[12345]E for data entry but works well from Phasing->DOI->PDI->P64 ......

#### indy91

After just arriving on the moon, the only thing i noticed that appears to be missing from the MCC pads is TLAND, needed, prior to PDI. There's the odd missing V2[12345]E for data entry but works well from Phasing->DOI->PDI->P64 ......

Ah, there already is a sneaky TLAND uplink together with the DOI target load. I'll add it to the uplink message so that it becomes clear that it gets updated.

#### sw34669

##### Active member
thanks
You can see if people are really paying attention to spot these things. I guess a quick AGC read value would show it's set to something other than +00000 .
I've also noticed since arriving on the moon that descent O2 seems to be stuck, even when out of their suits and prior to EVA it didnt go down. It was going down prior to updating to the last version. Prior to EVA I had 2 CRW showing In Cabin.

#### sw34669

##### Active member
checked my save just before pdi before updating TLAND and it was set to zero (I had uplinked the last set off data from mcc)
i added the scenario to the other thread (scn filename Moon ........ 15 mins bef PDI)

#### indy91

I have also noticed very little O2 usage during certain mission phases. Not sure it's a bug, but I'll take a look, maybe I find the reason.

And about TLAND, that only gets uplinked to the LGC. In the AGS you always need to enter it manually. It also gets used differently between the two systems. The LGC needs it as an initial guess for the time of landing for the P63 ignition algorithm. And you type it into the DEDA to prepare a manual state vector update for the AGS on the lunar surface. So not really required in the AGS to make a safe descent.

#### sw34669

##### Active member
brill ! that's all i needed to know
the O2 usage is more visable now post EVA after refilling the cabin twice
it's still a sauna @ 100F+ with them unsuited and all the lights off
im going to have a few PDIs today

#### sw34669

##### Active member
small glitch on the ascent lm checklist missing N46

#### indy91

So a "F 01 46" is missing, got it. I'm making my way through the Apollo 11 mission anyway, I'm up to lunar liftoff prep. Changing a bunch of MCC stuff and replacing the old mission scenarios as they will be broken. And I'm doing some minor checklist work like this!

#### sw34669

##### Active member
that's fab thanks. There's very little that's wrong. I'm just getting going with ascent execution atm.

#### Urwumpe

##### Not funny anymore
Donator
So a "F 01 46" is missing, got it. I'm making my way through the Apollo 11 mission anyway, I'm up to lunar liftoff prep. Changing a bunch of MCC stuff and replacing the old mission scenarios as they will be broken. And I'm doing some minor checklist work like this!

Can't you use the checklists as some sort of automated "acceptance test" for NASSP?