NASSP 8 - P37 Deorbit Prog Issue

[VladimirApollo]

Hello, I'm doing the Apollo 7 mission in NASSP 8 for Orbiter 2016 by following the Apollo7vAGC Flightplan file that was included in the NASSP 7 for Orbiter 2010.

I've reached the deorbit portion of the flightplan but I ran into an issue with Program 37. After punching in the proper GET for the deorbit burn and after the impact lat/long showed the lat/long that's in the flightplan, for some reason the AGC thinks it needs to add +dV instead of -dV for the deorbit burn, here's what the F06 81 planned dvx, dvy, dvz read:

It just adds these ridiculous amounts of dV that end up raising my orbit instead of lowering it. I've checked everywhere and I haven't come across anyone with a similar issue. If anyone out there has any ideas, I'd be grateful if you share
Oh also I've set the reentry angle to -2.06 degrees as instructed by the flightplan

Cheers

 

[indy91]

Yeah, that DV vector is nonsense. Could be a few things causing this. Do you have an accurate CSM state vector in the AGC? What were your other exact inputs other than the reentry angle?

P37 is a bit tricky to work with, especially because it's reusing noun 60 for different purposes, where you have to be careful not to change the wrong numbers. When you start P37 and get N60 the first time you should leave R2 as 0 and input the -2.06° in R3. If you get N60 again in P37 you shouldn't change any of the values, because then it displays numbers it calculated from the initial inputs.

I'm also suprised that P37 even iterated successfully to such a weird solution and didn't cause a program alarm.

 

[VladimirApollo]

Yeah, that DV vector is nonsense. Could be a few things causing this. Do you have an accurate CSM state vector in the AGC? What were your other exact inputs other than the reentry angle?

P37 is a bit tricky to work with, especially because it's reusing noun 60 for different purposes, where you have to be careful not to change the wrong numbers. When you start P37 and get N60 the first time you should leave R2 as 0 and input the -2.06° in R3. If you get N60 again in P37 you shouldn't change any of the values, because then it displays numbers it calculated from the initial inputs.

I'm also suprised that P37 even iterated successfully to such a weird solution and didn't cause a program alarm.

I appreciate the quick response! I performed automatic SV update 20 minutes prior to starting deorbit ops, as for the other inputs,
here's the excerpt of the entire procedure and I followed it to the number,
with the exception of changing the burn GET to T+260:05:00 to get the longitude coords to match the ones mentioned below. After the excerpt, all you do is proceed with 'PRO' and check all the parameters so I doubt that anything below this part is the issue. Also I did leave R2 on 0 the first time I went into N60, but every time after keying V32 to adjust the GET for the coordinates, R2 on N60 would increase more and more but I never fiddled with it.
V37E 37E
Line 1: 00xxx GET of burn in hours
Line 2: 000xx GET of burn in minutes
Line 3: 0xx.xx GET of burn in seconds
V25E +00259E +00039E +01600E inputs preliminary deorbit burn ignition time of MET: +259:39:16
PRO
Line 2: xxxxx velocity prediction in ft/sec
Line 3: xxx.xx entry angle in degrees
V23E -00206E loads variable velocity and -2.06 degree entry angle
PRO will begin deorbit burn computations
Possible PROG Alarm, "00605" flight path angle not attainable, key V31 to repeat
Possible PROG Alarm, "00613" excess iterations in solution, key V31 to repeat
Line 1: xxx.xx impact LAT, + is north, - is south
Line 2: xxx.xx impact LON, + is east, - is west
Key V32, and change the ignition time if necessary by 20, 10 or 5 minutes. Key "PRO" and re-enter data
When the impact LON displays close to "-06415", key "PRO." Otherwise, repeat above until impact LON is close to "-06415"

These are my orbital parameters that I acquired after the 7th SPS burn that went by flawlessly and my position during the P37 setup is somewhere northeast-ish of Australia.

---------- Post added at 12:28 AM ---------- Previous post was at 12:19 AM ----------

Quick update, I was just fiddling around with this some more and I found that If I click PRO and go through all the nouns on the first click without V32 to change the GET and leaving the default coordinates punched in it actually gives what resembles sensible deorbit dV values:

Perhaps the values in R2 on N60 are related to this somehow?
Here's my scenario file just in case, SV update was performed 20 minutes earlier.

 

[indy91]

Ah, so you did the recylce (V32). That actually takes you back to the very first step of P37. And then when you get N60 again you need to reenter all the data, including R2 set to 0. R2 will still have the reentry velocity from the previous calculation and if you don't set R2 to 0 there it will try to enforce your total velocity at reentry as you Delta V. That's probably why you got the huge DV previously. And that's also why this weird double use of N60 for both the velocity change input and reentry velocity display is not a very elegant solution (bad MIT Instrumentation Lab, bad!).

Here is the Apollo 8 CMP Checklist, with the full P37 procedures on PDF page 27: https://www.ibiblio.org/apollo/Documents/A8-CMP checklist-1004.pdf

You see there that V32 takes you back to step 1 every time. And N60 is, with slightly different meanings, displayed on step 2 and 5.

So all you have to do differently is change R2 of N60 to 0 in the step just after doing the recycle with V32.

 

[VladimirApollo]

Ah, so you did the recylce (V32). That actually takes you back to the very first step of P37. And then when you get N60 again you need to reenter all the data, including R2 set to 0. R2 will still have the reentry velocity from the previous calculation and if you don't set R2 to 0 there it will try to enforce your total velocity at reentry as you Delta V. That's probably why you got the huge DV previously. And that's also why this weird double use of N60 for both the velocity change input and reentry velocity display is not a very elegant solution (bad MIT Instrumentation Lab, bad!).

Here is the Apollo 8 CMP Checklist, with the full P37 procedures on PDF page 27: https://www.ibiblio.org/apollo/Documents/A8-CMP checklist-1004.pdf

You see there that V32 takes you back to step 1 every time. And N60 is, with slightly different meanings, displayed on step 2 and 5.

So all you have to do differently is change R2 of N60 to 0 in the step just after doing the recycle with V32.

I tried that, but what would end up happening is that no matter what GET I select, by resetting R2 on N60 to +00000 every time after V32 the impact coords wouldn't go lower than approx. +13xxx longitude. Only If I let R2 increase when I key in V32 will the longitudinal coordinate get down to -06415 which is what I need

 

[indy91]

Hmm, I've tried it myself in your scenario and I believe that the CSM is not in a very good orbit. The perigee and apogee altitudes are right (86x225), but the location of the apogee is not ideal. The reason for this orbit is basically that you would just need a small DV applied at apogee for the reentry. Unfortunately the apogee is not aligned in such a way that reentry will happen favourably for a 64.15°W splashdown. That's not really your fault, we don't have the proper calculation tools for this maneuver yet. Did you use IMFD for the previous maneuvers or the RTCC MFD or something else?

Your orbit seems pretty well aligned for an Indian Ocean landing actually. About 65°E. Why don't you just land there instead. That's a proper contingency landing area for the Apollo missions. And it seems to iterate quite well in P37. Just make sure on a map that you will hit water and not land. :lol:

 

[VladimirApollo]

Hmm, I've tried it myself in your scenario and I believe that the CSM is not in a very good orbit. The perigee and apogee altitudes are right (86x225), but the location of the apogee is not ideal. The reason for this orbit is basically that you would just need a small DV applied at apogee for the reentry. Unfortunately the apogee is not aligned in such a way that reentry will happen favourably for a 64.15°W splashdown. That's not really your fault, we don't have the proper calculation tools for this maneuver yet. Did you use IMFD for the previous maneuvers or the RTCC MFD or something else?

Your orbit seems pretty well aligned for an Indian Ocean landing actually. About 65°E. Why don't you just land there instead. That's a proper contingency landing area for the Apollo missions. And it seems to iterate quite well in P37. Just make sure on a map that you will hit water and not land. :lol:

Ahh I see then. I used IMFD/Delta Velocity for all my burns, I don't think I've ever tried out the RTCC MFD. Suppose I'll try landing in the Indian ocean a bit later. Just curious, are all the AGC programs and codes for CSM and LM simulated in NASSP, or are there any that were left out for whatever reason?

 

[indy91]

Just curious, are all the AGC programs and codes for CSM and LM simulated in NASSP, or are there any that were left out for whatever reason?

NASSP doesn't simulate the AGC, it uses the Virtual AGC emulator running the actually flown software. Because the Apollo 7 AGC software (called Sundisk) has not been found yet in the form of the 1700 pages printout of the source code, it instead uses the Apollo 8 software (called Colossus237) for both Apollo 7 and 8. So what you are using is 100% identical to the flown Apollo 8 software. In the case of Colossus237 the source code comes from the private collection of original AGC developer Fred Martin. Here the link to the source code: https://www.ibiblio.org/apollo/listings/Colossus237/MAIN.agc.html Available for the Virtual AGC emulator are the flown sofware versions (CSM and LM) for many more missions, although unfortunately not all of them.

 

[VladimirApollo]

So the Apollo missions had several iterations of the AGC software that were used, I didn't know that.

I've managed to deorbit and splashdown in the middle of the Indian Ocean and everything went extraordinarily well! I noticed, however, that CM RCS feels kind of overpowered, even the computer had minor issues with keeping it still when attaining entry attitude. Is this supposed to be this way or..? It didn't really affect anything, it's just that its movement seems very erratic when looking at it.

I'll try out the Apollo 8 mission soon, is it likely that the same could happen on the Apollo 8 mission regarding impact coords and reentry parameters?

Thanks for the help, wouldn't have been able to figure this out myself!

 

[indy91]

So the Apollo missions had several iterations of the AGC software that were used, I didn't know that.

There were updates for every mission until Apollo 15, Apollo 15-17 flew the same software for CSM and LM for cost reduction reasons and also because a third development branch was started for the Skylab CSM software.

I noticed, however, that CM RCS feels kind of overpowered, even the computer had minor issues with keeping it still when attaining entry attitude. Is this supposed to be this way or..? It didn't really affect anything, it's just that its movement seems very erratic when looking at it.

Yeah, in comparison to the SM RCS the CM RCS feel quite a bit overpowered. But that is the correct behavior I am pretty sure.

I'll try out the Apollo 8 mission soon, is it likely that the same could happen on the Apollo 8 mission regarding impact coords and reentry parameters?

Shouldn't have the same issue, a return from the Moon is very different. The TEI maneuver has the biggest impact on splashdown longitude really. The MCCs after TEI are mostly for controlling the reentry angle.

For Apollo 8 I would suggest to not use the old Excel flightplan. It's very outdated and not updated anymore. The Checklist MFD has the full procedures for the mission, just like the Excel flight plan had. In the current flightplan folder for Apollo 8 is the actually flown flightplan, which can be used quite well in NASSP.

And for maneuver calculations, the MCC scenario for Apollo 8 does all the calculations for you, so that you don't need to use any MFD. And if you use the non-MCC scenario the RTCC MFD is the best calculation tool.