Meadville Space Center

Project Apollo - NASSP => Support & Bugs => Topic started by: rcflyinghokie on November 23, 2016, 11:54:51 AM



Title: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on November 23, 2016, 11:54:51 AM
I am starting this thread for those working through Apollo 8 to post bugs and issues.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on November 23, 2016, 12:32:11 PM
Just pushed a fix for the dV CG switching and for a timing error that starts the flightplan group (4h in) before the insertion checklist (immediately after boost)


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on November 25, 2016, 09:59:39 AM
@rcflyinghokie, did you do a bunch of changes to the insertion checklist in the Apollo 8 Checklist MFD file? There are some things that seem different, and also a few problems that weren't there before. For example, I think the Fuel Cell Indicator switch a few times doesn't have the same desired position as in the description of this checklist item during the FC purge tests. Also, at no point are the SECS circuit breakers closed again and the SECS Logic switches enabled again. Fairly certain these things worked before...

Following the Checklist MFD I am also already done with all the TLI Prep before the 2 hours GET mark, weren't there previously later times specified for this? Pyro arm shouldn't really happen this early.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on November 25, 2016, 11:16:48 AM
The only changes I made were adding the dvCG switch to LM/CSM before launch and to the P40 checklist and changed the timing in the flight plan group so it would appear after the CSM/LV separation.  I didn't mess with the insertion or TLI checklist other than adding the word "Copy" to the text when a PAD is expected.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on November 25, 2016, 11:33:09 AM
Weird. Must be older changes then, I haven't tried Apollo 8 in a while. In any case, there are currently quite a few "bugs" in the checklist file, do you want to handle that or should I fix the ones I have found?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on November 25, 2016, 11:39:47 AM
Weird. Must be older changes then, I haven't tried Apollo 8 in a while. In any case, there are currently quite a few "bugs" in the checklist file, do you want to handle that or should I fix the ones I have found?

I already have it all up so I can easily fix it :)  Mind giving me a good list?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on November 25, 2016, 11:49:30 AM
Just from memory, you should check the FC Purge stuff in Earth Parking Orbit (part of the insertion checklist), I think the indicator switch isn't always right. As I said above, the circuit breakers and logic switches for the Pyros are not enabled again for TLI, only the Pyro Arm switches are. And after TLI and separation, when the left TVC power switch is reset from AC1 to Off the position the checklist controller wants is AC2 and not off.

In all the problem cases the displayed text for the checklist item is right, but the position in the column for that in the Excel sheet is wrong.

The TLI Prep with Pyro Arm maybe needs a slightly different timeline, the flight plan should give you that information. Go for Pyro Arm is given at about 2:20h.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on November 25, 2016, 12:03:33 PM
I'll run through and fix the timeline shortly.  I know why the FC indicators were on the wrong positions, because they use 1 2 3 as the position indicators in the saturnpanel.cpp unlike other rotary switches that use 0 1 2 etc.

EDIT: Fixed those issues you mentioned, will create a pull request soon.  Timeline seems to work right now let me know if something is still screwed up!

EDIT 2:  One thing I noticed is the securing of the cabin pressure before the SEP checklist asks for Direct O2 full open until the cabin pressure is 5.7psi.  In our sim this does not increase cabin pressure very fast at all and even with the valve open the whole time there is no way our sim reaches this pressure before sep, any thoughts?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on November 25, 2016, 03:38:40 PM
EDIT: Fixed those issues you mentioned, will create a pull request soon.  Timeline seems to work right now let me know if something is still screwed up!

I believe you that it is fixed. I was already further than separation and the timeline worked perfectly. So perfect, that the checklist for the S-IVB separation was reached exactly on time for separation. :D

Quote
EDIT 2:  One thing I noticed is the securing of the cabin pressure before the SEP checklist asks for Direct O2 full open until the cabin pressure is 5.7psi.  In our sim this does not increase cabin pressure very fast at all and even with the valve open the whole time there is no way our sim reaches this pressure before sep, any thoughts?

To me it looks like all the pipes, valves and switches for this are properly implemented. The Direct O2 is connected to the suit circuits, but those circuits should be connected to the cabin. And according to the diagram (http://nassp.sourceforge.net/wiki/File:CSM_systems_diagram.gif) there are a few connections to the cabin. I don't know enough about the ECS to find where the oxygen is flowing through, should it be the suit relief valve? I have no idea how to control that valve though...


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on November 25, 2016, 04:30:21 PM
To me it looks like all the pipes, valves and switches for this are properly implemented. The Direct O2 is connected to the suit circuits, but those circuits should be connected to the cabin. And according to the diagram (http://nassp.sourceforge.net/wiki/File:CSM_systems_diagram.gif) there are a few connections to the cabin. I don't know enough about the ECS to find where the oxygen is flowing through, should it be the suit relief valve? I have no idea how to control that valve though...

I am trying to find it now, but I remember reading a long time ago that if all 3 crew members were in shirt sleeve then all 3 are supposed to be on full flow.  And I just found it in the A15 systems checklist.

It looks like the apollo 8 checklist for doffing the PGA has the crewmember switch to cabin flow.  However the apollo 15 says the same but also explicitly says 3 on suit full flow if 3 unsuited.  I am going to dive through the AOH for more information.

EDIT:  So playing with time warp the direct O2 will increase the cabin to 5.7, but it takes over 3 hours, too long for that checklist step of course.  I am wondering if that valve should be increasing pressure faster?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on November 25, 2016, 04:59:11 PM
You mean the suit flow control valves on panels 300-302? Those are actually not implemented. So if the cabin pressure is increased via these valves, then we might have found the issue.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on November 25, 2016, 05:09:38 PM
You mean the suit flow control valves on panels 300-302? Those are actually not implemented. So if the cabin pressure is increased via these valves, then we might have found the issue.

Yes that's what I am talking about.  According to the AOH, putting them in cabin flow increases the flow rate to 12 cfm.  Something tells me I read a while back that this bypasses the CO2 scrubber and debris trap and such and thus was not used continuously, though I could be way wrong.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on November 25, 2016, 05:33:29 PM
That reminds me, do we have a link to the AOH volume 2?  I cannot seem to find it.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on November 25, 2016, 11:18:54 PM
Just discovered a potential oversight: we need markers for Earth landmark tracking when doing P23. Horizon sighting is one thing, but I don't know what I'm supposed to be locking onto when doing star/landmark sightings.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on November 26, 2016, 05:31:34 AM
Yes that's what I am talking about.  According to the AOH, putting them in cabin flow increases the flow rate to 12 cfm.  Something tells me I read a while back that this bypasses the CO2 scrubber and debris trap and such and thus was not used continuously, though I could be way wrong.

I think we should create an issue on Github for this and forget about until we work on NASSP 8.0.  :D

That reminds me, do we have a link to the AOH volume 2?  I cannot seem to find it.

You can get it at: http://www.spacecraft.it/ Just register, write a nice email and get the AOH Volume 2 and a few other documents. They went through the effort to scan these documents and these are large files, so I guess they want to limit their bandwidth costs.

Just discovered a potential oversight: we need markers for Earth landmark tracking when doing P23. Horizon sighting is one thing, but I don't know what I'm supposed to be locking onto when doing star/landmark sightings.

I actually started collecting information about the Earth landmarks from the Apollo Landmark Project and I will create a Marker file with all landmarks for which I have a complete set of latitude, longitude and altitude. Unfortunately we don't seem to have a document with a full list. Here a text file with the landmarks I have been able to find information about so far.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on November 26, 2016, 09:56:29 AM
I think we should create an issue on Github for this and forget about until we work on NASSP 8.0.  :D

Agreed, I guess I will leave the 5.7 psi thing in the checklist for now.  Back to checking 8 for fixable bugs for the 7.0 release!

You can get it at: http://www.spacecraft.it/ Just register, write a nice email and get the AOH Volume 2 and a few other documents. They went through the effort to scan these documents and these are large files, so I guess they want to limit their bandwidth costs.

So I started typing the email address, looks like I did register with then in 2011 :)  Got the AOH!


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on November 26, 2016, 01:10:41 PM
Thanks, indy. That'd also explain why there's no option to cross-check the landmark lat/lon/alt when I do landmark tracking. Not in the Colossus builds, I guess.  :yuck4543:


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on November 26, 2016, 03:19:22 PM
The MCC now supports TLC aborts. The Abort Maneuver PADs were calculated already anyway, so I just wanted to implement them as aborts that are not caused by a loss of communications.

The MCC has a lot of Mission States, but now it also has major mission phases, which are: Earth Orbit, Translunar Coast, Lunar Orbit, Transearth Coast, Entry. Because this is a new variable you have to start a new mission to try the abort, or you could edit in the MissionPhase parameter to your old scenario.

To start the abort sequence, you have to request the abort in the CAPCOM menu, which was now added as a menu option there. After you have confirmed the abort, it will then check in which mission phase you are. Currently only the TLC aborts are implemented. The MCC will use the last abort maneuver, for which you got a Maneuver PAD. So from TLI to a few hours after TLI the TLI+4 abort will be used. After you have performed the abort maneuver, the MCC will check if there is enough time between the Direct Abort Maneuver (DAM) and Entry Interface (EI) for another course correction other then the nominal EI-2 hour MCC. If yes, and this should be the case for the TLI+4 abort, then it will add another MCC 5 hours after the DAM. This timing is consistent with the Loss-of-Comm procedures. After this additional course correction the nominal entry schedule will be used by the MCC. The uplink for this course correction also includes the desired Entry REFSMMAT.

All other mission phases are currently not supported and if you select an abort for these, then no additional MCC updates will happen. Adding support for an abort from Lunar Orbit is easy, it will just switch to the nominal TEC schedule after the early TEI. An abort from TEC would involve moving the landing site, which would only be done in a time critical abort. Flyby is also not yet supported.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: abr35 on November 26, 2016, 05:38:57 PM
As far along as LOI-2 on Apollo 8. No problems to report so far. Would some tolerances for P23/P52 in the Checklist MFD be possible to help a user decide whether to accept or reject a state vector or alignment? Something like:

N05 < +00004 then PRO
N05 >= +00004 then reject


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on November 27, 2016, 09:19:52 AM
As far along as LOI-2 on Apollo 8. No problems to report so far. Would some tolerances for P23/P52 in the Checklist MFD be possible to help a user decide whether to accept or reject a state vector or alignment? Something like:

N05 < +00004 then PRO
N05 >= +00004 then reject

It wouldn't hurt, though if someone is using the auto checklist they would have to issue the V32 and pause it to go back to the proper step unless we implement a FAIL option like @jalex has done for the P40/41 options.

EDIT:  So I was experimenting and added the FAIL condition to the P52 in the Apollo 7/8 checklist.  Once it is merged please give it a try make sure I didn't miss anything.  If everything works I can start doing it with the P23.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on November 27, 2016, 12:12:28 PM
I tested it and there is a problem with the sequence. After you complete the repeated marking sequence, it goes back to where you pressed fail in the original P52 checklist. So it wants you to do the gyro torquing etc. again. I guess you can solve this by removing all the checklist items after the accept/fail decision from the Bad Angle checklist.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on November 27, 2016, 12:21:18 PM
I tested it and there is a problem with the sequence. After you complete the repeated marking sequence, it goes back to where you pressed fail in the original P52 checklist. So it wants you to do the gyro torquing etc. again. I guess you can solve this by removing all the checklist items after the accept/fail decision from the Bad Angle checklist.

Ah I did not catch this, I will post a fix shortly.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on November 28, 2016, 06:32:51 AM
There is still a problem: https://github.com/dseagrav/NASSP/pull/32#issuecomment-263136429


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on November 28, 2016, 08:01:12 AM
There is still a problem: https://github.com/dseagrav/NASSP/pull/32#issuecomment-263136429

Done, forgot I added the P51 to Apollo 8


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on November 28, 2016, 09:36:33 AM
I have added MCC Abort support for the flyby and PC+2 maneuvers and the early TEIs. It's not properly tested yet, but I will do that over the next few days. The only abort maneuvers that are now calculated by the RTCC but are not supported by the MCC yet are the TLI+90 minutes maneuver, the fast PC+2 (24 hours early return) and TEI-11 (one revolution later than planned). It's a little bit difficult to support these, because they are calculated "out of sequence". The TEI-11 Maneuver PAD for example is already given to the astronauts just after the final TEI-10 Maneuver PAD. And the times for TEI and EI are saved with each maneuver calculation and are important for the TEC sequence, so MCC support for TEI-11 would currently break the nominal return sequence. I have some ideas how to implement full support for abort maneuvers, that that would require the MCC to be reworked in some ways, which is not something I want to do so close to the release. So I think all I will do is test the changes I have done and then work on MCC abort after the release.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: abr35 on November 28, 2016, 10:49:04 PM
Not sure if this is a bug or mismanagement of the AGC. Lost my IMU alignment and can't get it back. Here's a run down of what happened, if something doesn't make sense I can post a scenario.

I was running P22 psuedo landing site tracking on rev 5, just before the night pass (78:05 GET I believe). I took 5 marks per the flight plan

F 50 25 00016 PRO to
F 05 71 (landmark data) PRO to
F 06 49 (SV change) it was high so I keyed V32E to recycle

Got a program alarm W-Matrix Overflow, went to P00 and quicksaved. Later went to do a P52 and with optics in CMC the computer was not pointing the optics at anything in particular. Marked the stars in manual and got a very large error. I tried a sextant star check with one of the abort PADs, still not pointing at the correct star. So I tried doing an alignment with the set stars on the abort pad, and that didn't work either. Did I miss something here? Was I supposed to do something about that program alarm?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on November 29, 2016, 06:42:16 AM
Got a program alarm W-Matrix Overflow, went to P00 and quicksaved.

I'd be interested in seeing this quicksave. I had W-Matrix overflow in the past, too. Each time your state vector is propagated in P00, the W-Matrix also gets modified. Basically, there is an uncertainty in the state vector integration routine and if you coast for a long time without a state vector update from the ground, the accuracy of the state vector is getting too high. The program alarm (421 I guess?) just tells you your state vector is not good enough, but that can usually be ignored. I think Apollo 9 or so also got this once.

Quote
Later went to do a P52 and with optics in CMC the computer was not pointing the optics at anything in particular. Marked the stars in manual and got a very large error. I tried a sextant star check with one of the abort PADs, still not pointing at the correct star. So I tried doing an alignment with the set stars on the abort pad, and that didn't work either. Did I miss something here? Was I supposed to do something about that program alarm?

I doubt the W-Matrix program alarm is related to the alignment problem. Maybe the optics weren't zeroed for the P52? In that case the CMC doesn't properly know where the optics are pointing. Did you maybe get another program alarm, 116 or 120?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: abr35 on November 29, 2016, 08:57:11 AM
Optics were zeroed after the P22, just before the program alarm. No other alarms. This scenario is immediately after the P22.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on November 29, 2016, 09:44:37 AM
Something weird is going on with the optics there. If you look at the OCDU angles (V16 N91), the angles are very different from the mechanical readouts for shaft and trunnion and zeroing doesn't work either. No idea yet why that happens.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on November 29, 2016, 10:57:43 AM
Something weird is going on with the optics there. If you look at the OCDU angles (V16 N91), the angles are very different from the mechanical readouts for shaft and trunnion and zeroing doesn't work either. No idea yet why that happens.

Even zeroing with a V41 N91 does not work nor resetting the optics.  I wonder if the optics positioning in the P22 screwed this up?

EDIT:  I ran a V36 and reset the REFSMMAT flag and uploaded the current REFSMMAT and the optics zero again.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: abr35 on November 29, 2016, 06:24:43 PM
The closest thing I can think of is I forgot to put optic speed to CMC/high once and left the speed switch in low. This caused the optics to lag behind where the CMC was pointing them. I picked up the scenario from an earlier point and I'll see if it happens again. If it doesn't maybe I can try and reproduce it.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on November 29, 2016, 06:46:29 PM
If I recall correctly the speed doesn't affect CMC drive only the speed at which the hand controller moves the optics


Title: Re: Apollo 8 Beta Testing Bugs
Post by: abr35 on December 01, 2016, 10:35:27 AM
Just burned TEI and hadn't had the optics problem again. I've had a similar problem with P23 where terminating the program early causes the CMC to continue pointing the optics to the last shaft/trunnion angle issued (even in P00h) until a new set of commands are issued by another program. I'll try to cause the problem again after I'm finished testing Apollo 8.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on December 01, 2016, 10:42:32 AM
Just burned TEI and hadn't had the optics problem again. I've had a similar problem with P23 where terminating the program early causes the CMC to continue pointing the optics to the last shaft/trunnion angle issued (even in P00h) until a new set of commands are issued by another program. I'll try to cause the problem again after I'm finished testing Apollo 8.

Were you able to go back and recreate the problem like you said before that quicksave?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: abr35 on December 03, 2016, 04:13:46 PM
Ok recreated the issue by zeroing the optics and returning to manual before N91 registers that they have been zeroed. It's very possible that I absent mindedly did that during a P22. In which case no bug.

Flew the rest of Apollo 8. Entry PADs came in from MCC at different times than they are listed on the Flight Plan. I assume MCC-7 and the Entry PAD are in relation to Entry Interface?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 04, 2016, 05:52:18 AM
Ok recreated the issue by zeroing the optics and returning to manual before N91 registers that they have been zeroed. It's very possible that I absent mindedly did that during a P22. In which case no bug.

The AGC should give you a program alarm when you do that. And weird that switching to manual and back to zero doesn't fix the OCDU angles.
 
Quote
Flew the rest of Apollo 8. Entry PADs came in from MCC at different times than they are listed on the Flight Plan. I assume MCC-7 and the Entry PAD are in relation to Entry Interface?

Yeah, they are relative to Entry Interface. Maybe the Checklist MFD can be adjusted for that.

EDIT: As requested a while back, I added a marker file for Apollo Earth Landmarks. Currently it only has the one landmark used in P23 for Apollo 8, but I will add some landmarks for Apollo 7 soon, too. I also added the worksheet to convert various AGC or Orbiter 2010 coordinates.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on December 05, 2016, 02:33:25 PM
Just a checklist question, in the P37, what would the desired TIG be?  I cannot find this in the checklists or the transcript.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 05, 2016, 03:38:39 PM
On the way back? According to the transcript they used the nominal time for the MCCs. They tried P37 after most P23 cislunar navigation sessions, to compare the solutions calculated onboard and on the ground. They used 122:00:00 GET for MCC6 and the more exact number 144:46:00 GET (Entry Interface minus 2 hours) for MCC7.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on December 05, 2016, 09:54:29 PM
On the way back? According to the transcript they used the nominal time for the MCCs. They tried P37 after most P23 cislunar navigation sessions, to compare the solutions calculated onboard and on the ground. They used 122:00:00 GET for MCC6 and the more exact number 144:46:00 GET (Entry Interface minus 2 hours) for MCC7.

Ah ok, I must have missed that reading through.  I knew they used it for comparison but I didnt know what times.  Perhaps adding those times to the heading for the checklist MFD would help?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 06, 2016, 09:45:01 AM
Perhaps adding those times to the heading for the checklist MFD would help?

Sure, the time for MCC7 is usually not too different from the historical time, a few minutes at most. That won't really make much difference for the P37, if you want to compare it with the ground solution.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on December 06, 2016, 10:33:06 AM
Sure, the time for MCC7 is usually not too different from the historical time, a few minutes at most. That won't really make much difference for the P37, if you want to compare it with the ground solution.

I added that to my changes.

Also another question, my entry N61 is off from the entry pad, the pad shows a LAT:+00828  LON:-16500 and my CMC shows  LAT:+00513  LON:-16082.  Additionally the RTGO is about 400 more in the CMC than the PAD.  Should these be closer together?  Running the entry the CMC works very well and the CMC predictions are very very close to actual results post landing but that PAD seems off.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 06, 2016, 10:45:10 AM
Also another question, my entry N61 is off from the entry pad, the pad shows a LAT:+00828  LON:-16500 and my CMC shows  LAT:+00513  LON:-16082.  Additionally the RTGO is about 400 more in the CMC than the PAD.  Should these be closer together?  Running the entry the CMC works very well and the CMC predictions are very very close to actual results post landing but that PAD seems off.

Weird. Which MCCs had to be done? Was MCC7 scrubbed? I remember jalexb88 said something about a coordinate differences when MCC7 is scrubbed, but I thought I fixed it. And the PAD lat/long should always be identical to the uplinked coordinates.

I am currently also close to a Apollo 8 reentry, for testing some of the abort stuff. Apparently the 7000 ft/s TLI+44 Direct Abort was so accurate, that the intermediate course correction was scrubbed and MCC7 will only be 1.1 ft/s. Maybe I'll notice the same problem soon that you are experiencing.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on December 06, 2016, 11:05:50 AM
Weird. Which MCCs had to be done? Was MCC7 scrubbed? I remember jalexb88 said something about a coordinate differences when MCC7 is scrubbed, but I thought I fixed it. And the PAD lat/long should always be identical to the uplinked coordinates.

Actually every MCC was scrubbed after TEI.  I omitted the P23's on the return trip though, that could possibly account for not needing corrections?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 06, 2016, 11:18:53 AM
Actually every MCC was scrubbed after TEI.  I omitted the P23's on the return trip though, that could possibly account for not needing corrections?

The onboard state vector isn't used by the RTCC, so the P23s are irrelevant for ground calculated MCCs. The scrubbed MCCs are the problem, because no entry target is uplinked if all MCCs are scurbbed. So I should fix that. I am confused where the -160.82° is coming from though. Probably a P37 on the way to the Moon? The onboard calculated entry target has a longer range, so that would explain the 4° difference. I will probably add an entry target update to the very last RTCC calculation, the final Entry PAD + state vectors. It will be the same target uplinked previously with a MCC, if it is done. And I will also add a entry target update to the TEI-10 uplink, just so that the AGC has a target that is not the padloaded Atlantic Discrete Recovery Area (ADRA).


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on December 06, 2016, 11:23:59 AM
I am confused where the -160.82° is coming from though. Probably a P37 on the way to the Moon? The onboard calculated entry target has a longer range, so that would explain the 4° difference.

I ran a P37 on the way back using the MCC7 time, but never ran another for EI-2h, that us probably the source for that issue.

Also when you are finished with your entry, let me know if you see any checklist issues.  I have a 7 and 8 to upload with a few minor fixes (spelling, timing, a few switches that were technically trivial but omitted originally etc) so if you see any more problems I can add them to my current drafts and then upload them.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 06, 2016, 11:46:42 AM
Pushed the changes. Try again from before the final Entry PAD (EI-45 minutes) or earlier.

I ran a P37 on the way back using the MCC7 time, but never ran another for EI-2h, that us probably the source for that issue.

Without the P37 it would still have the coordinates of the ADRA. At least the P37 coordinates are fairly close. :D The problem was simply that there were no entry target (latitude+longitude) uplinks with all MCCs scrubbed (why is it suddenly so accurate???).

Quote
Also when you are finished with your entry, let me know if you see any checklist issues.  I have a 7 and 8 to upload with a few minor fixes (spelling, timing, a few switches that were technically trivial but omitted originally etc) so if you see any more problems I can add them to my current drafts and then upload them.

No really big issues. I have to go back to earlier in the flight though, there was a problematic switch setting which led to overheating suits. Enough for the astronaut state evaluation to notice they have died. I either missed a switch setting for the insertion checklist or there is a problem with the Checklist MFD in there. I have to look what the problem was, something on the lower end of Panel 2. Maybe the suit heat exchange switch.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on December 06, 2016, 11:51:08 AM
No really big issues. I have to go back to earlier in the flight though, there was a problematic switch setting which led to overheating suits. Enough for the astronaut state evaluation to notice they have died. I either missed a switch setting for the insertion checklist or there is a problem with the Checklist MFD in there. I have to look what the problem was, something on the lower end of Panel 2. Maybe the suit heat exchange switch.

Ok let me know if you do see a problem, though I ran the auto checklist for the whole mission to test it and did not run into this issue, user error perhaps?  :P

I am adding my checklist modifications now as well.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on December 11, 2016, 11:26:01 AM
One think I noticed during entry is when doing the CM RCS tests, the roll thrusters of the SM still fire with the CM thrusters, however the P and Y ones only the CM fires.  Is there perhaps a procedural error here or maybe something wrong with the configuration?  I posted a scn (testing an abort so the timing is way off)


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 11, 2016, 12:27:56 PM
The Auto RCS configuration is wrong. The four A/C roll switches have to be off for CM RCS operation. Only the 12 other Auto RCS switches can be used for automatic CM and SM RCS operation. The Apollo 15 Entry Checklist has this as the first item for the CM RCS test: "AUTO RCS A/C ROLL (4) OFF (verify)".


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on December 11, 2016, 08:02:42 PM
The Auto RCS configuration is wrong. The four A/C roll switches have to be off for CM RCS operation. Only the 12 other Auto RCS switches can be used for automatic CM and SM RCS operation. The Apollo 15 Entry Checklist has this as the first item for the CM RCS test: "AUTO RCS A/C ROLL (4) OFF (verify)".

I will fix the checklist then, thanks!

EDIT:  Actually there is a lot wrong with the entry checklists, nothing detrimental just simple order and missing breakers etc.  I will run through this and check it and post an updated checklist tomorrow after exams.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on December 19, 2016, 01:38:33 PM
Just did a full workup of the entry checklists and made a pull request.  Everything seems to be working properly and the timelines are pretty good.  Let me know if there are any issues.

Also is there a drogue deploy sound effect in NASSP that says "drogues" with a quindar tone?  Or is that the orbiter sound?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on December 19, 2016, 05:13:48 PM
I get a CTD when I try to load the 'non-MCC'-.scn. Seems to be located in the LVDC -removing the good old 'use_LVDC' phrase makes it load. Anybody any ideas?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on December 19, 2016, 09:30:27 PM
I get a CTD when I try to load the 'non-MCC'-.scn. Seems to be located in the LVDC -removing the good old 'use_LVDC' phrase makes it load. Anybody any ideas?

Does it CTD during the load or sometime after?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on December 20, 2016, 02:39:17 AM
During. After the reentry.dds, to be most specific.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 20, 2016, 07:07:14 AM
Hmm, no problem with that scenario for me. Does it happen every time? I sometimes get CTDs when Orbiter is just finished loading. Is the Apollo 7 scenario without MCC working? The scenarios should be completely identical, except for a parameter that enables the MCC ground and mission tracking from the beginning. So no idea why there would be a problem with the LVDC++ in that scenario.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on December 20, 2016, 08:54:07 AM
Apollo 7 does work. Just tried the other Missions: as soon as there's the Saturn V LVDC++ involved, it crashes after reentry.dds has been loaded. Most interestingly it doesn't even create the lvlog.txt, so there must be something happening when or before the constructor is called. :?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 20, 2016, 08:59:39 AM
Did you build from scratch or did you download the prebuild modules? If you build it yourself, maybe try the "Rebuild" option? Maybe something went wrong there with the LVDC++.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on December 20, 2016, 09:03:25 AM
During. After the reentry.dds, to be most specific.

I can load all of them with no trouble, as indy said probably a build issue?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on December 20, 2016, 09:15:15 AM
I've got the latest git checkout, and yes, I've rebuilded the modules at least 3 times.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on December 20, 2016, 09:20:00 AM
I've got the latest git checkout, and yes, I've rebuilded the modules at least 3 times.

Are you in debug mode or release mode in VS?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 20, 2016, 09:22:46 AM
Are you in debug mode or release mode in VS?

Oh right, that is a common problem, the LVDC++ doesn't seem to like the debug mode. I get about 5 frames per second with a build in debug mode, so I almost never use it. Also don't forget to REbuild if you change from debug mode to release mode, or vice versa.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on December 20, 2016, 09:44:34 AM
Got it. LVDC.cpp was corrupt, obviously. I just forced git to make a new checkout for this one file, and now it works. Strange. And casts quite a bad light on git, I'd say... :|


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on December 20, 2016, 12:50:50 PM
Actually there is a lot wrong with the entry checklists, nothing detrimental just simple order and missing breakers etc.  I will run through this and check it and post an updated checklist tomorrow after exams.

Just by curiosity, which checklists are you using for the changes you are making? When I made the entry checklists it was based off the "Apollo Entry Summary Document Mission C-Prime" document which unfortunately the link isn't working anymore.  The procedures were perfectly in-line with that document which seems to be very close to the actual procedures that were used on Apollo 8. I see there are some things that are not in that document, like shutting off the fuel cell pumps and other items and I saw you added them to the checklist. I do think the additions you made are good but Im thinking they are more in-line with the later missions, did you use the Apollo 15 entry checklists?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on December 20, 2016, 01:30:02 PM
Just by curiosity, which checklists are you using for the changes you are making? When I made the entry checklists it was based off the "Apollo Entry Summary Document Mission C-Prime" document which unfortunately the link isn't working anymore.  The procedures were perfectly in-line with that document which seems to be very close to the actual procedures that were used on Apollo 8. I see there are some things that are not in that document, like shutting off the fuel cell pumps and other items and I saw you added them to the checklist. I do think the additions you made are good but Im thinking they are more in-line with the later missions, did you use the Apollo 15 entry checklists?

I actually did not add the shutting down of the fuel cell pumps those were already there.  And I am using that very document, the entry summary, and also the A15 entry checklist kind of hybridizing the two.  The checklists as they were had some problems with the timeline, as well as little things like auto rcs switches in the wrong positions for cm rcs checks, but I think I did lean more towards the a15 entry checklists in the end, as it seems to work with our sim better.  I of course am open to suggestions!

Also here is the entry summary I have saved.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 20, 2016, 01:37:39 PM
NTRS was down for a while it seems, it is again online available: http://hdl.handle.net/2060/19700024999

Pretty much all checklists or related documents are better worked out for later missions than it was for a Apollo 8. So I don't mind if we deviate from the Apollo 8 in some places, as long as it works with our CSM. Staying close to Apollo 8 should be the goal though.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on December 20, 2016, 02:34:31 PM
Fair enough, I agree better for having procedures more inline with the later missions, looks good! Ill go make a run with it now...


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 20, 2016, 02:38:48 PM
Fair enough, I agree better for having procedures more inline with the later missions, looks good! Ill go make a run with it now...

Why don't you test something for me? Instead of flying a full mission, try the recently added MCC support for aborts. It's not a fully developed support, but because a bunch of abort Maneuver PADs are already displayed, I added some limited support for direct return aborts, flyby and early departure from lunar orbit. I have not tested a PC+2 maneuver or lunar orbit abort, so maybe that is something you could try. Here my changelog with a short description: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2863.msg25011#msg25011


Title: Re: Apollo 8 Beta Testing Bugs
Post by: macieksoft on December 20, 2016, 02:57:00 PM
Well, i have problems with Apollo 8 quickstart (VAGC T-60) scenario (i have not checked other A8 scenarios).
P37 return to earth gives me strange delta T values and enormous delta V.

Well, i am doing it following way:
-First i am updating SV with Project Apollo MFD.
-Then i am calling P37 and inputting some TIGs, i had to recycle it (V37N00, then V37N37 to start again and input new TIG) because in most cases coordinates of splash are unacceptable.
-When i finally get some acceptable splach coordinates with P37 i proceed with them, i input +00000 in R2 to compute minimum fuel return, then i am getting below 3 minutes delta T which is crazy, it gives not enough time to prepare for separation and reentry after P40 SPS thrusting!!!
-After P37 and i am making IMU orientation to option 2, the time is EI time so TIG + delta T (so its TIG + about 3 minutes).
-Delta V is also somehow big, when doing the burn with P40 it was keeping SPS firing for about 2 minutes!
-Also the burn orientation was somehow strange, it was firing SPS "downwards" (torwards the earth) instead of firing it near retrograde attitude.
-I found myself reentering atmosphere with CM attached to SM... I was bearly able to initialize EMS before i started to hear the air drag inside, not even time to do separation :evil

EDIT: Is it correct to recycle P37 by using V37E00E (V37N00)?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on December 20, 2016, 02:57:22 PM
Why don't you test something for me? Instead of flying a full mission, try the recently added MCC support for aborts. It's not a fully developed support, but because a bunch of abort Maneuver PADs are already displayed, I added some limited support for direct return aborts, flyby and early departure from lunar orbit. I have not tested a PC+2 maneuver or lunar orbit abort, so maybe that is something you could try. Here my changelog with a short description: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2863.msg25011#msg25011

Hmm could be fun... Is it as simple as say after any abort PAD during the mission, I hit request Abort and then fly the abort PAD and it will afterwards give you the required mid-course maneuvers and entry PADs for that particular abort?

EDIT: Ill go ahead and try a PC+2. Im starting from the launch T-60 scenario.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 20, 2016, 03:22:24 PM
Hmm could be fun... Is it as simple as say after any abort PAD during the mission, I hit request Abort and then fly the abort PAD and it will afterwards give you the required mid-course maneuvers and entry PADs for that particular abort?

That's how it should work. The abort sequence will always lead back to the normal Trans-Eart Coast sequence, so once you get nominal MCC Manuever PADs (MCC-5, MCC-6, or MCC-7) then you know you are back in the normal sequence of events and everything should work out just like usual.

Well, i have problems with Apollo 8 quickstart (VAGC T-60) scenario (i have not checked other A8 scenarios).
P37 return to earth gives me strange delta T values and enormous delta V.

Well, i am doing it following way:
-First i am updating SV with Project Apollo MFD.
-Then i am calling P37 and inputting some TIGs, i had to recycle it (V37N00, then V37N37 to start again and input new TIG) because in most cases coordinates of splash are unacceptable.
-When i finally get some acceptable splach coordinates with P37 i proceed with them, i input +00000 in R2 to compute minimum fuel return, then i am getting below 3 minutes delta T which is crazy, it gives not enough time to prepare for separation and reentry after P40 SPS thrusting!!!
-After P37 and i am making IMU orientation to option 2, the time is EI time so TIG + delta T (so its TIG + about 3 minutes).
-Delta V is also somehow big, when doing the burn with P40 it was keeping SPS firing for about 2 minutes!
-Also the burn orientation was somehow strange, it was firing SPS "downwards" (torwards the earth) instead of firing it near retrograde attitude.
-I found myself reentering atmosphere with CM attached to SM... I was bearly able to initialize EMS before i started to hear the air drag inside, not even time to do separation :evil

EDIT: Is it correct to recycle P37 by using V37E00E (V37N00)?

P37 is a little tricky to use. So from your quick reentry, I guess you separated from the S-IVB in Earth orbit before TLI? Did you load anything for R3 in Noun 60 or did you leave it to 0? This should still give a good result, however the lunar missions have a different EI angle polynomial, which means the AGC might have a hard time iterating to find the best entry angle for you. Not sure, haven't tried it with Apollo 8 and Earth orbit.

The strange attitude might be because it wants to reach a specific reentry angle, hard to attain with such a low orbit (100NM).

And you recycle P37 best with V32E. This will get you back to Noun 33 (Time of Ignition) which in Earth orbit will be the usualy parameter you want to change.

Ok, I just tried it myself. The AGC wants to have a -3.22° angle from Earth Parking Orbit. This is very high (because of the lunar mission parameter padload I talked about above) This requires a high DV and probably the weird attitude, making the trajectory steeper.

I want to research something about this topic. Probably still on the ground the astronaut got a Block Data PAD, like this for Apollo 16: http://history.nasa.gov/ap16fj/csmlc/a16L5-9.gif This could be a help for P37, but I also have to find a good procedure for this. I'll report back.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: macieksoft on December 20, 2016, 05:10:33 PM
So there is a value in PAD that changes behavior of P37?
Is there any way to change this padload?
I mean doing this trough DSKY and not trough mission editing.

And AFAIK in A11 scenario (in one of earlier NASSP 7.0 releases, in broken scenarios) i had no problems with deorbit burns, A11 is also a lunar mission.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 20, 2016, 05:25:57 PM
So there is a value in PAD that changes behavior of P37?
Is there any way to change this padload?
I mean doing this trough DSKY and not trough mission editing.

One way of doing is to play around with a manually entered flight path angle (R3 of N60). You could try values from -2° to -1° and look how much time you get between TIG and Entry Interface. It should be at least 15-20 minutes, I think.

If you want to load the parameter for the automatically chosen angle, use this procedure:

V24 N1E
1351E
6607E
11755E

This loads the parameter RTED1 used in the Apollo 7 and 9 scenarios.

Quote
And AFAIK in A11 scenario (in one of earlier NASSP 7.0 releases, in broken scenarios) i had no problems with deorbit burns, A11 is also a lunar mission.

Looks like the old Apollo 11 scenario never got the Apollo 8 parameter. That scenario was probably based on the more functional Apollo 7 scenario. The LVDC++ scenario, also using a different AGC version now, had the parameter for lunar missions since August 13th.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on December 20, 2016, 05:43:22 PM
Don't forget that when you use P37 in earth orbit, the parameter for splashdown longitude iteration is not VPRED, but TIG. Leave VPRED where it is and set GAMMAEI to 0. Longitude is then controlled by changing TIG. Increasing moves the long east, decreasing moves it west (or the other way round? Got to dig out my notes). When it's to close for you, add one orbital period and try again.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on December 20, 2016, 06:01:24 PM
You got it right, meik.

mackie, it's definitely a TIG shift for EPO. There's just not enough wiggle room that low to tweak entry angles and delta-V all that much.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on December 21, 2016, 10:16:39 AM
To be fair, neither the CSM GNC checklist nor the AOH state this in any way. The only place where you can find it is the GSOP, which is like putting it in the maintenance manual, but not in the user's manual. :Duh!39835:

Anyway, I'm aproaching MCC1 now: have we settled on any targeting data for RTCC MFD? I haven't found anything in the docs. I do have my own, but maybe somebody has found something better.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 21, 2016, 11:01:39 AM
To be fair, neither the CSM GNC checklist nor the AOH state this in any way. The only place where you can find it is the GSOP, which is like putting it in the maintenance manual, but not in the user's manual. :Duh!39835:

There are many good documents about P37 for lunar missions, but not for Earth orbit unfortunately.

Quote
Anyway, I'm aproaching MCC1 now: have we settled on any targeting data for RTCC MFD? I haven't found anything in the docs. I do have my own, but maybe somebody has found something better.

I have mostly used the numbers from the Spacecraft Operational Trajectory: http://web.archive.org/web/20100524045935/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740072753_1974072753.pdf

Target for the translunar MCCs would then be:

TIG: TLI+ 6 hours for MCC1
GET of pericynthion: 069:09:29 GET
Altitude 60.2NM
Latitude: -9.1°
Longitude: -174.8°

DV is usually about 16 ft/s.

There probably should be a list of targeting data (identical to those used by the MCC) for people who want to calculate these maneuvers with the RTCC MFD.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: macieksoft on December 21, 2016, 05:19:29 PM
So there is a value in PAD that changes behavior of P37?
Is there any way to change this padload?
I mean doing this trough DSKY and not trough mission editing.

One way of doing is to play around with a manually entered flight path angle (R3 of N60). You could try values from -2° to -1° and look how much time you get between TIG and Entry Interface. It should be at least 15-20 minutes, I think.

If you want to load the parameter for the automatically chosen angle, use this procedure:

V24 N1E
1351E
6607E
11755E

This loads the parameter RTED1 used in the Apollo 7 and 9 scenarios.

Quote
And AFAIK in A11 scenario (in one of earlier NASSP 7.0 releases, in broken scenarios) i had no problems with deorbit burns, A11 is also a lunar mission.

Looks like the old Apollo 11 scenario never got the Apollo 8 parameter. That scenario was probably based on the more functional Apollo 7 scenario. The LVDC++ scenario, also using a different AGC version now, had the parameter for lunar missions since August 13th.

Thanks. It worked for me. With automatic angle i got about 9 minutes delta T and then i used manual angle in R3 to get even more time (12 minutes). Entry worked well. MAX G computed was about 6G but in fact meter never shown more than 4. OFC burn orientation and burn delta V was all ok.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on December 22, 2016, 08:51:34 AM
Quote
GET of pericynthion: 069:09:29 GET
Altitude 60.2NM
Latitude: -9.1°
Longitude: -174.8°
That's about the same as mine, plus/minus some seconds/tenths of deg/NM. LOI-1 and -2 parameters?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 22, 2016, 09:33:40 AM
That's about the same as mine, plus/minus some seconds/tenths of deg/NM.

Your numbers are probably from the Mission Report, the actual numbers from the flown mission. The RTCC for the MCC is using the numbers from the Operational Trajectory document, so the planned numbers.

Quote
LOI-1 and -2 parameters?

TIM: 069:09:29 GET (this is the impulsive TIG, TIG with the finite burntime will be calculated from this number)
Apoapsis: 170NM
Periapsis: 60NM
Inclination: 167.7°

LOI-1 targeting will eventually be replaced by the actual targets used, which were target site + approach azimuth + time of pass over target site.

LOI-2 just needs the circular orbit height (60 NM) as an input. It will calculate the next possible LOI-2, so make sure the TIG is about 73:30:00 GET, and not one revolution earlier or later.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on December 22, 2016, 10:07:06 AM
Hmm...how does this LOI-1 (w/MCC) work? I calculate the MCC, then switch to it, insert the parameters and hit calc, right? It won't stop calculating here when I do it like this...or do I have to be in moon's SOI for that?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 22, 2016, 10:18:02 AM
There probably should be a safeguard against what you did...

The LOI-1 with MCC option is mostly for the LOI-2 REFSMMAT. The problem with that REFSMMAT is that it depends on the state of the spacecraft at LOI-2 ignition. Between the time the REFSMMAT is normally calculated and LOI-2 there are two maneuvers: MCC-4 and LOI-1.

The LOI-1 w/ MCC option then calculates the LOI-1 maneuver taking into account a MCC which was previously calculated. If you didn't do that, then the MFD probably tried to use a MCC at 000:00:00 GET with a DV of 0 ft/s which caused the problem.  :ROTFL3453: So I should probably implement something like: "If the DV is 0 then don't try to use it to calculate the trajectory".

If you have calculated both the MCC and LOI-1 you can go to the REFSMMAT menu and calculate the LOI-2 REFSMMAT. But if you have already done the last course correction and all you wanted to do was calculate the LOI-1 maneuver, then you have to use the LOI-1 without MCC (LOI-1 w/o MCC) option.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on December 22, 2016, 10:29:14 AM
I have calculated an MCC, there is data below 'MCC' in the display. Haven't done the MCC neither, so it should work, shouldn't it?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 22, 2016, 10:34:58 AM
Getting the same problem. Probably a RTCC MFD only problem. I'm investigating it.

EDIT: There were two bugs:

-Outside the Moon SOI it calculated a moon referenced state vector, but the trajectory propagation function thought it was Earth referenced.
-The never ending calculation came from a missing vessel mass calculation.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on December 22, 2016, 11:31:28 AM
During launch of the Apollo 8 mission I get a strange crash sound effect at skirt sep, anyone else hearing this?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on December 22, 2016, 11:35:39 AM
During launch of the Apollo 8 mission I get a strange crash sound effect at skirt sep, anyone else hearing this?

Yeah I hear it as well, not sure if its orbiter sound or NASSP.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on December 22, 2016, 03:45:35 PM
Well, I'm in lunar orbit.  :ThumbsUp432: Worked quite smooth, this RTCC MFD is sharp as knife, apart from some things:
- CMC'S N44 gives some strange figures for HA and HP with the LOI-1 target load. The burn itself is good, and V82 after the burn is almost on spot. Guess the CMC is doing nonsense here.
- PAD's and CMC's figures for roll attitude are off by some deg. Didn't bother me, though. P and Y are within some tenth of deg.
- First try with the LOI-2 REFSMMAT didn't work. P52 responded with alarm code 1301. Worked after uploading it again.
BTW: LOS was only 1 minute early. Impressive. :shock:


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 22, 2016, 03:57:18 PM
Well, I'm in lunar orbit.  :ThumbsUp432: Worked quite smooth, this RTCC MFD is sharp as knife, apart from some things:
- CMC'S N44 gives some strange figures for HA and HP with the LOI-1 target load. The burn itself is good, and V82 after the burn is almost on spot. Guess the CMC is doing nonsense here.

Do you mean Noun 42 in P30? That's normal behaviour. The LOI-1 is a long burn and the CMC simply adds the DV vector to the state vector at ignition for the HA and HP, so it's nonsense. At least for Apollo 11 the crew got both numbers with the LOI-1 Maneuver PAD:

Quote
072:51:24 McCandless: LOI-1, SPS/G&N: 62710, plus 0.98, minus 0.19, GET ignition 075:49:49.65; minus 2889.7, minus 0394.4, minus 0068.6; roll 358, pitch 226, 347; 0169.2, plus 00610; 2917.3, 6:02, 2910.8; sextant star 31, 1066, 358. Remainder of the PAD is NA. GDC align, Vega and Deneb, 243, 183, 012. No ullage. The horizon will be visible just below the upper edge of the hatch window 2 minutes prior to the LOI burn. It will not be visible in the rendezvous window on the left-hand side. LOS at 75 hours, 41 minutes, 23 seconds. AOS at 76:15:29. AOS without the LOI burn, 76:05:30. The values which you would see on Noun 42 prior to LOI burn are HA, plus 431.3; HP, minus 128.2. Read back, over.

The RTCC should usually give the Noun 44 values for a V82 after the burn. So the actually desired orbital parameters.

Quote
- PAD's and CMC's figures for roll attitude are off by some deg. Didn't bother me, though. P and Y are within some tenth of deg.

The CMC doesn't really care about the roll attitude at ignition. Maybe the CSM had already drifted off by the time you started P40?

Quote
- First try with the LOI-2 REFSMMAT didn't work. P52 responded with alarm code 1301. Worked after uploading it again.

No idea why it didn't work, but 1301 is probably caused by a broken REFSMMAT.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on December 22, 2016, 05:49:53 PM
Ok, one should read both digits after 'Noun'... :Duh!39835:
As said, roll doesn't really bother me, as long as pitch and yaw are good.
Another thing: LOS and AOS seem to be transposed on the map update display. I get AOS at LOS time and LOS at AOS time. Same for SS and SR.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 23, 2016, 06:47:22 AM
Ok, one should read both digits after 'Noun'... :Duh!39835:

Both nouns display apoapsis and periapsis, so it's easy to confuse them.  :ROTFL3453:

Quote
Another thing: LOS and AOS seem to be transposed on the map update display. I get AOS at LOS time and LOS at AOS time. Same for SS and SR.

That's one of the reasons why the map update didn't make it yet into the MCC calculations. I have to work on it some time again.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on December 24, 2016, 04:16:00 PM
And now to something completely different:
"Hey, don't take that, it's not scheduled." :wink:

Merry Christmas!


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on December 26, 2016, 12:14:28 AM
Awesome. ^_^

I'm doing that right now, although I was wondering—did anybody ever get any ridiculous results doing the P22 sightings?

Also, I think we can safely say that old telemetry client coded ages ago and the RTCC/MCC features don't work so well together. I tried doing a ground-initiated PIPA bias check, and found that none of the in-built uplink functionality would work anymore (SVs, REFSMMATs, etc.).

EDIT: I think it's due to indy's landmark shifting that P22 tracking is off. I know it was done to account for a spherical and flat moon, but I had a thought-when tracking an "above-ground" landmark, the projected LOS onto the flat ground is an ellipse, not a point. In any case, I can track B1 perfectly, but marking on CP2 causes MAJOR state vector shifts that make no sense...


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 26, 2016, 07:27:16 AM
I'm doing that right now, although I was wondering—did anybody ever get any ridiculous results doing the P22 sightings?

EDIT: I think it's due to indy's landmark shifting that P22 tracking is off. I know it was done to account for a spherical and flat moon, but I had a thought-when tracking an "above-ground" landmark, the projected LOS onto the flat ground is an ellipse, not a point. In any case, I can track B1 perfectly, but marking on CP2 causes MAJOR state vector shifts that make no sense...

The coordinates of CP2/8 in the flight plan and the actually tracked landmark (this is used for the marker file) are completely different. The flight plan value is:

Lat: -10.2°
Long: +155.1°

and the actually tracked one:

Lat: -09.638°
Long: +163.382°

So your bad P22 probably results from this. The "landmark shifting", shouldn't really be a factor for the Moon. The Moon is assumed spherical in the AGC, so if you simply set the altitude to 0 the AGC should never be confused about the location of a landmark.

I'm not sure if the flight plan version we have (November 22nd, 1968) is outdated in some way or if Jim Lovell simply tracked a landmark that is 8° in longitude from the flight plan coordinates. I'll check my library of PDF documents if I can find anything about that. But so far it seems very clear, the +163.382° landmark was the one that was actually tracked.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on December 26, 2016, 09:42:27 AM
When I read the transscript right, Jim just 'redefined' CP 2 because it was easier to find for him. Maybe this had something to do with their fogged windows. It was planned to visualy track the CPs through the hatch window during Rev 1 and 2, I guess to get familiar with them. As the hatch window wasn't usable, Jim might have looked out of one of the docking windows, but those don't cover the same FOV as the hatch window (they have a 'blind spot' beween them, which is normally covered by the hatch window). Jim couldn't find CP 2 because of that, so he picked another recognisable feature for him.
But good to know that 'F9' CP 2 isn't flightplan CP2. I've recently tracked it with the 'unkown landmark' option and got good dV and dR, but 'bad' coordinates. As, to put it german 'nicht sein kann, was nicht sein darf', I figured that orbiter's definition might be wrong. Now I know what's wrong...


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 26, 2016, 09:53:40 AM
So, I guess this is one of the cases where we should use the planned coordinates instead of the actual tracked coordinates? In the "Revision I to the Attitude Sequence for the Apollo 8 Spacecraft Operational Trajectory" document from December 12th, 1968 the coordinates are still those from the flight plan. So I guess it is safe to say that these are the intended coordinates for CP2 on launch day.

I'll probably change the marker file then to have the flight plan values for all the landmarks. At least in Orbiter 2010 you can't really find a recognizable landmark on the surface to track during the next few revolutions. So letting the user find their own landmarks like Lovell doesn't make much sense.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on December 27, 2016, 12:38:49 PM
Why don't you test something for me? Instead of flying a full mission, try the recently added MCC support for aborts. It's not a fully developed support, but because a bunch of abort Maneuver PADs are already displayed, I added some limited support for direct return aborts, flyby and early departure from lunar orbit. I have not tested a PC+2 maneuver or lunar orbit abort, so maybe that is something you could try. Here my changelog with a short description: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2863.msg25011#msg25011

I am at the point of doing the PC+2 fast return burn at around 071:13:19. However there is one issue, I have the Entry REFSMMAT being uplinked 45 mins after the pericinthyon and not after the burn itself. I believe in the notes you said on PC+2 aborts it should uplink the REFSMMAT 45 mins after the burn? I dont know if I did the procedure wrong, which was I got the PC+2 fast return PAD at around 50 odd hours MET, I then initiated the abort through MCC menu.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 27, 2016, 12:55:10 PM
It's a bug and you did everything correctly. I implemented the logic for the abort maneuvers, so that the Entry REFSMMAT is uplinked at the correct time for flyby, PC+2 and fast PC+2 maneuvers. But I forgot to remove the "safe guard" for the fast PC+2 maneuver. So it didn't store the latitude, longitude and most importantly the times for TEI and Entry Interface. I'll fix that. What you can do is take a scenario before PC+ 45 minutes, and fix the RTCC section:

-"RTCC_TEI" has to be the time in seconds of the "TEI" maneuver, in this case PC+2. I don't know the exact time, but you probably have it displayed or saved in the scenario as "MCC_AP11MNV_GETI".
-"RTCC_SplLat" and "RTCC_SplLng" have to be the landing coordinates in radians. For the fast PC+2 maneuver the longitude should be "1.134464014". You might find it in the MCC section of the scenario as "MCC_AP11MNV_lat" and "MCC_AP11MNV_lng".
-"RTCC_EI" is the entry interface time in seconds. If the Maneuver PAD is saved in the scenario you can find it as "MCC_AP11MNV_GET05G".

This should be all you have to fix. If it is too much of a hassle then you have to go back to before the Fast PC+2 Maneuver PAD was calculated. Sorry for the bug.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on December 27, 2016, 01:16:00 PM
Thanks indy! Ill try it out. Also, I've noticed that as you said before the trans earth timeline is too tight for the fast return transfer of only about 35 hours or so. In the MCC sequencing I noticed MCC-6 is set at TEI+31 hours, which would be almost at re-entry lol. I changed it to TEI+19 hours in MCC.cpp, just so it would work with the fast return. Maybe we could make a clause so that  "case MST_CP_TRANSEARTH3: //MCC5 Update to MCC6 Update" is skipped if on a fast return abort?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 27, 2016, 01:32:12 PM
Thanks indy! Ill try it out. Also, I've noticed that as you said before the trans earth timeline is too tight for the fast return transfer of only about 35 hours or so. In the MCC sequencing I noticed MCC-6 is set at TEI+31 hours, which would be almost at re-entry lol. I changed it to TEI+19 hours in MCC.cpp, just so it would work with the fast return. Maybe we could make a clause so that  "case MST_CP_TRANSEARTH3: //MCC5 Update to MCC6 Update" is skipped if on a fast return abort?

Yeah, I think it would be good to implement a general "skip this mission state" condition. In the case of the Trans-Earth MCCs the maneuvers should be skipped if the time for MCC-7 would already be reached. So with the Fast PC+2 MCC-5 should still be at the nominal time, but MCC-6 would be directly skipped, because TEI+31 hours > EI-2 hours. MCC-7 will then happen at the nominal time again. There is probably no scenario in which MCC-5 would be skipped in this way.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on December 27, 2016, 01:45:56 PM
So if I understand, because TEI+31 hours > EI-2 hours, it should already skip MCC-6 if doing a fast abort, and I could revert the modification I did for MCC-6 from TEI+19 hours, back to + 31 and it should be skipped?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 27, 2016, 01:53:38 PM
So if I understand, because TEI+31 hours > EI-2 hours, it should already skip MCC-6 if doing a fast abort, and I could revert the modification I did for MCC-6 from TEI+19 hours, back to + 31 and it should be skipped?

No, that is just my idea how it could be implemented. It doesn't work that way yet. Right now it would just go through the MCC-6 phase way too late and then immediately calculate MCC-7. But by then splashdown has probably already happened. Skipping mission states is not quite straight forward, I'll think about if it can be done without rewriting half of the MCC.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on December 27, 2016, 01:55:13 PM
No, that is just my idea how it could be implemented. It doesn't work that way yet. Right now it would just go through the MCC-6 phase way too late and then immediately calculate MCC-7. But by then splashdown has probably already happened. Skipping mission states is not quite straight forward, I'll think about if it can be done without rewriting half of the MCC.

Sounds good, Ill keep MCC-6 at TEI+19 hours so that it sequences correctly, and continue the mission.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 27, 2016, 02:00:21 PM
Sounds good, Ill keep MCC-6 at TEI+19 hours so that it sequences correctly, and continue the mission.

You'll also have to change something in rtcc.cpp. In MCC.cpp the time is for calculating and displaying the Maneuver PAD. This should be about 90 minutes before the burn. The actual TIG is defined in rtcc.cpp. Just change the line

Code:
MCCtime = calcParams.TEI + 33.0*3600.0;

to whatever you want. If the calculation time is TEI+19.5 hours then the MCCtime should be TEI+21 hours. That should work out for the fast PC+2. The maneuver is probably skipped anyway, because of a small DV.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on December 27, 2016, 02:12:55 PM
You'll also have to change something in rtcc.cpp. In MCC.cpp the time is for calculating and displaying the Maneuver PAD. This should be about 90 minutes before the burn. The actual TIG is defined in rtcc.cpp. Just change the line

Code:
MCCtime = calcParams.TEI + 33.0*3600.0;

to whatever you want. If the calculation time is TEI+19.5 hours then the MCCtime should be TEI+21 hours. That should work out for the fast PC+2. The maneuver is probably skipped anyway, because of a small DV.

Got it..Thanks!


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 27, 2016, 03:20:14 PM
Do you have a scenario for me after the Fast PC+2 maneuver? Or if you haven't fixed the scenario yet, any pre PC+45 minutes scenario? I want to test an idea how to implement skipping MCC-6. All it will do is fix abort support for the MCC functionality, so it's not really a new feature. I wouldn't want to implement new features in a Release Candidates ;)


Title: Re: Apollo 8 Beta Testing Bugs
Post by: dseagrav on December 27, 2016, 04:46:34 PM
The thread got screwed up somehow so I deleted the last post; I think it was jalexb88's but I'm not 100% sure.

Edit: It was. Try reposting I guess?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 27, 2016, 04:49:07 PM
Here it is at 70:30:00 ~45 mins before TIG. Ive also included a screenshot of the PAD as it was overwritten by MCC-4, but I didnt perform, MCC-4, just took advantage of the free SV update...too lazy for P23s  :ROTFL3453:   I initiated the abort right after the MCC-4 PAD came out.

I have seen posts break like yours, not sure what causes it.

MCC1-4 are ok to be calculated before the abort is initiated, they don't overwrite the parameters required for the Return to Earth sequence. I've tried the Fast PC+2 burn and then used 100x time acceleration. MCC-5 will be only 3.1 ft/s and it's a corridor control maneuver; only if more than 24 hours are between MCC and EI longitude control will be done. But no problem, the landing point is barely shifted because of this. It's still right in the middle of the Arabian Sea. Now I just have to continue flying until the next MCCs.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on December 28, 2016, 03:59:04 PM
As I said in the other thread, the support for the time critical return (Fast PC+2 maneuver) is now implemented. I have tested that flyby mission to its conclusion now. It really is a time critical abort, because it reaches the absolute limit for the reentry velocity: 36937 feet per second at 0.05g, so about 1000 ft/s faster than your usual return from the Moon. Here a scenario at EI-2 minutes. Have fun playing around with it, the EMS is still very accurate at this speed, although it really is on the limit what the EMS can support. A few seconds in the wrong orientation during the first part of the reentry and you are dead.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on January 13, 2017, 12:42:30 PM
I have a documentation correction to report. For P37, step 10, it should say that you record *R3* as delta-Vzp1, not R2. Also, you V32E to step 13, not PRO. Otherwise, you move on to step 15.

On a related note, I've been doing the P37 exercises in AP8, and IDK if I should expect this, but I can't shift my impact longitude using the iterative procedure in the documents—among other things, I get no difference in dV between the two conic solutions (initial, then the one with 10fps input adjustment to make the longitude shift). Is it way too ineffective just inside the Earth's SOI, or am I making a mistake?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on January 13, 2017, 01:23:11 PM
During TLC or TEC? What was your initial value for DV: a PAD value or zero? Also don't forget that you have to use the high speed procedure (-MA) from the CMP checklist during a nominal TEC, or else P37 will run into a constraint.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on January 13, 2017, 01:28:30 PM
TEC. I was doing the P37s after P23 sets. Since I wasn't getting P37 block pads after TEI, I used the RTCC to generate a block data (timed for MCC6, Mid Pacific, angle at 0.0 for auto angle control), and it gave me an input dV of 2fps. The input dV in N40 after I ran the conic solution was 1820.7 fps.

Do we have the high-speed procedure in any of our checklists? Because I don't see it in the flight plan scan I got from the Virtual AGC page.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on January 13, 2017, 01:53:35 PM
Only in the flown CMP Checklist in the No Comm part: https://drive.google.com/open?id=0BzUu_aREm1xST0tIOHFhWGhBVVk But we should probably use that procedure in our word checklist, too. Just a shame it's missing a few of the charts for longitude control. The Checklist MFD probably already has the -MA procedure.

And I don't think anything is written in Noun 40 on Colossus237/249. That is done in later versions, starting with Comanche.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on January 13, 2017, 01:55:28 PM
So instead, we should use the 3-axis velocities in N81 for conic and precision, and then just get DV magnitude from that?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on January 13, 2017, 02:07:28 PM
You can probably use that DV with the procedure for later missions. There is also a very similar procedure for Apollo 10 (http://history.nasa.gov/ap10fj/pdf/a10-crew-charts.pdf) but there Noun 40 is already loaded with the DV magnitude.

The Apollo 8 longitude control (starting on page NC-7) depends on charts we would probably be able to find in this document: https://airandspace.si.edu/collection-objects/graphs-and-charts-apollo-8 Now we only need to find that as a PDF. :D I guess I could ask David Woods about it, who is the source of of the CMP Checklist. And I also wonder why these available documents aren't uploaded to the Apollo Flight Journal page for Apollo 8...


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on January 13, 2017, 02:52:24 PM
Well, I'm also kinda worried about the CMP checklist, anyways. LOL

I looked at the -MA procedure, and it says to read a value called GREU from erasable address 1107, which maps to the MSW for the altitude calculated in P21. Is this the fancy way of saying "round this value down to a precision of 64nm, and use it in the chart?" Because GREU isn't labeled as such in the assembly listing.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on January 13, 2017, 03:00:05 PM
I think it's just an altitude check, but P21 can of course not display an altitude above +9999.9NM, so instead the EMEM address is accessed directly to see if the altitude is ok to try P37 with a negative major axis constraint, which potentially causes a hyperbolic return trajectory. Back when we talked about this procedure I calculated the given number 07990, which is: 141,369.5 NM. Also, the "GERU vx. radial speed" chart isn't actually in the CMP checklist, is it?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on January 13, 2017, 04:18:50 PM
No, it's not. We could try reconstructing based on the K charts we got with Apollo 15, which was just difference in conic solution longitudes over dV difference between conic solutions. We could get something useful out of that.

Also amused by the note in the N.C. procedures prior to TLI+23 about the W-matrix reinitializing: "MIT says no but NASA says yes." Did MIT think it was excessive, or was it more of an "OMG pls no u don't know wut ur doin"? haha


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on January 13, 2017, 04:47:12 PM
No, it's not. We could try reconstructing based on the K charts we got with Apollo 15, which was just difference in conic solution longitudes over dV difference between conic solutions. We could get something useful out of that.

Also amused by the note in the N.C. procedures prior to TLI+23 about the W-matrix reinitializing: "MIT says no but NASA says yes." Did MIT think it was excessive, or was it more of an "OMG pls no u don't know wut ur doin"? haha

Haha I just noticed this a few weeks ago and got a kick out of it, and it started a pretty in-depth banter between my girlfriend (also a space nut) and I regarding lost comms and what the astronauts would actually do in this situation :P


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on January 13, 2017, 05:18:52 PM
I'm not sure where I am getting this from, maybe reading a bunch of Tindallgrams, but the original MIT concept for the W-Matrix was to let it run for the majority of a mission. That way you could always keep track of the accuracy of the current state vector onboard. When the W-Matrix gets to big either a state vector update from MCC-H or onboard tracking has to be done. This could of course also originate from the earlier development of the AGC, when it was supposed to be much more self-sufficient than the final product.

Operationally it of course makes sense to not only have an indication of absolute state vector accuracy but also between phases of tracking and general convergence of a tracking phase.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on January 15, 2017, 09:49:12 AM
So running Apollo 8 to test the checklist edits, I constantly CTD at 3m16s into launch.  I cannot pinpoint the cause but its right around tower jett.  Anyone mind taking a look?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on January 15, 2017, 10:19:04 AM
You saved the scenario at about T-11 seconds. At that point Guidance Reference Release has already happened (at T-17 seconds) and the LV IMU is measuring accelerations. Currently saving during phases where accelerations are measured, which is launch, TLI, whenever a P4X program is running, doesn't work. If you look at the lvlog.txt file you will see that the acceleration readings in the first timestep are way too high. And once the IGM is started the crash happens.

That's why I usually save a prelaunch save somewhere between the last crew input (GDC align) at T-45 seconds and GRR at T-17 seconds.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on January 15, 2017, 03:40:42 PM
Good to know!  Thanks for the info that makes perfect sense.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on January 16, 2017, 11:39:28 AM
Getting excited to see this get released! Indy, is there anything in particular you would like me to do? Maybe I can take care of creating the Apollo 8 scenarios or something like that, I've only flown that mission about 500 times or so.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on January 16, 2017, 11:47:28 AM
Sure, you can do that. Remember to use the MCC+Checklist MFD for the whole mission. If you find Checklist MFD or documentation issues then fix them or let them get fixed along the way. I'm doing the same for Apollo 7 still, at about 45h GET right now. Use this thread as a guideline: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2919.0 I don't really think we need a T-20 minutes scenario though.

EDIT: rcflyinghokie is doing some checklist changes for the launch through TLI right now, so best coordinate with him about that.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on January 16, 2017, 12:05:34 PM
As Indy said, I am currently working through TLI right now changing some orders to match the flown checklist.  If you guys find issues let me know and I will add them :)


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on January 17, 2017, 10:00:57 AM
So part of the insertion checklist has a step to open breakers "1 and 2" on panel 278.  This is the uprighting system compressors and the SIVB/LM SEP pyros.  Now does this mean all 4 breakers open or did Apollo 8 perhaps not have the SIVB/LM SEP pyro breakers installed?  And if it did have them installed, wouldn't they be opened before launch and never used?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on January 17, 2017, 10:41:44 AM
The Entry Checklist has it as "UPRIGHT SYS COMPRESS cb(both) - close" again. Considering that these two circuit breakers are labeled "1" and "2" the circuit breakers on panel 278 might be identical to later flights and it is just a minor checklist deviation.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on January 17, 2017, 10:47:31 AM
The Entry Checklist has it as "UPRIGHT SYS COMPRESS cb(both) - close" again. Considering that these two circuit breakers are labeled "1" and "2" the circuit breakers on panel 278 might be identical to later flights and it is just a minor checklist deviation.

Thinking about it, I bet they did have the SIVB/LM SEP breakers installed there because this CSM was originally slated to take a LM up if I am not mistaken, in which case they probably ought to be open before launch and left open.  I will treat this piece as the uprighting system breakers. 

EDIT:  In that case though were these breakers closed before launch?  Our current checklist has the SIVB/LM sep breakers closed and the uprighting system open before launch.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on January 17, 2017, 11:28:33 AM
Our current checklist has the SIVB/LM sep breakers closed and the uprighting system open before launch.

That's how it is in the AOH Volume II as the liftoff configuration. But that AOH is for the J-Series missions of course.  I wouldn't worry too much about it, the current setup for launch seems fine. Put it in the insertion checklist, if you want, that way it will still confirm that the two circuit breakers are in the correct position. If we ever find the exact liftoff switch positions for Apollo 8 then we can still close the circuit breakers pre launch.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on January 18, 2017, 07:49:51 AM
We have a procedural error in the battery charging checklists in the Checklist MFD, both in Apollo 7 and 8. Both Battery Relay Bus circuit breakers are currently opened. But only the CB for the battery being charged should be opened. With the current checklist the Battery Relay Bus would be left unpowered (check System Test Meter 4B). The reason to open the circuit breaker is that only the other battery (A or B) should power the Battery Relay Bus while the other battery gets recharged. It doesn't seem too bad in NASSP right now, the Battery Relay Bus only powers a few fuel cell and Inverter controls, which then couldn't be used during the battery charging.

Can you fix that in the Apollo 8 checklist @rcflyinghokie? So only the A circuit breaker is opened while battery A is being charged, only the B circuit breaker is opened while Battery B is charged and probably both of the circuit breakers are left closed when Battery C is being recharged.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on January 18, 2017, 08:13:05 AM
Can you fix that in the Apollo 8 checklist @rcflyinghokie? So only the A circuit breaker is opened while battery A is being charged, only the B circuit breaker is opened while Battery B is charged and probably both of the circuit breakers are left closed when Battery C is being recharged.

Yep no problem

EDIT:  Posted the first of the checklist changes based on the TLI documentation along with the Battery Charge fix.  Will push the checklist with the post TLI (SEP TD&E) changes this weekend.  Let me know if there are any issues.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on January 20, 2017, 05:09:00 PM
Some points regarding the reentry (applies to AP7, too):
- you need to punch in both CM RCS HTRS cbs for pre-heating; checklist MFD doesn't call for it. As we talk about it: we should hardwire system test meter channels 5C & D and 6A - D  to 4 volts or more, so that pre-heating can be omitted. AFAIK no mission did a CM RCS pre-heat.
- the CM RCS PRESS switch is springloaded to down (off). On is only momentarily.
- CM RCS CHECK: either we do it as per AP15 checklist via the AUTO RCS switches or as per AOH (pulling the SCS ROLL, PITCH and YAW cbs), but not with the CM RCS PRPLNT switches. Anyway, the way checklist MFD wants it, you come out with both rings armed; it should be only one.
- either CMC's or RTCC's alpha value is wrong. CMC seems to have the better one, IMHO.
- the crew-dies-despite-open-hatch-issue is really odd...



Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on January 20, 2017, 05:27:37 PM
Some points regarding the reentry (applies to AP7, too):
- you need to punch in both CM RCS HTRS cbs for pre-heating; checklist MFD doesn't call for it.

I'll check it for Apollo 7.

Quote
As we talk about it: we should hardwire system test meter channels 5C & D and 6A - D  to 4 volts or more, so that pre-heating can be omitted. AFAIK no mission did a CM RCS pre-heat.

I might as well add a static temperature for the CM RCS oxidizer valves and then correctly wire it to the PCM, where the voltage conversions of the SCE are currently done. Then whenever the temperatures actually become simulated, the rest is already done.

Quote
- the CM RCS PRESS switch is springloaded to down (off). On is only momentarily.

I'll fix it.

 
Quote
- CM RCS CHECK: either we do it as per AP15 checklist via the AUTO RCS switches or as per AOH (pulling the SCS ROLL, PITCH and YAW cbs), but not with the CM RCS PRPLNT switches. Anyway, the way checklist MFD wants it, you come out with both rings armed; it should be only one.

I'm not sure if the early mission nominally used one ring. I'll have to check the Entry Checklist. We actually have the flown one for Apollo 8 now. I'll post it soon, should be on the AFJ at some point, too.

Quote
- either CMC's or RTCC's alpha value is wrong. CMC seems to have the better one, IMHO.

I'm not sure what you mean by alpha.

Quote
- the crew-dies-despite-open-hatch-issue is really odd...

Does this happen directly after the hatch is opened after splashdown?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on January 20, 2017, 05:39:30 PM
Quote
I'm not sure what you mean by alpha.
I guess the EMEM name is ALPHAPAD, the pitch angle to local vertical the CM settles to during entry. Before 0.05g the CM DAP tries to keep the pitch angle around that, but RTCC's PAD and CMC don't agree.
Quote
Does this happen directly after the hatch is opened after splashdown?
No. The crew dies because of excessive CO2. Before splashdown, both BUS TIEs are switched off, which stops the suit compressor, so that the CO2 isn't removed any longer. Neither post landing ventilation nor the open hatch seem to bring fresh air into the CM.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on January 20, 2017, 05:48:26 PM
I guess the EMEM name is ALPHAPAD, the pitch angle to local vertical the CM settles to during entry. Before 0.05g the CM DAP tries to keep the pitch angle around that, but RTCC's PAD and CMC don't agree.

So the pitch angle at 0.05g doesn't agree with the PAD value? I'll check the Entry PAD calculations then. Are you sure your REFSMMAT is identical to the one on the RTCC MFD?

Quote
No. The crew dies because of excessive CO2. Before splashdown, both BUS TIEs are switched off, which stops the suit compressor, so that the CO2 isn't removed any longer. Neither post landing ventilation nor the open hatch seem to bring fresh air into the CM.

I'll look into it. I don't know much about the ECS though. The atmosphere should be simulated as a really large tank, maybe something is wrong with that tank.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on January 21, 2017, 06:42:54 AM
I guess the EMEM name is ALPHAPAD, the pitch angle to local vertical the CM settles to during entry. Before 0.05g the CM DAP tries to keep the pitch angle around that, but RTCC's PAD and CMC don't agree.

They don't? I usually get around 150° pitch at 0.05G on the Lunar Entry PAD. That's a pretty usual value for historial Entry PADs, too. I just flew a reentry and the CM had about 152° pitch when the aerodynamics took over pitch control. Before the roll to lift vector down it has a few degrees more, but at that time the flight path angle isn't -6.5° anymore, so that is realistic.

I am using the value 157° pitched up from LVLH at 0.05G for the PAD attitude. I have to remember where I got this value from, but it seems to give me fairly good results. Maybe because of this value the attitude is a few degrees of, but it can't be more than 2-3°.

No. The crew dies because of excessive CO2. Before splashdown, both BUS TIEs are switched off, which stops the suit compressor, so that the CO2 isn't removed any longer. Neither post landing ventilation nor the open hatch seem to bring fresh air into the CM.

Maybe because the cabin and atmosphere pressures have already equalized, there is no air flow. There seems to be some extra code for the hatch that is not handled by the thermal engine, so maybe the problem lies there. Of course it could be that partial pressures are simply not equalized. In that case you just have to quickly reduce the crew in PAMFD to 0. :D

- the CM RCS PRESS switch is springloaded to down (off). On is only momentarily.

Can you give me a source on that? I can't find this in the AOH or checklists...


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on January 21, 2017, 08:25:34 AM
Quote
I usually get around 150° pitch at 0.05G on the Lunar Entry PAD.
Me too. CMC steers for about 157°, so the error needle never moves down. Which could lead somebody who follows the checklist by the letter to the assumption that the CMC is no go.
Quote
Can you give me a source on that? I can't find this in the AOH or checklists...
AOH Vol. 2, p. 4-544 states that 'On position is momentarily'. CSM 104 sys handbook p. 464 shows a little downpointing arrow on the switch, indicating that it is springloaded to down. A toggle switch wouldn't make sense; those are squib valves. Once they have been fired they remain open, whether there is voltage on them or not.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on January 21, 2017, 09:21:19 AM
- you need to punch in both CM RCS HTRS cbs for pre-heating; checklist MFD doesn't call for it

Fixed now in Apollo 8, but if Indy has the 8 Entry checklist I will comb over it as I did with boost and such.

EDIT:  Also I noticed the 8 SEP checklist does not re latch the fuel cells before separation.  Is this a checklist oversight or did they not do it?

EDIT 2:  I also noticed (and I did not know this before) that the primary procedure for CSM/LV separation was the turn the THC CCW, the CSM/LV SEP button is a backup according to the checklist.  I am assuming our panel is not coded to sep using the THC so should I just write the sep procedures how we need them using the backup procedure (arming the SECS pyros and CSM/LV SEP pb)?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on January 21, 2017, 09:29:32 AM
Me too. CMC steers for about 157°, so the error needle never moves down. Which could lead somebody who follows the checklist by the letter to the assumption that the CMC is no go.

The 157° is the pitch relative to LVLH at 0.05G used during the Entry PAD calculations, but the Entry REFSMMAT is defined for LVLH at Entry Interface. So the number 157° should lead to the PAD value at 0.05G. I have found the equations the AGC is using, so a more accurate angle can probably calculated relative to the flight path at 0.05G. But it still should be 152° at most, that is the usual number on the historical Entry PADs. I'm not sure why you are getting 157° pitch at 0.05G, the CMC gives me pretty much exactly 150°.

And here the Apollo 8 Entry Checklist for rcflyinghokie:  https://drive.google.com/open?id=0BzUu_aREm1xSY1YwT0wydW1qRFU There are two Entry checklists, this one is the better scan, the other document has a few more charts.

EDIT 2:  I also noticed (and I did not know this before) that the primary procedure for CSM/LV separation was the turn the THC CCW, the CSM/LV SEP button is a backup according to the checklist.  I am assuming our panel is not coded to sep using the THC so should I just write the sep procedures how we need them using the backup procedure (arming the SECS pyros and CSM/LV SEP pb)?

Nope, THC CCW doesn't work yet. That is one of the fun things I want to work on for the next version, with completed SECS for aborts etc.. If somebody else doesn't steal this job from me.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on January 21, 2017, 10:14:51 AM
I pushed the requested changes:

-CM RCS Press switch springloaded to down.
-The RTCC now uses the AGC method to calculate the attitude for 0.05G. There actually was an error in the calculations, the number 157° compensated for the flight path angle, but that wasn't necessary; the attitude was already calculated with the velocity vector and not as a LVLH orientation. This will usually change the pitch angle for 0.05G from 150° to 152°.
-Hardcoded temperatures for the CM RCS injectors. The temperature is 30°F, which is slightly above the minimum for which the CM RCS Preheat is not required.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on January 22, 2017, 04:03:42 AM
I'd already coded in THC abort for launches ages ago, but I may not have committed the changes properly. Oh well, we can do it better through the connectors, anyways.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on January 22, 2017, 01:51:50 PM
I have made a pull request for Apollo 8 Checklist MFD changes based on the TLI checklist up to the post CSM evasive maneuver procedures.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on January 22, 2017, 02:11:23 PM
I have made a pull request for Apollo 8 Checklist MFD changes based on the TLI checklist up to the post CSM evasive maneuver procedures.

Thanks! Am I good now to fly the whole mission, to create the Apollo 8 release scenarios with the current state of the checklist?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on January 22, 2017, 02:35:06 PM
Thanks! Am I good now to fly the whole mission, to create the Apollo 8 release scenarios with the current state of the checklist?

Unless you wanted to tackle it because you did a lot of the post TEI checklist, I was going to use the actual Apollo 8 entry checklist and make the necessary changes for accuracy.

Other than that, things look good from boost to MCC1, I have not tested anything further with the latest changes.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on January 22, 2017, 02:45:18 PM
Unless you wanted to tackle it because you did a lot of the post TEI checklist, I was going to use the actual Apollo 8 entry checklist and make the necessary changes for accuracy.

Other than that, things look good from boost to MCC1, I have not tested anything further with the latest changes.

Sounds good if you want to handle the Entry stuff I don't mind. I'm thinking of going ahead with the mission and scenario creation. I will only get to re-entry a few days from now at the earliest, so Ill pause once I get there to work (or test your work) on the entry checklist.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on January 22, 2017, 03:22:20 PM
Excellent, that works.  Also let me know if there any issues with the boost-CSM evasive maneuver checklists.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on January 26, 2017, 09:40:46 AM
I found one problem using the actual TLI checklist is it does not turn the cabin fans back on, I will add this back in post insertion in my next checklist update.  In the mean time, turn your cabin fans on so your cabin temp stays up ;)


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on January 26, 2017, 11:54:15 AM
I found one problem using the actual TLI checklist is it does not turn the cabin fans back on, I will add this back in post insertion in my next checklist update.  In the mean time, turn your cabin fans on so your cabin temp stays up ;)

There is also a double C&WS Operational Check in the insertion checklist. Is that intended? There's a few items I forgot to add at MCC-4 and at LOI-1 which Ill take care of.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on January 26, 2017, 01:03:20 PM
There is also a double C&WS Operational Check in the insertion checklist. Is that intended? There's a few items I forgot to add at MCC-4 and at LOI-1 which Ill take care of.

Nope thats a copy paste error, I will fix it :)


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 02, 2017, 08:46:29 AM
Just a status update I am about halfway with the revisions of checklist mfd with the Apollo 8 Entry checklist.  This have been a little slower I have been down with a pretty bad cold so I apologize with the delay.  I should have something pushed and ready for testing by the weekend.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on February 02, 2017, 09:01:28 PM
I have an issue to report.

Apparently sometime between the post-TEI entry REFSMMAT and the MCC-5 uplink, the MCC will no longer uplink to the AGC. This also applies for the RTCC MFD and the PAMFD. Anyone able to get a trace on it? Scenario included.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: abr35 on February 02, 2017, 10:07:57 PM
Try setting your PCM bit rate to low and then uplink - fixed it in your scenario for me. Never saw that on 8 but had it happen alot in the alpha-LEM on 11. As for the cause I have no idea as to whether or not it is a bug.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on February 02, 2017, 11:02:52 PM
Done. Worked. Awesome.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 03, 2017, 05:48:24 AM
That is a known problem. It indeed seems to affects all uplink methods, which means it is not an TCP/IP glitch as I previously thought. So it's probably a NASSP bug. I just looked for it for a while, but I haven't found the solution. It's a little bit hard to test when it happens fairly rarely.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 03, 2017, 07:55:56 AM
I have an issue to report.

Apparently sometime between the post-TEI entry REFSMMAT and the MCC-5 uplink, the MCC will no longer uplink to the AGC. This also applies for the RTCC MFD and the PAMFD. Anyone able to get a trace on it? Scenario included.

I loaded your scn and am able to uplink from all three of those without a problem.  Try switching the PCM BIT RATE switch from high to low to high and see if that works for you.

EDIT: Wow talk about a delay in the posts haha looks like it was already answered :)


Title: Re: Apollo 8 Beta Testing Bugs
Post by: Thymo on February 03, 2017, 09:19:10 AM
EDIT: Wow talk about a delay in the posts haha looks like it was already answered :)

I just had the same happen to me. :P
Don't forget to look if there's another page after the one you're on. haha


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 03, 2017, 10:00:49 AM
I was able to reproduce the problem and found the issue. It's pretty noteworthy actually. The problem is in this line of code:

Code:
tx_size = (int)((simt - last_update) / 0.00015625);

tx_size is the number of words the PCM can downlink per timestep (1/60 seconds at 60fps), in this case with the factor 0.00015625 in high bit rate, 0.005 is used for low bit rate. "simt" is the simulation time (the PCM uses the total mission time) and last_update is the time since the last time a PCM I/O was performed. Usually the difference between simt and last_update would be the same 1/60 seconds. On the first timestep however, when Orbiter is started, then last_update is 0. Only after the first timestep last_update becomes the "old" simt.

And this causes tx_size to overflow. The highest possible number for an int is 2,147,483,647 and if I use this as tx_size and reverse calculate simt and keep last_update as 0 then I get a simt of 93.2 hours. So with the bit rate switch in high when a scenario loaded, and only if the GET is 93.2 hours or higher then tx_size overflows and becomes a negative number. Why is that bad? There is a check in place if tx_size is between 0 and 1024, or else no input/output of the PCM is performed. So that then never happens. Setting the bit rate switch to low solves the overflow situation, last_update will also be processed then and will be not 0 anymore. So setting the switch back to HBR then is no problem.

@dseagrav: Do you have any idea why tx_size has to be between 0 and 1024? Now that we know the problem, maybe you can fix it. You know more about the PCM. Should there just be maximum allowed number for tx_size before it gets converted to integer?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on February 03, 2017, 03:48:40 PM
Awesome.

BTW, has ANYBODY managed to get a -MA P37 solution out of the AGC yet? I've tried multiple times, but the computer seems to just want to stick with the elliptical solution.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 03, 2017, 04:17:38 PM
Yes, P37 with -MA works great for me. So it still gives you a large DV (about 50 ft/s) despite the procedure? Are you following the Apollo 8 CMP Checklist or my earlier description of the procedure? The CMP Checklist has it on page N.C.-1. The procedure has to be done before the conic solution is finished iterating, so you have to be quick.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on February 03, 2017, 08:03:23 PM
I've punched it in ASAP, way before I get the KEY REL indicator. But when the precision solution runs, it converges to the same elliptical solution that P37 would normally provide. And based on RTCC's targeting of a high-speed reentry (the Abort option), I should be getting a dV in excess of 2500 fps, primarily radial. Here's my results from my last run after MCC5:

GERU: 7916
GET: 114:18:00.52
GET(EI): 146:41:19.21
LONG: -160.74°
dT trans: 32:23:18.69
V400k: 36222
dLong: -2.85
LONG(corr.):-163.49
dVx: 0.9
dVzL: 2500 fps
V400k(avg): 36400
K: .006
dVxL: 15 fps

This is based on using the GERU v. radial velocity chart, and noting that the constant-dT lines correspond to approximately 30° of longitude shift.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 04, 2017, 06:47:27 AM
I'm still trying to understand the P37 charts myself. So you are trying to do a longitude shift? Into the Atlantic Ocean, if I understand your RTCC MFD inputs correctly? Also, does the 6.6° ReA mean anything or did you just play around with it? You can just use 0.0° of course and it will calculate the angle for you; the same angle as the AGC.

I tried your scenario, let the uplink happen and set the uplinked state vector into the CSM slot (V47). Then I tried a P37 with N60 as all zeros and the -MA procedure. The precision solution is DVX = -1.1 ft/s, the rest is 0. Now I enter the charts and I can follow until the GER vs. radial velocity chart. It gives me the same initial radial velocity as you, when I use the dT Transfer. About 2500 ft/s. And then what? How much longitude shift have you tried? Aren't you done with P37 after the initial run and then just calculate P30 inputs with the K-factor? I think you only go to point 3 of the procedure for MCC6 and later. Can you tell me more about your specific P37 inputs?

Also for your information, currently the reentry range is hardcoded as 1285 nautical miles in the RTCC. Apollo 8 used 1350 NM and for that the chart was created. That's why you get -163.49° and not exactly -165°. Apollo 10 used 1285 NM and they switched to 1250 NM at some point. These numbers will be mission specific preflight settings for the RTCC at some point.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on February 04, 2017, 11:32:40 AM
The 6.6 was RTCC generated from an all balls entry. I'll post a detailed procedure later.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 06, 2017, 08:26:44 AM
I finished the entry checklists and there are a few timing issues, once I go back and fly a complete reentry with it I will be submitting it for you all to test, sorry again for the delays!


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on February 09, 2017, 01:51:39 AM
OK, here's the detailed procedure I performed:

  • After MCC5 was completed, I performed a P21 when the first P37 iteration comes up in the checklist. I started at TEI+24 (around 113:18:00) as the event time, then inspected the raw altitude via V6N02 1107. Since it was above the 7990 stipulated in the manual, I advanced forward one hour, to 114:18, and got an altitude just under the range, the GERU listed in the post before this one. This gives me the TIG I should use.
  • I go into P37 with the TIG determined through P21, setting all balls for target dV and entry angle. After the conic solution starts, I move quickly to set the -MA option via V24N01 3651E 70000E,E. I finish this before the conic solution is complete.
  • Having set the option (basically loading a large negative semi-major axis as a minimum constraint in the iteration), I proceed through the displays to start the precision solution. I monitor the time of the integrated state vector as the checklist dictates. The precision solution does three passes of integration, but I am unsure if the repeated integrations fail the requirement for EI time oscillations to be lower than 5 hours or that so long as the time before the loop isn't differing more than 5 hours, it'll be fine.
  • Once the precision solution is complete, I record the T(EI), longitude, dT, v400k, and dV components. I then proceed out of P37 back to idling, and calculated the biased longitude based on v400k.
  • I then go to the GERU vs radial speed chart. I place a reference marker for my GERU and V400k as determined prior. Then, I move to the left of the chart approximately 4 dT curves to effect an approximate 135 degree longitude shift east to the mid-Atlantic zone. I place another reference mark here. The x-axis difference between the two provides my dVz for the burn, and I determine the average v400k between the two points using the curves associated with the value.
  • I get the K value from the average v400k and GERU, then use that to determine dVx.

I used RTCC in abort and all-balls mode to check the solution, which appears to agree. What was throwing me is that I expected P37 to converge to a solution that was radically different than the course I was already on with the -MA option set, but it converged to the same place. But is it just supposed to be that any converged solution after the option is set shows it's possible to create a high-speed solution?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 09, 2017, 05:26:48 AM
Ah, I think I understand your problem now.

The nominal Apollo 8 Moon-to-Earth trajectory has a major-axis that violates a constraint in P37 of Colossus 237/249. So with the P37 options set both to 0, all P37 should do is entry corridor control. But with the constraint violation P37 will try to slow you down and gives you a large radial upwards DV.

If you load the -MA, that constraint is now much more relaxed and would in theory allow a hyperbolic return. But remember that a 0 for the DV option in P37 tries to calculate a a Minimum DV solution. It won't try to achieve the loaded major axis, that is just the absolute maximum P37 will allow. If you give P37 a large DV it might try to accelerate towards the Earth and could then run into this new constraint. But if you had a good TEI then all the -MA procedure will accomplish is that your normal return trajectory to the Mid Pacific is allowed by P37.

I don't think loading a negative number is really necesary for Apollo 8, only in some specific abort cases maybe. So if you want to test what happens, just load the highest possible still elliptical (>0) major axis as MA. That would change the procedure to V24N01 3651E 37777E,37777E I am pretty sure that will also give you a P37 solution that agrees with the "ground solution" aka RTCC MFD.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 09, 2017, 09:37:41 AM
Question regarding CM/SM SEP.  Is the SEP attitude the same as 0.05G attitude with the 45 degrees of yaw added?  Or did they maneuver to a R and P for SM SEP that was different than the entry attitude?  And if that is the case, should it be added to the MCC thread for entry?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 09, 2017, 09:46:25 AM
They spent most of the time after MCC-7 in the 0.05G attitude. Then they pitch to the horizon check attitude and perform the horizon check at EI-17 minutes. From that attitude they move 45° out-of-plane, seperate the SM at EI-15 minutes and from then on track the horizon with the 31.7° line. At 0.05G they should end up at the 0.05G attitude again.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 09, 2017, 09:49:43 AM
Ah ok, that makes sense.  The checklist has a pitch written in as a SM SEP ATT however now I can see this just being the horizon attitude at separation, thanks!


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 09, 2017, 12:27:49 PM
And another question, I am seeing the steam pressure is supposed to peg when the CM hits 90k.  Does our ECS accurately simulate that?  And should the ECS indicators be on primary or secondary for this to peg?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 09, 2017, 12:46:00 PM
Both Primary and Secondary don't seem to move much during reentry. So we have to assume that it is not simulated yet. The only heat exchange happening for the ECS is with a primary and a secondary radiator in the SM. But even that probably just takes the static temperature and doesn't take into account the heat from the reentry.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 09, 2017, 01:47:33 PM
And now a power question, when the main bus ties are turned off at 800ft per the entry checklist, the entire CM goes dark, was this normal?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 09, 2017, 01:56:52 PM
I think so. Switching the main bus ties off kills your two main buses. But you should still have the Flight and Postlanding Bus, Battery Buses, Pyro Buses and the Battery Relay Bus. So all the systems necessary for postlanding activites should still be active, like ELS, Float Bags, SECS, Audio, Lighting etc. If not then there are some circuit breakers on 2XX panels not pushed in.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 09, 2017, 02:13:08 PM
I think so. Switching the main bus ties off kills your two main buses. But you should still have the Flight and Postlanding Bus, Battery Buses, Pyro Buses and the Battery Relay Bus. So all the systems necessary for postlanding activites should still be active, like ELS, Float Bags, SECS, Audio, Lighting etc. If not then there are some circuit breakers on 2XX panels not pushed in.

Ok so it was normal to lose the CMC, EMS, and ECS gauges before splashdown?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 09, 2017, 02:22:12 PM
I guess so. If the Main Bus Ties are switched to off then loosing the AC Buses and Main DC Buses will be the consequence, no way around it. They maybe wanted to protect the CMC and other systems from a short caused by water. And there also wasn't really a need to have the computer and EMS running anymore. And all the ECS you needed could be accomplished by opening valves to the outside.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 09, 2017, 02:25:41 PM
I guess so. If the Main Bus Ties are switched to off then loosing the AC Buses and Main DC Buses will be the consequence, no way around it. They maybe wanted to protect the CMC and other systems from a short caused by water. And there also wasn't really a need to have the computer and EMS running anymore. And all the ECS you needed could be accomplished by opening valves to the outside.

Ok that makes more sense, its just a little unnerving I suppose to still be aloft and everything just appears to die :P


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 09, 2017, 02:30:57 PM
There two PowerMergers, GaugePower and SwitchPower, which are powering a lot of the gauges and switches (not used at the moment) and those are powered by the Main Buses in NASSP. That is maybe not 100% realistic, some gauges will be powered by other buses. So maybe in the real CSM not all gauges go off when Main Bus power is lost. We'll have to look into that some day.

EDIT: Looking at the AOH, it really seems like 90% of the gauges are powered by the DC Main Buses.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 09, 2017, 02:35:13 PM
Always something more to investigate :)  Well with that answered I am going to push my checklist MFD file, let me know if there are any issues.  The timing worked out pretty well for my scn which I have posted here as well.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on February 11, 2017, 10:00:33 AM
Always something more to investigate :)  Well with that answered I am going to push my checklist MFD file, let me know if there are any issues.  The timing worked out pretty well for my scn which I have posted here as well.

Awesome! I am out of town until Monday night for work. When I get back I'll be able to finish the last scenarios with the completed checklists. Looks like we are very close to getting this out the door!


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 11, 2017, 10:09:37 AM
@jalexb88 Did you make some already for launch/TLI?  If so how did the checklists workout after I changed them using the actual ones?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on February 11, 2017, 08:38:33 PM
Ah, I think I understand your problem now.

The nominal Apollo 8 Moon-to-Earth trajectory has a major-axis that violates a constraint in P37 of Colossus 237/249. So with the P37 options set both to 0, all P37 should do is entry corridor control. But with the constraint violation P37 will try to slow you down and gives you a large radial upwards DV.

If you load the -MA, that constraint is now much more relaxed and would in theory allow a hyperbolic return. But remember that a 0 for the DV option in P37 tries to calculate a a Minimum DV solution. It won't try to achieve the loaded major axis, that is just the absolute maximum P37 will allow. If you give P37 a large DV it might try to accelerate towards the Earth and could then run into this new constraint. But if you had a good TEI then all the -MA procedure will accomplish is that your normal return trajectory to the Mid Pacific is allowed by P37.

I don't think loading a negative number is really necesary for Apollo 8, only in some specific abort cases maybe. So if you want to test what happens, just load the highest possible still elliptical (>0) major axis as MA. That would change the procedure to V24N01 3651E 37777E,37777E I am pretty sure that will also give you a P37 solution that agrees with the "ground solution" aka RTCC MFD.

Thing is, though, that according to the Orbit MFD, my return trajectory is elliptical, not hyperbolic, and there shouldn't be an SMa conflict, unless that SMa upper limit is smaller than the nominal return...


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 12, 2017, 04:51:47 AM
unless that SMa upper limit is smaller than the nominal return...

That is exactly the issue and why the -MA procedure had to be used. Both for the nominal Apollo 8 return and some abort cases. The maximum major axis P37 allows in Colossus I and IA (Apollo 8 and 9) is 8e8. Take half of that and you have the maximum semi-major axis. 4e8 is about a lunar distance, how they ever thought that was going to be enough...


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on February 12, 2017, 05:29:06 PM
@jalexb88 Did you make some already for launch/TLI?  If so how did the checklists workout after I changed them using the actual ones?

Yes they are committed up to LOI-1. The checklists are fine except very minor things like the double C&W checklist witch you already corrected. The only other thing I can think of is that there is no direction to put FDAI#1 from orb rate back to inertial after TLI is complete.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 12, 2017, 07:44:05 PM
The only other thing I can think of is that there is no direction to put FDAI#1 from orb rate back to inertial after TLI is complete.

I was curious about this too since the TLI checklist does not have this part.  I remember adding that "secure ordeal" after TLI originally and I removed it to match the actual checklist because I do not know when they actually did switch it back to inertial or secure for TLC.  I will do a little more research and see if I can get an answer, if not, I will throw in switching it back to inertial for TLC in preparation for the next MCC.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on February 14, 2017, 10:54:34 AM
I was curious about this too since the TLI checklist does not have this part.  I remember adding that "secure ordeal" after TLI originally and I removed it to match the actual checklist because I do not know when they actually did switch it back to inertial or secure for TLC.  I will do a little more research and see if I can get an answer, if not, I will throw in switching it back to inertial for TLC in preparation for the next MCC.

I just made a pull request with a modification to the Apollo 8 checklists. It does not affect your latest changes, I just modified a few things between MCC-4 and TEI.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 14, 2017, 11:48:19 AM
I just made a pull request with a modification to the Apollo 8 checklists. It does not affect your latest changes, I just modified a few things between MCC-4 and TEI.

I have a few edits to TLI as well, nothing major just smoothing out timing of hidden delays and the like.  I will fold them into your modifications and make my own pull request after


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 14, 2017, 12:09:00 PM
I found an interesting discrepancy, we used the apollo 15 launch checklist to configure for launch I am assuming.  Based on that, the pyro arm switches are turned on as part of the pre launch checklist.  However, lacking a pre launch checklist for apollo 8, I am wondering if this was done.  I noticed that the pyro arm switches are up for the entire portion of launch, TLI, and SEP.  Nowhere in the 8 TLI checklist does it say to either arm or safe these switches.  Were they possibly left locked in the up position throughout these events and power controlled through the breakers (the arm breakers are positioned via the checklist)?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 14, 2017, 12:57:00 PM
Pretty sure all other lunar missions got a "Go for Pyro Arm" before TLI, during the TLI Prep checklist. Apollo 8 didn't seem to have gotten this call. So maybe they controlled it with the breakers.

The Translunar Procedures document (see http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=983.msg23769#msg23769) has the switches in safe and that checklist begins after TLI.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on February 15, 2017, 02:11:24 PM
I have a few edits to TLI as well, nothing major just smoothing out timing of hidden delays and the like.  I will fold them into your modifications and make my own pull request after

Just flying re-entry right now. The "Final Entry Pad, CSM and LM state vectors, entry target" should be before the EMS Initialization and RSI test & setup (right after Update DET up, to EI). Or else we are using the preliminary PAD to setup the EMS, we want to use the final PAD for that.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 15, 2017, 05:26:39 PM
flying re-entry right now. The "Final Entry Pad, CSM and LM state vectors, entry target" should be before the EMS Initialization and RSI test & setup (right after Update DET up, to EI). Or else we are using the preliminary PAD to setup the EMS, we want to use the final PAD for that.

You are correct, consider it fixed!  Just need to make sure the timing still flows right.  Give it a whirl since you have an active entry scn?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on February 15, 2017, 08:27:06 PM
You are correct, consider it fixed!  Just need to make sure the timing still flows right.  Give it a whirl since you have an active entry scn?

Just flew with the changes, looks good! Ill be pushing my scenarios in the next few hours. I just added one thing to the Apollo 8 checklists and I posted it here to run it by you. All I did was added a "EI - XXhXXmin" in heading 2 for things that are mission time dependent so that if we do the entry preparation checklists on our own, say after an abort, it will be easier to know when to do the various mission time dependent items since in those cases the mission time is no longer valid.  For example the IMU align at entry minus 1h35:

                                                                                              Heading 2
P52 IMU Realign (REFSMMAT)   522600   MISSION_TIME         EI - 1h35min            -1   1   P52 IMU Realign (REFSMMAT)


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 15, 2017, 11:24:51 PM

Just flew with the changes, looks good! Ill be pushing my scenarios in the next few hours. I just added one thing to the Apollo 8 checklists and I posted it here to run it by you. All I did was added a "EI - XXhXXmin" in heading 2 for things that are mission time dependent so that if we do the entry preparation checklists on our own, say after an abort, it will be easier to know when to do the various mission time dependent items since in those cases the mission time is no longer valid.  For example the IMU align at entry minus 1h35:

                                                                                              Heading 2
P52 IMU Realign (REFSMMAT)   522600   MISSION_TIME         EI - 1h35min            -1   1   P52 IMU Realign (REFSMMAT)


Good idea!  Also do you have an entry scn handy I could play with?  I cleared my quicksaves :(


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on February 15, 2017, 11:47:30 PM
Good idea!  Also do you have an entry scn handy I could play with?  I cleared my quicksaves :(

Here you go



Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 16, 2017, 07:09:46 AM
Scenarios are merged. I think the updated Checklist MFD file is still missing though, right?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 16, 2017, 08:58:45 AM
Scenarios are merged. I think the updated Checklist MFD file is still missing though, right?

Yes, doing my last run through TLI now.

EDIT:  So in regards to the pyro safing, I used the TLI checklist primarily and then added in the safing of the pyros at the end of the SEP checklist instead of A) not at all as per the actual TLI checklist and B) right after SEP as per the Translunar LOI TEI Procedures.  I think this preserves the timeline for the user and still safes the systems after TLI.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 16, 2017, 09:52:17 AM
EDIT:  So in regards to the pyro safing, I used the TLI checklist primarily and then added in the safing of the pyros at the end of the SEP checklist instead of A) not at all as per the actual TLI checklist and B) right after SEP as per the Translunar LOI TEI Procedures.  I think this preserves the timeline for the user and still safes the systems after TLI.

That works. We can do it "properly" for later missions and base the Apollo 10+ TLI checklist on the Apollo 12 Launch Checklist, which is the next one we have. And with that, we are really feature complete now.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 16, 2017, 10:30:35 AM
The only issue I see with the scn files so far (and it is very trivial) is that the RCS Logic breakers are in during most of the mission.  They should be opened after CM/SIVB sep and I believe not closed again until CM RCS checks before CM/SM sep.  I can fix this if you all want.

On another note, the 8 CMP checklist has the NONESS BUS being switched to MN B before P40 SPS burns.  However I cannot find mention of the NONESS breaker being closed.  Would it be safe to assume this breaker was closed before launch since no other documentation (that I have seen) mentions the NONESS breaker?

EDIT:  I have fixed the scn files to reflect the RCS LOGIC breakers but will hold off on making a pull request until I have more info about this NONESS breaker, in which I might as well close it in the files for completion.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 16, 2017, 11:04:52 AM
The only issue I see with the scn files so far (and it is very trivial) is that the RCS Logic breakers are in during most of the mission.  They should be opened after CM/SIVB sep and I believe not closed again until CM RCS checks before CM/SM sep.  I can fix this if you all want.

Alex will fix it. EDIT: Or you already did it :D

Quote
On another note, the 8 CMP checklist has the NONESS BUS being switched to MN B before P40 SPS burns.  However I cannot find mention of the NONESS breaker being closed.  Would it be safe to assume this breaker was closed before launch since no other documentation (that I have seen) mentions the NONESS breaker?

Hmm, The later launch checklists have the circuit breaker open and I can't find any reference to closing it. Later missions also don't have the switch setting in the P40 checklist. Maybe this is a CSM-103 only thing with special sensors on that bus.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on February 16, 2017, 11:11:03 AM
EDIT:  I have fixed the scn files to reflect the RCS LOGIC breakers

Sounds good!    EDIT:   In the Apollo 8 - 12 - Entry Preparations T+142h40min, I forgot to set the ROT CTRL PWR 1 & 2 from OFF back to AC/DC. Do you mind fixing that?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 16, 2017, 11:19:18 AM
Alex will fix it. EDIT: Or you already did it :D
Haha yeah, figured while I had them open might as well!

Hmm, The later launch checklists have the circuit breaker open and I can't find any reference to closing it. Later missions also don't have the switch setting in the P40 checklist. Maybe this is a CSM-103 only thing with special sensors on that bus.

I couldn't either which is why, given our lack of a true prelaunch checklist for 8, I think it may have been closed for launch as I cannot find another point where it would actually be closed.  Also I found in the Pre SC Sep addendum in the TL LOI TEI procedures, the NONESS is also assumed to be on MN B prior to sep, which begs the question since it was not turned on in the launch/insertion checklists, was it also turned on in prelaunch?


Sounds good!    EDIT:   In the Apollo 8 - 12 - Entry Preparations T+142h40min, I forgot to set the ROT CTRL PWR 1 & 2 from OFF back to AC/DC. Do you mind fixing that?

So they should be on AC/DC when you load that scn correct?

EDIT:  For the NONESS, the TL LOI TEI procedures also has the NONESS switched from MN B to MN A 2mins prior to SEP and then no record of switching it off.  I think you are right about there perhaps being some CSM 103 specific instrumentation on that bus.  Where would be a good source to find out?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on February 16, 2017, 11:23:18 AM
So they should be on AC/DC when you load that scn correct?

Yep should be on...the reason I turn them off is in case I bump my controller during time accel.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 16, 2017, 11:28:02 AM
I have fixed the scn files, I have not, however messed with the NONESS breaker or pre sep switching until we find out a little more about this.  Clearly they have no effect on our sim at the moment anyways so we can always change those down the road should we add power draw from that bus at a later date when we re examine the CSM power system.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on February 16, 2017, 02:00:46 PM
unless that SMa upper limit is smaller than the nominal return...

That is exactly the issue and why the -MA procedure had to be used. Both for the nominal Apollo 8 return and some abort cases. The maximum major axis P37 allows in Colossus I and IA (Apollo 8 and 9) is 8e8. Take half of that and you have the maximum semi-major axis. 4e8 is about a lunar distance, how they ever thought that was going to be enough...

Maybe it was intended for a minimum-dV abort from the Moon more than anything else, in which case it would suffice?


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 16, 2017, 02:42:20 PM
The Apollo 8 Spacecraft Operational Trajectory from October 25th 1968 still had a return 24h later as the nominal trajectory. In that case Entry Interface would have been at 171:05:32 GET with an entry velocity of 36071 ft/s. It also mentions the return one day earlier as an option, which is of course the trajectory that was then flown. So, with that trajectory there probably wouldn't have been a problem with P37.

Maybe it was intended for a minimum-dV abort from the Moon more than anything else, in which case it would suffice?

It suffices for all direct return aborts, yeah, not for the nominal return trajectory from a lunar orbit though.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: meik84 on February 16, 2017, 04:26:20 PM
Quote
Maybe this is a CSM-103 only thing with special sensors on that bus.
I guess the FQR (flight qualification recorder -not to be confused with the DSE) was on the noness bus. AFAIK they wanted more data from the SPS when in deep space.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 16, 2017, 04:37:24 PM
I guess the FQR (flight qualification recorder -not to be confused with the DSE) was on the noness bus. AFAIK they wanted more data from the SPS when in deep space.

Apollo 7, too. An early CSM-101 Systems Handbook (http://wayback.archive-it.org/all/20100525065443/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19720067986_1972067986.pdf) has 6 FQR circuit breakers on a panel 277, and those are powered by Non-Essential Bus 1.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on February 16, 2017, 07:57:25 PM
Well, I did a ground-calculated version of the abort burn from TEC. Definitely works from that perspective, and I made it with about 2% SPS propellant. However. for whatever reason, P37 in precision mode won't converge on a new solution afterwards—it'll find the conic solution after I set up the -MA option, and be just fine with it, but it throws the program alarm during precision iteration that I've exceeded the number of permissible loops, though before the alarm is thrown, the SV time is within an hour of the ground-calculated EI.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 17, 2017, 06:17:55 AM
Do you have a scenario after the RTCC calculated burn? Maybe you are running into some other kind of constraint in the precision phase. Or P37 can't deal wth something else on that trajectory. It must have been a really long burn, if you only have 2% of SPS propellant left.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: rcflyinghokie on February 17, 2017, 11:42:39 AM
I have not check in Apollo 7 yet, but is anyone else getting a "drogues" verbal sound effect when they are deployed after entry in Apollo 8?  I do not think this is from orbiter sound as I couldn't find the effect.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: jalexb88 on February 17, 2017, 11:49:57 AM
I have not check in Apollo 7 yet, but is anyone else getting a "drogues" verbal sound effect when they are deployed after entry in Apollo 8?  I do not think this is from orbiter sound as I couldn't find the effect.

I do get that, but only after I load a scenario/quicksave just before entry interface. If I fly a scenario all the way from MCC-7 or entry preparations to splashdown, I dont hear that sound effect.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on February 17, 2017, 02:00:40 PM
Do you have a scenario after the RTCC calculated burn? Maybe you are running into some other kind of constraint in the precision phase. Or P37 can't deal wth something else on that trajectory. It must have been a really long burn, if you only have 2% of SPS propellant left.

2:21 burn time. I really thought it'd have to finish it off with RCS for a while.

I've attached the scenario, and selected abort mode in the MCC menu (which probably doesn't do anything after TEI anyways). The parameters from my last P37 after the burn should still be in there; I moved the TIG forward 15 minutes when the first iteration failed, according to the CMP checklist.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 17, 2017, 02:21:43 PM
The Drogues sound is from NASSP. So it's a feature, not a bug. If it only happens with saving/loading shortly before EI then there might be something wrong with handling of the different CM stages though. No idea.

I've attached the scenario, and selected abort mode in the MCC menu (which probably doesn't do anything after TEI anyways). The parameters from my last P37 after the burn should still be in there; I moved the TIG forward 15 minutes when the first iteration failed, according to the CMP checklist.

RTCC MFD gives a 1.2 ft/s corridor control burn at EI-2. Then I tried the normal Apollo 8 -MA procedure and got a 130 ft/s conic phase solution and the 605 alarm for exceeding iterations in the precision phase. The 130 ft/s solution is weird and I might have done an error in the procedure somewhere. Instead of the 70000E,E for the -MA I then tried the hardcode values used for Apollo 10 and later. Those values are 75725E, 75417E. With that the conic phase gives me a good solution about 1.3 ft/s. The precision phase fails again due to iteration limit. I will investigate this further. However, the reentry is faster than usual, 36800 ft/s with an angle of -6.62°. So maybe there is some other constraint that prevents P37 from working there. Although, that problem should then also happen with the RTCC MFD entry targeting...


Title: Re: Apollo 8 Beta Testing Bugs
Post by: eddievhfan1984 on February 17, 2017, 02:38:51 PM
I had similarly large differences between conic and precision solutions when I'd do P37, though. AFAIK, the conic options just showed the relative feasibility of the solution when going strict Kepler, but you'd expect the precision solution to be more nuanced.

As far as I can tell, the SMa constraints are the only ones in erasable memory. I'm looking through the P37 assembly right now, but most of it is in interpreter pseudo-opcodes, which I may need to take a little time to figure out.


Title: Re: Apollo 8 Beta Testing Bugs
Post by: indy91 on February 17, 2017, 02:50:19 PM
For a normal return trajectory conic and precision phase are fairly close for MCC-7, so only two hours between MCC and EI. Direct Return Aborts have the greatest difference between conic and precision phase usually.

The orbit is fairly hyperbolic with a semi major axis of -118.2e6 meters and an eccentricity of 1.05. That might be the issue here. Different MA values give different results for the conic phase. I don't know why the Apollo 10+ values are any good, -118e6 as the semi-major axis (-236.4e6 as the major axis) should already violate the constraint. The Apollo 10+ constraint is about -69e6. So P37 would run into the MA constraint in any CMC version. The "70000E,E" value from the CMP Checklist should in theory allow the trajectory, the value is -268e6 there. But the major axis isn't directly used in the calculation as a constraint, it rather is used in a simple geometric equation that might not exactly make the specificed major axis a constraint.

I haven't found the exact reason for the failed iteration yet but it is probably caused by the hyberbolic orbit.