[23:23:24] NASSP Logging has been started by thewonderidiot [11:21:45] Good morning [11:24:17] hey [11:24:49] almost on deorbit day for Apollo 9 [11:25:54] Yeah i am way behind [11:26:00] I havent been able to do much at all this week [11:26:20] after SPS-7 it was easy [11:26:31] bit of photo taking in pitch orbit rate and that's it [11:26:37] Well at least i will have good MCC for when I continue :) [11:26:38] pretty empty flight plan [11:26:46] too empty actually [11:26:56] we might want to add one or two things [11:27:04] like state vector updates at the beginning of the day [11:27:24] I started rendezvous back on TPI0 because the timelines didnt work right as far as checklist items so I have to clean it up a little better [11:27:30] Yeah that sounds good [11:27:41] or else you have to do a nominal alignment with a 12+ hour state vector [11:27:53] flown mission had SV update [11:28:13] as well as PTC tests, backup alignment tests and more [11:28:17] Oh yikes thats an old SV for an option 2 [11:28:23] but we'll talk about that when you get there [11:28:27] Haha sure [11:28:31] yeah, the alignment was off by 1.5° in pitch [11:28:46] the onboard state vector propagation is really good, but not that good [11:29:18] Oh, in reading transcripts (about the only thing Ive had time to do) I noticed an interesting comment regarding the LM suit isol valves [11:29:25] From 12 [11:29:26] 063:24:45 Carr: Roger. I hate to change the subject on you guys, but it looks like you don't have your Auto Repress capability now. When you activated your Suit ISOL valve, it looks like what you should have done is gone to the Suit, Flow, and then used your actuator override, in order to set it up. [11:29:49] So I need to go in and find out why not using actuate override to go to disconnect disables auto repress [11:30:01] Has to be something to do with the pressure switch I would imagine [11:30:27] yeah [11:30:28] I havent had a chance to pull the schematics [11:30:38] auto repress due to low suit circuit pressure [11:34:07] but I'm not quite sure what that means either [11:34:28] I need to look at the connections between the suit and cabin pressure switches [11:34:42] But I want to finish this damn rendezvous [11:35:04] I got some docs from Lauren, nothing too new info wise though unfortunately [11:35:12] any bigger issues with the timeline targeting wise? [11:35:24] so are the delta times between maneuvers too short or long? [11:35:39] When I got to tpi they were too short [11:35:44] I ran out of time to do everything [11:35:52] Up to CDH things went well though [11:35:53] so between CDH and TPI [11:35:58] Yeah [11:36:13] I am reflying it this morning to see if I can pinpoint any issues on my end [11:36:34] https://www.dropbox.com/s/bresxumvsry2n62/HSI-209485.pdf?dl=0 [11:36:36] I'd be interested in your CSI, CDH and TPI times [11:36:39] https://www.dropbox.com/s/0s7qfh7fqx4htpo/HSI-37569.pdf?dl=0 [11:36:46] Sure I will write them down [11:37:00] ah, I already got that one, because I had the link to your Dropbox saved :D [11:37:16] I was thinking: "Didn't Ryan request some more documents?" And there they were :D [11:37:29] Still waiting on one [11:37:34] which one? [11:37:53] ECS performance [11:37:58] Something for me [11:37:59] Haha [11:38:19] LUNAR MODULE ENVIRONMENTAL CONTROL SYSTEM PERFORMANCE LM-3 ( LUNAR MODULE 3 ) APOLLO 9 [11:38:42] That is of interest to me especially because of the multiple powerups and shutdowns of the system [11:38:47] yeah [11:38:53] I want to see if our system behaves properly during those [11:39:31] The rendezvous doc looks almost identical to the tindallgram [11:40:05] even the final document will be very similar to the final Tindallgrams about the rendezvous [11:40:22] this early one has the originally planned rendezvous profile [11:40:27] Still has the angles that dont quite make sense... [11:40:56] first a CSM style rendezvous from above, like it would do in a rescue case [11:41:02] and then the normal Apollo 9 one [11:41:19] relative plot looks a bit crazy [11:41:41] relative motion* [11:43:17] Yeah [11:43:19] you can probably calculate the insertion maneuver of that profile with the DKI processor [11:44:04] usually you can see that, when there is a CSI maneuver with nominal zero DV follow the DKI calculated maneuver [11:44:07] no wait [11:44:11] that isn't right at all [11:45:42] CSI being nominal zero DV is the two-impulse processor [11:45:51] like with the Apollo 7 rendezvous [11:45:55] or a No PDI+12 abort [11:46:13] Yeah I haven't kept track of those different processors :P [11:46:57] some are remnants of Gemini, some were developed for Apollo specific abort maneuvers, and one is like the onboard programs with added features [11:47:49] I remember Michael Collins talking in his book about having to learn a lot of rescue cases [11:48:00] and by now, I think, we can calculate them all [11:48:20] and because I'll soon work on the Apollo 11 MCC, I'll need them [11:49:50] Those rescues will be fun to try [11:50:59] and the CSM Rendezvous Procedures document for Apollo 11 has all the documentation you need to fly them [11:51:33] Just need to put the LM in some interesting situations :) [11:52:00] Like an emergency liftoff [11:52:32] oh, I have the right document for that as well [11:52:49] "Rendezvous Following Anytime LM Lift-Off" [11:53:03] so proper emergency [11:53:30] that's not even one of the rescue cases covered [11:54:03] Guess it could include a plane change as well [11:54:54] and a high apocynthion dwell orbit to quickly get the relative phasing right [11:55:15] in a bad case of the phase angle [11:55:21] I haven't even looked into that maneuver [11:55:30] Would they be combined? [11:55:37] For time sake [11:56:50] I don't think there is any special plane change maneuvers necessary [11:57:00] CSM and LM are never super far apart [11:57:25] so the normal procedures for that (using a DVY for CSI and doing a proper PC) should still apply [11:58:08] seems like there are three phase angle regions [11:58:17] nominal, post-nominal, pre-nominal [11:58:26] the nominal one just does the usual CSI/CDH/TPI [11:59:57] post nominal the CSM needs to do some phasing [12:00:20] maneuver for a high apocynthion and then it stays there for 1-3 orbits [12:00:25] then recircularization at 60NM [12:00:30] target phasing is 20° [12:00:45] and then the CSM just does CSI/CDH/TPI/TPF [12:03:32] there are some charts in the document to choose the apocynthion height based on LM insertion phase angle [12:04:06] that's all for the post-nominal phase [12:04:12] pre-nominal is even crazier, haha [12:05:03] and there are different cases for CSM active, LM active etc etc [12:05:20] if Alex had read this document, then I'm sure he would have tried this already :D [12:06:34] Haha I bet! [12:08:48] and I haven't tested the time-critical LM ascent yet either [12:09:17] that's the one they planned for mainly a water tank leak in the LM ascent stage [12:09:36] get to the CSM as quickly as possible before everything overheats [12:10:02] one-half revolution rendezvous :D [12:10:16] I was going to ask about the time critical one :) [12:10:19] ones* [12:11:05] CSM lower perilune to 1NM above LM insertion altitude [12:11:15] LM insertion targets 60NM apolune directly [12:11:38] so at the time of insertion, the CSM would be in theory 1NM above the LM [12:11:57] and ahead a bit of course, so that they rendezvous at apolune [12:12:14] Then they just need to match velocity at that point [12:12:21] and immediately after insertion, the LM would start line-of-sight braking [12:13:25] the CSM targeting for this should be possible with the general purpose maneuver processor [12:13:31] I have a flag salad RR case for you [12:13:35] oh no [12:13:42] Where I couldnt drive it with V41 N72 [12:13:45] yeah [12:13:55] Just did a quicksave, want to have a look? [12:14:02] sure [12:14:41] So here is what I did [12:14:50] Final com through P34 with P20 running [12:14:51] come [12:14:53] comp [12:15:04] F37 00 E [12:15:07] V47 [12:15:13] and then the V41 N72 [12:15:26] sounds quite normal [12:15:35] https://www.dropbox.com/s/9fhbuz4x9minpum/Apollo%209%20MCC%20-%20TPI0%200001.scn?dl=0 [12:15:46] And when I mentioned it last time thats what i did as well and it worked [12:15:50] Now [12:15:58] I did deviate in one way from the procedure [12:16:12] In that I was not in a V76 att hold when I final comped and P00'd [12:16:28] But thats the only difference [12:16:40] hmm [12:16:42] interesting [12:17:02] But I dint think that would have an effect [12:17:05] didnt [12:18:12] So after all that its still tracking [12:18:59] Even after a V44 it seems [12:19:39] And now I have a 503 clearly telling me P20 is still trying to do things [12:25:50] did we ever have this issue in Luminary099 and later? [12:27:05] I dont recall running into it [12:33:16] And now I am getting a 503 when starting P20 again [12:34:44] hmm, so in this mode, the LGC isn't in control of the RR [12:34:48] it's the RR auto tracking [12:35:05] so the issue is that the LGC still commands the RR to do auto tracking [12:35:22] Well now its telling me that my LOS is wrong [12:35:41] I am wondering if it took incorrect marks after I exited P34 [12:37:06] I mean i know how to fix it of course, but still it shouldnt have done that [12:38:55] hey [12:42:11] Morning [12:45:24] hey Alex [12:53:49] oh [12:53:59] here is a procedure that clears the output bit [12:54:03] V63E [12:54:05] PRO [12:54:06] V34E [12:55:10] Question is, why did that happen to begin with [12:55:14] Where as sometimes it doesnt [12:56:37] no idea [12:58:45] Haha ok [13:01:34] it must be some procedure that does not call the line of code where the output bit is reset [13:06:04] The V63 didnt help [13:06:14] still tracking [13:07:14] Ah it worked never mind [13:12:18] my bet is that it's some sort of Luminary069 issue like that Luminary099 flag that needs to be reset for PDI [13:12:25] and that the checklists would have a procedure for this [13:12:35] or procedures that avoid this from happening [13:12:41] I'm sure it's not random [13:12:54] so some order of DSKY inputs will make it happen vs not [13:13:15] you certainly need to be tracking the CSM at the time [13:17:54] rcflyinghokie, starting work on utility lights [13:18:49] also fixed the AGS cb and OVH/FWD switch [13:19:39] utility light panel* [13:19:46] Nice! [13:22:23] Were there any other switch issues? [13:23:46] I dont think there were any other spelling issues in the LM [13:28:05] haven't found any others [13:30:25] Hey Ryan [13:30:57] just flying to Los Angeles [13:32:44] Oh nice [13:33:16] Giving that 737 a workout huh [13:33:34] yes [13:33:43] with FS2CREW [13:34:01] i need to learn all the checklists and flows myself too [13:34:15] Yeah you will get them eventually [13:34:33] I have them mostly memorized just from doing them over and over but FS2CREW helps so much [13:35:19] cant wait to get rudder pedals too [13:35:19] I am learning a new plane in RL right now, nothing fancy, a Grumman Cougar [13:35:34] So engine out instrument approaches are on the list for tomorrow [13:35:45] you seem like a Grumman fan :D [13:35:58] Hey Niklas [13:36:01] hey [13:36:47] Oh Ryan, I think I hadn't told you yet about my Apollo 10 experiments with the TOA at the Moon, did I? [13:37:27] TLI cutoff bias etc. [13:37:41] Nope [13:37:48] Last I heard you were going to play with them [13:37:55] yeah [13:38:10] Hey i have hundreds of hours in a AA-1B, I even helped rebuild it [13:38:11] so, the TLI cutoff has a big influence on the MCC DV [13:38:31] but not really on the arrival time at the Moob [13:38:32] Right [13:38:32] Moon [13:39:04] the biggest influence on that is the approach azimuth for post LOI, as used in the MCC calculation [13:39:17] and the trajectory change request for Apollo 10 is a bit weirdly worded [13:39:21] so my current theory is this [13:39:37] to get closer to the Apollo 11 trajectory approach the Moon, they played around with the approach azimuth [13:39:44] -90° works pretty good [13:40:07] but then in the LOI calculation itself (after all MCCs are done) they would use the desired one, -91° [13:40:26] So it got them in the ballpark and it was tweaked by LOI [13:41:12] yeah, usually it's not a good idea to use different ones in the MCC and the LOI calculation [13:41:31] they can't be very different, or else you can't reach the desired orbit [13:42:28] the trajectory change request says: [13:42:31] "The midcourse would be targeted by the RTCC free return best adaptive path (BAP) mode through the use of a MED to control the lunar landing site approach azimuth so as to obtain a resultant translunar trajectory compatible with the desired new orbit orientation." [13:42:48] "LOI-l would be targeted in the usual manner using a MED to obtain the desired new lunar landing site approach azimuth." [13:43:06] MED = Manual Entry Device, so user input for the RTCC processor [13:43:42] So this is more targeting and less tailoff issue? [13:43:53] yeah, I think this is TLMCC targeting [13:44:11] the changed TLI cutoff bias might still be better [13:44:14] I can check that [13:44:32] whichever gives the smaller DV for the originall planned approach azimuth [13:44:39] because TLI was still targeted to that [13:44:48] -95.25° instead of the new value -91° [13:46:26] Ah yeah thats a difference [13:47:30] main reason why the MCC isn't 0 DV [13:48:28] what I quoted above is worded a bit weird, but normally you could just use the new approach azimuth in all calculations [13:48:51] but maybe they didn't want to [13:49:09] Could be [13:49:14] What did you test? [13:49:35] -90° seems to work well [13:50:09] gives MCC-1 DV fairly close to the SCOT [13:50:17] as well as the TOA [13:50:37] at the pericynthion [13:52:21] Oh good [13:54:34] Oh I was messing around with a glycol pump sound [13:54:59] Its one from FTETTM [13:57:06] as long as nobody is suing us because of it, sure [13:57:08] :D [13:57:52] Well i took it from the movie clip and edited it a touch [13:58:15] So I dont know the ramifications of doing that [13:59:01] I mean, in the end it's a pretty generic sound [13:59:09] shouldn't be a problem... I think [13:59:17] I have a startup sound and then a file that can be looped [13:59:27] They are in audacity right now [13:59:35] I can convert them and let you guys take a listen [13:59:47] wav or mp3? [14:01:46] mp3 [14:01:52] Orbiter Sound needs wav I think [14:01:59] yes it does [14:02:48] Ok so wav it is haha [14:02:57] https://www.dropbox.com/s/nl83yrbejqbqlfe/Glycol%20Pump%20Start.wav?dl=0 [14:03:04] https://www.dropbox.com/s/u1id8pnnrak89yk/Glycol%20Pump.wav?dl=0 [14:03:54] they both sound good [14:04:58] I agree [14:05:54] I was also trying to figure out what to use for the suit fan sound [14:06:21] Maybe the cabin fan sound from the CM, a little muffled? [14:08:34] sounds plausible [14:11:28] Oh for the 9 rendezvous times, how are we handling the "time bias" [14:12:36] I think we don't need it [14:13:12] Sundance still uses the old rendezvous targeting, where CDH is at the next apsis after CSI [14:13:17] and not half a revolution later [14:13:42] so they used a bias to get the timing right [14:14:23] although this might not be 100% compatible still with the planned profile [14:14:31] but in any case we would probably need different biases [14:15:10] So for now just input the times as shown on the update pads? [14:15:37] yes [14:16:03] Ok [14:16:35] And for CSI, Am I just entering 1 in R1 and 2750 in R2 leaving R3 alone? [14:16:38] they changed the bias in real time as well [14:16:52] because the CSM orbit wasn't perfectly circular [14:17:06] and in turn the LM orbit in the coelliptic orbit wasn't perfectly circular [14:17:18] which shifts the apsis following CSI to a different point [14:17:22] that's a good question [14:17:48] I think if you leave R3 as 0, then it would use the same calculation method as Sundance [14:17:57] CDH is at the next apsis [14:18:02] periapsis of course in this case [14:18:24] so usually you already enter the central angle there for TPI [14:18:26] the 130° [14:19:32] we will get better results, if we input the 130° (or anything non-zero really) [14:19:42] and no time bias [14:19:55] on the other hand, we would get closer to the Apollo 9 procedures by using 0 and the time bases [14:19:57] biases [14:20:12] The rendezvous instructions say F 06 55 +00001 N +02750 E PRO [14:20:26] Sundance might not even have a R3 there [14:20:28] I'll check [14:20:42] Thats what i am thinking [14:22:03] yep, R3 in N55 in Sundance is blank [14:22:17] Ok [14:22:26] So just fill our R2 and R3 here? [14:22:28] out [14:22:39] yeah [14:23:06] strictly you only need to enter anything not 0 in R3 to use the multiples of 180° travel to CDH formulation [14:23:22] but in P34 R3 of N55 is used [14:23:34] so apparently it was the procedure to already enter the 130° there [14:24:24] https://www.dropbox.com/s/z6mhj90swjkkfkk/LM%20Suit%20Fan.wav?dl=0 [14:24:27] Ok [14:25:04] that sounds a bit weird [14:25:19] like... stretched [14:27:45] and in Sundance R1 of N55 is always the option for the next apoapsis/periapsis [14:27:51] and not multiples of 180° [14:27:59] that also explains one thing in the rendezvous procedures [14:28:25] depending on the pre-CSI trajectory you could end up in a orbit after CSI, that is shortly before apoapsis [14:28:40] if the orbit wasn't perfectly circular [14:29:01] so the next apsidal crossing would be only a few minutes later [14:29:04] Better? [14:29:04] https://www.dropbox.com/s/z6mhj90swjkkfkk/LM%20Suit%20Fan.wav?dl=0 [14:29:11] that's why the procedures say [14:29:26] Note: manual iteration for finding apsidal xing may be reqd [14:29:31] because it could be 1 or 2 [14:29:48] Yeah I see that [14:29:54] orbit after CSI is short after apogee, you need to use 1 [14:29:58] shortly before, it's 2 [14:30:01] I think [14:30:19] sounds good [14:31:16] and the time bias would be roughly the same time difference to apogee [14:31:31] CSI at exactly apogee, 180° later and next apsidal crossing are the same [14:32:02] if not, you can bias a time and you can still achieve CDH being about 180° later [14:35:15] I'm for the solution without time biases. I think that's correct trajectory wise and easier procedure wise [14:37:24] I always liked this from the Virtual AGC website: [14:37:26] "Jim also tells me that a copy of Sundance 306 may still "be in the building". I'm not certain which building he's talking about, but it's nevertheless interesting news that a copy of the program does exist somewhere." [14:42:00] so we weren't going with the "plumber fixing the furnace" sounds?? [14:44:22] bummer [14:44:48] hehe [14:51:06] Sorry had to call IT, apparently the FAA remote connection server is down so I cannot connect to work haha [14:51:21] Haha [14:51:45] And for the cabin fan, we can use the same sound as the CM I suppose [14:52:09] yeah [15:09:12] Hmm not sure it likes this using 0 02750 and 130 [15:09:20] its been 6 minutes after a V32 [15:09:24] Still nothing [15:10:29] Yep after 7 minutes 605 alarm [15:11:51] Trying a 1 [15:14:49] That gives me good CSI numbers [15:16:38] oh, 0 in R1 is never right [15:16:55] has to be 1 [15:18:03] Haha that makes more sense [15:18:18] 0 would be 0° between CSI and CDH [15:18:29] I'm surprised there isn't an immediate program alarm for this :D [15:18:37] Took 7 minutes after a V32 [15:18:39] Then a 605 [15:18:49] yeah [15:19:04] it calculates a coelliptic orbit at the CSI point [15:19:10] so above, not below the CSM [15:19:20] so it never will reach the desired elevation angle [15:23:10] activating all the systems for Apollo 9 deorbit now [15:23:13] 3 hours to TIG [15:23:35] Awesome [15:30:32] PAD looks good [15:33:34] Going to hit the blue part, right? [15:35:33] from the lat and long on the Entry PAD i would say, yes [15:35:49] TIG is 5 minutes off flight plan [15:36:00] for Apollo 7 it was usually like 30 minutes [15:44:05] brb [15:47:27] So for this CSI am I supposed to be entering the 130 in R3? [15:47:32] Or am I leaving it blank [15:49:13] MIT guy would say: it can be anything but 0 [15:49:26] MSC procedure guy would say: just enter 130° [15:49:34] Ok [15:49:48] P32 only detects 0 or not 0 [15:49:52] I guess thats a difference from Sundance [15:50:07] I think there is no R3 in sundance [15:50:16] at least not in P32 [15:50:22] Yeah [15:50:39] But since we dont have sundance, 130 is appropriate here [15:51:09] yep, that's what gets entered in most checklists [15:51:17] helps getting not confused about N55 [15:51:38] Ok gotta make a few calls back in a bit [16:12:39] had a pretty large temperature drop, when I activated the evaporators [16:42:15] quick preview of the utility lights panel: [16:42:16] https://www.dropbox.com/s/3wtqee9tjvthgxh/Screenshot%202018-08-03%2012.41.13.png?dl=0 [16:43:00] its zoomed in a bit, in-sim it will look better [16:44:18] still missing a few details, screws, etc [16:45:12] this is what I used to base it: https://www.hq.nasa.gov/alsj/a12/LM6-co25.jpg [16:46:54] morning! [16:46:55] good enough, haha [16:46:57] hey Mike [16:48:42] what's up? [16:48:54] 20 minutes away from deorbiting Apollo 9 [16:50:22] woohoo! [16:50:29] bring home that misbehaving AGC [16:51:03] I took a quick look at PRESTAND last night and as I expected it sets up POSTAND to run in the phase tables [16:51:06] only that one standby mode thing and the restart [16:51:10] so maybe your phase tables are bad or something [16:51:17] could be [16:51:18] but you didn't get an 1107? [16:51:23] don't think so [16:51:47] very strange [16:52:04] I ran a self test as part of the deorbit prep, now I totally trust the CMC again :D [16:52:36] lol [16:52:58] but the self test in Colossus is ridiculously stripped down, those passed even before I fixed all of the bugs preventing landing :P [16:53:14] it did [16:53:20] but then again I guess reentry in the CM worked back then too [16:53:20] although too slow [16:53:24] haha [16:53:56] yeah, reentries have worked since before my time [17:00:18] deorbit is in darkness [17:00:48] the deorbit attitude is contrained, so that a window marking can be put on the horizon for the burn, as a backup attitude cue [17:01:00] what's the point of that, if even in the flight plan deorbit is in darkness! [17:01:40] lol [17:02:04] at least reentry is in daylight [17:02:19] another set of window markings can be used as attitude reference during reentry [17:03:23] that works really good actually in NASSP [17:03:28] you can easily fly a reentry that way [17:07:10] time for deorbit [17:42:02] everything worked flawlessly [17:45:28] :D [17:54:04] and egress [17:54:10] mission accomplished [17:56:35] woo! [17:56:37] now what? [17:58:53] well I let Alex test the new targeting for Apollo 10 [17:58:59] so that you arrive at the Moon at the right time [17:59:16] so I can directly proceed to working on the MCC support for Apollo 11 [17:59:23] :D [18:00:15] copy&pastes from Apollo 10. [18:54:01] indy91, nice to hear [18:54:17] yeah I guess you have your work cut out for Apollo 11 [18:55:54] with every mission so far I'm trying new things for the MCC [18:56:27] and for Apollo 11 I'll try to make it compatible with the July 18 and 21 launch dates from the get-go [20:14:19] Ok back to NASSP now that a crisis is averted [20:15:10] I've put the Gumdrop in the water [20:16:31] How was entry [20:16:37] very good [20:16:54] How were the procedures? [20:17:34] good for the most part [20:17:48] has to be adjusted to the flight plan [20:17:56] Yeah they are more or less copy paste [20:18:01] P30 is done earlier, maneuver to burn attitude etc [20:18:06] yeah, I figured [20:19:32] I will probably ask some more questions when I get there :) [20:20:04] yeah, sure [20:20:45] I have the pitch orbit rate procedures written down for when you get there [20:28:05] Great [20:30:14] Ok CSi question [20:30:42] I think this might be a FPX vs FP6 difference [20:30:59] 416+00000 and 417+10000 [20:31:18] Would I use 416+10000? [20:31:40] and never mind about 417 thats the radar filter [20:31:47] FPX vs. FP6? [20:31:51] But its useless to me in earth orbit [20:32:03] FP(whatever is in Spider) versus FP6 AGS [20:32:07] oh lol [20:32:12] Not "10" [20:32:14] :P [20:32:27] Flight Program 6 was actually called Flight Program X [20:32:31] that's what's printed on the listing [20:32:32] yeah [20:32:33] Oh [20:32:34] oops [20:32:35] so I was confused, haha [20:32:36] that's the funny part :D [20:32:43] it's 3 or 4 [20:32:52] Apollo 10 was certainly FP5 [20:33:29] FP Spider [20:33:34] hehe [20:33:40] I like it [20:34:23] But yeah 416 should be 1, not zero for using FP6, right? [20:34:31] yeah, I think so [20:34:32] Apsidal [20:34:34] Ok [20:34:48] is that the same as R1 in N55? [20:34:57] I think so? [20:35:08] The rendezvous procedure says 416+00000 [20:35:20] But its comment is "1st apsidal" [20:35:21] hmm [20:35:33] So I am thinking difference in program/address [20:35:41] maybe 416+0 is a mode compatible to Sundance [20:35:53] apsidal crossing vs. 180° travel [20:36:03] in FP6 only 1 and 3 are valid inputs, I think [20:36:07] Thats correct [20:36:12] Thats why I was confused [20:36:21] 1/2 or 3/2 [20:36:22] has to be 1 then [20:36:24] Ok [20:36:26] yeah [20:36:36] And I am debating on keeping the radar stuff in this checklist [20:36:37] 3/2 orbits would be some of the abort rendezvous [20:37:00] Technically it was done, but of course rescaled the radar features are useless [20:37:10] right [20:37:29] manual RR updates for the AGS are completely broken in Earth orbit + FP6, right? [20:37:33] Yeah [20:37:37] Per the manual [20:37:57] But apollo 9 used them with FPSpider [20:38:07] filter can't be rescaled or something like that [20:38:11] Yeah [20:38:35] I wouldn't include anything in the checklist that could break the AGS state vector [20:38:57] Sure [20:38:59] if you can't do break it that way, then it's ok to be included I guess [20:39:04] -do [20:39:17] I will investigate a bit [20:39:29] I dont think initializing the radar filter breaks anything [20:39:36] Mike? [20:39:59] thewonderidiot, your thoughts? [20:40:27] oh I have no idea :D [20:40:42] you can try doing the RR updates [20:40:49] there is a good chance it breaks the SV [20:41:05] hmmm, maybe [20:41:18] do we know sundance's downlink list code? [20:41:42] or am I thinking about the totally wrong thing [20:41:53] manual RR update is via the DEDA [20:42:00] very annoying to do, haha [20:42:02] right [20:42:12] you give it current RR range or range rate [20:42:20] yeah that sounds painful [20:42:37] not as bad as a full manual state vector update of course [20:42:52] Well here is what it is doing... [20:42:57] In apollo 9 that is [20:42:58] Luminary069 to FP6 auto updates are functional [20:43:17] 417+10000 to init the radar filter [20:43:43] And then 415+10000 to "store z-axis direction cosines & rng/rng rt data in rdr filter" [20:43:53] I dont see actually inputting anything [20:44:13] Assuming the addresses are the same in both FP's of course [20:45:00] I think they are, yes [20:45:07] They initialize and then a bunch of 417+10000/316R [20:45:19] What is the purpose of that [20:46:08] Oh i see [20:46:41] give the AGS data on the direction of the CSM? [20:46:42] the manual says thats done, errors nulled, then enter is pressed [20:46:45] Yeah [20:46:54] LGC does that as well [20:46:55] Now does that break anything with scaling [20:47:08] rather, does that change the AGS SV [20:47:09] good question [20:48:09] rcflyinghokie1, https://www.dropbox.com/s/f3mdj20yu2lro3y/Screenshot%202018-08-03%2016.47.25.png?dl=0 [20:48:15] what do you think? [20:48:32] still WIP [20:48:46] Ohh pretty [20:49:41] Wrong switch type though [20:50:00] and thats where we want it, right? On the OVH hatch panel [20:50:03] Need the graphic from say the mode control switches [20:50:21] there isn't a flag in the FP that says Earth vs. Moon [20:50:37] And yeah I think the position looks great [20:50:47] so if the FP6 Operating Manual says RR updates don't work then I have to assume trying it in any way is bad [20:50:53] indy91 I would agree [20:51:09] I will pull those out, I wish I could just comment them out haha [20:51:17] I can easily change the switch type [20:51:36] Yeah I figured you could [20:52:24] And for completion you could add the circle to the left of the CDR switch ;) [20:53:25] Interesting it wasnt on apollo 15 [20:53:34] Never mind haha [20:55:27] yeah that coming [20:55:44] and some more screws on the beige area [20:56:08] and general realigning of things [20:58:01] And those strips of what, velcro? [20:58:08] The black and white below the plugs [20:58:20] But yeah it looks awesome :) [21:01:10] CSI numbers indy91: [21:01:29] N75 +00097 +44 39 +54 06 [21:01:46] N81 -00378 balls and balls [21:01:57] N82 -00379 00000 -00027 [21:03:06] goods all pretty good [21:03:09] DTs good [21:03:11] DH good [21:03:14] DVs good [21:03:27] V90 was -00001 in R2 [21:03:31] So didnt add it [21:04:08] And the time given to burn it was 96:13:00 by MCC [21:05:56] yeah. I think that is mid-pass for a specific tracking station [21:05:59] The N81 from MCC was -40.9 [21:06:12] hmm, that's of course a bit off [21:06:40] Yeah [21:07:29] the ground solution as currently calculated by the RTCC uses the fixed TPI TIG option [21:07:34] so it iterates on the DH [21:08:12] theoretically the better solution I guess, your TPI might be a bit late [21:09:40] What did my P32 use [21:10:12] same targeting [21:10:20] Hmm [21:10:21] tries to achieve the TPI you give it [21:10:25] TPI TIG* [21:10:44] Adding that 130 doesnt mess anything up with this does it? [21:10:45] but there still might be some differences I am currently unsure about [21:10:51] Because it was blank every time I called P32 [21:11:03] you mean 0 or blank? [21:11:08] Its zero sorry [21:11:20] yeah, has to be non-zero [21:11:28] or else it calculates the manuever the Sundance way [21:11:33] with the next apsidal crossing [21:11:56] Ok [21:11:58] I take the better solution back [21:12:22] the current RTCC Concentric Rendezvous Processor just uses conic routines [21:12:34] So the LGC is better? [21:12:39] probably [21:12:48] RTCC uses a perfect SV of course [21:13:05] Yeah and mine is based on RR updates [21:13:45] but MCC is not considering non-spherical gravity for CSI yet [21:13:51] works good enough for lunar orbit [21:14:18] so burn the LGC solution [21:14:22] I did [21:15:44] You said the CDH update is CSI plus 15? [21:16:30] hmm [21:16:34] yes [21:16:46] I think the AGC also mostly uses conic routines for the CSI calculation [21:17:14] but in any case, the calculation methods are quite different. Have to investigate some more why they are different. [21:17:35] And I am not adding any time biases in any maneuver? [21:17:52] yeah, none are required [21:17:55] Ok [21:19:05] if your TPI time becomes much later than planned in P32, then we know the RTCC solution was better after all :D [21:19:33] you'll see in P33 with the DT TPI [21:20:26] Well just started P33 [21:20:39] The initial time was 2 seconds earlier than the MCC time [21:21:33] probably means that LGC and MCC disagree about how long half an orbital period is [21:21:51] CSI to CDH delta time [21:23:08] About to run a V32 lets see some prelim CDH numbers [21:25:35] N75 +9.2 +57 29 +03 19 [21:25:46] N81 -37.4 0 +.6 [21:26:00] MCC N81 -38.0 0 -2.8 [21:26:05] night! [21:26:18] 3 minutes DT TPI [21:26:20] interesting... [21:26:44] Lets see what final comp yields [21:27:03] I mean, it's possible that one of the time biases is for spherical vs. non-spherical gravity [21:27:11] and not just the apsidal crossing thing in Sundance [21:30:40] the biases are mentioned in the Tindallgrams [21:30:54] and there it talks about large radial components you would get without biases [21:31:02] that sounds to me like the apsidal crossing thing [21:31:03] Interesting [21:31:47] but I am not 100% on that [21:32:09] So TIG TPI in P32 wants a 3 minute bias [21:32:23] CDH wants to add 1:45 time bias [21:32:54] And its cut off for P34 [21:32:56] I would try using those and see if it gives better results [21:33:01] smaller DT TPI etc. [21:33:28] Think a bias was added during P34? [21:34:16] is there on in the rendezvous procedures? [21:34:24] Its cut off [21:34:35] let me look at that [21:34:46] pdf pg 41 [21:34:58] *40 [21:36:03] I'm not seeing it [21:36:16] Well its cut off on the photocopy [21:36:51] Apollo 9 LM Rendezvous Procedures? [21:36:53] Yes [21:37:14] sorry, I don't know what you mean [21:37:25] Bad photocopy [21:37:39] ohhh [21:37:46] I thought you mean a cutoff bias [21:37:48] Ohh [21:37:50] No no [21:37:55] like, burning TPI, but cutting off early or late [21:37:55] lol [21:37:58] cut off as in cut off of the copy [21:38:02] Sorry! [21:38:03] haha, now I get it [21:38:13] Haha I see how the context could imply that [21:38:35] Final comp P33: [21:39:04] right, the TIG input for P34 is cut off [21:39:51] So slow in LEO [21:40:06] Yes, so I cannot see if it has a bias or not on there [21:40:11] Uhh [21:40:15] R3 in N75 [21:40:17] - 00 14 [21:40:31] Something got messed up [21:40:40] Let me revert and try again [21:41:14] I don't think P34 needs to be biased [21:41:35] suddenly R3 of N75 is good? [21:42:10] that's DT TPI [21:42:15] 0 would be perfect [21:42:42] Yeah [21:42:53] I dont know why it changed from bad to good like that [21:43:02] must be RR updates [21:43:52] Yeah [21:44:05] Uhh maybe I messed up, my CSM is still in P20 [21:44:17] It might have been thrusting around changing its SV [21:44:39] But no, that shouldnt make a difference in this [21:45:21] Just in case I put a new CSM SV in and am remarking before CDH [21:45:59] Very small N49's [21:46:34] Only 2 of them [21:48:51] the DT TPI calculated with perfect SVs should tell, if we need time biases [21:49:20] Should I stop marks and uplink new SV's to test? [21:50:01] sure, if you want to test it right now [21:50:12] P33 calculates a very accurate TPI TIG I think [21:50:12] Yeah might as well [21:50:16] and compares it to the input [21:50:41] so if that turns out to be a significant DT then we know the bias is (at least partially) to compensate the usage of conic routines [21:51:00] so P32 with perfect SVs, execute CSI, and then P33 [21:51:36] Loading up pre CSI now [22:02:30] brb [22:02:47] Damn storms [22:13:54] rcflyinghokie, any results yet? [22:14:02] Just about to burn CSI [22:14:14] Prelim P32 numbers: [22:14:22] With new SV's no RR [22:14:45] N75 9.6 +44 38 +54 06 [22:14:51] N81 -36.7 [22:15:01] N82 -36.8 0 -.6 [22:16:39] Now do you want me to uplink new SV's again before P33? [22:16:59] probably not [22:17:02] Ok [22:17:10] And also, What is PLM FDAI in the pad [22:17:19] the P33 should be consistent with what you actually burned [22:17:20] pitch [22:17:36] inertial? [22:17:40] flight plan has all the PADs [22:18:27] If it's an ordeal pitch I was in inertial [22:18:40] But if its an inertial pitch, my CSI was 126 on the FDAI [22:18:41] yeah, inertial [22:18:45] And the pad was 310 [22:18:51] hmm [22:19:21] might be heads up vs. down [22:20:09] Ah [22:20:18] I am roll 0 [22:20:28] heads up [22:20:31] retrograde [22:21:29] iirc I used the same PAD for Apollo 9 and 10 [22:21:38] CSI on 10 is prograde [22:21:42] Ah [22:21:55] so I might just need to add a heads up/down option for the PAD calculation [22:22:01] I think mine is supposed to be retrograde [22:22:04] weird that I didn't notice this [22:22:20] yeah, better burn retrograde :D [22:22:21] Yeah retrograde face up [22:22:28] Thats what the computer did [22:22:36] Ok CDH comps time [22:23:06] The time that comes up is just over 3 seconds later than the pad [22:23:18] 38.44 seconds vs 35.29 seconds [22:23:28] 96:57 before that [22:26:21] Interesting the CSI pad says PLM FDAI [22:26:28] But CDH says PLM INER [22:27:03] CDH numbers: [22:27:16] TIG from pad 96:57:35.29 [22:27:32] N75: +00096 +53 35 -00 34 [22:27:45] N81:-00372 +00000 -00011 [22:28:01] N81 from pad -00037 -00000 -00006 [22:28:14] 130 PLM INER [22:28:47] R1 of N81 from pad? [22:29:20] -00370 [22:29:24] ah [22:29:25] Thanks [22:29:34] so the DV is pretty close for that [22:29:41] not a large DT TPI [22:29:48] I'd say no time biases [22:30:05] Ok [22:30:15] 30 seconds could easily come from the CSI burn having small residuals [22:30:22] Right [22:30:31] And I didnt check V90 [22:30:42] So there could have been missing dvy [22:30:58] probably less than the prescribed 2fps but still error [22:32:40] yeah [22:33:23] well, good luck with the rest of the rendezvous. I'll take a look at that pitch angle when I get the chance to [22:33:29] One more thing.. [22:33:33] Also on pitch angle [22:33:37] CDH is wrong too [22:33:54] Might be because CDH for 9 is burned +X [22:33:59] And 10 I believe +x [22:34:01] +z [22:34:10] oh [22:34:16] that could be, yeah [22:34:20] I dont remember but I am at 308 and the pad says 130 [22:34:20] I'll take a look [22:34:30] about 180° difference [22:34:32] Yeah [22:35:00] I'll be back about Sunday evening [22:35:08] good night! [22:35:11] night! [13:04:55] Hey Alex, are you familiar with how to get new sounds into NASSP? [13:15:15] hey Ryan, hmm let me try and remember [13:15:31] I am trying to piece it together I*think I know [13:15:39] But I am just reverse engineering here [13:16:14] I added them to nasspsounds.h [13:17:04] yeah nasspsound.h [13:18:01] I think I added an entry there once, but thats the extent of my knowledge on adding sounds [13:18:26] Haha ok [13:18:34] I am going to just reverse engineer the lm master alarm :P [13:19:54] I had created that .wav, but Thymo did the dirty work of adding it to the code, so he might know more [13:20:10] *I think it was Thymo [13:20:56] Yeah thats the code I am using to go back haha [13:33:41] Since the pumps themselves dont have a class I don't know where to put the code haha [13:37:01] Ah never mind found a good place, I just dont know how to loop a startup sound to it [14:17:13] done! [14:17:14] https://www.dropbox.com/s/2j8spzc4zr43ics/Screenshot%202018-08-04%2010.16.03.png?dl=0 [14:18:41] Oh that looks awesome! [14:19:07] btw the screw that partially obstructing part of the letters in "UTILITY LIGHT" is authentic based on the photo [14:19:36] Haha yeah good attention to detail :) [14:19:51] I wonder how that affected the EL lighting of that panel [14:20:05] Or if it was even lit [15:46:58] I'm close haha but I'll work on it later, gotta go fly [18:59:41] .tell rcflyinghokie, Utility lights panel is now wired with your existing code and works good! PR is sent [20:44:46] I cant get these sounds to play :( [20:44:52] Oh awesome! [20:50:44] next on the list is the color bands on the temperature display [20:51:10] back later! [20:52:28] You rock [09:32:26] good morning Ryan [09:33:00] gonna fly from Vancouver To Seattle [09:39:12] @rcflyinghokie and its only 30 minutes so i can use this flight to practice my landings [12:31:59] If you are landing north in SEA you get a good view of Mt Rainier [12:33:20] hey [12:36:00] Good morning [12:36:48] Just noticed last night that the latest D3D9 client has self shadow support now [12:36:58] looks quite amazing [12:37:19] I probably noticed but didnt realize it was self shadowing haha [12:45:57] https://www.dropbox.com/s/iold3637vftddih/Screenshot%202018-08-05%2008.43.15.png?dl=0 [12:57:30] Ohh the detail [13:00:29] I am stuck with this sound [13:00:40] I cannot seem to get it working and I don't know why :( [14:49:46] hmm maybe Thymo can help you with that [14:52:51] Thymo if you are around, I could use some help making my glycol pumps make noise :P [15:04:35] Just came back from vacation last night so yes! [15:05:33] .tell thewonderidiot I figured it out. It all works now, just need to fix the clock timing and the sign bits which stopped working somehow. [15:07:35] rcflyinghokie: I was working on some sound stuff for the suit compressors not too long ago. Where are you getting stuck? [15:07:53] Well i tried copying your method for the CW sounds in the LM [15:08:03] I just cannot seem to get them to play [15:08:33] I will show you what I have done so far (forgive me its a big PR, I accidently pushed my sound edits to my main repo) [15:08:41] but its in LM ECS mostly [15:09:22] CW stuff ended up from me ended up in the tree? I didn't know that, neat. [15:09:27] I'll check out your branch [15:09:47] Yeah I used your CW stuff as the backbone [15:09:50] Worked very well [15:10:15] I just added the logic and power to your CW code [15:10:27] The logic was a PITA ;) [15:11:12] Yeah, that's mostly what I ran into. I spent quite some hours staring at schematics. [15:12:03] Not helping was that I started my working when the SCERAs weren't implemented yet. I could write most of it, but not the majority of the logic. [15:13:25] Yeah Nik's SCERA in place helped me, I added a lot to it and the CW at the same time [15:13:43] But I was able to finally get through the logic and it works as far as we can tell as advertised [15:14:12] Okay, I'm all checked out. Where do I look? lm_ecs.cpp? [15:14:40] Yeah [15:14:57] I put my code in the lemprimglycolpumpcontroller [15:15:11] But I really am thinking it wasnt the best place [15:19:11] Ideally I just simply want, for any glycol pump [15:19:23] if it is turned on, the start sound plays and then the run sound loops [15:19:28] if it is turned off the sound stops [15:22:01] I was working on something similair for the CM. Someone made new suit compressor sounds years ago that included start and shutdown sounds. [15:22:09] I got it to play but they didn't really play in the right order. In one occasion the start sound kept playing continuously. [15:26:08] I see your loading the sounds twice. Once in LEM.cpp and once in the pump controller. [15:27:31] Got my last three messages? [15:29:36] Thrice even. In the constructor and the init function. [15:35:58] Sorry can you repeat :/ [15:36:02] Damn internet issues [15:36:17] No problem. haha [15:36:23] I was working on something similair for the CM. Someone made new suit compressor sounds years ago that included start and shutdown sounds. [15:36:26] I got it to play but they didn't really play in the right order. In one occasion the start sound kept playing continuously. [15:36:30] I see your loading the sounds twice. Once in LEM.cpp and once in the pump controller. [15:36:32] Thrice even. In the constructor and the init function. [15:37:23] I was kind of just copying what you did in cwea :P [15:37:27] I have commented out the sound declarations in the ecs classes. I'm still looking at how to make the sounds from the lem class available. [15:38:04] Also, I am wondering if this should have its own class [15:38:23] Just the sounds? [15:38:29] Thats my hesitation haha [15:38:38] All I need is if the pump is pumping or not [15:38:49] I think those are good where they are. [15:39:02] however it doesnt give any sound for the secondary loop pump [15:39:19] That is controlled in lemsystems [15:39:31] simply a cb turns the pump on [15:39:34] The problem is that the lm_ecs is just way better designed from an object oriented stand point that we just can't access everything we want like in the csm. :P [15:39:51] Ironic huh [15:43:13] Is the sound playing at all right now? [15:43:33] Hey @Thymo [15:43:36] Hey [15:43:46] how was your vacation [15:45:09] Very nice. Spent two weeks in the costa brava in Spain. :) [15:45:20] very nice [15:46:08] i've just been mostly playing fsx and i start my food college course next Wednesday [15:47:09] Nice. College doesn't start for another 4 weeks here. [15:47:54] Not to say I won't be busy. I'll be working about 90 hours the coming 2 weeks and then will be gone for another 2. :P [15:50:56] rcflyinghokie1: New approach. Passing a pointer to the sounds to the pump controller. That should work. [15:50:57] No sound at all [15:51:14] Feel free to do it and just push to my repo :) [15:51:34] I am simultaneously trying to get this Apollo 9 post docking timeline fixed [15:51:35] cant wait for the lem sounds [15:53:42] Argh. I've been coding in Java for two long. I keep pressing enter instead of tab to autocomplete. Guess I should change some keybinds. [15:56:56] haha [15:57:47] How can I test my changes? I don't really have a scenario with a powered lem. [15:58:43] Oh I will give you one [15:59:58] This one should work [15:59:59] https://www.dropbox.com/s/q43ufsanqamswx0/Apollo%209%20MCC%20-%20Phasing.scn?dl=0 [16:00:18] Ignore the MA that comes on when panel switching and craft switching haha [16:00:35] Its an instability in the glycol loop from long timesteps [16:00:42] Next project for me [16:01:59] Well I'll be excited to actually see the CW doing something else except test mode. :) [16:02:53] I believe I have logic for every light [16:06:03] Ugh wtf is up with my internet [16:06:36] I forgot how annoying the master alarm for the lem is. [16:08:59] Yeah [16:09:02] Welcome to our pain [16:09:11] You can pull the MA cb for now [16:09:24] That will help during this testing [16:10:43] I will [16:26:05] rcflyinghokie: Little problem pulling that breaker. [16:26:15] Oh? [16:26:24] The CW is fail safe in that the alarm comes on when the CWEA loses power. [16:26:31] No just the MA breaker [16:26:37] Not CWEA breaker [16:27:00] Ah [16:27:02] That works [17:00:25] morning! [17:01:58] good morning [17:02:11] just flew to Seattle with the pmdg 737 [17:20:49] Woo I think I figured out Apollo 9 docking angles [17:31:05] good evening [17:32:42] Hey :) [17:34:11] Looks like Apollo 9 had the same problems designating the RR [17:34:31] the actual mission? [17:34:34] Yep [17:34:37] fun [17:34:40] well [17:34:41] kind of [17:35:04] It was designating for docking [17:35:09] They ended up pulling the cbs [17:35:12] haha [17:35:18] that will certainly do it [17:35:47] I am trying to get the ballet of pre docking maneuvering in the checklists [17:36:07] I have a few LM V49 angles from the transcript [17:36:10] my V63 procedure is more elegant... although it might only be working in Luminary 069 [17:36:11] hey Niklas [17:36:13] hey [17:36:27] I made a PR with the utility lights panel [17:40:15] Hey Nik [17:42:34] merged [17:42:36] hey [17:42:50] thanks [17:43:37] also, did you try the latest D3D9 client revision? Those self shadows are pretty neat [17:46:17] yep, updated 1 or 2 weeks ago [17:46:54] it doesn't seem very framerate friendly, when I change the orientation of the outside view [17:47:48] hmm I did not notice any fps drop [17:48:14] but I havent really played around with it much yet either [17:48:36] Have a link? [17:49:05] for the D3D9 client? [17:50:29] https://www.tuttovola.org/index.php?action=downloads;sa=view;down=1150 [17:50:40] thats for Orbiter Beta R73 [17:57:35] Thats what we are running currently R73? [17:59:08] well just do SVN update on your Orbiter folder [17:59:23] Oh duh [17:59:49] Wow I never reinstalled SVN after my last wipe [18:01:04] Now I need to remember how to do this [18:01:40] http://orbit.medphys.ucl.ac.uk/betainstall.html [18:01:54] Good my SVN folder is still there I dont need to d anything else other than update [18:04:24] Very nice [18:10:13] hey @indy91 [18:18:38] hey [18:49:34] I just realized that the front cover of the AGC Handbook is a great place to steal a logo for a shirt :D [18:49:35] https://image.spreadshirtmedia.com/image-server/v1/products/1044681311/views/1,width=500,height=500,appearanceId=2,version=1533494666.png [18:53:54] Haha [18:55:06] Thymo, any luck with the sound? [19:31:04] I reverted everything. My initial idea didn't work out the way I wanted. [19:36:06] Ok :P [19:37:43] Does the cabin fan sound work? [19:38:08] Yes [20:09:53] night [20:10:01] hmm [20:10:02] night! [20:10:05] that's the one [20:17:19] I will be so happy when i finish this docking checklist [20:27:02] According to the debugger the sound is being played but I don't hear anything. Not sure what's up. [20:33:31] Maybe it doesnt like the sound file? [20:34:27] Hmm [20:34:43] Added a debug line, it's not playing according to that. [20:38:27] It must be something with the soundlib. Might not be registered properly. [20:38:40] I'll take another look after work tomorrow. [20:41:47] Ok [20:41:57] The sound files did come when you grabbed my repo right? [20:42:14] Yes [20:42:49] I'll push to the ECSsound branch in my repo so you can take a peek. Maybe you find something useful. [20:54:51] Ok thanks! [20:57:28] Oh and Mike, I spotted the commit you made to Borealis. Nice find, I enjoyed reading about it. [21:33:12] Thymo: yeah that was a fun one to write :D [21:37:58] I've been wondering what the purpose behind that change was for a really long time [21:38:04] it's nice to finally have a good answer [21:38:32] and it was super satisfying to see it work in the hardware sim :D [21:45:06] I suppose down the line yaAGC could be changed to emulate a specific AGC. [21:47:48] probably not worth it, heh [21:48:26] but I did modify my local yaAGC to have the bug for easier testing [13:51:18] hey [13:53:09] hey Alex [14:01:47] started working on Apollo 11 MCC support [14:03:56] I'm mapping everything out through MCC-2, adding new functions and variables etc., before launching the mission [14:05:34] ooh great [14:07:14] man your getting there, just one MCC mission left to make [14:07:39] with the additions, support for the whole launch window including the two TLI opportunities is theoretically possible [14:07:59] just would need better initial guesses for pericynthion latitude etc. which are variable through the launch window [14:08:35] Would it not iterate to the correct one anyway? [14:08:35] the RTCC had lots of nominal values for the launch window stored, which would have been selected based on actualy launch [14:09:01] yes, but I am not 100% sure that the initial guesses are close enough for all cases [14:09:25] pericynthion time for example seems fairly sensitive usually [14:10:09] one interesting topic is time keeping [14:10:46] from an Apollo 15 document I learned today, that they used the TEPHEM from the CMC to correct the exact liftoff time for RTCC purposes [14:10:50] I did some testing with Apollo 8 MCC and late launches/2nd opportunity TLI's and it seemed to work well with MCC [14:10:59] that's good to hear [14:11:15] Of course I had to re sequence the MCC on the case of 2nd opportunity TLI [14:11:20] yeah [14:11:31] that won't be necessary with Apollo 11 [14:11:38] and I'll update the other missions as well [14:12:05] at the predicted time of TLI the MCC will check, if the LVDC has cycled to the second set of targeting parameters [14:12:25] if yes, then it will re sequence automatically [14:12:29] great [14:12:55] and yeah, about the time keeping, the MCC will now also do a TEPHEM update, like in the RTCC MFD [14:13:10] and use that base time for all state vectors, delta V updates etc. [14:13:24] should make things a bit more accurate over all [14:14:22] oh great [14:14:27] the CMC clock should always be accurate [14:14:55] I would expect P11 to update TEPHEM and set the clock to 0 only micro to milliseconds apart [14:16:24] right [14:17:46] actually does it just before setting the mode register to P11 [14:17:52] so technically before P11 is started [14:22:37] Are you implementing aborts as well on 11? [14:23:09] what kind of aborts? [14:26:38] direct return aborts and flyby aborts? [14:27:59] those I plan to implement, yes [14:28:00] yeah [14:28:13] what about the lunar orbit/LM ops aborts? [14:28:52] I hope so, yes [14:29:06] initiating and choosing which abort to do could be tricky [14:29:21] because often there is more than one option [14:35:57] I guess I meant just the intial abort pads and then if you fly it then you are out of MCC support anyway [14:36:28] initial* [14:36:39] every update the crew got during the planned mission will be part of the MCC support [14:36:51] so yeah, lots of abort pads [14:36:56] great [14:37:10] Apollo 10 already had that as well for the rendezvous [14:37:57] Apollo 9 actually had no abort PADs at all for the rendezvous [14:38:05] well, kind of, they got one for TPI0 [14:38:12] which wasn't executed [14:38:32] all the CSM rescue maneuvers are handled differently [14:38:51] the CMP had to write down the Maneuver PADs the LM crew got and then apply some biases to it from his documentation [14:39:48] I guess for the abort button in the MCC menu, if you hit it during LM descent/surface/ascent phase, then a simple way to handle it for now is the MCC logic waits until LM has hard docked back to the CSM, then makes the next possible TEI abort [14:40:06] Is that how Apollo 10 MCC does it maybe? [14:40:35] no, it just gives the Maneuver PADs the crews actually got [14:40:40] and then no further support [14:40:48] ah, right [14:40:57] for the whole mission [14:41:02] abort button for Apollo 10 doesn't do much yet [14:41:07] skipped it for now [14:41:14] Apollo 8 is much better supported [14:41:18] right [14:42:04] theoretically abort support could be infinitively extended [14:42:10] including full alternate missions etc. [14:42:25] yeah I think that just the intial pads are good for now [14:42:47] that will force people to learn the RTCC MFD if they want to carry out the abort lol [14:44:00] haha, yeah [14:44:22] good morning [14:44:31] hey [14:55:22] indy91, I was thinking of lowering the volume of our RCS sounds a bit more as they still sound a bit excessive to me. What do you think? [14:55:36] sure [15:21:14] looks like I have everything in place to launch [16:03:59] lol [16:04:21] at T-15 minutes we have a default launch control audio playing as well as a custom Apollo 11 one [16:04:39] so we have two Jack Kings talking over each other [16:10:31] lol [16:11:31] yeah there is lots of pre-launch audio on that mission [16:11:48] makes it kind of annoying when you want to time accel [16:12:54] yep [16:46:12] morning! [16:54:58] hey Mike [16:57:57] hey [16:59:28] about the "Apollo 8 MCC Burn Scrubbed" issue on Github, I believe the targeting parameters from the LVOT can indeed make TLI so accurate, that MCC-3 is the first required MCC [17:00:23] which is fine for Apollo 8, but there actually is a possible bug related to that in the Apollo 10 and 11 MCC, so I better fix that :D [17:00:47] not that it's really possible for Apollo 10 to have a DV that enables MCC-1 and 2 to be scrubbed [17:03:18] seems a bit unlikely still that even MCC-2 is below 5 ft/s [17:03:20] and wasnt Apollo 10 & 11 targeted to intentionally over-burn TLI? [17:03:32] yeah, to compensate for the evasive burn [17:03:39] so after that it is on track again [17:04:35] TLI and evasive burn are not in exactly opposing directions [17:04:53] but fairly close [17:05:03] not close enough to result in a 0 ft/s difference [17:05:29] so no wonder Apollo 8 is the most acurate mission right now [17:08:50] there is a bit of house keeping coding to do for adding a new mission to the MCC. Forgot something for that with every new mission so far, and Apollo 11 isn't an exception :D [17:09:21] so: Apollo 11 launch, second attempt [17:11:37] AlexB_88, I don't have any recent Apollo 8 scenarios, I guess you were the only one who flight tested the full TLI targeting parameters? [17:13:15] hmm, looking at the coding, there is a possibilty that a failed MCC-1 or 2 calculation results in 0 ft/s DV and that is taken as scrubbing the burn [17:15:42] I had tested the targeting parameters, yes [17:15:50] and they did work [17:16:03] yeah, I remember single digit DVs [17:16:07] for the following MCCs [17:17:33] " The usual Midcourse Correction that is necessary after TLI is now as low as 5 feet per second." is what I wrote to Ron Burkey, who got us the numbers from the LVOT [17:20:30] so I am just hoping it's actually not a bug, but a good TLI plus healthy separation maneuver :D [17:23:30] oh, and the new self shadows in the DX9 Client also look very nice on the launchpad [17:23:43] when the access arms are rotated away for example [17:24:43] yeah [17:25:09] with the "projected" setting [17:35:05] default is "Stencil". What is different in projected? [17:56:14] It seems to better cast the models shadow onto the surrounding terrain in my tests [17:57:08] ah [17:57:16] Like its more apprent on the lunar surface, sometimes the LMs shadow is not well aligned with the LM depending on the shape of the terrain its on [17:57:18] guess I'll try that as well then [17:57:24] apparent* [17:57:49] but projected seems to fix that somewhat [17:57:59] Apollo 11 launch, third attempt [17:58:10] the LM indeed has no LVDC on board [17:58:24] it also doesn't exist yet to have its AGC accessed [17:58:37] trying those things cause CTDs, who would have thought :D [17:58:38] Only one issue though with projected, you cannot see the shadow form the cockpit [17:58:49] so thats an issue during the lunar landing of course [17:58:54] yeah [17:58:59] Ill report that bug I guess [17:59:18] that's purely a DX9 Client thing, right? [18:00:27] I think [18:06:31] ll be out for a bit [18:06:33] cya [18:07:53] cya [18:13:10] lol, a LM with an LVDC [18:13:20] that sure would have made IBM happy [18:13:58] could have been used for the powered descent [18:14:27] the output of the LVDC is very similar to the AGS [18:14:46] just attitude error, actual control is done by analog circuits [18:15:09] so just hook up the LVDC to the ATCA and there you have it :D [18:16:04] lol [18:21:24] Apollo 11 is just like Apollo 10 they said [18:21:34] just copy over the MCC-H stuff they said [18:22:00] right now it's working as well as copying over code from Ariane 4 to 5 :D [18:22:15] like establishing the TEPHEM [18:22:17] part of that is [18:22:18] TEPHEM0 = 40038.; [18:22:28] which is absolutely correct for Apollo 10 [18:22:38] but not 11... [18:25:23] hahahaha [18:25:30] rough comparison :P [18:26:36] gave me a nice launch date and time: July 16, 1968. 13:32:00.18 [18:26:42] find the error... [18:26:56] hmm [18:27:03] it was a few seconds later than that, wasn't it? [18:27:04] just a few [18:27:45] roughly 31,536,000 seconds later [18:28:00] yeah, just a few [18:29:03] the 0.18 seconds is fairly significant, if not accounted for [18:29:18] so that's one thing the MCC is doing now [18:29:25] still smaller than actual missions [18:29:37] Apollo 15 for example was 0.79 seconds [18:30:21] roughly the delay from commaning IU umbilical disconnect, actually disconnecting it, and caused by that a signal to the CMC gets send [18:30:25] commanding* [18:31:00] and a bit of delay in the AGC itself [18:34:50] although I actually don't know how much [18:34:56] I've looked a bit in the code [18:35:11] clock time being zeroed and a new liftoff time being calculated are very close to each other [18:35:30] so I would expect them to be no more than some milliseconds apart [18:35:54] but the delay between liftoff discrete being set and clock being zeroed would be interesting to know [18:35:59] how often does it check that? [18:39:47] hmmm [18:39:58] what is the liftoff discrete? [18:40:41] channel 30, bit 5 [18:41:21] what major mode is the AGC in at that time? [18:41:38] P02 I think [18:42:43] ah, CHKCOMED [18:42:57] yeah [18:43:03] and that starts up P11? [18:43:22] yep [18:43:27] that or the backup signal [18:43:28] yeah, that's the one then [18:43:33] so how often is that called [18:44:31] seems like there's a periodic waitlist task that runs ALFLT, which calls CHKCOMED [18:45:50] seems like every 0.5 seconds when compassing? [18:46:01] seems high, but possible [18:51:12] found something in the programmed guidance equations for Colossus 3 [18:52:23] "At the beginning (in "ALFLT") and end (in "SLEEPIE") of each half-second gyro-compassing cylce in P02 or P03, a check is made for liftoff..." [18:52:30] so twice in that 0.5 seconds [18:53:01] probably means the 0.18s I got on this launch are quite average [18:58:43] ok, Apollo 11 launch, take 4 [19:00:30] Evening! [19:02:47] hey Thymo [19:03:51] What's up? [19:04:45] working on MCC support for Apollo 11 [19:13:25] heya Thymo [19:21:20] seems like I got the year right this time [19:41:32] back [19:42:58] wb [19:44:00] wow, 4 takes! You must really be getting sick of hearing Jack King... [19:45:20] no, I saved at T-30s [19:45:32] only the usual T-10s countdown then [19:45:48] and also some flight controller loop snippets [19:47:56] I guess one thing I should do is make the TLI simulation for the PAD etc. able to handle a PU shift in the middle of the TLI burn [19:48:13] burntime is off otherwise [21:02:54] night! [21:18:14] night! [21:41:41] night! [11:42:14] good morning [11:52:48] hey [13:14:07] morning [13:15:02] hey Alex [13:15:09] had a good Apollo 11 TLI [13:16:12] the new TLI PAD calculation is within 2 seconds of the burntime on the historical TLI PAD. Only problem is, my actual burn time just now was almost 10 seconds too short. So something is off there. [13:27:00] hmm, weight maybe [13:28:03] could be, but the TLI PAD gets calculated with the actual weight [13:28:15] I have to check if thrust and ISP are right [13:29:14] and CSM weight is a bit high, 1700 lbs. I guess Ryan has to take a look at that. [13:29:31] 1700 lbs too much* [13:32:45] but other than that I have a lot of confidence in the new TLI PAD calculation [13:33:18] Apollo 8, 10 and 11 burn times were off by only 3, 1 and 2 seconds respectively from the the historical PADs [13:41:24] great [13:51:31] the difference to before is of course taking into account that the MRS is not happening right at the beginning of the TLI burn, but later on [13:51:53] at least in the case of the first opportunity [13:56:50] total vessel mass looks fine [14:02:33] yay, UHCL has [14:02:34] operational support PLAN FOR THE REAL - TIME AUXILIARY COMPUTING FACILITY APOLLO 11 FLIGHT ANNEX [14:03:05] probably not many difference to Apollo 10, but I guess I'll request it anyway [14:12:00] oh damn [14:12:14] I think the MRS is commanded through flight sequence program right now [14:12:18] at least for Apollo 10 and 11 [14:12:28] at 3 seconds after IGM start [14:12:36] no wonder TLI burn time is short :D [14:14:17] quite the oversight [14:15:09] let's see if that changes the burn time... [14:22:31] definitely does the MRS right on schedule now [14:26:16] cutoff right on time now [14:26:24] awesome that it was such a simple thing to fix [14:28:47] pushed my latest state [14:28:58] Apollo 11 MCC implemented and tested through the evasive maneuver [14:31:59] nice work [14:48:55] thanks! I hope to progress quite quickly with Apollo 11 [14:52:24] shouldn't be many new RTCC things to be implemented until LM undocking or so [15:21:04] hmm, build has failed [15:22:12] no, build was good [15:22:16] upload of the build was bad [15:22:29] Error creating GitHub release: Error reading repository 'dseagrav/NASSP' releases: 502 - Bad Gateway [15:22:37] just happens occasionally, I think [15:25:59] @indy91 are you working on 11 right now? [15:26:08] yep [15:26:27] very great to hear [15:28:00] not sure if you remember this Niklas but i asked you about the 11 MCC in December and its finally happening now [15:28:25] yep! just had to do Apollo 9 and 10 first, haha [15:29:00] but im still glad that i did a full 11 mission with the rtcc mfd [15:29:33] now you know how to fly the mission from the flight controller perspective [15:29:56] yeah [16:42:21] morning! [16:45:25] hey [16:45:44] how goes 11? [16:45:59] up to 6h GET [16:46:04] so very well [16:46:22] nice :D [16:52:31] pretty much copy&pasting some stuff from Apollo 10 right now [17:05:32] Evening [17:06:30] hey Thymo [17:06:46] What's happening? [17:07:25] still working through all the new schematics and making lots of corrections to the backplane database [17:07:45] and starting to think about how I want to go about actually building the first modules for my AGC [17:08:06] Cool. [17:08:25] I'm just preparing some dinner and then might work on the app for a while. [17:08:30] nice [17:09:11] For some reason the sign bits stopped working. Maybe I messed up the bitmask. [17:09:45] Apart from that and some timing issues it works like a charm! [17:10:02] very cool! [17:10:12] what sort of timing issues? [17:11:04] I still do the while(1) {usleep(11.7);} stuff. So it runs too slow. [17:11:51] oh yeah [17:12:02] you'll definitely want to implement that similar to how yaAGC does it [17:14:08] I've looked at that. I'm not sure if I understand it yet. [17:15:37] it essentially chunks the processing into larger timesteps [17:38:32] hey Thymo [12:00:45] good morning [12:00:53] college starts today for me [12:10:35] hey [12:11:15] so less time flying NASSP I guess :D [12:11:39] its only three days a week [12:13:22] so lots of free time then [12:18:22] I'm up to the first rest period of Apollo 11 right now [12:18:26] should get MCC-2 done today [13:04:59] morning [13:05:45] hey Alex [13:14:22] I'm trying to check if the PTC REFSMMAT I am using for Apollo 11 is right [13:15:06] but it seems like it's the same as with Apollo 10. I have two documents from early July saying which REFSMMAT would be used and they agree with each other. But if I am using IMU angles from the transcript, then it doesn't work out. [13:17:12] so in real time they must have been using a different REFSMMAT [13:17:37] there are lots of references in the transcript to attitudes "pen-and-inked into the Flight Plan" [13:23:41] yeah I guess our method of using the average monthly TEI time only works from Apollo 12 onwards? [13:25:58] it might be the other way around even [13:26:21] the REFSMMAT in Apollo 10 and 11 documentation is not compatible with the way we calculate it in the RTCC MFD [13:26:28] the RTCC MFD does it the Apollo 12 and later way [13:26:54] but maybe, on the actual mission, they used a PTC REFSMMAT calculated the RTCC MFD after all [13:27:02] I'm trying to reverse engineer the REFSMMAT [13:27:22] so right now with the MCC I have the PTC REFSMMAT hardcoded for Apollo 10 and 121 [13:27:24] 11 [13:49:50] I am using the backup GDC alignment from the historical MCC-2 Maneuver PAD [13:50:06] align the IMU to that with P51 and then downlink the REFSMMAT [13:51:10] very rough procedure, I can probably calculate it from some PAD data [13:52:53] and I did it wrong somehow, haha [13:55:44] oh, I know [14:00:18] hmm [14:25:15] ok, I'm not having any luck with this, haha [14:25:19] different approach [14:25:33] try if the RTCC MFD can come up with the right REFSMMAT [14:26:12] and it looks good actually [14:26:18] PTC REFSMMAT calculated with a GET of 190h [14:26:30] gives the same attitude as on the MCC-2 Maneuver PAD [14:26:35] thats almost re-entry time [14:26:48] yeah, but remember, average TEI time [14:26:57] hmm [14:26:58] still [14:28:23] average TEI time could also mean, it works for July 16, 18 and 21 launches [14:28:33] right [14:28:44] so maybe referenced to something for a July 18 launch [14:30:14] btw Ive been adjusting the CSM RCS texture, I have noticed that it looks too small when firing. It displays about half the size when firing, as the LM RCS does. [14:30:49] So what I did was copied the width and length of the LM RCS, over to the CSM and it looks a lot better [14:32:54] and it would make sense to me as both seem to have similar RCS specs (thrust/ISP) [14:33:59] yeah [14:34:07] do what you think is more realistic [14:37:23] ill simply make them both the same as the LM is [14:37:53] length 3, width 0.15 [14:39:52] very easy change, ill have a PR up shortly [14:45:14] sure [14:45:44] so, from what I know from the mission control tapes so far is that a lot of calculation requests are done via voice [14:46:05] so I might actually figure out what specific calculation they requested for the PTC REFSMMAT [14:46:15] by continuing to listen to the tapes [14:52:12] PR sent [14:59:15] merged [14:59:55] well, not much I can do about this PTC REFSMMAT business right now [15:00:09] I'll keep on using the one from the preflight documents, until I find a better source [15:00:23] it's working perfectly fine [15:12:13] Good morning [15:14:52] hey Ryan [15:16:10] Hows it going [15:21:48] hey [15:21:58] I've had something for you [15:22:01] what was it... [15:22:15] ah, CSM weight [15:22:28] I think our Apollo 11 CSM is 1700 pounds to heavy [15:22:43] that's compared to the weight on the evasive Maneuver PAD [15:24:09] Oh yeah? [15:24:40] Wonder where the discrepancy lies [15:24:59] I checked a little bit, and found your source for the SPS propellant mass [15:25:03] that looks right [15:25:10] so maybe empty masses [15:25:26] Those i believe were in the mission report [15:25:29] Or the scot [15:25:39] I cant check at the moment [15:25:52] But one of those had empty masses [15:27:42] yeah [15:27:56] no rush, I'm sure I have enough propellant to get into lunar orbit :D [15:28:42] Haha indeed [15:29:41] Oh i have the rendezvous finally done on the checklist, i flew it quite a few times [15:30:50] the more you flew it, the less I liked my ground solutions, haha [15:31:00] I had to write in a procedure for the docked LM P52 but thats where i am, just need to do LM closeout and IVT [15:31:18] Haha oh did you figure out the FDAI angles on the pads? [15:31:24] Was it the copy from 10 [15:32:07] haven't looked into that yet [15:32:35] I'll probably fly Apollo 9 again anyway before the release [15:32:48] did the LM docked realign angles work out? [15:33:13] Yes they did [15:33:15] the "point AOT with CSM" thing [15:33:16] good [15:33:36] Might need to work on the timing of them but they worked well [15:33:43] ok [15:34:13] ah, they are mission time right now [15:34:18] should probably be TPI relative or so [15:34:59] I think that should be fine as mission time [15:35:23] ok [15:35:44] it's 99:15 right now [15:35:52] I think my issue was the 2 minutes between [15:35:55] ah [15:36:01] needs more? [15:36:20] Maybe or one pad with both, idk how it was done [15:37:02] Maybe i need to write faster :P [15:37:18] But again ill fly it a few more times and make sure it wasn't just me [15:37:46] The docking attitudes from the transcript work really well btw [15:37:57] So good targeting of the burns [15:38:20] I do hit sunset right at docking though [15:38:44] I had hard dock just after dark haha good thing the cms docking target was lit [15:38:55] Cm's [15:39:18] looking at the flight plan [15:39:30] docking 99:14 [15:39:36] sunset 99:20 [15:39:39] so pretty close [15:40:13] we should have about the same relative timing [15:40:27] after all TPI is set at a specific time before sunrise [15:40:52] Hm i think i used fp docking time or maybe i took too long again need to look and see [15:40:53] also possible is that we have different lighting because of a different launch day [15:41:02] Oh thats true [15:41:13] then TPI might have been placed earlier [15:41:15] maybe [15:41:33] Does rtcc calculate sunset/sunrise in LEO? [15:42:04] I think so [15:42:17] if not I have to add a page for it, because the calculation is definitely in the RTCC [15:42:17] I think it only did for "Moon" [15:42:27] just maybe not in the MFD [15:42:34] Earth only had AOS LOS [15:42:39] map update? [15:42:52] Yeah [15:43:03] I am pretty sure thats the page i used [15:43:12] I'll check [15:43:23] and if there isn't such a thing, I'll add a MFD page for it [15:44:48] or modify the map update page [15:45:04] in the real RTCC there would be several related displays [15:46:34] in this case the "Daylight-Darkness Summary Sheet" [15:46:51] with cape crossing, terminator set, sunset, sunrise, terminator rise [15:47:17] and GET, GMT, lat/long for all of those [15:48:02] just loaded my scenario after docking [15:48:08] I was quite early with that [15:48:10] about 99:00 [15:48:24] Yeah they spent a lot of time station keeping [15:48:26] TPI was also earlier, but not that much [15:48:30] right [15:48:33] I didn't I guess [15:48:38] Yeah haha [15:49:02] I added the maneuvers for the lm to perform for the cm too from the transcript [15:49:15] Face to face, rotation, engine bell [15:49:35] But still im done by 99 easy [15:49:53] I'm making it 3 minutes between those alignment updates and I'll look which PAD they actually used [15:50:07] Ok i think that will help [15:50:08] there is a generic gimbal angle update PAD, maybe that one [15:50:23] Check the transcript too [15:50:27] right [15:50:37] I learned a lot from it [15:51:01] yeah, me too with Apollo 11 right now [15:51:27] apparently I can throw everything away about the PTC REFSMMAT in preflight documents [15:51:32] they used a different one anyway... [16:04:18] Haha what was the difference? [16:05:49] well, it's different [16:06:00] I have two preflight documents confirming which REFSMMAT was to be used [16:06:04] but they don't use it [16:06:10] same issue actually with Apollo 10 [16:06:18] on the actual mission they use a different one [16:06:48] the one in preflight documents can't be calculated with the RTCC MFD, but I suspect the one they actually used is the type you can calculate in the RTCC MFD [16:13:30] Ah [16:16:13] Oh, thymo and i were trying to get the glycol pump sounds working, probably did things all wrong :/ [16:17:03] Its in my local repo if you want a look. I have it in the pump controller code right now [16:17:57] I'll look at it [16:18:13] I wouldn't know if it is wrong, I never messed with any audio code [16:19:24] great, my Apollo 11 mission will be 10 minutes behind the flight plan in lunar orbit [16:21:56] I really wonder what I am doing wrong with that, so that there always is a delay [16:23:47] Ok thymo is helping with it [16:26:23] the code for those sounds is very messy, haha [16:27:57] why are they loaded twice? [16:28:00] in constructor and init [16:38:31] never mind about that being late [16:38:57] it's interesting, the historical MCC-2 solution was almost in the opposite direction of mine [16:39:24] and the actual mission was 5 minutes too early at LOI TIG, and I will be 5 minutes too late [16:39:29] both compared to the flight plan [16:39:32] funny how that works [16:41:14] Yeah i copied thymos cwea sound code [16:41:26] His was loaded twice i think too? [16:41:54] seems unnecessary [16:42:16] Check out the sound code in cwea and see if it is haha [16:42:39] I'll check some other places where sounds are initialized in a class [16:42:49] also, what all does this add [16:42:57] cabin and glycol fan sounds? [16:42:59] Ok my intent: [16:43:00] pump* [16:44:15] Pump is pumping: startup sound plays and not looped, when finished the run sound plays looped, when the pump is off the sound stops [16:44:33] I didnt do cabin fan sound [16:47:08] morning! [16:47:24] Hey Mike, i started ignition finally [16:47:36] awesome :D [16:47:57] The chemist in me is geeking out with all the compounds! [16:48:13] yeah he spares no details lol [16:48:46] Im enjoying the discovery development and naming of hypergols currently [16:49:11] Many more than i knew were experimented [16:50:45] yeah, I added the cabin fan sound :D [16:50:47] hey Mike [16:52:19] do we have any precedent for a sound that has a system starting, running and stopping? [16:53:16] Not that im aware of [16:57:40] Maybe something in the DeltaGlider code has examples of such a thing? [17:05:34] I indy91 we have a consumables analysis scot for 11 dont we? [17:06:10] yes [17:06:13] dated July 3 [17:06:41] Where online is it i cant find it [17:06:57] Its where i got the empty masses (i hope) [17:07:09] Work computer, no links or saved docs :/ [17:07:32] archived NTRS [17:07:56] https://web.archive.org/web/20100511194452/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740072754_1974072754.pdf [17:09:08] has an initial CSM mass of 63457 lbs [17:09:38] mine is 64916 lbs before MCC-2 [17:09:53] it was 65100 lbs or so at the evasive maneuver [17:12:29] Yep masses are right [17:12:33] Ill check the math [17:17:25] Looks right [17:19:55] My csm mass from empty plus propellant is 63879.9 on here [17:20:26] So idk where the extra 1000 lbs is from [17:21:29] Heres some difference though less fuel in the mission report tgsn the scot [17:21:29] the total mass in NASSP is: SM empty, CM empty, SPS propellant, 4x SM RCS propellant, 2x CM RCS propellant [17:22:17] Sm empty:4785kg cm empty:5570kg [17:22:45] Cm rcs total is 111.5kg [17:23:08] Sm fuel+ox total 18507.9kg [17:23:37] SM RCS is 4x152.5kg [17:23:38] Hmm the 2x and 4x in there [17:24:10] Smrcs total is 607.8kg [17:24:19] That adds up [17:25:18] gives me 65217 lbs [17:25:37] so what is wrong then [17:25:50] maybe the empty mass includes the RCS mass? [17:25:57] of the numbers you found [17:25:57] How did you get that number [17:26:06] I get 63879 [17:26:14] I added all you listed [17:26:26] 29582.2 kg [17:26:37] 28975 [17:26:40] Kg [17:26:44] 4785+5570+111.5+18507.9+607.8 [17:27:23] Oh i dont have smrcs in this [17:27:37] Because that was a default number [17:28:27] I dont think empty includes rcs in this [17:28:36] #define RCS_FUEL_PER_QUAD 152.5 [17:28:45] that's what we always use at least [17:29:08] Yeah close enough [17:29:17] 151.95 per quad on 11 [17:29:52] Im going to add the mission report fuel numbers instead of the scot [17:30:00] They shoukd be moree accurate right? [17:30:02] where did you get empty weights? [17:30:26] so you think theissue is the SPS propellant, not the empty masses? [17:30:53] because the total RCS mass is roughly the same as the mass error [17:31:09] Empty weights from scot [17:31:14] which page? [17:31:28] but even the SCOT has the lower total mass [17:31:44] Document page 27 [17:31:59] Pdf 38 [17:32:24] I doubt those are empty masses [17:32:31] Ahh [17:32:41] Well damn i did a bad [17:33:02] I would guess those are total CSM minus SPS, which is listed separatel [17:33:05] Let me recalculate assuming they include rcs [17:34:04] Hmm [17:34:09] 62294? [17:34:44] no [17:34:55] too low [17:35:17] Thats subtracting rcs from those masses [17:35:22] if I add up the CM and SM masses on that page I get 63425 lbs [17:35:41] SM RCS analysis has 63457 lbs as the initial value [17:35:43] so fairly close [17:36:13] which number did you subtract from which number [17:36:18] So to convert those cm and sm masses to empty im subtracting rcs, correct? [17:36:47] CM 12280 lbs [17:36:51] CM 12280-245.9 [17:36:52] minus 111.5 kg [17:37:08] yes, that looks right [17:37:20] SM 10551-1340 [17:37:35] yes [17:38:17] Then add 40803 sps [17:38:22] 61838.5 lbs without RCS [17:38:33] hmm [17:38:39] Oh i forgot smrcs again [17:38:44] yeah, that would give 62500 something [17:39:12] weird [17:39:29] Yeah 63634 [17:39:39] haha [17:39:47] oh, I did a bad [17:40:06] I dont have it on this part of the excel doc because i didnt need it for the scn file [17:40:30] now I get 63429 [17:40:33] close enough [17:40:48] Ill change the fuel to the mission report fuel also [17:40:54] See what it comes out as [17:40:57] sure [17:41:16] I mean, that is a pretty exact science :D [17:41:25] what it will result in in NASSP [17:41:39] :) [17:41:54] Oh nevermind i did use those numbers [17:42:24] Sm fuel 15712 lbs ox 25091 [17:42:28] Including lines [17:42:48] I remember when it wasn't an exact science, and the CM randomly had the CM RCS mass as part of the empty mass... [17:42:51] but that was a code issue :D [17:42:57] Haha yeah [17:43:45] So that number is much better [17:44:08] If we added crew, equipment, and consumables it would be right on [17:44:26] great [17:44:39] as I said, just one of those things I noticed [17:44:50] TLI burn time was also off, but I fixed that [17:45:00] Ill push the excel sheet tonight if you want to fix the scn files [17:45:29] Or i can just add it all tonight if tgeres no rush [17:45:45] you can push the updated excel sheet and launch scenarios [17:45:51] Ok [17:46:05] I don't think I'll update my mission scenarios [17:46:12] 1700 pounds isn't that much [17:46:20] won't change anything for the MCC implementation [17:47:11] Good catch [17:47:29] another annoying issue is the entry range on Abort PADs [17:47:35] Im pretty sure the other empty masses are actually labeled as such fir the other missions [17:47:38] as compared to the actual ones [17:47:46] but that's very much my department, haha [17:47:55] Yes it is :) [17:48:02] yeah, I guess just this Apollo 11 document had it a bit confusing [17:48:28] TLI PAD can now deal with mixture ratio shifts in the middle of TLI burns [17:48:40] previousy it couldn't and it predicted the burn time wrong because of it [17:49:03] didn't matter anyway, there also was a LVDC bug that always did the MRS at the beginning of TLI [17:49:58] so those issues mostly cancelled each other out until recently :D [17:55:23] pushed my latest state [17:55:30] Apollo 11 done through MCC-2 [17:55:44] Nice [18:05:03] I have some procedures to add to 10 and 11 for IVT and switching ECS and such, they worked well for 9 [18:09:17] Ill fly 11 on your heels again and fix things like 9, the method works pretty well [18:09:32] Then 10 with hopefully a better timeline ;) [18:15:27] I'm not really convinced yet that I have figured out the Apollo 10 timeline issue [18:15:33] might still be TLI targeting [18:16:52] Well it will be a while till I'm there anyways ;) [18:18:20] .tell thymo did you have any additional luck with the glycol sounds? [18:18:35] and maybe NASA takes pity on me and sends me the AS-505 LVOT at some point [18:18:54] such an LVOT does wonders [18:19:16] like this conversation shows: https://github.com/dseagrav/NASSP/issues/378 [18:19:33] TLI was so good, that MCC-1 and 2 were both scrubbed [18:19:42] criterion is 5 ft/s DV for those [18:37:45] Its so funny how this stuff just vanishes or gets lost or never gets reviewed for declassification probably because its all paper and nobody wants to do it [18:38:18] Imagine if we tried this 50 years from now to fet docs fron today [18:38:34] Ehh never mind, government would still have it all congested ;) [18:52:37] in 50 years many more documents will be lost [18:54:26] so better get it all yesterday [18:55:04] the LVOTs annoy me more than anything else [18:55:15] because it's just so inconsistent [18:55:46] currently publically available: Apollo 14 [18:55:54] I mean docs created now [18:56:03] Because they would likely be digital [18:56:19] still, someone has to read it [18:56:22] to declassify it [18:56:35] Hence the congestion [18:56:38] yeah [18:56:58] docs created now... [18:57:15] Space Shuttle documents had a fairly good availability [18:57:28] there still is this [18:57:29] https://www.nasa.gov/centers/johnson/news/flightdatafiles/index.html [18:58:03] I haven't seen any Orion, Dragon or CST-100 checklists or operational trajectories or anything like that [19:06:47] Maybe not for a little [19:08:05] I guess when those are appearing, then we will know that they are serious about flying those machines, haha [19:20:27] Haha yeah i will not hold my breath just yet [19:31:58] Tine to catch my train [20:52:58] good night! [09:18:47] good morning Ryan [09:19:05] Morning [09:19:14] I am just peeking in briefly before work haha [09:19:31] started my first day of college yesterday [09:24:36] Congrats! [09:24:49] I have to catch my train I'll be on later :) [10:38:44] good morning [10:44:12] hey [12:45:43] .tell rcflyinghokie The size of the glycol pump audio files is a bit excessive. 11MB for 7 seconds?? [13:43:18] hey rcflyinghokie. Past me has a message for you. [13:49:39] Past you? [13:49:51] Oh haha [13:50:05] I can probably get them smaller [13:50:24] occasionally I check the file size of the NASSP release file, just to see if it changes by any unusual amount, haha [13:50:40] They are the same sample rate and format as other sounds in there but ill check and see what i can do this evening [13:50:43] suit fan seems ok [13:50:56] glycol pump and glycol start are quite large for their length [13:51:54] cabin closeout sound is 25 seconds and just 1 MB [13:52:27] so I am sure it can be made a bit smaller [13:53:06] Yeah probably a setting in wav generation [13:53:22] Shouldn't be an issue to make smaller [13:56:30] great [13:56:39] I figured out my issue with the PTC REFSMMAT [13:56:43] at least for Apollo 11 [13:56:58] What was it? [13:57:26] I had added a parameter for the function calculating the octals for a REFSMMAT uplink. [13:57:40] and with that change the REFSMMAT was converted to the AGC coordinate system by default [13:57:55] I took the PTC REFSMMAT from documentation, so it already was in the right coordinates for the AGC [13:58:15] so the REFSMMAT was converted, when it didn't have to [13:58:32] so that made it off by roughly the angle of the Earths axial tilt :D [13:59:13] I changed that function for Apollo 9, because the LGC gets a desired REFSMMAT uplink [13:59:38] but I did Apollo 9 after 10 [13:59:50] so the function must have still been right when I did the Apollo 10 MCC [14:00:02] but for Apollo 10 the PTC REFSMMAT was also wrong [14:00:12] so only half the puzzle solved... [14:00:45] hey [14:00:47] hey Alex [14:01:06] but for Apollo 11 it now seems right. When I use an attitude for P23 from the transcript it works out [14:01:14] any more PRC REFSMMAT luck? [14:01:18] PTC* [14:01:22] yeah, my fault for Apollo 11 [14:01:27] still not sure about Apollo 10 [14:01:48] So the conversion didnt fix 10 just 11? [14:03:15] when I flew Apollo 10, the function was working right [14:03:42] I give it a flag if the supplied REFSMMAT should be converted or not [14:03:49] ooh do we have glycol pump sounds now? [14:03:56] So is it still wrong [14:04:03] I fixed it now [14:04:17] Ehh still working on making them play [14:04:36] it was working right when I did Apollo 10. So that PTC REFSMMAT, from preflight documentation, seems to not be the one actually used [14:04:42] for Apollo 11 the function was initially broken [14:04:48] I have the messy code in a new local to experiment [14:04:50] then I fixed that and uplinked the right REFSMMAT [14:04:56] Oh weird [14:05:06] now Apollo 11 works out, so the preflight REFSMMAT for that mission was correct [14:06:49] fun fact for Apollo 11, their free return trajectory gives a mid Pacific landing, just by luck [14:07:07] so the flyby solution targeted to MIDPAC is very small [14:07:12] nice [14:09:03] rcflyinghokie, I may know the problem with the sounds [14:10:18] Fire away [14:10:38] they have a too high bitrate [14:11:02] 12288kbps [14:11:20] the other sound files are much lower, like 705kbps [14:12:47] pretty sure I had the same issue with the LM master alarm and I had to reduce the files size/bit rate to get it to run [14:13:45] oh, so that could pretty much solve both issues. It not playing and it being excessively large files, haha [14:14:39] I reduced the bitrate and it still didn't play [14:14:53] I matched the parameters of the cabin fan sound file [14:15:28] And the bitrate is much smaller than 12288...unless my newest version of those files didnt get in the pr [14:15:55] But you are probably right [14:16:42] 12288 kbps sounds about right for the current file size [14:17:07] Then for whatever reason my lady edits to the wavs didnt save :/ [14:17:14] Last not lady [14:17:45] lady edits sounds interesting [14:18:02] Maybe them not saving was why they still did not play for me after i thought i edited haha [14:18:10] Technical term ;) [14:26:12] found it! [14:26:22] its because you have to make the sounds mono [14:26:52] I just made them mono on my end and they work in sim [14:27:20] Oh wow [14:27:38] So i can clean up my code and it will work [14:28:19] I just tested it by assigning the new sound to the LM master alarm, just to see if it plays [14:29:54] speaking of the PTC REFSMMAT, Ryan, when you get to do the Apollo 11 checklists, I have implemented alternative logic for MCC-1 scrubbed or not [14:30:06] if MCC-1 gets scrubbed, the REFSMMAT is uplinked early [14:30:36] I should probably go back and do the same for Apollo 10 [14:42:41] Oh ok [14:42:56] Did we do that for 10? [14:43:00] Sounds familiar [14:43:54] we talked about it [14:44:02] but I didn't implement it for the MCC at the time [14:44:24] your checklist partially already consider that early uplink [14:44:32] so shouldn't need many changes when you get to it [14:45:47] Right [14:47:34] hello Eagle, how have you been the past two days? :D [14:48:57] is there any checklist for LM Familiarization? [14:49:07] doesn't show me anything yet [14:49:20] or do I have to select flight plan? [14:49:46] ah yes [14:49:47] I have [14:53:34] I do t think familiarization has a checklist [14:53:54] But all entries that include it do [14:54:05] But that step is simply just text [15:00:49] yeah, I just had to click on flightplan in the Checklist MFD [15:00:53] didn't start automatically [16:05:24] So did the checklist not come up? I think its set for a certain mission time [16:06:18] it did not come up on its own [16:07:03] First lm entry? [16:07:56] yeah [16:07:57] hmm [16:08:05] it should come up at 56:10 [16:08:10] I'll test if I was too impatient [16:08:45] And as i said i will be cleaning up the ivt procedures a lot [16:08:51] They are messy on 11 [16:12:12] There is a deadline on the group as well naybe its too short [16:12:17] When did you enter [16:12:55] Yeah the deadline is 20 minutes so 56:30 [16:13:05] That should be adjusted just in case [16:16:46] how does this deadline thing work? [16:18:26] ok, LM checklist does appear at 56:10 [16:18:43] I think the confusing thing was that the CSM checklist told me to go to the LM at 56:00 [16:18:49] and then there was no checklist there [16:19:39] maybe it could be adjusted so that when the CSM checklist tells you to go to the LM, the checklist there starts at the same time [16:20:56] Yeah i plan on it [16:21:00] great [16:21:30] And ill double check 9/10 but i think they have good times [16:22:46] yeah, I had no problems there [16:25:20] Good [16:27:59] tomorrow I should get into lunar orbit [16:28:09] so far so good, only small adjustments from Apollo 10 [16:29:36] Excellent [16:45:10] morning! [16:48:08] hey Mike [16:54:31] what's up? [16:55:36] just flying a bit more Apollo 11 [16:55:46] tomorrow I'll be in lunar orbit I think [16:56:10] :D [17:08:52] I say you try to land the csm ;) [17:09:37] Afterall the sps wss originally designed for a lunar descent/ascent [17:09:56] who tried to land the CSM? [17:10:36] oh "say" [17:10:39] I read "saw" [17:11:07] That would be a feat [17:11:16] it would [17:11:45] getting back into orbit might be a problem [17:11:57] propellant problem [17:12:03] No throttle might make it nearly impossible as well [17:12:27] hmm, I think there isn't even enough propellant to get down [17:12:36] have to do LOI with the DPS [17:12:46] Haha ironic [17:14:24] I guess you could design descent and ascent stage as pure burn stages for LOI and TEI [17:16:28] APS might be able to TEI a nearly empty SM [17:17:13] Or at the very least deplete DPS and then FITH with APS lol [17:17:20] yeah [17:17:37] Sounds very Kerbal [17:21:16] there are some LOI aborts that need DPS and APS [17:21:51] Mode I is hyperbolic orbit, Mode II is unstable orbit, Mode II is high lunar orbit [17:22:10] a very late Mode I requires DPS to depletion and then APS burn for example [17:22:12] Apollo 14 [17:22:51] I haven't looked much at LOI aborts, just saw those charts in the flight plans [17:23:18] One funny thing I have tried was to run P63 and PDI with the staged ascent stage [17:23:54] how did it like it? [17:24:24] one thing that is supported by the LGC is guided RCS insertion [17:24:32] cut off the APS a bunch of seconds before insertion [17:24:33] If I recall, it did start burning, but things went downhill at a very rapid pace thereafter :D [17:24:35] and then burn the RCS [17:25:37] oh so it will steer for you while you burn RCS? [17:26:15] yep [17:26:24] of course only works very late in the ascent [17:26:33] I haven't seen much checklist reference to that [17:26:36] but it's in the GSOP [17:26:45] ill have to try that [17:30:48] hmm [17:30:55] apparently it doesn't do it automatically [17:30:59] I thought it did [17:31:16] it just provides help to the astronaut to manually do it with the RCS [17:31:23] probably error needles and DV display [17:31:25] maybe burn time [17:31:47] yeah, it calculates time-to-go [17:31:55] and goes through the same guidance equations [17:32:29] some of it [17:34:05] oh and for LOI, the APS is only needed on hybrid trajectories [17:34:13] because getting back to Earth needs more DV [17:35:26] for Apollo 11 and so it's just a burn with a specific DV at PC+2 [17:35:34] using the DPS [18:14:48] So every mission after 11 would need APS [18:15:44] I guess it depends on how unfree the return is [18:16:03] 12 is very unfree [18:16:07] and the flight plan confirms that [18:16:27] it has LOI abort modes using both DPS and APS [18:16:37] 13 and 15 might be ok [18:16:42] 14 and 17 are very unfree as well [18:16:50] not usre about 16 [18:16:52] sure* [18:17:26] yep, 13 has DPS only abort modes [18:17:36] 14 I checked earlier, has to use APS [18:18:19] for 15 the chart isn't in the flight plan [18:19:25] 16 is difficult to read [18:19:27] looks like no APS [18:20:19] 17 needs APS for some modes [18:21:09] and even a FITH [18:21:14] but only for the loss-of-comm case [18:22:45] so lots of different procedures [18:23:25] maybe I'll implement the calculation for the chart update for Apollo 8, 10 and 11 [18:40:32] reorganized the MCC code a bit, mission specific stuff in their own files [18:40:45] looks very neat now. We support missions B, C, C Prime, D, F and G :D [18:42:11] no Mission E, sorry [18:42:17] Slacker [18:42:26] but twice Mission C for that [18:42:33] kind of [18:43:08] C was also lm in leo right? [18:43:27] no, C is just Apollo 7 [18:43:35] CSM only low Earth orbit mission [18:44:01] Oh thats right the crews swapped [18:44:11] 8/9 [18:44:15] yeah [18:44:22] the Borman crew trained for Mission E [18:44:26] Yeah [18:44:56] And McDivitts for D anyway [18:45:15] yep. If Apollo 8 or 9 didn't matter that much [18:45:23] that's just the order [18:46:19] they did it differently with the early Shuttle missions [18:46:36] they had fixed designations [18:46:59] Yeah those numbers are all over [18:47:16] so STS-51-L, the 5 technically stands for 1985, was launched in 1986, after 3 missions that already had a 6 [19:52:19] indy91, yeah that does look very neat with each mission having its own MCC file [19:52:49] already did that for the RTCC calculations for each mission, but the MCC was also getting a bit crowded [19:55:37] ah right thats what im looking that, the separate RTCC calculations [19:55:41] yeah [19:55:54] but the MCC sequence for each mission is also getting a lot [19:56:19] so that's why I moved it [19:56:37] the RTCC file was really getting gigantic before I moved those mission specific calculations out of there [19:56:45] I bet [20:26:30] good night! [21:57:07] Okay I fixed the sign bits. They display correctly again. [21:57:50] For some reason V/N flash doesn't work. I'm getting the updates to ch163 but I'm not seeing any changes. [21:58:47] .tell rcflyinghokie I haven't quite yet figured it out. I think I loaded it properly but it's not playing yet. I'll keep looking. [22:16:32] Thymo, I think I figured out the reason the sounds are not playing. Its because they are in stereo whereas in Orbiter it only seems to play if the .wav is mono [22:18:43] Really? That sounds like it could be an issue. I'll have to try that. [11:01:25] hey [11:03:03] Morning [11:03:22] I am making those sound files smaller [11:03:37] Apparently they did not save with the lower sample rate [11:04:19] and have to be made mono, I guess, as Alex said [11:07:13] Yep [11:07:15] All done [11:18:49] Lets see if my messy code works then try to clean it up [11:27:05] good morning [11:27:17] Morning [11:30:00] hey [11:51:11] Well i guess I need to ask Alex how he got these to play! [12:00:32] oh one thing I wanted to ask, my CSM/LM DP has risen to 1psi [12:00:55] from the time of LM familiarization (56h GET) to shortly before LOI (70h GET) [12:00:58] is that normal? [12:01:02] what could cause that? [12:01:16] pressure in the CSM isn't any higher than before [12:02:01] I suspect it's not a leak... [12:03:29] Temperature change perhaps [12:03:59] Or did you leave your suits in flow [12:04:36] Also you pressurized your CM a little before opening the hatch, right? [12:06:01] suits are in disconnect [12:07:11] even 1.3psi now [12:07:22] Hm I have a throey [12:07:25] theory [12:07:51] Pressure increases in the LM/tunnel from temp increase could have triggered the relief valves [12:08:04] letting out a little gas, and of course not replacing it [12:08:18] which relief valves? [12:08:21] in the LM hatches? [12:10:49] Yes [12:11:27] During accel it the pressure can creep up high enough to trigger the fwd relief valve [12:11:49] yeah [12:11:50] possible [12:11:51] I have watched it happen in lm only operations with 30x [12:12:12] I've only used 10x since I was in the LM [12:12:20] and I used 50x earlier and it didn't happen much [12:12:38] so I still kind of suspect it's how I left the LM [12:12:46] but I'm not sure [12:12:55] I would still bet on the instability [12:13:14] LM ecs isnt fired up for that check, is it? [12:13:17] I cannot remember [12:13:24] it is partially [12:13:27] fans? [12:13:30] glycol? [12:13:39] yeah, now I remember, from the first LM pressurization to LM familiarization much later there was barely a pressure change [12:13:41] checking [12:14:38] glycol pump and suit fan switches are on, but surely the CBs aren't [12:17:09] looks like I left the LM as I entered it [12:19:22] I just never had it develop such a high DP [12:22:56] I dont think I have either [12:23:12] Did you put the LM ovhd hatch vlv back in open when you left? [12:26:16] yes [12:26:32] so it's not just the tunnel [12:29:35] The pressure relief is the only thing I can think of with instability [12:36:37] I'll just press on [12:38:48] press on about 1.3psi [12:40:51] yeah [12:43:27] PR with the downmixed sounds is up [12:43:36] And I will table this and press on with 9 [12:45:48] so they work? [12:46:06] or no luck with the audio yet [12:47:17] Well the files should play, but I cannot seem to get them to [12:47:32] I need to see how Alex got them to [12:49:08] ok [12:49:25] this is also something for Alex: https://www.orbiter-forum.com/showthread.php?t=39770 [12:52:42] who needs a PAD burn attitude. The LOI-1 attitude is so close to the flight plan, that the sextant star check works with the IMU angles from the flight plan, haha [12:53:20] and TEI-1 and 4 seem to run into the return inclination constraint of 40° [12:53:37] so they get calculated with 40° ascending nodes, gives a nice DV [12:57:46] Nice! [12:58:57] Ok MCC questions: do you have times handy for the 99:55 ish LM MCC update, the CM jettison attitude update, and block data 11? [12:59:13] Also did you mess with the AOT angle times by chance? [12:59:22] Because 3 minutes seems to work well [13:03:03] ah right, that was already commited with the 3 minutes [13:04:29] LM burn to depletion update: cm->MissionTime > 99.0*3600.0 + 55.0*60.0 [13:04:50] LM jettison attitude update, 3 minutes later [13:05:09] Block Data 11, cm->MissionTime > 100.0*3600.0 + 35.0*60.0 [13:22:06] Thanks [13:56:25] I really hate how the framerate behaves on the CSM main panel [13:56:31] more often than not I get 60fps [13:56:38] but sometimes it is down to about 48 fps [13:56:49] and then randomly it can jump to 60 again [13:56:58] I wonder what causes that [13:57:26] in any case, once we are in Beta with 8.0, performance issues is one of the many topics we should look into [13:59:17] Hmm I have not noticed [14:00:01] I have set panel scrolling to a faster speed [14:00:08] with that you can easily notice the difference [14:01:34] I use 75 [14:03:22] I use 50, so you use even more, haha [14:06:11] I dont notice it though [14:06:12] I have a decent CPU I think, but Orbiter is definitely capping out one of the CPUs when the frame rate drops [14:08:34] But I think I would need the framerate indicator to truly know [14:09:32] I'm sure you would notice it, if it also would happen for you [14:09:38] you can easily see it when scrolling [14:13:08] Oh the slight jitter? [14:14:23] yes [14:15:20] I never thought about it, I have always used a fast scroll speed I thought it was normal :P [14:18:00] that's the thing, I could deal with it if it was always the same [14:18:14] but sometimes it's good, sometimes not [14:18:29] doesn't matter if I have something else using CPU in the background or not [14:19:51] well I almost made it to LOI-1, now the LOS/AOS time update, the last update before LOI, causes issues, haha [14:19:53] so close [14:22:34] Of course haha [14:32:59] hmm, seems like for the hyerbolic case (pre LOI), the equations aren't reliable [14:34:40] So why were they there? [14:34:55] they seemed to work fine for the Apollo 10 map update [14:35:19] Hmm I get an error with this uplink [14:35:28] unknown system address 7 [14:35:37] wait, what? [14:35:42] what is showing that? [14:35:48] A debug line [14:36:05] If I repeat uplink it works [14:36:11] want a sc? [14:36:13] scn [14:36:35] I think it could be a save issue [14:36:36] hey [14:36:46] Since I saved it after MCC says ready but before I uplinked? [14:36:57] Morning Alex, I have some sound questions for you in a bit [14:37:28] hey Alex [14:37:38] possible, but it saves the uplink in the scenario [14:37:51] scenario would be useful, yeah [14:38:07] https://www.dropbox.com/s/fdhmi1p1yvqw646/Apollo%209%20MCC%20-%20Docking%200002%200001%200001.scn?dl=0 [14:38:58] MCC_upString V71E21E1501E77776E2E33034E77471E50525E43E1702E20266E207E2020E11153E12204E5123E4223E15731EV33E [14:38:58] MCC_upDescr LM state vector [14:39:04] seems to be completely there [14:39:07] maybe a loading issue [14:39:49] Again i can repeat uplink in the MCC menu and it works [14:40:04] But when i try it from there, I get that debug line error [14:40:09] repeat uplink recalculates the uplink and uplink string [14:41:12] I get the same error [14:41:35] should hopefully not be too difficult to find the cause [14:42:04] sprintf(oapiDebugString(), "LM-UPLINK: UNKNOWN SYSTEM-ADDRESS %o", sa); [14:43:05] aha! [14:43:28] when it loads the uplink string by default, it converts it into the proper machine code uplink format [14:43:35] and that is hardcoded to the CMC format right now [14:43:43] Ah [14:43:51] so it does what it should do, reject an uplink with a CSM ID [14:43:52] Well no wonder [14:44:03] Easy fix [14:44:16] Or seemingly [14:44:51] worst case is I need to add a variable to tell it what uplink type it is [14:45:05] AlexB_88, so my sound files should be good now, mono 16 bit lower sample rate, I still cannot get them to play :/ [14:45:24] I have my messy sound code in my LMECS branch if you want to have a look [14:45:37] Thymo, this call for help extends to you as well :P [14:47:01] were you able to load the mono sounds? [14:47:29] ah you said it lol, no [14:47:36] Well I think the problem is they arent playing at all [14:47:47] I didnt try using it in place of a working sound like you did yet [14:47:55] well I tested your sounds on my end and they do play in mono [14:48:20] Mind trying the recent ones I pr'd? [14:48:31] sure [14:53:20] rcflyinghokie, yes your sounds are loading [14:53:49] so I think its a code issue then [14:54:02] Ok [14:54:14] I figured since the debug line I had in there says its not playing [14:54:21] I will look at that more later [14:54:26] At least the files work [14:55:01] indy91, the APS burn pad for the lm, the N86 DVZ seems off [14:55:18] The P30 DVZ is -429.1 [14:55:29] But the N86 DVZ is +15868 [14:55:37] +1586.8 [14:55:52] that's about right [14:56:00] P30 compensates for burn time [14:56:03] AGS doesn't [14:56:11] and it's a mighty long burn [14:56:38] Oh ok [14:56:43] and the -429.1 is not 0, because the AGC doesn't compensate for it perfectly [14:57:14] so yeah, for those long burns, there will be a DVZ difference [14:57:24] unless most of the burn is in DVY direction [14:57:34] like the docked DPS burn [14:59:52] I have to add a variable for that uplink issue [15:00:03] should be fixed for all future cases like this [15:00:51] Great [15:10:10] indy91, how's 11 progressing? [15:11:43] I'm shortly before LOI [15:11:59] but now I am getting an issue with the LOS/AOS time calculation [15:13:22] I'll be back later [15:27:06] think Ill fire up another mission now [15:27:17] either 9 or 10 [15:27:44] rcflyinghokie, which of those 2 are most complete, checklist-wise? [15:28:10] 10 probably [15:28:20] Though I have to make some ECS changes to it that are minot [15:28:23] minor [15:28:24] But [15:28:31] 9 up to LM Jett is complete [15:28:44] *more complete if that makes sense haha [15:29:00] And plus you can test Nik's new targeting for the SPS maneuvers [15:29:01] right [15:29:07] yeah [15:29:27] think ill do 9 then [15:29:40] Go for it [15:46:03] I am trying to figure out the procedure for opening the interconnects before LM jet [15:46:20] Would it just be opening the asc feed valves? [15:50:41] yeah [15:50:52] and closing the main SOVs too I think [15:55:02] Ah ok [15:55:21] Basically the same procedure as during a burn [16:04:36] yeah, all the early Apollo 9 burns have changed targeting [16:05:09] changed after both Ryan and I flew that part [16:13:07] indy91 where did you get the 9 jettison attitude? [16:14:08] I believe that's the burn attitude for the LM [16:14:19] it gets calculated from the DV of that burn [16:14:27] and then converted to CSM IMU angles [16:16:21] I am just trying to make sense of the maneuvering just after [16:16:27] there are FDAI angles in the FP [16:16:50] And then the sep maneuver att is 45 out fo plane and -60 pitch form lm att [16:17:01] Just trying to figuire out what it wants and when haha [16:17:07] the LM burn is targeted 45° out of plane also [16:17:37] ah [16:17:44] I think the FDAI angles are for post jettison [16:17:46] to view the LM [16:17:54] and for the CSM maneuver [16:17:56] Thats what i was thinking [16:18:26] maybe those FDAI angles should be updated in real time [16:18:44] but they should be ok [16:18:53] Let me maneuver to them and see what it looks like [16:20:15] I don't think I've added auto uplinks for the burn to depletion [16:20:31] timing is a bit tricky [16:20:50] and it's missing a subsystem for those burns still [16:20:55] that only flew on 9 and 10 [16:21:19] Also, based on the roll in the FP, is it possible the roll is wrong by 180 for the jettison attitude? [16:23:17] possible [16:23:33] Jettison attitude from MCC is 312.4 328.6 44.1 [16:23:53] FDAI from FP post jet is 132.9 105.8 23.5 [16:24:23] how can 23.5° yaw even be 45° out of plane [16:24:29] if the REFSMMAT is LVLH [16:25:20] Probably just to view the LM? [16:25:23] I dont know [16:25:32] oh [16:25:34] maybe it's [16:25:39] LM jettison at specified attitude [16:25:48] then 45° out of plane and 60° pitch [16:25:59] 2 ft/s maneuver with 4-X Jets [16:26:11] and THEN maneuver to the specified FDAI angles [16:26:13] to view the LM [16:26:25] Possible [16:26:36] Since the evasive is 8 minutes after jettison [16:26:37] we should have documentation on this [16:26:52] Ill be back in a few [16:30:24] indy91, I have a PR waiting btw [16:30:59] does that have to do with this: https://www.orbiter-forum.com/showthread.php?t=39770 [16:31:50] ah, no [16:31:58] I actually did not see that post yet [16:32:11] I meant to show it to you, but I forgot when you joined [16:32:14] my fix is just an adjustment to the CSM panels [16:32:41] but I know exactly the problem he is having [16:32:58] that's good [16:33:47] I have it too with my UHD monitor, windows 10 annoyingly likes to rescale apps at its leisure based on your resolution and its very hard to control it [16:35:25] in my case I have given up using UHD with Orbiter, so I now use a 16:9 monitor (1080p) [16:35:50] nothing we can do? [16:36:59] well I did have a way of getting the proper panel scale back with my UHD [16:37:58] I had to rename my Orbiter directory to another name and then make sure I dont choose "True Full Screen" in Orbiter Video settings [16:38:25] ouch [16:39:25] Because if you choose True Full Screen with UHD, windows rescales the application and seems to mark the applications directory with the new scaling, so its impossible to undo it [16:39:41] not even deleting everything in the directory and re-installing [16:40:38] only way is to re-name the directory, then windows seems to forget it. F*&%*&* windows.... [16:41:34] Ill post a reply [16:42:26] btw there must be a better way to control the scaling but I havent had any luck finding one [17:09:43] back [17:11:54] https://web.archive.org/web/20100524032522/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740072567_1974072567.pdf [17:11:59] maybe that helps with attitudes etc. [17:12:41] I have not read this one before [17:17:26] Jettison at LM inertial burn attitude, maneuver to station keeping attitude, but no clarity on the sep attitude [17:18:14] oh here [17:19:29] IGA 120.452 MGA 28.793 OGA 68.289 [17:20:08] "CSM should be at an attitude of yawed south 135 and pitched down 60 from the velocity vector" [17:21:51] Check out pdf 18 [17:23:34] hmm [17:25:19] So the csm does flip around for the sep? [17:26:12] I'm not sure [17:31:05] It looks right [17:31:22] I just maneuvered to the flight plan values it looks very similar to the diagram [17:31:37] And I can see the LM through the windows [17:32:06] Well kind of haha [17:32:08] sounds promising [17:32:22] any idea what I have to change for the MCC? [17:32:36] I'm a bit too deep in LOS/AOS calculation equations to concentrate fully on both, haha [17:32:36] Actually I don't think anything [17:32:41] I like that [17:33:08] I just need to make sure that is indeed the burn attitude for the LM but otherwise it looks good [17:34:01] The only thing is this sep attitude is not 45 degrees out of plane [17:35:44] And the burn attitude is good for the LM [17:37:12] the burn vector of the LM is pitch 0° and yaw 45° relative to LVLH [17:37:32] but it's a large burn and the LGC compensates by starting the burn more pitched down [17:37:42] so that at the midpoint of the burn it's about at pitch 0° [17:38:09] so the actual ignition attitude is a bunch of degrees below 0° pitch [17:41:26] I think this attitude will work for sep [17:44:04] I believe my problem with these LOS/AOS times is that the Apollo 11 trajectory is too beautiful [17:44:54] I'm not even joking. The pericynthion is exactly at one a line with Moon and Earth [17:45:08] and causes some numerical trouble, lol [17:45:55] well it's still angled by about 0.27° in latitude [17:46:23] but the trajectory is such, that AOS would be at X° true anomaly and LOS would be at minus X° true anomaly [17:46:46] so exact that's is a special geometry case [17:50:37] Oh wow [18:01:14] all thanks to me stubbornly insisting on using an analytic solution as long as possible [18:04:34] And now it breaks down :P [18:05:02] oh and also me stubbornly never using outside libraries for anything [18:06:27] I am detecting a pattern of causation [18:06:37] you are stubborn :P [18:06:47] who would have thought [18:10:04] Remind me, OMI gimbals are which again [18:10:12] CSM [18:10:17] Middle is yaw [18:10:20] outer roll? [18:10:52] yeah, I think so [18:11:00] middle is always the bad one, right? [18:11:02] gimbal lock [18:11:39] Yes [18:11:53] I am trying the angles from that sep doc now [18:11:58] since it is newer than the fp [18:12:22] good guess [18:12:31] I also noticed 2 vs. 3 ft/s [18:12:46] sounds like they used 3 on the actual mission? [18:12:47] Yeah [18:12:50] flight plan has 2 [18:12:59] Let me check the mission report for that [18:18:43] Hmm I cannot find a velocity [18:20:13] the document I linked you has the answer [18:20:26] it says 3 ft/s and it's from a month after the mission [18:20:28] I was looking for the actual used [18:20:30] Oh [18:20:36] Duh [18:20:39] I mean [18:20:42] March > April [18:21:02] I've seen errors in postflight documents :D [18:21:23] I dont know why I was thinking october [18:22:05] October 1968 documents for Apollo 9? Completely unusable, lol [18:22:43] No I was thinking the mission was october [18:22:56] But that was 7 [18:23:06] oh [18:23:19] So I was thinking april was still a pre mission doc [18:23:20] yeah, explains the confusing [18:23:49] So i am using the angles and velocity from this [18:23:58] Its not clear if a P47 was used [18:24:14] Transcipt maybe has the answer [18:25:02] Nope missing a bunch there [18:25:19] I bet they used P47 [18:25:44] I would think so, but this FP has been pretty good at explicitly saying P47 [18:26:41] right [18:36:26] Ok lets try this procedure out [18:36:37] If this works we are good till rest period [18:36:44] And then the easy stuff [18:52:16] Maneuvering to this attitude also keeps the LM in view almost the whole maneuver [18:52:24] So I think there is some logic behind it ;) [18:53:31] yeah, sounds good [18:59:38] So MCC has the APS burn at 103 hours 6 minutes [18:59:44] Its supposed to be 102:0 [18:59:54] I cant believe I just noticed this [19:00:44] Did I miss something? [19:05:28] hmm [19:05:51] I think I got a few things wrong with that calculation [19:06:11] but it's probably finding the solution one rev too late [19:08:14] I'll change the TIG [19:08:27] it's using mid pass of the Texas tracking station right now [19:09:48] but I'll change it to something simpler [19:09:56] Ok [19:10:18] I used 102h GET as the initial guess [19:10:55] but maybe that specific function is always looking into the future [19:11:03] so it's never returning a past time [19:11:54] Actual was 101:53:15 [19:12:20] if you want you can change something quickly in your local copy and recalculate [19:12:34] Sure [19:12:43] file RTCC_Mission_D [19:12:49] part of the MCC project file [19:12:54] line 1163 [19:13:02] there you will have [19:13:03] OrbMech::HHMMSSToSS(102, 0, 0) [19:13:10] change that to half an hour earlier or so [19:13:14] that should do the job [19:13:17] OrbMech::HHMMSSToSS(101, 30, 0) [19:14:13] Lets see what it does [19:15:34] I will use the general purpose maneuver processor for this, it's more reliable than a bunch of manual calculations [19:16:04] flight controller input, total DV as the actual mission, pitch 0°, yaw 45°, TIG at 100°W [19:18:31] 101:48 [19:18:38] perfect [19:18:40] yep [19:18:42] just one rev too late [19:18:56] one of those things I always hope you and other people find, haha [19:19:26] Actual jettison was like 101:21 I believe [19:19:39] I might need to make ours reflect that for time [19:19:50] But I will try first and see [19:20:08] yeah, I believe your and mine mission were off by about 5 minutes from the actual mission [19:20:15] Sounds right [19:20:23] and the actual was further off a few minutes from the flight plan [19:23:57] Actual lm jett was 101:22:45 [19:24:05] Wonder when the sep was [19:25:19] Same time it seems [19:25:44] But I dont know for sure [19:30:33] can you tell me your DV vector? [19:31:54] morning! [19:32:10] For the new calculation [19:32:27] yeah [19:32:31] https://www.dropbox.com/s/5ong6a21t3j56zl/Screenshot%202018-08-10%2015.19.03.png?dl=0 [19:32:32] same as the old one [19:32:34] I'll do you one better [19:32:36] hey Mike [19:33:06] thanks [19:33:11] unknown system address, heh [19:33:21] Yeah haha [19:33:28] I reloaded an older scn to recalculate [19:33:38] So I could just punch a quick P30 into a pre jett scn [19:33:48] just wanted to check if I did my changes right to use the GPM processor for this [19:33:58] mostly 45° vs. -45° [19:34:29] using 100°W as the impulsive TIG point results in 101:49 for me [19:34:52] and that seems a pretty reasonable guess from the mission report ignition and cutoff numbers [19:35:09] Yeah its close [19:35:22] And remember this is still before the burns were fixed [19:35:33] So my orbit probably isnt where theirs was [19:35:49] one more job for the GPM processor. But that's how I like it, no special calculations, but the RTCC files for the missions doing the same input steps as the flight controller would [19:36:31] and the GPM processor always takes an earliest TIG as the input [19:36:46] usually I chose 30 minutes earlier than flight plan for that [19:36:59] you should never be that much off that that results in a rev too late [19:37:42] ok, back to annoying geometry [19:37:59] but I guess there won't be a LOI-1 for me today :( [19:41:20] One more thing witht he aps [19:41:29] it will recalculate the csm jett attitude as well right [19:41:40] yeah [19:41:46] Ok [19:41:56] inertial attitudes will be different [19:42:55] Ok lets burn this APS [19:43:09] opening the interconnects, thats the feeds and sov's? [19:43:34] Open feeds/close sovs [19:43:44] interconnects are the valves between APS and RCS propellant [19:43:59] I know what they are haha [19:44:00] so "ascent feed" on the panel labels [19:44:04] I mean the procedures [19:44:21] well the SOVs aren't the interconnects [19:44:34] I don't know if the procedure is to have the SOVs also open [19:44:42] Theres a step to open the interconnects [19:45:00] but I would think they want to give the LM as long a time under attitude control as possible [19:45:04] so open all the things [19:45:07] But the only procedure I find is the one during a burn where the feeds are open then the sovs closed [19:45:22] And then the reverse before shutdown [19:45:30] that's mostly to not use up the RCS prop [19:45:43] during flight phases that can use a lot of RCS [19:45:55] Like a long +x translation [19:46:13] Or lunar ascent [19:46:17] as it empties [19:46:39] So I guess the underlying question, do I need to close the SOV's for aps burn to depletion [19:46:42] yeah, the APS can't be gimballed so in the real LM with changing CoG etc it would use up more RCS than it does for us [19:46:57] I don't think so [19:47:02] leave them open [19:47:04] Ok [19:47:16] then it will have attitude control as long as possible [19:49:44] And LM is burning [19:50:04] bye Spider [19:54:22] won't decay from orbit until October 23, 1981 [19:55:54] ECO [19:56:05] +54965 [19:56:45] pamfd has me at 3975.3x127.3 [19:57:17] yeah, I had something similar, I think [19:57:48] had about 1:30 left burn time [19:58:58] yeah, they targeted for plenty for extra burn time [19:59:13] on my Apollo 10 mission the LM masses didn't work properly [19:59:31] so the burn to "depletion" didn't quite deplete the APS propellant [20:01:47] That reminds me I need to check these empties on 9 anyways [20:12:25] Can you link me a consumables analysis for 9 and 10 by chance [20:12:51] I sure can [20:14:01] Apollo 9 [20:14:02] https://web.archive.org/web/20100524053543/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740072933_1974072933.pdf [20:14:56] Apollo 10 [20:14:58] https://web.archive.org/web/20100524012714/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740072794_1974072794.pdf [20:16:03] Hmm no empty masses for 9 [20:16:08] I need to hunt down those [20:17:20] I think my numbers have included RCS in 9 and 10 as well [20:23:26] 9 did [20:23:43] I assume 10 did as well based on the mass [20:33:53] Hmmm looks like the CM was 12300 inert for Apollo 10 [20:37:36] But that seems like CM plus propellant when compared to the other CM's [20:38:55] so what you are saying is [20:39:00] the Apollo 10 crew was fat [20:39:19] Haha [20:39:25] Just seems odd [20:39:51] That the Apollo 10 "inert" CM is aboutt he same mass as 9 and 11 CM plus propellant [20:40:12] seems weird [20:40:51] Yeah [20:42:02] 9 and 11 are now only like 40lbs different [20:47:57] 10 is still like 12300 [20:48:04] in two different tables in 2 different docs [20:48:10] But I dont know if that includes crew [20:48:24] I wouldnt think so that would be >300lbs [20:52:35] idk maybe 10 was heavier [20:54:53] Small little addition is adding an extra 98 lbs to every SM for the SLA ring [20:56:05] 9 10 and 11 all had them [20:56:12] I assume 7 and 8 did as well [20:56:50] But I dont know for sure, 9 10 and 11 its listed in the mass properties [20:56:57] And stays with the SM [20:57:06] I think [20:57:22] Yeah its used to compute SPS burn masses [21:01:01] I will look into 10 more detailed later, but I fixed 9's masses [21:03:26] great [21:03:29] good night! [21:03:33] Later [13:07:31] morning [13:19:20] Good morning [13:31:30] And the duplication of me has begun it seems haha [13:33:42] good morning [13:35:51] Morning [13:36:46] getting better at ils landings and also im excited about Niklas's apollo 11 mcc's [13:45:31] Are you flying them CAT III or hand flying? [13:46:21] not sure but on the approach chart it says vor/loc [13:46:40] Thats not an ILS approach [13:47:03] Thats what is called a non precision approach because you have only lateral guidance [13:47:21] Your vertical guidance will be governed by step downs at fixes down to an MDA [13:47:44] but i might fly san fran to la and its a cat iii approach [13:47:54] And once you hit MDA, at the MAP you go around if you have no field in sight [13:48:30] Are you using just the FMC or are you also using the approach plates? [13:48:44] fmc [13:48:55] Which approach are you doing next do you think? [13:49:39] LAX ils 15L [13:49:56] it says cat ii and cat iii [13:50:28] You mean 25L? [13:50:44] ah yes [13:50:55] https://www.fltplan.com/AwDisplayAppChart.exe?CRN10=1&CARRYUNAME=PILOT&DEPTARPT=KLAX&ARRARPT=XPTG&TYPECHART=00237I25LC2_3.PDF&END=END&WINDOW=YES [13:51:18] yes thats the one [13:51:29] Btw this site has all the instrument procedures [13:51:35] https://www.fltplan.com/AwMainToApproachPlates.exe?CRN10=1&CARRYUNAME=PILOT&MODE=SEARCH&end=end [13:51:49] US and Canada though, I have other sites for international procedures [13:51:59] But learning these plates will help a lot [13:53:01] And they will help when choosing the IAF for an approach [14:31:43] rcflyinghokie1, one minor thing with the Apollo 9 checklist so far. After insertion the checklist has you pull the PYRO SEQ A/B cbs on panel 250. This of course means that when you do the EPS checks afterwards, the DC indicators are cycled through the PYRO bats and the check says it should read 37 or so volts but of course with the 2 previous cbs pulled, it indicates 0 [14:32:20] Let me have a look [14:33:27] Hmm those might be the wrong cb's :X [14:35:38] I need to find where I got that [14:36:29] Nope its from the Apollo 8 insertion checklist [14:37:05] Those are opened before the EPS check [14:39:02] I wonder then if the DC indicators should display voltage for the pyro bats, independent of the cbs being pulled then [14:39:19] Its possible [14:44:53] Oh I think the EPS checks were done before those pyros were pulled [14:45:05] The insertion checklist is just written funny [14:45:37] Or maybe those pyros werent pulled on 9? [14:45:39] I dont know haha [14:45:47] This is the 8 insertion list I am using [14:56:37] Looking at the schematics, the pyro bus that the voltage is sensed on is powered by the cb [14:56:41] So that is right [14:56:45] May just be an order thing [14:56:53] Or 9 didnt pull the pyros like 8 [14:57:06] Good catch I will investigate further [14:58:49] another thing I think is missing, the PYRO ARM switches are not turned off in the insertion check [14:59:01] or maybe thats intentional too [14:59:52] for the PYROs all that was turned off after my insertion was the logic switches and the SEQ A/B cbs [15:02:35] Yeah thats all from apollo 8 [15:06:32] I need more launch/insertion checklists [15:09:55] yeah haha [15:15:03] another thing is the docking gimbal angles in V49 seem to be slightly unaligned in pitch with the SIVB, maybe 5 degrees or so [15:28:26] and hard dock! [15:31:02] Yeah they are close but not perfect [15:31:12] I believe the actual mission was the same [15:33:31] makes sense [15:36:14] oh does SIVB restart work? [15:45:26] I believe so [15:51:12] great [15:55:06] The V49 angles for docking were in the checklist right? [15:55:44] Yeah they came from the flight plan [15:55:45] yes [15:55:51] I cant see that anything different was read up [15:56:02] Niklas and I discusses this as well [15:56:39] We think that the NASSP attitude calculation is slightly off from the actual, but since the angles are close enough they can still be used [15:56:50] I remember the pitch being off as well [15:56:58] But its close enough for a CMP to dock ;) [16:04:23] But yeah i need to look into that pyro logic thing, maybe Nik knows something I dont [16:17:41] oh and I think SPS-1 uplink only had CSM state vectors, so that will need a V66 after it in the checklist [17:27:41] good evening [17:28:10] Hey [17:28:38] AlexB_88 I knew I missed one :P [17:29:45] Wait, did that get a SV? [17:29:57] That was just a pad and target load I believe [17:30:02] hey Niklas [17:30:05] hey [17:30:15] rcflyinghokie1, yes it got a CSM SV [17:30:31] I dont see one in the flight plan there [17:31:03] hmm [17:31:10] I have one by itself at 3:15, is that what you mean? [17:31:20] nope, I have a SV update at that time [17:31:23] I'll remove it [17:31:29] Ah ok [17:31:57] hmm [17:31:57] Btw indy91, the APS burn maneuver sequence works well [17:32:04] great [17:32:13] The computed angles work nicely with the fdai angles from that sep doc [17:32:37] Alex stumbled upon something interesting, a carryover from Apollo 8 insertion [17:32:40] yeah, right now there is the separate SV update at 3:15 but also one with the SPS-1 update, which is wrong [17:32:49] They opened the seq a and b pyro breakers on 250 [17:33:03] And then closed them later [17:33:15] Question in, was the EPS check done before or after this [17:33:20] If after, pyro bats would read 0 [17:33:41] depends on what the gauge is reading [17:35:33] Systems Handbook says it would read 0 if those breakers are out [17:36:00] Yes this is correct [17:36:14] I've only seen those breakers being opened in the Apollo 8 checklist I believe [17:36:16] Question is, on 8, was the EPS check done first [17:36:27] And second question, were those opened on later missions [17:36:43] If not, I have some insertions to fix [17:38:30] I don't think so [17:38:39] the next best one we have is Apollo 12 I believe [17:38:56] Apollo 8 TLI checklist has an EPS check done by the LMP [17:39:07] LMP Checklist refers to the Systems Checklist part of the LMP checklist [17:39:12] and there is a handwritten note! [17:39:18] If Pyro Bat ck desired: [17:39:23] close those breakers, basically [17:39:33] that's the LMP checklist PDF page 7 [17:40:41] Ah hah [17:41:15] I guess it can stay there then on 8 [17:41:57] oh, I am orange [17:42:09] on the Orbiter Forum [17:42:16] I saw that [17:42:39] How did you manage that :P [17:42:44] good question [17:42:58] about a year ago I applied to join the "Addon Developer" group of users [17:43:13] but I am not sure that did anything [17:45:26] [15:36:14] oh does SIVB restart work? [17:45:27] Well something clicked haha [17:45:37] AlexB_88, yes it works [17:45:48] two commands to the IU done automatically on Apollo 9 [17:45:57] Oh indy91 do you want me to add that change for the aps burn calculation to my PR? [17:46:02] allowing the attitude maneuver back to 0,0,0 LVLH [17:46:05] and then restart enable [17:46:19] in the RTCC file? [17:47:13] I already did that [17:47:14] https://github.com/dseagrav/NASSP/commit/1f11f7c5df91f00ddeebd1c97942706ea6858215 [17:47:33] Ah ok I havent checked today [17:47:58] managed to do LOI earlier and then I had to go away, so I pushed my latest state [17:48:34] was a good LOI-1 [17:48:39] or as a certain astronaut would say [17:48:44] 075:56:29 Collins (onboard): I take back any bad things I ever said about MIT - which I never have. [17:49:27] indy91, yep it was quite the show! [17:49:42] that restart had been on my bucket list for a while [17:49:59] That SIVB was there, there, there and....gone! [17:50:06] and when the LVDC was finally running in the separate S-IVB it was one of the first things I implemented [17:50:33] the second restart is not supported yet [17:51:06] but with the flight sequence program files I might be able to add the two additional timebases needed for that [17:51:23] so was the SIVB sent into solar orbit I guess? [17:51:30] yes [17:51:43] but just barely, because that burn did not work right on the actual mission [17:52:39] the first restart only sends it into a higher orbit, but not nearly solar yet [17:52:59] oh and something minor, but the P30 maneuver PADs by MCC dont seem to following the same format as the P30 forms in the Apollo 9 flight plan [17:53:15] I think I've reused the Apollo 7 format [17:53:22] ah, right [17:53:30] too lazy to implement a whole new thing for Apollo 9 [17:53:38] I mean it has everything, just not in the same order [17:53:42] right [17:53:46] which is not a big issue imho [17:54:03] I would say just the DVR was missing actually [17:54:30] I'll look at it, maybe I can use the same Maneuver PAD calculation for both and just display it slightly different for 7 and 9 [17:54:49] I've just done that for the first time, with the map update PAD [17:55:04] oh and SPS-1 did not include the nav check section, I guess not every burn included that? [17:55:11] hmm [17:55:58] I've skipped that for SPS-1 [17:56:05] they didn't get that on the actual mission [17:56:09] ah ok [17:56:40] I might have missed that for other burns where they did get a check, not sure [17:56:52] I need to add the P21 for those [17:57:03] I believe they didn't get one here, because they got a separate SV update plus nav check earlier on [17:57:11] yes [17:57:19] more often than not they are getting a SV uplink with target load and Maneuver PAD [17:57:19] Do you have a list of nav check times you used [17:57:29] or rather then a nav check pops up [17:57:31] when* [17:57:58] I can give you the burns where I used it [17:57:59] anyway im off for a bike ride, ill be back a little later [17:58:02] cya [17:58:11] which, as I said, might be incomplete or wrong [17:58:21] Yeah that would be fine for now [17:58:22] I forgot to check for each burn [17:58:31] I totally forgot to add the P21's in the checklist [17:58:33] SPS-2 to 4 [17:58:40] With each SV? [17:58:43] it's a crew option to do that anyway [17:58:55] SPS-2 to 4 have a nav check on the Maneuver PAD [17:58:58] Figure I can placehold it with no harm [17:59:05] SPS-6 as well [17:59:14] and 7 and 8 [17:59:22] not sure if I forgot it for SPS-5 [17:59:25] might have [18:00:19] Were any V66 uplinked? [18:00:54] SPS 2 [18:00:58] 3 [18:01:02] 4 [18:01:10] Thats all I have so far [18:03:31] they did get a nav check on the Maneuver PAD for SPS-5 [18:03:33] so I am adding that [18:04:49] for most burns a V66 is uplinked [18:05:04] seems to be crew preference [18:05:19] on 11 there are almost exclusively CSM state vector only uplinks [18:06:20] Just need to know which ones so I can remove the crew V66 [18:07:15] all of the SV updates with target load have a V66 [18:07:19] Ok [18:07:48] I believe all of the updates that are only SV updates have a nav check PAD and no V66 [18:07:59] Ok [18:08:04] V66 kind of defeats the purpose of doing a nav check [18:08:23] Haha true [18:08:28] just for burns the extra checks make sense [18:08:37] same thing as a sextant star check really [18:08:43] It was done using the LM SV right [18:08:45] just confidence in the PGNS [18:08:54] nav check? [18:09:02] Yeah [18:09:09] LM slot* [18:09:15] no, that's with the CSM one [18:09:34] CSM state vector uplink, check with P21 if the uplink was any good. If yes, V66 [18:09:41] if not recover "good" SV with V47 [18:09:42] Oh if the uplink was good I am with you [18:10:12] took me a long while to notice that the LGC doesn't have that capability [18:10:19] CSM to LM slot transfer [18:10:28] Yeah [18:10:48] I mean, it's quite useful to have when doing P22s and P23s [18:10:50] So for the target loads, they are uplinked with a V66 [18:10:55] But they also have nav checks? [18:11:21] except for SPS-1, all SPS burns have the uplinks: CSM state vector, V66 and target load [18:11:35] and a nav check on the Maneuver PAD [18:11:44] which was not necessarily done each time [18:12:48] all those mass updates... [18:12:52] in the PR [18:13:00] who is going to fix the padloads? :D [18:14:09] Haha sorry! [18:14:41] I'm sure whoever was responsible for this back in the day was thinking the same thing [18:14:58] those masses in the padload probably were changed the most [18:15:10] Well the mass spreadsheet has the updated total masses if it helps [18:15:43] sure. I'll wait a bit if any further updates are coming and then I'll update them all in one go [18:15:50] plus padload spreadsheets [18:16:27] it's really just that it's desirable to have the right LM mass in the CMC from launch on [18:16:27] Yeah I might have ones for 10 if I can figure out if that inert mass was indeed empty [18:16:38] CSM mass gets updated anyway on Maneuver PADs each time [18:16:40] All of those LM masses should be solid [18:16:50] I just double checked them all [18:17:11] 9 was the only one with incorrect LM masses [18:17:47] I used a simulation doc and not the actual loaded when i first calculated them [18:19:03] tricky to find the right numbers [18:19:27] KSC people probably knew more about the actual masses than anyone else. They really had to know how heavy their rocket was [18:20:07] and in real time they had some people keeping track of masses for maneuver calculations [18:20:19] in mission control that is [18:23:32] Its nice to finally be on day 6 :) [18:24:32] what's the schedule? [18:24:49] For day 6? [18:24:56] yeah [18:25:06] SPS6 [18:25:12] S065 [18:25:23] landmark tracking? [18:25:49] It was an experiment [18:26:07] Photography of a site? [18:26:09] oh I know, but I mean, no landmark tracking? I guess that's on day 7 [18:26:17] Yeah no landmark tracking [18:26:18] was too lazy to check [18:26:36] the S065 photography involved 4 camers with different filters [18:26:56] they had a device to attach those 4 cameras [18:27:06] one of the rendezvous windows [18:27:09] Ah [18:27:32] and you'll be using the pitch orbit rate procedures for that [18:28:16] scratch any ORDEAL stuff on day 6, your REFSMMAT doesn't support it [18:28:38] How so [18:28:42] retrograde [18:28:54] your ORDEAL would be rotating the FDAI in the wrong direction [18:29:07] Oh thats right [18:29:15] I remember you saying that [18:29:16] a fact they learned in real time [18:29:36] So I should just remove the ordeal stuff? [18:29:37] what they also learned was that they have to rotate the CSM in the other direction with the pitch orbit rate procedure [18:29:51] yeah, that would just be confusing [18:29:54] Sure [18:30:08] for the S065 photography you'll get the right attitude to start the pitch rate [18:30:10] and time [18:31:14] Fixed [18:31:59] the few pages of the CMP Checklist we have have the first part of the pitch orbit rate maneuver [18:32:13] when you get to it, I have the full manual EMEM changes written down [18:32:28] but I guess we mostly found it in the AOH as well [18:33:36] Right I remember that [18:40:09] Ok SPS 6 time [18:44:13] I think I need to go in and change some DAP loads for the proper ullage [18:45:39] Thats BC in R1 in N46 right? [18:48:30] yes [18:48:40] B is quads A/C, C is quads B/D [18:48:51] 0 is fail, 1 is use [18:48:57] I think I might just add that to the P40 as a text reminder [18:49:00] so a two jet ullage would set 0 to one of them [18:49:07] similar to the option to choose csm or csm/lm [18:49:29] have you been doing the ullage lately? [18:49:34] Yes [18:49:38] I'm not sure I ever did them, haha [18:50:04] Its kind of fun to watch the CMC use it and then cut off the +X jets when the SPS fires [18:50:09] one interesting note, for the short burn logic in the CMC, it actually detects if you are doing an ullage burn and subtracts the estimated DV of that [18:50:27] because for short burns (less than 6 seconds) it has a fixed burn time before ignition [18:51:51] so it adjust the burn time based on some calculations how much DV the ullage does [18:51:57] I remember reading that [18:52:01] and for that it is good to change the DAP load [18:52:17] and not just disabling two Auto RCS jets or so, haha [18:52:38] it checks if the DAP is set to 2 or 4 jets for +X [18:53:04] I guess that mostly becomes relevant for very light CSMs [18:53:29] where the ullage DV is quite a bit [18:56:12] Yeah like SPS6 perhaps [18:56:24] 18 seconds [18:56:32] but 2 jets [18:57:39] morning! [18:57:51] if they gave the CMC all the smarts to calculate the ullage DV, they might as well have made it automatic... [18:57:52] hey Mike [18:59:09] Yeah, afterall the LM does it ;) [18:59:36] So I will add to the P40's: [18:59:39] B = Quad A/C C = Quad B/D [18:59:42] BC = 11 for 4-jet ullage, B or C = 0 for 2-jet ullage [19:00:01] And throw the FP ullage before the P40 checklist [19:00:21] and I guess I'll go back and add the ullage type and time on the Maneuver PADs as a remark [19:00:26] Ullage was not read up with a maneuver pad was it? [19:00:32] it was [19:00:33] Oh never mind [19:00:35] Even better [19:00:47] Then i will just leave it at that [19:01:57] I've never added it before, but I will in the future [19:03:00] Hm sps 7, says 2/15 [19:03:04] all the rest are 18 sec [19:03:10] could that be a typo? [19:03:18] Or because of the lighter sps [19:04:16] lighter CSM usually means longer ullage [19:04:31] G&C Checklist has charts for it [19:04:50] max ullage time is 18 seconds in the Apollo 15 checklist [19:04:54] 2 jets, very light CSM [19:05:10] correction, 19 seconds [19:05:19] and 13 max for 4 jets [19:06:04] that's both for CSM alone [19:06:30] 9 FP ullage times are: SPS# 4: 4/18 5: 4/18 6: 2/18 7: 2/15 [19:06:31] light CSM plus heavy LM is up to 30 seconds, wow [19:06:49] yeah, 4/18 is consistent because there still is a LM [19:07:17] but that 15 seconds is weird [19:07:18] 10 only has 2/17 on LOI2 and 2/14 on TEI [19:07:20] Yeah [19:07:28] I was making sure i didnt read it wrong [19:07:33] Its a typed 5 not 8 [19:07:39] maybe they were looking at propellant tank data and determined they don't need a long one [19:07:57] but no idea really [19:08:21] Interesting on the burn table for 9 [19:08:29] 2 jet 10 second for docked dps? [19:09:35] I dont remember checking that [19:09:42] Was that a LM DAP load thing? [19:09:50] Or was that manually ullaged [19:11:00] luckily we have the Sundance DAP study guide, lol [19:12:13] but it's the same as in Luminary [19:12:24] you have only choose 2 jets system A, 2 jets system B or 4 jets [19:12:43] DAP was different in Sundance [19:14:44] some things, yeah [19:14:52] like, it had no option to disable the DAP [19:14:54] And I am more concerned with the ullage time, did using the docked dap load increase the time to 10 seconds? [19:15:03] so A in R1 was 0 for LM only, 1 for CSM/LM docked [19:15:06] not 1 and 2 for those [19:15:17] I doubt it [19:15:19] but I'll check [19:15:25] So I guess they manually did it? [19:16:51] ullage is fixed at 3.5 seconds for APS burns, 7.5 seconds for DPS burns [19:16:57] even in Sundance [19:17:10] So I guess they applied an extra +x? [19:17:18] no other way really [19:18:29] maybe the transcript has something [19:20:37] Not really [19:20:48] They call ullage on at about t-7 [19:21:02] Oh never mind its 10 [19:21:15] So maybe saying ullage on means they are doing it [19:21:53] Yeah "begin ullage at 10" [19:22:03] So probably manual [19:24:30] can easily be done [19:25:43] the LGC has a fixed ullage time it compensates the DV for [19:25:52] so it doesn't monitor the TTCA input bit [19:26:23] so you could do the additional manual ullage with the trans +X button as well, no difference for the LGC [19:28:39] Think the button or TTCA was used? [19:29:39] probably TTCA [19:29:59] I'm sure it's in the checklist... [19:31:03] hmm, what was your source on the ullage times? [19:31:45] Flight plan [19:32:15] ah, I thought transcript [19:32:22] deorbit is 4 jets and 15 seconds [19:33:01] didn't you say 15 seconds for SPS-7? [19:33:16] it's 18 in the flight plan [19:33:36] Its 15 in the FP [19:33:49] definitely 18 [19:34:02] Oh wait SPS 7 isnt deorbit [19:34:16] deorbit is SPS-8 [19:34:21] Yeah [19:34:24] my fault [19:34:32] 7 is 18 8 is 15 [19:34:41] yeah, but 4 jets for SPS-8 [19:35:16] I'm not sure about the logic between using 2 or 4 jets, but the time checks out I think [19:35:35] at least it's consisted with some charts on what to use [19:35:42] consistent* [19:35:58] True [19:44:41] huh, all the early TEIs and also the nominal TEI on Apollo 11 are running into the 40° return inclination constraint. Makes it easier for us to calculate and we'll get nicer DV as well, because our TEI calculation doesn't do an optimization yet. [19:47:23] And when TEI does optimization? [19:48:02] Oh the sxt star check for SPS 6 doesnt work [19:49:28] all those annoying sextant star checks [19:49:42] I have to look if they are broken on the Apollo 7 style Maneuver PAD [19:50:05] but it might just be too strict about the star availability [19:50:09] I think it would work if I was rolled 180 [19:50:29] yeah, that's why there is a delta time parameter for the calculation [19:50:45] 26 is just about to come above the earth horizon [19:50:45] so that it calculates the check for a time X before TIG [19:50:52] has to be adjusted for each burn I guess [19:50:59] I am about 27 minutes from TIG [19:51:03] more often than not it's 30 minutes before TIG in the flight plan [19:51:36] Right [19:51:38] more like 20 for SPS-6 [19:52:12] I used 15 for some reason [19:52:19] I'll change that, but it might still not be enough [19:53:34] I think it assumes I am heads down as well [19:53:54] SPS 6 is heads up [19:54:09] As are all of the burns on 9 it seems [19:54:24] what assumes you are heads down? [19:54:45] the calculation looks right, it must be too strict about what stars are available [19:54:59] occulted by the Earth and all [19:56:10] Well star 26 is visible if I was heads down [19:56:43] Well, will be visible when it rises [19:56:59] it calculates the sextant star check in the burn attitude [19:57:27] and using a time X minutes before TIG it should find stars that are available [19:57:37] even in the burn attitude [19:58:02] https://www.dropbox.com/s/76zb2r6iz748798/Screenshot%202018-08-11%2015.57.45.png?dl=0 [19:58:09] Star 26 [19:58:19] And as you can see my optics are facing the wrong way [19:59:08] your optics are facing the only way they can in burn attitude [19:59:45] at TIG they often point down, as you said, because most burns are done in heads up [19:59:46] And star 26 is what it wants me to use [20:00:04] oh, now I get it [20:00:12] I thought it didn't give you a sextant star at all [20:00:16] Oh no no [20:00:23] You can see the pad there too [20:00:36] right [20:01:30] that's weird [20:01:41] the calculation should be the same as on the Apollo 11 Maneuver PAD [20:01:59] but I also often got no star on Apollo 9 when there should have been some available [20:06:32] I really don't see a difference to Apollo 11 [20:06:41] and for that Maneuver PAD the calculation definitely works [20:08:48] it didn't even give me a sextant star for SPS-6 [20:08:53] that's why I didn't notice I guess [20:09:07] it rarely gave me any on Apollo 9 [20:09:23] Haha I dont know then [20:09:25] Hey Niklas [20:09:37] gonna start apollo 11 again maybe now [20:10:06] mission control support for Apollo 11 is implemented through LOI-1 right now [20:10:20] and you sure that's the burn attitude, rcflyinghokie? haha [20:10:30] According to P40 it is [20:10:41] I believe it [20:10:56] Looks like i will be heads up retrograde at TIG, also correct [20:15:51] T-2 [20:18:49] I can't even get it to give me any sextant star [20:21:36] SPS 6 complete [20:23:23] ok, now I got one [20:27:16] Now lets try these S065 maneuvers [20:29:16] Hey indy95, have tried a couple fresh Apollo 11 Mcc launch scns, the tb6 prediction from the mcc is about 5 seconds early, can attach scn if needed [20:29:47] dont' make me younger than I am :D [20:30:09] https://www.dropbox.com/s/pmo8gd3qi618i75/Apollo%2011%20MCC%20-%20Launch%200001%200001.scn?dl=0 [20:30:10] 5 seconds early is pretty good [20:30:57] no other problems with the MCC so far? [20:31:10] Ok just making sure I wasn’t screwing something up on my end with time accel or anything [20:32:04] more than 50x time accel is still unsafe with the LVDC++ unfortunately [20:32:14] but 5 seconds difference should be no problem [20:33:14] Not that I’ve noticed only made to td&e with the latest changes, ran into a problem with the mcc-1 burn calc a few days ago had to reset the state I believe but that has probably been fixed [20:33:43] Ya I never do more than 10 in earth orbit 30 during tlc [20:34:02] yeah, Apollo 11 is very much work in progress right now [20:34:10] there might have been changes that could break things [20:34:17] should be all good to LOI-1 now [20:34:37] I'm not even sure the TB6 prediction can be more accurate than +/- 8 seconds [20:34:46] the LVDC only does navigation every 8 seconds, lol [20:34:50] I have a gtx 1060 but my main panel FPS never goes above 42 so I don’t like accel to high [20:35:19] the issue is mostly the CPU [20:35:42] because we have a very outdated 2D panel with lots of bitmap operations going on I believe [20:35:58] so graphics is rarely the bottleneck, only for any fancy Orbiter 2016 settings [20:36:17] with the CSM main panel it's definitely the CPU being the bottleneck [20:36:27] I believe there are a bunch of things we can do about that [20:36:40] I'll look into it after being done with the Apollo 11 MCC [20:37:28] if we were using a 3D panel with all the latest features Orbiter 2016 and the DX9 Client supports, then we would have much better frames [20:38:08] I’m so used to the 2d panel I almost prefer it haha [20:38:28] even with 2D panels we could do something actually [20:38:48] but the huge performance boost would require making the panels from scratch [20:38:52] as 2D meshes [20:39:07] So way down the line [20:39:12] yeah [20:39:25] but a bunch of performance improvements should still be possible [20:39:56] Gotta run to work I’ll be back on later! [20:41:30] Ok waiting for orb rate time [20:43:26] most Apollo 9 SPS burns use the preferred REFSMMAT, right? [20:43:37] I wonder if that has anything to do with the sextant star issue [20:43:39] Yeah [20:53:28] ok, the calculation definitely still works for the Apollo 7 Maneuver PAD type [20:53:42] just tested it in an old scenario [20:54:11] so maybe it is indeed something with the 0/0/0 attitude [20:54:14] or REFSMMAT [20:59:42] Just seems confused haha [21:00:21] I never had it calculate a wrong check before [21:00:32] just none at all, when there should be stars available [21:00:59] I think I have a scn around the time of the screenshot if it helps [21:01:05] yeah, probably helps [21:04:38] One sec let me check [21:06:57] hmm, so if I let it calculate the same burn in the RTCC MFD, it gives me a good one [21:07:08] RTCC MFD uses Apollo 11 style Maneuver PAD calculation [21:07:44] Same burn results? [21:07:50] But a better star [21:08:34] a reasonable star [21:09:04] the one on the MCC suppled PAD is probably as wrong as yours [21:09:12] https://www.dropbox.com/s/bffqssnnkld86ov/Apollo%209%20MCC%20-%20Day%206%200001.scn?dl=0 [21:09:13] maybe it's a heads up/down issue [21:09:19] Thats what I was thinking [21:09:22] although I don't understand yet how that is possible [21:09:26] And here is a scn with the pad calculated [21:09:30] Its a bit before the burn [21:10:20] thanks [21:11:36] back in a bit [21:17:19] ok, I have a lead [21:23:25] figured it out [21:28:19] in all those cases the REFSMMAT gets calculated by the CMC, not RTCC. So the RTCC has to predict what the REFSMMAT is going to be. And I used the wrong heads up/down sign convention for that. But I also used the heads down for the Maneuver PAD calculation, so the displayed attitude ended up being all zeros anyway. [21:28:33] but it still had the burn attitude wrong with heads up/odnw [21:28:34] down* [21:28:42] I'll have the fix up tomorrow [21:28:44] good night! [14:39:17] hey Ryan [14:40:04] Hey good morning [14:40:33] another thing in the Apollo 9 checklist, SIVB 2nd restart is listed as 6:07:04, but comes after the initiate bat charge B at 6:20 [14:40:55] Oh a time error awesome those ca be hard to find when i make these haha [14:41:45] And there it is clear as day haha [14:42:14] Fixed [14:42:54] also should the daylight star check at 7:00 actually start at 6:50? [14:44:48] Yes it should [14:45:07] Good catch [14:45:53] Also fixed [14:47:14] thanks [14:47:35] what does "P52 maneuver to daylight star check attitude" refer to? [14:48:01] in the daylight star check checklist [14:48:12] did you mean V49 maneuver? [14:50:09] also I think the sunrise time given in the PAD is wrong, ill ask Niklas about that one [14:50:20] Probably haha [14:51:14] Where does it say P52 maneuver [14:52:40] in the daylight star check checklist at 7:00:00 [14:53:01] I see "to be performed after P52" and then "maneuver to daylight star check attitude per MSFN" [14:53:35] Ah I see [14:54:13] in-sim it has all those together though, so it reads: "to be performed after P52 maneuver to daylight star check attitude per MSFN" [14:54:33] Oh weird haha [14:54:41] Wonder if I can stagger those [14:55:47] Yeah I have the following P52 now as a heading [14:55:53] So it should be less confising [14:55:55] right [14:56:02] confusing* [14:56:15] it was very confising :p [14:56:28] I bet! [14:57:41] Yeah didn't you know? 249 has a P52 maneuver ;) [15:01:53] Ah damn I need to get the address changes for this landmark tracking from Niklas [15:20:10] good morning Alex And Ryan [15:21:05] Morning [15:21:23] you have inspired me to reinstall my PMDG and DCS :P [15:23:12] yeah i just did another landing and this time with no (vectors) in the fmc route so i didnt really use any atc [15:31:34] rcflyinghokie, so the Apollo 9 checklists, so they go up to splashdown yet? [15:31:44] I am on Day 7 [15:31:50] So almost [15:32:29] I am at a stop on the landmark tracking I need some info regarding the rates and EMEMs from Nik [15:32:39] But then just 2 more SPS burns [15:32:45] And splash [15:33:00] but the flight plan on my end in the checklist file already seems to go up to deorbit [15:35:51] so I guess what I meant was that it was already complete, but your revising it right now [15:40:27] Oh yeah [15:40:35] They all are "complete" [15:40:44] But in need of a lot of love [15:40:56] It was my first draft haha [15:41:14] Especially with MCC support [15:42:33] haha, right [15:47:51] But please keep the questions/comments/errors/improvements coming! [15:53:15] will do! [15:53:24] brb [17:56:54] hey guys [18:01:13] hey [18:01:52] I think the SR time on my daylight star check might be off [18:03:10] wow was I lazy [18:03:15] the one at 6:15:00 on Apollo 9, it has the sunrise at 6:49:45, but actual sunrise isnt until 7:05:00 or so [18:03:20] it's hardcoded to the transcript time [18:03:48] haha [18:04:10] but I wonder why there is such a big difference there [18:05:06] also, T ALIGN is all 0s [18:05:16] I dont know if thats correct or not though [18:06:29] they didn't get one [18:06:34] ah ok [18:07:57] how can the sunrise time be so much off though [18:08:09] the trajectory should be close to the actual mission [18:08:23] ah [18:08:24] Sunrise time - 15: GET 006:49:45.00. The time of the start of the daylight star check. The flight plan PAD describes this field as the time of sunrise at start of daylight star check. However, this figure is the start of the daylight star check procedure which is (sunrise - 15 minutes) and the crew interpret it correctly. Sunrise is thus predicted to occur at 007:04:45.00. [18:09:04] ah there you go [18:10:47] I think I hadn't figured out how to calculate the attitude on the PAD [18:10:53] so I just gave the one from the flown mission [18:11:00] right [18:13:58] Alex, when you get to day 2, I'd like you to save scenarios before the SPS updates and at T-15min or so. and maybe keep track of the DV vectors for me [18:14:10] neither Ryan or I have flown those 3 SPS maneuvers with the new targeting [18:14:22] I have tested it, so I am sure it won't give you a CTD or so [18:14:25] but it's quite new [18:14:50] ok [18:15:04] it uses the new GPM functions? [18:15:07] yep [18:15:15] equations directly from the RTCC documentation [18:15:40] so it will now get into an orbit very close to real I guess [18:15:49] I hope so, yeah [18:15:55] especially your orbital plane [18:16:05] burns are mostly out of plane [18:16:19] in fact they are node changes [18:16:27] so they mostly move the longitude of the ascending node [18:16:34] that's different than a plane change [18:16:42] plane change rotates your DV vector [18:16:59] node shift kind of moves your orbit west or eastwards [18:17:41] the main difference orbit wise will be later, with SPS-5 [18:17:47] that's a circularization burn [18:18:03] and previously the calculations didn't account for the nonspherical gravity [18:18:10] so it never was really circular [18:18:26] your baseline orbit for the rendezvous will be very circular [18:18:43] also has effects on SPS-6 after the rendezvous, which I couldn't properly test etc. [18:19:03] so as you can, even if Ryan and I were just flying the mission, lots of things left to test :D [18:19:06] as you can see* [18:19:13] yeah lol [18:19:43] are all the burns on Apollo 9 updated with the new functions? [18:19:59] only SPS-1 has stayed the same [18:20:10] it's pretty much a fixed DV from preflight [18:20:15] same DV vector in all documentation [18:20:25] so re-entry should be at the correct orientation and time [18:21:42] yeah [18:21:52] but I had that as well [18:22:16] GPM processor stuff was done just before I flew SPS-6 [18:22:45] time will always be off wrong the flight plan after such a long time [18:22:56] but I was much closer than I usually was on Apollo 7 [18:23:47] will be off from* [18:35:07] back in a few [19:16:17] Good afternoon [19:16:46] hey [19:17:00] I have reached landmark tracking [19:17:02] hey Niklas [19:17:27] oh, so quickly? [19:17:29] And made the mistake of buying DCS hornet, its distracting :P [19:17:38] what about the photography experiment [19:17:54] did you manage the pitch orb rate stuff on your own? [19:18:13] No I was going to ask you what the crew used for those rates [19:18:52] the procedure that involves changing EMEMs [19:19:01] Also I have a weird stuck UPLINK light after a SV update on day 7 [19:19:08] hmm [19:19:13] It goes away if I enter P00 but it stays on after the SV update [19:19:17] can happen [19:19:23] a V33E usually does the trick [19:19:30] No ill effects that I can see just a curious observation [19:19:55] And its with that particular uplink I think [19:20:07] what GET roughly? [19:20:11] Because I clear the light, repeat the uplink, same result [19:20:17] One sec, I also have a scn with it [19:21:13] The one at 141:35 [19:21:18] With a T align [19:23:54] looks like a pretty standard SV update [19:24:12] aside from it being uplinked with a rare-ish PAD type [19:24:36] Hey [19:24:42] https://readux.ecds.emory.edu/collections/emory-control:LSDI-Apollo15/ [19:24:45] hey, good evening [19:24:59] holy shit [19:25:11] a whole flight data file??? [19:25:15] Anybody else seen this? Looks like the entire Apollo 15 flight data file assembly [19:25:16] Yup [19:25:34] Download it all now it just went up within the last week [19:25:53] I mean, for Apollo 15 we probably had the most checklists of all missions [19:25:56] but not all of it [19:26:10] like CSM contingency checklists [19:26:19] I'm downloading it [19:26:27] thanks for bring our attention to this, haha [19:26:29] Well now we have a complete lm g&n dictionary [19:26:52] I literally just found it clicking around haha [19:26:58] Whoah! [19:27:58] we were missing a few still for 15 of course [19:28:34] LM Timeline Book even, I believe [19:28:46] CSM Rescue Book should be fun [19:29:24] Downloading everything! [19:30:00] yeah [19:31:25] Hopefully makes implementing the j missions a breeze when it comes to it [19:32:05] Procedurally it should [19:32:22] indy91 where else did we use the DAP orb rate, was it for 10? [19:33:19] yeah, but that was for PTC [19:33:44] just use the beginning of the procedure in the Apollo 9 CMP Checklist and I can give you the EMEMs [19:34:11] or the AOH, I already forgot again that it has the procedures [19:35:05] yeah, that procedure is valid [19:35:10] PDF page 305 in the AOH [19:35:14] the EMEMs are [19:35:26] VVVVV: 00002 [19:35:30] WWWWW: 14175 [19:35:39] XXXXX: 0 [19:35:45] YYYYY: 11546 [19:35:56] ZZZZZ: 23163 [19:36:15] the Z is for the day with SPS-6 [19:36:32] the alignment is different on all subsequent days, so you have to pitch in the other direction [19:36:47] so for the later days it is: [19:36:52] I know I put this in a checklist somewhere [19:36:55] ZZZZZ: 54621 [19:37:01] that's what you need [19:37:10] Wow duh [19:37:23] Sitting right there in 9 "DAP Orbital Rate" group [19:37:33] sounds right :D [19:37:43] Yep its there [19:37:46] these downloads are slow... [19:37:54] I have them all [19:38:07] so what you are telling me is. My Internet is slow [19:38:12] They were quick for me and my internet isnt very fast [19:38:14] So yes [19:38:24] Well not very fast from what I am used to [19:38:34] or it's throttling for other countries. I'll go with that :D [19:38:40] ^^ [19:38:44] Me too [19:39:39] Yeah my procedure has the reversed pitch [19:39:50] you will need both in any case [19:39:52] I will add a note for SPS 6 [19:40:00] er day 6 rather [19:41:03] TEI-11: plus 4144.8, plus 0371.9, minus 0242.2. That's an ambitious early TEI they got there on Apollo 11 [19:42:18] my RTCC is calculating the solution 24h slower [19:42:20] that seems like a big dvx [19:42:33] maybe that's just about in the DV budget [19:43:53] must be [19:44:07] or else they wouldn't have given to the crew on the actual flight :D [19:44:13] True [19:46:02] maximum available DV is one of the inputs for the RTE processor, I guess they just used the fastest return they could possibly do [19:46:15] For landmark tracking were any EMEMs messed with [19:46:34] don't think so, that should be manual [19:47:05] Ok [19:47:58] And do you have an idea what the crew used to exit the dap orbital rate? There are many options [19:48:41] we are missing that page from the CMP Checklist [19:48:46] we only have the first page [19:48:51] I am just putting CMC hold on there [19:48:54] and I haven't figured it out from the transcript [19:49:05] or V37E 00E, or even THC to CW, so many options :D [19:49:11] Yep haha [19:49:19] V49 etc etc [19:49:26] just put the Apollo 11 crew to sleep on LOI day [19:49:32] Seconal [19:49:34] ? [19:49:35] so next week I can start with the descent prep for Apollo 11 [19:50:10] they are astronauts [19:50:19] if the flight plan says to sleep, they should be sleeping [19:50:22] no excuses [19:50:43] Haha well sometimes the flight surgeon intervenes and drugs them ;) [19:50:58] Scare that they used seconal though [19:51:02] scary* [19:51:18] some of the checklists are missing the first pages [19:51:33] in the Apollo 15 flight data file [19:51:34] Volume 2 looks like the LM Activation Checklist [19:52:21] Volume 3 is the CSM Entry Checklist [19:52:46] just naming them, so I don't get confused [19:52:50] Oh absolutely [19:53:31] Volume 1 is CSM Systems Data, which we didn't have yet, but not too much new for us [19:53:44] excerpts of the CSM Systems Handbook, which we had for the J Missions [19:54:22] Oh did you want the save with the stuck uplink light? [19:55:01] sure [19:55:14] I remember getting that once on Apollo 9 as well, but didn't think much of it [19:55:20] I wonder if it was the same uplink [19:56:20] https://www.dropbox.com/s/zebi6ihbjgk31gc/Apollo%209%20MCC%20-%20Stuck%20Uplink%20Lt.scn?dl=0 [19:59:59] oh, stuck uplink light, but not in P27 [20:00:04] so V33 wouldn't do much, lol [20:00:56] something is screwy there [20:01:07] Yeah [20:01:12] And you can clear it with a P00 [20:01:13] it shows both the options ready for uplink and also repeat uplink [20:01:19] I don't think that should ever be the case [20:01:25] But if you repeat the uplink it does it again [20:08:28] Did you have me remove the other P22 checklists in the apollo 9 file? [20:08:31] Didn't [20:09:41] They only used auto optics? [20:10:58] yeah [20:12:13] at least the auto optics checklist is the closest one each time [20:12:39] the actual mission didn't have much luck with most of their landmark tracking anyway [20:12:55] clouds, hung telescope, the 121 program alarm [20:14:04] Volume 5 of the Apollo 15 FDF is LM Systems Data [20:14:11] has parts of the Systems Handbook [20:14:16] might be useful [20:14:51] Oh nice [20:15:00] I look forward to perusing these [20:16:17] no clue about the hung uplink light [20:19:15] afternoon! [20:20:29] Maybe Mike knows ;) [20:21:11] uh oh [20:21:22] What would make a uplink activity light stay lit after a SV update [20:21:30] No hung P27, just the light [20:22:00] hm [20:22:03] indy91 its funny because its consistently this update [20:22:04] not sure [20:22:12] I'll get back to you in a bit [20:22:23] our toilet did a bad this morning and I'm cleaning up the bathroom [20:22:38] yikes :/ [20:22:47] back [20:23:16] hey Mike [20:23:32] rcflyinghokie1, and the updates after it are fine? [20:23:34] and before [20:23:36] o/ [20:23:44] Before yes, havent had one after yet [20:23:50] Alex and Mike: https://readux.ecds.emory.edu/collections/emory-control:LSDI-Apollo15/ [20:23:58] complete Apollo 15 flight data file [20:24:03] I will see if an RTCC update right after does the same, if not then I wager its the MCC update [20:24:39] oh man [20:24:43] what all is in a flight data file? [20:24:49] does this have erasable memory at all? [20:25:08] we had that for Apollo 15 [20:25:15] it's in the G&C Checklist [20:25:21] for the CSM [20:25:23] Regular RTCC SV update no light [20:25:35] But I repeat the MCC uplink it comes back [20:25:40] maybe it's the V66? [20:25:44] I'll try removing it [20:25:46] what about the LM? [20:26:05] I don't think the LGC padload was in the flown documentation [20:26:28] CMC one is only in there in the case you loose all your erasable memory and have lost comm [20:26:29] I wouldnt think the V66 is the reason since it had no trouble before [20:27:08] I debugged it a bit, the assembled uplink string looked normal [20:27:42] and Mike, the flight data file is all flown documentation [20:27:49] checklists, reference materials, cue cards [20:27:55] aha, awesome [20:30:17] we had a lot of this for Apollo 15 already [20:30:20] but not all [20:30:24] like the reference material [20:30:35] excerpts of AOH and Systems Handbook [20:31:16] :D [20:31:39] which is good for the LM, we don't have one for a J-Mission LM [20:32:18] Systems Handbook that is [20:33:13] I guess me and Alex are especially looking forward to the CSM Rescue Book, haha [20:34:01] oh nice! [20:34:41] my internet connection: "ah crap" [20:34:45] yeah [20:34:52] I'm slow with the download is well [20:34:53] as [20:35:02] Ryan had it in like an instance [20:36:45] and we were also missing the LM Timeline Book for 15, right? [20:39:27] well we had the nominal descent and ascent timelines in the Apollo 15 delco manual [20:39:39] but not the abort plots [20:39:40] right [20:40:33] I wonder if it has an LGC padload [20:40:35] indy91, as a novice with P22, what does it mean by set up for yaw/roll landmark tracking? [20:40:40] somewhere in the data file [20:40:49] I doubt it [20:40:55] but it's possible [20:41:06] rcflyinghokie1, I haven't figured that out yet myself, lol [20:41:11] Haha ok [20:41:19] I wasn't able to find any documentation on it [20:41:49] I believe it's a technique to avoid the high trunnion rates that come with a landmark directly below the orbital path [20:41:56] Ah [20:43:17] Ok lets see whats wrong with this P22 procedure [20:44:07] it could be: starting with a yaw angle and then when the pitch rate is initiated, also start a roll rate [20:44:10] something like that [20:44:36] but rolling too much would mess up the tracking in resolved mode [20:44:39] so I don't know [20:48:44] Me either [20:52:44] seems like in this FDF is also the two copies that were flown of some checklists [20:52:58] they had 2x Entry Checklist, 2x LM Activation Checklist [20:53:05] at least [20:56:54] no LGC padload, but I didn't expect one to be there [20:56:58] index of offset designator? [20:57:06] P22 [20:57:12] what? [20:57:18] What is that [20:57:26] oh, in the option code? [20:57:34] Yeah [20:58:01] imagine you want to take marks on a landmark near the landing site [20:58:06] but not the landing site itself [20:58:17] just something close to it [20:58:26] so I think it starts you with pointing at the landing site [20:58:34] but you can input the coordinates later [20:58:43] and it won't overwrite the RLS [20:58:45] I think [20:58:52] Well this is after the marks are taken [20:58:57] so a landmark offset from the landing site [20:59:08] in any case, it should be irrelevant to Earth orbit [20:59:12] Ok [20:59:14] 0 it is [20:59:22] 100DE (DE being lmk id) [20:59:32] uhh [20:59:38] landmark ID? [20:59:50] YEah [20:59:52] must be the stored lunar landmarks [20:59:54] Your pad even gives them [21:00:04] now I am very confused [21:00:28] ohhh [21:00:31] no no [21:00:37] very different [21:00:45] is your procedure derived from the Apollo 8 CMP Checklist? [21:00:52] Yes [21:00:58] early Colossus actually had lunar landmarks stored [21:01:14] and an extended verb to aid in choosing some in lunar orbit [21:01:17] so that is the IDs [21:01:46] that feature was removed after Apollo 8 or 9, not usre [21:01:47] sure [21:02:11] for the IDs in Earth orbit, that's the ID of the Apollo Earth landmark list [21:02:18] refer to the Earth landmark maps for that [21:02:33] very useful for the landmark tracking to study those maps beforehand [21:03:08] and the option code might actually be entirely irrelevant in Earth orbit [21:03:16] only the first digit maybe [21:04:00] yeah, the first digital is still important in Earth orbit, just 0 or 1 are valid options I believe [21:04:04] 05 71 comes up after I mark [21:04:07] known or unknown landmark [21:04:13] the default in there is 70777 [21:04:41] So i guess I just need to know what to replace it with and why haha [21:04:57] 1 and 2 are options, not 0 and 1 [21:05:25] 70777 is just a randomly initialized erasable in shared memory I would guess [21:05:30] Right [21:05:41] option code is 10000 in Earth orbit [21:05:45] 1 is for known landmark [21:05:48] Yes [21:05:53] you got coordinates, so it's a known landmark [21:06:01] But no ID associated [21:06:08] not in the option code, no [21:06:10] Ok [21:07:11] only would work in lunar orbit, only on Apollo 8 [21:07:23] using an ID there other than 1 [21:07:27] 1 is the RLS [21:08:57] seems like the stored lunar landmarks were removed from Colossus right after Apollo 9 [21:10:03] have you been looking at the landmark maps? It's great, with the maps and the high resolution in Orbiter 2016 you really don't need any marker for a good tracking [21:10:37] just good preparations for what you will be looking at [21:12:24] No i dont think I have them [21:13:01] from the Apollo 8 flight data file [21:13:15] https://www.ibiblio.org/apollo/Documents/A8-Landmark%20maps+photos-1004.pdf [21:13:51] AlexB_88, CSM Contingency Checklist has some fun procedures for a CSM power failure in lunar orbit with the LM on the surface [21:14:09] quickly doing power down, LM return and TEI basically [21:14:50] and about LOI aborts we were talking about a few days ago [21:14:58] Oh I have those I thought you meant for Apollo 9 [21:15:52] same thing [21:15:58] don't think they would be different [21:16:11] maps for basically all of the Earth landmarks usable for Apollo [21:16:18] what more do you need, haha [21:16:41] Oh are those earth landmarks in that doc? [21:16:47] yes [21:16:51] I didnt open it :P [21:17:03] Incorrectly assumed since it was 8 it was lunar [21:17:38] there was a separate document for that [21:17:44] but I don't think we have that for 8 [21:18:12] Apollo 10 also still flew the full Earth landmark maps [21:18:30] but later on they didn't have alternative missions that would use it much [21:18:58] "Loss of Comm PTC REFSMMAT" octals in the Apollo 15 CSM Contingency Checklist [21:19:12] good to have that [21:20:49] unless I missed a download, the CSM Rescue Book is missing from this FDF... [21:21:56] and no G&C Checklist [21:23:21] and no CSM Systems Checklist [21:25:39] so not quite a complete FDF [21:25:46] but still, very complete [21:25:51] and lots of new material to digest [21:27:31] Wow transcript has a big back and forth about P22s in earth orbit haha [21:27:48] A little bit of arguing too [21:28:01] what about? [21:28:04] the program alarms? [21:28:09] And then rusty goes "Hey, I wish to hell we had a GSOP" [21:28:17] No about how it's used [21:28:29] How it changes a SV, etc [21:28:33] Its interesting [21:29:11] indy91, nice! [21:29:16] what GET roughly? [21:29:22] then I can check that out later [21:29:33] bummer about the CSM Rescue Book though [21:29:41] Roughly 5 23 23 04 [21:29:47] ok [21:29:54] days hrs mins seconds [21:29:55] ind91, is it missing? [21:30:00] seems like it [21:30:01] indy91* [21:30:04] or hiding somewhere in there [21:30:25] missing ones I have noticed so far: CSM Rescue Book, CSM G&C Checklist, CSM Systems Checklist [21:30:48] we already had the last two ones though [21:31:50] oh, and LM Lunar Surface Checklist [21:32:27] they added these documents from June through July [21:32:32] last one on July 25 [21:32:45] maybe they will still upload the missing ones [21:32:49] that would be great [21:33:35] indy91, any idea if they stored the landmarks or did a V32? [21:34:00] storing doesn't work in Earth orbit [21:34:04] you see the pattern... [21:34:18] Ah yeah good point [21:34:53] or it might work, but write nonsense in the RLS, not sure [21:38:12] that Apollo 15 FDF seems to get its documents from David Scott, who I believe also was the source for the checklists you can find in the AFJ and ALSJ [21:38:32] so there is a chance that they are simply still adding checklists, and not that some are missing [21:38:34] I hope... [21:40:40] hopefully there will be other missions too [21:41:18] Imagine complete data files for every mission, a dream... [21:43:02] yeah [21:43:13] but I'm sure this is just the stuff from Dave Scott [21:43:31] there are a bunch of astronaut collections at their old universities [21:43:47] like for Michael Collins [21:44:15] a lot of Gemini stuff and his personal notebook he talks about in his book, where he kept notes about everything for his fligh [21:44:17] flight [21:44:48] oh, lol. UHCL has Apollo 14 and 15 CSM Rescue Books [21:44:53] because, of course it has [21:45:08] Ill probably get the 3 SPS burns done tonight (SPS-2,3,4 [21:46:03] great [21:47:10] I guess we can wait a bit, if more checklists appear on that page, and if not, all we are really mission is the CSM Rescue Book. And then we should have everything flown from Apollo 15 [21:47:24] missing* [21:47:54] good night! [21:48:08] yeah [21:48:09] night [21:50:57] Woo S065 DAP orb rate and landmark tracking procedures are fixed and working [21:54:58] okay, bathroom has been cleaned, finally [21:56:04] so what's up? [21:56:14] Trying these P22's in LEO [21:56:53] AlexB_88 you might know, for a P22 do I start my orb rate pitch at T1 or T2 [22:06:30] hmm [22:06:35] I think T2 [22:06:49] isnt T1 when you start seeing the landmark on the horizon? [22:07:02] sorry haven't done P22s in ages haha [22:10:20] Yeah [22:10:27] Nor have I so i am very rusty [22:10:36] T2 sounds more reasonable [22:12:34] alright coming up on SPS-2 [22:13:03] You get all the good targeting :P [22:14:24] I feel like a guinea pig :P [22:15:28] Yeah Nik just tested them but not as a whole [22:15:35] So you get the all up test [22:15:38] Niklas said im the 1st to try the new burn targeting for these burns in a full mission [22:15:45] Yep [22:15:45] yeah [22:16:11] He asked for some scenarios before each burn which Ill post one here after [22:17:06] Good call [22:17:13] Its nice to know that its legit RTCC equation from the real thing that are behind these maneuver calculations [22:18:03] As far as the General Purpose maneuver processor is concerned of course [22:20:50] Apollo 9 may be a boring mission considering it just loops around the earth 150 times or so but in Orbiter 2016, man is it scenic! [22:31:06] Oh yeah it is [22:31:30] And the docked DPS and Rendezvous will keep you busy! [22:32:00] It was awesome comparing rendezvous and docking photos with the real mission, the orientations were almost identical to the actual [22:42:09] nice [23:30:06] Goodnight! [23:34:21] .tell indy91 Here is SPS 2 and 3 [23:34:35] .tell indy91 https://www.dropbox.com/s/lvb9l4v3h8bay10/Apollo%209%20SPS%20tests.zip?dl=0 [23:36:02] .tell indy91 SPS-2: +99.5, -845.0, -0.2 SPS-3 +0.7, -2582.5, 0. Still have SPS-4 to do [23:37:05] im off! [11:06:30] . [13:34:01] Good morning [13:35:27] hey [13:38:03] So the landmark tracking is all done, the only thing i dislike is that updates come during a p22 so im considering making mission specific groups to handle that [13:39:21] yeah, I noticed that as well. You need a second astronaut to write down those PADs, haha [13:41:40] Printscreen is doing that task for me ;) [13:44:22] So other than that all i have left is another S065 and 2 more SPS burns i believe [13:44:53] great [13:45:06] pitch orbit rate procedures are working without issue? [13:45:40] Yep [13:45:57] Not quite orb rate but close enough [13:46:35] For the photo pass its close enough [13:47:40] yeah, I guess that's mostly due to the orb rate not being constant [13:47:42] elliptical orbit [13:47:46] Yep [13:47:49] but it was quite close for a while for me [13:47:57] only a few degrees off after 30 minutes or so [13:48:05] Yeah that sounds right [13:56:31] Anything special i should be aware of for the rest of 9? [13:58:36] the state vector updates we probably want to add, but are not in the flight plan [13:59:09] if we don't do that, then the whole will use a 20 hour old state vector [13:59:24] they did those on the actual mission, we just have to find good places to add them [14:00:15] somewhere between the guidance system activation (including P51) and P52 [14:00:51] maybe you can figure out a good time from the transcript [14:01:24] oh, and after SPS-7 your orbit will diverge from the actual mission [14:01:34] because they used a much higher apogee for that [14:01:42] I've stayed with the flight plan [14:06:21] Ill look and see what i can find from the transcript [14:06:35] Did tou get to read that p22 conversation [14:06:37] You [14:07:21] about the best technique for it? [14:07:28] with T2 etc? [14:09:44] Oh no the transcript argument [14:09:55] But that info doesn't hurt either :) [14:10:11] no, I haven't read that yet [14:10:22] the landmark tracking PAD is just the same as for lunar orbit [14:10:37] the timing for lunar orbit is quite optimal and well defined [14:10:50] starting the pitchdown at T2, and then mark at the specified intervals [14:11:06] Ok thats what i ended up doing [14:11:09] for Earth orbit I have noticed, that T2 is about the latest you want to start pitching down [14:11:21] so 10-20 seconds earlier is a bit better [14:11:46] T2 is when the CSM is at 35° above the horizon from the landmark [14:11:58] they didn't get this exact time for the Earth orbit PADs [14:12:05] Oh ok [14:12:24] I think they got either 0°, which is T1, or 5°, which is an often used number for AOS [14:12:35] and it was up to the crew when to start the pitch down [14:12:44] which is of course 0.5°/s, not 0.3°/s as in lunar orbit [14:13:23] Looks like they added a flight plan update to track Spider [14:13:41] Including a sv update for it [14:17:49] Check out about 9 days 55 minutes [14:17:54] Transcript [14:18:59] Also a dap PTC [14:19:20] Different deadband each rev [14:22:50] yeah, I had read that about Spider [14:23:05] and the CMP Checklist has PTC procedures, so I was surprised not to find it in the flight plan [14:24:01] Just gotta remember to sneak those in [14:42:38] Looks like a SV at 187:30 from transcript [14:43:31] And 211:30 [14:44:00] They seem to uplink with the nominal inu orientation even though the fp doesn't say it [14:44:06] IMU [14:44:31] you mean at the same time as they got the T Align? [14:45:22] Yeah [14:45:38] that's easy to do [14:45:40] I just found sv uplinks on the transcript and they line up exactly [14:45:50] then I won't even need to add another MCC state for those [14:46:04] just adding a SV uplink to the T-Align update [14:46:07] Right to the minute [14:46:15] Or close [14:47:20] And i think for the SV at 217h it was shipped to the LM slot to have the old P22 SV in the CSM slot? [14:47:39] Oh and v66 on those t alighn SVs [14:48:04] ok, with V66 [14:48:29] there is no landmark tracking at 217h in the flight plan though [14:48:40] they just did it again because of their earlier problems [14:48:49] Right [14:49:15] Oh and a w matrix update at about 217 as well [14:49:22] I guess for lm tracking? [14:50:42] no, I think they had the W-Matrix disabled before that [14:50:52] so the init values were 0, maybe even in the padload [14:51:06] Oh ok [14:51:26] Ans another SV update fir the LM is 221h [14:55:38] also related to the landmark tracking I would think [14:55:55] I think I'll stay with those two uplinks with the T-Aligns [14:56:03] that enough flight plan changes [14:59:49] No the 221 has the LM SV for LM tracking [15:00:12] ah, right [15:00:26] Unless you dont want to add that and make it optional [15:00:33] hmm [15:00:34] not sure [15:00:55] you can check if you can see the LM at that time [15:02:41] I would guess it heavily depends on the actual trajectories [15:03:07] so, something that only really works on the mission as flown, not as planed [15:05:11] Ill try it at that time and see [15:05:43] If it works i can make it an optional thing in the FP, maybe relying on the mfd for the update [15:41:18] there was a short article about the Apollo 15 flight data file and it mentions 18 binders. So what is available now is all they got [15:42:52] Hmmm still alot [15:44:31] oh yeah, lots of fun new stuff [15:44:44] but at least the CSM Rescue Book would have been nice... [15:45:01] that was what I was hoping for the most and it sadly wasn't there [15:45:08] Who knows maybe al worden has one ;) [15:45:35] oh right [15:45:44] this stuff was from David Scott [15:46:08] so even if he was hoarding all the flight data file stuff he ever had, the missing stuff would not be part of that [15:46:30] except for the Lunar Surface Checklist [15:46:43] that is also missing from the files [15:46:52] Yeah since Al was the CMP and is still alive its possible he has one [15:48:01] yep [15:48:38] he certainly had one for Apollo 16: http://www.echoes-from-apollo.com/my-blog/2012/11/apollo-16-csm-rescue-book-change-a-for-all-launch-dates.html [15:48:55] Random, i didnt know the F1 used TEB as an ignition source [15:49:20] I assumed spark plugs like the J2, but i guess RP1 needs more oomph [15:50:06] yeah, I think I had read that before [15:50:29] I also realized that the CM thrusters used a different hypergol mix than the SM [15:50:48] It didnt used Aerozine 50 [15:51:52] It used instead straight MMH [15:51:56] I wonder why [15:52:37] This book has been sparking my fuel research on the spacecraft haha [15:53:38] maybe it has to do with operating in the atmosphere [15:54:01] Possible [15:55:34] MMH alone isn't as stable though [15:56:19] But MMH has a higher density, so better performance [15:56:48] Which could be needed for atmospheric use like you said [15:59:58] Still an interesting detail considering the SM RCS, DPS, APS, and LM RCS all used Aerozine 50 [16:00:10] right [16:10:59] back in a while [16:46:37] morning! [16:47:06] rcflyinghokie: that's really interesting [16:49:51] Which part? Lol [16:50:42] CM thrusters using MMH while everything else used Aerozine 50 [16:52:32] Oh yeah [16:52:54] And of course Az50 is 50/50 UDMH and MMH [16:53:29] yep [16:54:03] maybe because MMH is a bit denser than Az50? [16:54:29] that could have helped with space a bit, but probably not a lot [16:58:05] Hmm a later AOH says MMH for the SM [16:58:21] Curious [17:03:07] That makes more sense to me though [17:03:17] But still why MMH amd not Az50 [17:27:30] Did the SPS need regenerative cooling? [17:27:40] Thats a ln advantage of Az50 [17:33:25] not sure [17:33:48] I'm at the point where I need to add a few more PADs for Apollo 11 [17:34:08] K-Factor and AGS abort constants [17:34:26] I know that they were written down on an LM Activation data card on Apollo 13 [17:34:39] but 11 and 12 it might still be in the LM Activation Checklist [17:34:47] but there is no space there for the K-Factor [17:35:14] I'll add them to one PAD together anyway I guess [17:35:22] they are read up together [17:52:58] Does MCC compute it? [18:05:05] I was looking into it, but it's pretty tricky [18:05:30] I'm not quite sure how the ground gets accurate AGS time [18:06:22] and the abort constants, I have good documentation how to calculate them for Luminary116 [18:06:31] Luminary099 uses a very different concept [18:06:35] not sure about the AGS [18:06:51] I think the AGS is more like Luminary116 and later already [18:07:08] just only supports one descent abort phase [18:13:05] That would make sense [18:13:59] And for the k factor, could ground see the 377 and LGC time and compute the difference? [18:14:33] 377 is on telemetry [18:14:40] it just only changes every few seconds [18:15:01] there is a least significant half of the double precision time [18:15:04] 353 I believe [18:15:18] but it's static, changes whenever you initialize the time [18:15:59] so maybe the accurate clock time is whenever the clock changes one bit [18:16:10] but I'm not really sure [18:25:10] I thought the k factor wss the difference between lgc and ats clocks caused by astronaut error [18:25:17] Ags* [18:26:03] yes [18:26:23] but also the nominal time offset [18:26:33] so usually it's something like: 90:00:00.15 GET [18:26:53] so mathematically it's simply: LGC time minus AEA time [18:27:57] I know how to get accurate current LGC time, no problem [18:30:03] But the k factor? [18:31:42] as I said, K factor is LGC time minus AEA time. And the AEA doesn't seem to keep a current time on a sub second scale [18:31:58] I guess it's just some counters and those increment 377 [18:32:24] so I haven't quite figured out yet how to get that from the Virtual AGS [18:33:07] it must be something with that least significant half of the AGS time [18:33:10] maybe [18:34:09] have to look through the AGS documentation [18:34:25] Ah i see what you mean [18:36:09] I hope I figure it out, would make the AGS more precise [18:36:23] should be easy to add that update to the RTCC MFD then as well [18:36:32] Unless MCC just computed it separately on earth using the 377 sampled a few times [18:38:56] But that seems too simple [18:39:14] yeah, really not sure how they did that, right now [18:39:30] I can see if any ags docs have something [18:39:33] I'm not even sure how they could accurately determine that the AGC needs a clock update, which they did from time to time [18:41:34] Would have to be some ground processing of the TM I'd imagine [18:41:48] Which is my theory for the k factor [18:46:16] Maybe ill uncover something this evening, gotta catch my train [19:54:53] hey [19:58:13] hey, good evening [20:02:17] did Guenter give you burn info I posted last night? [20:02:18] the university website says it got 18 binders from David Scott, and all of them are already up [20:02:22] yes [20:02:30] so he didn't have the checklists that only the CMP really had to use [20:02:49] bummer [20:02:56] but we have all the checklists that are missing already, except the CSM Rescue Book [20:03:02] and a copy of that is at UHCL, so all good [20:05:31] we already had that from Apollo 14, but the 30 minutes LM activation in the Contingency Checklist sounds fun [20:06:28] we didn't have the procedures for the CSM for that before though [20:07:23] the procedure applies to a partial LOI [20:07:41] 650 to 900 ft/s burned [20:07:45] so a pretty narrow window [20:07:57] before that you can wait 2 hours before having to do a maneuver [20:08:22] and after 900 ft/s burned are different procedures [20:09:13] but I've never tried any of the LOI aborts [20:09:25] sounds like a fun challenging getting back home with that [20:09:29] challenge* [20:16:04] oh good, I have your Apollo 15 scenarios to try that :D [20:18:09] yeah [20:19:31] we don't have a way to update the LOI abort charts yet [20:20:14] the Apollo 10 RTACF support plan suggests the attitude is fixed with specific pitch and yaw relative to Earth-Moon plane coordinates [20:20:31] but I can only guess what inputs they used for that [20:20:44] Apollo 10 seemed like 20° pitch 0° yaw in my tests [20:20:52] but Apollo 15 might be way different anyway [20:33:35] yeah Id love to try that at some point [20:34:02] ok hopefully I can get SPS-4 out of the way this evening [20:34:07] great [20:35:38] I have to say Apollo 9 is not as boring as it seems on paper lol [20:37:39] Before the mission I was like, ok going to loop around the earth endlessly... But so far every burn has a curve-ball like the stroking test on SPS-2 and MTVC on SPS-3 [21:04:30] boring are only the last 3 days or so [21:04:35] the flight plan is empty [21:04:42] but on the actual mission they added some stuff [21:04:51] I'm just doing the LOI+30 minutes procedure btw [21:06:02] activation timeline is... challenging [21:06:27] I bet it is [21:08:02] didn't have time to also prepare the CMC to monitor [21:08:12] I'll do a corridor control calculation after the burn [21:08:33] should be the best indication if this was any good [21:12:24] woooow [21:12:37] corridor control burn would be only 86 ft/s [21:12:59] it was a manually controlled DPS burn, just monitored with P47 [21:13:05] so for that it's pretty good I would say [21:13:25] more than 10 minute burn, 2100 ft/s [21:13:27] nice stuff [21:13:47] 4% of DPS propellant left, lol [21:14:36] not sure if the DPS can do that 86 ft/s alone [21:15:48] no, not quite enough [21:16:19] but I am sure, with an updated LOI abort chart you could do even better [21:16:42] based on actual trajectory and REFSMMAT [21:16:55] but I am very happy with that result [21:17:10] next time I have to print all the procedures, so I don't have to check the PDFs, wasting time [21:18:10] that was fun though. Good night! [11:42:05] Good morning [11:42:19] hey [11:43:18] I flew the LOI 30 minutes DPS abort yesterday evening [11:43:27] very challenging [11:43:46] with the new Apollo 15 CSM and LM Contingency Checklists and Alexs pre LOI scenario [11:44:25] Oh nice [11:44:45] the procedure has to be used if the SPS fails during LOI [11:45:10] only a very small timespan during LOI though [11:45:25] failure between 650 and 900 ft/s DV already burned [11:45:41] quickly activate LM, because TIG is at 30 minutes after LOI TIG [11:45:51] and then a 2000 ft/s burn nearly depleting the DPS propellant [11:46:05] I barely made the burn on time [11:46:13] activating the LM in 30 minutes is... interesting [11:46:46] Be like apollo 13 [11:46:48] oh, and the burn is manual [11:46:59] no time for a full LGC activation [11:47:13] Ags? [11:47:25] AGS controlling yaw, pitch and roll manually with the TTCA [11:47:43] Kind of like 13 [11:47:47] but you are flying LGC error needles and have P47 running [11:47:56] Yuck [11:48:02] yeah [11:48:12] the burn is fixed attitude, fixed DV [11:48:24] Probably easier with 3 crew ;) [11:48:35] and the chart for it would be updated in real time, so difficult to say how much off the attitude and DV was [11:48:54] yeah, I had no time to do the CSM part of the burn. Only the maneuver to burn attitude [11:49:16] but with all of this, I got a corridor control burn of 86 ft/s for 20 hours after the maneuver [11:49:18] not too bad [11:49:25] Boy it would be cool to have multiplayer [11:49:31] yeah [11:49:38] also for rendezvous procedures etc. [11:49:43] Oh yes [11:49:54] tracking each other, rescuing each other, haha [11:50:24] I want to try the 30 minute LM activation again some time, but then with the checklists printed [11:50:33] that will result in a bunch of time save [11:50:38] Yeah im sure it would help [11:51:36] if the DV was a bit larger and communications are lost, then you would do a FITH once the DPS is depleted and finish the burn with the APS [11:51:39] I'll try that next time [11:51:57] Oh in not good news i couldn't find a thing on k factor computation, other than the obvious get when ags time = 0 [11:52:15] I found one thing [11:52:25] oh and I tried one other thing [11:52:48] so I set it up, so that whenever 377 changes by one bit, it compares time with the LGC clock [11:52:55] doesn't give me consistent results [11:53:00] K Factor is still moving around [11:53:29] and what I found was something the Apollo 9 Mission Report Supplement for the AGS [11:54:20] https://web.archive.org/web/20100519172039/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19750064239_1975064239.pdf [11:54:27] PDF page 145 [12:02:16] Lets see ehat this says [12:04:48] Oh interesting [12:04:55] Not what i expected [12:10:48] dumb question, how again do you convert erasable memory of the AGS to the DEDA display? [12:10:52] just drop the last two bits? [12:30:18] I believe so [12:30:28] I dont remember exactly off hand [12:31:46] I'm at the PDI PAD for the Apollo 11 MCC right now. Haven't flown anything of it yet though [12:31:50] Pdf 89 of the op manuap? [12:32:04] Op manual* [12:33:36] yeah, that could be it [12:40:01] next I want to implement simulations of ascent and descent guidance [12:40:32] that is needed for accurate insertion state vector prediction, descent abort constants calculation and a few other things [12:40:39] Oh yeah [12:40:50] should also result in more accurate liftoff time calculation [12:42:06] have a bit of info how that was done in the RTCC in a Apollo 12 document about calculating the descent abort constants [12:42:23] So i haven't flown a liftoff since before the AOT spiral math fix, sis that fix the plane error during ascent? [12:42:34] Did that* [12:42:55] I think so, yes [12:43:10] I remember that we still had some issues with that [12:43:14] but I'm not sure [12:43:50] The plane error was simply a result of a bad alignment [12:43:57] yeah, should be [12:44:05] So if the p57 works better it should fix it [12:44:15] yes [12:46:35] Looking forward to it [13:03:57] So ive been wondering, was it just the tunnel pressure during undock plus mascons that had 11 target a bad landing site? [13:08:53] mostly I think [13:09:39] Wondering if we can recreate it [13:10:33] mascons probably not [13:12:12] Tunnel dv should be relatively simple [13:12:42] Assuming we can find a figure for that dv imparted wrt pressure [13:13:21] the CSM Data Book had something I believe [13:13:52] Which mission [13:16:13] in the general section [13:16:19] so in both of the books we have [13:16:45] good morning [13:17:33] thinking about starting 11 this morning [13:17:41] Just trying to find them [13:18:36] Ah found them [13:20:40] @indy91 have you found the cause for that pad displaying ctd yet? [13:20:48] unfortunately not [13:25:06] just wondering how far into 11 are you? [13:25:39] flown until the end of LOI day [13:25:51] working on PDI day PADs [13:25:55] very nice [13:26:10] you could probably fly the mission until LOI-1, if you want to [13:26:11] Yep got a table for approximate dvs for pressure [13:26:39] yeah the tlc is fairly simple [13:28:23] Should be easy to implement [13:29:59] Any idea what is set to now for undock [13:32:23] you mean what DV is imparted at undocking? [13:34:04] Yes and jettison i guess haha [13:34:15] Though they should be different [13:35:35] not sure [13:37:19] I believe the undocking DV is some Orbiter code [13:38:13] Ah [13:38:21] I found the math for it [13:38:35] Based on mass/tunnel pressure etc [13:38:57] Dv imparted for each vehicle [13:39:59] And two stage undocking [13:42:37] Just need to find velocity imparted by the probe extension and ill have all the pieces [13:44:19] About .5 fps [14:03:04] woo, I have the basics of the ascent simulation [14:17:33] I'm not quite sure how to manipulate the undocking velocities [15:15:53] I can get some math in place and then we can look into that [15:38:50] Hmm i guess lm jett doesnt impart as much dv as I thought [15:45:38] doesn't have to to be much, anything in horizontal direction gets worse over time [15:45:46] for the state vector [15:52:50] Well i mean the jettison not undock [15:53:22] The probe extension imparts 5fps split between the vehicles based on mass of course [15:53:55] They came up with another undocking technique to alleviate this called two stage undocking [15:55:04] Results in LM dv of 0.0086 fps [15:55:11] that's not much, lol [15:55:39] Yeah [15:56:03] Compared to about 2.7 with no tunnel pressure [16:01:23] just tried a lunar ascent with one of Alex's Apollo 15 scenarios [16:01:48] the cutoff was on the second with the new ascent simulation [16:04:56] now I need Alex to tell me what inputs to use for the tweak maneuver, lol [16:06:08] looks like below 10 ft/s in any case [16:06:39] great, I was quite annoying in the past about the fact that the liftoff time calculation uses some very rough assumptions [16:06:44] now it seems to be very accurate [16:33:39] next I need to implement a simulation of the descent guidance [16:33:43] bit more complex [16:34:16] and the Powered Descent Abort Program, which calculate abort constants and for I have good documentation, uses both ascent and descent simulations [16:49:35] morning! [16:50:40] Where would i find this undocking velocity [16:51:02] Oh mike, do you know how the AGS k factor was computed by chance? [16:51:09] And good morning :) [16:51:35] haha nope! [16:51:40] I don't even know what a k factor is :D [16:53:05] hey Mike [16:53:22] o/ [16:53:27] you have to ask that in a different way to Mike :D [16:53:34] how long does it take for the AGS clock to overflow? [16:53:43] how long is an Apollo mission? [16:53:48] lol [16:53:51] good question [16:54:10] something with 70 hours and up to 300 hours are the answers [16:56:50] um [16:56:55] does the AGS even have a hardware timer? [16:57:00] this might be done in software [16:57:31] not sure, I will get back to you [16:58:51] software I think [16:59:23] well in any case, to be able to use the AGS for GETs after 70ish hours, you usually use a time bias of 90 or 100 hours or so [16:59:27] that is the K Factor [16:59:50] And its usually not perfect like 90:00:0000 [17:00:38] yeah, it depends on how exact the astronaut has initialized the AGS clock. And we haven't quite figured out yet how mission control could calculate the exact time difference. [17:03:00] That cdu error report is interesting [17:03:08] But still dont quite get it [17:03:35] yeah, me neither [17:04:18] maybe a clever way to figure out the time difference by looking at some attitude calculations? [17:06:38] Who knows haha [17:07:37] attitude stuff certainly gets calculated more often than the AGC clock time [17:09:43] True, i guess the answer lies in what AEA TM they get? [17:10:18] And what in that can be used for a k factor [17:10:24] yeah [17:21:34] OH SHIT [17:21:39] http://fold1.gainesville.archive.org/0/items/apollocommandmodacel/apollocommandmodacel_raw_jpg/ [17:22:20] finally [17:23:49] ^_^ [17:25:23] it has been.. 509 days since I first sent a message to the guy asking if he would be interested in having them scanned lol [17:25:39] that is a record that maybe only NASA STI will be able to beat [17:26:42] infinity > 509 [17:27:19] hehehe [17:28:06] Yeah dont tempt fate now [17:28:14] good point [17:28:18] she's only scanned the binder so far [17:28:28] Progress [17:28:38] https://archive.org/details/apollocommandmodacel [17:29:25] rcflyinghokie, when I undock any two vessels, the relative speed is 0.2 m/s [17:29:39] Orbiter default? [17:29:48] yeah [17:29:56] .2 for both? [17:30:02] relative speed [17:30:02] Or total [17:30:05] Ok [17:30:13] not sure how that is calculated [17:30:28] I posted the question on orbiter forum [17:30:29] if it just gives both of the 0.1 m/s or some mass calculation [17:30:30] yeah [17:32:14] it doesn't look configurable [17:32:19] Well i have mass/pressure calculation ready for if/when we can use it [17:32:21] it might be by hacky methods of course [17:39:51] At least the math for a replacement method is straight forward :) [17:40:48] yeah, I remember it being quite managale equations in the CSM Data Book [17:41:12] Yeah basic algebra [17:42:01] And then i just did a simple regression to figure out the equation for pressure vs Valpha [17:42:11] Fits a power function nicely [17:47:07] Also apparently for 11 they vented then turned the valve to dP, instead of leaving it in vent [18:41:17] So i think when i get hone ill make those P22 into mission groups to allow for the updates during and then burn sps 7, almost done [18:42:12] I didn't quite understand what you mean with mission groups [18:42:21] there are MCC updates during the P22s [18:42:46] how do you want to deal with that in the checklists? [19:11:24] Sorry train LOS [19:12:38] I was thinking either i can put the P22 in the flightplan group or make a group for each set. Right now I have a group for P22 with 3 landmarks and one for 4 it makes it easier to handle the recycling [19:13:13] ah, ok [19:13:20] But the group for the entire tracking period seems more prudent [19:14:18] Make it a mission specific one for the whole tracking period [19:15:07] Ill play with it but i think that route is the cleanest [19:15:27] And then i need to also check if i can see the lm [19:25:02] I was very familiar with the ascent guidance before today already. But one thing I learned is that there is a pitch steering limit that is purely there for compatibility with the AGS orbital insertion [19:25:41] I guess otherwise there is the chance of erratic commands when switching over to the AGS [19:30:04] A limit in P12? [19:31:18] yep [19:31:32] it only seems to run into that constraint early on in the ascent [19:32:20] so if you switch to AGS early in the ascent and this limit in P12 wouldn't be there, then it might have a very different pitch angle or so [19:33:03] I guess they did simulations with switchover at different times and noticed some undesirable behavior there [19:33:28] Ab i can believe that [19:34:07] yeah, I think the AGS has a quite different guidance scheme. Have never really looked at it though [19:39:02] Yeah i think the way it computes the guidance is simple more coarse [19:39:30] Like the Saturn before IGM maybe [19:40:40] yeah [19:40:51] I mean, even P12 is quite simple as compared to e.g. the IGM [19:41:27] but the AGS probably can't afford as much vector math [20:23:42] night! [21:04:06] .tell indy91 your landmark tracking update for 144:35:00 only has 3 landmarks when it appears it should have 4, is this a mistake? [11:11:42] Good morning [11:14:03] good morning [11:14:31] started up the 737 600 using just the checklists that i printed out [11:14:31] hey guys [11:14:54] need to learn that with the nassp checklists [11:16:17] I just couldn't find 4 good landmarks on that rev [11:16:42] not even when looking at the SCOT plots of the ground track [11:17:22] Ah ok so should i change it to 3? [11:17:59] yeah [11:18:11] Astronauthen96__ you will get it memorized in no time running the flow [11:18:44] flight plan says Hawaii, Southern US and Caribbean Islands [11:18:58] Hawaii and Caribbean Islands is one landmark each [11:19:05] Indy91 sure ill do that tonight. I am through sps7 and about to start S065 again [11:19:16] and there really is no time to track 2 landmarks in the Southern US and then also one in the Caribbean [11:19:27] Haha yeah i bet [11:19:47] how did SPS-7 go? [11:19:57] Oh i fot replies about the undock dv but i dont think what i was asking got through to those whom replied [11:20:05] As far as i can tell it was good [11:20:17] Got the prescribed Ap and Pe [11:20:37] for the first time during the mission, your orbit is correct, lol. Both on Ap and Pe and also in the location of the line of apsides [11:20:47] As far as where i am wrt the actual mission orbit at this time idk [11:22:41] should be good [11:23:12] Awesome [11:23:13] and about the undocking DV, maybe the solution with modifying the state vector is the only one possible [11:23:25] if it's all hardcoded in Orbiter [11:23:48] would be similar to what we do when a new vessel is created [11:23:49] But that would mess with the sv error im trying to get wouldn't it [11:24:30] I want to see if this will cause a long landing [11:24:45] But also its real dV imparted [11:25:16] not sure what you mean [11:25:27] did they have P47 running but something about it didn't work? [11:26:15] or no P47 [11:26:58] the SV error you are trying to get is the LGC state vector for the LM. Imparting a DV by modying the state vector of the LM in Orbiter doesn't change the state vector in the LGC: [11:30:06] Ohh i misread then [11:30:21] I was thinking the reply was to change the LGC SV [11:31:56] I'm not sure they know about the SV in the LGC, haha [11:36:39] Yeah probably right :P [11:37:09] I just got some potential good advice from GLS that could be useful [11:38:20] I don't think the BTW2 comment is relevant [11:38:33] our dockingprobe code prevents a redocking like that [11:38:35] I think [11:39:45] Could be an issue for a two stage in the future, i need to figure out how this was done, i thought the capture latches were released automatically during extension [11:42:16] in fact the dockingprobe code might be the best place to handle this [11:42:35] is two stage undocking not supported? [11:49:42] I dont think so [11:50:02] That was extending the probe but not releasing the capture latches [11:50:50] And then releasing them using csm rcs to bring the probe out of the drogue in order to reduce lm dV from undock [11:51:16] Im trying to find the procedures [11:51:43] "soft undocking" in tbe AOH [11:52:47] Is the extend release switch in NASSP a mom up? [11:52:54] It shoukd be if not [12:00:48] yeah, I don't think that is supported [12:21:10] Well if anything the switch should be a mom up :P [12:23:05] Oh i see when the switch is held up the latches release and the probe extends, when the switch is released to neutral the latches re-engage [12:24:35] But the probe will totally extend with just a momentary bump of the switch [12:24:50] Letting it hold with the latches after extension [13:52:00] Looks like my forum post is generating some steam :) [13:52:17] great [13:52:38] Maybe we will get some useful sdk answers [13:53:06] I've looked at the SDK and haven't found a way to override the default undocking DV. But maybe there is such a thing and I just missed it [13:53:46] we're probably going to end up doing that in our dockingprobe code is my guess [13:53:49] but we will see [13:54:18] my brain is all confused about Apollo 11 abort and rescue stuff right now, haha. I could use an Alex to talk it through [13:54:32] Could be worth mentioning to Dr. Schweiger as well [13:54:41] About the default dv [13:54:55] yeah, wouldn't be the first time we got him to implement something new! [13:54:56] Haha yeah [13:55:16] thank god for the moment of inertia changes [13:55:21] that was really important for us [13:55:40] Seems like it would be easy to do, the docking code i mean [13:55:47] yeha [13:55:48] yeah [13:55:50] Oh yeah it made a huge difference! [13:56:02] about that, when I did the LOI abort thing I noticed that the attitude rate was fairly high during LOI [13:56:12] have to look at the Artemis padloads I guess [13:56:25] 15? [13:56:48] yep [13:57:13] probably normal, but I'm not sure I ever did any changes to that padload with the PMI changes [13:57:22] but it might have been correct all along anyway [13:57:47] Also perhaps an alex question he seems to like J missions ;) [13:58:36] I do like them as well [13:58:53] bit of a nightmare for the RTCC MFD to support so many procedures and missions [13:59:09] a lot of that stuff was added just so Alex could fly a mission the right way, haha [14:01:07] DAP part of the padload is correct of course [14:01:15] one or two octals were slightly different [14:01:23] Yeah and dont get me started on systems for j missions [14:01:26] but not so much that it can change anything [14:01:49] Though i "added" those consumables changes for him to fly them too haha [14:02:25] Guess he wanted power/oxygen tge whole time or something [14:02:32] I see a pattern [14:04:12] Artemis could actually deal with the wrong PMIs any way [14:04:33] the wrong and the right ones [14:04:48] For Comanche055 and earlier we had a padloaded parameter wrong, which made it work despite the wrong PMI [14:04:58] now it works and the parameter is right [14:08:12] Oh its weird having zeroes for the sps gimbal angkes in the maneuver pads, i got used to always seeing something from rtcc haha [14:09:41] hehe, guess you had a LM attached for quite a while [14:19:27] Yep! [14:19:56] Though the actual CSM had non zero angles right? [14:20:20] quite mass dependant [14:20:25] CoG moves around [14:20:49] https://history.nasa.gov/afj/ap15fj/csmgc/5-12.gif [14:21:36] we only have zero angles, because our SPS is offset to result in those zero angles for the CSM alone [14:21:55] which results in non-zero and variable angles for CSM+LM docked [14:22:24] So the variable COM will be needed to make that look right [14:22:36] and zero angles means zero trim angles. The zero position on the real SPS is offset by 2° in pitch and 1° in yaw [14:23:10] yes [14:27:47] Oh interesting k factor blurb: [14:29:09] From AOH: MSFN can obtain precise value of K by comparing LGC and AEA downlink and can correct for uncertainties in processing pushbutton depression" [14:29:46] processing pushbutton depression? [14:32:11] I read that as literally the difference in when the enter was keyed in 377 and lgc time [14:33:01] oh, interesting [14:34:22] so basically [14:34:25] LGC time on telemetry [14:34:30] DEDA enter event on telemetry [14:35:11] Thats what im thinking [14:35:17] Seems reasonable [14:35:46] Lm aoh under R47 [14:35:52] Pdf 293 [14:41:52] hmm [14:42:02] you can interpret that differently as well [14:42:39] MSFN can correct for uncertainties, which are caused by the AGS processing pushbutton depression not exactly on time [14:45:07] Or both [14:45:12] A combination [14:45:40] Either way its when it processed the enter and the lgc time on tm i think [14:45:42] the first variant would be "by processing" not "in processing", right? [14:45:54] ah, I know what you mean [14:55:40] Think that could work? [15:13:50] waiting for processing a button press would be difficult to implement [15:16:30] Damn elevator acting like a faraday cage [16:41:36] Hows Eagle? [16:43:08] same as the last few days [16:43:27] just working on all the PADs and updates before the descent [17:16:07] Any luck with the abort constants [17:16:56] yes [17:17:11] just needs a lot of infrastructure [17:19:17] Such as [17:19:33] ascent guidance simulation [17:19:45] basically done and used for the lunar liftoff time calculation already [17:19:51] descent guidance simulation [17:19:57] only the beginning stages done [17:20:28] and then it uses discrete abort times (like 2,3,4 minutes after PDI) and iterates on the required horizontal insertion velocity [17:20:46] and when that all is done it interpolates the solutions to get the abort constants [17:21:21] Interesting [17:21:44] that's how it worked for Apollo 12 [17:21:48] from an August 1969 document [17:22:05] Apollo 11 has different kind of abort constants, but the general process should be the same [17:24:56] Guess you will be doing some AGS aborts to test? [17:25:21] that all is for PGNS abort constants [17:25:42] AGS abort constants is kind of similar to Apollo 12 and later in Luminary [17:25:59] so it should be the same general process [17:26:42] the best sign that the constants are accurate will be the CSI DV [17:26:48] should be close to 0 [17:27:14] hmm [17:27:32] well not all that close really [17:27:59] When were pgns aboet constants updated [17:28:03] Abort [17:28:28] yep [17:28:30] per uplink [17:28:37] and that's needed for PDI2 anyway [17:28:42] CSI DV isn't 0 [17:28:49] but DH should be 15NM [17:29:00] with the fixed TPI time [17:34:11] "when were", oops [17:34:34] Apollo 11 flight plan calls it "LGC abort constant" [17:34:44] together with LS REFSMMAT and state vectors [17:35:10] so a while before undocking [17:35:55] and they must have been ready to update the LGC and astronauts if PDI get delayed [17:36:08] there is alot of uplinks and PADs to do for that, haha [17:39:20] I imagine so! [17:39:39] I'm not quite sure when Apollo 16 landed [17:39:48] maybe they made it to the second opportunity [17:40:54] 104:29:36 was contact [17:41:06] planned was 6 hours earlier [17:41:11] *35 [17:41:12] so they were whole 3 revs late [17:41:27] Damn SCS [17:42:02] crossrange on their PAD had become 3.6NM [17:42:17] couldn't have waited many more revs for the landing [17:42:20] Still below 8 [17:42:24] yeah [17:43:42] also becomes an issue for the terrain model [17:43:58] True [17:43:59] which might stricter than the constraints on guidance and propellant [17:47:19] Id be curious especially for apollo 15 [17:51:33] for what? [17:52:25] Terrain model degredation [17:52:51] oh, it's bad as it is [17:52:56] even with the right trajectory :D [17:53:12] but yeah, the trajectory is directly above Mons Hadley Delta [17:53:18] accounted for in the terrain model [17:53:36] if you start PDI at 8NM crossrange, then that should be interesting [17:53:57] one thing to note though is the two phase targeting [17:54:20] so it already tries to achieve a mostly in-plane position after P63 [17:54:41] and not just be at the landing site coming from somewhere at the end of P64 [17:55:00] so that cancels out that problem a little bit, but only late in the descent [17:55:58] Still I wonder if than just crossrange limits you as your revs increase [17:56:05] More than just* [17:56:15] hmm [17:56:20] maybe the mission rules have something [17:56:23] Like would something else limit before hitting 8 [17:56:30] also the LM operating under full power [17:56:54] I think the power reserves were pretty good [17:57:27] Especially with powering down on the surface and the bigger des bats and lunar stay battery [17:58:12] right [17:58:16] But yeah that could certainly be a factor, as could water use [17:58:31] From operating at full power [17:59:20] I believe the 8NM is mostly the constraint for the ascent [17:59:44] which becomes a constraint for the descent as well, if you have to abort shortly after landing [18:08:24] morning! [18:11:07] no scanning progress on ND-1021041, lol [18:11:21] the only scans are still just the front cover of the binder [18:22:18] such a tease [18:25:03] seriously [23:18:46] .tell indy91 before I forget, for the DAP orb rate procedure for S065 on Apollo 9, were B/D thrusters disabled? For some reason I have that in the checklist unless its a carry over from 10 [11:35:15] Morning [11:35:49] hey [11:36:10] that's from the Apollo 9 CMP Checklist I believe [11:36:15] I disabled them, yeah [11:36:58] Ok i thought it was from the cmp checklist, I pulled up the aoh last night and was like ok why did we disable [11:37:44] Also, similar note the second S065 has all zeros for the botton half of the pad [11:38:27] yeah, only one target to photograph [11:38:33] but it always displays the whole PAD [11:39:05] which actually might be the cause of the annoying CTDs, sometimes when a PAD with strings that are empty gets displayed [11:39:13] but I haven't been able to properly debug that [11:39:57] I filled in the PAD like they did on the actual mission [11:40:07] the first entry is when you should start the pitch orbit rate [11:40:15] time is 5 minutes before reaching the first target [11:40:24] and only there an initial attitude is given [11:41:17] Whats with the 2 fdai angles [11:41:41] The one thats populated and the other all zeros [11:43:18] the first one is where you start the pitch orbit rate 5 minutes before reaching the first target [11:44:07] And the second next to it? [11:44:29] all the other ones are just 0, because you only need the initial attitude [11:44:37] you just keep going in orb rate for that rev [11:44:48] Oh ok it was confusing [11:44:56] 0 means no entry [11:45:18] I'm not sure how to do it differently [11:45:21] Easy to mix up for fdai angles though where 0 can be an entry [11:45:42] Yeah i see the dilemma with that [11:45:57] would be some work, but I could check if it's 0 and display something else instead [11:45:58] an X or so [11:46:03] or NA [11:46:05] Certainly confused me though [11:46:06] N/A [11:46:08] right [11:46:20] N/A could work [11:46:33] I'll see what I can do [11:46:34] I originally was thinking XXX.XX [11:46:47] But N/A is more obvious [11:47:05] just implemented 4 new PADs, not looking forward to going back and changing old ones, lol [11:47:20] but I am through with the LM abort PADs for Apollo 11 now, I think [11:47:28] just a bit more and I can fly and test it all [11:47:50] Haha right, well its trivial, the only important add woukd be the SV's later with T aligns [11:47:55] Oh nice [11:48:19] Oh one thing ive noticed now that ive started regularly trimming is i always get overburn when i trim [11:48:48] trim? [11:48:50] you mean ullage? [11:53:25] but I also think you would overburn anyway, because that's just how the behavior is without simulating thrust on delay, thrust off delay and tailoff thrust [11:53:41] for burns controlled by the CMC that are under 6 seconds that is [11:53:53] Yes sorry haha brains not up yet [11:54:11] Ah thats probably it [11:54:19] I think I had about 1.5 ft/s or so on SPS-7 and 8 [11:54:43] Yeah 1.2 for my sps 6 and 7 [11:54:50] minimum impulse burns (under 6 seconds) are based on hardcoded constants [11:54:59] at least up to Apollo 9 [11:55:26] yeah [11:55:30] And i believe the guidance was not to trim residuals [11:55:54] in Comanche055 and Artemis the short burn behavior is configurable in the padload [11:55:59] I forgot about the min imp constants [11:56:29] let me quickly do a graph for that [11:59:06] hmm, I thought I had already a script for this [12:00:46] Is "short burn" determined from estimated burn time? [12:01:18] yep [12:01:33] it has logic for burns of 0-1 seconds and 1-6 seconds [12:01:55] 6+ seconds it recalculates the cutoff time every guidance cycle [12:02:19] but for short burns there is not enough time for that to converge [12:02:26] so the cutoff time is already fixed before ignition [12:17:15] Ah i see [12:17:27] So if a burn is say 6.9 seconds? [12:17:41] Or something above but close to 6? [12:18:41] then it sets a flag and doesn't schedule the cutoff before ignition [12:38:31] Would that still have an overburn [12:42:34] no, burns over 6 seconds don't cause overburns for us [12:42:44] not much anyway [12:42:53] it might still be a little bit when the mass is very low [12:43:11] just due to the CMC not cutting the engine off instantly [12:49:13] Hm or maybe it was just under 6 [12:50:40] could be [12:51:01] and for those 6+ seconds burns there is a padloaded parameter accounting the normal tailoff thrust [12:51:07] for* [12:51:16] we have that always set to 0 [12:52:39] Until our engines add tailoff [12:57:59] yep [12:58:20] and then we will also need to change the minimum impulse burn constants in Comanche and Artemis [12:58:55] in the LGC the tailoff behavior is hardcoded for any case, DPS and APS [12:59:12] so we kind of have to implement the right behavior at some point [13:03:35] Yeah that along with shifting COM [13:03:47] Dudnt someone do the rough math for that? [13:07:35] not sure [13:20:41] Somewhere on the old forum [13:30:37] yay, got the Apollo 11 RTACF I really wanted from UHCL [13:31:50] will help me structure the RTCC MFD right for any ascent/descent stuff [13:37:03] Apollo 11 RTACF document* [13:56:16] Oh nice! [13:59:37] I think I've made our version of the ascent simulation too "automatic" in some ways, haha [14:00:12] that is a general problem I have. On the one side I want our RTCC to be realistic. On the other hand, in the real RTCC a lot of manual steps were necessary for most calculations [14:00:22] and that doesn't really work with the MCC [14:08:54] Sounds like you have to give in to automation :P [14:09:19] partially, yeah [14:09:27] Until we get an RTCC simulation where the player performs theses steps ;) [14:09:34] These* [14:10:30] with punch cards and Chris Kraft breathing down your neck [14:11:36] for the ascent calculation I could implement it like this: [14:11:53] find liftoff time with simplified ascent simulation (reall just burn time and angle travelled) [14:12:05] simulate the ascent in detail at that time [14:12:13] update ascent parameters for liftoff processor [14:12:17] run liftoff processor again [14:12:32] you really only need to do one iteration of this and it's really accurate [14:13:45] that should be as manual as the real thing and for the MCC you just need to call: liftoff time processor, ascent simulation, liftoff time processor [14:16:42] And it would produce all the data you need, right? [14:17:10] yeah [14:17:47] I dont see any issue with that, any potential iteration fails? [14:17:53] Aka CTD [14:18:13] the ascent processor is quite new and not tested much [14:18:31] but honestly, I prefer it to fail now in some border cases [14:18:38] so I can fix it [14:18:45] so more iterations = more chance of failure [14:19:10] and that it fails to converge with one iteration is unlikely [14:19:45] it just needs updated burn time and ascent travel angle due to: liftoff mass, crossrange at liftoff and P12 target velocity [14:20:14] for the case of an Apollo 15 nominal liftoff updating that once change the liftoff time by 10 seconds [14:20:36] 10 seconds doesn't change the mass, it changes the crossrange by a tiny amount [14:20:56] insertion target also barely a change [14:21:19] in the MFD you would have two pages. The liftoff calculation page, that already exists [14:21:28] and an extra page for the ascent processor [14:21:46] there would be a button on that page to update the parameters for the liftoff time calculation [14:22:02] not a very complicated process really [14:22:32] and the ascent processor page could also generate an insertion state vector [14:22:39] And did you ever change the times based on liftoff instead of tpi time? [14:22:44] usable as an input for rendezvous calculations [14:23:09] predicted TPI time is still the main input for the liftoff time page [14:24:36] TPI time needs to be an input anyway [14:24:47] Ah ok [14:24:56] Its just a pain without an estimated tpi time [14:24:57] I have a document about the launch window and liftoff processor [14:25:27] it either takes TPI as a direct time input and calculates it for a specific longitude [14:26:04] or* [14:26:40] but the real program also takes a threshold time as an input [14:27:02] I guess earliest possible liftoff time [14:29:16] Could be [14:30:06] But i guess it doesn't matter when given a pad with the liftoff time :P [14:30:21] Oh do we have a d mission techniques doc? [14:30:23] I mean, liftoff time to TPI is roughly the same time [14:30:35] for a given rendezvous profile [14:30:53] so I could make it liftoff time as the input, and predict the launch time from that [14:31:03] I'll consider that [14:31:13] what kind of mission techniques? [14:31:39] you got us the rendezvous one, but very early and just a draft [14:32:02] we also have for Apollo 9: maneuver monitoring mission techniques [14:34:08] Something that would help with fuguring out what yaw/roll technique us [14:34:20] It still bothers me [14:34:23] me too [14:34:32] haven't found anything about it unfortunately [14:40:50] maybe it's simpler than we think [14:40:54] the checklist says [14:41:09] "roll to keep shaft axis > 10° from plane defined by X axis & LOS to LMK" [14:41:30] and if you are rolled when you want to pitch down, you also need a bit of a yaw rate [14:48:50] And the f/g techniques says roll to prevent excessive shaft rates if the landmark is too close to ground track [14:49:32] Trunnion angle should never get less thsn 10deg [15:02:18] yes [16:14:10] My thread is picking up steam even by the Dr himself [16:16:01] always a good sign [16:16:34] Feel free to chime in you probably know the docking of NASSP better than i with soft and hard dock etc [16:17:31] not super well [16:18:00] when I implemented the docking part of the SECS I quickly realized I didn't want to change much in our dockingprobe code :D [16:18:11] because it's complex [16:18:52] I don't blame you [16:22:40] I have decided to make it an earliest liftoff time input, not TPI at all for now [16:25:34] Oh nice [16:25:52] From an end user of an rtcc that is much easier [16:27:19] that's always useful feedback for me [16:27:57] Thats why ive voiced my displeasure with the tpi input for a while :P [16:28:15] But of course it needed a liftoff processor i believe to be fixed properly [16:29:16] "begin advanced docking code". Wish me luck! [16:29:21] lol [16:29:25] Haha [16:29:40] "largely lifted from atlantis" [16:29:45] the Shuttle [16:29:58] the Shuttle in Orbiter is simply Atlantis [16:30:10] Ah [16:30:14] Makes sense [16:30:30] I've read a bit of the documentation. Earliest liftoff time is an input and then it calculates the next time the CSM flies over the landing site longitude. [16:30:37] And that's the initial guess for all iterations [16:30:40] I'll set it up the same way [16:30:50] That should work pretty well [16:30:56] yeah [16:31:04] pretty close for the direct profile [16:31:10] I mean you could leave an option to calc based on tpi [16:31:13] concentric profile liftoff a few minutes later [16:31:36] But i dont know if its necessary other than experimenting [16:31:44] right [16:32:05] not sure yet [16:32:18] eventually there will be a TPI input again, because the real thing had that anyway [16:32:37] you would look in the sunrise/sunset table [16:32:41] find the right sunrise [16:32:44] subtract 23 minutes [16:32:51] and use that in the liftoff procesor for TPI [16:32:52] usually [16:32:57] Simple [16:33:12] certainly more steps than right now :D [16:33:20] Haha yeah [16:34:17] I may not know how to code it, but i am thinking we could simulate a soft undock [16:34:51] It would have to go from docked to attached, and then be able to separate without reattaching [16:34:52] yeah, simply because we already support soft docking [16:34:58] we just need to do it backwards [16:35:05] The trick is preventing redocking [16:35:10] right [16:35:13] Or reattaching [16:35:16] we have some "ignore docking" code [16:35:37] Would that prevent reattaching as well? [16:35:50] hmm, not sure [16:38:22] If we can get a way to set a zero velocity in orbiter (seems like dr s. Is up for it) and add a separation impulse locally it can work to create our own undock velocity [16:39:03] Then we can potentially get more advanced incorporating capture latches for a soft undock [16:39:33] I finally understand how it all works mechanically [16:43:39] a good start [16:45:03] Yeah i have the "models" of each situation in my mind [16:45:25] As in i know what each condition should do, but just need to be able to code it [16:46:39] What would be easier, adding a velocity or a calculated total force to split between the two in the code [16:50:15] force [16:50:33] using the AddForce function has the advantage that is goes away after one timestep [16:51:00] so you there is one timestep, in which we would cause the velocity change with a force for one timestep [16:51:05] probably the easiest to code [16:51:50] seems like Alex's lunar ascent scenario has a bit of an out-of-plane alignment error [16:51:54] Ok so i need to just compute a force from these velocity equations [16:51:58] just testing some ascents [16:52:10] Hmm post P57 fix? [16:52:14] not sure [16:52:30] I hope not [16:52:32] but otherwise the ascent is now super precise [16:52:46] even the time critical one, which I just tried for the first time [16:52:51] I know with a good alignment i got snall plane error [16:52:56] Og awesome [16:52:58] Oh [16:53:07] DV -4.9 +13.9 -2.9 for a tweak burn [16:53:55] I need to learn more about those [16:54:00] tweaks? [16:54:09] But thats a big y component id think [16:54:21] didn't trim all that much [16:54:30] Yeah [16:54:40] They fix ascent error? [16:54:43] yesterday I did a direct ascent profile [16:54:45] morning! [16:54:52] Afternoon :) [16:54:53] and got 7.5 ft/s DVY or so [16:54:56] hey Mike [16:55:01] yeah, pretty much [16:55:14] Ive never really tried one [16:55:15] they target the TPI position [16:55:24] with the LGC state vector [16:55:34] no time to incorporate any tracking [16:55:46] all they can really correct for is the APS being stronger or weaker than planned [16:55:48] Is it ground computed? [16:55:50] or bad trimming [16:55:51] yes [16:56:16] Read up and burned quick i imagine [16:56:23] yeah [16:56:31] would only be burned if more than 10 ft/s I think [16:56:37] and it's a fixed attitude burn [16:56:50] but I have to read more [16:56:56] can be easily calculated with the Lambert targeting page [16:57:02] More than 10 total or in any direction [16:57:16] I remember alex kind of explaining that to me now [16:58:03] not sure [16:58:04] Would a tweak burn be used if using ags? [16:58:33] Guess not without a reliable lgc sv [16:59:51] direct ascent profile would only be used with all systems working [17:00:03] not sure about switchover to AGS during the ascent [17:00:15] there also is the possibility of a bailout maneuver [17:00:23] switching from direct to coelliptic [17:01:30] ND-1021041 has been scanned up through page 4-28. AGC schematics should start on 4-89 [17:01:36] woo [17:01:48] so tomorrow, maybe :D [17:02:26] http://fold1.gainesville.archive.org/0/items/apollocommandmodacel/apollocommandmodacel_raw_jpg/apollocommandmodacel_raw_0159.JPG [17:02:58] the pages are in really really good shape compared to the other manuals, which is great [17:03:47] compare the title page of ND-1021042: https://ia801504.us.archive.org/BookReader/BookReaderImages.php?zip=/11/items/apollolunarexcuracel_0/apollolunarexcuracel_0_jp2.zip&file=apollolunarexcuracel_0_jp2/apollolunarexcuracel_0_0003.jp2&scale=1&rotate=0 [17:03:56] with the title page of this one: http://fold1.gainesville.archive.org/0/items/apollocommandmodacel/apollocommandmodacel_raw_jpg/apollocommandmodacel_raw_0004.JPG [17:05:49] yeah, that's certainly a difference [17:09:09] I got a Apollo 11 RTACF document from UHCL [17:09:19] First I thought it was basically the same as Apollo 10 [17:09:33] but the requirements for rendezvous stuff must be very much the same [17:09:47] alternative mission would be to fly the same rendezvous profile as 10 [17:11:26] well the Alternative Mission Plan doesn't agree with that [17:11:37] but for the mission preparation it probably didn't matter [17:11:48] they had everything in place still to refly the Apollo 10 rendezvous [17:12:20] "in lunar orbit, if the LM is NO-GO for a landing, then the alternate mission would be a DPS TEI. No rendezvous mission would be flown" [17:12:31] they really wanted a long DPS burn from Apollo 11 [17:12:42] ooooo [17:12:54] that's cool [17:14:02] yeah [17:14:05] low speed TEI [17:14:28] maybe the would ditch the LM and return faster with all that remaining CSM Delta V [17:14:32] they* [17:15:22] one alternative mission would also have DPS LOI [17:15:31] non-nominal TLI for example [17:16:25] hah, wow [17:17:00] a few days ago I did the LOI abort with DPS burn at 30 minutes after LOI ignition [17:17:06] I burned 96% of the DPS propellant [17:17:09] so that is simila [17:17:10] r [17:17:48] main difference is that the CSM was heavier [17:17:56] so I only burned 2000 ft/s, which is less than TEI [17:18:08] but still needed all the descent stage got [17:22:41] Ugh my physics is rusty, trying to figure out what this constant is in calculating alpha in the sep velocity equations [17:23:09] our code? [17:23:10] Alpha is some constant times reduced mass [17:23:12] No [17:23:16] CSM Data Book? [17:23:19] The data book [17:23:48] page? [17:23:53] 676 [17:24:44] Trying to get a force from this haha [17:25:07] 1/mass [17:25:41] but that 32.2 is suspicious [17:25:56] Thats what im trying to figure out [17:26:17] My knee jerk reaction was maybe its gravity [17:26:25] And alpha is a force? [17:26:38] https://en.wikipedia.org/wiki/Pound_(force) [17:26:46] there is a factor there [17:26:58] 1 lbf = 32.174049 ft*lb/s/s [17:27:08] Oh a conversion [17:27:12] yeha [17:27:45] So alpha is a force afterall [17:28:13] probably [17:28:56] or may an impulse [17:29:16] you want a velocity and have a mass [17:29:24] so an impulse would be the right factor for that [17:29:28] Yeah [17:31:14] Ok so we have mass and impulse [17:31:37] Need a time to integrate over [17:31:46] Thats the hard part [17:31:47] not really [17:31:57] velocity = impulse/mass [17:31:58] For a force? [17:32:52] what is V_T [17:32:58] a velocity in what unit? [17:33:23] figure 4.8-4 has some units [17:33:28] ft/s for V_alpha [17:33:33] and 1/slug for alpha [17:35:03] V_T must be ft/s then also [17:35:56] V(alpha) is just velocity in feet per second as a function of alpha in 1/slug [17:36:18] Ft/s yeah [17:36:28] doesn't really hurt to do the calculations in imperial [17:36:41] Nope just need to arrive at one number [17:37:01] input is CSM and LM mass and tunnel pressure [17:37:14] need to be converted to pounds and PSI I guess [17:37:21] then calculate alpha with that 32.2 equation [17:37:31] then V as a function of alpha [17:37:48] hmm [17:38:00] yeah, should work [17:38:21] But we want a force, right? [17:38:26] yes [17:38:41] in the end we have velocities for CSM and LM in m/s [17:38:51] I have all the math up to the velocity [17:38:53] so we need to calculate the right force for one timestpe [17:39:08] All in imperial though haha [17:39:20] in the end it's all good and in SI, haha [17:39:55] F=m*v*t [17:40:07] F is the force for AddForce, one timestep [17:40:15] m is the mass of the CSM or LM [17:40:21] v is the calculated velocity [17:40:27] t is one timestep [17:40:32] so a dt [17:40:53] uhh [17:40:55] I got that wrong [17:41:15] A is dv/dt [17:41:53] F = mass * vel / dt [17:41:58] Yes [17:42:06] that's the force for one timestep [17:42:08] however [17:42:11] good morning [17:42:13] For the tunnel [17:42:14] we need to figure out one thing [17:42:15] hey [17:42:16] Hey [17:42:27] we need to compensate for the default Orbiter 0.2 m/s [17:42:37] For now i hope [17:42:53] I'm not sure how the 0.2 m/s is applied? [17:42:57] Ideally we need to know if this is a predetemined dv or a force [17:42:58] 0.1 m/s to both vessels? [17:43:00] mass dependant? [17:43:14] you mean what Orbiter does? [17:43:18] Yes [17:43:35] Dr S said it as if it was a velocity [17:43:39] yes [17:43:43] always 0.2 m/s [17:43:44] But he coukd have bern simplifying [17:44:01] just need to know to which vessel a velocity is applied [17:44:05] both or only one [17:44:32] need to do some undocking experiments with Delta Gliders, haha [17:45:33] Yep! [17:45:59] Convenient scn all ready for that :P [17:46:22] But in addition, we need to do force for pyros and the probe [17:46:30] Pyros is 40a [17:46:40] Probe is a bit tricky [17:47:13] The data i have is it's about 5fps, and extension is 5s [17:48:11] experiment done [17:48:16] it's 0.1 m/s both [17:48:45] I docked two DGs and a third on the same position as one of them [17:48:47] then undocked [17:48:53] Ok so a constant velocity [17:49:05] yes, we knew that all along, lol [17:49:11] oh no [17:49:13] we didn't [17:49:21] could have been mass dependant, right [17:49:22] hmm [17:49:26] Yeah exactly [17:49:26] might actually still be [17:49:30] A force [17:49:35] two DGs have the same mass [17:49:40] Try shuttle docked with iss [17:49:43] yep [17:49:55] I am sure the 0.2 m/s is constant at least [17:50:02] from years of Orbiter experience [17:51:12] yep [17:51:16] 0.04 and 0.16 [17:51:21] 0.16 m/s for the Shuttle [17:51:30] I almost screwed that up, haha [17:52:16] So it divides a velocity baded on mass [17:52:21] Based [17:52:28] I mean, essentially it's the same calculation as in the CSM Data Book [17:52:39] Right [17:52:46] V = 0.2*(W1/(W1+W2)) [17:52:48] But its not a constant force [17:52:57] constant total velocity [17:53:22] V2 = 0.2*(W1/(W1+W2)) and V1 = 0.2*(W2/(W1+W2)) [17:53:38] just, an impulse being split evenly [17:53:44] Yeah [17:53:47] p = 0.2 * total mass [17:54:00] *reduced mass [17:54:10] Oh p never mind [17:54:13] yeah [17:54:18] hmm [17:54:20] so basically [17:54:42] V_LM = (V_T-0.2)*(W1/(W1+W2)) [17:54:45] or something like that [17:54:53] we can probably simply include the bias there [17:55:03] Yep i think that will work [17:55:21] But we need a force for the code right? [17:55:38] yeah [17:55:43] like we derived earlier [17:55:44] F = mass * vel / dt [17:55:54] and then AddForce [17:56:00] whatever coordinate system that is [17:56:09] I think it's body coordinates, which simplifies things [17:56:11] And then we need to add another force from the probe [17:56:33] is that a force or a resulting velocity as well? [17:56:38] force wouldn't really work [17:56:51] I have a resulting velocity [17:56:55] ah, good [17:57:06] best would be just one impulse [17:57:14] one time calling AddForce [17:57:19] Another data book has it [17:57:44] From sep 69 [17:57:57] File name is hsi 208962 [17:58:36] the one I hoped would have all the mission CMC padloads but ended up only having Apollo 12, haha [17:58:40] missing* [17:58:59] Pdf 486 if you are curious [17:59:06] Haha [18:00:03] that's based on tunnel pressure as well [18:00:07] This dv is for a given mass though [18:00:26] probably the same as with the more complicated calculation [18:00:52] Yeah im using the 0psi case just to find the probe impact [18:01:05] I assume the rest is the same math as the other [18:03:10] back in a bit [18:03:15] Ok me too actually [18:55:04] Back [19:10:30] And gone for a bit [19:57:16] Just ordered a bunch of ATMega8A's. :) [19:57:44] Gonna see if I can make my own modchip for my old Gamecube. http://www.gc-forever.com/wiki/index.php?title=XenoGC_Clone [19:59:23] that sounds quite fun [20:01:29] so you can access the GameCube debug port with that? [20:02:42] That chip patches the dvd drive's firmware on boot (it's an spi port) so it will load burned discs. [20:03:03] So I can run custom code on my gc. [20:03:24] Including Linux http://www.gc-linux.org/wiki/Main_Page [20:03:36] of course there is a GC Linux [20:04:03] It's even there for the Wii and Xbox. [20:26:22] fun fact: the gamecube's processor is a PPC 750 that is very very closely related to the RAD750 used in a lot of spacecraft [20:26:38] if it had the right operating system, it could probably run binaries from certain missions without modification [20:29:22] I didn't know that. Would definitely be worth looking at. [20:37:01] good night! [10:45:59] Good morning [10:46:27] hey [10:46:30] I found something [10:46:56] Oh? [10:47:00] apparently notes and memos some doctors who were involved with the Apollo program got [10:47:06] but it didn't just have medical stuff [10:47:15] https://utmb-ir.tdl.org/utmb-ir/handle/2152.3/9629 [10:47:24] Apollo 11 G&N Dictionary [10:47:33] I don't think we had that for 11 [10:48:31] Whoa [10:49:14] LM? [10:49:25] LM! [10:49:48] yeah [10:50:00] And it appears to have the missing pages from 12 [10:50:22] ah right, P06 and P12 [10:50:32] Yep [10:50:40] were only 2-3 pages, but still, good to have [10:50:43] P12 we had to steal from the checklist pictures :P [10:50:53] But this is great [10:51:05] and the order of things for radar tests should be interesting [10:51:18] and the extended verbs for that were differen from 11 to 12 as well [10:51:34] well, the verb commanding the LR to position 2 anyway [10:52:07] I'm not sure why a medical library would have this document, but I am not complaining [10:52:42] I was actually searching for CMP Solo Book or so and another document is a memo with a list of responsible people for each flown checklist [10:53:14] when searching for Apollo there you will find lots of medical stuff and general memos, bunch of Tindallgrams [10:53:23] And hidden gems [10:53:36] yep [10:53:47] bunch of heart rate diagrams of Jim Irwin [10:54:11] back in a bit [10:55:21] Sure [11:10:39] back [11:11:04] I think I got everything in place yesterday evening to fly Apollo 11 to PDI [11:11:15] the last PADs I had to add were the P76 PADs [11:11:42] hmm I am throwing a nullptr for return maxRows [11:11:49] Very nice [11:12:05] your checklist got too large :D [11:12:39] originally I thought the CMC would get the impulsive versions of e.g. the DOI burn. But they actually have the CMP the same TIG and DV as on the Maneuver PAD for the LM [11:12:45] gave* [11:12:57] Well what triggers that [11:13:01] no idea [11:13:06] 101:06:58 Duke: Columbia, Houston. On those P76s, a friendly reminder from your FIDO: add half the burn time to the TIG. Over. [11:13:10] Its smaller than apollo 10 [11:13:18] maybe one specific checklist? [11:13:32] not the whole document [11:13:35] Is it additive? [11:13:38] maxRows in one [11:13:53] additive? [11:14:04] whole file* [11:14:28] yes [11:14:39] Or is it only a max in a sheet [11:14:55] I would think in one of the sheets, but not sure [11:15:16] hmm [11:15:24] no, I think the issue is different actually [11:15:26] Well my longest is 746, which is actually shorter than 10 and 11 [11:15:34] if maxRows is a null pointer, then it didn't find any rows [11:15:39] Uhh [11:15:53] Maybe I need to remove the checklist state from the scn [11:15:58] so either an empty sheet or the name of one is wrong in the first sheet [11:16:00] Could be confused [11:16:09] Oh yeah let me check the names [11:16:24] yeah, maybe it remembered the state of a checklist that doesn't exist in that way anymore [11:18:08] Thats what i am betting on [11:20:35] Yep [11:20:47] Or not [11:20:50] Hmm [11:20:54] lol [11:21:16] the Checklist MFD indeed doesn't like it when you mess with the checklist sheets too much [11:22:57] I just have to delete the container right? [11:25:57] I think so, yeah [11:27:03] Now it ctd when I click the mfd [11:28:32] bad [11:28:38] I am confused! [11:28:59] try an completely empty scenario? [11:29:09] Just to see if the Checklist MFD file as a whole in good or broken [11:29:18] morning! [11:29:55] Yeah good call [11:30:39] Right now I get this error [11:31:01] An exception thrown [11:31:01] //Heading [11:31:02] if (strlen(grp->heading) > 0) { [11:31:02] if (grpcnt != 0) [11:31:22] Maybe I deleted too much? Haha let me try a new one [11:31:41] hey Alex [11:31:51] Oh wow [11:31:56] I know whats up [11:32:02] I updated the beta [11:32:09] And the module is disabled [11:32:10] AlexB_88, I have a few things for you [11:32:23] sure [11:32:30] first [11:32:31] https://utmb-ir.tdl.org/utmb-ir/handle/2152.3/9629 [11:32:35] Apollo 11 LM G&N Dictionary [11:32:46] nice [11:33:04] and remember tweak burns for the short rendezvous profile? [11:33:08] please enable the project apollo mfd on the launchpad [11:33:20] sounds useful to do Ryan :D [11:33:24] forget about needing tweak burns [11:33:25] Its not there though [11:33:41] rebuild NASSP [11:33:55] I did [11:33:58] it needs to link to the Orbiter API [11:34:08] which always changes (I think) when there is an Orbiter update [11:34:32] I will try again though [11:34:39] AlexB_88, lunar liftoff targeting has changed [11:34:55] tested it with your Apollo 15 lunar ascent scenario [11:35:03] input is now earliest liftoff time, not TPI time [11:35:05] indy91, oh cool [11:35:17] and new is a lunar ascent processor page [11:35:27] properly simulated ascent from liftoff to insertion [11:35:42] great! [11:35:42] and it can update some parameters that are used in the liftoff calculation [11:35:49] so you can do this: [11:35:54] calculate liftoff time [11:36:01] go to ascent page and simulate an ascent [11:36:07] that updates two parameters [11:36:18] and then go back to the liftoff page and recalculate [11:36:30] now you have a very precise liftoff time solution [11:36:37] less than 10 ft/s tweak burns [11:36:42] and most of that was out-of-plane [11:36:49] due to alignment issues maybe [11:37:22] I believe this is the realistic RTCC procedure [11:37:25] but I liked doing tweak burns :( [11:37:29] kidding :D [11:37:50] liftoff time processor uses assumptions for ascent burntime and angle travelled [11:38:03] ascent processor just simulates one specific ascent [11:38:11] so in combination you can get very accurate ascents [11:38:18] insertion time was on the second [11:39:24] and in the future I want the insertion state vector, calculated by the ascent processor, to be usable for rendezvous pages [11:40:13] all a result on working on the Apollo 11 MCC [11:40:15] Damn same error on a new one [11:41:45] the null pointer? [11:41:54] what about the scenario? [11:42:14] does the ascent processor also provide proper VI and HDOT inputs for P12? [11:42:54] No the exception thrown [11:43:20] no, it just simulates an ascent with given liftoff time, and horizontal and vertical velocity [11:43:55] they get calculated by the liftoff page though [11:44:07] ah ok [11:44:12] uses 32 ft/s fixed for HDOT for the direct profile [11:44:37] and 0 ft/s for the time critical one [11:44:41] the resulting velocities for the concentric profile might need work [11:46:24] in the RTCC documents even V HOR and V VERT are inputs for the liftoff processor [11:46:37] not sure how they were generate [11:46:38] d [11:46:43] maybe manually tweaked [11:47:54] rcflyinghokie, so where do you think is the problem? NASSP build or Checklist MFD file? [11:48:16] Its in the file I am 99% sure [11:48:27] I am betting its a name mismatch somewhere [11:48:44] So its on my end, don't worry :P [11:48:47] I will find it [11:48:59] ok [11:49:34] have to go until the evening. Alex, maybe you can play around with the new liftoff and ascent stuff [11:49:42] you are so good at finding bugs :D [11:50:19] cya later! [11:50:24] Later [12:10:33] So I cannot figure out what got broken [12:10:47] I reverted my last copy which had one change [12:10:50] And it works [12:11:09] Added that change to my current local, still broken, as far as I can see they are identical [12:11:20] So I think I might have a bad excel file? I dont know haha [12:12:19] weird [12:12:53] Yeah I am at a loss they are identical from what I can see contents wise [12:13:00] So I am reverting and using the one that works :P [12:13:48] So Nik and I have been talking a lot about undocking dV's [12:14:27] I have calculated (more or less) the forces that would be applied for a normal undock, additional force from any residual tunnel pressure, and pyro separation forces [12:15:01] All we need to do is compensate for orbiters default dV for undocking and then have NASSP code add the proper forces based on mass and tunnel pressure [12:15:27] The catalyst for this was I wanted to see if the extra dV from residual tunnel pressure will make Eagle land long [12:18:02] right [12:18:29] but there was a SV update performed after undocking, wasnt there? [12:20:47] I don't think so [12:21:33] Oh I stand corrected [12:21:49] It was a DOI -10 one though [12:22:00] So it wasnt a current SV is was a propogated one [12:22:57] Which i am betting was calculated on the CSM/LM SV [12:23:16] yeah [12:23:38] they may not have had time to use radar tracking data to make a fresh SV [12:23:48] Yeah looks like it was uplinked right after AOS [12:24:36] The thing is though that in NASSP there is no way to simulate that less accurate SV I dont think, as when you do a SV update, its always a perfect SV [12:25:13] so the only way would be to omit that SV update after undocking I guess, to simulate the error [12:27:24] Or through MCC, use the CSM SV and propagate it [12:28:12] Which is probably what was really done [12:28:40] Used what they had for the current CSM/LM SV and computed it for DOI-10 and shipped it up [12:28:58] That would allow for undocking error to creep in [12:29:54] hmm I see [12:30:54] so did they just totally forget that there was an undocking DV imparted or did they expect there to be an error? [12:32:38] Well they may have compensated for the probe [12:32:42] I dont know [12:32:59] But the tunnel pressure would have given both vehicles a slightly different path than the current SV [12:34:06] And there was apparently residual pressure in 11 because of a procedural error of not leaving the tunnel in vent after venting [13:37:16] Ugh and here comes the media blaming flight sims for the Q400 crash in seattle [13:37:46] https://www.wsj.com/articles/flight-simulator-enthusiasts-confident-of-real-world-skills-1534446556 [14:45:14] probably the Majestic Q400 [14:45:25] I fly I Q in the rw [14:45:31] a Q* [14:45:55] not a very complicated aircraft to start lol [14:46:57] No it isnt [14:47:05] Turboprop with FADEC [14:47:34] I have a good amount of time in the majestic as well haha [14:47:43] Never been on a real one though [14:48:18] its literally just flip the 4 bat switches on and engine selector, start, fuel on at 1st sign of NH [14:48:37] of course we always start on external power [14:52:05] Theres no APU right? [14:54:14] there is [14:54:50] Its been a while haha [14:57:30] I used to know those systems well when I was simming a lot more [14:57:38] I think I know the LM better now [14:59:44] haha yeah [15:00:01] Not that I am complaining or anything [15:00:09] I have to say thought the Majestic Q400 is very realistic, compared to the real thing [15:00:18] especially the flight dynamics [15:00:27] Yeah all the Dash8 pilots I know say the same [15:00:43] Same with the PMDG side of the house [15:01:45] Looks like a few more stuck uplink lights in the CM [15:02:09] hmm weird [15:02:42] I dont think Nik figured out the other one either [15:03:19] .tell indy91 I have another stuck uplink light on the uplink at 187:30 (t align and SV with V66) [15:03:36] He said everything looked normal [15:03:51] And it uplinks fine, just the light stays on [15:04:03] A P00 clears it [15:04:10] And the P27 completes [15:04:13] So its not hung [15:07:22] Funny the last hung uplink was when it was given with a t align pad as well [15:07:31] or stuck light rather [15:13:44] Yikes looks like me when i am at work :P [15:13:53] Connect disconnect connect disconnect :P [15:15:15] haha actually all the Q talk made me fire up FSX to do a circuit with the MJC Q400. However my PC decided to go haywire right when it was loading [15:15:55] Oh yikes [15:16:07] I actually am considering reinstalling my Q and my 73 and 777 [15:16:23] I just got DCS hornet too which is pretty awesome but still missing a lot [15:16:46] I need a better stick/throttle setup for it frankly [15:16:53] Ah, right [15:17:12] In college I was a regular VATSIMmer [15:17:26] I was a P5 instructor and all that jazz haha [15:17:29] The machine I have been playing around with lately is the old dodosim Bell Jet Ranger [15:17:40] nice! [15:18:01] Oh how is that? [15:18:23] I have a little real helo time in a R22 and B47-G2 [15:18:25] Its quite good, I knew about it for a long time but only actually bought it last week [15:18:47] Havent quite found a good helo sim, then again I dont own any DCS helos [15:18:48] nice, I have yet to fly in a real helo [15:19:18] If you do, try not to train in an R22 [15:19:27] really? [15:19:35] Think blades carry such little inertia that auto rotations are downright dangerous [15:19:42] Personal opinion :P [15:19:43] right [15:19:47] Thin* [15:20:21] I was fortunate to get some training in a B47 that is an awesome bird [15:20:36] Bell 47 I guess is the right name [15:21:23] I dont know much about helos, but from what is said the dodosim simulates all the dynamics extremely well [15:21:56] Its very hard to fly, compared to the default 206 [15:22:42] And do you know what is to blame with my recent helicopter fascination? [15:22:54] The LM of course :p [15:23:07] Haha! [15:23:24] Yeah especially hovering [15:23:30] Balancing on a column of lift [15:23:34] Or thrust [15:23:39] But its funny because the LM is easier [15:24:21] at least compared to hovering with the dodosim 206 [15:24:25] No aerodynamic problems [15:24:42] yeah, and in the LM you have quite a lot of computer assistance [15:24:53] Simple thrust vs gravity [15:25:00] right [15:25:37] And if your engine quits you pop the stage off ;) [15:26:16] haha yeah [15:26:18] but I will definitely do my helicopter PPL, and I can credit some fixed wing time towards it, which is nice [15:26:24] Yeah you can [15:26:37] If its similar to FAA of course [15:27:07] Of course here if I have a commercial fixed wing license, I would get to skip helo PPL [15:27:13] I would train to commercial standards [15:27:38] And a lot of fixed wing time counts towards that as well [15:28:08] Hmm that may be the same in Canada, ill have to check [15:28:14] I think it would be [15:28:34] I think its 60 hours instead of 100 required, for the helo CPL [15:28:46] if you have a fixed wing CPL [15:29:28] Yeah there are usually a bunch of breaks [15:29:38] To prevent excessive overlap [15:30:13] yeah [15:30:20] We call them "add on" ratings here [15:34:13] Woo Day 10 of Apollo 9 :) [15:34:17] Almost done! [15:34:42] I just added all the DAP orbital rate procedures and landmark tracking in the checklists [15:34:48] And they work [15:43:41] .tell indy91 same with 211:28 uplink, maybe has to do with them coming with the t align pad? [15:47:58] Are you still flying 9? [15:49:58] yeah, but not very fast lol I have been working all week [15:50:06] Ill try and carry on tonight [15:50:33] morning! [15:51:52] I know the feeling [15:52:02] Working from home today gives me a chance to finish :P [15:52:13] Hey Mike, how goes scanning :P [15:52:23] still in progress! [15:52:37] she's nearing the end of this first volume [15:52:39] Like everything else with this project :P [15:52:45] which means almost all of the NOR logic has been scanned [15:52:50] Oh nice, excited? [15:53:21] http://fold1.gainesville.archive.org/0/items/apollocommandmodacel/apollocommandmodacel_raw_jpg/apollocommandmodacel_raw_0478.JPG [15:53:23] extremely [15:53:29] this binder is in way better shape than all the rest [15:53:33] which is incredibly lucky [15:54:34] Oh wow [15:54:45] Its not even that faded [15:57:49] back in a few hours! [16:03:15] yeah it's great [16:03:25] and scanning complete [16:03:32] now it's just processing, and should be online later today :D [16:05:05] .indy91, also something with landmark tracking, they seem to be out of order was that intentional? in other words, the top part of the pad is after the bottom part time wise [16:05:14] .tell indy91, also something with landmark tracking, they seem to be out of order was that intentional? in other words, the top part of the pad is after the bottom part time wise [16:22:13] At least the DAP orb rate works [17:45:43] back [17:45:52] Haha [17:45:55] Sorry for the flood [17:45:56] bye [17:46:05] Good answer [17:46:07] "Yep nope" [17:46:15] yeah, I don't really have a good explanation for those [17:46:22] the uplink string looks right [17:46:29] Yeah its working fine, just odd [17:46:49] But not the landmark tracking, but the S065 [17:46:54] They seem out of order [17:47:13] The top landmark is tracked like an hour after the one below on the same pad if that makes sense [17:47:16] top left, top right, bottom left, bottom right [17:47:24] oh [17:47:25] hmm [17:47:35] Yeah only on the second to last update I believe it was [17:47:38] that could be it finding a tracking on the wrong revolution [17:47:52] I'll check [17:47:54] Ok [17:48:01] might have to adjust the estimated time there [17:48:03] I should have screenshotted it but I forgot [17:48:22] which area was it for? [17:49:09] Again i should have screen shotted it I'll go back and find out [17:49:43] update at 146:05? [17:50:34] that's a landmark tracking PAD with 4 entries [17:51:09] No it was S065 [17:56:20] Here it is [17:56:27] Uplink at 213:50 [17:56:45] https://www.dropbox.com/s/pp3ybgkzsmj3a30/Screenshot%202018-08-17%2013.56.35.png?dl=0 [17:57:05] Also a curious thing I have noticed, every time I load a save on 9 it starts at a FOV of 56 [17:57:36] Unless I am scrolling the mousewheel before saving or something, which is possible [17:57:50] But yeah thats the uplink in question [18:02:14] there is a bit of weird code with saving FOVs I believe [18:02:21] have to look into that [18:02:43] wait, wait. There is an uplink issue and there is a PAD having a wrong time issue [18:02:51] Which one has the wrong time now? [18:03:06] Two different things [18:03:10] yeah [18:03:12] The uplink light is trivial [18:03:14] ah I see, Mozambique [18:03:25] But thats the uplink with seemingly backwards times [18:04:10] uplink? [18:05:08] second to last S065 PAD [18:05:12] hmm [18:05:19] the baseline time there is 214:40 actually [18:05:50] I'm really surprised it finds 215:50 [18:05:58] I believe that's a rev too late actually [18:06:03] Update, not uplink [18:06:06] ah [18:06:12] Sorry poor worrd choice [18:06:13] yeah, so as per flight plan [18:06:27] there would be one at about 215:40 [18:06:33] But other than that they work well with orb rate [18:06:40] that's when they did photos of Wilmington, North Carolina or so [18:06:51] 214:40* [18:06:53] 214 [18:07:03] and then about 215:05 in Africa [18:07:34] so it found the first time on that PAD one rev too late [18:07:39] Ah [18:07:39] Mozambique is about right [18:09:46] I guess I'll just use an earlier initial time there [18:09:52] 10 minutes earlier should be enough [18:13:14] now the uplink thing [18:13:19] The light? [18:13:21] yeah [18:13:34] do you get it with any state vector update? [18:14:10] No its only the ones that some with a t-align [18:14:13] come [18:14:20] So 3 I believe [18:14:34] No idea if its a coincidence or what [18:15:45] well you had one before I implemented the SV updates with the T-Align [18:19:07] ah, was it the one T-Align update that already has a SV update in the flight plan? [18:19:26] Yes [18:19:34] we added them to the others as well, because there would have been only one per day [18:19:42] so there is one common thing then [18:19:47] Right thats why it stuck out [18:19:59] it's what I call a "generic" PAD [18:20:05] basically just a line of text [18:20:13] maybe it has to do with that [18:20:21] let's see... [18:21:21] Speaking of that light, do you remember why it comes on during P20 sometimes? [18:21:56] oh yeah, that is a feature, right? [18:22:10] when it's out of tracking attitude or so [18:22:16] it wants a V58 then [18:23:05] hmm, no [18:23:13] only in the CMC maybe? [18:25:15] yeah, that's how it works in the CMC [18:25:26] if you are 10° away from the normal tracking attitude [18:25:38] that what gives you an uplink light [18:25:53] then a V58 and it recalculates the attitude and gives you a 50 18 for it [18:26:24] Ah ok [18:26:39] I am trying to track the LM [18:27:26] maybe the required attitude rate is so quick that it can't keep up [18:30:21] It was when i started now its settled down [18:30:25] But I did it early [18:30:31] oh [18:30:42] uplink light doesn't stay on if I remove the V66 uplink [18:31:15] Really [18:32:38] Its tracking but I cannot visually make it out :/ [18:33:23] I mean, it's unlikely that it would be the closest at the same time as during the actual mission [18:33:59] Well we are on almost the same position wrt earth on our orbits [18:34:57] https://www.dropbox.com/s/kxizm4wuy3rbok9/Apollo%209%20MCC%20-%20LM%20Track%200001%200002.scn?dl=0 [18:35:37] I believe it [18:35:51] maybe they just got closer [18:36:09] and visual range was better in real life anyway [18:36:20] they could see their ascent stage on Apollo 10 as well [18:42:33] Ah oh well would have been nice [18:43:48] I'll leave it up until when they tracked the LM maybe I will catcha glimpse [18:43:57] I still am a little early [18:50:40] Still tracking with no light [18:50:45] But I still cant see :P [18:51:02] LM will be in darkness soon [18:53:08] stil don't know why, but the V66 is indeed causing the stuck uplink light [18:53:18] I justed put the V66 at the end of the uplink string [18:53:25] maybe it doesn't like that for some reason [18:53:39] I wonder if it's a speed thing [18:53:47] I'll try slowing down the uplink quite a bit [18:54:07] hmm [18:54:14] I wonder if the V66 turns the light on again [18:54:21] because P27 is basically done [18:54:26] V33ed and all [18:56:04] It might turn it on but not turn it off? [18:56:27] yep [18:56:37] did the uplink very slowly [18:56:45] light was off after the uplinked V66 [18:57:00] V33* [18:57:02] and then it became on again with the V66 [18:57:28] so I might just have to do something different with that [18:57:32] Ah [18:57:44] Is it because the V66 is last? [18:57:53] yeah [18:58:27] for maneuver updates the order is usually CSM state vector, V66, target load [18:58:43] so I guess the question is how to properly uplink V66 [18:58:54] maybe add a V37E 00E? [18:59:09] Any idea how it was done? [18:59:25] The V33 goes to P00 right? [18:59:41] So maybe you do need it uplinked as a V37E 00E [19:00:04] I've never been really sure about the V33 in P27 [19:00:12] I think it causes a check on the validity of the uplink [19:00:21] and turns off the light and goes to P00 [19:00:50] technically the V33 is just a proceed [19:00:55] Ah [19:01:03] ah right, haha [19:01:07] you can't uplink PRO [19:01:09] that's why :D [19:01:25] no uplink code for that [19:01:27] I never knew that [19:01:37] PRO was more of an afterthought [19:04:02] Oh fun fact I am on retrofire day [19:04:06] woo [19:04:22] Finally [19:04:32] I never did figure out why the checklist failed [19:04:38] damn [19:04:40] I reverted to my last copy [19:04:44] Which had 2 small changes [19:04:49] Added them in [19:04:52] And still no problem [19:05:08] I think I may have had a corrupt save on the file itself, I did get a weird error last tie I saved [19:05:11] time* [19:05:28] But I reverted, added back the changes that reverted and no problem [19:05:32] So I dont know [19:05:42] hope you didn't loose much [19:05:58] No thats just it [19:06:04] It was literally just 2 things [19:06:28] Putting the DAP orbital rate group in for the S065 [19:06:41] And adding a switch after LM docking [19:07:00] So idk [19:07:06] thewonderidiot, what turns the uplink light on and off? [19:07:24] a switch :P [19:07:31] lol [19:07:37] I'll see myself out [19:07:45] I dunno, some code :P [19:07:50] I bet [19:07:53] Ah I guess Mike is coming with me [19:08:23] But yeah it seems to stick on after uplinking a V66 [19:08:30] to NARA, shame scanning [19:09:50] but yeah, uplinking just a V66 seems to turn on the uplink light, but not turn it off again [19:10:51] Is it just that though? Uplinking a literal V66? [19:11:00] Or is there some other way they commanded a V66 [19:11:29] probably literal V66, but maybe plus something else, like a V37E 00E [19:13:27] I dont see the harm in adding that [19:17:24] seems to do the trick [19:20:58] Good [19:21:10] Now lets see how this retrofire does [19:22:16] oh, already at deorbit prep? [19:22:39] Yep [19:22:47] Got through the last S065s today [19:22:57] The timing for orb rate is like perfect [19:23:11] Ordeal is right on zero [19:23:39] yeah, who needs Artemis universal tracking anyway [19:23:50] Us lazy ones :P [19:23:51] trajectory wise deorbit worked great for me. Burn was close to apogee, as desired, and gise you plenty of time before EI [19:24:03] gives* [19:24:41] having the attitude constraint to pointing at the horizon for the burn was once again uselss, because the burn is in darkness [19:24:59] Haha of course [19:25:09] at least reentry itself is not in darkness [19:25:22] not easy to have both of those things in daylight [19:25:38] Need an interesting orbit [19:25:48] and like one deorbit opportunitiy per day [19:26:39] Oh I dont know what causes this, but I have noticed my option 1 p52s always have huge torquing angles [19:26:59] Is that because of the shutdown and startup of the system? [19:27:02] maybe your attitude rate while the NO ATT light is on is not 0? [19:27:26] Ah [19:27:31] That explains it [19:27:36] yeah, quite normal [19:27:39] Ok [19:27:53] main advantage of the pulse torquing option they added for the next mission [19:27:58] Makes sense [19:37:20] Waiting for T-1h [19:41:57] once P52 comes up with the new attitude for the IMU actually [19:42:20] that is the new attitude it's going to give you, so it doesn't account for any drift after that calculation [19:42:38] Ah so all that lag time in between any drift is now error [19:42:43] to reduce that you could do a V32 to let it recalculate that attitude and then quickly do PRO to let it torque [19:42:49] yep [19:42:54] True [19:43:00] or coarse align rather [19:43:27] but as long as the star is still in the sextant it shouldn't be a big issue [19:44:52] Now I see that pulse torque significance :) [19:45:04] no coarse align mode drift [19:45:06] has disadvantages too [19:45:14] takes longer [19:45:26] and it's not protected against gimbal lock actually [19:45:48] Oh it can torque you through it? [19:45:52] yep [19:45:54] OUch [19:46:02] so you need to be careful with your initial attitude [19:46:18] Yeah [19:46:19] I think that's why Mike Collins disliked that feature [19:46:30] He also wanted 4 gimbals [19:46:39] that would help, yes [19:46:49] they let the crew sleep longer because MCC-4 got scrubbed [19:47:02] and that kind of messed up the attitude timeline [19:47:04] Hm the RCS CMD transfer switch seems to hold up but not down [19:47:25] hmm [19:47:26] I assume thats the little delay added to the switch in code [19:47:39] to hold it momentarily [19:47:52] it does for up (CM) but its super quick for down (SM) [19:48:20] hmm [19:48:24] it has the delay time thing [19:48:46] interesting [19:48:59] watching the auto checklist hit it, it held up on cm for a little [19:49:08] but when it did SM, it was like instantaneous [19:49:40] did you add a delay in the checklist as well? [19:49:49] No [19:49:53] Just checked [19:50:27] should be the same for any switch position, but I'm not sure [19:50:56] Maybe I observed wrong idk [19:51:08] trivial thing though [19:51:18] ok maneuvering for deorbit [19:51:23] as long as the right relays were energized [19:51:29] Yeah they were [19:51:37] I held it in SM and CM after to be sure [19:52:20] retro refsmmat should have 180 180 0 burn attitude, right? [19:52:59] yes [19:53:04] Ok good [19:53:24] Maneuvering to that now [19:53:33] no Maneuver PAD yet? [19:53:58] No i have it [19:54:02] I was just confirming the angles [19:54:05] ok [19:54:19] Been a minute since I have done a retro burn in LEO [19:54:30] right [19:54:30] gives the astronauts more of a "burning backwards" feeling, haha [19:54:42] Yeah makes sense [19:55:11] also makes it not be a backwards REFSMMAT like the SPS-6 (?) one that made the different orb rate procedure necessary [19:55:52] Yep [19:58:35] Are you still thinking of adding ullage to remarks? [19:58:58] sure [19:59:13] I could use the same ones from the read up PADs [19:59:19] or calculate it dynamically [19:59:25] Should be pretty close [19:59:26] but I'm not sure about the 2 vs. 4 jets logic [19:59:32] Ah yeah [19:59:41] Might be best to stick to the flight plan then [19:59:54] Or use the jet logic from them and calculate times based on that [20:00:31] How did they determine that though, like using which quads for a 2 jet, fuel? [20:01:52] probably [20:02:00] balance it out [20:02:49] Thats what i have been doing [20:03:30] I have been better also switching between AC and BD roll for the same reason [20:04:03] it was much worse with the old moments of inertia [20:04:20] I did most of the planned activites during TLC on my Apollo 15 flight [20:04:34] Haha low RCS in LO [20:05:00] yeah [20:05:02] I remember how much I used with the LM during TLC and LOI as well [20:05:09] down to 50% already after LOI or something crazy [20:05:28] I am just below 50 right now [20:06:02] 46 48 47 45 about [20:06:22] only a bit below the flight plan [20:06:40] it has 50% for B and D at the end of mission [20:06:58] 52-53% or so for A and C [20:06:59] Yeah I did a few expensive manual maneuvers I am sure [20:07:15] good enough for SM RCS deorbit [20:07:18] impatient with V49 rates :P [20:07:39] haha, same [20:07:40] Though I could have just DAP'd a higher rate but still [20:07:47] More work than manual [20:08:23] And I am sure I burned some extra during LM ops, I left it in P20 for a while haha [20:08:40] SM RCS deorbit, one rev after nominal DV [20:08:42] But then again, it probably was on par with what was actually used [20:08:45] deorbit, not DV [20:08:52] How much DV [20:08:56] even your SM RCS should be enough for that [20:08:58] 100 ft/s or so [20:09:41] that isn't supported in the MCC though, haha [20:09:44] This SPS is 291 [20:09:54] yeah, because it's burning lots of DVZ [20:10:00] Yes it is [20:10:13] the usual amount for the nominal deorbit attitude [20:10:13] 229 [20:10:24] FP was 235 [20:10:26] total [20:10:42] 229 is your total? [20:11:14] 229 dvz [20:11:25] I am 291 total [20:11:43] -180 0 +229 [20:11:58] the FP had 235 is the total dV [20:12:30] T-60s [20:13:04] not sure what document is more accurate about that [20:13:12] another one says 320 ft/s for nominal SPS deorbit [20:13:43] one rev later would be even lower DV, but that was reserved for SM RCS or hybrid deorbits [20:14:14] actual was also 322 ft/s [20:17:24] Ok I am atmosphere bound [20:19:21] Am i expecting a postburn PAD [20:19:33] blunt end forward please [20:19:43] postburn PAD is given at CM/SM sep [20:19:55] was just an convenient event to trigger that PAD [20:20:08] Ah ok [20:21:11] So this first P61 I am running I am comparing with the first entry update? [20:22:20] Which would make sense haha [20:22:52] Interesting FC1 went off scale high triggered a MA but no CW light [20:23:33] Is CM/SM sep time based on anything or should I use FP time? [20:23:48] FP time would be bad [20:24:01] unless your deorbit TIG is really close to the flight plan [20:24:45] Haha [20:25:09] Less than 3 minutes difference [20:25:40] I thought I had a read a time somewhere [20:25:43] What should I use though, burn time plus x time? [20:25:53] like, wait until 12 minutes before EI before CM/SM sep [20:28:06] Ok [20:30:54] So what is my entry attitude [20:31:04] PAD had a pitch [20:31:07] rest 0° [20:31:33] So I am rolling 180 after sep? [20:31:58] yeah [20:32:04] Ok [20:32:20] And that puts me blunt in forward :) [20:32:24] end* [20:32:53] about 62°? [20:33:37] no [20:33:54] 35 [20:34:17] should be right [20:35:06] I have a lift vector down light [20:35:18] normal [20:35:24] don't trust it for Earth orbit entries [20:35:42] Again not used to them haha thanks [20:35:53] Letting CMC do the work [20:37:08] Spending a lot of time 90 degrees [20:37:34] don't need a lot of lift down or up then [20:37:41] Ah [20:38:02] "Disregard corridor lamps for entry from earth orbit (entry velocity <35K fps)" is what the AOH says [20:38:43] those lights are purely for SCS controlled, high speed entries, where you need to make the correct, split second decision about lift vector up or down [20:38:43] Consider them ignored [20:41:05] guess I need to set up some scenarios with the 32 types of training runs for Earth orbit reentries :D [20:43:20] That would be fun, and challenging [20:43:49] yeah [20:44:08] unfortunate that we don't have a good system for setting up scenarios like that [20:44:24] for the most part you simply need to fly scenarios to the right state [20:45:34] Yeah [20:46:22] Hm were both rings enabled before the propellant dump? [20:47:42] propellant valves, probably yes [20:48:09] Ok [20:49:22] I think the propellant dump switch also opens interconnect valves between the two CM RCS systems [20:49:52] but with the propellant valves for one system closed, only half of the thrusters would be burning and it would take twice as long [20:50:15] Ok I will open them before the dump [20:51:06] I think this entry procedure needs work [20:51:12] I wish I had a better reference [20:52:03] we lots of of references [20:52:06] all different [20:52:14] Yes [20:52:28] This one is mostly stolen from your Apollo 7 I believe [20:52:51] then it probably needs work, yes [20:53:33] Yeah haha [20:53:44] Well I have a good save right before deorbit [20:53:52] And the checklists are done and PR'd to that point [20:56:47] and merged [20:57:46] Well hard part is over [20:58:10] Entry will need work for sure, but should be manageable [20:58:24] But the orbital rate and landmark tracking work nicely I am happy with the flow [20:58:50] Entry will be tweaked tomorrow hopefully I can start 11 and come behind you [20:58:51] great [20:59:13] my PADs are printed, Apollo 11 flown to shortly before wakeup on PDI day [20:59:23] Anything unusual or glaring in the 11 checklist you have noticed to this point? [20:59:30] not that I remember [20:59:39] I'll take it [20:59:46] back [20:59:50] Hey [20:59:56] wb [21:00:10] 9 is all done up to entry [21:00:18] nice [21:00:19] So if you find anything let me know [21:00:25] I need to play with entry and clean it up [21:00:29] and now to continue my Apollo 9 [21:00:34] Where are you? [21:01:17] not very far, about to burn SPS-3 [21:02:00] How are the checklists flowing with the MCC? [21:02:11] lets see my hand flying skills lol [21:02:42] Oh the MTVC [21:02:44] rcflyinghokie, pretty good so far I find [21:02:48] Great [21:02:49] yes haha [21:03:08] Well if anyone can find my errors its you :) So let me know! [21:03:42] yes will do! [21:03:44] Coming soon to a maneuver PAD near you...ullage instructions :) [21:03:52] I already have 2 pages full [21:04:02] ;) just kidding [21:04:10] I honestly wouldnt be surprised! [21:04:16] Its so easy to overlook things [21:04:50] indy91, I did find a small error in the SPS-2 pad I think [21:05:11] the pitch trim came out as +1.16 [21:05:31] so about that [21:05:36] when it should be in the area of +0.66 or so I think [21:05:42] DTO says to bias that by 0.5° [21:05:48] oh [21:05:52] to get some attitude rates going, haha [21:05:58] oh lol [21:05:58] not sure if that was done during the actual mission though [21:07:01] interesting for sure, now I wish I had used that value to see the effect [21:08:11] I think I did, it wasnt much of a transient [21:08:20] SPS corrected quickly [21:08:25] But I do remember the lurch [21:14:39] Ah have to download the DCS beta again [21:14:52] I want to play with the hornet haha [21:29:40] AlexB_88, any chance yet testing lunar ascents? [21:30:16] did you have* [21:31:36] no not yet really, I have checked out the new RTCC MFD function but I need to understand the procedure better [21:32:09] ok [21:32:38] to get good accuracy it's basically just: lunar liftoff calc, lunar ascent calc, lunar liftoff calc [21:33:16] anyway, good night! [12:19:57] Good morning [12:20:30] hey [12:21:27] Do we have an entry summary for 9 by chance? [12:34:58] I dont have one on my end [12:35:47] Me either, I am trying to guess my way through this 9 entry [12:49:26] well there are procedures for eath orbit re-entry from other missions [12:50:54] Yeah [12:51:00] maybe you could use the entry summary document from Apollo 7 [12:51:18] That would help, have a link by chance? [12:52:49] https://www.dropbox.com/s/v1lz07ezklvh7vd/19700025002_CHECKLISTS.pdf?dl=0 [12:54:05] I am currently using the apollo 8 entry checklist as a guide coupled with the transcript [12:56:16] I seem to be pretty on par with that as well [12:57:44] I think the Apollo 14 Launch checklist would be good as well, it has a whole section on earth orbit entry prep/SPS deorbit [12:57:51] Apollo 15* [12:59:11] I am trying to be careful going too far ahead, but yeah I will reference it of course [12:59:31] The 8 deorbit checklist seems to be working well for me so far [13:00:25] I am so used to lunar entries that LEO entries are not as fresh [13:01:41] right, but the Apollo 8 checklist is a lunar re-entry whereas the Apollo 15 one despite being a bit further down is an actual earth orbit entry procedure, which may be more what we want in the case of Apollo 9 [13:03:38] But if its working good for you as you say then maybe thats good enough after all haha [13:03:44] No the apollo 8 entry checklist has a full leo entry procedure [13:03:54] Both for hybrid and sps [13:04:00] ooh [13:04:23] So I figure that might be closer to actual [13:04:56] my bad, I did not see that at all, indeed it does [13:06:01] Im sure the Apollo 8 LEO entry checklist is good enough yeah [13:06:46] :P [13:57:36] alright time for the burn [14:08:13] Go MTVC! [14:08:23] I made the mistake of using a numpad for it [14:09:03] haha [14:09:25] even with a joystick its hard [14:10:42] True [14:10:50] What kills me is the deadband [14:10:59] I wish you could set one [14:32:46] good afternoon [14:39:55] hey Niklas [14:40:13] just about to fly SPS-4 [14:40:29] but maybe I can 1st try out the new lunar ascent targeting [14:42:08] do what you want, I've tested two ascents myself, so I don't think it would be causing CTDs or so [14:42:59] I also restructured the liftoff calculations internally, so that it can calculate the DVs of each burn [14:44:23] the output and displays are now the same as from the actual processor [14:44:56] except that you could input an array of DHs and it would return multiple solutions [14:45:15] so a launch window with the acceptable range of DHs [14:45:19] usually +/- 5NM [14:48:23] so when calculating an ascent from scratch with say, Apollo 15, do I 1st have to find the desired TPI time, with that TPI search function in the RTCC MFD? [14:50:35] the liftoff page still does that [14:51:02] based on the liftoff time you input as the threshold time [14:51:07] I mean to get the TPI time at exactly sunrise minus 16 mins [14:51:23] oh, short profile [14:51:28] hmm [14:51:37] I mean, that's not really possible [14:51:58] all you can really do is adjust the DT between insertion to TPI [14:52:04] that is 44 minutes for Apollo 15 [14:52:13] you could adjust that time [14:52:23] right [14:52:28] and calculate the right TPI time on the DKI page first [14:52:30] so that works like before is what I mean [14:52:35] and then adjust accordingly [14:52:42] yeah [14:53:05] so once I have the lunar liftoff page done, what does the lunar ascent page do? [14:53:16] it simulates a lunar ascent in detail [14:53:28] like, full P12 guidance equations with 2 seconds timestep detail [14:53:50] that results in very accurate burn time of the ascent and also the travel angle between liftoff and insertion [14:54:06] so do I have to change anything on that page? [14:54:11] nope [14:54:16] just hit calc [14:54:20] the burn data (TIG, V HOR and V VERT) will have been copied over from the liftoff page [14:54:25] ok [14:54:26] yeah [14:54:37] and then it updates those two numbers on that page [14:54:44] which in turn get used on the liftoff page [14:54:51] and then I go back to the liftoff page and calc again? [14:54:52] the initial numbers there were just bad estimates [14:54:54] yep [14:55:09] wait which 2 numbers? [14:55:19] the two displayed on the ascent page [14:55:22] a time and an angle [14:55:32] no manual input for those yet [14:55:40] it just starts with the estimated numbers [14:55:59] those that were previously always used by the liftoff calculation internally [14:56:06] but there was no way to make them really precise [14:56:52] with precise numbers, the liftoff time will change by about 10 seconds, depends on the ascent parameters really [14:57:34] I had one iteration where the liftoff page did all this automatically [14:57:40] but that just wouldn't be realistic [14:58:16] simplified ascent calculation for the liftoff time and the full ascent simulation are just two different things [14:58:37] makes sense [14:59:13] does this work with calculating a T2 or T3 abort before PDI? [14:59:56] T3 abort is a normal concentric rendezvous I believe [15:00:56] and no, the T2 abort can't really be calculated in the MFD yet [15:01:21] also because I don't fully understand how they calculated e.g. an updated T2 time [15:01:26] right [15:01:40] did Apollo 11 get a T2 time update before PDI? [15:01:45] yeah [15:02:19] but I guess the pre-flight estimate should be ok [15:02:44] yeah, that's what I am using right now for the MCC [15:03:08] plus an ascent simulation with the default P12 parameters [15:03:21] and on the PAD all you get is the T2 time and the time for the phasing maneuver [15:03:30] which is simply apolune after insertion I believe [15:03:57] ok, and CSI1 time and TPI time [15:04:06] but those are easy to get as well [15:04:22] but what we don't have yet is something to calculate that whole procedure [15:05:19] probably with the DKI [15:05:28] right [15:05:30] but it first has ascent and a phasing maneuver of 10 ft/s [15:05:42] and only then the first DKI maneuver [15:06:24] it does look very DKI-ish [15:06:35] CSI1 would be the initial DKI maneuver [15:06:44] calculated on the ground or with P32 plus chart [15:07:09] changing the T2 only would change the total DV of the rendezvous [15:07:18] maybe they optimized that through changing the T2? [15:07:53] but what I probably will do is that you can use the insertion SV from the ascent page as an input SV for the DKI page [15:08:01] and that page needs to be able to handle the different sequence [15:08:31] sounds more like a task for a mission planning or rendezvous planning table [15:08:51] which I certainly want to implement [15:09:18] you would set it to planning mode and calculating any maneuver would add the maneuver to a sequence of maneuvers [15:09:26] and any new calculation would use the most recent SV [15:09:34] so you could do a whole plan for e.g. a rendezvous [15:09:55] I really like the sound of that [15:10:28] I would have to make a bunch of calculation pages compatible, but that shouldn't be so bad [15:10:43] they would need to process input and output SVs [15:10:57] and there would be a button on each page to transfer the maneuver to the mission planning table [15:11:12] that should be a pretty realistic process [15:11:24] yeah [15:12:13] oh, and one other thing. I got the Apollo 11 RTACF support plan from UHCL [15:12:31] and, we knew this already, but it confirms what the No PDI+12 was calculated with [15:13:13] it cryptically calls it "two-impulse to CDH offset maneuver sequence" [15:13:44] maneuver a. LM phase and height adjustment maneuver (two-impulse and terminal phase processor) [15:14:12] so yeah, it's indeed the two-impulse processor with offsets [15:18:02] whatever offsets those were, lol [15:18:06] 15NM is clear [15:18:24] and a phase angle that gives a nominal CDH to TPI time [15:18:25] or so [15:18:52] do you remember what number we came up with? [15:19:00] it was something quite even [15:19:04] like 4.0°? [15:19:18] for the short profile it's in the mission rules, haha [15:23:14] 4.7 I think [15:23:54] hmm but I maybe be confusing that with the 1.7 for the short profile lol [15:25:04] 1.69° actually, according to the mission rules [15:25:29] did you have the tweak burn calculation ready in the RTCC MFD in your Apollo 15 lunar ascent scenario? [15:25:55] so that you just needed to press calculate [15:26:03] I had it ready before liftoff yes, but I dont know if it was done by that quicksave [15:26:07] yes [15:26:20] I preloaded the TIG with insertion time from RTCC MFD + 2 mins [15:26:24] yeah [15:26:28] good thinking [15:27:07] or else you have to do the whole tweak calculation within 2 minutes after insertion, lol [15:27:14] yeah [15:27:25] impressive that they managed that during the real mission [15:27:51] but they did it the same way, just quickly input the state vector of the LM and hit calculate [15:35:27] morning! [15:35:31] hey [15:40:40] AlexB_88, is the HAM maneuver in the DKI sequence always nominally 0? I forgot, lol [15:42:36] pretty sure it is [15:45:31] hmm then again maybe not [15:47:12] btw, tweak burn is VX 0.2 VZ 4.1 [15:47:48] awesome [15:51:05] VY was -10.9 but thats another story ;) [15:52:10] yeah [15:58:29] I am struggling so hard right now with the temptation to start making a block 1 hardware sim [15:59:56] more is different from Block 2 than I was expecting [16:01:24] haha [16:01:37] how far are the scans? [16:03:22] volume 1 is done [16:03:27] just not uploaded yet [16:03:33] it includes everything but the memory and dsky [16:03:42] not bad [16:04:27] no missing pages, as far as I can tell, and all of the foldouts are in fantastic shape [16:04:36] Is our EMS Backup functional? [16:04:44] I am noticing the entry checklists usually use it [16:05:40] yes, it's functional [16:06:01] predicted 0.05G time is tricky to get accurate for Earth orbit entries [16:06:11] maybe that's why it gets used [16:06:38] so that range is still accurate [16:08:16] Ah ok [16:36:01] Ok testing this improved deorbit/entry checklist :) [16:44:48] Do i get an EI time from any of these PAD's? [16:46:22] interestingly not [16:46:28] just time from retrofire to 0.05G [16:46:56] so your event timer should be 0 at deorbit TIG [16:47:15] and isn't reset afterwards [16:48:28] and that RET 0.05G value determines if you need to go to EMS backup [16:49:15] Hmm so i wonder what was the time for say CM RCS preheating [16:49:46] I usually see it as an EI time [16:50:15] I guess I can make it based on TIG [16:50:26] yeah [16:50:36] Apollo 7 Entry Summary Document says 1 hour before TIG [16:50:46] Ok [16:55:05] don't look at that document too much though [16:55:35] it easily erases the Colossus nouns you had remembered [16:55:55] damn Sundisk [16:56:13] and its (my guess) Block I compatible nouns [17:02:38] Oh I am not dont worry [17:02:53] I am mostly using the apollo 8 checklist [17:29:23] Was CM/SM sep attitude just retro attitude +45 deg yaw? [17:38:02] yes [18:01:11] OK I think I have a working checklist for this finally :) [18:01:28] great [18:01:39] With that, I am off to get some (free) DA42 time [18:01:54] I will fly this once more tonight before I PR it [18:01:57] later [18:06:34] ok enough looking at chopper cockpit videos on youtube, time to fly SPS-4 [18:07:57] and I finally get to start PDI day for Apollo 11 [18:08:53] oh nice [18:09:25] of course I don't have everything 100% in place [18:09:35] abort constant calculation still needed for example [18:09:44] right\ [18:09:48] but I have the beginning of that in place [18:09:56] the ascent simulation is actually part of that [18:10:00] Is that even possible to get updated [18:10:02] oh I see [18:10:30] updated values were uplinked [18:10:32] oh man so it could be easy to create them for all missions in that case [18:10:35] and read up for the AGS I guess [18:10:58] Powered Descent Abort Program of the RTCC [18:11:01] I have documentation for it [18:11:19] and you will be able to dynamically update it once a page has been added to the RTCC MFD [18:11:34] right [18:11:38] just annyoing that Apollo 11 uses very different abort constants [18:11:48] hello, abort from PDI-2 :) [18:11:57] yeah, for example [18:12:15] different addresses? [18:12:27] very different concept [18:12:39] Apollo 11 uses a polynomial for the horizontal velocity [18:12:46] variable being time since PDI [18:12:52] right, it doesnt have the 2 parts [18:12:56] yeah [18:13:01] it does have two polynomials though [18:13:10] one if you use P70, one P71 [18:13:35] it chooses which one is used at the abort [18:13:52] so pressing abort (P70) and not much later abort stage (P71) could throw it off [18:14:12] in fact there is a bunch of talk in documentation about a tweak burn [18:14:25] if you keep the descent stage all the way back into orbit or so [18:14:38] I guess the abort constants are not calculated for that scenario [18:14:41] not quite sure [18:15:46] Apollo 12 and later use the two parts [18:16:00] and only need 3 constants for the abort [18:16:07] no, 5 [18:16:23] insertion semi-major axis as a function of phase angle to the CSM [18:16:38] and that in two segments, with the 5th constant being the switchover phase angle [18:17:00] more flexible in a way [18:17:32] and for that (Apollo 12 and later) I have a whole flowchart of the RTCC processor used [18:17:46] it just needs full guidance equations simulation of ascent and descent, haha [18:19:19] but wasnt 12 also only one part, and you had to do a tweak burn if you do a late abort? [18:19:47] oh wait thats with AGS [18:20:03] yeah, FP6 isn't compatible with that [18:20:15] there is a chart for that [18:20:24] I think only 13 and later AGS can do the 2 parts [18:21:29] yep [18:21:33] FP7 and later [18:21:57] and I think we've made 13 use FP8 [18:22:21] yeah, I think so too [18:22:23] oh about that [18:22:27] RR updates [18:22:29] for the AGS [18:22:43] are you sure you had a the PCM bitrate switch in high? [18:22:47] yes [18:22:50] hmm [18:22:56] it was the 1st thing I checked [18:33:28] has it worked for you? [18:37:12] I haven't tried it much [18:37:16] or ever [18:37:31] I'm activating Eagle right now [18:37:40] that Eagle doesn't have such fancy features :D [18:41:46] fancy features that dont work... sounds like my buddy's car [18:42:50] fancy features that don't work reliably... so still your buddy's car [18:43:44] yeah lol [19:03:23] indy91, did you want to know my SPS-4 burn details? [19:08:56] sure [19:09:08] SPS-4 was pretty standard, right? [19:09:16] no MTVC etc [19:20:07] no MTVC [19:20:43] VX: -1.3 VY -259.5 VZ 0 [19:21:00] all 3 burns went very well [19:21:08] well 4, so far [19:22:23] good [19:22:31] I have to compare the DVs with the actual mission [19:24:12] the burn calculation should be very realistic now [19:24:22] the only thing I am not 100% about is the TIG [19:24:31] it should be really close in any case [19:25:45] also, do the block datas take into account upcoming burns? [19:26:23] no, probably not yet [19:26:26] they should though [19:27:00] shouldn't be super difficult to implement, but I haven't gotten around to it yet [19:29:23] sounds good [19:32:25] They probably dont all need to be changed anyway, so far only block data 3 pad has that issue as it is right before SPS-2,3,4 [19:37:03] also sort of related, I am thinking of finally making a CSM panel for proper orientation of the 31.7 line [19:37:16] that would be great [19:37:46] the Block Data PADs do the same calculation as the normal deorbit calculations, so they should be quite trustworthy [19:39:42] Im thinking of having it to the left of the normal CSM left rendezvous window [19:40:08] and then maybe the 31.7° line centered? [19:40:15] that would make things easier [19:40:26] sure [19:40:55] and then I can also make the Entry PAD check for the right attitude [19:41:03] so from the normal left rendezvous panel you hit CTRL-LEFT to access a zoomed-in view which centers on that line [19:41:08] I really should have done that already [19:41:16] sounds good [19:41:55] I guess its just a question of making the view orientation right [19:42:08] or literally making it 31.7 if its centered [19:42:37] just pitched up 31.7° and the line at the center of the view would be my suggestion [19:42:49] right [19:42:59] should be very easy to do [19:43:12] Ill do that next week I think [19:43:55] as in, the week starting tomorrow [19:43:56] great [19:44:09] and then some manual retrofires, haha [19:44:52] I guess we can finally have the right pitch value for the horizon check too [19:45:14] for the lunar returns [19:45:15] yeah, that's what I meant with the Entry PAD [19:45:25] ight [19:45:27] and even now that should have the right attitude rather than one we can use [19:45:29] right [19:45:41] I question my past decision setting it up that way, haha [19:46:00] lol [19:46:04] well it worked [19:48:22] I just dont understand how they could see the horizon in darkness [19:49:09] maybe in RL the horizon is sort of visible at night from orbit [19:50:17] I'm not sure they were able to see it [19:50:21] when it was dark [19:50:30] but you would not see any stars [19:50:38] where the Earth is in the way [19:50:46] and you probably can usually see a lot of stars [19:50:49] so I don't know [19:53:23] yeah [19:54:32] we have a few "views from the spacecraft" documents [19:55:11] I wonder if they say anything about this [19:57:43] not really, just that part of the entry is in darkness, for Apollo 11 [20:36:44] night! [20:57:37] Good night! [11:59:20] morning [12:00:41] Good morning [12:00:53] hey Ryan [12:01:05] Finally through with 9 :) [12:01:32] great [12:01:42] Now to start 11 [12:02:32] So yeah Alex you should have at least adequate checklists for the rest of your 9 flight :) [12:02:45] hey guys [12:02:48] awesome [12:02:51] hey [12:02:58] Morning [12:03:08] I'm through with all the PDI PADs, yay [12:03:10] so many... [12:03:56] one interesting thing about time tagged state vectors [12:04:11] CMC and LGC both got a CSM state vector for PDI+25 minutes [12:04:18] but that time is still more than 2 hours away [12:04:33] so everything is very slow, because it has to propagate the state vector backwards [12:04:38] P20 slow, V83 slow, V47 slow, haha [12:05:11] Ouch [12:07:43] at least it should be very accurate for PDI and later [12:07:49] and also not so slow by then [12:08:06] yeah [12:08:41] and was there a LM SV update on the final REV before PDI? [12:09:13] nope [12:09:27] last LM SV update the LGC got is more than an hour before DOI [12:09:35] time tagged DOI-10 minutes [12:11:05] ah right [12:12:33] rcflyinghokie, also is the Apollo 11 LM timeline book that we got recently now integrated in the 11 checklists? [12:12:48] No [12:13:07] I plan on integrating it this run [12:13:18] great [12:14:28] oh, it's not? [12:14:33] good that you tell me, lol [12:14:50] not even the flag reset etc? [12:16:12] Hmm I may have gone back and added that [12:16:27] Its all a blur honestly [12:16:28] but I guess I'll follow the LM Timeline Book now [12:16:32] haha, no problem [12:18:15] AlexB_88, for the No PDI+12, I finally settled on the value of -4.47° phase angle [12:18:25] Yeah I may have added that reset but I didnt integrate the timeline book so yeah follow it :) [12:19:09] nice [12:20:00] gives very close to 40 minutes between CDH and TPI [12:24:22] woo, +000.01 P52 in the LM [12:24:40] show off :D [12:25:33] if I manage that in P57, then I'm a show off [12:26:05] me its the other way around, I get good P57s but horrible P52s lol [12:26:46] those good P57 with 10 ft/s out of plane error? :D [12:27:31] I average 00001 00002 with P52s in the LM [12:27:42] But P57's I have not tried since the "fix" [12:28:15] I will quite soon [12:28:22] or I could fly a No PDI + 12 [12:28:26] or a T2 abort [12:28:27] or a T3 abort [12:28:30] or a CSM rescue [12:28:41] or I could land on the Moon [12:28:43] lol yeah. I found that it was more accurate the lower the star was in the sky [12:33:04] 10 minutes to DOI. One thing I want to implement for the MCC, just as a placeholder for now, is maneuver evaluation [12:33:21] so it looks at the state vector before and after a burn and determines if the burns was good or burned at all [12:33:29] and then schedule an abort sequence or so [12:34:16] Ok time to light this candle and catch up to Nik :) [12:34:50] please don't catch up [12:34:53] haha [12:35:14] Well thats what you said for 9 and look what happened [12:35:19] I was on rendezvous forever [12:36:17] the only reason I wasn't stuck on the LM activation and abort stuff for much longer, is because everything through DOI had already been done for Apollo 10 [12:36:39] oh, and I haven't implemented the abort constants calculation yet [12:37:48] Well i am thinking I will catch up quick because everything up to where you are I also have in a checklists somewhere [12:37:56] But we shall see [12:39:08] indy91, I like the sound of that maneuver evaluation thing [12:41:00] shouldn't be so difficult [12:47:51] it would be fun to purposely screw up a burn into an odd orbit and see what kind of abort the MCC comes up with :) [12:49:02] usually a CSM rescue then [12:49:25] there are two partial DOI cases [12:49:38] DOI < 25 ft/s burned and >= 25 ft/s burned [12:49:46] those would be the first screw up [12:49:49] ups [12:51:05] hence then need to evaluate the maneuver [12:51:08] the* [12:51:35] DOI >25 sounds like a potential impact [12:52:25] an overburn might need an immediate response, yeah [12:52:31] of course DOI is like 75 ft/s long [12:52:40] so DOI > 25 is 25 to 75 ft/s burned [12:53:21] both cases need the rescue 2 sequence [12:53:46] with rescue maneuver (ground or chart calculated), 2-3 CSIs and then normal rendezvous [12:57:03] DOI overburn, hmm [12:57:19] you probably would want to switch to the other guidance system and null the residuals [12:57:42] and then wait what MCC-H has to say about it [12:58:58] Yeah you are LOS as well [12:59:26] Punch up V82 and hope your perilune is high enough [13:02:07] DOI Data Card has the manual shut down criteria [13:11:06] punch in V82 and hope theres no countdown [13:14:51] to what does it count down in lunar orbit? [13:16:53] 35k feet apparently [13:16:58] yeah, that's a bit low for DOI [13:23:20] Is the waste stowage valve connected to anything right now? [13:28:45] don't think so [13:29:59] ok, this PDI+25 state vector is no good [13:29:59] I was experimenting with adding nitrogen to the atmosphere [13:30:10] it's about to screw up my DOI, because V83 isn't getting done [13:30:35] Just need a way to purge the cabin to 60/40 after the hatch is closed [13:30:54] But that can be later :P [13:31:19] I'll leave the calculations in the config commented out till I get to that [13:31:36] But I have a normal O2 N2 atmosphere in testing and it looks good [13:32:26] yep, I am post TIG [13:32:32] damn [13:32:40] Uh oh [13:33:12] it just won't work with a CSM state vector that is still 90 minutes away [13:33:31] each time it has to use that permanent state vector for anything it has to do 90 minutes of orbital integration [13:33:40] and that just takes too long for this timeline to work [13:34:39] So did it not take as long in reality? [13:35:11] it probably would have, but I am doubting they uplinked a PDI+25 minutes SV for the CSM [13:36:35] that's just too far away [13:38:44] hmm [13:38:54] or maybe they did some trickery [13:39:09] accurate state vector for PDI+25 [13:39:24] then backwards propagated with a simulated AGC orbital integration [13:39:42] that way you could uplink a state vector time tagged "now" that will be accurate in a while [13:41:14] Hmm [13:41:19] Interesting theory [13:41:26] yeah [13:41:31] It would work I believe but it seems a bit odd [13:41:43] yeah, it seems odd [13:43:03] it could be done though [13:43:20] I am using the same equations as the AGC, just with the accuracy (timestep) parameter turned up [13:49:41] so you just have calculate it at the requested time, then propagate it back to the current time at the original AGC accuracy setting I guess [13:52:36] that would be the plan, yeah [13:52:43] still trying to find a source on that [14:10:31] ok, it is technically posible to follow the timeline [14:10:34] but barely [14:11:17] sme guy on the forums is getting that old issue where the Saturn1B sits crooked on the pad [14:11:39] My theory is that he somehow installed an older version [14:11:44] of NAASP [14:11:49] NASSP* [14:12:07] Maybe ven tried running NASSP 7 in Orbiter 2016 [14:15:06] Hmm i got two threads back to back, is this normal? SV and TLI 90 [14:15:12] In other words both triggered at the same time [14:15:19] yep, normal [14:15:23] ok [14:15:33] I've splitted up the TLI simulation and subsequence TLI+90 Abort PAD calculation [14:15:39] just weird to see "thread started thread completed thread started thread completed" [14:15:48] yeah [14:15:59] maybe I can hide that message for certain calculations [14:16:01] or any really [14:16:09] it is more of a debugging tool [14:18:31] I like the message honestly [14:18:35] Lets me know its working [14:18:56] Ok so I get the SV and TLI+90 at 1h30 [14:19:00] When do I get the other two? [14:19:09] maybe it could be changed to something other then thread started and thread completed [14:19:26] rcflyinghokie, just shortly after [14:19:41] Looking for a time for the checklist mfd [14:19:41] 3 or 5 minutes is what I usually use for multiple PADs in a row [14:19:58] Ok I will see when it comes up [14:20:07] 5 minutes from first to second PAD [14:20:14] 3 minutes from P37 PAD to TLI PAD [14:20:27] Um is it based on the uplink? [14:20:35] yeah [14:20:38] when that is done [14:20:38] Ah ok [14:20:50] so you have enough time to monitor the uplink and then write down the PAD [14:20:54] Right [14:25:32] if you have a better idea how to handle the schedule of uplinks and PADs, let me know [14:25:33] I am doing my own cabin purge through the press eq valve to see how the nitrogen behaves as a side experiment [14:25:35] it's certainly not ideal [14:26:00] Yeah the timing isnt bad, though what I would do is have the SV uplink by itself [14:26:06] sometimes you get the feeling mission control is letting you wait, haha [14:26:10] And then have the next three pads at fixed times [14:26:27] And i can define those in the checklist mfd so they are expected [14:26:36] could be done, yeah [14:26:57] That way it isnt uplink dependent [14:26:58] would only work before TLI though [14:27:10] Yeah like 1h30 uplink sv [14:27:14] because you are never 100% following the flight plan later on [14:27:26] 1h35 TLI 90 [14:27:32] etc [14:27:43] Yeah [14:28:13] But I have it following the current implementation for now shouldnt be an issue [14:29:25] yeah, I've set up those Earth orbit PADs a bit more flexible than before, so it can be done this way [14:31:39] the second opportunity should also be supported [14:32:02] haven't tested it yet, but it's looking at the LVDC to determine if it has switched to the second set of TLI targeting parameters [14:32:30] and would give you new PADs at 3h GET or so [14:33:10] Oh nice [14:34:27] nice [14:35:32] On my Apollo 11 run I will "accidently" have the XLUNAR switch at safe for the 1st opp TLI [14:35:53] so I will give that a good testing :) [14:35:58] Haha [14:36:13] How Houston would miss that on TM though... [14:37:04] "Uhh 11 this is Houston, confirm XLUNAR INJECT to INJECT" [14:38:05] "but I want to fly over my house just once more, pretty please?" [14:38:28] haha [14:38:37] Sounds like a Pete Conrad retort [14:38:53] now that I am looking at the code... [14:39:03] there could be some small issues still with the 2nd TLI [14:39:12] well, if my house were somewhere in the southern states of course [14:41:06] I'm sure they will let you use the SIVB to get into that orbit ;) [14:42:59] out of plane LOX dump to raise the inclination? [14:45:56] Think that will have enough dV? [14:46:02] probably not [14:46:11] Then light the J2! [14:46:19] or some JATOs [14:52:36] Oh Ignition has a great chapter on JATO propellant :) [14:53:05] morning! [14:53:06] Awesome, albeit extremely technical book, it pushed my chemistry knowledge as well [14:54:04] Its funny I accidently made a hypergol as an undergrad with RFNA and synthetic gasoline :P he describes that as one of the early ideas for JATOs [14:54:18] hahaha [14:54:29] Good morning [14:54:36] (and this case it actually is for me) [14:54:45] for once! [14:57:24] hey Mike [14:58:26] 10 minutes to PDI. Have to go for a while, hopefully will get to fly the landing in the evening. [15:00:16] Is it normal for the PAD TB6 to be off? [15:04:07] up to 8 seconds [15:04:39] Ok [15:04:47] So 4 wasnt bad [15:05:26] shouldn't be, yeah [15:10:36] And off we go! [15:10:42] Coming to catch up with you :) [15:16:29] 2:50 I got another TLI pad? [15:33:25] you sure it's a new one? [15:33:55] what's the mission state? [15:34:16] 21 [15:34:36] Right at 2h50m I got a thread started thread completed and TLI message [15:34:52] The PAD didnt change though [15:35:49] the thread started/completed probably was the TLI evaluation [15:36:09] so, maybe there is a bug with updates that have neither PADs nor uplinks [15:36:20] maybe it triggered the PAD auto show [15:37:03] Well I had my pad up for TLI already [15:37:23] And it didnt change so probably just the TLI evaluation thread as you said [15:37:31] However it did occur while I was still burning [15:37:53] So if it is supposed to evaluate post TLI, it came too early [15:38:26] interesting [15:38:29] a few seconds too late? [15:38:55] the TLI time in the MCC should be at cutoff [15:39:04] Yeah it came up when i had a few seconds of burn left [15:39:54] right now it's only evaluating a LVDC flag, which is set at TB6 start [15:40:03] but yeah, maybe it needs adjusting [15:40:40] Actually that 4 second difference sounds about right [15:40:47] The time between the pad TB6 and my actual [15:40:55] Probably the same time between that thread and ECO [15:41:12] oh [15:41:14] good point [15:41:31] in the future it should be evaluating dispersed TLIs as well [15:41:37] so maybe set the time a bit later [15:41:47] 8 seconds later for the LVDC navigation cycle [15:42:05] and TLI is defined (in LVDC terms) as cutoff signal plus 10 seconds anyway [15:42:16] when the thrust has 100% decayed [15:42:28] so maybe maybe it predicted TLI plus 18 seconds [15:42:32] maybe make* [15:42:33] Could be [15:42:39] Could work* [15:42:44] but the auto show is weird [15:42:59] you didn't have the TLI PAD up? [15:43:03] No i did already [15:43:14] oh [15:43:15] well then [15:43:32] I just thought it was a new pad, as I am used to that from thread started [15:43:37] right [15:43:50] just another case of me using a PAD-less and uplink-less update, which leads to confusion, haha [15:43:59] Haha yep [15:44:15] Well either way it helped find a potential time problem [15:44:37] yeah, I am adding that 18 seconds [15:45:02] Will that have any effect on my current mission? [15:45:19] no, not at all [15:45:36] I'm doing it like this: if (rtcc->calcParams.TLI + 18.0) [15:45:51] the RTCC internal TLI time stays as the predicted cutoff [15:46:02] which is the base time for certain calculations [15:46:17] Ok [15:46:29] I am going to pick up Eagle [15:47:19] the next new thing MCC wise will be the alternative sequence for MCC-1 scrubbed [15:47:41] that's the next PAD and uplinkless update [15:48:16] MCC-1 scrubbed sequence uplinks the PTC REFSMMAT early [15:48:30] and just a state vector at the time of the MCC-1 update [15:48:43] so you can do that with one of your PRO/FAIL checklists [15:49:54] Yeah pretty simple [15:50:04] Similar to Apollo 10 [15:52:37] are the LM optics parameters saved and loaded? [15:52:40] like detent [15:53:02] almost seems to me like that is missing [15:54:21] I dont believe so [15:54:49] seems like a simple overshight [15:54:59] and nobody poked me about it :D [15:55:05] good morning [15:55:15] Because it was an oversight for us end users as well :P [15:55:21] Hey good morning [15:55:37] And Columbia and Eagle are one :P [15:56:00] hey [15:56:12] my Columbia and Eagle are very much not one [15:56:53] what about DPS propellant vent? [15:57:13] I know about the RR test not being fully realistic yet [15:57:25] yep [15:57:58] /TBD: Vent Helium and Oxidizer [15:58:02] / TBD: Vent Helium and Fuel [15:58:08] so no, not done yet [15:58:18] guess I'll implement a simple first iteration of that [15:58:39] so more smoke effects I guess? [15:58:53] you can do that if you want, haha [15:58:59] I'm just getting rid of the prop [16:04:37] By the way, the cabin purges N2 nicely [16:04:49] I am cheating and purging through the press eq valve [16:05:11] This would of course be done through waste stowage when implemented [16:05:42] But the purging itself works well my N2 level has dropped significantly and no ill effects on anything ECS wise [16:06:03] pp CO2, cabin press and temp all normal [16:09:16] great [16:09:18] So I can implement cabin purging as long as I figure out a way to purge the cabin to 60/40 on the pad, and then implement the waste stowage valve [16:09:28] First part will be tricky [16:10:01] GSE connected to a port on the hatch pumping o2 I guess [16:10:13] And cutting off when the ratio is 60/40? [16:10:29] From there the cabin purge is easy [16:10:54] But anyways, back to 11, when do I get my evasive maneuver pad? [16:11:13] Supposed to be 4h [16:11:33] rtcc->calcParams.TLI + 3600.0 + 10.0*60.0 [16:12:35] so roughly at 4h [16:13:17] I can always adjust it a bit [16:13:22] 5 minutes earlier or later [16:13:22] 4:11 no pad [16:13:29] what's your mission state? [16:13:49] Still 21 [16:14:10] sub state? [16:14:13] 0 or 1 [16:14:20] 2 [16:14:29] can't be [16:14:33] And this time I didnt do any moving of states [16:14:38] you must have [16:14:41] Nope [16:14:47] there is no substate 2 in that state [16:15:17] do decrement substate [16:15:27] something must have changed it to 2 [16:15:33] https://www.dropbox.com/s/h6estodefili55d/Screenshot%202018-08-19%2012.15.24.png?dl=0 [16:15:45] Looks like it changed right after the state changed [16:16:17] yeah [16:16:27] But this time I didnt touch any debug options [16:16:30] setSubState(1); [16:16:37] it does this right after changing to that state [16:16:47] so that it changes to the next substate immediately is right [16:16:59] But this means it changed to 2 right after [16:17:14] yes [16:17:41] oh, hmm [16:17:48] there is a missing "break;" in that code [16:17:51] what would that do... [16:18:16] advance the state? [16:18:18] substate* [16:18:35] I have a pre TLI save I will see if it does it again [16:18:49] it would probably also call the next state [16:18:57] which already is the evasive maneuver [16:19:08] however, it already would have substate 1 [16:20:01] and substate 1 of a "PAD only" update calls setSubState(2); [16:20:04] all my fault then [16:20:14] missing "break" for a switch [16:20:20] So thats why [16:20:53] Good I didnt mess it up :P [16:20:57] haha, yeah [16:21:04] wasn't there something like this before? [16:21:10] I believe so [16:21:11] where you were sure you didn't touch anything [16:21:13] Apollo 9? [16:21:15] Yeah [16:21:22] Or was it 10 [16:21:23] any idea at what GET? [16:21:28] No idea haha [16:21:33] but I'll check anyway [16:21:35] But I do remember this happening before [16:21:42] could just be the same issue [16:21:50] Yeah I remember it was in state 2 [16:22:17] 9 or 10? What is your guess [16:22:52] I doubt that it is 9 [16:23:02] only one similar thing in that MCC sequence and it's right [16:23:37] 10 looks good as well [16:23:42] maybe it was a different issue [16:23:52] It was 10 for the APS pad, but I did increase it a step [16:23:59] ok [16:24:01] According to IRC logs :P [16:24:05] haha [16:24:15] I made you believe it was your fault [16:24:29] But yeah that one I advanced a state and screwed it up [16:24:37] Ended up in a state that cant exist [16:24:58] ah right [16:24:59] now I remember [16:25:02] 10 indeed [16:25:08] Yeah [16:25:16] That was my bad, this one, not so much :P [16:25:38] So in the mean time, should I decrease the substate? [16:25:38] correct [16:25:41] yes [16:25:46] that shoud fix it [16:26:17] Ah thats what confused me before, it did say you can has PAD when the TLI evaluation came up [16:26:29] So i thought a new pad came up [16:27:15] xyes [16:27:41] that was the message for the evasive maneuver PAD [16:27:45] in substate 1 [16:27:50] without ever having calculated it [16:28:17] then it switched to substate 2 [16:28:30] which in the first of the two executed states didn't do anything [16:28:49] and in the evasive maneuver update it just waited on the next state [16:29:20] So i have to wait until after the evasive maneuver pad time to decrease the substate? [16:29:26] Because its just back on 2 again [16:32:50] Ill just increase the state [16:35:12] Still bumping me to substate 2 [16:36:03] Maybe I should just add the fix haha [16:36:08] Its all sorts of confused [16:36:43] https://www.dropbox.com/s/gtoz197u40cwuu1/Apollo%2011%20MCC%20-%20LM%20Ejection.scn?dl=0 [16:36:49] If it helps, I will be back in a bit [16:39:40] off to work, later! [16:50:10] yeah, it could be that it won't work without the fix [16:50:19] let me quickly get a push together [16:52:44] pushed [17:02:07] Thanks I will see if it works :P [17:03:21] you probably still have to do the decrement substate [17:03:26] but this time it should do something [17:03:32] Yeah but this time it will not go to 2 and stick [17:04:02] first check if the state is 21 or 22 [17:04:07] I will give this a whirl then I need to go to the store [17:04:09] Sure [17:04:13] BUilding now [17:04:29] if it for some reason has gone to 22, you just need to do reset state [17:04:50] and then all should be good again [17:07:11] Its 21 [17:07:19] So decrease substate? [17:07:34] yeah [17:07:47] Now on 21 1 [17:07:56] Seems happy [17:07:56] what GET? [17:07:59] 3:36 [17:08:03] ah, ok [17:08:15] so, as expected, the PAD should be at around 4h [17:08:22] I will run it forward to see when the pad shows up [17:10:39] And voila [17:10:41] All good [17:11:16] Now to the store, thanks! [17:11:16] great [17:11:24] catch ya later [17:11:27] cya [18:32:06] the Eagle has landed [18:33:28] \o/ [19:33:01] looking ahead, I have a bunch of new things to implement for the RTCC, haha [19:39:56] Such as? [19:41:27] Ascent PAD [19:41:57] has a bunch of AGS variables that I need to understand [19:42:04] Haha I can help with that [19:42:31] I got to know those pretty well when hunting down those AGS failures from before [19:42:53] tell me about the azimuth [19:43:00] stored as sine and cosine [19:43:15] and in addition to that there is an optional octal increment? [19:43:51] Which address? [19:44:28] 47/53? [19:46:54] Because I think I was asking you about those before haha, I dont know those as well [19:47:42] and 547 [19:47:58] thats the correction in octal [19:48:07] Which I have no idea how to utilize :P [19:48:17] I just remember what it was defined as haha [19:48:27] have to look at the equations [19:48:30] Yeah [19:48:34] At least we have them [19:49:27] RTACF has a big Lunar Surface Align display [19:49:55] the addresses 047 and 053 are among them [19:50:47] and you also would be able to let MCC-H calculate a new azimuth from an AOT sighting [19:51:09] Was that done for 11? [19:51:15] so an alignment from scratch with a failed PGNS [19:51:20] not nominally I think [19:52:25] well I found the calculation the AGS uses when it stores the azimuth [19:52:43] an euler angle from rotation matrix calculation [19:53:15] I guess it's all a geometry excercise [19:54:17] oh fun [19:54:47] you scared astronauthen away with the mention of Euler geometry [19:55:14] probably [19:55:22] he should never look at the RTCC MFD code then [19:56:19] but I do want to add to that even more [19:56:36] there are lots of support calculation done by the RTCC and RTACF [19:57:10] so that CAPCOM is always quick to come up with some e.g. pointing angles [20:03:54] Yeah its crazy how fast those seem to be able to be read up [20:04:01] and supporting AGS AOT alignments would be great anyway [20:07:30] Ok time for the evasive [20:20:23] good night! [12:02:32] Good morning [12:02:37] hey [12:02:47] getting good P57s [12:02:54] and a 90°F LM cabin [12:06:11] Irc client fail [12:07:01] did you get my messages? [12:11:03] Nope [12:11:12] I said morning and my client crashed [12:12:23] getting good P57s [12:12:25] and a 90°F LM cabin [12:12:55] Yeah its the heat exchanger code [12:13:25] Ive noticed that if suit temp is closed it heats [12:13:30] And open it cools [12:13:46] Because the glycol there is cooler than the air [12:14:18] at least we know the source of that [12:14:19] But also the flood lights still put out a lot of heat [12:14:39] Im thinking any electrical heat load needs a reduction factor [12:14:50] hmm [12:14:58] not sure what changed, but now the temp is sinking [12:14:59] Because the geat loads we used are based on max load [12:15:02] below 80°F already [12:15:13] I must have changed something in the LM configuration [12:15:51] My cabin didnt change much i left suit temp cracked the whole Apollo 9 seemed happy at 68-75 [12:16:04] But yeah i need to dive into that hx [12:16:24] I must have done something or else the temp wouldn't be sinking now [12:16:31] Lights? [12:16:37] don't think so actually [12:16:44] CB config for liftoff [12:17:04] Wheres the suit gas diverter [12:19:34] Oh something i want you to watch for me during rendezvous, your RR temp [12:19:44] It shoukd heat up as its being used [12:19:59] But if its too much i need to make it radiate off more heat [12:21:24] yeah, suit gas diverter could be it [12:21:33] suit circuit was always good [12:25:45] It still is a bit warm for my liking with the suit temp closed [12:26:36] But if the diverter valve is in suit and lights are on, the cabin will warm because its not getting cool air from the suit circuit [12:26:52] I think the cabin needs to radiate more heat [12:28:33] didn't even have many lights on, I believe [12:33:33] Well the only heat sources the cabin gets are the astronauts if unsuited, aot lamp, coas, and lights [12:33:48] What about your utility lights? [12:40:37] could be AOT lamps [12:41:17] Flood OVHD/FWD was in almost full dull [12:41:21] ANNUN/NUM full bright [12:41:30] dimm* [12:41:33] not dull, lol [12:42:15] and another heat source is the Sun [12:42:24] which always shines on the landing site [12:43:04] hey [12:43:16] hey Alex [12:44:32] ok, LM is in lunar stay config. Now I already need to think about plane change [12:45:24] already landed, eh? [12:45:38] oh yeah [12:45:57] and a bunch of P57s done [12:46:55] Gravity+REFSMMAT: 0.01°, 2x celestial bodies: 0.04°, 1 celestial body + gravity: 0.00° were my errors [12:47:23] I need to learn how the isolation and radiators work a little better [12:58:57] indy91, nice [12:59:20] hopefully the lateral error wont be too high at insertion [13:00:39] yeah, I have a good feeling [13:00:53] it really might come down to star choice at this point [13:01:16] yeah [13:01:33] were the stars lower in the sky? [13:02:31] I think the ones I used were all pretty high up [13:06:21] I haven't looked at the plane change page is probably years... [13:06:43] in* [13:07:23] finds a good solution it seems [13:07:57] I'll scrub the burn if the burn exceeds X NM [13:08:07] crossrange without the burn* [13:10:16] do you get the issue where sometimes VX will be like -10000 fps? [13:12:02] not this time, but I probably should look into fixing that [13:14:48] I bet I still have a scenario for that from you... [13:14:57] yep [13:14:59] from Apollo 14 [13:17:36] works good with that scenario [13:23:33] Its if you take a TIG thats off nominal [13:23:35] good morning [13:23:38] hey [13:24:50] hello [13:25:03] yeah, I have some ideas on how to improve that [14:09:11] definitely going to start apollo 11 today [14:12:13] @indy91 did you get a ctd any maneuver pads for your 11 testing? [14:12:21] none yet [14:13:21] brb [14:23:53] rcflyinghokie, cabin temp is approaching 100°F and I really don't like it. I've tried a few things, but I am really not sure what I did to temporarily fix this [14:24:07] all lights are off [14:25:30] what could it be? [14:31:20] oh [14:31:24] it's the astronauts in the cabin [14:31:37] if I put them in the suits, cabin temperature drops quickly [14:34:20] well, not super quickly [14:36:31] and down to 70°F, much better, haha [14:41:47] Astronauts in cabin and sgd in cabin mode? [14:45:14] yes [14:45:20] that is heating it up real good [14:46:31] Hmm i bet the cabin isnt pushing enough air into the suit circuit for cooling [14:48:32] cabin into suit circuit? isn't it only working the other way around? [14:50:47] if the valves work both way then the air should be mixing even at equal pressure, but it isn't properly doing it [14:50:53] maybe that valve needs adjusting? [14:51:33] hmm, no, it's pretty large [14:54:28] I mean the cabin gas return [14:55:43] that's in auto [14:56:02] hmm [14:56:35] it should definitely have Q exchange, even if the pressure on both sides of a valve are identical [14:59:01] but even setting it to open doesn't help [15:01:42] Might need more power at the cooling hx? [15:02:09] which one? [15:02:34] Heatexchangercooling [15:02:50] Also i need to see what the glycol temp is there [15:03:06] the suit circuit is cool [15:03:44] Oh then the cabin is just not transferring enough q [15:05:08] I need to dig into all of that again anyway [15:05:49] you can experiment with it when you get as far as I am right now [15:06:13] for now I can let the astronauts cool off in their suits, haha [15:07:14] Are the suits in disconnect when they were in the cabin? [15:08:21] One issue with this could be the fact that the suits are contained, hiwever when the astronauts were in the cabin on 11 they still were in suits just not pressurized [15:08:49] So their heat didnt go into the cabin and they still had lgc cooling [15:09:07] I mean it did go into the cabin but mostly the suit circuit directly [15:09:08] ah right, that set up [15:09:14] setup* [15:09:49] they are in suit flow [15:10:09] should I try in disconnect with crew in cabin? [15:10:18] Yeah [15:10:29] Well, no [15:10:45] You don't get lgc cooling into the circuit [15:11:23] Need like a doff helmet gloves option tgat vents into the cabin haha [15:11:40] right [15:12:43] More to play with [15:13:04] Ill get to the LM on 11 and see what i can do [15:13:41] On another topic i have been playing with the math for undocking force [15:14:31] The removing of the orbiter dv yields negative velocity and thus negative force values [15:16:58] if the undocking DV is lower than what Orbiter does [15:18:28] It is [15:18:37] ok time to fire up Spider [15:18:57] For some cases [15:20:14] Will that cause problems? [15:20:45] AlexB_88 let me know how the timing works going between csm amd lm etc [15:20:55] sure [15:22:29] well, as said in the thread on the forum, we have to look if there are any issues with redocking [15:23:29] I dont think so as probe alone undocking is almost as much dv as the default [15:24:30] Hmm the pyro undock seems low to me [15:25:21] What would be a good csm and lm weight estimate for lm sep [15:25:26] Lm jett* [15:26:55] 33000 and 5800 lbs [15:27:37] Vt of .2 ft/s [15:28:25] And orbiter was what .66 ft/s? [15:29:13] 0.2 m/s [15:30:09] better estimates: 37542 and 5668 [15:30:42] Wont change the dVt [15:31:38] Not much at least [15:31:55] .26 [15:32:21] So 0.08 m/s [15:47:02] Im trying to find out if that orbiter dV is a minimum to avoid redocking [15:52:20] when you undock then on the next timestep the other vessel will be x meters away from you, due to the 0.2 m/s undocking velocity [15:52:36] so maybe it checks how far away the other vessel is for docking [15:52:57] and if it was set any lower it would redock [15:58:43] Maybe [15:59:23] I might know a workaround thats actually realistic [15:59:39] Involves deleting docking ports though [16:00:29] Delete the cm docking port whenever the capture latches are disengaged ie holding the switch in extend/release [16:01:52] Says its supposed to be held at least 5 seconds but not to exceed 20 [16:09:58] right [16:10:43] I guess it's best if you prepare how the behavior should be and then we can take a look together at coding it [16:10:53] time to do an EVA [16:11:08] Sure [16:11:17] I have the math i think its right haha [16:11:37] Hmmm disclaimer EVA not simulated yet [16:11:53] damn [16:12:07] time to waste some O2 then [16:12:31] Haha yep! Pollute the moon with that O2 [16:12:52] or time to crash Orbiter in funny ways by trying to start our old EVA code [16:15:29] so, apparently there was a button for that [16:15:33] somewhere on the panel [16:15:50] on a panel area that still was code, but isn't defined right now [16:15:55] has* [16:16:08] and that would trigger the events to start an EVA [16:16:19] under the condition of GroundContact() [16:18:34] Oh really [16:22:44] you typed a lot of checklist item text for the EVA [16:22:51] 99% of which can't be done [16:23:11] Yep [16:23:53] Will you try and revive the old EVA? [16:23:58] It was just a transposition of the checklist, of course it can be edited, but i figure some can be done later [16:25:16] not for NASSP 8 [16:29:09] Oh i know [16:30:21] Is there a form for the LM AOT star observation PAD? [16:31:01] only in the crew checklists apparently [16:35:07] ah [16:42:49] Regarding all the text, gotta give you something to read while you cant EVA ;) [16:45:27] Oh indy91, on the forum post it was mentioned that the separation velocity can be controlled through the attachment system? [16:45:59] yeah, attachments can be jettisoned in any way I believe [16:46:34] oh, and while I can't EVA I'll do CSM procedures that you didn't include in the checklists, hehe [16:47:14] morning! [16:47:44] hey [16:47:48] https://archive.org/details/apollocommandmodacel [16:47:57] scans are up :D [16:47:57] all done? [16:48:12] not totally -- I still need to stitch together all the multi-scan foldouts tonight [16:48:16] then this volume will be done [16:48:29] where are the schematics? [16:48:45] Ah yes the CSM solo fun :) [16:48:53] 4-88 and on [16:49:16] ah, with text in between [16:49:32] yeah, just like ND-1021042 [16:49:37] right [16:53:27] time for cabin depress and not doing a small step [16:55:11] lol [16:55:16] good morning Mike [16:55:20] o/ [16:55:36] i will be starting 11 today this afternoon [16:55:44] as i have a job interview at 11:30 [16:57:27] @indy91 if i manage to get ahead of your mcc's should i just stop there? [16:58:24] I would be surprised if you get ahead [16:58:33] I am at the time of EVA right now [16:58:42] me too but just in case i do [16:58:48] i want to finish it quickly [16:58:52] Be advised you won't have new checklists [16:58:52] well getting ahead will do you no good [16:59:07] no updates from Houston past the EVA yet .D [16:59:09] :D [16:59:16] Im only at lm ejection [16:59:29] where we're going we don't need checklists [16:59:56] what do you mean by new checklists? [17:01:10] and the hatch is open [17:01:16] now what... [17:01:21] breath in that fresh lunar air [17:02:06] sounds good [17:02:24] Niklas just wondering how much time acceleration you can do when the lem is on the lunar surface? [17:02:33] I'm not sure really [17:02:44] others here have more experience with that [17:02:49] how much can you do without frame rate drops? [17:03:01] LM main panel is frame rate friendly [17:03:15] the ECS won't like it much, but 50x should be possible [17:04:44] Astronauthen96__ i am revising them to incorporate the MCC updates and cleaning up procedures that were missing [17:20:52] hmm selecting "crew number" in the ECS page of PAMFD from within the LM, always selects 1 number higher then requested [17:21:10] like if I press 2, it will display 3 [17:21:18] Yeah its how its coded... [17:21:20] press 1, it will display 2 [17:21:24] oh [17:21:35] Its number in cabin plus suits [17:22:00] So if you have 2 in suits, type 0 and it will show 2 [17:22:26] If you have 1 suit 1 cabin and type 0 it will show 1 [17:22:36] Took me a bit to figure it out [17:24:13] ok [17:24:15] So for say 1 suit 1 cabin type 1 and it will show 2 [17:25:00] the input is crew in cabin [17:25:04] the display is total crew in LM [17:25:47] crew in cabin, but not in the suits [17:26:44] right [17:35:21] well i am going to leave for my interview now and i might start 11 or 9 after [17:35:29] Good luck [17:35:35] Id start 9 ;) [17:35:43] okay [17:36:00] i probably will as i did 11 already [17:36:12] goodbye [17:38:35] yeah, good luck [17:39:00] In the current code, if you are attached (soft docked) can you release without it recapturing? [17:39:35] Does Apollo 9 have the real LM activation checklist in the MFD, or is it still based on Apollo 12? [17:40:16] not sure, Ryan, never tried it [17:40:43] We dont have a real checklist for 9 so its 12 mixed with flight plan and transcript cues [17:40:45] one of the three activation LM checklists flown on Apollo 9 is in the hands of a collector, who I had contacted about some specific LGC procedures [17:41:20] if we really need to know something from a specific page we can do that again I guess [17:41:30] And yeah thats the other problem, there were 3 activation checklists for 9 [17:42:05] LM Systems Evaluation Chechklist, LM EVA Checklist, LM Rendezvous Activation Checklist [17:42:10] I did my best with what i had but any input would be welcome! [17:42:55] its very good so far [17:43:58] Oh a hack to help your cooling, crack the suit temp valve, because of the hx code and the cold glycol, it cools better when flowing [17:44:08] I need to investigate that further [17:44:41] suit temp to hot? [17:48:00] Well it cools when the temp valve is open [17:48:14] And warms back up when closed [17:48:24] So revers of the desired behavior [17:48:48] But its because the glycol is colder than the suit [17:49:05] And the hx code only cooling not heating [17:49:11] its already full fold [17:49:15] ok, got it [17:49:15] the suit temp vavle [17:49:27] full cold* [17:52:45] Right but if you need the suit temp to cool, turn it hotter, its backwards right now [17:53:34] ok [17:53:42] right now my cabin temp is about 0 Kelvin [17:53:43] what do [17:54:25] so suit temp valve in the middle maybe? [17:54:36] luckily no astronauts on board right now :D [17:57:46] Alex you can play with it, middle should be fine, but you will notice a difference when the suits are manned between full cold and any open setting [17:58:39] Indy91 yeah might need to light a campfire if they were ;) [17:58:53] Maybe huddle around some hypergols? [17:58:58] Toasty ;) [17:59:57] should help [18:05:14] one thing is before the LM AOT star check it says to move the RR out of mode 1 region. One issue is that the RATE/ERR MON switch is not set to RR before this step so you cant see on the FDAI the slewing of the RR, unless you switch it to RR [18:05:38] There is a lot of those through out even the real checklists [18:05:52] I thought about adding them in but didn't [18:06:02] Probably should haha [18:06:25] Might be an implicit step [18:06:46] I think it would help from a new user perspective [18:08:05] hmm but if the real checklist is like that then maybe its good to keep it as is too [18:09:00] alright time to get ready to fire up the old DPS [18:09:52] Yeah thats one switch that seems to be omitted a bunch [18:10:05] At least in checklists [18:10:18] Ah yes, nice stable docked burn [18:10:45] Dont forget ags is scaled [18:11:22] So entering velocity is whole numbers, no decimal [18:14:10] ok [18:14:32] so does AGS work well in LEO? [18:16:03] It does [18:16:31] Cant do the RR updates but still does a nice job [18:16:54] Rendezvous calculations are not perfect but close enough [18:18:14] I guess that is all true of the real AGS [18:24:52] Moreso because of rescaling [18:25:06] I got much better results in LO [18:25:36] But i still was able to do an AGS only rendezvous in LEO so it does work [18:26:57] even the AGC struggles in Earth orbit in some regards [18:27:08] like the DV jumping around in P34 and P35 [18:27:11] also due to scale [18:28:09] Important thing is it gets you back :) [18:28:30] Though the apollo 9 AGS could do RR updates [18:33:44] I just entered a manual one after each burn it worked well enough [18:43:26] well I can omit my V55 for the LGC, I just happened to get the initial time to be perfectly identical to the CMC time lol [18:46:47] Did you use the new clock sync technique [18:47:56] yes [18:48:27] but I mean I did not need to use it after all when I hit ENT, both were identical [18:50:45] Pretty good then [18:51:14] Now lets see some all balls on those p52's ;) [18:56:04] I had an all balls on a P57 today [18:56:12] gravity + 1 star, but still [18:56:21] Still it's a star [18:57:32] yeah [18:57:42] so I got one axis 100% right at least, haha [18:58:27] ok something weird happened [18:59:17] the DPS actually fired a bit during the gimbal throttle set procedure, even when the STOP button was pushed [18:59:50] and this is before DPS press [19:00:13] how did you notice? [19:00:39] Good question [19:01:15] I can hear DPS engine sound very faintly, and switching to the CSM I looked at the EMS and the counter is running [19:01:33] wow [19:01:39] very little thrust but a bit [19:02:10] can I post a scn? [19:02:15] Sure it was the dps? [19:02:20] probably 10%, unpressurized [19:02:26] which can give a thrust still [19:02:44] sure, give the scenario [19:02:52] just tell me what I have to do to replicate it [19:07:29] With stop pushed what can give the signal [19:08:04] well there is a lot of different relays and logic behind this [19:08:11] engine stop button is just one part of it [19:08:35] it could be some initialization problem [19:08:59] well I lost the quicksave and cant reproduce it, great [19:09:26] or the order of the logic is wrong so that it can have an engine on signal for exactly one timestep [19:09:29] something like that [19:10:08] at what exact point did the engine fire in the procedure? [19:10:24] and how long was it on? [19:10:49] when I armed the descent engine in the gimbal throttle set procedure [19:11:06] So when the switch was flipped? [19:11:09] as long as the it was armed, it was on [19:11:11] yes [19:11:30] descent engine override switch? [19:11:31] very little thrust of course [19:11:43] no, that can't override engine stop [19:12:11] Be back in a bit [19:12:12] ENG ARM -> DES [19:12:22] thats what did it [19:12:23] Im curious as to what caused this [19:12:52] as long as it was in DES, even with the stop button pushed, I had a bit (very little) thrust from the DPS [19:13:33] the low thrust is 10% setting, but without pressurization [19:13:42] which can still generate a bit of thrust actually [19:14:04] that is all correctly modelled, how it behaves with which pressure [19:14:51] it was running at about 1 or 2 percent [19:15:10] and with the stop button pushed that is weird to me [19:15:29] oh yeah, something is screwy there [19:15:50] there are basically conditions for thrust [19:16:12] pre valves, engine arm (throttle actuator) and the a thrust on signal [19:16:16] whatever valves that is for [19:16:37] normally, in your config, I get the pre valves, engine arm signal but not thrust on [19:17:15] so for you thrust on must also have been set [19:17:18] this is the logic: [19:17:19] lem->deca.GetThrustOn() || (lem->SCS_DES_ENG_OVRD_CB.IsPowered() && lem->scca3.GetK5()) [19:17:32] that second part is simply descent engine command override [19:17:46] which internally also wouldn't work with the stop button set [19:17:55] so I don't think it's that [19:18:06] so it must be coming from the DECA [19:19:27] were you under AGS or PGNS control? [19:22:58] and I need to know all your STAB/CONT CB settings on panels 11 and 16, haha [19:23:39] even the engine stop button needs to have power to do something [19:23:46] so it could be something with that [19:32:26] I have to go but Ill continue checking this tommoow morning [19:32:28] cya! [19:33:52] maybe just a leaky DPS, haha [19:38:55] Any scoop on the dps? [19:39:48] no, Alex had to go and couldn't reproduce it [19:40:06] it could be some flaw in the logic together with a weird CB setting, is my best guess [19:40:50] Im just trying to make sure its not a procedure error first off [19:41:39] it could be procedure error plus bug, yeah [19:41:47] or else we would have had this happen before, in some shape [19:41:54] True [19:41:58] but no idea really [19:42:04] Ive never had it [19:42:21] I'll try to reproduce it together with Alex when he has told me his CB config [19:43:11] He was on gimbal drive check, so should be easy to reproduce the panel state to that point [19:43:45] yeah, we'll see [19:43:54] I've just finished the not-EVA [19:44:36] Increased the moons atmospheric pressure? [19:45:27] I tried [19:46:43] Oh well guess you get 1 more attempt [19:47:03] equipment jettison, yes [19:47:14] Mhm [19:53:06] So are we handling the mcc1/ptc uplink the sane way we did for 10 [19:53:12] Same [19:55:06] the same way you did that [19:55:19] I'm not sure I implemented it the flexible way on 10 [19:55:54] So what message will i get if its scrubbed [19:56:18] The normal scrubbed message? [19:56:29] yeah [19:56:39] and then it will enter an alternative sequence in the MCC [19:57:10] PTC REFSMMAT at TLI+4 hours [19:57:53] SV update only at the time where you would also get the MCC-1 update [19:57:53] Ok [19:58:00] then back to normal [19:58:11] Ill see what it does and implement pro fail logic [19:58:14] but it's the same way n the flight plan [19:58:18] in* [19:58:21] Shouldn't be hard [19:58:28] yeah [20:00:20] Ill see what i can add tonight, gotta drive, later! [11:50:26] good morning [11:50:33] just one question about apollo 9 [11:51:04] hey [11:51:18] i am assuming the docking angles are the same right? [11:51:47] same as what? [11:51:54] as they always were [11:52:13] because i still have them saved on my tablet [11:53:17] do you mean the numbers for the Nouns so that the FDAI shows the right thing? [11:53:41] yes [11:53:46] yeah, should be the same [11:54:12] looking forward to this mission [11:55:22] just curious were the mcc's for apollo 9 difficult to figure out? [11:57:54] it's not mcc's actually, the MCC feature in NASSP stands for Mission Control Center [11:58:07] confusing in general that MCC also means midcourse correction [11:58:17] that's why they often used MCC-H instead, H for Houston [11:58:32] yeah [11:59:04] so the mission control support for Apollo 9. Yeah, there were some big roadblocks [11:59:33] for most of the SPS maneuvers it was difficult to find the right targeting method [11:59:59] for a lunar mission I already knew the objective criteria most burns [12:00:02] i am glad you figured it all out [12:00:15] I figured it mostly out, yeah. Should be very flyable [12:01:26] and if i can remember there is more than one lem activation for the mission [12:02:55] about 2.5 activations [12:03:04] first for a systems evaluation and the docked DPS burn [12:03:22] on EVA day the LM gets activated partially, but only a limited number of systems [12:03:37] so I would only count that as half [12:03:40] and then for the rendezvous [13:51:28] hey [13:58:26] hey Alex [13:58:36] Eagle is back in the air [13:58:40] or, the vacuum of space [13:59:08] oh wow [13:59:26] that was quick [14:01:39] nothing new to implement for the RTCC really [14:02:01] all already done for the simulated ascent shortly after the landing [14:02:27] my final P57 had an 0.03° error [14:02:38] the P52 I just did on orbit as well actually [14:02:45] CSI had a +2.0 ft/s component [14:02:53] and that took out about half of the plane error [14:03:01] so looks all really good [14:03:09] great [14:03:31] DH will be about 15.4 [14:03:36] but about that [14:03:59] making it any more accurate requires taking the nonspherical gravity into account [14:04:18] the insertion velocity the liftoff targeting comes up with is a bit low [14:04:32] at insertion apolune was 44NM (above mean radius) [14:04:38] and at CSI that was down to 43.5NM [14:05:20] so for insertion the P12 target was right, but it should iterate on it to achieve the right DH on the perturbed trajectory [14:06:06] but I am confident that, with the new ascent simulation, the DH should always be within a mile of the planned now [14:07:46] first CDH solution, 15.5 DH and 0:12 TPI slip [14:25:05] Good morning [14:30:45] hey [14:31:10] indy91, nice stuff looking forward to try it myself [14:31:36] I think Ill be able to fly Apollo 9 rendezvous today [14:33:57] Already? [14:34:21] I'm flying Apollo 11 rendezvous today [14:35:51] AlexB_88, anything on the DPS issue? [14:41:05] rcflyinghokie, a checklist error almost got me today. AGS address 337 instead of 377 [14:43:18] Damn i thought i fixed those [14:43:19] third to last line of the Lunar Surface Operations checklist in the LM file [14:43:33] I found that error on 10 and fixed it for it and 9 [14:43:47] yeah, I remember it from a previous mission [14:44:11] Ill be sure to get it fixed [14:46:46] indy91, Ive tried to replicate the issue but I cant unfortunately. From an earlier save I followed the exact procedure and it did not happen [14:49:49] damn [14:57:46] rcflyinghokie, I think I found something in the RCS HOT FIRE checklist [14:58:20] It has you go to attitude control - pulse beforehand, but I think it should be mode control [14:58:47] because in pulse, the registers on the DSKY do not match with what the checklist wants [14:59:52] Its the procedure at 48:00:00 in the flight plan [15:04:16] Did i get it wrong from the apollo 12 activation? [15:08:27] well look on page ACT-44, it says to have ATT CONT (3) - MODE CONT [15:09:13] so its just a question of making it mode cont before the procedure at 48:00:00 I think [15:09:49] right now it has you go to pulse before the RCS hot fire check [15:11:04] indy91, does MCC give the gyro torquing angles yet, or do we still use PAMFD for that one? [15:11:21] it gives gyro torquing angles [15:12:50] ah great, just got them [15:13:27] rcflyinghokie, also we can remove the reference to using PAMFD V42 in the Docked IMU Fine Align checklist as MCC does that now [15:17:10] Ok i think the pulse is a remnant, because vokd and hot fire were split [15:17:18] And yeah the v42 can go [15:18:43] Or rather pamfd [15:20:54] also, whats the V47 button on PAMFD? [15:22:25] Which page [15:23:05] LGC [15:24:10] Isnt it v42 [15:24:25] theres a V47 button as well [15:24:32] Oh idk [15:25:14] also, I think I used Alignment: Identical for my IMU coarse align [15:25:27] should that of been LVLH instead? [15:26:02] For which phase [15:28:07] well during initial LM activation [15:28:36] Before the docked dos? [15:28:39] Dps [15:28:44] yes [15:29:04] identical [15:29:09] ah ok [15:29:18] I guess it will have me change it later on? [15:29:50] Yeah when you power up before undocking you will coarse align again [15:29:57] And use lvlh [15:33:31] oh before the LR test, the tape meter cbs are still open [15:36:34] oh, I recently added the V47 button [15:36:49] it's for the backup method to get the K-Factor for the AGS [15:37:09] it causes an ENTR press on LM DSKY and DEDA at the same time [15:37:24] ah ok [15:37:44] you need to have V47 up with a V32 I believe [15:37:48] and 377+0 [15:38:37] ah makes sense [15:39:49] rcflyinghokie, also on the RR self test page it says slew left 18 secs at the beginning, I think which is to get out of the mode 1 region. I think however this was already done earlier in the activation checklist (the slewing out of mode 1 region) [15:41:08] Mode 1 is pointing forwards, the RR starts in Mode 2 [15:41:39] sorry I mean mode 2 [15:43:55] The early part of the Apollo 9 activation check has the "Unstow RR" procedure which includes " Slew Left 18 Sec to Mode I [15:43:56] " [15:45:09] But its also in the RR self test at the end of the activation checklist [15:46:02] so just a question of removing "SLEW left 18 secs" out of the RR Self Test checklist [16:03:32] rcflyinghokie, is the initial AGS time bias on Apollo 9 40 hours? [16:06:41] yes [16:27:06] Sorry got pulled into a meeting [16:27:22] I saw a bunch of messages let me go back and catch up [16:28:28] Let me look about the RR [16:28:47] And yes 40 hours and then 90 hours for rendezvous [16:31:52] Im trying to remember where i got that slew to mode 1 and down 50 from [16:40:12] Has to do wirh the designate RR step [16:49:14] Might have been on the daylight star checklist? [16:49:29] The one we have a few pics of? [16:52:14] morning! [16:54:43] Hey [16:55:29] Hmm any idea where the RR is when first unstowed? [16:56:42] hey Mike [16:59:22] rcflyinghokie, flightplan says at 43:50, right after ascent bat c/o [17:04:19] I mean what position its in [17:04:28] Not when :P [17:05:33] And i don't have a copy at work but i think i got those rr instructions from the apollo 9 daylight aot star checklist [17:07:36] general thing about rendezvous checklists [17:07:50] it's probably better to not wait for a specific mark count, but instead for a time to TIG [17:07:57] or else you can get in time issues [17:08:02] like TPI with a moving TIG [17:08:13] it wants me to wait for 10 marks right now [17:08:20] but that would be about 2-3 minutes too late [17:10:02] That 11 checklist had no MCC [17:10:16] All uodated ones are based on TIG [17:10:20] Updated [17:10:40] ah, good [17:10:48] well this one doesn't use GETs much [17:11:02] just "wait to X marks", which doesn't have much to do with the MCC [17:11:04] Mark counts should be good for 10 and 9 using TIGs [17:11:19] Yeah those are just from the real procedures [17:11:35] time to TIG > marks > fixed GETs basically, for me at least [17:12:02] well the Timeline Book says V32 at X marks, but it also has timestamps there [17:12:06] X minutes to TIG [17:12:36] so it's kind of up to the astronaut when exactly to do the recycle [17:13:18] Didnt use the timeline book when i did the initial 11 checklist, didnt have it yet [17:13:33] Just the rendezvous procedures [17:14:24] oh, that's right [17:15:15] an experienced astronauts would probably be able to measure getting more marks vs. running out of time [17:15:20] but that's hard to do in a checklist [17:17:06] there isn't a right or wrong, just running out of time would be bad [17:17:33] Yeah indeed [17:18:00] Could also just make it wait for x marks or t- time [17:18:34] hmm, my AGC is locked up [17:18:44] did I just do a V90 with GET of 0h? [17:19:25] yep [17:19:30] N38 is going backwards all the way [17:19:47] lol [17:20:25] later AGC version have the current time or one from a specific program preloaded there [17:21:01] I am pretty sure I entered a time [17:21:11] maybe some display came up and it didn't get my ENTR or so [17:21:19] Oh yeah that happens [17:21:37] PRIO DISP is a useful light for that reason, haha [17:22:09] And also the time will come back up as well after an enter, if you dont check the noun you may think you have a weird dvy [17:22:24] Ive done that before [17:28:18] managed to save the situation though, with a quick V96 [17:28:23] and back into P20 and P34 [17:28:34] otherwise I could have burned the AGS or CMC solution [17:28:41] not that I had the CMC up though [17:29:24] Which burn [17:31:12] TPI [17:33:32] Ags would get you there :) [17:34:39] yeah, the solution agreed closely [17:36:10] and I also had no time for charts [17:36:21] really a 3 man job such a rendezvous [17:42:42] Indeed [17:52:17] alright time to light this DPS [17:53:50] Not early this time? [17:59:27] the TIG? [18:00:24] 49:42:00 on the FP, mine is 49:33:00 [18:04:42] I think he meant the DPS thrust you had yesterday, but that also is early [18:05:08] Yes i did mean the accidental ignition ;) [18:05:26] Hm too early? [18:05:45] ah yes, no I could not reproduce that issue [18:06:58] It was weird because the DPS was showing maybe 1-2% thrust and I could hear it at see that the Orbiter thrust indicator (green bar) was showing that tiny bit of thrust [18:07:19] but the weird thing is that should have been impossible because my stop button was pressed [18:08:41] if only we could reproduce it [18:08:59] if we could, then it could be a weird CB config [18:09:19] either a CB config that showed a bug that never happens otherwise [18:09:38] yeah [18:09:39] or there might even be the case where the engine stop button doesn't have power and doesn't set the relays to stop a burn [18:09:51] but I haven't been able to find a CB config that would do that [18:09:55] there might not even be one [18:09:59] but wouldnt it go to 10% thrust in that case? [18:10:37] no, as I said, it simulates unpressurized thrust [18:11:14] there is an equation for this, haha [18:11:18] ActuatorValves = (ActuatorPressure - 45.0)*1.0 / (110.0 - 45.0); [18:12:05] with full DPS propellant, but unpressurized, it still can produce enough pressure to open the actuator valves [18:12:58] but not 10% [18:13:27] because, the actuator valves normally only are open or closed [18:13:35] the throttle valves would be at 10% [18:13:46] so it would be 10% times the amount the actuator valves are open [18:16:03] rcflyinghokie, would it be possible to remove some of the yellow proceed items that are after the T-30s into green? The reason is it would be more user-friendly if some of those are automated and just timed from the 30 second mark. Right now you must press proceed on the checklist MFD at T-30, T-15, T-10, T-7.5 and T-5, in the docked DPS checklist [18:16:22] *not remove but change to green (auto) [18:17:02] maybe just keep the T-30 and T-5 as yellow, manual proceed checkpoints? [18:17:57] Absolutely, those came from old checklists [18:18:35] But ive thought about that too just never did it haha [18:18:53] Laziness [18:19:24] haha no worries it not the most high priority of things either ;) [18:23:26] No but you are correct [18:23:35] Thats the kind of feedback i like [18:23:54] Its better than me doing a "bad" [18:24:42] But ill go through all the burn checklists and remove the unnecessary pauses like those [18:25:29] Indy91 how did the ascent calculation and the sv propogation work out? [18:32:25] ascent and rendezvous was good [18:32:33] what sv propagation? [18:34:06] and Columbia and Eagle are one again [18:35:00] The sv given to the CM of the LM [18:35:07] Before ascent [18:35:37] oh, right [18:36:01] I will test how accurate it is [18:36:04] I haven't yet [18:36:19] but yeah, that is an output of the new ascent simulation, insertion state vector [18:36:28] will implement it that it can be uplinked in the MFD as well [18:37:13] but I am quite confident that it's accurate [18:38:28] I'll probably directly transfer it to the state vector page [18:38:34] hmm [18:38:55] that requires the ascent simulation to also work in the RTCC MFD open in the CSM [18:39:05] which might already work, if not, I'll make it work [18:42:06] good DPS burn [18:42:45] oh and one thing that was easy to set up with the MCC are scrubbed ascents [18:43:10] there is a mission rule, if the LM hasn't lifted off at 90 seconds past the nominal time then they will have to try again next rev [18:43:17] Those could be fun [18:43:24] the MCC checks ground contact at that time [18:43:44] and if there still is ground contact, it recycles to the MCC state of the ascent targeting [18:43:52] and gives new PADs and all [18:47:35] So how many revs before the plane error is too much [18:49:51] depends on a bunch of factors [18:49:59] approach azimuth, CSM orbit inclination [18:50:11] but I had I believe 0.2NM crossrange at PDI [18:50:15] and 2.6NM at liftoff [18:54:46] Still not bad [18:54:57] I gotra run see ya later [19:09:32] AlexB_88, ever checked the Apollo 11 Rendezvous after Anytime Liftoff doc? [19:10:31] there is still some stuff we don't support [19:11:13] if the phase angle at insertion after an emergency liftoff is really bad the CSM has to do a high dwell orbit orbit. Quickly boost into a 300NM orbit, stay there 3 revs, then deboost and rendezvous [19:11:47] apparently calculated with the DKI, so I still have some work to do with that [19:20:36] oh interesting [19:21:39] I have not read that doc, no [19:22:36] it's actually Volume II of the Abort and Rescue Plan [19:22:45] those documents you requested a bunch of from UHCL [19:22:53] https://web.archive.org/web/20100531234335/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740072785_1974072785.pdf [19:22:59] oh right [19:24:21] and the RTACF document I requested also mentions the high dwell sequence as one that has to be supported for Apollo 11 [19:26:59] Apollo 12 CSM Rescue Book also has a chart and a timeline for it [19:29:05] well, the Apollo 13 document you got us also has a variant of it [19:30:29] yeah [19:30:42] So I just got my SPS-5 maneuver pad, have a few questions [19:30:55] sure [19:31:01] SPS-5 is circularization? [19:31:17] It says in the flighplan that it should be 133x133, but its showing 140.5x131.5 [19:31:22] aha! [19:31:24] yeah [19:31:33] and that's the whole issue with circularization [19:31:50] it's the nonspherical gravity [19:31:54] and its at 56:56:06 instead of 54:25:16 [19:32:02] oh, that's bad [19:32:08] well the first thing first [19:32:18] with the orbital elements at TIG your orbit is 140.5x131.5 [19:32:21] Kepler orbit [19:32:43] but actually it's as close to 133x133 as possible in a nonspherical gravity field [19:32:55] your orbit will have two apogees and perigees per rev [19:33:05] and it will vary up and down by maybe a mile [19:33:15] but you'll see that it's actually very circular [19:33:29] 140.5x131.5 is what P30 will display [19:34:08] ah I see [19:35:40] so this is what it would have been in reality, too I guess [19:35:41] if you try to get 133x133 only using the state vector at TIG and assuming a Kepler orbit your velocity will be too slow or fast [19:35:42] Ryan and me got more like 133x125 due to that [19:35:42] yeah, this is from the RTCC documents [19:35:43] general purpose maneuver processor circularization [19:35:58] now to the TIG [19:36:07] I used an earliest possible time of 54:00:00 [19:36:44] but 56:56:06 is really weird [19:37:06] yeah [19:37:19] even if the burn should have been at 54:24:00, 90 minutes later is still only 54:54:00 [19:37:33] no, wait [19:37:53] https://www.dropbox.com/s/nptlq6bvzgdthce/Apollo%209%20MCC%20-%20Before%20SPS-5.scn?dl=0 [19:38:01] yeah, I'll have to look at that [19:38:15] thats the .scn right before the SPS-5 MCC thread [19:40:18] the height finding function must be broken [19:40:23] really the only explanation [19:40:34] I think I've done some changes to that [19:42:03] yeah, I think I have an idea what the issue is [19:42:17] I'll have a fix, maybe even today [19:44:45] basically, I changed the time-radius function to be consistent with the one in the AGC [19:44:48] find time at radius [19:45:05] the one in the AGC, for an elliptical orbit, always finds the radius in the future [19:45:23] so that's probably how it accidentally jumped a rev ahead [19:47:19] ah makes sense [19:53:58] unfortunately the RTCC document only had the equations for the circ burn, not for finding a specific height in a nonspherical gravity field, haha [19:54:09] and the one in the CMC is not universally usable [19:54:24] it's used in P37 for the integrated trajectory [19:58:39] oh really lol [20:14:23] I have a short term fix for your issue [20:14:35] but I'll also change the threshold time for the burn [20:14:48] so yours will be at about 53:54:00 [20:15:34] which is even earlier than what I got before, but fairly consistent with the fact that the pre SPS-5 trajectory isn't right [20:15:45] well, pre SPS-1 trajectory really [20:15:57] it's missing acceleration from the S-IVB LH2 vent [20:16:00] oh really? [20:16:03] ah I see [20:16:55] so it makes SPS-5 30 mins early about [20:16:59] yep [20:17:01] I guess Apollo 9 is even longer attached to the S-IVB [20:17:34] I think it all starts with SPS-1 not being at 110NM, but more like 100NM instead [20:17:42] yeah [20:17:46] that rotates the orbit wrong [20:17:49] I noticed that [20:17:58] or at least differently than the flight plan expects [20:23:52] damn, still more bugginess [20:24:05] I'll to look more into finding a proper fix tomorrow [20:24:08] have to* [20:24:38] good night! [12:41:52] hey [12:42:47] hey Alex [12:42:57] I think I fixed the issue you had [12:43:08] nice [12:43:29] it finds the solution now where it's at 133NM with positive flight path angle [12:43:50] that was a problem before, I think I've told you about it, you ran into it with a circ maneuver in lunar orbit [12:44:11] and surpringly, that TIG solution is actually pretty close to the flight plan [12:44:18] so the orbit isn't as much off after all [12:44:21] last night I had also made my own temporary fix by changing the "opt.TIG_GET" in RTCC_Mission_D.cpp from 54 to 52 hours [12:44:57] then it might have randomly find a solution on the right rev, yeah [12:45:02] what was the TIG? [12:45:06] hmm but it found a GET of 53:53:00 or so [12:45:15] ah, so the too early one [12:45:21] yeah [12:45:23] I would try again with the fixed version [12:45:37] right [12:45:39] 54:17:00 or so it was [12:45:44] so pretty close [12:46:43] just needed to sit down, understand what the equations I took from the CMC are actually doing, and now it seems to reliable find the solution for a given height and going upwards [12:53:51] just made a quick test and yep works good TIG 54:18 or so [12:55:35] Did TEI go well? [12:56:16] yep [12:56:49] it's weird how quick everything happens [12:57:29] LM activation, PDI, 4 hour rest, EVA; 4 hour rest, return to orbit, docking, LM jettison, 3 hours later TEI [12:57:48] and then a well deserved 10 hour rest period, haha [13:01:53] and I thought long haul flying was scary [13:10:43] so I guess your approaching the finish line of your NASSP 8 MCC mandate :D [13:12:08] well [13:12:15] still need to go through 7 and 8 again [13:12:33] making sure everything works still, adding one or two of the new features [13:12:54] right [13:51:47] oh, I found some calculations for the RTCC Lunar Surface Alignment Display [13:52:09] one part of that is the AGS azimuth, part of the ascent bad [13:52:14] adresses 047 and 053 [13:52:20] ascent PAD* [13:53:51] I was talking to Ryan about that in the last few days [14:00:04] oh nice [14:00:50] Ascent PAD also soon coming to a RTCC MFD near you [14:01:57] Ill be at the premier! [14:03:45] oh I guess ascent pad will be good to see your cross-range to judge if you need to do a plane change or not [14:05:51] yeah [14:06:00] the Ascent PAD calculation won't calculate that much [14:06:19] most of its data will come from the liftoff page [14:06:58] crossrange and the DEDA values are calculated [14:55:13] just working on the 31.7 line view now [14:56:28] and in adding the new resource file (bmp) I have completely butchered my VS directory haha [14:56:45] but it will be easy to revert [15:01:56] haha, good [15:05:23] fixed [15:22:21] https://www.dropbox.com/s/pxo51r2a8kdu64q/Screenshot%202018-08-22%2011.21.31.png?dl=0 [15:23:06] all that is left is setting it at 31.7 pitch, I have it pointing forward for testing still [15:23:56] I like it [15:26:46] I might need a bit of help for that last step [15:26:54] SetCameraDefaultDirection(_V(0.0, 0.0, 1.0)); Is pointing forward [15:27:09] So I want it pointing up to 31.7 [15:27:48] seems to be a vector format for that so I guess its not just entering 31.7 verbatim lol [15:28:24] no, it will be sine and cosine of it [15:31:47] try this [15:31:48] hmm this is where I should have been paying attention in math class, lol [15:31:49] SetCameraDefaultDirection(_V(0.0, 0.5254716511, 0.8508111094)); [15:32:02] thanks [15:32:03] basically the same as the hatch window view [15:32:07] just 31.7°, not 57° [15:32:22] right [15:34:56] there you go! [15:34:57] https://www.dropbox.com/s/7ipgremx4eta0wn/Screenshot%202018-08-22%2011.34.39.png?dl=0 [15:37:53] great [15:38:49] should be ready to PR shortly [15:44:36] and PR is sent [15:45:22] just in time for your re-entry ;) [15:48:48] yeah, I can try to follow the horizon now [15:48:54] and I'll change the Entry PAD of course [15:53:48] merged [15:54:38] thanks [16:03:35] also, is the current LEO block data calculation compatible with the 31.7 degree line on the horizon? [16:04:39] yep [16:04:47] same as the normal deorbits [16:05:06] the Block Data is specifically for that [16:05:16] you can deorbit without CMC and SCS [16:05:23] what were we doing before? COAS on horizon? [16:05:47] I roughly put the horizon on the upper edge of the screen [16:05:56] and for the Entry PAD it was COAS in horizon [16:06:13] right [16:09:49] do we have a checklist for following a block data pad abort? [16:10:05] hmm, not really [16:10:14] Apollo 7 did some tests [16:10:55] I guess its just place the line on the horizon and do an SCS burn at the TIG and DV of the pad [16:11:20] "manual retro attitude orientation" [16:11:45] doesn't even need the SCS [16:12:17] manual attitude control, line on the horizon, heads up, pointing backwards against your velocity vector [16:12:29] and then just using the EMS [16:12:42] which has a self contained accelerometer [16:12:51] SCS auto cutoff is a bonus [16:13:05] but you could do it without that [16:13:10] just Direct On [16:13:25] SPS* [16:13:26] so its head-up meaning the CSM will be pointing downwards [16:13:33] yep [16:13:51] the normal deorbit maneuvers use the same attitude [16:14:51] if everything fails on you in that phase then you could still do it all manually [16:15:11] ok I will simulate that Dave Scott just let out a nasty one and we have to abort ASAP! [16:16:11] put him in the LM and undock [16:16:21] of course [16:18:14] the block data burns are CSM-only obviously? [16:18:35] yeah [16:19:16] ok so I turned off mission tracking in the debug menu and will try one [16:19:31] great [16:19:43] I guess the "request abort" would have turned off that too? [16:19:56] doesn't do anything yet for Apollo 9 [16:20:05] or maybe... [16:20:38] no, I haven't implemented that for Apollo 9-11 yet [16:21:28] maybe in the mean time that button could be programmed to stop all MCC updates [16:22:29] yeah, I'll do that for those missions after I am done with the nominal Apollo 11 [16:30:44] So I did the burn [16:31:05] ApA: 236 nm PeA: 3.2 nm [16:31:35] pretty normal [16:31:41] awesome [16:31:44] Apollo 9 nominal deorbit has 0NM perigee [16:31:56] perfect [16:32:08] from a similar apogee [16:32:22] so your flight path angle at EI should be reasonable [16:32:45] just no way of knowing when the air starts hitting [16:32:49] I'll be back later [16:55:13] did you put it in the water? [16:55:47] morning! [16:56:03] hey Mike [16:56:35] I have a bit of trouble with one of our favourite topics [16:56:46] decimal to octal :D [16:56:51] in this case, DEDA octal [16:57:37] oh boy [16:58:28] https://www.dropbox.com/s/7ipgremx4eta0wn/Screenshot%202018-08-22%2011.34.39.png?dl=0 [16:58:36] btw, I'm a lot less busy now, so if there are any still outstanding questions that you asked me (I don't think I answered any) in the past couple of weeks I can try to do that now :P [16:59:09] and Dave Scott is indeed not aboard [16:59:15] wrong screenshot Alex [16:59:23] that's one you posted already, I think [16:59:46] https://www.dropbox.com/s/9n4wvy5gorb70cm/Screenshot%202018-08-22%2012.59.38.png?dl=0 [16:59:56] thats better [16:59:59] yep [17:00:39] So I burned manually, but with P47 up [17:00:57] if numbers is negative, convert to 2s complement by invertig all bits to the left of least significant bit which is a one [17:01:01] number* [17:01:05] and then let PGNS fly the re-entry, putting the pad coordinates into P61 [17:01:17] worked like a charm [17:01:21] oh, great [17:01:38] we still lack a reentry simulation [17:02:12] I believe the Block Data would be target for a 55° rolled reentry [17:02:17] targeted* [17:02:44] thewonderidiot, what I don't quite understand is why you don't invert all the bits [17:03:21] now that I write that [17:03:43] 00000 at the end wouldn't become 11111, in binar [17:03:44] y [17:03:48] because two complement [17:03:50] that stays 0 [17:03:54] probably that's why [17:04:04] yeah, two's complement makes it so you have a single zero [17:04:36] but the process is to invert all bits, and then add one to the result [17:04:44] ah, right [17:04:52] not in this RTCC document, but normally, yes :D [17:05:12] hahaha [17:05:14] so let's say I have a negative decimal value, correct scaled [17:05:15] weird [17:05:26] indy91, I think you use a 16:10 screen, the new panel I added is 16:9, so let me know if it still displays correctly on yours. I guess the important thing is the line is in the center of the screen [17:05:30] -0.5625 was the example [17:05:35] mhm [17:05:51] end result for the DEDA, -56000 [17:06:12] 15 bit binary of course [17:06:51] all I really need is a C++ function that also does it right for negative numbers [17:07:00] double in, integer out [17:07:06] so the question is, why does -0.5625 become -56000? [17:07:33] this is from an example in that RTCC document, I can link it [17:08:16] page 1005 [17:08:17] of course [17:08:24] https://web.archive.org/web/20100525000249/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19730062603_1973062603.pdf [17:08:52] that's a lot of pages :P [17:09:01] sure is [17:11:10] also, when I used the right octal (-56000) but formatted in decimal (-23552) and did a sprintf(Buffer, "%o"); with it it had an 37777 something in from [17:11:12] front [17:11:22] probably because integer is too long [17:11:50] I always have trouble with this stuff... [17:14:08] yeah, it's not wrong -- you're storing -23552 in a 32-bit value, and all of those leading bits will be 1 if it's negative [17:14:25] signed binary stuff is messy [17:14:39] with the AGC octals we actually convert the number and not just display it differently [17:14:53] maybe should be done here as well, for less confusion [17:15:01] but the function for this is quite complicated [17:15:09] and uses 1s complement of course [17:15:56] I always find it easiest to work with data like this by converting it to unsigned and dealing with the data directly [17:16:08] in which case, one's complement just becomes "number ^ 077777" [17:17:02] how do you get from double to unsigned without just dropping the bits? [17:17:38] you go to the fractional representation [17:18:11] and in C++ language that is? [17:18:28] double sin_DL = -0.5625; [17:18:36] how to make an unsigned out of this? [17:18:54] unsigned x = (unsigned)sin_DL; is probably bad [17:19:35] multiply by the number that represents a one in inary [17:19:54] 0777777 is as close as you can get to one, unsigned [17:20:01] er [17:20:08] 0377777 rather [17:21:05] so 0400000 would be a one, if that first bit wasn't used as the sign bit [17:21:30] .py bin(int(0.5625 * 0o400000)) [17:21:37] which is what they have, right? [17:21:49] yeah, I think so [17:22:06] so, following their steps [17:22:18] shift one place right, convert to two's complement [17:22:53] I just still have troubl with the data types to use [17:23:07] .py oct(((int(0.5625 * 0o400000)>>1) ^ 0o777777)+1) [17:23:11] hmm [17:23:20] DEDA, not AEA [17:23:37] so probably a 0 too many or so [17:26:34] yeah, I"ll have to play with this a bit [17:27:03] indy91, its actually quite easy to follow the horizon at night with the 31.7 line [17:27:33] lack of stars? [17:27:38] yeah [17:27:49] you can see where the stars suddenly stop [17:28:16] At on my screen, with the Apollo 8 Entry Interface scenario [17:28:23] At least on my screen* [17:28:32] great [17:28:41] so one technique more that is working right [17:28:51] yeah [17:40:48] I think I have a working function for octal to DEDA [17:40:52] decimal* [17:51:43] Just looking through the checklists, Ill let Ryan know he can now make the changes to now reference the 31.7 line instead of the COAS for the entry checklists [17:54:48] sure, it's a simple change for me, I already had the logic in there [17:59:46] .tell rcflyinghokie, I added a new window in the CSM that has the 31.7 line centered. The entry checklists can now be changed to reference that line instead of the COAS, and the horizon check attitude from 300 to 265. [18:22:34] huh [18:22:46] just got an email from Ryan, who says he is unable to connect to IRC [18:23:01] and also saying that he got an email [18:23:15] "Dear Ryan, Thank you for contacting the NASA STI Information Desk, and I apologize for the long delay in my further response to your document request below. I regret to say I have just learned we cannot make the document you’re looking for publicly available – it was reviewed by the NASA  Export Control specialists and found to contain material that is restricted for use by NASA employees, or NASA contractors only. Please let us know if we c [18:25:42] which one did he request? [18:25:56] I did the LVOT I think [18:26:22] I forgot who did what [18:28:30] yeah, I requested the Apollo 10 LVOT [18:28:33] no reply yet [18:28:53] oh, did I make him request the LOI Targeting RTCC Requirements? [18:29:25] but I think this is good news. We can force them to review individual documents [18:46:49] I think he asked for rendezvous techniques or something [18:49:21] 19750064221 Apollo mission techniques mission D rendezvous. Volume 1: Techniques description, revision A 1969 [18:49:24] this probably [18:50:11] to be fair, most of those are gone from the current NTRS [18:50:33] at least that's consistent [18:52:13] I wonder what in there is restricted material [18:52:24] probably something really dumb [18:53:15] judging by the NTRS ID, that was one of the documents added after the mass archiving of NTRS stopped [19:06:57] Wasnt there a reference to the 31.7 line during launch operations? (saturn takeover during ascent) [19:07:10] or maybe it was abort procedures [19:12:12] oh I think its in the SPS to orbit abort (scribe on horizon) [19:14:20] yeah, one of those [19:15:41] mode 4 [19:16:08] the Apollo 15 checklist details the pitch profile and fixed attitude burns [20:26:33] good night! [22:13:04] .tell rcflyinghokie There is a SV update at 55:30:00 that does not have a V66 after (the uplink has no V66 either) [11:06:25] hey [11:07:06] Good morning [11:07:13] Bye [11:07:17] :P [11:07:40] More for the to do list [11:08:02] always [11:08:14] so you did get an answer from NASA STI, I heard [11:08:35] you requested the Apollo 9 rendezvous techniques? [11:08:46] Yes [11:08:53] Not a good one [11:09:23] maybe they should ban Tindallgrams as well, for good measure [11:09:33] Did mine show you the reply? [11:09:36] Mike* [11:09:40] yeah [11:09:53] That makes zero sense [11:10:07] at least we can force them to review documents individually [11:10:51] Any thoughts on a course of action [11:11:04] not really [11:11:45] in mostly better news I found some equations for the AGS azimuth in RTCC documents [11:12:21] in not so good news the equation is wrong, but the diagram it comes with is right [11:12:51] and I am not getting consistent results yet calculating that angle [11:13:58] so the angle as it is is still better than what I calculated [11:14:10] LGC and AGS are consistent [11:16:36] Hmm how are the equations wrong but the diagram is right [11:19:23] good question how they managed that [11:19:27] but I am pretty sure [11:19:54] just two variables have to be exchanged then the equation should be right [11:24:01] it's weird notation anyway [11:24:21] vector minus vector and then an atan [11:24:29] Typo perhaps [11:24:29] maybe I don't quite get what they mean there [11:52:59] well it's off by a 0.06° that I can't explain [11:54:22] unless... [11:54:55] no, the IMU shouldn't be that off [12:21:57] Nope [12:31:21] hey [12:36:26] hey Alex [12:49:56] whats up? [12:56:11] AGS azimuth still making me a bit of trouble [12:59:30] is AGS azimuth related in any way to the 413+1 that is done after landing? [13:02:26] yeah, I think that stores them from the current AGS alignment [13:03:02] so that they stay constant for the lunar stay duration [13:05:44] trouble is they don't really stay 100% constant, especially not with a plane change done by the CSM [13:06:16] right [13:07:02] In Apollo 11 MCC, does a CSM plane change happen, if crossrange is above a certain threshold? [13:10:48] yes [13:11:00] I've set it to 4NM, maybe should be 8 [13:11:07] normal is 2.6NM, so no plane change [13:13:36] yeah 8 would seem rather high [13:15:42] didn't find anything in the mission rules unfortunately [13:16:17] and with my luck mine would probably end up 7.9, so good thing you set it to 4 lol [13:34:37] so I found a small issue with my PR yesterday, I had set the view coordinates in the Saturn::SetView so that the new window is identical to the CSM left rendezvous window [13:35:31] and so to do that I just added the " || " IE: if (PanelId == SATPANEL_LEFT_RNDZ_WINDOW || SATPANEL_LEFT_317_WINDOW) { [13:36:39] but that screwed up some of the other views so I what I did was separate the 2 into to there own independent ifs [13:36:48] and that fixed the problem [13:37:13] indy91, Ive already made a PR with the changes [13:37:49] if (PanelId == SATPANEL_LEFT_RNDZ_WINDOW || SATPANEL_LEFT_317_WINDOW) [13:37:57] if (PanelId == SATPANEL_LEFT_RNDZ_WINDOW || PanelId == SATPANEL_LEFT_317_WINDOW) [13:38:02] here is your problem [13:38:35] but your solution works as well [13:39:02] oohh lol [13:39:08] so you basically had if (SATPANEL_LEFT_317_WINDOW) [13:39:13] I like your better though haha [13:39:16] which is always true if it's non 0 [13:39:19] yours* [13:39:31] I like yours better, because both views are adjustable [13:39:41] ah true [13:39:51] merged [13:39:58] thanks [14:08:57] good morning [14:09:19] so i guess 9 should be pretty flyable now right? [14:09:48] with my latest fixes, yes, lol [14:10:15] but both Ryan and Alex have been or are flying the mission, so bugs are getting more rare [14:10:26] yeah i would rather do a mission that i have not flown yet [14:13:20] 9 is surprisingly fun [14:14:06] ok EVA time [14:14:19] and with two and a have lem activations sounds a bit fun too [14:14:33] hlf* [14:18:10] https://i.imgur.com/PCrEa2v.png [14:18:19] I just don't know what they mean there [14:18:40] Z_B is a vector, Y_AGS and Z_AGS are vectors [14:18:45] they are subtracting them [14:18:53] and then divide them? [14:19:02] and suddenly it must be a scalar because they use atan [14:19:21] I guess I just don't understand the notation there [14:24:10] oooh [14:24:15] not subtracting vectors [14:24:19] it's the dot product [14:24:28] then I get the same as with my calculations [14:24:38] the one that is 0.06° off, but for other reasons :P [14:28:38] at least I can now use this equation and understand it [14:32:27] glad you figured it out! [14:34:05] now I need to figure out why the calculated body Z-axis of the LM is off [14:34:20] only 0.06°, but still [15:06:43] oh lol, I have just used the O2 demand regulation lever in the CSM for the 1st time [15:06:49] never even knew it was there [15:21:59] https://www.dropbox.com/s/klwiuvzny3pi08c/Screenshot%202018-08-23%2011.21.29.png?dl=0 [15:25:05] attitude for the EVA should be right, so comparisons to photos are possible [15:28:40] hmm the sun seems to be on the back side of the LM, but in photos its on the front [15:30:44] like this: https://www.dropbox.com/s/1ytjz0slf69mdz9/Screenshot%202018-08-23%2011.30.20.png?dl=0 [15:30:54] compared to this: [15:31:07] http://moonpans.com/prints/A9_scott_eva.htm [15:34:00] and you are aligned to the EVA REFSMMAT and at IMU angles 0? [15:34:30] hmm, but yeah [15:34:36] for me it looked similar to you [15:34:43] that's weird [15:34:55] I was so sure I got it right [15:38:41] yeah I got the EVA refsmmat and am at 0 [15:59:02] nothing is ever easy and just works, haha [16:06:33] so, my first guess, the right attitude with your REFSMMAT would be 180°/180°/0° [16:10:23] yeah [16:35:39] ok, this time I actually have it [16:35:59] with your REFSMMAT it is 200°/180°/0° [16:36:09] and the calculation gets fixed [16:37:50] in the end all that was wrong were a minus on two vectors [16:38:28] haha I was thinking it was a sign issue [16:45:43] morning! [16:47:41] hey [16:48:04] hey Mike [16:50:39] pushed my latest state [17:05:07] awesome [17:07:14] ill be out for a few hours [19:08:08] back [19:10:55] wb [19:17:35] alright starting day 5 now on Apollo 9 [19:26:59] I wonder how your rendezvous with differ from mine and Ryan's [19:27:01] will* [19:27:11] your orbit should be more circular in any case [19:27:25] can't be bad for a concentric rendezvous profile [19:27:40] yeah [19:27:49] currently its 134.4x131.5 [19:28:18] is that actual or calculated from current state vector? [19:29:39] actual [19:30:08] so you monitored your altitude and found that those are your perigee and apogee? Or did you use a tiny burn on the GPM page to check? [19:30:29] PAMFD ;) [19:30:45] so from the current state vector [19:30:51] that will also not be accurate [19:31:03] your orbit is probably even more circular that that [19:31:18] doesnt PAMFD just use orbiter functions directly? [19:31:21] yes [19:31:41] but that also doesn't take nonspherical gravity into account [19:31:52] ah right [19:32:04] it just calculates the apogee and perigee from the current state [19:32:14] in the ideal "circular" case, your orbit will have two apogees and perigees per orbit actually [19:32:31] what's your current altitude on the PAMFD? [19:35:56] 132.1 [19:36:07] oh [19:36:27] if you give me MJD, RPOS and RVEL from your scenario I can check how circular your orbit really is [19:36:41] sure [19:36:55] ah, the 132.1 is referenced to pad radius, I think [19:36:58] MJD 40287.2972261129 [19:37:09] RPOS 3796439.521 -175102.935 5418036.156 [19:37:09] RVEL -4612.5555 -5445.8977 3057.5852 [19:37:51] thanks [19:37:54] let's see... [19:41:13] generating a graph with the right altitude reference [19:41:38] which is not what we use in Orbiter, there it's pad radius everywhere [19:42:21] 133NM circular was the desired orbit [19:44:45] https://i.imgur.com/brBSeNt.png [19:45:02] that's about one orbit [19:45:25] circular enough to get the two apogees and perigees, haha [19:47:59] and here the same with the altitude reference PAMFD uses: https://i.imgur.com/CCECvCy.png [19:48:36] yeah I see the apogees and perigees for sure [19:48:45] the 2 ones a mean [19:48:51] I mean* [19:48:54] I guess what I am mostly interested in is if any calculations break down because of the very circular Earth orbit [19:49:09] I doubt any will, but there is a small chance [19:50:39] you will see during the rendezvous [19:51:54] Im the Guinea Pig, as always... :D [19:53:53] you don't want it any other way [19:56:01] haha true [20:07:57] also, just a small technicality but when the EVA desired REFSMMAT is uplinked, it just says "REFSMMAT" instead of "Desired REFSMMAT" in the uplink messages [20:14:14] it always does that [20:15:19] I don't think the MCC ever says specifically which REFSMMAT type it is [20:15:23] not the one I just got for the rendezvous, it said desired REFSMMAT [20:15:24] I mostly sticked to the flight plan [20:15:30] hmm [20:15:50] and the one for the docked DPS burn [20:15:58] maybe in that case the flight plan said that as well [20:16:00] I'll check [20:31:40] and Spider is alive once again [20:39:14] gotta say for not having an actual activation check for Spider, Ryan did a pretty fine job [20:39:39] so far at least :D [20:57:13] yeah, it must be quite challenging to piece all that together [20:57:15] good night! [11:00:47] Good morning [11:01:38] hey [11:01:56] I get to so some NASSO work yay [11:01:58] NASSP [11:02:40] how far with Apollo 11 are you? [11:03:03] I havent been able to touch the sim itself since last weekend [11:03:18] So Evasive [11:03:26] ah [11:03:34] I've just done MCC-5 [11:03:40] Should be able to burn through a lot today [11:05:25] I want to finish Apollo 11 soon and I also haven't forgotten about the descent abort constants [11:05:39] still need to work on that targeting [11:07:34] Hopefully I get to LOI at least today [11:34:47] Hmm so I want a new/nice joystick setup, what to get [11:39:33] something with 3 axis :D [11:40:05] Well I have a 3 axis :P [11:40:18] I was looking into one of the thrustmaster HOTAS systems [11:42:51] Hmm but thrustmaster might be making one for the f 18 [11:42:56] Maybe I should wait longer haha [11:46:20] keyboard works good enough for PDI as well [11:46:48] have to go, I'll be back in the evening [11:46:55] cya! [12:09:42] morning [12:14:08] Hey [12:20:54] Spider is now on its own, coming up on the phasing burn [12:21:10] btw great checklists so far [12:21:23] Good to hear [12:21:52] I have done all of your fixes other than the P40 yellow test and the entry stuff, as I will apply those to all of the cheklists at once [12:22:02] yellow text* [12:22:31] great [12:22:49] one other minor comment I would say is the handling of the switch to CM/switch to LM [12:23:31] Suggestions? [12:24:08] It got me confused at some points I think I was switching back and forth in the wrong order so I was coming up on undocking and still had not done the LM side of the undocking checklist (cb config) etc [12:24:41] But then again it might of been a user error on my part too [12:26:28] I guess what I mean is if you miss one then that throws the whole sequence "out of sync" haha But I mean other then that they are pretty good as is [12:26:51] Yeah [12:26:55] I have had that issue as well [12:27:17] Also it's sometimes hard to see if I have missed one in the checklist itself! [12:27:58] If there is a better way to handle it I am all for it, I thought of like putting a tag on them or something like numbers but that just seems too "clunky" [12:30:35] I wonder if there could be a further way to identify the "switch to XX" itself like have a time/number on them so that say when your in the LM and it says "switch to CM", if it could rather say "switch to CM 01" and then you switch to CM and then the next "switch to LM" will be rather "switch to LM 02" or something like that, then you will know its in order [12:32:12] Yeah thats what I meant by numbers [12:32:17] ah, right [12:32:47] It could work [12:33:09] I can try adding it when I do the bulk checklist changes [12:33:16] I want to finish 11 first :P [12:33:25] Or another idea, after each "switch to XX" describe what what is the next item on the other vehicle [12:34:03] Like "Switch to CM and perform such and such" [12:34:24] or Switch to LM to continue X" [12:34:27] Also viable [12:34:35] But a lot of work haha [12:34:38] might be cleaner [12:34:49] right haha [12:34:58] I will experiment in the near future and see what works best [12:35:14] When Nik gets back we can see if he has any thoughts as well [12:35:21] yeah [12:35:31] But I am ok with doing whatever is easier for the end user, even if its more for me :P [12:36:07] right [12:36:19] So on another topic, I am in the market to replace my old logitech 3d pro [12:36:30] Just trying to decide what to get [12:36:35] Thrustmaster T1600M [12:36:55] Haha I was looking at that and the warthog [12:36:56] T16000M* [12:37:17] warthog would not be very good for NASSP though, no twist [12:37:30] Oh really [12:37:43] nope [12:37:50] I have both those joysticks actually [12:38:13] But I can see why you would want it if you play DCS ;) [12:38:23] Yeah i am finally getting back into DCS [12:39:49] So no twist huh [12:39:52] Damn [12:40:12] The T16000M has hall effect sensors too, its a very precise stick [12:43:19] Probably what i will get, until thrustmaster makes a hornet stick ;) [12:43:56] How is the throttle [12:44:23] Its good [12:45:18] One thing with the LM though is I always have to have to slide up to the top and back down at every session start in Orbiter [12:45:55] Or else the throttle at 0 for some reason registers at like 20% in sim [12:46:22] Does it happen in the DG as well? [12:46:32] so I slide up down full travel and they are synced again, (physically and in-sin) [12:46:39] Ill try [12:46:49] That will tell us if its an orbiter or NASSP issue [12:47:39] no [12:47:50] so yeah must be a NASSP issue [12:54:16] Another thing I found in the checklists, The checklist has the gyro torque at 91:25:00, But MCC has this displayed at 91:15 or so [12:55:55] I mean not the gyro torque itself at 91:25:00 But the "copy gyro torque angles" [12:57:49] Ah yeah thats should be at 15 [12:59:10] Fixed [13:01:02] And I pulled the trigger on the 16000M [13:08:53] Hmm I am getting a SV update way early on 11 [13:16:55] MCC is giving t to me at 6:50 [13:17:17] FP says 10h [13:17:42] Oh its a PTC REFSMMAT [13:17:57] I guess because MCC1 is scrubbed I am getting it early [13:21:14] This will be a fun pro fail case [13:25:20] well I just got my 1st ever successful P52 in the LM [13:25:48] and I credit my T16000M for it [13:26:15] Its the 1st time I try a LM P52 with it actually [13:27:34] Very nice [13:27:43] I have been using AGS pulse and my numpad [13:27:46] Works well [13:28:03] right [13:29:02] one thing though, in the P52 PICAPAR checklist, on the 2nd star it says to switch PGNS mode control to off [13:29:50] So does that mean youre supposed maneuver with ACA hard-over? [13:30:04] Nope, copy paste error [13:30:27] haha I thought so [13:31:14] Thanks [13:31:19] All fixed [13:32:21] thanks [13:32:47] One thing about this P52 is that I shot right through my Phasing TIG lol [13:33:39] Timing problem? [13:34:18] yes... Me being slow [13:34:23] Oh haha ok [13:34:24] haha [13:35:21] Well I had half an hour to do it, plus get ready for the phasing burn. Maybe a bit tight but I think it would be possible [13:40:00] I think that was the actual timeline as well [13:40:13] Well, based on the procedures for phasing [13:40:19] And they had 2 people :P [13:41:02] right [13:42:42] Back to what we were talking about before: I just came up upon a "Switch to CM" after the P52, So I switch to it and now the next thing on the CM checklist is "P20 Rendezvous Navigation" [13:43:57] So I am thinking that it could say "Switch to CM to perform P20 Rendezvous Navigation" or something like that, I think it would be more helpful then just numbers (and cleaner) [13:44:55] Or "Switch to CM, carry on with P20" [13:46:08] just thoughts for now of course :) [13:49:10] No i like the idea [13:51:22] also I think that the MNVR to 0,70,0 after the SM RCS SEP burn is missing in the checklists MFD [13:51:30] for the CSM [13:53:25] Also here in the checklists this is a bit confusing the section that starts with 93:10:00: [13:53:28] https://www.dropbox.com/s/r0aprztvfi3ca9c/Screenshot%202018-08-24%2009.52.29.png?dl=0 [13:54:49] The end of that section seems to be items at the end when the 2 vehicles come back for rendezvous, but it all seems to be part of a checklist you do at 93:10:00 [13:55:19] Ok for the maneuver after sep, that has been added [13:55:52] Yes [13:55:57] Second part thats correct [13:56:07] I only have 2 P20s in there for the CSM during all of the LM maneuvers [13:56:30] That P47 is for after the LM is back [13:56:41] I think tht adding more times to separate the parts would help [13:56:50] I cant because the time is so different [13:56:53] not just all bunched in the 93:10 part [13:57:18] 93:10 is only for the first part of that not the whole thing [13:57:27] I can add a subheading to separate them though [13:57:49] right, and you switch to LM after the 1st P20 [13:58:11] and then I guess at the right time it will switch you back for the 2nd P20 [13:58:19] Yeah [13:58:30] But I have added a subheading to split it up better [13:58:38] the issue is I just got switched back, but havent even done phasing burn yet [13:58:52] so Ive started doing the P20 check right now haha [13:59:01] *the 2nd P20 [13:59:08] But yeah I think that idea would be good [13:59:26] Yeah the switching back and forth gets confusing especially with how often [14:03:01] I think one of the P20s might not be necessary [14:03:04] At least for now [14:04:07] But I will leave it as is until I go make the switches more streamlined [14:04:32] So I think the "Switch to CM" just before "Perform AGS Update" in the Phasing checklist may not be required [14:05:12] I was looking at that one just now [14:05:53] Ok so the sep burn is done [14:05:59] switches to lm for target dv [14:06:07] switches to csm for the first P20 [14:06:32] That seem right? [14:08:07] I think the switch in the phasing checklist is the one I will take out, along with a p20 [14:10:17] yeah that makes sense [14:17:11] So do you enter the N86 from the DKSY into the AGS, or from the PAD? [14:23:10] A good question [14:23:20] I honestly don't know [14:23:35] The checklist is set up right now to use the DSKY because there was no MCC when i put it in there [14:26:39] ok [14:26:58] also is the whole burn at 40%? Or do you go to 100% after 26s? [14:27:13] All 40 [14:27:19] BT is supposed to be 25 seconds though [14:27:25] Yep [14:27:44] 40& takes a few minutes [14:27:48] 40% [14:28:34] It shouldnt for phasing [14:28:51] 15 seconds at 10% and 10 at 40% [14:29:13] Whats your dV? [14:29:25] 83.7 fps [14:29:30] Yeah thats right [14:30:10] ahhhhh [14:30:25] I put in 837 fps into the AGS [14:30:31] Whoops [14:30:33] the scaaaaling lol [14:30:35] I forgot [14:30:36] Yes [14:30:52] Ive done it too [14:31:07] And actually the actual AGS on 9 was scaled the same [15:09:00] Hmm I am not getting the TLI abort PAD's after the +25h one as I am supposed to per the flight plan [16:46:48] morning! [16:49:20] good evening [16:49:24] o/ [16:50:45] rcflyinghokie, TLI abort PADs? [16:51:43] what GET [16:55:11] Hey [16:55:14] 11:55 [16:55:15] hey [16:55:28] Supposed to get a bunch [16:55:35] +35 +44 +53 [16:55:39] Along with the +25 [16:55:49] Unless I am misreading [16:57:03] yeah [16:57:24] does it not show the 4 at once? [16:59:36] Yeah i am blind [16:59:50] They are just all bunched together I didnt notice [17:00:06] Maybe spaces in between would help? [17:00:52] Or me paying better attention [17:00:57] haha, yeah [17:01:23] that's basically how the real PAD looks like. It has a slightly thicker line between each part [17:01:24] Sorry about that [17:01:40] Yeah ANY line would have helped [17:01:45] trie [17:01:47] true [17:01:54] But no big deal [17:02:11] I'm not sure how I can do that with annotations [17:02:22] but annotations have their shortcomings anyway [17:02:35] sometimes it is hard to see the number from e.g. a long Maneuver PAD [17:02:37] Even spaces would work [17:02:49] Something to differentiate the 4 [17:02:50] yeah, I can add an empty line between entries [17:02:56] Theres plenty of room [17:03:02] Hey AlexB_88 throw your idea about the "Switch to CM/LM" to Niklas see what he thinks [17:03:50] Shuttle got a printer at some point, so they got some PADs printed out for them, haha [17:04:50] like here on the last pages: https://www.nasa.gov/pdf/568162main_fd03_expk.pdf [17:04:54] that is service, haha [17:04:59] I'll be back in a little [17:05:02] Nice haha [17:06:03] yeah I was thinking of making the "change to LM" or "change to CM" in the checklist MFDs to have a description after each of them to tell you where in the checklist you pick up from after you switch ships [17:06:27] like "change to CM & carry on with P20" [17:33:56] sorry, had to go afk for a bit [17:34:10] I know what you mean, some message that makes it a bit more clear would be good [17:34:48] and rcflyinghokie, it seems I can't add an empty line to it. Something with the annotations doesn't like that. [17:36:14] maybe a row of dashes? '-----------------'? [17:37:00] ah right, let me try that [17:38:09] yeah, that works [17:51:00] The MCC3 maneuver PAD, isnt that supposed to come at 51:15? [17:51:06] It came for me at 51:25 [17:51:25] I guess I am splitting hairs there because the uplink is scheduled at 51:15 [18:05:36] yeah I usually put the two (uplink and PAD) together [18:05:47] and used a time in between [18:06:11] did you get a PAD or did you just mean the scrubbed message? [18:11:21] I got a PAD [18:20:09] MCC-2 didn't go well? [18:20:56] Oh i overburned it [18:21:07] I wanted an MCC3 because of a potential time issue [18:21:23] time issue? [18:21:52] Right now the "start PTC" happens before the burn if the burn is scheduled [18:22:13] So i went back and overburned my MCC2 a little to generate an MCC3 [18:22:19] ah, ok [18:22:34] Nothing on your end is wrong dont worry [18:22:37] so the burn criteria for MCC-3 and 4 work, haha [18:22:45] Yeah [18:23:06] either a pericynthion altitude violation or the altitude of the node [18:23:55] what's the DV? [18:24:00] Well my flyby PC was 46 [18:24:13] I am about to have one pop up I'll tell you shortly [18:25:19] noticed a bug with the SPS/RCS decision for MCC-3 and 4 [18:25:29] doesn't take the LM mass into account [18:26:02] Its RCS [18:26:10] 4.6 [18:26:15] how long a burn? [18:26:36] 35s [18:26:42] yeah, that's bad [18:26:47] it would be SPS [18:27:07] anything stopping you from burning it with the SPS anyway? [18:27:23] trim gimbal angles should be the same as before [18:27:43] Nope I can burn it with SPS [18:28:39] for heavy CSM+LM the threshold would be about 3 ft/s [18:28:44] 0.5 seconds burn [18:29:17] hmm [18:29:24] but then there also is a mission rule [18:29:33] "SPS MCCs should be greater than 3 sec" [18:29:41] really not sure about your scenario [18:29:53] I have to add more logic for that [18:30:43] https://www.dropbox.com/s/d8nyipkim9gn747/Screenshot%202018-08-24%2014.30.07.png?dl=0 [18:30:43] I doubt they would want a 35 second RCS burn [18:30:49] Theres the PAD [18:31:06] And I just noticed my FOV changed again haha [18:31:21] Probably my middle mouse wheel [18:32:11] they probably would wait until MCC-4, if the burntime becomes greater than 3 seconds due to that [18:32:31] if not then MCC-3 is ok as well [18:33:35] I think for simplicity, in your case, I would burn MCC-3 [18:33:49] and I'll think about adding more maneuver decision logic [18:33:56] MCC-3 with the SPS that is [18:35:16] Ok [18:36:12] Apollo 15 for example burned MCC-2 and 4 [18:37:24] gave the ground tracking some trouble to do MCC-4 though [18:37:51] their DOI had an out-of-plane DV because their LOI state vector wasn't so good [18:38:33] indy91, so I did the phasing burn this morning, should have remembered the scaling. I had targeted the AGS for an 837 fps burn, instead of 83.7 fps [18:39:10] fun [18:39:26] orbit would be intersecting the atmosphere, right? [18:40:22] yeah, should [18:40:26] 133 circular [18:40:37] 84 ft/s to give roughly 10NM up and down from the CSM [18:40:45] 840 would be 100NM up and down [18:40:49] anyways, well say that your MCC calculations would have broken down after that haha [18:40:50] so a 33x233 orbit [18:41:11] yeah, it probably wouldn't have liked that much [18:41:23] that's what the maneuver evaluation will be for, haha [18:41:44] immediate CSM rescue burn :D [18:42:19] fun [18:42:32] so now I am coasting with P34 targeting TPI0 [18:43:38] I am a bit unsure of how this TPI update form is supposed to be filled. Is it just for the onboard calculated solutions that are entered on it, or Is the MCC one filled in on it as well? [18:44:45] I think it's for the ground update [18:45:00] so only ground update [18:45:34] I'm not sure if Apollo 9 had anything like the Data Cards [18:45:34] oh and I guess you enter the N81 Dv in the bottom left corner [18:45:44] dont think so no [18:46:08] well on the CSI PAD it's pretty clear [18:46:15] PGNCS and Charts section down below [18:46:25] same for CDH [18:46:31] same for TPI really [18:46:54] yeah [18:47:33] the MSFN part is where the ground calculates the same things as the LM, but with their state vectors [18:47:55] and everything above is a full ground solution [18:49:04] my TPI0 DVR is 5.7 [18:51:08] ok [18:51:12] but N81 are -18.6, 0, -0.5 [18:51:12] is that good or bad? :D [18:51:34] oh, haha [18:51:40] I believe the 5.7 is meter per second [18:51:42] would it not be closer to 18 fps? [18:51:44] how did that slip through [18:51:56] oh lol [18:52:08] whats a meter? [18:52:11] :D [18:52:17] I use it all the time [18:52:41] and then convert it to ft/s [18:52:55] yeah well I guess the AGC itself does that [18:53:10] looks like I just forgot a " / 0.3048" for the Apollo 9 TPI PAD [18:53:14] fixed [18:54:31] oh and I guess I am supposed to re-enter P34 N37 with the ground TIG? [18:54:43] thanks [18:58:23] not sure about that [18:59:00] you got the initial guess for it earlier, on the phasing PAD [18:59:11] ground solution is with perfect state vectors of course [18:59:23] right [18:59:30] oh [18:59:37] and it's using that initial guess still for the TIG [18:59:42] which I think is right [19:00:09] not enough time for tracking [19:00:26] I have to check that in the transcript though [19:00:42] if the TPI0 TIG on the Phasing PAD and the TPI PAD were identical [19:01:25] So My MCC N81: -18.6, 0, -0.5 [19:01:50] PGNS N81: -18.0,+2.1,-7.6 [19:02:06] 'I guess that DVZ is kind of odd [19:02:25] will be because if the different TIGs [19:02:28] of* [19:02:43] ok [19:03:25] 94:57:53 on both Phasing and TPI PAD [19:03:38] so I did it right [19:03:55] there was a lot of debate in Tindallgrams on what TIG to use [19:04:29] fixed TIG from before phasing, updated TIG from MCC-H, or the P34 TIG search [19:04:42] I do believe they ended up using the updated P34 TIG [19:05:28] oh, btw, what is the TIG on your TPI PAD? [19:05:58] vs. the one P34 gave you [19:07:30] TPI PAD: 94:55:56 [19:07:47] P34 N37: 94:53:53 [19:08:07] very interesting [19:08:18] rcflyinghokie, for us both the rendezvous timeline was late, right? [19:08:27] Yeah [19:08:31] it was at 5-7 minutes off or so [19:08:40] yep [19:08:53] Maybe the fixed maneuvers preceding it? [19:08:56] so the new properly circular orbit and the different targeting for SPS-2 to 4 seems to improve that [19:09:40] CDR to CMP: "I just wanted to tell you we got another solution on an elevation angle of 25.05" [19:10:01] would the say that if they were letting P34 calculate the TIG for a specific elevation angle? [19:10:42] Well either they used that [19:10:52] Or they let ti determine an elevation based on tig [19:10:53] it [19:11:57] yeah, sounds more like they used the fixed TIG [19:12:02] and got an elevation angle from it [19:12:29] Unless it came from a chart [19:12:32] they wouldn't get an angle otherwise [19:12:35] hmm [19:13:03] don't think so [19:13:23] aha! [19:13:25] mission report [19:13:36] And the answer is...... [19:13:46] "terminal phase targeting used the time option of program 34" [19:13:50] There ya go [19:14:00] So leaving the elevation blank [19:14:23] Isnt that how you do a time option? [19:14:24] so all that talk in the Tindallgrams about how well the elevation solution iterates in the football shaped orbit... for nothing [19:14:29] yeah, 0 there [19:15:28] and more good stuff from the mission report [19:15:42] might have never read this crew procedures part [19:15:57] about the time biases [19:16:28] "the biasing was necessary because the onboard software used Keplerian orbits (conic) and instantaneous velocity changes to simplify and expedite maneuver targeting" [19:16:42] so based on that I would conclude we in fact need the biasing [19:16:58] so I leave the elevation blank in P34? [19:17:05] well, all zeros [19:17:15] Luminary doesn't use any more integrated trajectories for the rendezvous than Sundance [19:17:15] right [19:17:24] and the planned TIG [19:17:43] from Phasing and TPI PAD [19:17:56] ok [19:17:57] Ok so what changes do I need to make [19:18:35] in the TPI0 part, the occurances of 27.5 to 0 [19:18:42] +02750 I guess [19:18:44] hmm [19:19:18] but then on each recycle it will not display the TIG again [19:19:41] so not 06 37, but 06 55 instead [19:19:52] where they would be able to see their elevation angle at the fixed TIG [19:20:53] Weird that this procedures doc doesnt have that [19:21:10] so my N55 now says +03076 [19:21:29] with the fixed TIG, and +00000, +13000 [19:21:34] normal would be 27.5 [19:21:43] in the transcript they got a 25.05 solution once [19:22:01] so yours isn't too far off [19:22:22] procedures doc is from late January [19:23:07] in Don Eyles book, the part where he talks about who or what was to blame for the 1201/1202 alarm, he said there were 100s of procedure changes in the month before launch, haha [19:23:56] that alone is also a cause of such issues [19:24:11] I guess only the final versions of crew checklists tell the full story [19:25:20] Damn greedy collectors :P [19:25:44] I could go full Indy Jones on that topic [19:26:31] Well as a parallel, I was feeling all "national treasure" at the air and space museum :) [19:26:59] maybe we get some Apollo 9 Flight Data File stuff from David Scott [19:27:12] he donated all his Apollo 15 documents apparently [19:28:02] so there is a bit of hope [19:28:04] That would be nice [19:28:32] Ok SPS MCC3 complete [19:28:40] oh, N55 now 29.98 [19:29:14] yeah, you have a pretty high attitude rate at TPI0 [19:29:25] so small SV updates by the RR can change it by a lot [19:30:02] so a NASA website says NARA got flight data files from all Apollo missions [19:31:11] thewonderidiot, how would we go about searching for that stuff? [19:33:11] https://catalog.archives.gov/id/573157 [19:34:09] so final N81 was very close to the PAD [19:34:31] yeah, with the same TIG that is expected [19:34:34] right [19:34:59] so this procedure will be also used for the actual TPI? [19:35:11] nope [19:35:20] actual TPI is from coelliptic orbit [19:35:30] so there the elevation angle option will be used [19:35:58] So are all of the TPI0 P34's done with the time option? [19:36:34] yes, the TPI0 stuff [19:38:09] the ground determined one that already was fixed before Phasing [19:40:02] And what about a bias [19:40:11] Not for TPI0 right [19:40:25] yeah, I don't think there was one for that [19:40:30] just CSI and CDH really [19:40:50] the ones from the rendezvous procedures should be good [19:42:38] Ok [19:42:53] And that is added to what, the pad time? [19:45:03] And is it added or subtracted [19:48:49] added to the PAD value [19:49:02] in P32, 3 minutes added to the TPI TIG input [19:49:22] in P33 1:45 added [19:49:45] uhh, wait [19:50:08] in P33 they bias the CDH TIG [19:50:10] hmm [19:51:38] I'm not sure, but I don't think that is necessary [19:51:51] because in Sundance they target the next apsis [19:52:13] 1:45 is quite a bit when you want to have CDH at a specific DH [19:53:03] I think we should try it once, but I don't think that 1:45 bias in P33 is necessary [19:53:07] I am like 60% sure :D [19:53:11] Haha ok then [19:53:22] Alex, would you be willing to try a biased and non biased CDH? [19:55:50] hmm, that might be even easier [19:56:00] we have Coelliptic calculation page [19:56:24] just need to input the same DH as P32 came up with and calculate the TIG for CDH [19:56:33] and then compare to the P33 TIG [19:56:43] after CSI has been performed [19:58:26] or if that sounds too convoluted, just give me a scenario after CSI :D [19:59:16] but I am fairly sure now that CSI itself will need the bias [20:00:23] I really should set up some calculation for that [20:01:23] once I get CSI out of the way all send you a scenario [20:02:17] Wont be until Monday morning unfortunately [20:02:28] no problem [20:02:40] I can keep busy putting Columbia in the water [20:02:48] and fixing whatever Ryan wants me to fix :D [20:02:56] I might have time to burn insertion tonight, but I work over the w-e [20:02:58] haha nice [20:03:26] I am going to get my insertion PAD right about now actually [20:04:47] Checking out Eagle [20:04:58] Glycol is 49, cabin 69 [20:05:07] Temps look good [20:07:02] how about secondary glycol loop? [20:07:13] or should I not ask about that? :D [20:08:22] by the way its about 500 degrees in Spider right now [20:08:35] Just kidding ;) A nice and toasty 80 [20:08:52] Haha yeah after 11 I really want to get back into the ECS [20:09:17] Uhh sec loop I don't want to know :P [20:09:31] Once I get those radiators in though, should be a lot better [20:09:51] Radiators as heat sinks I mean [20:10:04] any luck with the glycol and time accel yet? [20:11:09] Havent even tried [20:11:20] That will be part of my ECS work round 2 [20:12:42] indy91: http://www.ibiblio.org/apollo/NARA-SW/Rg255-1.doc is the best index we have [20:13:15] password? [20:13:31] ah [20:13:34] just for editing [20:13:34] ok insertion pad looks good +39 fps DVX [20:13:54] 3 minutes early [20:14:49] "APOLLO FLIGHT DATA FILE CHANGE CONTROL RECORDS. " that sounds fun [20:15:14] and it apparently does have final versions [20:15:27] only problem [20:15:28] "Arranged by mission (Apollo 12 to 16) and thereunder by subject." [20:17:44] but the section I discovered earlier "E.159. PRE-SHUTTLE FLIGHT DATA FILES. " should have basically all missions [20:17:51] "1968-1977" [20:18:13] so if we want to spent some money [20:18:37] there probably is a way to get the checklists we most desire [20:20:30] maybe we can ask them first what documents are there? [20:20:55] I think Mike mentioned they are helpful with that, and it doesn't cost anything [20:21:09] like, what Apollo 9-11 checklists they even have [20:22:26] Absolutely [20:22:34] PR up with checklists [20:22:51] Also added (commented out) nitrogen and fixed the initial o2 calculations for earth [20:23:17] PR up with checklists from NARA, impressive :D [20:23:24] You wont notice a thing, just the rounded off values were killing me in the config so I recalculated them [20:23:29] Hey what can I say.... [20:23:34] :P [20:23:38] I wish [20:23:59] slighty more precise values are acceptable [20:24:35] merged [20:24:40] User wont even notice [20:25:00] But I am excited about the nitrogen [20:25:29] All I need to figure out is a way to get a 60/40 mix in the cabin before launch, and connect the waste stowage valve as a vent [20:26:24] how did they even get rid of the N2? [20:26:38] just vented their atmosphere out all the time? [20:26:42] until it was gone? [20:27:41] Yeah [20:27:44] That was the cabin purge [20:27:49] Through waste stowage [20:28:17] A lot vented out during boost of course [20:28:37] And then they slowly purged the rest using the waste stowage valve [20:28:54] There was always a residual N2 level I am sure [20:28:58] yeah [20:29:57] indy91, are you going to target the planned or actual splash point for Columbia? [20:30:32] good question [20:30:37] planned [20:31:54] Apollo 11 was the first mission to use a nominal target not on the MIDPAC contingency target line [20:32:00] so nominal is not 165°W [20:32:35] right [20:33:12] I think they even had some latitude targeting for TEI [20:33:21] I think planned is the good option too. I think in reality they had a last minute change due to a storm or something? [20:33:49] yeah [20:33:53] so they landed long [20:34:07] simply by loading an entry target for the CMC which was further downrange [20:34:17] and they got P65 for a few seconds [20:48:14] hmmm, I never thought about asking them what they have, heh [20:48:22] for that sort of thing [20:48:37] I've only attempted to request things they may or may not have, like AGC schematics [20:48:51] and the only thing I got a hit on was the Grumman level 3 schematics :) [20:50:04] well if they have nearly complete documents, then I know what to request [20:50:27] then go for it :D [20:50:33] and if I start going down that road then I might as well get some RTCC documents... [20:50:47] but it's almost certainly gonna cost money [20:50:59] the scan requests [20:51:04] not them asking to look, right? [20:51:43] and, I think I asked this before, is this a service open to anybody? Even non US people? [20:52:00] how even does their payment work [20:52:45] https://www.orbiter-forum.com/showthread.php?p=580325#post580325 [20:53:33] I like how you use the External MFD like a cue card attached with velcro [20:53:47] Nice to finally have screens of the LM without a bunch of lit C/W lights :) [20:54:02] I think so -- not sure [20:54:14] asking them to look is probably fine? worth a shot [20:54:36] "Forms of payment we accept are money order, check, and debit / credit cards." [20:54:45] ah, debit cards [20:54:46] Alex, what is driving the LMP ball? [20:54:46] for credit cards, you call them and give them your card number [20:54:48] that's good [20:54:51] haha I needed lots of velcro to hold a screen up ;) [20:55:00] AGS [20:55:13] No alignment? [20:55:27] Or is ordeal driving the cdr ball [20:55:30] yep its aligned [20:55:32] yes [20:55:34] Ah ok [20:55:40] I usually do it the other way :P [20:55:45] Thats why i was confused [20:55:46] oh lol [20:55:55] I did a bad with the ORDEAL on 11 [20:56:08] Uh oh [20:56:19] I had aligned the CSM IMU from the landing REFSMMAT to the ascent REFSMMAT [20:56:28] very similar, just a bunch of degrees difference [20:56:34] like 15 or so [20:56:46] but then was too lazy to do the GDC Alignment [20:56:58] so I had one FDAI with ORDEAL and one with the wrong alignment [20:57:12] that confused me a bit when I was doing maneuvers [20:57:17] Oh oops [21:00:47] back in a few [21:02:22] good night! [23:03:50] hey @rcflyinghokie1 [23:03:57] Good evening [23:04:09] did you do any apollo 11 checklist stuff yet? [23:04:18] Yeah I am through Mcc4 [23:04:36] Through MCC3 was pushed to the main repo today [23:05:16] so if i started 11 now would i be good as long as i dont get ahead of you or would i have to wait? [23:06:41] Yep you would be just fine as long as you dont get ahead haha [23:07:48] also i really screwed up on my Innsbruck approach i nearly crashed into a mountain then i tried to land but skidded of the runway [23:08:21] Not good lol [23:24:17] .tell indy91 the PC+2 block data seems to come a bit early, should be coming around 70h, only 10 minutes but thats when its expected instead of 69:50 [23:26:25] .tell indy91 does it come at the same time for MCC4 scrubbed and not scrubbed? [23:43:21] .tell indy91 also the LOI pad comes at 73:14, seems a bit later than the flight plan (73:02), is there a reason? [23:58:02] night! [23:59:27] night! [08:42:50] . [12:32:34] Good morning [12:34:24] good morning [12:34:42] Niklas i am starting apollo 11 [12:34:51] and i actually will do it instead of just saying it [12:35:28] Haha good [12:36:02] started it last night right up to 6 minutes before launch [12:37:11] Oh, I recommend you go in to your scn file and increase your suit heat exchangers in the CSM [12:37:53] i would if i knew how [12:37:56] I have a PR up to do this but you can exit the scn to do it as well, otherwise the suit temp hovers in the low 70s instead of 50s as it is supposed to [12:38:24] just open up your current scn file in visual studio [12:38:44] search PRIMSUITHEATEXCHANGER [12:38:53] You will see 3 lines like this [12:38:54] could i just do it in notepad? [12:38:55] PRIMSUITHEATEXCHANGER 1 283.000000 284.000000 10.000000 0 [12:38:55] PRIMSUITCIRCUITHEATEXCHANGER 1 283.000000 284.000000 10.000000 0 [12:38:56] PRIMCABINHEATEXCHANGER 1 294.000000 294.500000 10.000000 0 [12:39:01] Ehh I dont know [12:39:15] You are using VS to compile anyways right? [12:39:15] i have edited scenarios before in notepad [12:39:29] i am not sure what you mean by that [12:39:56] What do you do to get an updated version of NASSP [12:40:17] just download the build and paste into my orbiter beta folder [12:41:14] Oh never mind then [12:41:23] found the three lines [12:41:30] Ok [12:41:40] Last number on the 3 has a 5 for you right? [12:41:48] second to last* [12:42:05] "5.000000" or something [12:42:25] yes on the third line [12:42:53] All 3 of the lines I pasted in there should have a 5 for you [12:43:27] You can simply just copy what i pasted in here and replace your lines with them [12:43:32] okay [12:43:35] Same with [12:43:36] SECSUITHEATEXCHANGER 1 283.000000 284.000000 10.000000 0 [12:43:37] SECSUITCIRCUITHEATEXCHANGER 1 283.000000 284.000000 10.000000 0 [12:43:38] SECCABINHEATEXCHANGER 1 294.000000 294.500000 10.000000 0 [12:43:50] thanks [12:44:14] It's minor but it helps keep the suit tem right [12:44:17] temp [12:45:43] also i did the Innsbruck approach [12:45:53] just barely missed the mountains [12:46:40] Did you skid off again? [12:49:14] nope [12:49:56] i am guessing you have done with approach many times [12:50:53] Not super many but enough to know how dangerous it is [12:51:43] funny how for me this approach is a bit more difficult that landing on the moon with nassp [12:53:15] Its a lot going on at once [12:57:34] well i am going to launch now and i will talk to you after tli and transportation and docking [12:57:58] Enjoy [12:57:59] and i assume mcc1 was scrubbed just like 10? [12:58:22] Yeah [12:58:27] okay\ [12:58:31] Assuming your SPS evasive goes well [12:58:31] see you later [12:58:48] oh i have done with sps evasive maneuver many times [12:58:56] the* [13:06:54] hey guys [13:06:57] Morning [13:07:15] I always edit my scenarios in text editors [13:07:21] Notepad++ usually [13:07:39] I'd trust notepad++ over notepad :P [13:08:02] about the timing of MCC updates [13:08:15] usually I combined an uplink and PAD of they belong together [13:08:42] and I chose some time in between the PAD and uplink times from the flight plan [13:09:26] and another thing I am usually doing is when another updates comes soon after the last one, then I don't use a mission time or X hours after TLI but time since the last updated ended [13:09:29] I get the LOI PAD just before 73:14, then the TEI-1 just before 73:59 [13:09:31] has to be done that way really [13:09:48] or else it could happen that you only have a few seconds to copy a PAD [13:09:56] those are sufficiently far away from each other [13:09:58] Well there is a lot of time between these ones [13:10:11] I see the TEI-1 and 4 have a 5 minute gap [13:10:12] so I did not use SubStateTime with the TEI-1 one [13:10:24] yeah, 5 minutes to write down the PAD [13:11:00] I will gladly update any timings of PADs if they are off by more than 10 minutes or so [13:11:00] Nominally the LOI uplink comes just after 70h [13:11:17] *73 [13:11:50] you are sticking to closely to the flight plan I think [13:12:06] Well I need to have some way to trigger the checklist mfd [13:12:11] main reason the uplink and PAD are a few minutes away from each is other is that they wouldn't fit in the flight plan otherwise [13:12:31] -is other [13:12:38] Oh I am not concerned with the timing if its per FP or not [13:12:48] I just need to know when they trigger is all for the checklist [13:13:06] well roughly at the time they are in the flight plan [13:13:18] close to LOI they are relative times to LOI [13:13:31] and other Apollo 11 missions are usually 5 minutes late from the flight plan [13:13:37] so that alone already accounts for 5 minutes [13:13:58] and then if I rounded up the time of the uplink to be at the same time as the PAD, then you can easily get 10 minutes "delay" already [13:14:23] So i guess a "Wait for MCC" is prudent versus a time [13:14:38] thinking about the actual missions, it often happened that the crew saw an update in the flight plan and then asked if it is ready [13:15:01] with the MCC you currently just have to hope and wait it is coming [13:15:38] I'm not sure how to solve that really [13:15:55] I will just add a "Wait for MCC Update" pause in there [13:16:39] for later missions (Apollo 14 and later) they rather changed the onboard time than diverge from the flight plan [13:16:51] for those it would make sense again to use fixed times for checklist and MCC [13:18:08] if you have any ideas on how to make that more user friendly in the MCC, let me know [13:18:29] but right now most GETs in the checklist can only be roughly estimates [13:18:46] as I said, if it's off more than 10 minutes, then you should tell me and I can adjust some things [13:19:33] Sure [13:19:37] so was anything off my that amount? [13:19:41] by* [13:20:13] PC+2 was 10 minutes off [13:20:30] But everything else is about right [13:20:42] ok, let's see [13:20:53] it's at 5 minutes after the MCC-4 update [13:21:09] which itself might be 5 minutes late, because LOI will be 5 minutes late [13:21:28] MCC-4 update at LOI - 6:25 [13:21:37] or rather pericynthion time [13:22:20] Ok I will add another wait trigger then [13:23:21] What are the MCC-1 thru 3 triggers [13:26:20] TLI+7:10 [13:26:32] TLI+22:40 [13:26:47] LOI-24:40 [13:27:26] Ok [13:27:32] I added "wait for" triggers instead [13:28:30] yeah, might be a bit better [13:28:47] I can try to add a feature where you find out when the next update is coming [13:29:00] like MCC says "10 minutes to update" [13:29:40] A message that stays up? [13:30:07] Hmm or maybe, not sure if this is too much, but an option in the menu to request next update time? [13:31:28] that's what I meant [13:31:40] an option where the use can ask the MCC when the next update is coming [13:31:42] user* [13:32:20] now that I think about it, that would be very tricky to implement [13:42:57] Yeah I can imagine some hiccups [13:43:49] mostly because it's so many different events [13:44:09] TLI/LOI etc. relative, SubStateTime, sometimes even ground contact [13:45:30] I alternate between flying Apollo 11 and implementing some new RTCC MFD stuff right now [13:45:38] descent abort constants right now [13:45:46] probably not going to be ready by the time you get there [13:45:48] but we will see [13:48:14] I am streamlining LOI procedures now [13:54:20] So this pitch up to observe lunar surface step [13:54:40] I can't see the lunar surface haha [13:54:54] hey Niklas [13:55:23] i am just before the earth orbit state vector update [13:56:34] also right after insertion i get a "thread started, thread completed" [14:00:11] TLI evaluation [14:00:16] Nothing to worry about [14:00:24] Its just working behind the scenes [14:02:22] rcflyinghokie, same, couldn't see anything [14:03:01] Ok [14:39:54] indy91 what is the trigger for the LOS Map update? [14:42:21] LOI minus what time [14:42:32] LOI-0:40 [14:42:36] Thanks [14:42:57] is that PAD looking reasonable? [14:43:06] it caused me a bit of trouble when I got there [14:43:09] had to fix some things [14:43:18] LOS 75:51:50 [14:43:26] AOS with 76:25:50 [14:43:34] AOS without 76:15:52 [14:43:38] Looks reasonable [14:44:05] yeah [14:44:07] great [14:44:24] and that's the only map update you are going to get, haha [14:44:30] Noted :P [14:49:15] Moon ahoy [14:49:41] LOI time [14:52:03] i assume t+90 means tli plus 90 minutes right? [14:53:18] I did a bad, left a main bus tie on after the initial gimbal checks :/ [14:53:32] Looks like I am tying Bat C for LOI [14:54:05] astronauthen96__, yep [14:54:21] and i almost left the suit compressor on main bus b after the redundant component check [14:54:45] Should just switch one off and the other to main A when you do that [14:55:03] okay [14:55:27] i remember my first 11 mission it was really using up fuel cell c if i remember correctly [14:59:09] Hmmm my second P40 RPY is different from the PAD RPY [14:59:57] do you reenter the values in p30 [15:00:07] Yes [15:00:17] P40 pitch 178 [15:00:22] PAD pitch 227 [15:00:29] oh that's bad [15:00:45] When i first called P40, for the gimbal checks, the P40 RPY was spot on [15:00:50] Now, not so much [15:00:51] check P30 again [15:01:20] N81 values are different [15:01:21] maybe you did a typo with the DV [15:01:30] Thats why [15:01:38] Why would they change [15:01:46] yeah, when you got P30->P40->P30 it already has done the finite burntime compensation [15:01:50] so the DV vector is rotated [15:01:53] they change for me too [15:01:58] Ahh [15:02:15] so you really have to reenter the DV in P30 again with that sequence [15:02:22] and not just PRO through P30 [15:02:26] is that what you did? [15:03:25] Yep [15:03:35] yeah, that explains it then [15:03:38] "Reload N81 values" [15:03:41] Is right in the FP [15:03:57] yep, that's the finite burntime compensation of the AGC, done in P40 [15:04:08] it's not such a great compensation though [15:04:36] so in the RTCC I have to first calculate a compensated DV and then in addition compensate for the AGC compensation, lol [15:05:12] Haha well I have made a note in the FP to make sure its clear [15:05:36] can be confusing for sure, just one of those "gotcha" things in the AGC [15:06:50] Hmm another question, If I want to rotate around that 0.2 deg/sec, what is the best course for that [15:06:59] CMC FREE and pitch? [15:07:24] Or SCS, pitch accel [15:08:29] yes [15:08:31] haha [15:08:35] both ways work [15:08:41] I usually go the SCS way [15:08:45] att hold for yaw and roll [15:08:51] and accel cmd for pitch [15:09:18] Yeah thats how I am writing it in the checklist here [15:09:24] Thats what I usually use [15:16:24] Worked nicely as expected [15:16:33] Good ol 30 minute pitcharound [15:17:22] yeah, haha [15:17:27] All for no moon [15:17:34] indeed [15:21:43] Ok lets try this LOI finally [15:22:36] indy91 is it LOI-40 for that update or PC-40 [15:22:47] PC-40 [15:22:50] not LOI ignition [15:22:51] hmm [15:22:53] but [15:23:03] it saves a new LOI time when it calculates [15:23:05] LOI [15:23:11] so it might be LOI TIG after all [15:23:27] Well its coming up just before 75:24 [15:23:54] PAD TIG is 76:00:20.36 [15:24:19] so pericynthion time [15:25:41] Ok [15:36:56] Are the angles good for both sextant star checks before LOI? [15:37:27] Guess so :) [15:40:14] same attitude, so probably [15:41:45] 11 minutes to go [15:47:31] oh, I almost forgot about this! [15:47:39] today was a good day in Orbiter development [15:47:57] look what finally has been fixed [15:47:58] Bug fix: vessels landed at simulation start did not scan for grevity sources and therefore returned a zero weight vector [issue #1318] [15:48:36] remember when we had trouble with our accelerometers while landed? [15:48:38] Yes! [15:48:49] first solution was to add a force for a short bit to trigger it [15:48:58] right now the solution is a fake weight vector [15:49:07] but soon that can be removed, because it's fixed! [15:49:09] Now we can remove the fake vector [15:49:29] Oh I shouldnt be talking though, I am LOS :P [15:49:54] cya on the other side [15:50:09] at 76:25:50 hopefully [15:51:57] my tli took a bit longer than last time [15:54:34] yeah [15:54:45] it now does the mixture ratio shift properly [15:54:54] at about 2 minutes into the burn or so [15:54:59] changes thrust and specific impulse [15:55:50] that should have been working a while ago, but there was a bug that did the mixture ratio change shortly after ignition already [15:58:14] so for the first two minutes of TLI it has a lower thrust than before, which leads to a longer burntime now [15:59:45] Residuals -1.0 +.1 -.1 [15:59:48] Not bad [16:00:19] N44 169.0x60.3 [16:00:35] Pretty good targeting :) [16:02:19] good enough, for sure [16:08:38] Assuming my orbital elements are correct [16:08:58] pushed my latest state. Has a few updates from lunar landing on, none before I think [16:11:16] Ok did they use DAP orb rate here after LOI? [16:11:37] don't think so [16:12:15] Ok [16:14:01] Wow [16:14:12] orb rate ball exactly on P315 at AOS [16:14:45] Impressive [16:15:31] your orbit must be just as expected [16:16:56] Ok I am going to PR my checklist through LOI 1 and run some errands [16:18:49] Back in a while [16:19:31] cya later [17:15:41] @indy91 i see Ryan made a pull request for checklists through loi 1 will that get pushed today just curious [17:16:55] hmm, let's see [17:17:07] merging is a long and difficult process. Let me start doing that [17:17:11] done [17:17:42] just didn't want to spam the Orbiter Forum with build messages :D [17:18:24] i usually go to bed at 11 and its 10:am here and if i am motivated enough maybe i'll be in lunar orbit tonight or maybe in the afternoon [17:18:57] the mission support is theoretically complete for Apollo 11 [17:19:07] I am just past MCC-6 on the way home with testing [17:19:13] very nice [17:19:19] so there will be one or two adjustments, but I don't expect anything big [17:19:31] i assume the rendezvous was easy for you [17:19:47] i know you have done alot of them [17:20:47] yeah, no problems [17:20:55] rendezvous is my specialty [17:21:28] mostly from the calculation perspective, but as you said, I've done a lot of them as a user as well [17:22:59] also i assume the csm rescue pads are in case the rendezvous goes bad [17:23:16] yep [17:23:32] although during a nominal mission most of the rescue PADs aren't even filled in [17:23:34] wonder if that could be done in nassp [17:23:43] a csm rescue [17:23:45] almost all of it can be done [17:23:59] we have good documentation about it and most of the calculation tools [17:24:28] so many possibilities with nassp [17:24:33] https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19700025402.pdf [17:24:45] this is the document with all the rescue cases Mike Collins had to learn [17:24:54] he talks a bunch about it in his book [17:25:11] you mean carrying the fire? [17:25:17] yep [17:25:32] i have the audiobook on amazon audible [17:25:43] oh fun, didn't know where was an audiobook [17:26:39] also i have Gene Cernan's last man on the moon audiobook and it is actually him reading it [17:26:57] is it good? Don't have that book [17:27:36] yes it is very good [17:27:45] especially with him narrating his own story [17:28:14] Apollo 17 is a fun mission [17:28:39] i bet it will be in nassp in the future especially the eva's [17:28:49] cant wait to find the orange soil [17:29:15] haha, yeah [17:29:25] Apollo 17 has a great landing site [17:29:27] a valley [17:30:28] and if i can remember the csm does the doi and then a circularization burn [17:31:02] right [17:31:24] that started with Apollo 13 already [17:31:28] well, it was planned for 13 [17:31:31] CSM doing DOI [17:31:36] instead of a LOI-2 [17:31:47] so LOI-1 was just called LOI, and LOI-2 became DOI [17:33:56] i think they also slept between doi and the circ burn so i guess their inital orbit must have been high [17:34:14] unless the descent was slow [17:34:22] DOI happened at the normal time of LOI-2 actually [17:34:39] so a whole sleep period between DOI and PDI [17:35:43] on Apollo 17 specifically they didn't dare staying in a orbit with such a low perilune for so many hours [17:35:59] so they did a DOI-1 at the time early missions did their LOI-2 [17:36:08] but it didn't lower the orbit quite as much [17:36:16] and then later there was a short DOI-2 with the LM [17:38:08] and only after that the CSM did it's circ burn back to a 60x60 orbit [17:40:20] this doesn't matter now with the mcc support but i am still curious why that ptc resfmmat kept putting me in gimbal lock [17:51:06] Looks like Collins flew the initial orb rate after LOI with SCS MIN IMP [17:51:14] And had a lot of trouble doing so [17:52:31] Gravity gradiant/mascons [17:57:43] astronauthen96__, which one? Apollo 11 calculated with RTCC MFD? [17:57:47] rcflyinghokie, I believe ir [17:57:47] it [17:57:58] yes 11 [17:58:27] they actually used a different type of PTC REFSMMAT for 10 and 11 [17:58:42] maybe because of those issues, not sure [17:59:02] I found documentation that has the right PTC REFSMMATs and I've hardcoded it for the MCC [17:59:29] so what the RTCC MFD calculates is only really valid for Apollo 12 to 17 [17:59:41] Ptc and mccs with that refsmmat worked nicely [18:01:14] yeah, for me as well once I fixed that it got converted from ecliptic to AGC coordinates. when it already had the right coordinate system... [18:03:08] Oh will the fake vector we have mess anything up with the orbiter fix? [18:04:12] ah right, I wanted to check that [18:04:53] /Orbiter 2016 hack [18:04:54] if (length(w) == 0.0) [18:04:54] { [18:04:55] w = GetGravityVector(); [18:04:56] } [18:05:05] it first checks if the Orbiter API returned vector is 0 [18:05:20] that will not be the case anymore in the most recent Beta [18:05:26] Orbiter Beta* [18:05:37] so it should simply use the one from Orbiter then [18:05:55] and I don't have to remove our code immediately [18:07:48] Oh ok [18:08:10] Think that will affect our P57 at all? [18:08:46] good question [18:08:51] by a tiny amount maybe? [18:09:21] no, probably not [18:09:31] the fake gravity vector was pretty detailed [18:09:52] but you never know [18:10:02] with the gravity option I had very small errors [18:10:14] +00001 every time I believe [18:27:03] Yeah me too [18:27:32] Will the real gravity vector be a little different than out fake one? [18:27:37] Our* [18:28:09] fake gravity is the whole local gravity field [18:28:21] all that should be different is e.g. the Earths pull on the LM while on the lunar surfac [18:28:24] surface [18:28:35] so it shouldn't be any significant amount [18:28:48] but it will certainly not be worse, it can only be better :D [18:43:20] Always a good thing [18:45:20] and I had no insertion plane issues really [18:45:32] 2 ft/s on CSI, 2 ft/s on CDH and it was down to 0.00° [18:49:40] Great [19:17:22] about to do some p23's [19:17:59] and @indy91 i have not got any pad displaying ctd's [19:18:42] I imagine there arent any on the first half of the mission [19:19:30] ctd's? [19:20:28] yeah [19:20:39] Ive already been through it with no issue [19:21:18] when i attempted apollo 10 a while back i got some ctd's when the tli pad would display for some reason [19:22:45] only certain PADs cause it I think [19:23:12] I've only ever had it with TLI PAD, Block Data PAD and the S065 Photography PAD for Apollo 9 [19:27:00] What is the trigger for LOI 2 pad? [19:28:08] in lunar orbit it's times relative to the start of the revolution (180° longitude) [19:28:23] LOI-2 PAD is rev 2, time 35 minutes [19:29:16] Ok [19:33:04] Hmm your LOI 2 pad didnt stop time accel [19:33:24] I thought they all did [19:38:59] yeah, me too [19:39:04] but I had a few that didn't [19:39:34] oh, I see [19:39:38] at least in the case of LOI-2 [19:39:49] it's not using the normal update function [19:39:56] so I have to add the stop time accel manually [19:40:50] added them where they were missing [19:41:05] LOI-2 should be the last of those [19:41:17] they were also missing for Block Data 1 and the Evasive Maneuver [19:42:06] Ah ok [20:25:28] good night! [00:17:11] good evening @rcflyinghokie [00:17:39] just one question when you say through loi 1 is it right up to loi 1 or does it go past it? [10:16:39] hey [10:19:26] Hey Niklas [10:23:26] what's up? [10:24:42] Just came back from a camping trip this Friday. About to head out for another week as a cub scout leader this time. [10:25:06] Yourself? [10:25:59] sounds busy [10:26:33] working on descent abort constants [10:26:46] Yeah, can't wait for college to start again to be honest. :P [10:27:02] needs a fairly complete simulation of the descent guidance, which is fairly complicated. Who would have thought! [10:27:27] Haha [10:27:34] Are these constants for MCC? [10:28:07] well, RTCC (MFD) in general [10:28:19] to update the constants used in the LGC and AGS [10:29:02] I see [10:29:23] one thing that was always planned is that you could wave off a landing attempt for one orbit [10:29:33] so you would get a PDI2, a second attempt [10:29:48] but now the LM has travelled further away from the CSM [10:30:23] so for an abort during PDI2, the insertion has to be very different to set up the rendezvous [10:32:07] That makes a lot of sense. Sounds like a fun challenge. [10:32:26] I have some good documentation on it [10:32:40] just needs simulated descent and ascent [10:33:10] my preliminary version for the descent was just thrusting again the velocity vector [10:33:24] which leads to a lunar impact at about 5 minutes after PDI, haha [10:33:32] so not quite realistic enough [10:35:42] Haha, that doesn't quite do it indeed. [11:46:23] Ah forgot to mark away, my apologies [11:50:59] good morning [11:53:57] Morning [11:54:04] Back to working on post LOI 2 stuffs [11:54:35] nice and circular orbit? [11:57:25] At LOI+20 we are at a N44 of 60.6x59.3 [11:57:44] Was closer to perfect after the burn of course [12:00:15] good morning [12:00:17] hey [12:00:17] starting day 2 [12:01:22] Had a good day 1 I take it? [12:02:27] yes and i started day 2 last night now its time for mcc2 [12:13:30] indy91 when should I expect the A-1 P22 PAD [12:14:15] how about I teach you to read the MCC file? :P [12:14:35] then you don't have to ask me about every update [12:14:56] Yes please [12:15:10] in the MCC project [12:15:14] file MCC_Mission_G.cpp [12:15:39] you can see there [12:15:41] "A-1 landmark tracking update to TEI-11 update" [12:15:58] no, better the one before [12:16:03] TEI-5 update to A-1 landmark tracking update [12:16:07] Ok [12:16:15] in that mission state it calculate TEI-5 and then waits for the next update [12:16:23] UpdateMacro(UTP_PADONLY, PT_AP11MNV, MoonRev >= 3 && MoonRevTime > 50.0*60.0, 42, MST_G_LUNAR_ORBIT_LOI_DAY_4); [12:16:33] almost all this is for the TEI-5 [12:16:40] MoonRev >= 3 && MoonRevTime > 50.0*60.0 [12:16:47] this is when the next update is happening [12:17:10] Rev 3 + 50 minutes? [12:17:12] yep [12:17:31] I need to figure out a clean way to do the checklists with these [12:17:36] feel free to ask me if you are reading these right for other updates, it can be confusing for sure [12:17:45] I mean I can always use the "wait for XX PAD" [12:18:10] I mean, the update will happen roughly at the flight plan time, that's what the time is derived from really [12:18:23] it just won't ever happen exactly then [12:18:30] well, in most cases not [12:19:42] Yeah [12:20:42] I will see how the wait for works with other people who come behind me for their opinions [12:21:39] sure [13:17:40] Are all the landmark tracking P22's done as unknown? [13:19:30] I think the opposite is the case [13:20:13] unknown is code 20000 [13:20:20] you don't even give it a lat/long/alt with that [13:20:35] you just mark and at the end it gives you coordinates [13:21:10] so they all should be either known landmark (10000) or the landing site (10001) [13:21:25] but I think they manually input the coordinates close to the landing site [13:21:35] so on 10 and 11 they all are 10000, I believe [13:24:10] Ok that makes it simpler [13:25:32] Ok to not incorporate am I V32'ing on the N49 or N89? [13:27:02] V32 on the N49 [13:27:12] and then V37E 00E [13:27:16] Ok [13:27:17] V34 might works as well, not sure [13:27:28] checklist says a V32 [13:27:35] To reject cycle [14:06:20] Ok this first p22 might be early? [14:06:43] It's supposed to be performed around 82:35 [14:06:52] The PAD says 81:47 [14:07:45] that's really weird [14:07:52] that wouldn't even be a rev early or late [14:08:43] Oh sorry [14:08:46] I misread [14:08:46] 81:47 is T1? [14:08:50] 82:47 [14:08:59] :/ [14:09:06] Never mind! [14:09:23] haha, ok, that makes more sense [14:09:50] So sorry haha [14:09:56] I can read I swear [14:10:18] I believe it [15:57:29] .tell indy91 so why is the A-1 PAD so different from the one in the flight plan? [15:58:31] .tell indy91 PAD N89 +65424 +32750 -00000 and FP N89 +02000 +32750 -00000 [16:03:47] .tell indy91 I believe the PAD is miscalculating [16:47:25] back [16:47:36] All one thing dont worry [16:47:43] haha [16:47:51] is that the latitude? [16:47:54] Yeah [16:48:02] it shouldn't even be calculating anything for it [16:48:11] haha [16:48:16] Oh is it supposed to be from the FP? [16:48:17] I have a suspicion [16:48:33] looks like a saving loading bug maybe [16:48:34] Because it looks like a longitude [16:48:36] Oh [16:48:39] lng/2 [16:48:45] let's see... [16:50:23] hmm [16:51:03] was it originally right when it came up? [16:52:00] I can go back and see [16:52:08] yeah, please do [16:52:20] I took a screen shot right after it came up, also wrong [16:52:22] I don't see a saving/loading issue [16:52:26] weird [16:54:42] ok, I can confirm it [16:54:47] trying to debug it [16:55:16] not a display error [16:56:00] Thats a start :P [16:56:39] Oh also I changed the docking probe switch to be a spring loaded up, can you make sure I did it right? :P [16:58:13] I think I know what it is [16:59:00] Orbiter uses left handed coordinates [16:59:29] I got annoyed that the function finding the T1 and T2 times for that PAD was using bad conversions back and forth [16:59:35] Hey Niklas [16:59:37] so I made it all right handed [16:59:41] forgot one step though [16:59:42] hey [16:59:56] mcc2 went good 25.8 fps with -0.2 residuals [17:00:02] great [17:00:32] Well darn if you overburned you could have had an incorrect RCS MCC3 :P [17:00:33] rcflyinghokie, fixed [17:00:48] Great [17:01:14] do you want it springloaded to the center [17:01:15] ? [17:01:20] so up and down go back to the middle [17:03:16] No [17:03:18] Only spring up [17:03:37] It works as it should now after testing, at least the switch visibly does what I want it to do [17:03:53] And it does extend the probe [17:04:19] I tested it with both LM and CM hatches open, that was interesting haha [17:04:30] yeah, SPRINGLOADEDSWITCH_CENTER_SPRINGUP should be right [17:04:35] shouldn't break anything either [17:05:15] I added the delay as well, because eventually it needs to be held 5 seconds to fully extend the probe [17:05:52] Actually, scratch that [17:06:20] It needs to be held 5 seconds to keep the capture latches released while the probe extends [17:06:30] At least for a normal undocking [17:19:48] Not sure if it's necessary, but perhaps it might be prudent to disable undocking while the hatches are open? [17:20:01] Because the probe/drogue shouldnt be in there? [17:20:44] Or maybe I am just reading too far into it haha [17:21:52] you can't undock while the hatches are open? [17:25:39] I'm not sure what you are trying to say [17:26:11] Well if the probe isnt in there [17:26:40] Probably something to deal with in the future, not now [17:26:46] you mean visually in the mesh? [17:29:53] No just simply if the tunnel is open, the probe and drogue probably are removed, so putting the switch to extend/rel should not separate the vehicles [17:30:34] oh you mean the hatches of the CSM/LM interface [17:30:38] I thought the outer hatches [17:30:42] like Apollo 9 EVA style [17:30:49] Yes if they both are open, the docking probe [17:30:55] the docking probe is probably out [17:31:02] No sorry the tunnel hatches [17:31:06] yeah, that is unlikely to work, haha [17:31:19] shouldn't be too difficult actually [17:31:21] I mean probably not a case we would deal with right now [17:31:26] But still, I just did it [17:31:39] just needs a check on the hatch state in the dockingprobe code [17:32:52] you can make an issue for that [17:33:00] but I don't think it's very difficult to implement [17:33:01] Sure [17:33:13] Just happened to notice by accident :P [17:33:36] emergency cabin pressure only works so well when the hole is the size of the hatch ;) [17:34:12] true [17:34:15] Btw its cool to watch gravity gradient stabilization in action [17:34:39] I am 30x in sleep attitude and it keeps bouncing around 90 ordeal +- 30 degrees [17:38:35] brb [17:38:45] yeah, that's a fun effect [18:25:12] back [18:27:32] And new joystick just arrived :) [18:28:36] awesome+ [18:28:48] not only awesome, but awesome+ apparently [18:29:02] Hey I'll take the + [18:29:15] Its been 10 years since I have bought a new one [18:29:54] mine was bought for MSFS 2004 I think, haha [18:30:02] technically my brother owns it [18:30:11] Haha I had a sidewinder 3d pro until 2008 [18:30:20] Then got a logitech 3d pro [18:30:48] rcflyinghokie, do you remember if the RTCC MFD on the PDI PAD page ever gave a good PDI TIG? [18:31:12] mine seems to be a minute off [18:31:46] I thought it did [18:31:55] Its been a while though [18:32:28] it's using the numbers from the Apollo 11 padload, so it should be especially close to that [18:52:15] hmm, about 52 seconds off [18:52:27] it helps if you subtract the 26 seconds at 10% and not add it [18:52:28] :D [18:56:10] Ah [18:56:17] That will do it ;) [18:56:22] one display is still off though [18:56:37] the time-to-go it displays right when P63 has finished the ignition algorithm [18:56:39] 9:50 is normal [18:56:47] 9:03 on the RTCC MFD right now [18:56:49] hey again so should be leaving the csm hatch closed for the tlc? [18:57:33] I think so, yeah. Tunnel hatch was closed most of the time. [18:58:05] just starting day 3 i will probably be in lunar orbit in the next 2 hours [18:58:55] Yeah its closed whenever LM stuff isnt going on [18:59:07] And in reality the probe/drogue was put back in [18:59:34] The only time the probe drogue were not was the rest period after LOI and final LM entry for decent [18:59:40] The hatches were cloed for that though [18:59:43] closed [18:59:49] brb gotta reboot [19:13:37] Windows wanted a reboot as well right after...greedy bastard [19:14:03] Ok, so how do I get my stick setup for NASSP again [19:14:43] TRASHY LITTLE SUBROUTINES [19:14:51] Luminary code is always fun [19:15:02] Haha its so funny to read some of those [19:18:34] Oh no deadzone I love it! [19:19:32] Disable orbiter joystick, enable rhc [19:19:34] ? [19:19:55] yeah [19:20:37] What about throttle [19:21:55] if you only have a joystick connected as RHC/ACA then it gets a cheaty throttle [19:22:35] so the one on your joystick should be working as that [19:23:18] Hm doesnt seem to [19:23:27] And I have to move my stick a lot to fire [19:24:03] arm the DPS [19:24:30] what PGNS mode? [19:24:30] Ok throttle works [19:24:47] Say OFF [19:24:57] that's properly off in the LM [19:25:02] not like CMC free [19:25:04] try att hold [19:25:41] Yeah I have to move about half before I get anything [19:26:12] lots of variables are influencing that [19:26:13] Eh maybe not half [19:26:24] Just getting used to it I guess [19:26:32] but there is a deadzone on the ACA as well [19:26:36] the detent [19:26:57] and it has a quadratic guidance law [19:27:00] That might be it [19:27:09] I'll just have to adapt [19:27:37] so from 0 to full deflection it is a quadratic function for the attitude rate [19:27:48] are you in 4°/s or 20°/s mode? [19:31:11] rate scale? [19:31:18] Or DAP [19:31:52] DAP [19:32:14] 4 [19:32:32] so half deflection will give 1°/s [19:32:35] because quadratic [19:32:52] Thats about right [19:32:58] great [19:33:02] Ok nothing wrong then [20:18:16] night! [11:11:09] good morning [11:11:19] i have one possible problem [11:11:41] my apa is a bit low around 158nm [11:15:08] hey [11:15:12] on the PAMFD? [11:15:27] yes [11:15:57] 158 or 168? [11:16:01] 168 would be normal [11:16:12] 58 [11:16:22] hmm, that's pretty bad [11:16:34] state vector or alignment comes to my mind [11:16:49] try a V82. Does the CMC think you are in a 60x170 orbit? [11:17:04] i will try that now [11:18:42] 160.3 x 57.3 [11:20:04] huh [11:20:16] maybe a typo when you reentered the DV in P30? [11:20:31] possibly [11:21:59] i will try again [11:23:02] actually could you look at one scenario for me first? [11:23:07] sure [11:24:15] https://www.dropbox.com/s/xdkjj8zs9psgmwu/BEFORE%20LOI%201.scn?dl=0 [11:25:35] you want me to check the DV? [11:25:53] this was before entering the new dv [11:26:43] i do have a current state shortly after Madrid aos as well [11:27:23] yeah, I see in P30 that it has the compensated DV, so it has to be reentered [11:28:07] i did reenter it [11:28:13] yeah, certainly [11:28:21] this DV would probably crash you into the Moon [11:28:38] unfortunately the scenario has the TEI-4 PAD displayed, not LOI [11:28:42] so what do you want me to do? [11:28:56] i just decreased the state [11:29:12] i dont think the loi pad would change would it [11:29:46] well I wouldn't advise getting the LOI-1 PAD back this way, you rather should write it down. But no, shouldn't change [11:30:14] oh wow [11:30:19] did that [11:30:30] the predicted apolune is now 160NM [11:30:47] very weird i didn't see that at all [11:30:52] so something does go wrong when you go back [11:31:21] good thing i have a scenario before the loi pad [11:31:38] no idea why this happens [11:31:53] is this a potential bug? [11:32:38] yeah [11:32:43] RTCC MFD gives the same DV [11:33:09] did you have a MCC-3 or 4? [11:33:16] no just 2 [11:33:21] mcc2 [11:33:30] ok [11:34:38] has to be something with your trajectory [11:35:18] the original LOI-1 PAD probably had the same DV [11:35:27] but in my scenarios it works fine [11:35:43] what do you mean original? [11:37:28] well when it first came up [11:37:35] okay [11:37:40] probably was the same as when you decreased the mission state [11:37:44] already had the wrong orbit [11:37:47] i will check right now [11:40:05] i don't know if this means anything but i calculated the loi with the rtcc mfd and the orbit was around 60 x 169 [11:41:17] in your scenario it gives me 58x160 [11:41:46] i made the calculation in a different scenario just before 73 hours GET [11:42:13] this was before the loi 1 pad was even displayed [11:42:43] interesting [11:43:14] in any case, I have found one cause at least that is easily fixable [11:43:20] your perilune is low [11:43:26] before LOI-1 that is [11:43:46] the result is that it can't achieve the desired orbital plane (over landing site) and also get a 60x170 [11:43:57] but there is indeed a bug that is caused in that scenario [11:44:06] if I fix that it gives a 57.2x170 orbit [11:44:17] which is probably ok [11:44:57] it simply might give unreliable results depending on when you calculate the LO [11:44:58] LOI [11:44:59] not sure [11:45:12] it shouldn't really give different results for different calculation times [11:46:20] not sure if this would tell you anything [11:46:21] https://www.dropbox.com/s/5zxga9hm47kdpp2/LOI%201%20PREPERATIONS.scn?dl=0 [11:46:54] I'll look at it [11:48:36] did you use the default apolune and perilune altitudes on the RTCC MFD? [11:49:28] I don't know why Alex used these [11:49:37] the target really should be 60 x 170 [11:51:11] with the unfixed version and the default numbers (59.2 x 169.8) it gives me an apolune of 163.0 consistently in both scenarios [11:51:30] but I have a fix soon, so that the orbit will have 170 apolune [11:52:11] no i simply just pressed CALC [11:52:22] ok [11:52:36] using the with or without MCC option? [11:52:42] without mcc [11:52:44] ok [11:53:00] well that doesn't give a 170 apolune in either of your scenarios [11:53:29] but doesn't matter, I have a fix soon for you [11:54:04] although a 160NM apolune for 2 orbits might get you back on the flight plan schedule, lol [11:55:11] i think i was looking at the calculation for the apolune on the left of the mfd [11:55:43] and fully trusted to give the right DV, haha [11:57:13] just curious will this "fix" come today? [11:58:18] right now [11:58:24] okay [11:58:50] unfortunately I didn't move my work on power descent abort constants into a separate branch, so I have to push a half finished version of that [11:58:56] powered* [11:59:11] pushed [12:09:08] I guess you can now do the procedure with reverting to an earlier mission state [12:09:18] HA and HP should now be 170 and 57.2 or so [12:21:07] @indy91 new orbit is 169.9 x 57.2 [12:21:17] Niklas your so smart [12:23:18] the bug wasn't so smart of me, haha [12:23:32] if the LOI burn happens instantly, then it would be at 57.2NM [12:23:39] desired orbit is 60x170 [12:23:42] so that doesn't work [12:23:42] well the fix was smart [12:23:46] and easy! [12:24:11] it modified the orbit from 60 to 57.2 perilune but what it didn't do was change the energy of the orbit [12:24:28] really just had to move two lines of code further down [12:25:18] so am i okay to proceed with loi? [12:25:21] yeah [12:25:55] also another interesting thing is the mission audio before LOS behind the moon matches up pretty good [12:26:15] right when the earth disappears i get static [12:26:50] how did you adjust the timing of the mission audio? [12:26:56] like relative to LOI TIG or so? [12:27:22] in the audio they say about 2 minutes to LOS [12:27:56] then i look at the MAP UPDATE los time and i start the audio 2 minutes prior to the NASSP los time [12:28:07] i have the sound file if you want to try it [12:28:41] ah, no need, I know where to find it [12:28:50] okay [12:29:03] speaking of Apollo 11 audio, I still have to continue listening to the mission control audio they relased a while back [12:29:10] i just thought it was quite interesting [12:29:13] I only got to about 1h GET [12:29:33] yeah, Ryan also mentioned that the orbit and timing matched very well to reality [12:30:00] would you know where to find any pre launch audio (non public affairs) [12:30:12] yeah [12:31:38] https://archive.org/details/nasaaudiocollection?and[]=subject%3A%22Apollo+11+MOCR+ACR+Collection%22 [12:31:52] this is the collection of audio they released just a few weeks ago [12:32:10] all of the flight directors and flight controller loops, including the back rooms, for the whole mission [12:32:15] just difficult to find anything [12:32:19] let's see... [12:32:57] which loop do you want? [12:33:07] Flight Director loop? [12:33:19] that would probably be all the flight controller and also the astronauts [12:33:31] CAPCOM has a separate loop, not sure what that is for [12:37:22] yeah sorry, I'm not sure how to find anything quickly in that collection, haha [12:37:48] thats okay [12:37:57] do you know lunarmodule5 [12:38:40] he said the FD loops are on ch7 [12:39:32] where? [12:39:56] but I know the system, basically [12:39:57] here [12:39:57] https://ia801500.us.archive.org/8/items/A11_T883_HR2L_CH13_11-40-05_19-12-40-2015-09-16Recording.wav/Historical_Recorder_1_Tracksheet.JPG [12:40:02] https://ia801500.us.archive.org/8/items/A11_T883_HR2L_CH13_11-40-05_19-12-40-2015-09-16Recording.wav/Historical_Recorder_2_Tracksheet.JPG [12:40:02] in the collection you can see in the sames their are channels [12:40:05] channel lists [12:40:33] but where is lunarmodule5 talking about it? I was wondering if anyone made a more readable system to find anything [12:41:58] he said "The fd loops are on ch7" [12:42:07] "There are 20+ tapes on ch7..covers nearly the whole flight" [12:42:35] yes, but where did he say that? [12:42:48] i found him on facebook [12:43:12] ah, so on facebook [12:43:16] he posted some prelaunch footage of the astronauts in the csm talking to mission control [12:45:19] I think I found the prelaunch tape [12:46:30] https://archive.org/details/A11_T869_HR1U_CH7_09-32-17_17-32-17-2015-08-26Recording.wav [12:46:34] it is super quiet though [12:46:44] RETRO loop I was listening too was as well [12:46:46] to* [12:46:54] launch is at about 4:05:00 [12:46:56] roughly [12:48:48] good morning Alex [12:49:04] hey [12:49:06] almost in lunar orbit [12:49:42] hey Alex [12:50:04] I've been flying Apollo 11 (about 10 hours left) and working on abort constants [12:50:08] pretty far with that now [12:50:56] astronauthen96, nice [12:51:19] indy91, great! And Ill try out that ascent pad now [12:51:51] I didn't make a branch for the abort constants work, and I wanted to push some fixes, so I had to push my current state of that as well [12:51:55] don't touch it yet, lol [12:52:01] can only end in tears (aka CTDs) [12:52:26] right now I am generating time since abort vs. horizontal velocity [12:52:32] haha [12:52:38] so what Luminary099 wants for abort constants [12:52:51] well I have a box of Kleenex beside me [12:53:14] it's also not useful yet. No display, no uplink [12:53:35] right [12:53:51] interestingly what I am generating right is closer to the table in the Apollo 12(!) Rendezvous/Abort Book than the Apollo 11 padload [12:53:55] right now* [12:54:08] it's especially far off at about 6 minutes into the descent [12:54:28] 5595.5 ft/s for the padload [12:54:44] 5603.8 for the Apollo 12 table [12:55:01] 5605.0 calculated by the RTCC MFD [12:55:22] I tested an abort at that time with the current padload, gave me a 10NM DH [12:55:31] so I wonder if that will improve with updated constants [12:56:47] hopefully [12:57:14] Ill try and burn CSI today on 9, maybe CDH even [12:57:30] but mostly, of course, it will be good for missions where we don't have a padload [12:57:31] and PDI2 [12:57:39] yeah [12:59:32] first iteration will only support Apollo 11 though [13:10:21] one issue I am seeing on the Lunar Ascent page is that in some cases pressing CLC, nothing, happens. I then restart orbiter, go back to the liftoff page and CLC, then Ascent page and then CLC works [13:13:04] you did a lunar liftoff calculation before that? [13:13:18] yes [13:13:35] I haven't seen that yet [13:13:54] which scenario are you using? [13:16:50] https://www.dropbox.com/s/48l2nbw8gfjq0vw/Apollo%2011%20MCC%20-%20LS%20simulated%20countdown.scn?dl=0 [13:17:16] But I cannot re-create the issue unfortunately [13:17:19] back in 10 mins [13:19:32] sorry it was this one: [13:19:33] https://www.dropbox.com/s/gm684sjkysmh1zn/Apollo%2011%20MCC%20-%20Before%20LM%20Liftoff.scn?dl=0 [13:27:45] yeah, I can't replicate it either [13:30:05] it's doing a whole simulated ascent, so I guess it's having an engine failure or so :D [13:35:47] ok, got it as well [13:35:50] bunch of NaNs [13:36:52] yeah [13:37:10] it seems to not happen consistently [13:37:22] I think I already figured it out [13:37:51] something with the desired thrust direction vector [13:38:33] taking the acos of 1.00000001 or so [13:43:58] the arccosine is really one of my nemesis [13:49:00] but I think that was the issue and it's fixed [13:50:50] awesome [14:06:29] CSI pad looks good TIG 96:16:00 TPI 97:54:35 DVX -35.8 [14:09:44] ok so I add a time bias of 2 or 3 minutes? [14:10:00] PAD form says 2, but checklist MFD says 3 [14:10:39] 3 minutes [14:10:44] added to TPI time [14:11:20] ok [14:12:33] I guess the pad form was an earlier version and they changed it from 2 to 3 minutes [14:13:56] yeah [14:14:01] and in real time to 4 minutes even [14:14:14] but 3 should be good enough [14:15:02] whats the targeted DH for Apollo 9? [14:15:53] 1st pass through P32 shows 06 75 of +9.0 [14:15:58] 10NM [14:16:01] ah [14:16:10] makes sense [14:16:27] thought it was supposed to be 15 for a sec [14:17:02] and N81 DVX of -35 fps, pad says -35.8. Super [14:17:55] now I wonder if the CDH TIG bias should also be used [14:18:03] has to result in closer to 10NM [14:18:17] the question is if that does anything good for TPI [14:19:29] CSI TIG isn't retargeted to give the right TPI TIG and also right DH [14:19:37] not in the RTCC right now at least [14:43:22] ok CSI done [14:43:57] the time between insertion and CSI is very busy in the checklists [14:44:10] Niklas your pad showed the right orbit this time [14:45:40] good [14:48:06] what I dont understand is why the checklist MFD has you wait until getting the CSI pad before starting P32 and taking marks [14:48:33] the flight plan shows P32 starting just after the insertion burn [14:49:25] do you have CSI and TPI TIG before the PAD? [14:49:40] Same thing for CDH, it says after CSI to wait 15 minutes to get the PAD, then start P33 [14:49:58] Well I am thinking you could use the flightplan TIG initially [14:50:10] you can't really [14:50:30] you'd have to go to P00 again to change CSI or TPI TIG [14:50:47] right [14:51:15] and the flight plan has P32 at the same time as the CSI update [14:51:45] but I wonder [14:51:57] what if you for some reason don't have comm after insertion for a while [14:55:18] yeah [14:55:30] btw CDH has a bias of 1:45 [14:56:12] I don't see them getting a CSI or TPI time earlier in the transcript [14:56:29] about that bias, I'd like you to try it with and without bias [14:58:08] you mean make a pass through P33 itself with and without the bias, or actually do the burn twice? [14:58:23] you probably have to do the burn twice [14:58:45] the P33 DT TPI isn't reliable for the same reason that you need a CSI bias [14:58:52] conic trajectory calculations [14:58:59] hmm [14:59:07] sure, but I wont have time today to do it twice, but I could give you a scenario if you want [14:59:13] does P33 show a DH? [14:59:20] if yes then that would already say a lot [14:59:41] yes it has a 06 75 [14:59:42] so which DH it results in with the different TIGs [14:59:50] that only needs two P33 calculations [14:59:54] not burning CDH itself [15:00:36] so maybe try that and then anything more can wait [15:00:37] ok ill make 2 passes through P33 [15:00:47] bias of 1:45? [15:01:02] checklist says 1:45 and pad form says 1:50 [15:01:06] 1:45 [15:01:12] btw what the purpose of these biases? [15:01:12] flight plan is old [15:01:35] well in P32 it compensates for P32 using conic trajectory calculations [15:01:42] for the CSI to CDH and CDH to TPI trajectory [15:02:01] so giving P32 a biased TPI time results in a better DV calculation [15:02:44] that all is necessary in Earth orbit only [15:03:54] right [15:04:00] next question ;) [15:04:26] but I am unsure about the P33 bias [15:04:29] Do I have to modify the initial TIG that P33 comes up with, with the PAD TIG? [15:04:34] yes [15:04:37] ok [15:04:37] uhh [15:04:43] with the PAD TIG? [15:04:44] no [15:04:54] use your own one plus bias [15:04:59] ok [15:05:17] so Ill make a pass 1st without it then with [15:05:22] yeah [15:05:40] using a bias in P32 leads to a smaller DH [15:05:50] so the P33 bias might simply add that back again [15:06:22] but Sundance always puts CDH at periapsis [15:06:27] which Luminary doesn't [15:06:31] so it might bias for that [15:06:38] that's what I am not quite sure about yet [15:06:59] CDH at the next apsis* [15:07:42] So I guess to re-enter P33 to add the bias, I can do V34 and then at the flashing 37, run P33 again and that should put me at the start of the program [15:08:06] or go to P00 [15:08:46] ok without the bias its DH of 9.1 [15:08:57] so consistent with before [15:08:58] want the rest of the data too? [15:09:04] DT TPI [15:09:15] don't need DT CDH/TPI [15:09:19] -0150 [15:18:47] ok with the 1:45 bias, DH: +9.0 and dT TPI -0129 [15:19:13] uhh [15:19:21] DH 9NM again? [15:19:22] haha [15:20:27] maybe it is going downwards the first time and upwards the second time [15:21:27] but I tend towards using the bias actually [15:21:56] what DH did you guys get when flying 9? [15:23:11] something with 9 [15:28:39] ok, CSI time [15:28:50] flight plan has 96:22:00 [15:29:05] mission report for "pre-rendezvous nominal" is 96:15:52 [15:29:32] however, all other times (ground, LGC, actual target solution) are 96:16:03 [15:29:55] this tells me that they probably did move the CSI TIG in real time to achieve 10NM again [15:32:28] in our case it would need to be just a bit later [15:33:49] its funny because my CSI TIG was 96:16:00. Very close [15:35:31] yeah [15:35:40] shouldn't be more than a minute later [15:35:43] so maybe even closer, haha [15:36:23] this would probably have been manually [15:36:34] or with a display that has several CSI TIGs and you can choose the best one [15:36:57] about that, the RTCC already has a "concentric rendezvous processor" Just the MFD doesn't have it yet [15:37:18] will be integrated on the coelliptic page, which only calculates CDH right now [15:37:55] then we properly have the three main rendezvous programs of the RTCC: two-impulse, concentric, docking initiation processors [15:38:47] so CDH is 35 fps and with APS. That sounds like a swell idea, my residuals will probably be as much as the burn itself [15:39:16] not quite as bad, but pretty bad, yeah [15:39:37] I guess they really wanted to test that APS [15:39:56] short burn with it, yeah [15:40:03] might even be a DTO just for a short burn [15:40:10] there will be a plenty long burn later on [15:42:02] ah right I forgot about that burn [15:45:38] residuals 6 fps, not so bad [15:50:47] eagle and columbia are now in lunar orbit [15:51:02] the orbit is 169.5 x 57.2 [15:51:08] that sounds good [15:59:17] TPI TIG: 97:55:46 DVR: +19.1 fps [15:59:34] what was the TPI TIG on the CSI PAD? [16:00:10] 97:54:35 [16:00:22] not too bad [16:02:22] but I wonder if using 3 minutes bias didn't hurt a bit [16:02:40] looks more like 2 would be enough [16:02:53] but that is all just guessing [16:07:39] I'm on the last day for Apollo 11 [16:08:30] and I'll have to do a MCC-7 [16:08:52] probably because I spend a bit too much time chasing residuals on MCC-5 [16:17:00] dont think Ive every had to do 2 TEC mcc's [16:17:04] ever* [16:17:59] first one was 3.3 ft/s, this one should be about 1.2 ft/s [16:18:08] as I said, too much residual chasing [16:18:18] and the threshold for MCC-7 is 1 ft/s [16:21:22] oh well then I have skipped a lot of MCC-7's that I should have burned [16:21:41] 1.4 [16:21:45] haha [16:22:04] yeah, I could get away with skipping this one as well [16:22:13] but MCC-H says I should do it [16:22:22] just dont chase your residuals too much this time, dont want to have to do MCC-8 [16:26:49] yeah, MCC-8 is tricky to fit in the schedule [16:27:43] lol Ryan [16:28:29] even puts a PRO/FAIL condition on CMC self test and DSKY check [16:28:34] in the checklist [16:29:11] hehe, hes thinking ahead to when we will have failures modelled for that [16:30:52] I have a bunch of experience with EMS entries, I can do it [16:48:52] I have 11.2% SPS propellant left [16:48:55] a waste really [17:11:13] You can send your comments and complaints to the flight planning branch address at the beginning of the flight plan [17:13:18] ok maybe propellant quantities is not their jurisdiction :D [17:14:17] "I want the Manned Spacecraft Center! Who is this Johnson guy?" [17:16:29] haha [17:18:29] I remember back years ago when Id fly a mission with NAASP version 3 or so and how I would run out of fuel before even completing TEI lol [17:19:31] obviously it was my bad IMFD skills, but to think that I could have finished the mission with 11.2 % SPS is mind blowing haha [17:19:55] yeah, accurate TLI, LOI and TEI have some effects [17:27:32] off to work! cya [18:32:46] Good afternoon [18:33:51] Connection reset by peer, weird [13:15:08] morning [13:16:12] hey Alex [13:21:56] Apollo 11 done, still working on abort constants [13:23:44] great [13:24:35] time to burn CDH [13:43:40] good morning [13:46:53] hey [13:47:00] still have loi 2 to do [13:54:18] indy91, theres some new orbiter revisions and I just noticed this fix [13:54:25] Bug fix: vessels landed at simulation start did not scan for gravity sources and therefore returned a zero weight vector [issue #1318] [13:55:12] yeah, I was talking to Ryan about that a few days ago [13:55:40] our implementation of the fake weight vector is such that it first tries the one returned by the Orbiter API [13:55:57] so basically we can seamlessly transition to the newer Orbiter revisions [13:56:06] and I just remove the fake weight vector code at some point [13:56:16] ok [13:59:17] ok just got my TPI pad [14:07:25] PGNS calculated TIG is only 9 seconds off from the PAD TIG [14:08:32] great [14:10:17] watch it jump to 1 minute on the next recycle, haha [14:16:17] nah, it only jumped to 30 seconds ;) [14:25:05] its funny it keeps jumping to 30 seconds before PAD TIG to 30 seconds after PAD TIG with each V32 [14:31:04] seems like the biases are good to be used then [14:37:50] would i be safe to go to day 5 or should i wait for Ryan> [14:37:54] ?* [14:38:51] there are a few checklist errors, but all in all the checklist was already in a good state. Ryan flew the mission just a few months ago. [14:39:13] has all the relevant updates from the LM Timeline Book, like the resetting of the landing radar flag [14:52:48] Good morning [14:53:48] hey Ryan [14:56:13] AlexB_88, you were right about seeing the horizon in darkness with the 31.7° line view [14:56:27] you can see the stars vanishing and that's how you know where the horizon is [14:56:47] So what was fixed for that view to work [14:58:21] Alex added a new panel [14:58:32] zoomed in view and in the right direction [14:58:35] with the line centered [14:59:00] on the left rendezvous window panel the right direction would be just above the panel [14:59:13] even though the line is there, but it's not at the right place there [15:01:58] Ah very nice, similar to the LPD? [15:02:05] yeah, I guess [15:02:14] it's to the left of the left rendezvous window [15:02:58] and Alex tried a deorbit with that view by using numbers from one of the Earth Orbit Block Data PADs [15:03:09] worked very well [15:06:48] good morning Ryan [15:08:52] Morning [15:09:33] so am i good to finish day 4 with your new checklists? [15:11:10] Yeah it's done up to LOI2 for sure [15:11:22] I'll get back onto them hopefully Friday [15:11:38] okay [15:13:53] even without your checklist changes could i complete the mission before Friday just curious? [15:14:01] Of course [15:14:13] Just no promises on the current state [15:14:39] what do you mean "current state" [15:15:54] Well they exist [15:16:32] and i assume your new sounds are in the lem [15:16:34] They just are based on other missions, timelines aren't quite right, systems weren't implemented and we didn't have certain checklists [15:16:36] Nope [15:18:07] Still need to figure it out [15:26:45] AlexB_88 how did the rest of 9 go [15:32:53] sorry I was away for a few [15:33:19] indy91, yeah the horizon is not very hard to see at all [15:34:40] rcflyinghokie, they are quite good so far [15:34:53] I am about to burn TPI now [15:36:01] Great, how's the time for marks [15:37:38] it is a little busy, for example if I follow the regular timeline, I miss the 400+4 at TIG-16m for TPI. By the time the V32 pass its done its already down to TIG-13m or so [15:38:19] sorry I meant 410+4 [15:46:45] hmm the 1st P35 has you PRO before TPI+7m, dont you have to wait until TPI+7m, then PRO? [15:52:38] Yeah I had the same issue with the -16 [15:52:58] And yeah did I put those PRO out of order? [15:55:01] you have the PRO at TPI+7m, but its at after the pass through P35, so the TIG for MCC-1 will be off [15:56:16] The intitial PRO in P35 should only be done at TPI+7m, so you have to move the yellow "wait until TPI+7m" back to before the initial PRO in P35 [15:56:20] I need to take a look I thought I had those right haha [15:56:59] once you hit the 1st PRO in P35, that makes the TIG happen at the time you hit PRO, +3m [15:59:21] Right now as it is, it says to hit the 1st PRO with no time reference associated with it, so essential would give a random TIG, then it you pass through P35, and then back at the final F16 45, and only then it has the "Hit PRO at TPI+7m". But that message should come back before the initial PRO, to have the MCC-1 TIG right [15:59:27] I thought it was the pro before the final pass that did it [16:00:08] I must have just put it in the wrong spot [16:01:49] Its the 1st PRO that sets the TIG [16:01:57] back [16:02:03] P35 talk? [16:02:54] yeah [16:03:26] whenever you PRO in P35 that sets the TIG at 3 minutes later [16:03:40] applies to both MCCs [16:04:13] so you should be PROing at exactly 7 minutes after TPI [16:04:21] Yeah I must have it in the wrong spot, easy fix [16:04:24] on the event timer [16:04:35] for MCC2 the timer on the DSKY is reset [16:05:05] it does retain the TPI TIG though, it's needed for the P35 calculation [16:05:19] so I am sure it would still be accessible through the appropiate noun [16:06:07] rcflyinghokie, yeah very easy fix, its just bringing the message to before the 1st PRO [16:06:31] and for MCC-2 as well, and I guess Apollo 10 and 11 would apply if not like that already [16:06:51] I need to check [16:06:57] I think 10 is correct [16:07:04] But again need to verify [16:07:48] yeah, just the TIG since TPI would be different on lunar missions [16:08:06] bit more time to do everything, 90 vs 120 minute orbit [16:08:28] also, there is missing the switch PGNS mode to AUTO right after TPI, before starting P20. I think that should be there [16:09:06] but thats based on the 11 procedures so I may be woring [16:09:12] wrong* [16:09:48] Yeah I used the 9 procedures [16:10:07] They use att hold and V76 a lot [16:10:18] ah right [16:10:29] I usually ignore it and use P20 in auto :P [16:10:35] then I think its missing the V76 right after TPI [16:10:56] I'll try to remember to look when I get home [16:12:49] 9 has to use V76 a lot [16:12:55] or else you run out of RCS, haha [16:13:20] right [16:14:12] the flight plan change A has the charts for it, the nominal RCS left at LM jettison is only 35% [16:14:32] on lunar mission it's usually more than 50% [16:14:44] although I always have less RCS left than that with the LM [16:37:06] alright Spider is now station keeping with the CSM [16:47:17] indy91, just tried out the new descent abort page [16:47:48] yeah, it's fairly complete for Apollo 11 now, just doesn't quite give the expected results [16:47:54] it's not super far off, but a bit [16:48:00] some things left to fix I guess [16:48:13] it's mostly the slope for the AGS coefficients [16:48:21] but same effect on the PGNS velocities [16:48:47] insertion is about 3 ft/s faster than then Apollo 11 padload [16:48:56] for aborts 120 seconds after PDI [16:49:06] and an abort 10 minutes after PDI is 1 ft/s slower [16:49:40] did you test to see the DH with the updated targets? [16:49:56] haven't tried it yet, no [16:50:06] haven't even tested if the uplink is any good [16:50:14] although I looked at the octals and they should be right [16:50:21] maybe I can try it tomorrow [16:50:39] I'll try one later today if I get to it [16:50:59] also, congrats on completing the MCC goal for NASSP 8 ;) [16:51:22] ... just so I can start over Apollo 7 [16:51:25] and 8 [16:51:46] but thanks! was a bunch of work [16:52:13] if I get these abort coefficients any good then I'll still add that update for the MCC [16:53:00] nice [16:53:39] and support PDI2 [16:53:49] I think a bit of green can be added to that development overview post lol [16:54:02] and lots of new red [16:54:16] with the RTCC MFD you should already be able fly PDI2 now on Apollo 11 [16:54:25] with ok abort constants [16:55:43] both simply use the CSI/CDH rendezvous [16:55:55] later missions get more complicated [16:56:12] different rendezvous profiles for different abort phases [16:59:27] yeah [17:33:16] off to work! [18:05:18] @indy91 so all are the MCC update pads finished for all the missions? [18:05:34] Apollo 7-11, yeah [18:05:49] very nice [18:05:51] but I'll have to go through 7 and 8 again, they are basically unchanged from NASSP 7 [18:06:03] so nassp will be moving to the beta stage pretty soon i guess [18:06:42] yeah, we should evaluate soon if that is a step he want to do. And what NASSP 8.0 Beta even means, lol [18:07:26] i would imagine 9-11 would have a ton of scenarios [18:07:40] but i would still do the full mission from T-4 hours [18:09:12] we will start creating scenarios when Ryan says the CSM and LM ECS are completely done I guess [18:09:18] so what is still a while away [18:09:21] that* [12:38:35] good morning [12:38:44] had that pressure problem during activation again [12:38:56] cabin pressure was too low and i could not get it up [12:39:35] hey [12:39:50] yeah, we have to talk to Ryan about that, I also had issues with that [12:40:33] is there a procedure to bring the cabin psi i up? [12:41:03] Direct O2. That should be going into the suit circuit and from there to the cabin [12:41:07] also i was rushing things too and i didn't get the suit pressure to 8psi or 3psi or what ever it was [12:41:39] that is just a bunch of tests if the suit circuit isn't leaky [12:42:45] well i will try this again [12:42:50] talk to you later [12:55:40] hey [12:57:34] hey Alex [12:59:00] tried a PDI2 abort, needed a few smaller fixes still but it seems to calculate and uplink correctly now [13:03:20] great [13:07:02] how did it go? Was the DH pretty good? [13:08:57] oh, I have only checked the insertion DV [13:09:19] very close to what the Apollo 12 rendezvous/abort book said for an abort at that time [13:09:41] insertion horizontal velocity* [13:11:55] nice [13:15:41] the RTCC document is for Apollo 12 anyway, so supporting further missions doesn't require many new calculations [13:16:27] just the logic for supporting several different schemes is complicated [13:16:57] the two phase insertion for Apollo 12 is CSI/CDH first and then at PDI1+10 minutes and later it's Boost+CSI/CDH [13:17:23] but I believe for later mission the first phase is Boost + CSI/CDH and then later it's directly CSI/CDH [13:19:47] oh and a HAM also [13:20:24] Apollo 17 for example. PDI1: 1st segment CSI/CDH, 2nd segment Boost+HAM+CSI/CDH [13:20:49] PDI2: 1st segment: Boost+HAM+CSI/CDH, 2nd segment: CSI/CDH [13:21:15] and you need to supply two TPI times in any case [15:46:37] back in a few hours [19:06:09] good afternoon [19:13:53] @indy91 i also had a problem with the p22 [19:14:01] hey [19:14:10] got an operation error [19:14:36] at what point in P22? [19:14:54] when i enter the codes and press enter i think that was when it happened [19:15:12] the last three numbers on the pad [19:15:31] you mean the landmark coordinates? [19:15:35] latitude, longitude, altitude [19:15:45] yes [19:16:22] can't really do much wrong there, you must have mistyped or so. That's the usual cause for an operator error. [19:17:49] would you mind taking a quick look at this https://www.dropbox.com/s/80rbfm4er33nqs9/P22%20AUTO%20P.scn?dl=0 [19:18:28] sure [19:19:53] and what do you want me to do there? [19:20:03] follow the checklist to see of that causes an operator error? [19:22:00] it's likely a checklist error or, as the name says, operator error. Just data not entered correctly. [19:23:29] could have been caused by e.g. forgotting a + or - [19:24:38] there's really not much I can do [19:30:18] i can try it again [19:30:51] not too concerned as i am beginning to activate the lem [19:31:42] it was the entering of coordinates before the marking, right? [19:31:50] yes [19:31:59] just a typo then [19:32:09] entered a number too much or forgot the sign [19:32:16] that is what usually causes operator erros [19:32:18] errors [19:32:44] usually you just press clear or key release and enter the stuff again, no big deal [20:02:55] also i assume i have to have the lem hatch open during lem activation right? [20:04:19] flight plan and checklist should have the times to close the hatches [20:04:42] on the CSM side it's at about 97:50 [20:04:51] same for the LM [20:05:15] and do i set both latches to close? [20:05:38] on the LM side I would use Lock and Auto [20:25:26] night! [11:31:42] good morning [11:31:58] finally got through that PSI issue [11:35:36] hey [11:35:42] what helped? [11:36:06] i think i turn one of the valves to direct 02 [11:36:25] then the cabin psi went up one or two points [11:36:25] one of the valves? [11:36:33] are we talking LM or CSM? [11:36:36] lm [11:36:40] oooh [11:36:56] I thought CSM pressure while pressurizing the LM [11:37:06] what was your problem again? [11:37:27] cant remember the name but the second last item in the regulator check the handle wouldn [11:37:39] wouldnt push forward as the psi was too low [11:37:50] cabin psi [11:39:15] suit gas diverter probably [11:39:23] yes [11:39:37] you shouldn't need Direct O2 for this [11:39:43] is DES O2 open? [11:39:54] pressure regulators in cabin mode? [11:39:56] not sure i did everything in the checklist [11:40:07] checklists can be wrong [11:40:13] or misinterpreted [11:40:30] that is right i can check if you want [11:40:31] and of course the hatches should be closed, lol [11:40:44] i am right before undocking [11:40:47] right [11:41:01] lem hatch is locked and auto [11:41:11] descent O2? [11:43:17] well this is my current scenario https://www.dropbox.com/s/am8fgq5eiqrfvf2/BEFORE%20UNDOCKING.scn?dl=0 [11:44:06] using Direct O2 all the time wouldn't be sustainable [11:46:20] you have no O2 left [11:46:23] all gone [11:46:27] Descent O2 that is [11:46:32] how did you manage that? :D [11:46:39] no clue [11:50:19] didn't that happen to you before? [11:50:23] I thought I remembered that... [11:53:02] it's already gone in your pre LOI scenarios [11:54:24] well last time i left the tunnel vent on due to a checklist error and all my 02 in the csm was nearly gone [11:54:33] ah right [11:54:39] similar thing must have happened this time [11:55:08] did you have the tunnel vent on again? [11:55:21] there should be no tunnel venting until lunar orbit [11:55:39] not during tlc [11:55:40] and then also the LM upper hatch must be in open [11:55:48] well, it's all gone at the end of TLC [11:56:39] very strange [11:58:21] the only explanation really is that one of the hatch valves was open [11:59:46] one other possible thing though [12:00:15] I do remember from my mission that the tunnel fairly quickly developed a under pressure, even if it wasn't in vent [12:00:40] having the LM overhead hatch in open isn't a bad thing normally, but combined with some bug in the tunnel it could cause your issur [12:01:03] is there any fix for this? [12:01:45] well, right now I still think it's a user error [12:02:00] oh, you mean, fix it in your scenario? [12:02:04] yes [12:02:34] editing the scenario [12:04:13] in your scenario search for DESO2TANK [12:04:22] the line below has [12:04:23] CHM 0 252.046437783518 251.794391345735 123785.452066959871 [12:04:27] this is the content of the tank [12:04:51] replace it with [12:04:52] CHM 0 21772.5 21772.4 10692896.1197916 [12:05:01] that's the full tank content [12:05:23] replace the whole line? [12:05:31] yep [12:05:53] thanks [12:06:59] just curious what would happen if i continued the mission without any descent 02? [12:07:24] I'm sure there is a mission rule for it, haha. But you could switch to using ascent O2 actually [12:07:42] you might be able to fly the whole mission with just the content from the two ascent O2 tanks [12:07:50] so close DES O2 and open ASC O2 1 [12:07:59] and see what happens, haha [12:08:21] in your pre LOI-1 scenario you even had the LM overhead hatch in Close [12:08:29] do you remember if you had it that way the whole time? [12:08:43] I'd like to track down in your scenarios when you started loosing the O2 [12:08:48] if it was user error or a bug [12:08:51] everytime both hatches were closed the latch was in close [12:09:26] also in the csm when i had the handle to closed the pressure difference would increase slightly to about one psi [12:10:18] yeah, I had the same thing happen actually [12:14:01] what time acceleration did you use in TLC? [12:16:01] there is some plumbing in the LM ECS that vents from the O2 manifold, if there is an overpressure condition [12:16:48] I wonder if really low FPS and fast time acceleration could make it unstable and start venting [12:21:56] tlc was 60x [12:23:35] and what view are you usually using during time acceleration? [12:23:43] LEB [12:23:48] yeah, good [12:24:00] no frame rate drops or lags [12:24:02] and I guess that should keep the frame rate fairly stable [12:24:04] yeah [12:25:33] also last night i attempted a landing from my pre undocking scenario but i left the kill rotation on by accident for the doi burn [12:25:51] haha, ouch [12:25:59] i never have it on for any burn [12:27:04] right, that's what the computers (AGC and AGS) are for :D [12:29:12] and is there supposed to be a lunar surface pad because i don't think i got one [12:30:20] after undocking [12:31:23] no [12:31:28] after the sep burn [12:31:41] it's given 3 minutes after the time for the sep burn [12:32:35] i should probably record the seperation maneuver pad [12:33:19] you should probably record them all, haha [12:33:21] well, most [12:33:34] I printed out the PADs from the reformatted Apollo 11 flight plan [12:33:40] they are really nice to use [12:35:06] unfortunately i am low on ink so i will use white paper [12:35:28] also for the simulated countdown is there a certain tig used [12:36:39] yeah, I think you will get an Ascent PAD for it on the surface [12:36:45] but basically it's the T3 Abort time [12:36:53] from the Lunar Surface PAD [12:37:16] well i will continue with my mission now [12:37:25] talk to you later [12:38:38] cya [12:44:21] hey [12:45:26] hey Alex [12:45:49] well I lied yesterday... I wasnt back after a few hours haha [12:46:17] we had a major power failure due to a big storm. Lasted 9 hours [12:47:05] damn [12:47:42] can't remember if I've ever had a power failure for that long. [12:48:32] A lot of the city was affected. I dont understand why we dont have underground power lines by now lol [12:48:46] costs more money [12:49:00] yep [12:49:02] but I guess that is the main reason why we don't have long power failures, lol [12:49:41] when there is some flooding here, then locally you can have power failures that last a bit longer [12:54:07] yeah I bet [12:54:43] It would cost an insane amount of money to convert our existing powerlines so I am not holding my breath [12:56:07] ooh a new RTCC MFD mode? ;) [12:56:16] concentric rendezvous processor [12:56:35] existed in the RTCC already for a bit, just not for the MFD [12:57:00] basically calculating what the AGC does with some extra features [12:57:37] and retaining the old CDH calculations [12:59:43] nice [13:02:31] RR XMTR power now works :) [13:04:58] yeah, I was starting to look at the RR Test Mode [13:05:02] making it work properly [13:05:21] great [13:10:29] it looses track when you switch from Auto to LGC mode [13:10:52] I think that's the same reason as the glycol pump thing [13:10:58] you go from Auto to Slew to LGC [13:11:04] and while in slew it's loosing track [13:11:20] but I have to do more reading [13:13:01] oh you mean that thing about the switch behavior in NASSP [13:13:39] that you can skip right over slew, but in reality you had to pass through it [13:32:04] yep [13:40:25] Are you running the latest Orbiter beta? [14:05:01] no, not yet [14:05:13] is there even a DX9 Client for it yet? [14:23:01] not yet [14:23:13] Ill wait until there is one [14:25:40] yeah, same [15:42:19] @indy91 something strange is happening [15:42:37] ok [15:43:13] i made a pdi test scenario from where it was supposed to be 15 minutes to pdi but it appears the agc TFI has changed [15:43:41] agc tfi says 8 minutes and when i set the det earlier i matched it up with the previous tfi [15:44:39] also before i got some pad updates and an uplink at the right time but from my pre undocking scenario i got THREAD STARTED but nothing else and now i am getting those pads about 5 minutes from pdi [15:44:41] weird [15:44:54] oh, that's really bad [15:45:15] MCC got broken [15:45:27] not sure how though [15:45:42] could be just me changing things too often [15:45:58] is that the scenario you gave me? [15:46:07] the before docking one yes [15:49:40] at what point did the THREAD STARTED appear [15:49:41] roughly [15:50:13] did you already have the DOI PAD then? [15:50:18] i think it was 2-3 minutes till pdi ignition [15:50:26] wait nevermind [15:50:33] and you got no THREAD ENDED? [15:50:39] no [15:50:47] just thread started and nothing else [15:51:02] but the first time i used that scenario the pads did appear [15:51:05] that means some calculation has failed [15:51:21] yes [15:51:23] could be my update from today [15:51:34] i didn't get your update today [15:51:46] also just wondering when the t3 abort pad is supposed to appear [15:52:25] lol [15:52:28] long before DOI [15:52:43] and was there an uplink with that [15:53:09] there is an uplink with the T2 Abort PAD [15:53:48] well i got some abort pad with an uplink about 3 minutes till pdi ignition [15:54:11] that's no good [15:54:18] all of that should appear before DOI [15:55:31] did you maybe not allow an uplink? [15:55:42] possibly [15:55:45] and then the sequence got screwed over because all the updates were too late [15:55:48] would that screw things up [15:56:11] yeah [15:56:21] it doesn't calculate the next thing [15:56:31] it waits until the uplink is finished [15:56:33] when i created the undocking scenario the first time i used it everything seemed to be fine by after that everything started screwing up badly [15:56:49] could be a saving/loading issue [15:57:36] have you ever had that before [15:58:00] be back later [15:58:06] okay [16:27:17] astronauthen96__, can you give me the scenario shortly before PDI? [16:31:03] and hard dock [16:31:19] quite challenging that LM active docking [16:31:42] yeah, it's quite different [16:51:49] @indy91 sure [16:52:56] https://www.dropbox.com/s/4ub9q77d5rzz4av/pdi%20test.scn?dl=0 [17:02:01] astronauthen96__, there also is a SV uplink for the CMC after the sep burn [17:02:07] did you also allow that one? [17:02:27] no that one came right in this scenario for me [17:04:37] ok [17:04:46] I flew your pre undocking scenario to the sep burn [17:04:52] right now there is the T2 Abort PAD [17:04:56] and it has an uplink [17:05:03] but the checklist is missing the uplink [17:05:08] do you have to do the sep maneuver [17:05:13] for the uplink [17:05:27] no, it just has the nominal time of the sep maneuver saved [17:05:36] and the trigger for the next PAD is SEP maneuver plus 3 minutes [17:06:01] the uplink that happens there has a CSM state vector, so that is supposed to make sure it includes the sep burn [17:06:32] did you maybe miss this uplink because the Checklist MFD is missing it? [17:06:40] possibly [17:07:43] hmm [17:08:06] when did you get the T3 Abort PAD? [17:08:37] very close to pdi ignition [17:09:04] aha [17:09:10] the uplink is with the T2 PAD [17:09:33] and it won't show the T3 PAD if the uplink hasn't been done [17:09:59] did you eventually do the uplink? [17:10:07] some time before the T3 PAD [17:10:44] on the screenshot of my current state it says right before pdi csm ready for uplink but when i open the scenario it is displaying the doi pad something must be severely broken [17:11:34] DOI PAD also has an uplink [17:12:04] i will just start from my undocking scenario and wait for the 3 minutes after sep maneuver [17:12:17] I just did exactly that with your scenario [17:12:22] all PADs and uplinks worked fine [17:12:25] okay [17:12:40] just looking at your scenario [17:12:46] empty T2 Abort PAD?? [17:13:30] the pdi one? [17:13:56] yeah [17:14:09] I guess you should go back to undocking, yeah [17:14:16] and not forget any uplinks [17:14:22] the MCC isn't flexible about that, haha [17:14:42] if something is forgotten or done out of order there can easily be problems [17:17:50] you also disabled the auto PAD showing, that can contribute to you overlooking something [17:18:07] in that period after undocking there are maaaaany PADs in a short period of time [17:21:07] okay [17:22:16] I mean, maybe the MCC should just continue if an uplink is forgotten. But most uplinks are essential and if you are forgetting one then that can break the normal mission progression anyway, defeating the purpose of using the MC feature. [17:22:34] MCC* [17:32:13] I am still confused how it ended up in the state in that pre PDI scenario though [17:32:55] maybe there is some bugginess going on as well, not sure [18:00:43] APS burn to depletion went well [18:01:18] to depletion one could say [18:26:03] I guess implementing readings for the LR VEL and ALT XMTR is in the works too? [18:26:43] not right now, but it should be easy [18:26:59] the transmitter powers only would vary with temperature or the radars really [18:27:04] and on/off of course [18:27:11] of* [11:19:19] good morning [11:19:31] hey [11:19:32] eagle is at tranquility [11:19:36] great [11:19:52] did the PADs work this time? [11:19:54] yes [11:20:15] for my docking scenario it did the thread started but nothing else [11:20:39] then i exited and reopened the current state and i instantly had a t2 abort pad [11:21:28] in the same undocking scenario you gave me? [11:21:37] i made a new one [11:21:39] ah [11:22:18] so the thread started was for the T2 PAD? [11:22:39] i think so yes [11:22:47] oh [11:22:53] are you updated to the latest release? [11:22:58] no [11:23:05] that probably explains it [11:23:22] for the T2 PAD calculation it does a lunar ascent simulation [11:23:30] which I also had added recently to the RTCC MFD [11:23:46] and there was a bug that didn't happen every time where thre ascent simulation could fail [11:23:48] if i get the latest release will it affect my current state [11:27:13] hmm [11:27:17] only for the better I think [11:27:26] Hey Ryan [11:27:31] didn't do any big changes for the MCC [11:28:16] but yeah, you probably ran into the same issue as Alex did when he mentioned that the ascent page didn't work reliably [11:28:41] but that has been fixed [11:28:59] as of 3 days ago I think [11:31:13] Morning [11:31:22] hey [11:32:14] Which PRO starts the timer in P35 again? [11:32:53] the one where it starts the iteration [11:33:07] on the 16 45 [11:33:23] where you also could do a V32 to recycle, although that is never done in P35 [11:35:13] The first 16 45? [11:35:31] yes [11:36:19] the second one is the last one and the DV has already been calculated then [11:36:51] So how was it determined if one was necessary [11:37:16] Was that gone through and just terminated? [11:37:19] astronaut preference really [11:37:45] I would always go into P41 anyway [11:37:59] and only null the DV a little bit if it's close to 0 anyway [11:38:42] so not really necessary to have a PRO/FAIL decision for the checklist there [11:40:08] astronauthen96__, there will be at least two instances where the lunar ascent processor is used after the landing, so I would update to the latest NASSP release [11:40:13] Well on 9 for example, they opted not to do MCC1 [11:40:43] because of low DV? [11:41:05] Yes [11:41:18] And its in the procedures as an option [11:41:31] if small, skip P41 and recall P35 [11:41:59] But they were supposed to burn MCC2 whatever it was [11:42:31] ok [11:42:43] so you already know more about this than me, haha [11:42:46] do it as you want [11:43:38] I am just trying to tailor the checklist is all [11:43:59] Because I have the PRO timing messed up already so I am going back to fix it [11:44:04] right [11:44:22] I don't think there is a 100% correct answer [11:44:38] unless you find something in mission rules or rendezvous charts for a specific mission [11:49:01] Ok i think I have it cleaned up properly [11:50:26] Now back to 11 [11:50:29] And landing day [11:50:54] are you on the latest release? [11:51:24] Orbiter? [11:51:28] NASSP [11:51:29] Or NASSP [11:51:30] Yes [11:51:31] Both [11:51:33] good [11:51:37] not good [11:51:47] is there even a DX9 Client yet for the latest Orbiter release? [11:52:05] I don't think so but the previous one is working [11:52:33] not sure, but there usually is a recompiled DX9 Client for a specific Orbiter Beta [11:52:36] I'm sure it's fine [11:52:57] There have been a few beta releases without one [11:53:09] none of which I have updated to, haha [11:53:20] but I guess if you ran into no issues so far it's good [11:54:41] Yeah none at all [11:55:16] Is the latest still the one for R73? [11:55:55] I use R27.0 [11:55:58] from May [11:56:00] Yeah thats it [11:59:32] I'm working on a proper RR test btw [12:00:07] there is a frequency lock on and a range lock on. The range one takes about 12 seconds and that applies to the normal operation as well [12:00:18] so in the future the No Track light won't go out immediately [12:05:39] Oh excellent [12:05:51] It will follow the checklist's 12 second tag [12:07:38] yeah [12:07:46] the test specific code is really very simple now [12:08:06] just a fake range and range rate and varying signal strength as a square wave [12:08:29] and the rest is common code for test and normal operation [12:09:27] So are we going to get some signals for the test meter? [12:09:36] yes [12:10:02] Nice [12:10:03] oh and side lobe lock on might also be a thing [12:10:13] Oh that would be fun [12:10:19] have to be careful under AGS operation [12:10:27] the LGC has a program alarm for it, I think [12:10:32] Yes it does [12:10:59] 525 I believe? [12:11:15] Its coupled with the LOS>3deg [12:11:18] I'd love to implement diminishing signal strength over range, but I'm having trouble finding the right function for it [12:11:20] yeah [12:11:21] Or can show up with it rather [12:11:44] we already are simulating side lobes of course [12:11:50] HGA? [12:12:01] rendezvous radar [12:12:02] hey [12:12:05] hey Alex [12:12:15] Ah yeah you can tell from the AGC [12:12:23] Morning [12:12:35] Alex I finally got in and fixed that MCC timing, thanks for finding that [12:20:02] great thanks [12:30:21] Yeah I just had the wait for in front of the wrong pro :P [12:38:35] I mean it probably still worked, but maybe with a few program alarms :p [12:40:29] Haha yeah the timing would have been funky for sure [12:49:24] only problem with the RR Test right now is a tracker light in V63 [12:52:07] or not [12:52:12] seems to be normal actually, [12:52:16] indy91, good progress with the RR test stuff? [12:52:23] I think so [12:52:50] Apollo 17 G&N Dictionary mentions the tracker light [12:52:55] Apollo 11 one doesn't [12:57:21] probably this condition: [12:57:34] "RR data-not-godd discrete occurs during LGC data read sequence" [12:57:37] good* [13:47:48] just noticed the "Move code for Liftoff/No Auto Abort switch to its own class" Is there new functionality for that? [13:49:27] no, it just has its own class now [13:49:54] I'm pretty sure it previously determined the state of the light many times per timestep [13:50:18] so that's pretty inefficient [13:50:29] right [13:50:50] the button and lights were already fully implemented [13:56:05] maybe I should add the CSM not getting a liftoff signal from the IU as one of the SECS failure states [13:56:13] then you have reason to press the button, haha [14:02:31] sure [14:03:59] also, I was wondering if there was a way to cause a guidance reference failure in the IU while in TB5 [14:07:43] hmm, not sure [14:09:37] oh and is Apollo 11 MCC compatible with having an IU guidance reference failure, followed by a manual TLI? [14:09:40] PLATFAIL parameter in the scenario [14:09:45] I am thinking it should already be [14:10:02] you should be able to use any mission time with PLATFAIL [14:10:31] the code looks weird, I don't remember it very well [14:10:58] but "PLATFAIL 1" should give a failure at a random time [14:11:04] but always a failure [14:11:13] during first stage flight it looks like [14:11:22] no, during the ascent [14:11:41] but PLATFAIL with any number larger than 1 will give a failure at that time I believe [14:12:04] yes, MCC should be compatible with manual TLI [14:12:15] MCC-1 will just be longer I guess [14:13:53] yeah I helped with making that code, thats why its weird :D [14:14:02] haha, ok [14:14:20] just could have used some comments to understand it better, but it's ok [14:14:25] but also "PLATFAIL" is saved under this condition: if (stage < LAUNCH_STAGE_SIVB) [14:14:42] good point [14:14:45] that should be changed then [14:15:03] So I dont know if that would mean that if you saved after insertion, but before the planned failure time, it will be lost maybe? [14:15:21] yes [14:15:25] I'll change that [14:15:39] So its just a question of taking it out of that if statement [14:16:25] no [14:16:29] or maybe just putting it in a if statement that goes all the way to SIVB separation [14:16:34] stage < CSM_LEM_STAGE [14:16:38] right [14:17:07] of course it could then give the failure parameters to the separate S-IVB at CSM sep [14:17:29] would failure multiplier also be included? [14:18:07] yeah, probably [14:19:14] before I get into any bigger projects after the MCC I would like to try if all of the LM abort and CSM rescue cases for Apollo 11 are supported right now [14:19:50] one thing that annoys me is the CSI time for the No PDI+12 aborts [14:20:11] there isn't really a good and realistic way to get that time [14:20:26] CDH time is fixed, so CSI time would be half a period earlier [14:20:47] I don't think the two-impulse processor supplies that CSI time [14:21:30] so you would have to find the orbital period after the phasing maneuver, divide it by 2 and subtract that from the CDH time [14:23:01] seems like a complicated process for the RTCC. I wonder if I am missing any display or so where you could more easily get that CSI time [14:26:08] indy91, for the LS uplink/sv update, would it be prudent to have one of the PAD's come up with that instead of leaving the TEI-30 up? [14:26:15] That saves time waiting for another update [14:26:32] that could be done, yes [14:27:10] landmark tracking PAD follows directly after [14:27:15] Yeah [14:27:21] hmm [14:27:28] but there is no waiting time there [14:27:29] But since TEI-30 stays up, you dont get much notice that an uplink is available [14:27:49] PAD follows directly after uplink [14:28:24] But since the TEI-30 stays up, you cannot really tell an uplink is available [14:28:58] It's easy to miss the message [14:29:01] ok [14:29:05] Does that make sense? [14:30:09] well I don't have any problems with missing MCC messages, but I can change it there, sure [14:30:40] I mean for me I never even noticed it because I was still in the LM running a checklist [14:31:16] I think the best course would be maybe just removing the TEI-30 PAD message when it comes up? [14:31:34] what TEI-30 PAD message? [14:32:00] Thats the PAD that is displayed until it is replaced by the landmark tracking PAD [14:32:46] so deleting the PAD from being displayed? [14:33:21] As just a secondary indicator that something new came up [14:33:46] The ready for uplink message goes away too quick [14:34:06] or do you mean that it auto displays the PAD again? [14:34:10] the old PAD [14:35:43] I think in this case I will combined PAD and uplink [14:35:45] Well the pad is still displayed from when it first came up [14:35:47] combine* [14:36:12] I think that more of a good than bad thing. No need to remove the PAD if all you get is an uplink. [14:36:25] but I will combined landmark PAD and uplink for this [14:36:30] combine* [14:36:33] Ok [14:37:11] That ready for uplink just was easy to miss [14:37:50] I typically look for a change in the pad display though as most are associated with it [14:38:02] right [14:40:07] should I make the MCC more persistent about this? [14:40:17] like display another Ready for Uplink? once per minute? [14:42:33] It might not hurt [14:43:01] Especially during a phase like this bouncing between both vehicles [14:44:25] yeah [14:44:38] adding that is actually quite easy [14:45:08] and once per minute is not super persistent but if you overlooked it, then it can be a help [14:45:16] and 1-2 minute delay is never critical [14:50:42] pushed the updates [14:51:07] Thanks! [14:52:30] yeah I agree with making the MCC annoy you if you miss an uplink [14:52:54] Haha as I am sure the CAPCOM would as well ;) [14:53:06] I think mission control would be all over you in reality too lol [14:53:16] yeah [14:53:18] if you are in that 3 minute window that the MCC spends in the state 112 (waiting for the CSM DAP Data PAD) then you might need to decrease the state by one [14:53:47] but that's all that got "broken" from before [14:54:20] would be great if you could test the new combined PAD and uplink, Ryan [14:54:45] indy91, is the new RR test stuff in that update too? [14:54:49] not yet [14:54:56] I think it's mostly done though [14:55:23] brb [14:56:02] want to test some side lobe acquisitions [14:58:28] Hey Alex [14:59:23] @indy91 something strange happened during pdi i got a thread started and thread completed then nothing else [14:59:35] PDI Evaluation [14:59:43] It checks if you started PDI [14:59:46] but when i landed i did get the we copy you down Eagle [14:59:53] haha, yeah [14:59:58] just a place holder message [15:00:14] maybe I leave it in, but that is the "landing evaluation" [15:00:25] I've added those to check if the mission has normally progressed [15:00:39] if PDI hasn't been started for example it should cycle to a second PDI attempt [15:00:43] and give MCC updates for that [15:00:50] but that is not completely implemented that [15:01:18] The thread started/completed without any info about it are a bit confusing [15:01:32] maybe it should at least some message like "PDI looks good from here", haha [15:01:39] at least show* [15:01:49] or you are go to continue powered descent maybe? [15:01:56] it would make sense as thats what its really doing [15:01:59] oh, that's good, yeah [15:02:52] astronauthen96__, hey [15:03:04] eagle is at tranquility [15:03:10] nice [15:03:41] Looking forward to fly Apollo 11 MCC myself, but 1st I will fly 10 [15:03:55] well finish 9, then fly 10 [15:04:42] Hopefully you guys have sorted the initial bugs by the time I get there :p [15:04:53] well i can tell you that Niklas's mission control for 11 works perfectly [15:05:01] I bet it does [15:06:33] Also Niklas should i have been writing down those abort pads? [15:07:02] you don't have to, no, they don't contain important information about the nominal mission [15:07:25] was not there a TIG for the simulated countdown for the TPI i think? [15:08:05] yeah, on the surface you are getting an Ascent PAD and CSI PAD for a launch one revolution after landing [15:08:16] write down the Ascent PAD, you need the numbers in P12 [15:08:18] polay [15:08:22] okay [15:08:44] very excited for the rendezvous [15:09:22] just needs a good P57 before launch and it's easy [15:09:52] just need to memorize the translation controls for the number pad on the keyboard [15:27:43] so I added "PLATFAIL 2200" to an post insertion scenario starting at 2182, but the failure does not occur at 2200 [15:28:03] maybe it only works from pre-launch [15:30:49] yeah, it has to initialize the failure [15:31:34] if (stage > PRELAUNCH_STAGE) return; [15:31:40] it has this condition on it [15:32:29] ah ok [15:42:04] I also think we should add some better time accel limiting from just before GRR to post TLI [15:42:40] maybe 1x from -20s to insertion, and 10x up to post SIVB separation [15:45:09] yeah [15:45:27] 1x during IGM is ok though [15:45:32] 10x [15:46:06] right [15:46:39] I think I had issues though at S1C staging with 10x. The SII engines would not ignite [15:46:55] unless I went back to 1x manually before staging [15:47:08] But that may of been fixed, Ill test it again [15:48:12] oh but I guess IGM is after SII ignition anyway [15:48:41] dont know if the same issue would happen after SII staging/SIVB ignition [15:49:38] I have to check [15:49:52] didn't look at any LVDC stuff in a while [15:50:56] you know how with the Gemini computer they had to transfer the program for entry etc. from a tape or so? While in orbit because the computer had limited memory. [15:51:20] That's how my brain is like after working on RTCC stuff for a while and someone mentions the LVDC or IU or Saturn stuff in general :D [15:54:58] haha I bet [15:55:45] the issue with the ignition were the switch selector commands to the stage [15:55:52] btw I did not know that about the Gemini computer... REALLY!? thats insane lol [15:56:05] later revisions of the Gemini software, yeah [15:56:30] with time acceleration the commands are not issued quickly enough [15:56:43] and then it runs into the engine failure code [15:56:53] failure logic* [15:57:16] timing and scheduling is a big issue with the current LVDC [15:57:39] that will need some improvements soon [15:58:10] Hey [15:58:40] Back from another week camping. ATMega's came in today. :) [15:58:49] Hey @Thymo eagle is at tranquility [15:59:08] just landed this morning [15:59:09] Sweet! [16:00:21] I've hooked one of the uCs up to my RPi and a breadboard. I guess I should find out how to write and compile to make a LED blink as a test. [16:26:25] @indy91 also i got 00000 on the doi p52 [16:26:43] was not there a name for that like all balls or something? [16:29:11] yep [16:29:13] all balls [16:29:25] indy91, that update now causes a CTD :/ [16:29:32] watching it on vintage space right now [16:29:49] "Thresd Started" comes up, it hangs for a bit, and CTD [16:30:08] Ryan i got the thread started too but no ctd [16:31:53] For the LS Uplink? [16:32:26] no for some of the abort pads for 11 [16:34:07] This is for a specific thread that was just changed [16:39:57] ok [16:40:50] astronauthen96__, your issue was probably caused by that bug in the T2 calculation that had already been fixed in the most recent versions [16:40:58] I had to load an older quicksave, I will try to get a debug on it for you [16:41:07] Still not back to that time yet [16:41:30] well i did get the thread started issue but when i exited orbiter and went to my current start the t2 pad was there [16:41:41] but empty, right? [16:41:45] no [16:41:53] ah [16:42:05] yeah, it wasn't consistently broken [16:42:08] at least i don't remember it being empty [16:42:08] worked often [16:42:17] but not always [16:42:53] rcflyinghokie1, I know what the problem is [16:42:54] my bad [16:43:01] Haha ok [16:43:21] Also something interesting I am noticing, whenever batt 2 is switched from lo to high, the dc bus light comes on [16:43:32] The other bats dont have the same effect [16:44:10] oh never mind [16:44:23] Its any of the SE bus [16:44:43] indy91, btw is that LS update a LS REMSMMAT or RLS update? [16:45:13] LS REFSMMAT [16:45:18] ah ok [16:45:30] and it does the descent planning there [16:45:34] Are there any RLS updates before PDI? [16:45:35] and now also a landmark tracking PAD [16:45:41] don't think so [16:46:02] I guess one is not really needed [16:46:24] It will be interesting to know how MCC will go about updating the RLS on the future missions [16:46:27] not at that point [16:46:42] but the CMP does some tracking on the landing site a bit later [16:46:51] so a later uplink would have a RLS update [16:46:59] ah ok [16:47:29] rcflyinghokie1, fix pushed [16:47:40] I guess in Apollo 11 MCC, that part is not covered since its during LM surface ops [16:47:42] especially radius is the thing [16:47:59] yeah, it would need to evaluate downlink data from P22 [16:48:02] not supported yet [16:48:22] and it would have to decide if that tracking actually made the landing site vector any better [16:48:51] Something that will definitely needed for Apollo 12 [16:48:54] a bit too advanced for the MCC right now [16:49:07] but thats for the next NASSP version [16:49:48] if you can mark on the Surveyor and actually improve the landing site radius in NASSP then that's already impressive [16:50:00] yep [16:50:02] it does [16:50:48] But also, Apollo 12 had the wrong RLS, its a few 1000 ft off to the right of Surveyor [16:51:32] ah, I see [16:51:49] you can always do it manually and store your P22 data in your RLS [16:51:57] The real mission I mean (and naturally our initial RLS in the scenario) [16:52:11] yep thats what I did on my last Apollo 12 run [16:52:17] works quite good [16:52:20] great [16:52:57] I have warnings in that build [16:53:09] Severity Code Description Project File Line Suppression State [16:53:10] Warning LNK4098 defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library ProjectApolloMFD F:\Orbiter 16 Beta\Orbitersdk\samples\ProjectApollo\Build\VC2017\LINK 1 [16:53:48] what did I break now [16:54:19] Same error in ProjectApolloMFD ProjectApolloConfigurator and ApolloRTCCMFD [16:54:39] I didn't change anything of that kind [16:54:49] I added new files [16:54:55] separate files for the RR code [16:55:08] and that requires changes to the project files [16:55:19] mine built fine [16:55:30] is the commit from right now or the earlier one today as well? [16:55:31] I can try another clean/build [16:55:38] This is the most recent [16:55:50] I didnt notice in the previous one [16:56:00] well I just added two lines of code, nothing more [16:56:05] so yeah, try a complete build [16:56:12] I will try that again [16:57:08] rcflyinghokie1, did you leave Orbiter running before rebuilding by any chance? [16:57:14] made that mistake before lol [16:59:34] NOpe [16:59:38] And same errors [16:59:42] brb [17:00:03] hmm the latest build is fine for me, weird [17:00:42] error or warning? [17:28:46] @indy91 do you have a list of the codes for the different letters for the AOT? [17:30:19] astronauthen96__ Its in the LM G&C dictionary [17:30:49] https://history.nasa.gov/afj/ap12fj/pdf/a12_lm_g&n.pdf [17:31:41] Guenter? [17:31:50] already gone to bed [17:31:54] haha [17:33:17] oh but I guess we have an Apollo 11 LM G&N dictionary now dont we [17:34:24] that we do [17:35:35] hmm, I dont think I got my hands on that one. Have a link? [17:36:43] http://hdl.handle.net/2152.3/9629 [17:37:17] thanks [17:37:23] Ah there he is [17:38:34] Well that is useful [17:39:13] Any word on my build warnings by chance? [17:41:31] well it's a warning, so it can't be that bad [17:41:45] I don't know why it would happen [17:42:41] especially with such a harmless commit [17:49:21] cant seem to find the codes in both documents [17:50:59] in the section about P52 and P57 [17:51:28] page PGNS-40 in the Apollo 11 onr [17:51:29] one [17:58:19] No CTD on the uplink :) [17:58:48] well it was the landmark PAD that caused it [17:59:01] without knowing which vehicle to calculate that PAD from it had some issues :D [17:59:10] PAD for* [17:59:27] back in a bit [18:00:12] there were two lines of code that all the landmark tracking PADs for Apollo 11 have in common and I forgot to copy them over to the earlier calculation [18:03:24] got it thanks [18:13:45] oh wait, I forgot. If I want to try all the 18 rescue cases for Apollo 11 I have to use the sextant with the lack of VHF Ranging. That's like actual effort [18:14:16] I could let the LGC calculate the burns though :D [18:14:26] Yeah like manually putting in AGS stuff :P [18:14:43] I've never really tried those programs before [18:14:46] lots of effort [18:14:47] P72 to P75 [18:16:39] but they are really just different in their end product [18:16:43] I have used them when I was comparing AGS PGNS CSM data [18:16:46] a DV for the CSM and not for LM [18:16:51] Oh never mind [18:16:55] I used 32-34 [18:17:11] For LM dV [18:17:52] in the CMC? [18:19:17] Yes [18:19:44] I believe? [18:19:48] Haha now I don't remember [18:20:07] some maneuvers are compatible [18:20:13] I think you just bias the CSM solution or so? [18:20:20] there are charts for it [18:21:07] I think [18:25:46] So is the V35 in the LM supposed to light the ISS CW light? [18:25:56] I cant remember haha [18:28:54] GG9002X [18:28:58] I guess that' [18:29:04] is triggered by the self test [18:29:18] But is it supposed to be [18:29:32] Yep [18:29:40] Answered my own question I'll see myself out :P [18:35:02] @indy91 got another thread started with the ascent pad [18:35:12] then i reopened the current state then the pad was blank [18:35:20] then i reset the state and it showed the pad [18:39:44] astronauthen96__, did you update to the latest NASSP release yet? [18:40:09] if not then it's the same bug as you got with the T2 PAD [18:40:12] no but i will now [18:40:22] that should fix it, I think [18:40:28] if it is the bug that I think it is [18:58:21] Hmm for inhibiting roll commands would that been done in DAP or Auto RCS switches? [19:02:04] Auto RCS switches [19:02:41] DAP would be like: "If you don't give me any roll jets I can't do this attitude hold thing anyway, so no point even telling me about it" [19:03:04] DAP could deal with specific failed quads etc. [19:05:29] the CSM Rendezvous Procedures document basically has all the pages that would be in the CMP Solo Book [19:05:58] also only says "Disable CSM Roll Jets", but further down it specifically gives V48 inputs [19:06:04] Ah ok [19:06:06] so the roll jets are probably Auto RCS, yeah [19:06:20] So I just need to confirm which roll jets are set in DAP and shut those off [19:06:35] or just all of them [19:06:43] True [19:06:55] just after the LM RCS hot fire it has "enable A&C + B/D Roll" [19:06:57] A/C* [19:07:23] and then even a few minutes later two Auto RCS jets off to not do bad stuff to LM equipment [19:08:20] Yeah this one in particular is to prevent tunnel torque while the docking latches are cocked and the probe/drogue is put in to place [19:08:30] Bad time to torque the tunnel [19:08:53] ouch, yeah [19:09:07] I was reading a bunch about those tolerances [19:09:52] looking at the next page in the CSM procedure, it has some useful stuff for your checklists [19:09:59] that is not in the flight plan I think [19:10:07] In the solo book? [19:10:18] the pages that would be in the solo book, yeah [19:10:23] Can you link me? [19:10:50] actual NTRS for once [19:10:54] Nice [19:10:55] https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19700025402.pdf [19:11:07] PDF pages 34 and so on [19:11:20] those look very similar to the Apollo 12 CMP Solo Book we have [19:11:32] and they are a bit more detailed than the flight plan [19:11:39] not much, but it might help here and there [19:12:10] Yep thats almost where I am [19:12:17] Thanks [19:12:35] brb [19:44:17] back [19:45:46] welcome back [19:47:32] thanks [20:01:31] any chance the new RR stuff would be ready tonight? ;) [20:02:18] nope [20:02:59] I'm sure it's buggy still [20:03:09] essentially complete though, I think [20:05:43] haha fair enough [20:07:27] I've pushed fairly broken stuff in the past, but this is just one general test short of being "push-able", haha [20:08:55] yeah [20:09:51] but I'm quite happy with the solution [20:10:18] it's less of a test mode update that a general RR overhaul that then requires almost no special RR test mode [20:10:37] just fake range, range rate and signal strength from the RR test subassembly [20:10:57] and the rest of the RR treats it as a normal signal [20:11:37] makes sense [20:11:53] Wasnt the EMS supposed to get a similar overhaul like that? Or maybe it has [20:12:38] haha, yeah [20:12:45] I had a development branch that was 99% ready [20:12:56] but I couldn't get it into agreement with the checklists [20:13:08] some light coming on at the wrong time or so [20:13:14] oh lol [20:13:17] it was basically schematic vs. checklist [20:13:44] but that EMS overhaul was the reason I found out timesteps are different in Orbiter 2016 [20:13:59] the EMS uses biases for its accelerometer for the test modes [20:14:10] and we had an oscillating acceleration instead of 0 in space [20:14:17] so it failed the tests, haha [20:14:32] at some point I'll implement all that stuff again [20:14:47] ok 99% isn't quite right, it also would need a change of the EMS bitmap [20:15:20] because the test patterns aren't perfect [20:17:14] yeah I guess well have to find a proper lunar return bitmap. If I am not mistaken weve been using an LEO on all along [20:18:36] I think there are 3 different patterns [20:18:53] 2 lunar ones, with exiting of the atmosphere and without [20:19:01] and then the LEO one is also different [20:43:34] night [11:15:23] good morning [11:15:27] about to burn csi [11:15:43] hey [11:15:53] lunar surface phase already done? [11:16:04] did it all yesterday [11:16:19] then went up to ten minutes to csi then quit as a i had a severe headache [11:18:12] how large is your plane error? [11:19:45] i have no idea [11:19:53] Rinc is 0.01 [11:20:36] oh, awesome [11:20:39] that's really good [11:20:45] is that after or before CSI? [11:20:53] before [11:23:01] yeah, quite good [11:23:14] and I guess the last P57 on the surface was also good then [11:23:30] 00002 or3 i think [11:27:58] yeah, well done [12:40:30] Good morning [12:42:12] hey guys [12:42:50] Hey [12:43:36] morning [12:44:07] Ok this is a RANDOM question, but something that is partially related, they said on the news yesterday when talking about the new Armstrong biopic that buzz aldrin played sinatra while walking on the moon...now I cannot find any technical references to this nor do I imagine they would have had the tape player in the LM, let alone out on the surface! [12:44:59] And on wikipedia (which I think is incorrect?) " It became the first music heard on the Moon when played on a portable cassette player by Apollo 11 astronaut Buzz Aldrin after he stepped onto the Moon" [12:45:10] So much seems wrong with that statement [12:46:20] can't find anything in the transcript [12:46:54] Nor could I [12:47:11] And they wouldnt have had the tape player in the LM I would imagine [12:47:25] And of course playing it on the surface would do nothing [12:48:23] The only "kernal" of truth I can think about this is maybe it was played in the CM sometime orbiting the moon, but I think the news and Wikipedia are dead wrong on this account [12:49:10] I probably don't even have to ask, but is Wikipedia having a source on this? [12:49:22] they had tape players on the missions of course [12:49:49] during the Apollo 15 lunar liftoff, was that Air Force Song played from the CSM or LM? [12:52:27] short distraction on my part. I wondered where the flight controllers were getting general orbit parameters from. And I have good info on the FIDO Orbit Digital Summary display, so for the first time I am implementing a full mission control display in the RTCC MFD. [12:52:48] basically the Orbit MFD for the FIDO [12:53:44] This source seems so wrong [12:53:49] https://www.nytimes.com/1990/11/18/magazine/on-q.html?pagewanted=all&src=pm [12:54:00] Mystified, Jones asked someone who the man was. "Why that's Buzz Aldrin," came the reply. [12:54:01] Later, the astronaut came up to Jones again. He said that just as he was getting ready to step off the spacecraft, he reached back and took the cassette of "Fly Me to the Moon" that Jones had arranged and conducted for Count Basie and Frank Sinatra, and he played it. [12:54:01] "The first music played on the moon," Jones says. "I freaked." [12:54:22] That is impossible in so many accounts [12:54:39] Apollo 10: [12:54:39] 145:48:12 (Music: It's So Nice To Go Traveling - Frank Sinatra.) [Long pause.] [12:58:40] However there is no way Aldrin played that tape on the surface with his cassette player :P [12:58:56] yeah [12:59:00] maybe in the LM [12:59:09] but even for that I can't find anything [12:59:19] I doubt they brought it in the LM on 11 [12:59:30] Weight/dust contamination [12:59:46] And they were all business on the surface especially for 11 [12:59:59] Maybe J missions [13:00:00] the source on this seems to be Quincy Jones himself [13:00:12] Yeah, in 1990 though [13:02:08] indy91, a FIDO display sounds neat [13:02:39] yeah, doesn't even need any new stuff, just a collection of calculations that are already available [13:02:58] it gets updated automatically every 12 seconds [13:04:17] I needed to make the font for that page a bit smaller or else it all can't fit [13:05:20] yeah I bet [13:06:18] the display looks similar to the general purpose maneuver one [13:06:59] there also is a similar display, space digital summary display [13:07:06] that one is for cislunar flight [13:07:15] has stuff like pericynthion time, altitude etc. [13:07:26] the orbit one is mostly for Earth and lunar orbit [13:08:37] most of the documents I have only show the display but don't explain what all the numbers mean, but one of the RTCC documents has the detailed description, luckily [13:14:27] nice [13:15:16] Are you doing the space digital summary display as well? [13:15:46] I plan to, yes [13:16:59] AlexB_88, up for some RR testing? [13:17:08] sure! [13:18:04] btw this guy on the forums is trying to land Apollo 11 at Taurus Littrow... Oh Boy :D [13:19:05] I've tried his scenario [13:19:10] most things look good [13:19:15] RLS wasn't updated I think [13:19:22] and then P63 works but something strange happens [13:19:29] it goes directly to V06 N63 [13:19:31] not N61 [13:19:45] and the display is nonsense and I can't PRO to the next one [13:19:59] I wonder if he tried starting P64 or so and messed up some flags [13:20:34] yeah maybe [13:21:02] Yeah remember that was an issue on 10 [13:21:22] Starting the P64, and then exiting created some flag salad so they removed it [13:21:35] wasn't it P63? [13:21:44] an Average G flag [13:22:08] pretty sure that specific issue was fixed on Apollo 11 as well [13:23:08] Ah yes [13:23:23] AlexB_88, FIDO display and RR test update pushed [13:23:27] hope you find some bugs, haha [13:23:30] I am sure there are some [13:23:35] oh I will try [13:27:19] it's not just the test mode that was changed, so some general RR testing would also be good [13:34:19] 1st test looks good [13:34:33] Ill try some general RR stuff too [13:40:25] so I get the tracker light after doing the V63E, and it stays on for 12 seconds and extinguishes at the same time as the no track light [13:42:53] yeah [13:43:01] the Apollo 17 G&N Dictionary has that [13:43:04] 11 and 12 not [13:43:41] the cause is that no data good indication to the LGC is present yet [13:44:40] not sure if that is an electronics difference [13:44:59] but when you initially switch to LGC mode it doesn't have an auto track signal to the RR anymore [13:45:08] and that should make it loose range lock [13:47:49] so not sure, I think the tracker light there is right [13:48:24] yeah they probably had it in 11 and 12, but forgot to add it to the checklist [13:49:00] also I find that if I cycle through the slew position, the behavior is different [13:49:17] like the tracker light does not come on in that case [13:49:32] btw I really dig this FIDO display [13:50:59] yeah, it should be pretty realistic [13:51:04] two things still missing [13:51:19] you can specify a GET and it gives apogee and perigee information for that time [13:51:37] and if the orbit intersects entry interface it displays some info on that [13:52:00] already implemented are calculate GET from longitude and calculate longitude from GET [13:52:09] When i get this checklist up to undocking I will PR them and try your new changes as well [13:52:16] great [13:52:32] Figure I will do it before my RR tests :) [13:52:43] and another thing to note is that the FIDO orbit page only updates the state vector when you press update [13:52:50] what LPP/PPP? [13:53:05] and TAPP [13:53:09] so all of the current state displays are derived from that initial state vector, not current [13:53:17] right [13:53:25] lol, I don't know much about the differences between RTCC and RTACF, but I know two things [13:53:30] RTACF displays would be static [13:53:38] and it couldn't display greek letters [13:53:48] so our display is the RTACF one right now [13:53:54] L is longitude [13:53:58] P is phi I guess, latitude [13:54:04] so LPP is longitude present position [13:54:12] PPP is present latitude [13:54:15] TA is true anomaly [13:54:29] LNPP is longitude of the ascending node [13:54:53] K would be K-Factor, which is drag basically, so it's always 0 for us right now [13:55:48] so yeah, this is what the FIDO would usually see [13:55:54] I'm sure he had other displays available [13:56:09] but he probably had this for CSM and LM up quite often [14:07:21] Hmmm something interesting [14:07:22] So I did find one thing but I dont think its a bug [14:08:31] Ah never mind, getting ahead of the flight plan :P [14:08:50] old scenarios with the RR already locked on the CSM and no track light off, load with the no track light on for several seconds (and sometimes the tracker light) and then they both go out and all is fine [14:09:53] AlexB_88, yeah, I have implemented a new timer for the range lock on [14:09:55] the 12 seconds [14:09:59] saved in the scenario [14:09:59] But then I save and reload and then it doesnt have that behavior (The scenario loads and the no track light goes out almost instantly, not after a few seconds) [14:10:37] in new scenarios the light also is on for a moment? [14:10:47] like less then a second [14:11:01] still a bug I think [14:11:17] but yeah, old scenarios don't have the timer saved [14:12:25] also, whats the purpose of setting the NORRMON flag during the RR test? [14:13:11] I think it has something to do with Mode I vs Mode II [14:13:19] NO RR MON [14:13:22] no RR monitoring [14:15:19] right [14:15:51] just testing some marks now in P32 [14:16:01] and about the light, I think it just needs one or two more parameters saved in the scenario [14:24:01] so every time it loses lock, when it regains lock it will have a timer before the no-track light goes out correct? [14:26:22] yeah [14:26:51] in the electronics there is a separate frequency lock and range lock [14:27:02] frequency lock can happen instantly basically [14:27:15] that's why in the test mode you get the range rate display [14:27:22] but range only after the 12 seconds [14:37:20] So in reality I can see how they would not get the tracker light during the self test [14:38:44] Because after setting the NORRMON flag, you go from AUTO TRACK TO LGC and then it says to wait 10 seconds. So by the time you get to V63 the no track light is already out again [14:38:58] and you would not get the tracker light [14:39:24] oh, the light goes out again on its own before V63? [14:39:30] is that the right behavior? [14:39:47] when you switch to V63 it does a RR CDU Zero I think [14:39:52] which can take up to 10 seconds [14:40:02] uhh [14:40:07] when you switch to LGC mode I meant [14:40:50] it goes out on its own if you pass through slew [14:41:01] oh, ok [14:41:06] which it would have been inevitable in reality [14:41:51] yeah [14:42:00] so you think the behavior is all right? [14:46:31] yes I do [14:46:51] great [14:47:13] I really only implemented it as per Systems Handbook and AOH, not to work with the checklists [14:47:30] gives some unexpected results as with the tracker light, haha