AGS vs PNGS Rate of descent disagree on low altitude Descent Abort

[replicant]

Let me preface by saying this is an excellent project. It's unbelievable what you guys are offering for free. Thank you.

As someone else stated, I am going down the AGS rabbit hole now. I like to think I have thoroughly studied the physics, systems and manuals so that I am not just a monkey flipping switches. Attached is my Apollo 16 PDI scenario. The cabin is nice and comfy, antennae are tuned, and a PGNS guided descent, landing and/or descent abort go flawlessly. However, the abort insertion for an AGS descent abort is always high at apolune (I did read the thread about APS cant). 315 and subsequent 337 readout place it at 63NM (which would be correct and is what the AGS believes) but it's actually about 85 NM. So, using the wonderful Rosetta stone of the supplied Apollo 17 PDI, I noticed one important discrepancy. During PDI all the way down to about 2000 ft AGL, the PGNS, radar, and AGS ALT agree within +/- 2000 feet. The RATE of descent all agree within within about 5 to 10 fps. An easy 223 update of +00020 makes an AGS descent abort work perfectly. Unfortunately, in my scenario, AGS and PNGS ALT and ALT rate agree very closely until about 5 mins in. Shortly after V57E and about 5:10, the AGS and PGNS rate of descent diverge sharply. By the time 15,000 feet is reached, the PGNS and radar agree that ROD is about 90 fps, but flipping the switch to AGS it thinks ALT is zero and the ROD is 220fps! So this must be the culprit, something is wrong or not setup correctly by me in that accelerometer for the strapped down gyro. Either a scaler isn't right or I did something wrong. Obviously this disagree negatively impacts ascent trajectory and orbit since the climb rate that the AGS believes and the actual diverge as well. Here is the scenario. Thanks.

Edit. Those numbers were a little off. They are about 5000 ft AGL. At 15,000 ft AGL , PGNS ROD is about 220fps and AGS ROD is 330 or 340 fps.

 

[rcflyinghokie]

Some of the divergence you are seeing is likely the PGNS incorporating LR data. If you are waiting until 2k ft on Apollo 16 to update the AGS height you are about 12000ft late You will notice, for your example, the Apollo 16 timeline has it update at 14k feet, not at 2k ft. Apollo 15 did it at 12kft, and Apollo 17 at 13kft. I did not get to test the scenario file, however this is a purely procedural guess.

 

[replicant]

Some of the divergence you are seeing is likely the PGNS incorporating LR data. If you are waiting until 2k ft on Apollo 16 to update the AGS height you are about 12000ft late You will notice, for your example, the Apollo 16 timeline has it update at 14k feet, not at 2k ft. Apollo 15 did it at 12kft, and Apollo 17 at 13kft. I did not get to test the scenario file, however this is a purely procedural guess.

True. I have tried early and frequent AGS height updates. The LR data with acceptance of V57E obviously corrects the PGNS computer model that would send the LM violently into the surface.

I was just envious of that Apollo 17 scenario because it seems to keep better AGS height data without intervention. Also the rate of descent is still a bad divergence even with early and frequent updates. So no matter what, in mine, that AGS ROD diverges by almost 120fps at 2k whereas in the Apollo 17 scenario it stays within 10 fps at 2k. Maybe just picking nits, but hey….lol.

I have heard the actual descent audio where Charlie Duke says “now that V57 is in John, we will probably see a fps divergence.” Maybe I just thought it was too excessive.

Thanks again

 

[indy91]

There are a few things I notice in your scenario:

-The current GET is very different from the flight plan time for PDI. I guess you are simulating the actual mission with its delay? Should be no problem to do that.
-The RTCC liftoff time wasn't synced to the CMC liftoff time. This is a fairly minor thing, won't cause your AGS issue. On the config page of the RTCC MFD press the UPD button to get the actual liftoff time from the CMC (or LGC). In your case it was off by 0.26 seconds. Just makes state vector uplinks etc. a bit more accurate to do this synchronization.
-AGS K-Factor. There is a way to update the K-Factor for V47, if you go to PADs and AGS SV PAD there is a button to calculate the actual number. It's off by about 1 second for you which is not ideal, but also can't really be the sole cause of the AGS descent issue.
-LGC deadband wasn't loaded correctly in V48 I think. Noticed that when I tested some stuff in the scenario.
-Here is the big one: When I do a P52 I get a torquing angle of more than 1°. This is a pretty bad alignment. The AGS depends on PGNS data for its initial alignment and state vectors. The PGNS gets updated data from the LR during the descent, in all axis. But I wonder if this PGNS misalignment is actually causing the AGS problems closer to the time of landing. The manual altitude update only fixes any errors in one axis for the AGS. What I noticed with the PGNS, too, was a blinking velocity light just before landing. That shouldn't really happen. I wonder if that is also from the alignment error, the PGNS rejecting LR data because it's too different from the PGNS state vector.

So overall, I think the best thing to try is to go to a bit earlier scenario and do another LM P52. And then update the AGS alignment and state vectors and check if the AGS now behaves better. And it definitely should behave better than I can see in the scenario. The AGS gyro and accelerometer biases are near zero when I check through the DEDA, so I don't think the issue comes from that.

 

[replicant]

Thanks very much for the detailed look.

1) Yes. My goal is historical PDI. More light at the landing site. That’s a me thing.

2) I thought I was checking the RTCC config page, but I missed that. So update just updates the RTCC itself for state vector propagation? Thanks. Good to know.

3) The AGS K-factor button was a little mysterious. I did read the thread about how the 224 to 227 coefficients can only be calculated for 11 and 12 by the RTCC at this time so we need the lunar timeline book. I was using V25 inside of V47 to set the 377 base time.

4) So yeah. The big one. A whopping 1 degree? I wonder how I did that? That definitely explains why without V57E it just slams in under PGNS. I had no idea I was so far off because honestly PDI and landing are smooth under PGNS. I was proud of myself when I read through all the threads trying to figure out tephem and why P63 wouldn’t run.

It makes sense because the AGS does align via datalink in 414 +3 or 400 +3 as I recall. When I use V42 in PAMFD I am ruthless about all zeros. Then I run P52 option 4 after updating and uplinking the landing site option 28 in RTCC for the REFSMMAT. How did you do your P52 to test it? Option 3 or did you torque them longer. I can use the sextant but honestly I avoid it when I can. So I wonder if it’s an order of operations thing.

5) On the DAP 48 octals, that’s me playing with different configurations. Wasteful on fuel maybe, but hey….

Edit: On reflection I think you must be right. Obviously the LR covers a multitude of sins. At low alt the LGC must be freaking out about what the LR is telling it vs what the PGNS gyros are telling it. (Someone is lying and I don’t know who. Poor HAL) . And if the AGS alignment is correct, the problem must be it was predicated on an error. So I will go back and see if I can figure where that is occurring.
Thanks.

 

[indy91]

2) I thought I was checking the RTCC config page, but I missed that. So update just updates the RTCC itself for state vector propagation? Thanks. Good to know.

State vector uplinks to the AGC are using Ground Elapsed Time, so the RTCC needs to know the exact time when the AGC had its clock zeroed so that it can convert an "absolute" time to GET for the uplink. That's all this little 0.26 second update in the RTCC does, so that it knows exactly what GET to uplink with state vectors.

3) The AGS K-factor button was a little mysterious. I did read the thread about how the 224 to 227 coefficients can only be calculated for 11 and 12 by the RTCC at this time so we need the lunar timeline book. I was using V25 inside of V47 to set the 377 base time.

Both the K-factor calculation as well as the descent abort constants calculation are still a bit experimental, which is why I didn't implement them for the Apollo 11 MCC mission support yet. K-factor calculation can be safely used I guess. Descent abort constants (both for the PGNS as well as the AGS, the 224-227 coefficient you mentioned) depend on the exact rendezvous profile flown. That has not been implemented yet for anything but Apollo 11 and 12.

4) So yeah. The big one. A whopping 1 degree? I wonder how I did that? That definitely explains why without V57E it just slams in under PGNS. I had no idea I was so far off because honestly PDI and landing are smooth under PGNS. I was proud of myself when I read through all the threads trying to figure out tephem and why P63 wouldn’t run.

It makes sense because the AGS does align via datalink in 414 +3 or 400 +3 as I recall. When I use V42 in PAMFD I am ruthless about all zeros. Then I run P52 option 4 after updating and uplinking the landing site option 28 in RTCC for the REFSMMAT. How did you do your P52 to test it? Option 3 or did you torque them longer. I can use the sextant but honestly I avoid it when I can. So I wonder if it’s an order of operations thing.

I just ran a P52 option 3 in the LM to test, got a good star angle difference but then the pretty large torquing angles. For the delayed landing they probably uplinked a new REFSMMAT and then did a P52 option 1, I think?! But P52 option 4 also works. I hope you used no V42 after undocking, because that is only for the docked alignment, where the CSM alignment is used for the LM IMU.

5) On the DAP 48 octals, that’s me playing with different configurations. Wasteful on fuel maybe, but hey….

Yeah, wasn't really a problem, just something I noticed when I was in P52 and the auto maneuver didn't take me exactly to the star. Programs like P63 can set their own deadbands, V48 just matters in P00 there.

 

[replicant]

State vector uplinks to the AGC are using Ground Elapsed Time, so the RTCC needs to know the exact time when the AGC had its clock zeroed so that it can convert an "absolute" time to GET for the uplink. That's all this little 0.26 second update in the RTCC does, so that it knows exactly what GET to uplink with state vectors.



Both the K-factor calculation as well as the descent abort constants calculation are still a bit experimental, which is why I didn't implement them for the Apollo 11 MCC mission support yet. K-factor calculation can be safely used I guess. Descent abort constants (both for the PGNS as well as the AGS, the 224-227 coefficient you mentioned) depend on the exact rendezvous profile flown. That has not been implemented yet for anything but Apollo 11 and 12.



I just ran a P52 option 3 in the LM to test, got a good star angle difference but then the pretty large torquing angles. For the delayed landing they probably uplinked a new REFSMMAT and then did a P52 option 1, I think?! But P52 option 4 also works. I hope you used no V42 after undocking, because that is only for the docked alignment, where the CSM alignment is used for the LM IMU.


Yeah, wasn't really a problem, just something I noticed when I was in P52 and the auto maneuver didn't take me exactly to the star. Programs like P63 can set their own deadbands, V48 just matters in P00 there.

Ok, experiment bears out the hypothesis. Just for fun I ran the scenario without entering V57. It didn’t slam in, it actually leveled off at about 30,000 feet, in program 66! It thought it was 1000 feet AGL right there in PGNS. The AGS agreed perfectly both in altitude and rate of descent proving that my AGS align was almost perfect, it was just predicated on a bad PGNS align. This goes to show how much that LR will compensate for! Wow. Although obviously it shouldn’t have to work that hard.

So I went back and corrected the pitch misalign, it was 1.1 degrees that I saw. Then aligned the AGS off of that and all works well. Amazing what ONE degree will do on the REFSMMAT!

What’s really funny is I didn’t remember what I learned several months ago playing with this. As to your time difference on PDI point. I had already discovered quite a while ago that to maintain the pitch inertial reference point where you want it at the landing site changes every 2 hour orbital period by…..wait for it….about 1 degree.

Thanks a lot! Again, this thing is incredible. It gets better all the time. I love it on my machine, I’ve got the 16 gig moon textures and microtextures with the D3D9. I’ve got all the mission specific audio in the custom vessels sound folder so I can hear Charlie calling out on approach. The experience you guys are creating is awesome.

 

[replicant]

So I was perusing the Git Hub updates and lo and behold….RTCC now has a misalign debug button.

Those AGS aborts will be flawless now.

 

[indy91]

Yeah I added a way to show the misalignment of an IMU, but don't use it to get V42 angles, that is cheating!

I mainly added it so I could quickly check in scenarios how good the alignment is, for troubleshooting. Otherwise I would have to do a full P52 just to check. It might also be useful to @n72.75 and his IMU drift and bias update. And maybe we might cheat a little bit for mission scenarios that get released with NASSP in the future. It might make sense to give those a perfect alignment, so that we have "perfect", baseline scenarios for people to use.

 

[replicant]

Cheating? I wouldn’t dream of it….

Actually, in an attempt to be a purist, I decided to get past my laziness/fear of the scopes in the CSM and the AOT in the LEM. I have run 50 scenarios just practicing optical adjustment. Using your tool to cross check, my final conclusion is that original 1.1 degree error was an accumulated translunar cruise gyro drift. I am proud to say that now I can consistently use the optics in either spacecraft and correct alignment within 00.0XX

No more guessing. Yaaaaay. So go ahead, take debug away….I dare ya.

On a side note, I accomplished an AGS abort after pulling all 3 PGNS circuit breakers at 3000 ft to simulate a total failure. At about 500 feet it was falling at 100fps and 30 bank and 25 pitch down. The horror. I slammed it into AGS and hit abort stage. Just like the FP6 book says, it was amazing how aggressively the AGS recovers attitude. Good thing. The ascent stage was righted and leveled at about 60 feet with the descent stage a tumbling wreckage below.

I managed a rendezvous with the CSM using only the DEDA, the RR, and the cross hair pointers. No orbiter huds or MFD’s. Quite the challenge.

Again, the thought that this software is for free….thanks. You guys are steely eyed missile men.