As already stated, it is deemed necessary to standartize the non-mission-specific EMEMs for Colossus 249. I took a look and made out the following (any remarks and/or corrections are welcome):@Tschachim: I consider to put those on a extra sheet in the .xls and leave the others on the resp. mission tap. Concur?

The whole TVC/DAP config stuff, works well with CSM alone. No idea what happens when we add the LM, though. Those are the values from the .scn, the .xls says different for some. Does anybody know the reason for that?

Presettings for entry DAP. Figured out by me some time ago. Work quite good.

HORIZALTEMEM1354 0EMEM1355 21450

P23's horizon altitude, i.e. the distance between the point the astronaut marks on and the 'real' horizon. This is Jim Lovell's value he used on AP8. Could be refined a little, but works.

WRENDPOS,WRENDVELEMEM2000 240EMEM2001 754

Initial settings for P20's w-matrix. No source known, but any small value <> 0 is good (0 would render P20 inoperative).

RMAX,VMAXEMEM2002 77776EMEM2003 77776

Thresholds for FL V06N49. Set to some very low value, so that every mark leads to N49.

WORBPOS,WORBVELEMEM2004 1750EMEM2005 3146

P22' w-matrix. Same problem as for P20, same 'solution'. Delco suggests 0 for both.

ATIGINCEMEM2021 0EMEM2022 21450

P35's time from final pass to TPM-burn. 90 sec seemed a good value.

PTIGINCEMEM2021 0EMEM2022 21450

P75's time from final pass to TPM-burn. Again, 90 sec seemed a good value.

WMIDPOS,WMIDVELEMEM3000 5161EMEM3001 311

P23's w-matrix. See WORBPOS & co.

YACTOFF,PACTOFFEMEM3025 0EMEM3026 0

SPS trim angles. Both 0, as our SPS engine has no offset from CSM's center of mass.

ECSTEEREMEM3424 0

Cross product steering constant for P31. Range from -4 to +4. See GSOP 5.3-24 for further info. We don't use P31, so I recommend leaving it 0.

CDUCHKWDEMEM1341 0

SXTMARK CDU CHECK DELAY. Used in R53. When not 0, CMC will check after mark button has been pressed and the time defined in CDUCHKWD has elapsed if optic CDUs have changed by more then 3 bits. If yes, alarm 121 is issued and R53 exits. This is some sort of CDU operational test. Our CDUs can't fail, so I recommend 0.

Obviously non-mission specific, but still unkown to me:

EMDOTEMEM0110 ?EMEM0111 ?!

SPS flow rate, i.e. the mass lost during 1 sec of SPS burn. 7 and 8 have EMEM0110 1116 in the .scn, but the .xls offers EMEM0111(sic!) 1116 for 7 and EMEM0110 1045 & EMEM0111 34325 for 8. Anyone any idea?

RPVAREMEM2007 ?

'Variance of the primary body radius error', to quote GSOP 5.2-52. Used by P22. Suggestions?

RVAR,RVARMINEMEM3002 ?EMEM3003 ?EMEM3004 ?

RVAR is the 'range error variance corresponding to a percentage error' and RVARMIN is the 'minimum range error variance'(GSOP 5.2-78). Used in P20 for the VHF ranging. Delco: 0 for RVAR, (200 ft)² for RVARMIN. Scaling:?

ALTVAREMEM1356 ?

'A priori estimate for the angular error variance of an alternate line-of-sight measurement per axis'(GSOP 5.2-83). Used in P20 when the SXT isn't used for marks on the LM. Delco: (3.9mrad)². Scaling:?

INTVAREMEM2177 ?

According to GSOP 5.2-77 is this the variance of the coasting integration error, i.e. how good the coasting integration routine of the SVs works. Delco says: (14 m) ². Scaling:?

S22WSUBLEMEM2006 ?

Third diagonal component of P22's w-matrix. I guess this depicts the error in the landmarks altitude. 0 is no good, I presume the same scaling as WORBPOS and WORBVEL. Delco says 10000m as a value. Still got to find out the scaling, though.

504LMEMEM2011 ???

Moon's libration vector(GSOP5.5-16). This has to be a vector, so we need 3 adresses and not 1. Values unkown. Do we need them, anyway? Does orbiters moon have any libration?

Edit: I'm currently digging around in literature, so this post was and will be subject to edits. So don't wonder. Edit2: Gets ahead quite fast. Only 7 EMEMs left; rough values for all but one of them.Edit3: I dug around in the code a bit and found out that obviously some adresses are completely wrong and some are shifted by 1. Am I reading the code wrong or is the .xls wrong?

Great job, a long list, it will take a while for me to check that, but in general the scenarios are better than the Excel, sometimes denoted in the Excel, look for comments in red like "Values are partially missing, see scenario for correct data!" etc.

Quote

@Tschachim: I consider to put those on a extra sheet in the .xls and leave the others on the resp. mission tap. Concur?

Edit3: I dug around in the code a bit and found out that obviously some adresses are completely wrong and some are shifted by 1. Am I reading the code wrong or is the .xls wrong?

Since the code settings are working fine, the .xls is wrong in case of differences. You might want to correct the .xls in this case.

Quote

The whole TVC/DAP config stuff, works well with CSM alone. No idea what happens when we add the LM, though. Those are the values from the .scn, the .xls says different for some. Does anybody know the reason for that?

The .xls is wrong as mentioned before. Some of these settings are used for the CSM alone, some for the CSM/LM stack. The settings for the CSM/LM stack are NOT tested and most probably need fixing.

The SPS flow rate in the scenario should be quite fine and is calibrated for our flow rate.

About the P2x stuff I've no clue...

The POLYNUM,SATRLRT,RPSTART,POLYSTOP settings are for the FDAI error needles during launch, they are mission specific, the Apollo 7 scenario settings shouldn't be too bad at least.

I don't think we need the IMU compensation stuff, AFAIR we don't have/use these settings at the moment?

In general, if you put the non-mission specific EMEM settings of the Apollo 7 scenario to the code, you can't do anything wrong, at least not for Apollo 7 and about the other missions I don't case at the moment.

Please tell me if you change any value for Apollo 7, so I can check them just in case...

Since the code settings are working fine, the .xls is wrong in case of differences.

I'm just not sure if I'm calculating the addresses in the right way. The assembler code lists them in the format <memory bank>,<subaddress>, but we need the absolute address in the .scn.Edit: Double check: the calculation goes

Code:

(<memory bank> - 3) * 400 + <subaddress>(all octal)

right? So that E4,1417 leads to 2017, right?

Quote

I don't think we need the IMU compensation stuff, AFAIR we don't have/use these settings at the moment?

That's why I'm asking. Does our IMU drift? Do the PIPAs and IRIGs have any bias? I haven't programmed the IMU simulation, so I can't tell.

Quote

Please tell me if you change any value for Apollo 7, so I can check them just in case...

I guess I'll do an update with what I have in the nearer future, when I'll find some time. For most of the unsolved EMEMs we just need the scaling, so that's just a question of some code digging.

I should have said it differently: We don't simulate any drifting or bias explicitly to simulate the original behaviour, but there are attitude and acceleration errors, for example because of differences between the real universe and Orbiter's universe (Jarmo fixed most of them) or because of the discrete timestep handling of the simulation. But I don't think this is something we can or should compensate with these EMEMs.

This seems like the appropiate thread. For the past few months I have been always a little bit working on updating the Pad Load Worksheet, because I wanted to have the most recent values in one place. That will be ready soon. I've also started work on an Apollo 9 padload and there should be a launch scenario with a quite complete CSM padload soon, too. By doing some detective work on the Erasable Load Updates from the A15/16 G&C checklists documents I found some additional information about some padloads. For every padloaded values I have looked at the source code of the different AGC versions to make sure the memory addresses are correct for C249.

RTED1EMEM1351 6510EMEM1352 7025

The coefficient for the polynom defining the reentry angle in P37. Both erasable updates use the value 1.6602637, which is close to the one we use for A8.

CDUCHKWDEMEM1341 5

Not sure if this a CDU failure test or simply if the spacecraft is rotating too much for accurate measurements. We can leave it at 0 I guess.

S22WSUBLEMEM2006 471

With the scaling of 2^-14 this would be 313m.

INTVAREMEM2377 142

Our launch scenarios have this as CMPAD2177 set to zero, but I don't think that is correct. "E4,1777" should be EMEM2377, right? The Delco is right about the value, it is (14m)^2 and the scaling 2^-15. The GSOP says about this variable: "The variable INTVAR is included in Eq. (2. 5. 9) for the purpose of smoothing the effects of coasting integration inaccuracies." This is a property of the coasting integration routine so we probably want to use it. Would be quite interesting to see if this has any effect on the measurement incorporation during rendezvous. W-Matrix takes longer to get to zero? Any other effects? Only testing will tell...

The other variables aren't too interesting for us, I think, or not relevant for Colossus249. Just to collect the information in one thread, there are some other parameters that have been or will be changed in comparison to the original post here:

LADPAD,LODPAD,ALFAPADCMPAD3007 11463 CMPAD3010 5605 CMPAD3011 74344

With the improved aerodynamics the comment values (0.3, 0.18 and -20° respectively) now work very well.

ATIGINC,PTIGINCEMEM2021 1EMEM2022 3120EMEM2023 1EMEM2024 3120

180 seconds instead of 90 seconds because P35 is slow... well, mostly because we don't use the Apollo 7 AGC and Colossus249 tries to be more precise and so takes longer to calculate the MCC.

The new values which make the CSM/LM stack work. Now, the old TVC parameters do still work for Apollo 7 and 8 and therefore there isn't really a need to change the values in those scenarios. Only the CSM steering gain should probably be changed to the (historically correct) lower value; the old gain was adjusted to work perfectly before I messed with the CSM moments of inertia.