Meadville Space Center
Welcome, Guest. Please login or register.
July 05, 2020, 04:17:34 PM

Login with username, password and session length
Search:     Advanced search
Project Apollo - NASSP 6.4.3 released!
http://nassp.sf.net
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development
| | |-+  Programming (Moderators: movieman, dseagrav, Swatch, lassombra)
| | | |-+  Non-mission-specific EMEMs for Colossus 249
« previous next »
Pages: [1] Print
Author Topic: Non-mission-specific EMEMs for Colossus 249  (Read 4870 times)
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« on: May 15, 2012, 11:00:45 AM »

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?

AZO
EMEM1711 30636
EMEM1712 33227
Earth's azimuth (279,115422 deg). Constant in Orbiter, thus non-mission specific.

AYO,AXO
EMEM1713 to 1716 all 0
earth's precision and nutation. Orbiter's earth doesn't have that.

EMSALT
for LEO entry:
EMEM2017 2
EMEM2020 24622
for lunar entry:
EMEM2017 2
EMEM2020 30420
Altitude when 0.05g occurs. 284843 ft resp. 297431ft. Those are the original values, not tested in orbiter. Should work, anyway.

TVC/DAP
EMEM3012 5
EMEM3013 200
EMEM3014 100
EMEM3015 0
EMEM3016 30000
EMEM3017 2000
EMEM3020 20000
EMEM3021 500
EMEM3022 4000
EMEM3023 1000
EMEM3024 1000
EMEM3027 10000
EMEM3030 75024
EMEM3031 47207
EMEM3032 1066
EMEM3033 33013
EMEM3034 77705
EMEM3035 61340
EMEM3036 57377
EMEM3037 74664
EMEM3040 14414
EMEM3041 36243
EMEM3042 74624
EMEM3043 73117

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?

DVTHRESH
EMEM1353 632

AFAIK the 'engine fail' threshold; CMC will switch to engine fail routine if DVTHRESH isn't attained after engine on command + some (very short) time.

LADPAD,LODPAD,ALFAPAD
EMEM3007 6632
EMEM3010 3146
EMEM3011 74344

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

HORIZALT
EMEM1354 0
EMEM1355 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,WRENDVEL
EMEM2000 240
EMEM2001 754

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

RMAX,VMAX
EMEM2002 77776
EMEM2003 77776

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

WORBPOS,WORBVEL
EMEM2004 1750
EMEM2005 3146

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

ATIGINC
EMEM2021 0
EMEM2022 21450

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

PTIGINC
EMEM2021 0
EMEM2022 21450

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

WMIDPOS,WMIDVEL
EMEM3000 5161
EMEM3001 311

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

YACTOFF,PACTOFF
EMEM3025 0
EMEM3026 0

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

ECSTEER
EMEM3424 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.

CDUCHKWD
EMEM1341 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:

EMDOT
EMEM0110 ?
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?

RPVAR
EMEM2007 ?

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

RVAR,RVARMIN
EMEM3002 ?
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:?


ALTVAR
EMEM1356 ?

'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:?

INTVAR
EMEM2177 ?

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:?

S22WSUBL
EMEM2006 ?

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.

504LM
EMEM2011 ?
?
?

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?

The whole IMU compensation stuff (SFE,BIAS,ADIA,ADSRA,NBD)
Do we need that? I don't know anything about our IMU...


Others, but known to me and yet to be determinated:

POLYNUM,SATRLRT,RPSTART,POLYSTOP

Saturns roll/pitch programm in CMC language. I won't change anything on them, facing the dawn of LVDC++.

Edit: I'm currently digging around in literature, so this post was and will be subject to edits. So don't wonder. Wink
Edit2: Gets ahead quite fast. Happy 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?
« Last Edit: May 17, 2012, 12:03:12 PM by meik84 » Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #1 on: May 15, 2012, 01:41:57 PM »

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?

Concur!  Very Happy
Logged

Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #2 on: July 12, 2012, 07:12:25 AM »

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

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

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

Cheers
Tschachim
Logged

meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #3 on: July 13, 2012, 11:54:01 PM »

Quote
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.
« Last Edit: July 14, 2012, 08:09:33 AM by meik84 » Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #4 on: July 14, 2012, 06:15:41 PM »

Edit: Double check: the calculation goes
Code:
(<memory bank> - 3) * 400 + <subaddress>(all octal)
right? So that E4,1417 leads to 2017, right?
See for example ApolloGuidance::GenericWriteMemory:

   bank = (loc / 0400);
   addr = loc - (bank * 0400);

so I think it's without the "- 3", the maximum address within a bank is 0400.

Similar stuff is in CSMComputer:Timestep, the are helper functions for the reverse way, for example:

   vagc.Erasable[AGC_BANK(AGC_DAPDTR1)][AGC_ADDR(AGC_DAPDTR1)] = 011102;

Quote
Does our IMU drift? Do the PIPAs and IRIGs have any bias?
No, the IMU doesn't drift nor has any bias.

Quote
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.
New EMEMs are always welcome!  Happy

Cheers
Tschachim
Logged

meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #5 on: July 15, 2012, 12:04:02 PM »

Quote
See for example ApolloGuidance::GenericWriteMemory:

   bank = (loc / 0400);
   addr = loc - (bank * 0400);

so I think it's without the "- 3", the maximum address within a bank is 0400.
Got it: it's with the '-3'. The first 3 EMEM banks are addressed directly (addresses 0000 to 1377), the other 4 are bank-switched to addresses 1400 to 1777, depending on the EB register. See here:http://www.ibiblio.org/apollo/MirkoMattioliMemoryMap.pdf
Quote
No, the IMU doesn't drift nor has any bias.
Why then do we have torquing angles when we do P52? Confused
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #6 on: July 15, 2012, 12:51:00 PM »

Why then do we have torquing angles when we do P52? Confused
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.
Logged

meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #7 on: July 15, 2012, 01:36:12 PM »

Ah. Happy Too bad we don't know how they determined the bias during flight like they did for AP9. Would be quite an interesting thing...
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #8 on: January 15, 2016, 03:58:26 PM »

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.

RTED1
EMEM1351 6510
EMEM1352 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.

CDUCHKWD
EMEM1341 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.

S22WSUBL
EMEM2006 471

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

INTVAR
EMEM2377 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,ALFAPAD
CMPAD3007 11463
CMPAD3010 5605
CMPAD3011 74344

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

ATIGINC,PTIGINC
EMEM2021 1
EMEM2022 3120
EMEM2023 1
EMEM2024 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.

TVC DAP
EMEM3012 5
EMEM3013 123
EMEM3014 175
EMEM3016 17433
EMEM3017 4500
EMEM3020 4
EMEM3021 1130
EMEM3022 10000
EMEM3023 1000
EMEM3024 232
EMEM3027 10000
EMEM3030 75024
EMEM3031 47207
EMEM3032 1066
EMEM3033 33013
EMEM3034 77705
EMEM3035 61340
EMEM3036 57377
EMEM3037 74664
EMEM3040 14414
EMEM3041 36243
EMEM3042 74624
EMEM3043 73117

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.
Logged
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!