Meadville Space Center
Welcome, Guest. Please login or register.
December 14, 2019, 06:36:25 AM

Login with username, password and session length
Search:     Advanced search
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 News & Discussion
| | |-+  Support & Bugs (Moderators: movieman, Tschachim, Swatch, lassombra)
| | | |-+  Apollo 7 Beta Testing Bugs
« previous next »
Pages: 1 ... 5 6 [7] Print
Author Topic: Apollo 7 Beta Testing Bugs  (Read 11052 times)
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #90 on: January 10, 2017, 10:33:12 AM »

I've done some testing with different AGC versions, just for V67 input parameters and scaling, and these are my results so far:

Artemis072 and Comanche055 source code is wrong about the scaling of WRENDPOS and WMIDPOS. Both are scaled as meters *2^-19 and not 2^-14. So the values and padloads are then:

WRENDPOS and WRENDVEL: 10,000 ft and 10 ft/s. Scaled: 137 and 763
WMIDPOS and WMIDVEL: 30,000 ft and 30 ft/s. Scaled: 436 and 2732

These padloaded values are now in agreement with the Apollo 16 G&C Checklist Backup Erasable Load Update. The scenarios have been using the the correct values before, but now I can also use the correct engineering values in the Pad Load Worksheet. Also note that Luminary uses the same engineering values for WRENDPOS and WRENDVEL, but a different scaling for WRENDPOS.

Colossus237 and Colossus249 are a total mystery to me. The scaling for both WRENDPOS and WRENDVEL are different than in later versions. I tend to believe the Apollo 8 CMP checklist that R1 in Noun 99 is in 0.01 Nautical Miles. This is true until Comanche055, for which there is a Program Change Request to change the values in V67 to ft and ft/s. But how the scaling works, no idea. I guess I have to test it some more. For example, when I use +01000, +00100 and +00001 in V67 then WRENDPOS and WRENDVEL become 516 and 440. Makes no sense really when I take the scaling in the source code, but also not really when I assume NM and ft/s as the units.
Logged
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #91 on: January 10, 2017, 11:24:20 AM »

I've just tried around a little and settled to:
N99
R1 +00020
R2 +00010
R3 +00001

R1 makes some sense to me - 2 NM are about 12000 ft. R2 doesn't have such a big effect as it seems. dV/dR settle as quick with 1 fps as with 10 fps. The dV for the first mark is just bigger, that is all. All in all, the more the marks, the better. I made 60 marks for fun and in the end the CMC put the SIVB right in the middle of the crosshairs -not that I recommend such a 'gun fight'. Wink
Sequence with V67 is always V67 - enter data - V93. Otherwise the w-matrix remains unchanged. Oh, and no, don't do a V93 after P34 -messes up big time...
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #92 on: January 10, 2017, 03:09:08 PM »

+00020 would be 0.2 NM and not 2.0 NM, but I understand what you mean.

I tried these values and I got a good TPI phase, the same behavior that I have always been getting before. TPI was about 1 ft/s short of the PAD value and I got pretty large MCCs. 10 ft/s for MCC1, 6 ft/s for MCC2. I wonder, is the "phoney" S-IVB mark really necessary in Colossus? Does it maybe throw off the S-IVB state vector? The Apollo 11 CSM Rendezvous Procedures uses a V93 for MCC1 and MCC2, each time when P35 was just started up. But the Apollo 7 rendezvous first updates the S-IVB state vector and then in P35 the CSM state vector, while during a normal lunar rendezvous always the LM state vector was updated. So there might be a difference. I also remember that I got 10 ft/s MCCs half of the time or more, but quite often I almost had to do no MCCs at all.

I will test some more what went wrong for me earlier, try to find the scaling for the rendezvous W-Matrix values and then maybe change the initialization parameters in the launch scenario or maybe just add a V67 in the Checklist MFD rendezvous procedures. At least a V93 should be done.
Logged
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #93 on: January 10, 2017, 04:01:57 PM »

Quote
+00020 would be 0.2 NM and not 2.0 NM, but I understand what you mean.
Okay, then it's 1200 ft, almost those 1000 ft the rendezvous doc prescribes.
Quote
I wonder, is the "phoney" S-IVB mark really necessary in Colossus?
Nope. I guess it was made test if marking on the wrong SV (being 'phoney') would lead to bad dV/dR, so that such a mistake could be recognized. When I remember right, the dV/dR on that mark should be rejected, so the LM SV doesn't get messed up.
Quote
But the Apollo 7 rendezvous first updates the S-IVB state vector and then in P35 the CSM state vector, while during a normal lunar rendezvous always the LM state vector was updated.
Of course. You'd always update the SV of the vehicle that has actually performed the maneuver. During a normal rendezvous, the LM would do all the burns, so that SV had to be updated.
Quote
The Apollo 11 CSM Rendezvous Procedures uses a V93 for MCC1 and MCC2, each time when P35 was just started up.
Really? The flight plan doesn't mention it. Artemis' MINKEY doesn't do it either, AFAIK.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #94 on: January 10, 2017, 04:24:11 PM »

Quote
I wonder, is the "phoney" S-IVB mark really necessary in Colossus?

Nope. I guess it was made test if marking on the wrong SV (being 'phoney') would lead to bad dV/dR, so that such a mistake could be recognized. When I remember right, the dV/dR on that mark should be rejected, so the LM SV doesn't get messed up.

Absolutely right! The V32 to reject that mark is even in the rendezvous procedures document. I did it wrong all along.

Quote
Quote
The Apollo 11 CSM Rendezvous Procedures uses a V93 for MCC1 and MCC2, each time when P35 was just started up.

Really? The flight plan doesn't mention it. Artemis' MINKEY doesn't do it either, AFAIK.

The Apollo 12 CSM Rescue Book has the V93. Seems like you almost always do a V93, V57, V87 in this order at the beginning of a normal marking sequence. V87 allows VHF range to be processed.

When and how to do a V93 is one of the more complicated aspects of MINKEY. Read from page 5.2-83 here: http://www.ibiblio.org/apollo/Documents/HSI-208454.pdf
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #95 on: January 10, 2017, 08:18:53 PM »

Holy crap, been doing it wrong the whole time, too. LOL I didn't know I had to reject the phony mark after making it. I thought it just drove the state vector to the limits of the W-Matrix, and subsequent markings re-stabilized it.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #96 on: January 11, 2017, 07:06:47 AM »

Don't get your hope too much up, there still is Average G and the CSM and S-IVB state vectors shouldn't be too bad after TPI anyway, even without more marks. I just haven't been too careful with the "phoney" mark in the past. But now I at least know the procedure: do the single S-IVB mark, wait 15 seconds for processing, PRO, wait until the 16 49 comes up, reject with V32E, then V81E, V57E and then the normal marking sequence is done.

EDIT: I found the scaling of the W-Matrix initialization parameters! There is an additional factor that I managed to find in the source code. That factor is 1/sqrt(3), which is about 0.57735. If I then take the parameters I used for testing then the register 1 +01000 is 10.00NM and scaled 516, register 2 is 10 ft/s and 440 scaled. And just like the later AGC versions the basic scaling is not 2^-14 for the positions but 2^-19. I'm not sure if I can ever trust AGC source code again. This scaling also applies to the P22 and P23 parameters in C237 and C249.

If I then reverse engineer the rendezvous parameters used before then I get about 29000 ft and 17 ft/s. That's probably a bit much. The suggested parameters for Apollo 10 (I have no other source than a Tindallgram for that) are 10000 ft and 10 ft/s. I will try if these parameters are any good. And then for the last marking sequence we know that the parameters were changed to 1000 ft and 1 ft/s. So if everything works out then I'll add that change (no V67, directly in the erasable memory) as well. Also, all the scenarios I have created so far have to be changed as well. It's only two EMEMs, so not too bad.
« Last Edit: January 11, 2017, 08:37:05 AM by indy91 » Logged
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #97 on: January 11, 2017, 08:51:03 AM »

Quote
This scaling also applies to the P22 and P23 parameters in C237 and C249.
...but those are good? Don't forget that there are such thingies like ALTVAR and INTVAR, too...
BTW, do you understand how this ranging thing works (hardware-wise, I mean)? The CMC has 4 bits in output channel 13, obviously to tell the range unit what to do -but how does the actual range get into the CMC? There is no input channel or such for it. Confused
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #98 on: January 11, 2017, 09:30:49 AM »

Quote
This scaling also applies to the P22 and P23 parameters in C237 and C249.
...but those are good? Don't forget that there are such thingies like ALTVAR and INTVAR, too...

The rendezvous parameters were also good in the past. I have the feeling that I still don't know the actual problem with my scenario...

Quote
BTW, do you understand how this ranging thing works (hardware-wise, I mean)? The CMC has 4 bits in output channel 13, obviously to tell the range unit what to do -but how does the actual range get into the CMC? There is no input channel or such for it. Confused

There are a few input and output bits, but the actual range is shifted to register 46 (RNRAD) when the CMC requests it.
« Last Edit: January 11, 2017, 09:32:56 AM by indy91 » Logged
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #99 on: January 11, 2017, 05:33:43 PM »

Quote
There are a few input and output bits, but the actual range is shifted to register 46 (RNRAD) when the CMC requests it.
Okay, who would look there...
After some tests, I don't object against V93E after each maneuver. It doesn't hurt on one hand; doesn't improve SV accuracy significantly on the other. Zero-sum game IMHO.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #100 on: January 12, 2017, 12:55:14 PM »

I've finally settled for the rendezvous parameters. They are 1000 ft and 1 ft/s. 10x these values as the initial numbers don't work too well. I have pushed the update: Pad Load Worksheets with the now known scaling, a revised Apollo 7 Checklist MFD file, I fixed all Apollo 7 scenarios to have the new parameters and I added three new scenarios.

Now that this rendezvous madness is over I can finally return to creating the release scenarios. Those will take a while and if nobody wants to fly a Apollo 8 mission good enough to be without errors for the release, then I will do Apollo 8 after that.
Logged
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #101 on: January 13, 2017, 02:10:55 PM »

I just tried V87 just for fun. Seems to lead to some sort of 'hang up' -the CMC won't process any marks after that. I guess R22 gets stuck in a loop of some sort, as there is a 'data good' discrete, but no range in RNRAD. I suggest we set (inverted logic!) Bit 2 of channel 33 permanently for now, so that everybody who tries V87 gets what he deserves: the TRACKER light! Wink
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #102 on: January 14, 2017, 11:00:33 AM »

I know this is a trivial point but for the sake of realism and continuity, shouldn't Apollo 7 and 8 EMS on CSM/LV SEP be set to zero and not -100?  I know they changed it in later missions because of sudden, erroneous jump but of course our sim does not have that.  Just a thought Happy
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #103 on: January 14, 2017, 11:20:00 AM »

Sure. If you want to fix it, here a link to the new Apollo 8 TLI checklist: https://drive.google.com/open?id=0BzUu_aREm1xSN2VWeE5ub2x3Zjg I'll fix it in the Apollo 7 checklist.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #104 on: January 14, 2017, 11:24:15 AM »

Sure. If you want to fix it, here a link to the new Apollo 8 TLI checklist: https://drive.google.com/open?id=0BzUu_aREm1xSN2VWeE5ub2x3Zjg I'll fix it in the Apollo 7 checklist.

Oh wonderful!  I will check through our 8 procedures and make any necessary changes Happy
Logged
Pages: 1 ... 5 6 [7] 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!