I have problems with p22 Apollo 8

[Sverige]

I have problems with p22 apollo 8. I think I'm doing right but I can't get the landmark tracking auto of CP-2 to follow and when I do it manually I get completely wrong coordinates. This also applies to psedo landmark tracking of B1. The first landmark tracking worked great but I think something bugged during the journey around the moon. I have tried to do a manual state vector uplink from RTCC but this has not helped. Any suggestions?

/Mikael

---------- Post added at 07:19 PM ---------- Previous post was at 08:47 AM ----------

Indy?

 

[indy91]

So you have already done a P22 in lunar orbit and now the second one turned out bad? That does sound somewhat familiar. I think it has to do with the W-Matrix, but I am not sure what to do there. But if even a manual SV uplink didn't help that is quite weird. If you post your scenario I can take a look.

 

[Sverige]

Thanks! Yes, it worked at 76:05:00 but not at 79:25:00 CP1 and 80:00:00 B1. Do you mean the quicksave file?

 

[indy91]

I uplinked a new state vector and did a P21 as a test, with good results. So at least your CMC isn't horribly broken. I'll test more with it tomorrow.

 

[Sverige]

I uplinked a new state vector and did a P21 as a test, with good results. So at least your CMC isn't horribly broken. I'll test more with it tomorrow.

:tiphat::thumbup:

 

[indy91]

I also get a program alarm in your scenario when I do a V37E 00E, alarm 421, "W-Matrix overflow". The W-Matrix is always annoying to work with, I've had very inconsistent results because of it in the past. It's essentially a measure of how likely your state vector is in error. Did you do P23s earlier in the mission? It might have to do with that, although I couldn't tell you what to do differently.

I would suggest doing a V93E before your next P22, that will reinitialize the W-Matrix and hopefully help. But what you are describing is something I had many times during Apollo 7 Earth landmark tracking. First P22 gave good results, nearly zero errors. But then the second one gave pretty large errors and if I just kept coasting with no more P22s I eventually get that 421 alarm.

 

[Sverige]

Thank you for your detailed response. I really appreciate it! I did a lot of p23 on the way to the moon so maybe this is the problem. I will try previously saved files and of course V93E.

/Mikael

---------- Post added at 02:31 PM ---------- Previous post was at 12:59 PM ----------

Can you still go home with a corrupt W-Matrix? V93E didn't help me. Can I make correct TEI with p40 with a p30 data uploaded with MCC?

/Mikael

 

[indy91]

A state vector uplink always fixes the W-Matrix as it gets completely reset, I think. So there should be no other issues after that. And it's not that P23 is a problem, it will just over time, without any more P22s or P23s or state vector uplinks, assume that the state vector is in error and eventually will give that 421 alarm. In most checklists the desired action for that alarm is a SV uplink.

 

[Sverige]

Could I be wrong with RTCC, or? I use the parameters TGT = AS503, TIM = current time, SLT = CSM nav update to CSM (276) then upload. Maybe I should do an update just before p22?

/Mikael

 

[indy91]

Before uplinking press the CLC button to generate the uplink data. That will update the numbers on that MFD page, including the octals, so you can check on the DSKY if the right numbers are going into the computer. If you didn't do that you probably uplinked all zeros or random numbers to your AGC. :lol: That additional step was added when I reworked all the uplinks and made them its own category in the MFD. Maybe there should be a check if the uplink data has already been generated and not allow the uplink of empty data.

 

[Sverige]

I did CLC

/Mikael

 

[indy91]

I don't think you really have a state vector issue in your scenario. You only have a W-Matrix issue. I did a P21 check with and without state vector uplink and both looked ok.

Also, your OPTICS TEL TRUN switch is in the 25° position, so your telescope will have a constant angle and not be driven together with the sextant to the position that the CMC wants. Maybe that's part of the problem?

I just did a P22 with your scenario. I got the W-Matrix overflow again (despite doing a V93, hmm...) but I got a good result in general. The 06 49 display was DR +00005 and DV +00018 for me.

 

[Sverige]

No, the OPTICS TEL TRUN switch is not the problem. I always put it in the normal position before p22 (I think). I also get good DR and DV results (06 49) but 06 89 does not match the information in "LUNAR LANDMARK LOCATIONS -
APOLLO 8, 10, 11, AND 12 MISSIONS "and thanks for your help almost like Houston:lol:.

/Mikael

 

[indy91]

Ah, I didn't actually bother looking at N89, I really should have. N89 is showing longitude divided by 2, but I guess you knew that as well. I'll try again to see if I also get a N89 that is off.

 

[Sverige]

Ah, I didn't actually bother looking at N89, I really should have. N89 is showing longitude divided by 2, but I guess you knew that as well. I'll try again to see if I also get a N89 that is off.

Yes i know. I you have time do a test. also try auto on B1 (10001) 5 70.

---------- Post added at 06:42 PM ---------- Previous post was at 06:35 PM ----------

For information I have confirmed the position C1, C2, C3 and B1 using virtual moon atlas. So I've been tracking the right landmark.

 

[indy91]

Well for CP-2 it gave me back exactly the same coordinates as I had entered, which I find suspicious. More suspicious than if they had been off by a larger amount. What I also find weird is that the coordinates in the flight plan and in the document you were mentioning aren't the same.

Flight Plan:
10.2°S, 155.1°E

Lunar Landmark Locations:
9.7°S, 163.2°E

So that's already weird and not really helpful for comparisons. I guess what should be the measure for a successful P22 is the lat/long it gives you back, but something can't be right if it gives you exactly the same coordinates back. I think.

 

[Sverige]

Weird things happen. This time everything works as it should. I did a manual update of state vector just before p22 and then no time acceleration:thumbup:

 

[rwitham]

Hello,

I'm at MET 76:05:00 and attempting to perform the P22 procedure. I've read through this thread and I'm confused about where landing site information is coming from. Is there a document I'm not aware of? How would I know what B1 looks like?

Thank you

 

[indy91]

The CMC has a landing site vector loaded in its memory. If you use the code 10001 in P22 then instead of taking manually input landmark coordinates it will use that vector for the tracking. See the Apollo 8 CMP Checklist, PDF page 16, "P22 - Orbital Navigation (LDG Site - Auto Optics)".

The document that would be most helpful for the landmark tracking is the Lunar Landmark Maps. We don't have that for Apollo 8 unfortunately, the Smithsonian has the original and shows two pages of it here: https://airandspace.si.edu/collection-objects/maps-lunar-landmark-apollo-8/nasm_A19770578001

The document that Sverige mentioned has a few descriptions of the landmarks used on Apollo 8, 10 and 11: https://www.hq.nasa.gov/alsj/tnD6082_LandmarkTrackingAp8-10-11-12_1971002567.pdf That is probably quite helpful in locating the landmark to track.

This is how a more complete version of that document would look like, from Apollo 12: https://www.hq.nasa.gov/alsj/a12/A12_CSM_Landmarks.pdf

 

[Sverige]

I'm on my way home to earth so I get to do some more tests with Apollo 10. Most of the p22 has worked well with the exception of the use of code 10001 in P22. I'm wondering if I've done a 10001 re-encoding? Is this possible? How to change or update the landing site code (10001) in p22?

/Mikael