[16:07:06] NASSP Logging has been started by thymo [16:08:03] Did some well needed maintenance to the box. I also cleaned up Guenter's database a little bit. [16:08:51] Oh fun [16:09:24] ready to do cabin closeouts again [16:10:57] And I am ready to try to time a P22 during LM activation [16:11:04] This might be tough [16:11:22] haha yeah, the timing is a bit unfortunate [16:14:56] I MIGHT be able to make it [16:30:01] Looks like it can just squeeze in [16:35:09] hey again [16:35:21] 2 minutes from plane change [16:35:41] you probably don't really need one I guess [16:35:55] me? [16:35:57] yeah [16:36:13] with the tiny plane error you had [16:36:37] i will tell you the V16 N85 [16:36:48] r00059 [16:36:57] r2 00018 [16:37:05] r3 00036 [16:37:53] wait what? [16:37:56] for what maneuver [16:38:18] that doesn't look like a plane change [16:38:20] plane change [16:38:53] if your attitude isn't totally off then you would only have a R2 [16:39:07] something must have gone wrong [16:39:22] is your plane error on the Align Plane MFD still 0.01° or os? [16:39:25] so* [16:40:12] yes its 0.01 [16:40:19] that just doesn't look like a plane change to me [16:40:26] very strange [16:40:39] what did you enter in P30? [16:40:49] CDH-30 as the TIG [16:40:53] yes [16:41:06] and the DV should be R2 in V90 only [16:41:14] entered as R2 in P30 as well I guess [16:41:25] so no R1 and R3 entered [16:41:30] i remember when it said to copy the ydot it was 00004 [16:41:41] so 0.4 ft/s [16:41:48] but what DV did you enter in P30? [16:41:56] maybe by accident the whole V90 display? [16:42:02] i did not enter a dv in p30 [16:42:03] Noun 90 [16:42:28] well i have just over 2 minutes till the burn is it too late to fix [16:42:30] and now you are trying to burn a not DV? :D [16:42:38] scrub the burn [16:42:40] you don't need it [16:42:46] 0.4 ft/s out of plane, lol [16:42:53] they wouldn't burn that up to 5 ft/s I guess [16:42:54] is +00004 too low? [16:43:02] that's perfectly in plane [16:43:10] so low that you don't need the burn [16:43:19] I wouldn't even burn it if it was 10x the DV [16:43:27] that is great to hear [16:43:51] if you didn't enter a DV in P30, what are you trying to burn then? [16:44:10] that makes sense [16:44:27] Woo the P22 fits in perfectly [16:44:42] i will go do cdh now [16:44:51] hey Ryan [16:44:59] just doing my second rendezvous [16:45:24] astronauthen96__, did you just PRO through P30 and left the DV as it was in it? [16:45:37] yes [16:46:05] there is no plane change program calculating the DV, you have to manually enter it from V90 data [16:46:09] that 0.4 ft/s [16:46:21] so what you should have entered was 0 0.4 0 [16:46:24] as the DV [16:46:28] if anything [16:46:48] so i am still scrubbing it right? [16:47:07] yeah [16:47:18] okay i will talk to you after cdh [16:47:21] TPI can compensate for that little bit out-of-plane velocity [16:47:24] sure [16:48:43] Ok at 99h [16:48:49] Waiting for the LGC update [16:49:22] coming at you at MoonRev >= 12 && MoonRevTime > 65.0*60.0 [16:50:27] Yep I have that page open :) [16:50:56] Its been a help, not that I dislike bugging you for each one or anything... [16:53:53] haha [16:54:15] So am I getting any LGC abort constants here [16:54:21] nope [16:54:30] the ones your LGC has are good [16:54:33] Ok [16:54:49] abort constants calculations is not quite mature enough to be included in the MCC [16:55:15] No problem [16:55:39] Now I get an AGS K factor here [16:55:45] yeah [16:55:47] 90h GET [16:55:52] congrats, you did it right on time [16:56:16] Haha I havent initialized the AGS yet [16:56:23] Or the AGS time yet [16:56:24] see, even better [16:56:31] no, that's not good really [16:56:49] Shouldn't I get this update after I do those steps? [16:57:04] yeah [16:57:09] in the flight plan it's very close by [16:57:26] Yeah its LGC update, V47/time initialization, then K factor update [16:57:29] I guess normally you would do the initialization and then get the PAD right after [16:57:51] Might be smart for a 3 minute wait for that [16:58:01] yeah, I'll do that [16:58:08] I even left a placeholder MCC state for that [16:58:22] goes directly from MST_G_LUNAR_ORBIT_PDI_DAY_10 to MST_G_LUNAR_ORBIT_PDI_DAY_12 as you can see [16:58:32] Yeah I saw that [16:58:32] MST_G_LUNAR_ORBIT_PDI_DAY_11 is for the case I need to implement that [16:58:47] left a few others for e.g. S-Band antenna angles, if necessary [16:59:12] so I'll only have an uplink there, right? [16:59:22] tell me if 3 minutes is good for that [16:59:53] I think it should be [16:59:58] tricky to implement it any better way [17:00:00] I will time it to make sure [17:00:05] it would have to look at the AEA state [17:00:12] 5 minutes might be a safe bet though [17:00:37] I will need time for the uplink, the AGS 377, and the V47 [17:00:45] Lets see how long this takes [17:01:45] Damn my last quicksave was 15 minutes prior [17:01:50] Oh well [17:01:56] I will accellarate to see [17:02:04] accelerate [17:06:33] did that build warning go away for you? [17:06:54] Nope [17:09:15] I think you are go on that alarm [17:09:16] I cant remember, did 11 use the 90 hour bias the whole time? [17:09:24] nope [17:09:28] not for the ascent [17:09:30] Thats right [17:09:40] in the Data Cards there are some AGS times for CSI etc. [17:09:49] those are referenced to 120h I think [17:09:50] 120h for ascent? [17:09:52] Ok [17:12:29] Took about 4 minutes from the pad to finishing the V47 [17:12:41] So maybe 6 minute gap to be safe? [17:14:07] ok [17:14:19] and then 3 minutes for the AGS PAD [17:14:50] Are you splitting up the k factor and abort constants then? [17:14:53] which is followed by the sep maneuver PAD. Will get awefully close to LOS with this timing [17:15:13] LGC uplink is one update, AGS update with K factor and abort constants as one [17:15:35] Yeah that will be perfect, I say a 6 minute gap between those two [17:15:50] And then 3 minutes after that for sep? [17:16:09] yeah, 3 minutes to write down the AGS stuff [17:16:14] Perfect [17:16:29] then sep PAD and LOS will follow quickly, haha [17:17:09] Now with this K factor, did the crew run another V47 with that k factor? [17:18:01] Hmm [17:18:16] I think that V47 was done after the K factor [17:18:30] Just the entering of the time in the DEDA was done first [17:18:35] Then the K factor [17:18:39] ok [17:18:40] Then the V47/initialization [17:18:43] so less than 6 minutes? [17:18:46] Yeah [17:18:51] I'd say 3 is fine then [17:19:00] ok [17:19:01] It took me 3:51 [17:19:16] But that was with the full V47 [17:19:19] right [17:19:27] I will tweak the procedures to match this [17:19:39] on the next rev you will run into the annoying issue with state vectors being too far ahead [17:20:06] I'll be interested in your opinion about that, if the procedures are still possible to do in time etc. [17:20:49] Sure [17:21:10] This whole section will be tight up to undocking [17:23:28] next rev is also even worse with PADs, haha [17:23:30] so many of them [17:24:28] Ok jumping back to the P22 and seeing how this timeline progresses [17:26:37] I can push the current state if you want [17:26:38] Hmm could by build warning be because I am using the new orbiter beta? [17:26:41] Sure [17:26:51] my build* [17:26:51] including combined DAP PAD and gyro torquing angles [17:26:56] oh [17:27:01] yeah, that is possible I guess [17:27:12] I mean I have had no ill effects that I have seen [17:27:18] Just the warnings [17:27:22] now that I think about it... [17:27:35] Dr. Schweiger mentioned some weird Visual Studio stuff he had going on [17:28:08] I remember skimming that but didnt read in depth [17:28:12] pushed [17:28:16] me neither [17:43:57] So that 35 degree position for P22, is that designed so it clears the LM? [17:44:06] Or is it a coincidence [17:47:28] you mean the T2 time? [17:49:04] Yes [17:49:32] Seems like at least in NASSP thats when the landmark clears the LM obstruction [17:50:15] I am sure that is taken into account [17:50:22] well [17:50:48] more like the attitude 2° below local horizon is chosen so that it works with that T2 time [17:51:59] So either way it works out [17:56:42] Hmm so I am doing the dap set gimbal drive test and I keep getting plagued by RCS flags [18:01:43] Bunch of program alarms as well [18:01:49] 2004 [18:02:27] hey again [18:02:34] Am I missing something? [18:02:35] Hey [18:02:43] about 10 minutes to cdh [18:02:56] Fun [18:03:27] r1 +00071 R2 +00021 R3-00007 [18:04:24] @indy91 do these dv's sound good? [18:04:51] Nominal was -1.1 0.0 4.1 [18:05:18] Wondering why your cdh is mostly in the x direction [18:05:31] Where it should be mostly radial to "twist" the orbit [18:06:03] hope i didn't do anything wrong [18:06:53] Probably not [18:07:07] Could have been a mistake on ascent or csi [18:07:33] Actual was I think -8 -2 -18 something like that? [18:07:41] I'd need to look [18:08:35] Yeah -8.1 -1.8 -18.2 [18:08:39] Was actual [18:09:03] ours should be better than that [18:09:42] I had -0.5 -1.8 -2.1 [18:10:22] 2004 alarm is lots of jet failures [18:10:32] are you through RCS activation yet? [18:10:49] Nope [18:11:01] Setting the DAP set them off [18:11:13] hmm [18:11:35] were you maneuvering with the CSM? [18:11:44] DAP is set to 32012 [18:11:53] 1 in D means a larger deadband [18:12:07] I think that is what normally would prevent LGC RCS firing commands [18:12:13] No it was in wide db hold [18:12:26] what's your PGNS mode? [18:12:32] AUTO [18:12:47] you sure that is correct? [18:12:53] Per the 12 checklist [18:13:00] in any case, cycle to off and back to auto [18:13:06] maybe that stops the alarms [18:13:19] in auto it would want to go back to the original attitude [18:13:27] and sends jet fire commands [18:13:37] Yeah that did it [18:13:42] wide db hold in the CSM? [18:13:47] maybe you drifted too much [18:13:50] I wonder if the CM fired on a DB when I did it [18:13:52] out of the deadband for the LM [18:13:58] maybe [18:14:02] And yeah CM is in wide [18:14:19] only for RCS checkout though, right? [18:14:21] usually in min [18:15:19] Ah cm side "at request of the cdr" [18:15:20] oh wait, it should be under CMC control [18:15:33] no [18:15:34] Yeah and I have the last DAP I got [18:15:35] that's later [18:15:58] According to the FP, SCS is right about the time of the dap set [18:16:05] that must have been it. CSM drifted too far, LGC was in auto and wanted back to the original attitude [18:16:10] but RCS isn't on yet [18:16:12] So maybe I'll do SCS min before it [18:16:17] so lots of firing commands and no firings [18:16:20] Yeah [18:17:05] did you close the isol valves with the red flags? [18:17:10] or just left them red [18:17:30] I closed them reset the pgns switch and opened them again [18:17:43] ok [18:17:53] I think that is what would cause the 2004 alarm [18:18:02] Yeah U/V jets [18:18:08] not the red flags but switching a bunch of those quad switches to off [18:18:15] Yeah [18:18:57] SCS min db low rate? [18:20:17] not all the time, no [18:20:24] For this [18:20:45] well this is after the P22 [18:20:52] where it said stop pitch and go inertial [18:21:10] no other attitude instructions for the CSM until after the DAP is set in the LGC [18:21:33] Yeah [18:21:41] So I am in CMC hold at that point [18:21:46] I guess, yeah [18:21:52] at that point you switch to SCS [18:21:57] min/low [18:22:02] Right before the DAP [18:22:08] Or after [18:22:11] I cant tell haha [18:22:14] difficult to tell, yeah [18:22:23] Well I was in CMC hold before [18:22:25] doesn't make a difference really [18:22:29] And must have hit the db [18:22:36] oh [18:22:40] and with 5° DB? [18:22:55] Um let me check, it was the last DAP I got from MCC but I believe it was 5 [18:23:01] fromt he fp not MCC [18:23:04] yeah [18:23:06] about that [18:23:11] all the preflight documents have that [18:23:28] and in the transcript they changed it all to 0.5° DB [18:23:29] I am using the transcript one [18:23:37] Hm not for this I dont think [18:23:55] the flight plan changes for this start even before LOI-1 [18:24:07] wherever it has e.g. 21111 it was changed to 21101 [18:24:17] or 11112 to 11102 [18:25:50] I am trying to find where they read a change to this one up [18:26:02] yeah, looking for it as well [18:26:05] also this: [18:26:06] 098:38:03 Aldrin: Rog. In accordance with the - on page 47, step 1, we had the guidance control in PGNS and Mode Control, PGNS, Auto. And, of course, the circuit breakers are not in on the thrusters yet, so when we started through the DAP and proceeded on Noun 46 - and we're looking at Noun 47 now - why, we got an RCS TCA light, and we've got four out of the eight other bright-colored red flags. I think that this is explained by the fact [18:26:06] that we are in - PGNS and Auto and just unable to fire the thrusters. Over. [18:26:56] for example here: [18:26:59] Haha [18:27:04] 078:58:58 McCandless: On your DAP load, we would like in R1, 20101 vice the value which appears in the Flight Plan. [18:27:06] I just was about to paste that [18:27:18] The TCA light part [18:28:06] yeah [18:28:22] not sure about the DAP setting during LM activation actually [18:29:09] The only thing I can see is 11111 in R2 instead of 01111 [18:29:42] I thought I had seen multiple of these changes [18:29:44] was that 78h dap change for LOI? [18:30:29] No, LOI2 [18:30:33] I have that change made [18:31:32] I think I had seen one on a flown Apollo 11 flight plan page [18:31:37] have to find that again [18:32:55] Let me know [18:37:44] damn I get them even in SCS min db [18:38:06] Maybe I should change these LO DAP deadbands to 0.5 [18:39:09] Oh doh, BMAGS need to be in att1 rate 2 dont they [18:46:23] that's how SCS atitude hold works, yes [18:46:36] with Rate 2 it's just rate limiting [18:46:51] Yeah I know I was just pointing out I was stupid :P [18:47:09] In SCS min db it holds nicely for the LM dap [18:48:35] good [18:48:52] I guess the LGC just doesn't like drifting out of that deadband [18:48:58] in Auto [18:48:59] So I wonder why the gimbal drive test doesnt mention the cw light for engine gimbals [18:49:10] it doesn't? [18:49:13] werid [18:49:13] Nope [18:49:44] either a CWEA difference or an ommision [18:50:12] well lets see what apollo 15 says [18:50:21] 14* [18:51:27] Hmm the gimbal drive check seems to be omitted [18:51:28] Apollo 11 AOH Volume II does mention it [18:51:44] ah right, they didn't always do that [18:52:31] so the light definitely should be on and the checklist is just lazy for not mentioning it [18:52:32] yeah the 12 checklist mentions the des reg light [18:52:36] but not the gimbal light [18:53:00] procedures in the AOH mentions both [18:53:57] Well at least I know its "wired" correctly then [18:54:16] yeah [18:54:39] it's because the gimbals are driven into their stop during the procedure [18:55:02] Yep [18:55:20] the crudest possible method to get the gimbals into the desired position :D [18:55:32] Hey it's effective! [18:55:46] And doesnt pop the cb like the s bd steerable ;) [18:56:11] what causes that CB to pop? [18:56:17] Oh on the ream LM [18:56:19] real [18:56:34] when it hit a stop, the current would spike and cause the cb to open [18:56:41] oh, lol [18:56:45] I should implement that [18:56:54] I forgot where they had a lot of trouble with that [18:57:08] But yeah would be interesting especially with auto tracking [18:57:50] the current auto tracking code is very complex [18:57:56] //TBD: Auto Tracking [18:58:33] Thats WAY over my head... [18:59:00] I imagine it would be similar to the RR though right? [18:59:19] The signal based tracking? [18:59:29] the HGA would be similar I think [18:59:35] the steerable does a coning thing [18:59:47] conical scanning [18:59:56] I think [19:00:01] Yeah I would think they would be [19:00:22] Didn't 11's LM steerable have a bad "map" of where the LM was so it kept losing lock? [19:00:49] hadn't read that [19:01:03] not really sure how that best gets implement in code, I think conical scanning is very analogue [19:01:12] the circuitry etc. [19:02:07] I need to find it [19:03:04] Heres something off about the 12 activation [19:03:12] PGNS is still in auto while the CSM maneuvers [19:03:20] How does that work without setting off flags [19:06:35] DAP not on yet? [19:06:41] AGS mode? [19:06:57] This is after the DAP set [19:07:28] where is the maneuver in the checklist? [19:07:29] even the last step of the procedure is "give CSM go for mnvr to landmark track attitude" [19:07:41] ACT-38-39 [19:07:53] For the LM/DAP part [19:08:02] 12 activation checklist [19:10:22] hmm [19:10:59] even in SCS min db I am hitting the LM db [19:11:42] I don't remember that being a big problem [19:11:58] Nor do I [19:12:03] But I keep getting flags [19:12:17] something must be different [19:12:27] I am going to go back and run it again [19:12:39] in cmc min db hold I am find [19:12:40] fine [19:12:57] Maybe I have SCS configured wrong? [19:13:15] SC CONT SCS, ATT DB MIN RATE LOW BMAG 3 ATT1 RATE2 [19:13:24] jets on? [19:13:25] anything else I missed? [19:13:30] roll? [19:13:31] Yes [19:13:45] Gonna verify but I am 99% sure [19:13:55] does V76 any use in Auto? [19:13:56] Yep [19:14:04] have any* [19:14:13] Not that I am aware [19:14:22] Only HOLD [19:14:42] yeah [19:15:08] how do I zero the deadband in scs [19:16:22] to Rate 2 and back to Att 1/Rate 2 and the current attitude because the center of the deadband [19:16:30] becomes* [19:16:31] just finished tpi and mcc 1 and 2 [19:16:44] astronauthen96__, seen any Columbia yet? [19:16:51] i can see it on the HUD [19:16:53] not working thats what i tried [19:17:02] what do you mean not working [19:17:07] does it not hold attitude? [19:17:11] the needles [19:17:12] i think i am coming in a bit from the right [19:17:40] error needles [19:18:31] Are they not driven by the SCS [19:18:39] depends on the mode [19:19:01] FDAI2 should always be GDC driven I think [19:19:10] FDAI1 depends on the switch setting [19:19:26] and FDAI scale of course [19:19:47] but what about the attitude rate? [19:19:55] the LM should have 5° deadband [19:20:00] plenty for the SCS [19:20:22] I need to play with it more [19:20:42] check the LGC DAP again [19:20:50] have the SCS in min att hold [19:20:56] 32012 [19:20:57] cycle the PGNS switch [19:21:08] if the PGNS still tries to fire then I would be surprised [19:21:25] is the SCS actually holding attitude? [19:21:28] like, visually [19:21:31] not needles [19:21:59] I am running it again to see [19:22:21] SCS min db hold, looks like its holding [19:26:03] would you guys say this is close?https://www.dropbox.com/s/3fb8ed8dt3qvbmp/csm%20lm.png?dl=0 [19:26:20] the csm is a bit up to the right [19:26:52] will be even closer very soon, haha [19:27:28] its a bit above me now i have to figure out the docking attitudes [19:27:37] Hey hey NSFW! [19:28:13] Looking at Eagle's backside like that [19:28:40] yeah i guess that's kind of inappropriate [19:28:46] for work [19:29:41] rcflyinghokie, I wouldn't worry too much about red flags [19:29:47] I am not [19:29:48] you'll reset them anyway soon [19:29:54] Just making sure I am not screwing up [19:30:00] even the Apollo 12 checklist says they can be red [19:31:25] Ok [19:32:11] The maneuvering thing on 12 still is weird [19:32:20] well the LGC won't fight it [19:32:22] no RCS [19:32:27] just the flags being red [19:32:41] Yeah cycle CWEA as necessary, that explains that [19:33:03] the red flags are just an indication, nothing else happens when they become red [19:33:29] doesn't even disable the thrusters [19:33:47] that is only done manually by switching the thruster pairs off [19:41:15] Yeah switching to wide I'll get flags anyways oh well [19:42:33] your PGNS is more eager to do work than others it seems [19:43:31] She wants to land on the moon! [19:46:06] I thought the rcs flags clear when cwea is cycled? [19:47:33] Maybe I should still be in min db for this [19:48:07] sometimes they don't want to clear, yeah [19:48:22] might be that it is still trying to fire [19:48:30] It is [19:48:34] I'll have to look at that reset code again [19:48:35] because the db are maxed out [19:48:53] why do you want max DB so much, haha [19:49:04] I dont! [19:49:17] I just thought I am supposed to? [19:49:20] right, the checklist wants [19:49:44] maybe I am just not listening to the checklists all that much [19:49:45] Wellit says at request of the cdr... [19:49:47] sorry [19:49:51] so thats me right now [19:49:57] I say min db hold [19:50:16] So says the Czar of the ship [19:53:47] Also when the flags are red do they only clear by disabling first and then enabling? [19:54:31] yeah, or CWEA recycle [19:54:56] Which doesnt work [19:55:08] latching relay [19:55:18] well it does work, and then it immediately gets set again [19:55:25] cycle the PGNS mode switch again [19:56:07] Ah yeah the db [19:56:50] very difficult to dock [19:57:12] yeah, I find it more challening than TD&E as well [19:57:22] with TD&E you start at a defined point [19:57:35] i am just maneuvering all over the place with translation and rotation [19:57:39] and if you don't do too much thrusting in the wrong direction you stay near the S-IVB [19:57:52] and i don't know how to get the lem in the right attitude [19:58:07] isn't there a specific docking attitude for both CSM and LM? [19:58:20] i guess i can try that [19:58:29] but I also don't have much experience with that docking yet, haha [19:58:36] I've rarely flown a mission that far yet [19:58:47] 11? [19:59:29] LM Active docking is very challenging [19:59:45] There are docking attitudes, yes [20:00:57] would the flight plan attitudes work? [20:01:09] They should [20:01:34] but i am still off to the side with the braking phase [20:04:25] let the CSM take care of that [20:14:23] Ok RR test time [20:17:27] numbers are close to the checklist numbers :) [20:17:47] For the test monitor [20:19:15] Looks good [20:22:35] good to hear [20:23:07] I've tuned the test signal so that the signal strength meter gives about the right voltages [20:23:16] for the cycling shaft and trunnion error [20:25:34] Hi [20:25:58] Couple questions/comments about p23 on Apollo 11... [20:27:08] Should the w matrix be reinitialized I.e. to the values found in the apollo 12 flight plan before starting marks? [20:27:59] indy91 yeah they are within maybe .1-.2v of the checklist values which is great [20:28:44] lotisully86, sure [20:28:48] evening lotisully86 [20:28:50] Also I’ve found maneuvering to the attitudes in the flight transcript for Apollo 11 then using the procedure for auto optics first works far better than auto maneuver first [20:29:06] yep, same [20:29:25] the auto maneuver doesn't adjust it right for roll [20:29:30] one thing about the reinitialization [20:29:44] V67 only changes the initialitation parameters [20:29:56] V93 only resets a flag that the W-Matrix will be reinitialized [20:30:07] Right so auto optics first keeps you in the same general attitude [20:30:12] and the actual initialization doesn't happen until the first mark [20:30:43] and I believe the default state of the flag is such that the very first time you enter P23 it does a reinitialization anyway [20:30:52] with the padloaded init parameters [20:30:58] Ok [20:30:59] if you didn't change them that is [20:31:20] Artemis (Apollo 15 and later) does a 3-axis maneuver in P23 [20:31:26] or at least there is the option to [20:31:40] so that you would get 0° shaft angle [20:31:47] Right vec point and 3 axis [20:31:48] no, 180° I think [20:31:51] yeah [20:32:37] I’m just bringing this up because before just using auto maneuver I’d have trouble with the roll and having stars obscured by the lm [20:32:43] yeah [20:33:09] that's why 180° shaft angle, not 0° in Artemis. That always gives a view clear of the LM [20:33:29] mission control had a way to calculate the right angles [20:33:42] Manuvering to the flight plan attitude mentioned in the transcript and doing auto optics first, you are able to take sightings on all the stars [20:33:45] I have that partially already in the RTCC, will add it to the RTCC MFD soon [20:36:17] the attitude in the transcript, what shaft angle does that result in during the P23? [20:36:53] can not dock at all [20:37:16] I’m away from my pc right now at work but i will check later on tonight and let you know [20:38:01] but it worked better than just letting P23 do it [20:38:26] I just know it keeps you in the same general attitude for all stars, all stars are visible and all results are under 500 for r1 and r2 [20:38:42] Ya works way better way less rcs usage as well [20:40:47] Will check back in later about the shaft angles have to get to work [20:41:00] Cya [20:49:00] good night! [12:17:42] good morning [12:20:31] Morning [12:21:00] docking went good [12:21:19] had to give my self more sm rcs propellent but thats fine [12:21:43] i was so close to giving up [12:22:21] now i am 30 minutes till reentry [12:22:49] You need to practice! [12:23:06] You should be using the x pointers and the RR to help your LOS [12:23:41] Have the CM holding a fixed docking attitude, line the LM up facing the CM at like 50 feet, and pitch forward and line up the ovhd coas with the cm docking target [12:23:53] CM shouldnt have to use hardly any RCS [12:32:11] I have the 11 checklists right up to undocking finally [12:52:48] the problem with the docking was the translation [12:52:48] .tell Indy91 shaft angles are between 30000 and 05000 for the p23 auto optics first procedure [12:53:10] morning lotisully86 [12:53:30] Good morning how’s it going? [12:53:39] astronauthen96__ yeah the LM translation is challenging [12:53:51] Pretty good, just cleaning up Apollo 11's procedures slowly [12:53:54] i was about roughly 600 feet try to get the csm to line up with the lem [12:54:04] You mean LM to line up with the CM? [12:54:04] but as you get closer its easier for some reason [12:54:11] CM shouldnt be moving [12:54:21] Or rotating rather [12:54:29] doesn't the csm do the docking? [12:54:33] No [12:54:40] that is what i did [12:55:26] Oh is this for 11? [12:55:31] yes [12:55:39] Sorry, with you on 11 and Alex on 9 I am mixing them up [12:55:53] Yes 11 did CSM active docking I believe [12:56:57] yes [12:56:59] I need to verify that [12:57:05] But 9 did LM active [12:57:22] in 11 in the csm it says close distance and dock with lem [12:57:52] hey @lotisully86 [12:58:04] What’s up? [12:58:15] just flying apollo 11 30 minutes till reentry [12:58:29] i would say it was a great and fun mission [12:58:58] Nice I’ve never gotten much past lunar rendezvous [12:59:34] and @rcflyinghokie the docking attitudes from the flight plan worked just fine [12:59:52] Good, I have found they usually do [13:00:16] Flying 9 the last time and comparing the braking to the pictures taken on the actual mission, they looked identical [13:00:45] But I will admit I am looking forward to finishing 9 so I can go back into the LM ECS [13:00:49] finishing 11* [13:01:02] and mcc5 was 3.5 FPS and was the only course correction required [13:01:07] Great [13:01:12] Good TEI then [13:01:14] I think I’ve got the p23 figured out [13:01:21] Ah the dreaded P23 [13:01:24] I don’t think Collins ever did haha [13:01:44] I think you are right [13:01:56] i can't get the p23's right either i have no idea where the star and horizon should be in the sextant [13:02:37] They take a lot of practice/patience [13:02:43] Brb [13:03:06] kind of depressed that the mission is almost over [13:03:31] @lotisully86 so how far into 11 are you? [13:03:43] If you maneuver to the flight plan sighting attitude mentioned in the transcripts, enter on 202, auto optics, then verb 94, then auto optics and mark sequence, it will keep you in the same general attitude [13:03:47] For all stars [13:04:32] Also I believe star 40 was efh not enh [13:04:55] I’m on the first set of markings at 6 hours [13:05:01] very nice [13:05:37] Enh for star 40 puts the horizon below the terminator in darkness [13:05:57] well i am going to do reentry now i will be back in a bit [13:07:25] Good luck [13:11:00] .tell rcflyinghokie in the flight plan star 40 is listed as enh but the horizon number in parentheses is 120, so the letters may be a typo [13:38:55] .tell lotisully86, which mission? [16:42:48] hey @lotisully86 [16:43:22] .tell rcflyinghokie apollo 11 in the first group of sightings 6 hours into the flight plan/checklist [16:45:51] Hey [16:46:03] How did reentry go? [16:50:49] very well [18:17:15] good morning [18:21:15] hey [18:21:31] mission complete this morning [18:24:10] and you mcc feature worked great [18:24:24] good to hear [18:24:33] had to burn any midcourse corrections? [18:24:38] mcc5 [18:24:43] for me it was MCC-5 and 7, but 7 was on the edge [18:24:47] was 3.5 fps [18:24:57] good enough, haha [18:25:20] RRT was 195:01:29 [19:01:01] mine was 195:01:31, haha [19:01:43] not surprising that it is close, it's mostly a function of the desired reentry coordinates [19:01:49] but that it is that close is pretty fun [19:36:19] that is very interesting [19:36:37] and i was very close to giving up because of the lunar docking but i did it [19:38:27] yeah, it was challenging for me as well [19:38:31] need more practice [19:38:40] and a good timeline for attitudes to use [19:39:07] the docking attitudes from the flight plan worked perfectly [19:39:14] I guess what you could have done a bit better is the braking phase. You should be using translational movement to get exactly in front of the CSM. [19:39:24] that was the difficult part [19:39:27] that way you don't end up to the right of it [19:39:38] seemed that the closer you get the easier it is to line up with it [19:40:01] yeah, further away you don't see much effect from thrusting left or right [19:40:41] but just stick with the attitude you have after MCC-2 and do a bit of thrusting in the right direction and wait a minute or two for it to have an effect [19:42:26] aside from the difficult docking it was a great and fun mission overall [19:42:54] yeah, I also like about it that there isn't much idle time for a NASSP user [19:43:06] on the way back there is a bunch of it [19:43:12] but not in lunar orbit at all [19:43:49] and for sure no idle time for the astronauts either [19:43:55] haha, yeah [19:44:04] and barely sleep periods [19:44:14] Apollo 8 is similar with that [19:44:27] 20 hours in lunar orbit, fully packed with activities [19:44:47] especially between liftoff and tei [19:45:24] i bet that is why the sleep period comes just an hour after tei [19:45:25] oh yeah, get rid of the LM and then TEI just a few revs later [19:45:45] and it's a well deserved 10 hour one [19:46:50] just not sure which mission to fly next i am leaning towards 9 [19:47:37] if you are adventurous you could try mission for which we neither MCC or Checklist MFD support yet, haha [19:47:59] maybe 12 [19:48:29] i could probably reach lunar orbit but the lem stuff i am not sure about [19:48:47] yeah, maybe a mission like 9 with multiple LM activations is good practice first [20:42:25] good night! [12:56:27] hey [13:17:40] hey Alex [13:17:55] I'm working on the VHF Ranging system [13:23:36] oh nice [13:24:25] still working on some issues getting the right numbers into the CMC [13:25:26] for larger ranges it would overflow the positive numbers (beyond 37777) and it doesn't seem to get good numbers for that [13:25:47] largest 06 49 I have ever seen, hehe [13:25:53] lol [13:25:56] guess I need Mikes help for it [13:26:04] or maybe Thymo [13:26:23] maybe I need to invert all the bits or so [13:27:01] don't quite understand what the CMC code does with it, but it does have a check on the sign bit [13:27:24] and for the ranging I had to implement some basics VHF transceiver stuff [13:27:39] mostly just switching logic, so you will need the right switch settings in both CSM and LM [13:27:55] ah right [13:29:06] I loaded a post LM insertion scenario, if the ranging data is suddenly becoming good at exactly 163.83NM (37777 in octal) then I know it's working in general, just not for those larger ranges [13:32:50] right [13:34:28] I guess now all possible rendezvous scenarios, including CSM rescue are going to be possible [13:36:14] yeah [13:36:22] also one other weird thing [13:36:36] I have a few documents saying the max range for VHF Ranging is 200NM [13:36:54] but the Apollo 11 procedures want lock on right after LM insertion [13:36:58] nearly 300NM range [13:38:23] hmm weird indeed [13:38:56] maybe 200NM was for Apollo 10? [13:39:19] it could be an outdated number, sure [13:39:50] 160NM range and no 06 49 at all, so good marks [13:40:15] but it wasn't even pointing at the LM at first which is weird [13:40:18] good morning [13:40:26] I have to check if the MCC gave the CSM a bad LM state vector or so [13:40:26] hey [13:41:23] going to make some 11 videos then start 9 this morning [13:41:55] i think Ryan told me yesterday that for 9 its the lem that does the active docking is that correct? [13:43:07] yeah [13:43:33] i wonder why they switched it [13:43:49] maybe as a test to see if it can be done? [13:44:33] CSM active docking would have already been done during TD&E [13:44:46] LM Active Docking just was a test objective on Apollo 9 I guess [13:48:55] guess I'll test a CSM active rendezvous with just VFH marks [13:49:10] got 3 marks in before CSI, good enough [13:53:40] is the VHF ranging display on the EMS working too? [13:55:21] yeah [13:55:28] EMS code had some provisions for it already [13:55:43] just had to call a function in the new VHF Ranging code [13:55:47] and blank the decimal point [14:04:06] the EMS is a looking a bit weird then [14:04:20] but it seems to be consistent with schematics [14:04:27] it's displaying range in 0.01NM [14:04:31] so 1313 3 [14:04:35] is 131.33NM [14:04:59] it's not quite like that, but the missing decimal point is still s noticable gap [14:05:00] a* [14:11:56] but I guess the best sign for good marks is that it's not giving me any 06 49s [14:12:59] just have to check what was going on at the beginning there. Bad SV or range overflow [14:14:57] well if it was a bad SV, you probably would of got some 06 49s somewhere [14:18:22] I did get huge 06 49s at first [14:18:32] but I explained it away with the range scaling [14:18:43] but then I noticed it wasn't actually pointing the sextant at the LM [14:18:51] I rejected all 06 49s though [14:18:59] so I just have to check what really was the issue there [14:19:13] I then uplinked a LM state vector with the RTCC MFD and all was good [14:19:28] no 06 49 since. But that was at the same time as the critical range (163NM) was passed [14:19:35] so I don't actually know yet if that was the issue [14:24:53] oh [14:25:05] it looks like the CSM has a LM state vector [14:26:28] yep [14:26:29] MCC bug [14:26:32] easy fix [14:26:41] but now I wonder if I will even have a range issue [14:29:55] ok, waiting for 200NM again [14:35:47] acquisition, first good mark and no 06 49! [14:36:13] so it was just that the MCC accidentally uplink the LM state vector to the CSM slot [14:42:12] bad MCC [14:43:24] yeah, not my fault at all, all on the MCC :D [14:44:28] next step is finding a better acquisition range. It also could be that it has acquisition at a longer distance than it gets good data [14:48:25] AlexB_88, you were right about the Apollo 10 experience [14:48:34] they had acquisition at up to 320NM [14:48:49] and I guess for the next mission they then worked with that assumption [14:49:23] 320NM is a good number, using anything beyond 327NM would actually give a range overflow [15:00:09] Are you still getting the overflow you were speaking of earlier? [15:11:26] nope [15:11:37] wasn't an overflow after all, just a wrong state vector [15:12:05] the 06 49 were errors so huge that I thought it was an overflow [15:13:44] so the only issue left is the CSM/LM communication. I can make that a bit more elegant I think. [15:13:56] Then the VHF Ranging would already be ready for some further tests [15:14:18] tests by other people I mean [15:18:53] and then finally I'll try some CSM rescue cases, hehe [15:19:00] I'll be back later [16:32:12] Greetings from the beach :) [16:32:42] Hmm I have to look at that [16:34:11] hey [16:34:44] Finally got 11 to undocking that took more adjustment than I expected [16:34:50] careful with the sun at the beach, do you want me to calculate some PTC angles for you? [16:34:51] But it flows well now [16:35:07] Haha yes I need an accurate BBQ roll [16:35:53] I got the VHF Ranging System working today [16:36:15] Oh very good [16:36:26] last major system we needed I guess [16:36:38] We have to be more aware of comm settings now I imagine? [16:36:44] yep [16:36:49] in both CSM and LM [16:37:26] tests are good, just the CSM/LM interaction needs a bit more work [16:37:37] Yeah I'll need to go back and work on those I imagine [16:37:59] CMC interface is the same as in the LM, so that part was easy [16:38:23] so even the CMC would theoretically support up to 8 radar measurements [16:38:52] I'm going to switch to IRC on the laptop, stand by [16:39:18] So during VHF ranging ops, does the sextant have to be used as well? [16:39:54] And we have AOS from the balcony [16:39:55] Is it required to do sextant marks, or is the VHF ranging marks alone good enough to keep the SV good? [16:40:02] hey Ryan [16:40:22] I think VHF marks alone work, if I am not mistaken [16:40:23] good question [16:40:29] I think it's the perfect combination really [16:40:33] range is one dimensional [16:40:44] sextant gives an exact direction of the LM [16:41:03] so most of the times in the checklist you are doing both at the same time it seems [16:41:11] larger ranges VHF ranging only [16:41:45] I guess in theory VHF marks alone could be ok, but it will take longer to converge in all 3 axis [16:41:53] True [16:42:08] depends on the initial errors [16:45:31] Huh lotisully86 was right, the FP does have a typo with the P23 at 6h [16:45:52] Has R3 as 120 when it clearly is ENH [16:47:37] the reformatted one has [16:47:39] I remember that [16:47:44] indy91, not to put any pressure to commit the VHF ranging stuff but we're sitting at 6066 commits right now... Some people would say that is bad luck :D [16:47:49] that's when I started 100% trusting it, haha [16:47:58] in the actual one that P23 data is correct [16:48:14] stopped* [16:49:24] Yeah I just cross referenced it :) [16:49:43] the commit is possibly ready today, yes [16:50:27] Now with that, a few questions: [16:50:39] Will the RR self test give the systems test meter indications? [16:50:55] XPDR self test [16:51:05] And Will the XPDR need to face the LM now for the LM RR to lock [16:52:21] indy91: You pinged me earlier? [16:56:06] rcflyinghokie, haven't implemented the RR transponder yet [16:56:28] Thymo, thought I needed some help reading AGC code, but it turned out to be a different problem [16:56:36] Ah ok just the VHF ranging then [16:56:58] Different systems, thats right [16:57:12] Okay! [16:57:24] morning! [16:58:15] Good afternoon [17:01:10] Hey Mike [17:01:15] Btw Mike, just read this: https://www.livingspace.earth/home/2018/8/for-future-generations [17:01:22] :D [17:01:32] Very nice [17:03:43] I'd love to see this in person cometime [17:03:45] sometime [17:04:53] we're still trying to figure out where exactly it's going to be for the 50th but I'll keep you posted [17:06:26] hey Mike [17:06:49] If I am stateside I am making that trip for sure [17:07:07] Hell even if I am in AK I will [17:07:11] hahaha [17:07:24] Worth it [17:08:33] nice article! [17:08:59] Man there is a C150/152 towing banners here at the beach, flaps close to full high AoA its freaking me out he MUST be hugging Vso [17:09:01] why not Luminary099? Because we couldn't be able to agree on which version to use? :D [17:09:36] wouldn't* [17:09:42] hahaha, it will be Luminary 99 (rev 1 of course) for the event, almost certainly [17:09:53] Aurora will be the first thing we run on it, though, for diagnostics :) [17:10:11] oh yeah, makes the most sense [17:10:22] if you need a padload let me know, haha [17:10:48] oh yeah, we will definitely need your help putting together a demonstration that shows it doing more than just passing self-tests, lol [17:11:00] should certainly be possible [17:11:12] I've run P63 in the standalone Virtual AGC through ignition [17:11:24] Am I sensing an NASSP dev meetup? ;) [17:12:47] if you fly me in [17:13:02] lol [17:13:05] That would be pretty unique to do for sure [17:13:13] thewonderidiot, I gave the RNRAD register in the CMC something to do today [17:13:20] oh? [17:13:24] awesome [17:13:26] VHF Ranging [17:13:59] Does the AOH have CSM and LM configurations for ranging? [17:14:09] I imagine it does [17:14:11] yeah [17:14:16] I need to brush up :) [17:14:46] it goes: CSM VHF B transmitter -> LM VHF B receiver -> LM VHF A transmitter -> CSM VHF A receiver [17:15:00] so in the CSM always Duplex B [17:15:33] and in the LM voice/range on transmitter A, and receiver B on [17:18:33] Now what about S BD range? [17:18:47] How does that play in [17:18:59] as it's S-Band, it doesn't I think [17:19:10] So what is the range selection for? [17:19:20] I think MSFN ranging [17:19:27] Ah that makes sense [17:20:08] I need to study up on comm systems anyways [17:20:39] SBD was MSFN contach and VHF was ship to ship primarily right? [17:20:43] contact* [17:21:24] yeah [17:21:39] close to Earth you could use VHF for communication with MSFN [17:21:58] Right [17:22:12] but there are a lot of comm modes [17:22:24] like LM talking to MSFN via the CSM [17:22:28] Yeah a lot of configurations [17:22:33] LM to CSM on VHF, and then S-Band [17:22:47] or even LM PCM telemetry via the CSM [17:22:53] that's what VHF B Data is for [17:22:58] low bitrate [17:23:12] low bitrate only* [17:23:34] VHF A and B, just different frequencies? [17:23:45] pretty much [17:24:10] and redundant systems [17:24:31] I have only dug as deep as I needed for the VHF Ranging really [17:24:54] part of the update will be a bit of VHF switching logic in CSM and LM [17:25:08] but not much more [17:25:19] just beginnings of those VHF systems [17:25:29] I'll need to know what procedures need to be implemented [17:25:49] probably not much [17:26:02] some testing after undocking [17:26:20] but the ascent and rendezvous is LM active checklist-wise anyway [17:26:34] LM has the right switch settings already [17:27:28] Ok [17:27:56] I'll try to pop on later [17:34:10] thewonderidiot, the CMC radar interface is remarkably similar to the LM [17:34:19] I basically copy&pasted the code I had in the RR [17:34:42] haha oh really? that's not too surprising, I guess :D [17:35:14] smae output bits etc. [17:35:51] yep [17:36:21] just less options for selecting what measurement to sample :) [18:04:12] 1 out of 8 options used [18:04:19] in the CSM [18:04:44] in the LM it's 6/8 I think [18:04:59] LR range, LR X, Y, Z velocities, RR range, RR range rate [18:05:49] 7 options [18:05:55] 000 wouldn't do anything [18:14:32] 011 also wouldn't do anything [18:14:50] or rather, they both would probably generate strange signals to the RR and screw it up [18:14:56] :P [18:26:42] and in the CMC? [18:27:28] or is 011 just the "spare" signal in the LGC and only does weird things because wiring? [18:36:20] the leading 0 means to the hardware that the RR is being talked to [18:36:37] but 11 and 00 for the other two bits don't have any meaning, so some signals will do stuff but not all [18:37:24] 000, 010, and 011 probably would do similarly weird things to the VHF [18:39:41] ah, the first bit is slightly different from the other two, I understand [18:40:49] well luckily the software is smart [19:10:42] ok, let's give this VHF ranging another test [19:10:50] rescue case no. 1 [19:10:52] partial DOI [19:13:03] and CSM only gets the DOI burn via P76, so it's not perfect SVs all the way [19:19:29] yeah [19:20:35] I think in Apollo 9 the LM did the whole rendezvous with a CSM SV that was P76'd after it did the sep burn. Worked pretty well anyway [19:22:42] yeah, often that leads to TPI slipping all the time in one direction [19:22:54] I think the actual Apollo 9 mission had that as well, a little bit [19:32:11] who coded the Docking Initiation Processor again? [19:32:23] and who couldn't properly use it right now? [19:32:29] yeah, both me... [19:46:45] it was a good P76, but I can still see the LM getting closer to the center of the sextant with VHF marks [19:53:28] Maybe I can show you how the DKI works ;) [19:53:54] you can show me the high dwell orbit targeting works by testing it, haha [19:54:18] thewonderidiot, thewonderidiot, https://www.ibiblio.org/apollo/listings/Comanche055/P20-P25.agc.html [19:54:31] is something done with VEHUPFLG at the beginning there? [19:56:31] you mean at 37,2270? [19:57:06] yeah [19:57:14] is it always reset there? [19:57:20] at the start of P20 [19:57:21] yeah, looks like it [19:57:29] ok, wasn't sure if that's always the case [19:57:43] always updates the LM state vector when P20 is selected, and not the CSM one [19:57:47] thanks! [20:21:53] AlexB_88, VHF ranging update pushed [20:22:04] great! [20:23:19] takes about 13 seconds for data to appear on the EMS [20:23:33] and up to a minute until the tracker light on the DSKY goes out [20:24:44] Is there a particular scenario thats best for testing it? [20:25:36] hmm [20:25:53] after LM insertion for example [20:26:07] or after DOI or so [20:26:40] or do a direct lunar ascent and the TPI with the CSM [20:26:44] then* [20:31:02] and don't forget to use the reset switch when you have enabled ranging [20:31:10] panel 9 [20:34:26] so V87 is what enables ranging? [20:38:27] yeah, VHF marks [20:38:33] V88 disables it [20:39:37] hmm cant get it working yet [20:39:56] any switch positions needed in the LM? [20:40:32] yeah [20:40:55] VHA A to voice/range [20:40:59] and VHF B receiver on [20:41:22] in CSM VHF A Off, VHF B to Duplex [20:42:01] yep that did it! [20:42:50] and don't talk during acquisition, haha [20:42:58] no, that's not considered yet [20:43:29] although the AOH suggests to switch off VHF A voice for CDR and LMP during that time [20:44:59] now for some reason P20 with optics mode CMC does not find the LM tracker light [20:46:18] what scenario did you use? [20:46:32] does the CMC have good SVs for both vehicles? [20:46:40] yep I just updated them [20:46:42] also, the tracker light might be pointing away [20:47:57] you could look with the vehicle marker or Docking MFD HUD [20:49:21] ok no it is pointing at it [20:49:46] its just that the track light is not yet visible, I guess that same issue we had before [20:49:56] yeah [20:50:06] I am using a pre-CSI scenario, the LM is about 150 NM away [20:51:22] but I think the documentation says the light should be visible up to 400 NM [20:51:55] yeah, didn't you adjust some settings for that? [20:52:04] do you have the tracker on in the LM? :D [20:52:08] tracker light* [20:52:31] I just did the rescue-2 burn, can see the tracker light through the sextant still [20:52:41] yeah I do [20:52:51] but I am never that far away from the LM anyway during this procedure [20:53:29] I know it was an issue before, I think it appears somewhere near 100 NM and less [20:57:41] first bug found [20:58:00] if VHF ranging is unpowered, it doesn't reset the data good input bit [21:11:29] so when exactly do I hit the VHF RNG - RESET? After doing V87? [21:13:28] doesn't really matter I think [21:13:49] if you had the VHF ranging unpowered, aka switch down, then you need a reset to start the ranging again [21:14:22] AOH suggests it to do after the tracking light is already on [21:14:28] so after the V87, yeah [21:20:37] well have fun trying it some more, I'll continue flying this CSM rescue case tomorrow. Good night! [21:20:49] cya! [12:48:20] morning [12:54:48] hey [12:56:09] flying a bit more of this rescue case, the only thing I was missing from the RTCC MFD is the additional CSI times [12:56:32] the checklist says "P32, compute CSI Two TIGN" [12:56:35] whatever that means [12:57:19] maybe the DKI should display further CSI times whenever CSI and CDH are more than 1 half-rev apart [13:15:56] How did you initiate the rescue case? Purposely launch early or late? [13:18:30] I did the partial DOI burn first [13:18:39] first rescue case in the list [13:18:46] DOI less than 25 ft/s burned [13:18:55] I did about the same as the chart in the rendezvous procedures, 20 ft/s [13:19:05] and the sequence is then a Rescue-2 [13:19:14] TIG 1 rev after DOI [13:19:26] then half a rev later CSI-1 with N=2 [13:19:47] so at the midpoint between CSI-1 and CDH is a nominally 0 ft/s CSI-2 [13:20:57] and getting the CSI-2 TIG was a little tricky [13:21:11] so I was wondering what the best way for that would be [13:22:53] the page with the timline says "COMPUTE CSI TWO TIGN", but I'm not sure what that means. Computer it onboard somehow, get the TIG from MCC-H or something [13:23:12] I guess you could place it directly at perilune in theory [13:23:20] that could be calculated onboard with V82 [13:27:21] with V82? [13:28:04] R3 shows time until periapsis [13:28:32] ah wait [13:28:33] I thought it was time of free-fall [13:28:37] yeah [13:28:39] you are right [13:28:46] 35k feet or so in lunar orbit [13:30:08] you could use it I guess, but you'd get a nasty jolt at your "CSI TIG" :p [13:30:39] not sure when that was added, but you can use V82 [13:30:45] and then use N32E [13:30:51] N32 is time from periapsis [13:30:56] ah right [13:32:12] yeah, that's already a thing in Comanche055 [13:34:02] but I guess it wouldn't be so difficult for mission control to supply the times for the up to 4 CSIs [13:42:13] <40 No PDI2 +12 has 4 CSIs, haha [13:42:20] you could also call it: No No PDI [13:56:08] good morning [13:56:15] about to launch apollo 8 [13:56:17] 9 [13:56:27] looking forward to a great mission [13:57:50] Hey Ryan [13:58:10] I think quadrant A got a little too much sun, Houston, I think we need PTC angles [13:58:17] Good morning [14:00:52] hey guys [14:01:22] Hey [14:03:02] hey Niklas [14:17:07] sunburn, Ryan? ;) [14:20:45] Thankfully nothing bad [14:20:52] Just a pink forehead [14:21:13] Just gotta be careful the nest few days haha [14:44:22] coming up to the CDH burn with this CSM rescue case. Doing sextant and VHF mark together works pretty well. [14:44:28] marks* [14:50:50] Very good [14:51:15] Hmm I cannot seem to reset the AGS attitude hold [14:51:23] I am undocking in AGS pulse att hold [14:51:34] And I switch P&R to mode control and it maneuvers [14:55:30] are you in AGS auto? [14:56:03] so, it should be resetting the att hold attitude whenever the ACA is moved out of detent [14:56:13] in AGS att hold that is [14:57:01] So I need to move out of detent before switching the mode controls switches? [14:57:44] While in att hold [14:57:59] that's one thing that would reset it, yeah [14:58:15] probably also switching to PGNS guidance or AGS to off [14:58:16] I just dont remember this being an issue before [14:58:27] Off and then back to att hold? [14:58:44] Because that didnt work [14:59:58] your RCS is really eager to work on this mission it seems [15:00:07] I know, right? [15:01:19] is undocking itself in pulse mode? [15:02:02] Yes [15:02:19] Then the yaw 360 is in P&R mode cont [15:02:28] AgGS [15:02:30] AGS [15:02:36] and if you switch mode control it is not holding attitude but changing to a different one? [15:02:42] switch to* [15:04:28] Yeah it rolls and pitches [15:04:37] Only like 10 degrees in each direction [15:05:17] https://www.dropbox.com/s/wndk0w553b1deu8/Apollo%2011%20MCC%20-%20Undocking.scn?dl=0 [15:05:28] Undock and give it a whirl [15:07:22] I will [15:07:33] FP6 Operating Manual PDF page 44 [15:07:37] Follow Up Discrete [15:07:43] that explains how it works [15:09:10] CSM must have maneuvered since the last time you switch the guidance config in the LM around [15:09:18] switched* [15:10:56] Oh the PGNS AGS switch? [15:11:54] yeah [15:12:05] switching to PGNS and back to AGS alone will fix your issue I guess [15:12:17] Ok [15:12:30] So I might have to work the timing so that is done before the last CSM maneuver [15:12:46] And that makes sense I was playing with it I am in the AGS CAL attitude [15:12:54] Thats where ATT HOLD is putting me [15:13:05] And that was my last attitude before sep of course [15:15:01] ah, yeah [15:15:36] RCS checkout is before AGS CAL [15:15:49] and the CSM would maneuver to that original attitude again [15:16:06] Yeah [15:16:48] And I see nowhere does it say go to PGNS and back to AGS [15:17:10] annoying that it does that [15:17:22] but I think it's all the AEA doing it, not the ATCA [15:17:39] Yeah [15:17:45] hmm [15:18:33] even in max deadband [15:18:37] I see nowhere between ags cal (which is in AGS pulse mode) and undocking where the switch is cycled nor do I see any ACA instructions [15:18:48] but I guess it's like 12.5° off from what it wants in all axis [15:18:58] Yeah it was 14 deg yaw for the CM [15:19:19] So its compensating in P and R to make that angle [15:19:28] no need to cycle anything if the AEA has the attitude from before AGS CAL remembered [15:19:33] which is the same as undocking [15:19:59] AGS cal attitude is not the same as undocking [15:20:08] I know [15:20:18] the attitude before AGS CAL is the same as undocking [15:20:37] and if you don't play around with any switches during AGS CAL, then the AEA will have remember that attitude from before AGS CAL [15:20:49] so at undocking it is where it remembers for att hold [15:22:05] Hmmm good point [15:22:13] Let me see what the order is [15:22:36] you said you played around with it while you were in the AGS CAL attitude [15:23:33] No I said the last attitude I was in was AGS CAL [15:23:43] I don't remember touching it then but I am looking to make sure [15:24:20] or the CSM drifted too much [15:25:01] I dont have any earlier saves on my laptop but I will go back and see what I messed up [15:25:30] I will check and see when I flipped the control switches and in what order [15:25:44] But for now, off to the water, take it easy [15:28:09] .tell rcflyinghokie CSM attitude where the LM maneuvers to while docked is +6.8°, +11.67°, +10.59° roughly [16:47:13] morning! [16:49:17] hey [16:49:32] question for you [16:49:42] do you know anything about the release history of Skylark? [16:49:59] was there a release before 48, that may have been made but then updated to 48 before flight? [16:50:21] release as in, made its way to a rope? [16:50:26] yep [16:50:44] alternatively, did that happen for Artemis 072 or Luminary 210 [16:50:45] I know of documents for tests of an earlier revision [16:51:11] hmm, how much earlier? [16:51:34] le tme try to find it [16:51:58] and about Artemis, the padloads from the CSM Data Book have a different nomenclature for Apollo 15-17 [16:52:22] and it's called Artemis072 revision 1 or so for Apollo 17 or something like that [16:52:33] reeeaaallly [16:53:34] we were talking about that when we got the Data Book [16:53:39] hmm [16:53:43] we were still quite sure it's all the same for Apollo 15-17 [16:53:48] but we weren't 100% sure [16:54:20] "Phase 2 verification of the CSM RCS Docked DAP, Skylark 041 with forced firing" [16:54:32] from that JSC Index document [16:54:36] hmmmm [16:54:42] JSC Document Index [16:54:46] doesn't really prove much [16:54:48] haha right [16:54:50] just that it was tested [16:55:11] and revision 46 universal tracking tests [16:55:19] "Verification of" [16:55:34] and same for Skylark 042 [16:56:11] "Program notes for Skylam CMC flight program Skylark 48 (REV. 2)", from 07-28-73 [16:56:16] Skylab* [16:56:27] ooooooh [16:56:32] rev 2 of skylark 48, very interesting [16:56:47] there's no reason for them to have done that unless they had already manufactured skylark 48 [16:56:48] :D [16:56:54] also interesting is that there is a separate document for ASTP [16:57:04] oh? [16:57:13] "Program notes for ASTP CMC Flight Program Skylark 48", from 04-28-75 [16:57:23] huh, weird [16:57:24] why would there be separate program notes [16:57:39] good question [17:10:59] the other thing I need to do today is send an email out to the AGC developer list [17:11:23] now that the plan with Jimmie's AGC is more or less public, I'm going to tell all of them about it [17:11:35] and ask if anybody has any documentation or hardware that might be helpful [17:11:54] makes sense [17:14:22] This new VHF ranging I implemented was also quite extensively used during the Skylab/ASTP missions [17:14:46] just finishing my first full rendezvous with it [17:14:47] nice, how's that working? [17:14:52] oh sweet [17:14:58] better than my sextant marks, lol [17:15:06] but ideally you want both [17:15:16] VHF ranging for the range and sextant marks for the direction [17:15:19] perfect combination [17:15:54] I did the first of 18 rescue cases that the CMPs (on Apollo 11 and 12) had documentation for [17:16:01] partially burned DOI [17:16:29] at that point the LM is still so close [17:16:42] yet you have to do this multiple hour procedure to get back to it [17:18:33] heh [17:18:37] Skylark has a Contingency VHF Range Rate Program (P25), which I guess samples the range data to generate range rate, or so [17:19:25] also unique in the CMC, Artemis doesn't have that yet, but the LGC has a P25 also, so it's not properly unique [17:21:10] back to your original question about Skylark releases, I'll look a little bit more if I find anything [17:24:58] thanks! [17:30:01] GSOP revisions can be deceiving [17:31:28] indeed [17:31:48] I'm going to go ahead and request the skylark major modes document and the padloads [17:31:51] I guess the SCB Meeting Notes aren't reaching far enough [17:31:55] sure [17:32:01] oh I didn't think about those [17:32:03] but yeah, probably not [17:32:13] last one is January 71 [17:32:33] Skylark is definitely being worked on there, but that's too early [17:33:05] was your question more about revisions before the first flight of Skylark? [17:33:12] or also e.g. Skylab-2 vs. ASTP [17:33:40] I guess in general if there were multiple releases of it [17:35:53] yeah, in general [17:36:05] although if different versions flew that's even more interesting [17:36:25] same with Artemis, I don't think that is the case [17:36:29] but there is a chance [17:36:35] yeah I didn't think so either [17:37:17] Hey Mike [17:37:34] just had yet another successful apollo 11 mission [17:41:50] hey [17:45:12] okay, so they have the user's guide to major modes, the skylark 48 verification plan, and four documents about padloads for various missions [17:47:41] sounds good [17:50:33] alright, all requested [17:53:44] oh wow [17:53:55] I forgot we had the Programmed Guidance Equations document for Skylark [17:59:45] also I realized last night that the interface modules in the AGC are going to be a fantastic indicator of capacitor health [18:01:46] with modules A25 through A29, there's a whole 89 solid tantalum capacitors that are effectively just placed between two pins, and can be fully tested without cutting any wires [18:01:53] that's a pretty good sample size :D [18:02:01] haha, yeah [18:02:36] ah capacitators, always the weakness in old equipment [18:02:48] had one explode in a TV receiver [18:02:50] crapacitors, as my EE teacher used to call them [18:02:54] broke a whole lot more than only itself [18:02:58] yep [18:03:23] they will do that [18:03:24] jerks [18:34:41] thewonderidiot, one thing a Skylark padload will do for me immediately [18:35:01] I implemented all the rendezvous calculations from the GSOP in the RTCC MFD with some extra features to fly Skylab rendezvous profiles [18:35:14] but one convergence limit is unusually part of the padload [18:35:32] mostly that stuff is just a fixed constant somewhere [18:35:44] I had to guess that number on my own [18:35:57] will be interesting to see if I guessed close to it [19:17:15] LM has been rescued [19:17:24] 1/18 rescue cases done :D [19:36:40] nice :D [19:36:47] to both! [19:37:16] I just sent out a big email to the AGC developer mailing list :) [19:43:10] haha, will be interesting what they say [19:52:31] afternoon [19:54:29] welcome back [19:54:39] I see some VHF fixes to test [19:55:42] just some minor things [19:56:08] the thing I talked about yesterday where it doesn't reset the data good bit when you switch VHF ranging off [19:56:33] and it didn't reset the range to 0 when I approached the LM and lost lock at the minimum distance of 500 feet [19:56:41] those two things were fixed [19:57:52] I finished my first rescue case [19:57:59] most marks by the VHF ranging [20:00:43] nice [20:01:06] I wonder if we can fix the issue with the track light not displaying from certain distances [20:01:42] Could you see it during the whole rescue scanrio? [20:01:48] scenario* [20:01:51] yes [20:02:09] my max distance was about 125NM [20:02:29] will be double of that for the next rescue case [20:02:43] so I guess I'll see if I can see it if sextant marks are desired [20:03:29] when sextant marks* [20:03:54] I know at 150 NM away you cannot see it [20:05:47] can't say for sure I saw it at the max distance [20:06:02] but certainly whenever the procedures called for sextant marks [20:14:20] Hmm cannot see it from 120 NM [20:24:31] also, does the tracker switch on the CSM optics panel do anything? It has some weird debug lines that appear when playing with it [20:25:42] that's for the never installed star tracker [20:25:51] I think that's where the optics zero switch should be? [20:26:31] no [20:26:52] optics zero switch is where our general optics (CMC, Manual, Zero) switch is [20:27:20] Mode Switch (CMC vs. Manual) in the actual Block II CSM is where our tracker switch is [20:32:02] night! [11:29:32] good morning [11:29:42] about to do some docking with apollo 9 [11:31:13] guess i can say i am committed to this mission [11:32:24] hey [11:32:29] yeah, sounds like it :D [12:19:33] the docking angles in the mfd are totally wrong [12:21:31] what are they in the MFD? [12:23:28] 121 274 345 [12:24:12] basically the same as the flight plan [12:24:30] I know that the angles can be a few degrees off from my Apollo 9 flight [12:24:43] it's the S-IVBs fault, but I am not quite sure why [12:57:03] cya later [16:50:45] morning! [16:58:49] hey [16:59:00] what's up? [17:04:03] just working my way through Apollo 9, coming up on Day 7 [17:18:32] hmm [17:18:47] do you have any guesses as to when LM-10 would have been built? [17:19:02] I don't know what the LM construction timeline was [17:26:34] hmm god question [17:26:39] good* [17:26:44] good evening [17:26:54] hey Niklas [17:27:19] hey [17:33:45] the first document there is the most interesting to you, I think [17:34:05] thanks! [17:34:14] I want to know how close you got :D [17:34:34] I probably chose a very small number for the threshold, haha [17:34:41] to make it nice and accurate [17:34:59] more than necessary [17:35:06] let's see what I used... [17:36:18] there are two variables actually [17:36:20] EPS1 and EPS23 [17:36:22] EPS2* [17:36:41] both just threshold for accurate an iteration has to be to end [17:36:47] for how* [17:38:10] both used in the rendezvous targeting for the NC1 and NC2 maneuvers [17:38:50] EPS is an angle [17:38:57] I used 0.000001 radians [17:39:02] EPS1* [17:39:04] likely over the top [17:39:13] and I used 0.01 meters for a height difference iteration [17:39:15] now the padload [17:39:57] EPS1 is 0.0025° [17:40:31] so they used 0.0000436 radians [17:40:40] I used 0.000001 [17:40:50] way too accurate, as I said :D [17:41:26] if I see this right they used 1000 feet for the height difference [17:41:36] which is much larger than I expected [17:41:43] and again, I chose a very small number [17:41:53] 0.01 meters [17:42:04] but the difference is probably not much more than 1 or 2 iterations [17:42:14] indy91, did you see this? https://www.orbiter-forum.com/showthread.php?t=39875 [17:42:20] yes [17:42:42] sounds interesting, but I haven't looked yet how to use it [17:42:50] thewonderidiot, so I wasn't very close, haha [17:43:12] but then they had to consider accuracy vs. computational speed in the AGC [17:43:18] hahaha [17:43:20] right, yeah [17:43:22] no penalty for me to make it super accurate [17:43:49] guess I can work out how to create Skylark padloads with this [17:43:57] especially interesting is LMATRIX [17:44:10] Skylark used the same coordinate system as the Space Shuttle computer [17:44:27] M50 or B1950.0 or something like that [17:44:37] so not the annoying yearly coordinate system change [17:44:56] one disadvantage for this is that you need a whole matrix to convert to planetary coordinates [17:45:14] Apollo AGCs only needed small correction angles where a small angle approximation was enough [17:45:35] and if we ever want to launch Skylark for any given day I need to figure out how to calculate that matrix [17:45:53] huh, interesting [17:46:06] that's exciting [17:46:25] hopefully there's another example coming [17:46:26] I had begun some MATLAB scripts for the math to calculate it [17:46:33] when we got the GSOPs [17:46:34] Lauren said something interesting in her email: [17:46:43] but now I have a reference [17:46:56] "All of the documents except for the two from Skylab box 559 have been uploaded to the following Dropbox folder... That Skylab box is part of a set that was sent to JSC for scanning and I don’t have an estimated return date – if you foresee needing those documents sooner than later, I can put in a request to retrieve them." [17:49:17] so there is more [17:49:24] a couple more padload-related things, yeah [17:49:58] KSC ( NASA KENNEDY SPACE CENTER ) SUPPLIED DATA FOR CMC ( COMMAND MODULE COMPUTER ) E ( ERASABLE ) MEMORY LOADS FOR SKYLAB III [17:49:59] and [17:50:09] KSC ( NASA KENNEDY SPACE CENTER ) SUPPLIED DATA FOR CMC ( COMMAND MODULE COMPUTER ) E ( ERASABLE ) MEMORY LOADS [17:50:52] dated july 3, 1973 and march 28, 1973, respectively [17:51:10] those might not be actual padloads, but data used in their creation [17:57:24] right [17:57:36] this ASTP one alone should already answer most of the questions [17:57:40] :D [17:57:43] the usual difficulties are scaling [17:57:53] some obscure DAP settings not mentioned in GSOPs [17:57:58] now we just need to actually find Skylark [17:58:03] haha [17:58:09] true [17:59:18] fun, no common EMEM addresses with previous versions [17:59:34] so annoying to ever support in the RTCC MFD [18:00:42] ASTP padload is for the right launch day [18:00:53] wow, not a single one? [18:00:54] that's impressive [18:01:26] well I haven't check every single one, but the ones that are very common are different [18:01:28] like TEPHEM [18:01:48] always in the same location for all manned missions, all CMC and LGC versions [18:02:22] not in Skylark [18:03:41] yeah, there are those obscure DAP padloads we could hardly derive on our own [18:03:58] mostly Docked DAP settings which is completely new in Skylark [18:06:00] took only about 10 years to get to the point that Colossus 249 could be used for docked burns [18:08:20] having this the padload in this format is really the ideal case [18:08:23] -this [18:08:31] for us I mean [18:09:13] has engineering values, scaling and octals [18:09:28] that's why the CSM Data Books were so great to have [18:11:45] :D [18:20:36] I also noticed you created a Luminary 130 version [18:20:40] why? :D [18:22:27] and what could the unfixed bug do? [18:22:36] just a wrong indication on telemetry? [18:22:50] I don't understand this "self-relative branch" thing in the Luminary memo [18:25:17] hahaha [18:25:32] well, I was originally thinking certain ropes might be Luminary 116 [18:25:46] or possibly partly Luminary 130 [18:26:07] so I wanted to know the difference between 116 and 130, and for that I needed to know the difference between 130 and 131 [18:26:26] and when I learned that it was such a simple difference, there was no reason not to fully recreate 130 :D [18:27:01] so the problem was that length of the jump was hard-coded [18:27:12] always +3, in Luminary 130 and earlier [18:27:35] but sometime between 116 and 130, an extra instruction was inserted between the branch, and the place it was branching to [18:27:49] which meant that the +3 was now jumping to the wrong place [18:27:51] to set the flag in telemetry [18:27:55] yeah [18:28:05] jumping to the wrong place sounds potentially really bad [18:28:07] so they fixed that by giving the destination a label and explicitly branching to that label [18:28:20] yeah, definitely [18:28:27] P70 breaking maybe? [18:28:31] very possibly [18:28:31] I could try a landing with it [18:28:36] and then abort [18:28:59] first I want to check when PCR 893 was done [18:29:55] it might actually be jumping to data instead of code [18:30:02] which would be super bad [18:30:12] I don't know how the interpreter works well enough [18:30:22] sounds fun [18:30:45] would it be possible to use a Luminary 131 scenario and swap out the binary? [18:30:49] or is there an issue with that [18:30:56] yeah... I'm like 80% sure that it's going to try to execute ABTTGFLG as an interpreter instruction [18:31:01] lol [18:31:02] no, no problem at all [18:31:13] sounds like a fun thing to try [18:31:14] 130 is only a single word different from 131 [18:31:18] let me make you a binary [18:31:28] great [18:31:37] looks through old scenarios. [18:31:56] yeah, as usual I have an Apollo 13 one from Alex [18:32:11] he doesn't, he always deletes them, haha [18:32:41] https://drive.google.com/open?id=1IWFhOVOuU7Ej_16McCnVwkwbVKyd928q [18:33:04] awesome [18:34:09] I'll just press the abort button a few minutes into the descent [18:34:13] :D [18:34:45] the PCR is in the memo for Luminary versions 121 to 130 [18:34:57] but doesn't say which revision exactly had the PCR [18:35:30] can't be long before 130 [18:35:40] if it is so bad then you would easily notice it [18:35:47] http://www.ibiblio.org/apollo/Documents/LUM127_text.pdf [18:36:05] so it can destroy some "valuable erasable memory", whatever that means [18:36:58] the most valuable would be something used for the ascent back into orbit, hehe [18:37:04] haha yes [18:38:32] scenario is about 30 minutes before PDI, so it'll take a bit to get there [18:39:13] so I guess maybe just save a scenario after you do the abort, and see what all unexpected changed in erasable :D [18:39:24] assuming things don't go obviously wrong right away [18:39:32] yeah [18:39:37] I'll save the scenario for sure [19:00:26] 2 minutes to PDI [19:02:56] I let it descent 2-3 minutes and then abort [19:05:27] P70 works ok so far [19:07:52] good insertion [19:08:00] didn't see any issues [19:08:23] thewonderidiot, you'll have to show me which part of the code was changed [19:08:31] Maybe the bug only happens with late PDI aborts [19:08:38] where that flag that was added would be changed [19:12:56] indy91, I am doing the landmark tracking in Apollo 9. The landmark tracking PAD seems to be a different format then the form in the Apollo 9 flight plan [19:14:24] The one in the Apollo 9 flight plan also seems to have gimbal angles [19:25:40] yes, I was super lazy [19:25:46] used the Apollo 11 format I think [19:26:12] I mean its not that bad actually, its actually a better format [19:27:17] yeah [19:27:33] T2 at 35° still works, but it's very close [19:27:54] it's about the time you should start marking [19:27:57] not any later [19:28:31] hmmm [19:29:15] it does say during an "early abort" [19:29:44] ah right [19:29:51] https://www.ibiblio.org/apollo/listings/Luminary131/P70-P71.agc.html#53544F525041524D [19:29:56] that's where the change is [19:30:02] that line and a few above [19:30:15] switchover point should be at about 6 minutes into PDI [19:30:22] I did an abort at 2:30 [19:30:27] really work all very well [19:30:32] anything funky in your erasable? [19:30:37] have to check [19:30:44] might screw up something for the rendezvous [19:31:25] where did it say early abort again? [19:31:32] http://www.ibiblio.org/apollo/Documents/LUM127_text.pdf [19:32:30] but yeah has to be [19:32:37] it loads the parameters for an early abort [19:32:40] J1PARM [19:32:45] and jumps over 3 lines [19:32:48] in L130 [19:33:04] so it jumps over the late abort constants (J2PARM) [19:33:17] if it's a late PDI abort then it doesn't do that [19:33:26] am I understanding that right? [19:33:30] so it does have to be early abort [19:34:23] yep, you're reading that right [19:35:54] P70 was all normal [19:35:59] no program alarms, no restarts [19:36:02] insertion was perfect [19:36:15] so that's probably why they didn't notice the problem before releasing 130 [19:36:24] if P70 was totally hosed they probably would have known [19:37:29] yeah [19:37:49] LGC finds the CSM [19:37:51] with the RR [19:41:02] I'll go through the padload and check if any of those were destroyed [19:41:07] ok I may be cheating, but I will skip a few of these landmark trackings on Apollo 9. Id like to finish this mission before the decade is out :D [19:42:56] save often anyway, especially before S065 photography PADs [19:43:08] those have cause the untrackable CTD for me :( [19:43:11] rarely [19:43:14] but 2-3 times [19:44:09] ah really? Havent had any CTDs yet [19:44:16] Ill keep a look out [19:45:00] it's the one that never happens again when you want to debug it... [19:45:15] Block Data PAD is the other one that can cause it [19:45:22] it's a display issue, so much I know [19:45:29] not a problem with the calculations [19:45:40] something weird with annotations and maybe the DX9 Client [19:49:36] thewonderidiot, I thought I had found something, but it was an error in our Apollo 13 padload, lol [19:49:56] hahahaha [19:49:59] nice :D [19:50:16] doesn't cause any issues though, unless you want to calculate a MCC with P75 (aka P35) for the CSM [19:50:23] but that's fixed now [19:50:31] hmm [19:50:53] but also would cause one AOT detent to have a bad angle [19:50:55] that's quite bad [19:51:02] well, it's fixed now [19:52:10] Apollo 13 out of all things [19:52:27] that padload is older than me working on padloads [19:52:43] back in the day we only ran Luminary131 for testing [19:52:59] so that was our default padload from one of the padload documents [19:53:39] yeah [19:53:56] that was already there 3 years ago [19:54:01] finally fixed :D [19:55:18] none of the padload parameters that should stay constant is broken in the post insertion scenario [19:55:33] but there are lots of other erasables of course [19:59:20] guess you have to check what exactly the bug does before I can check if it happened to me [20:01:01] yeah [20:01:05] I'll do that [20:01:19] this would be easy with basic code, lol [20:01:29] this needs understanding how the interpreter would handle that [20:02:07] ah yeah, the tricky interpreter [20:03:00] it just does a bunch of vector math, how difficult can it be :D [20:06:57] I'll try a few more things in the scenario for general LGC health [20:11:01] hahaha [20:11:19] it also executes approximately a bazillion instructions for each interpreted instruction :P [20:11:43] so it'll be hard to pinpoint exactly where things go wrong [20:12:12] yeah [20:12:33] a real time debugger connected to NASSP would be good [20:12:47] then I could make it stop at exactly the right instruction, haha [20:13:01] probably gets triggered when it starts P70 [20:15:08] well in any case, I have tested what I could test. If you want to track this down properly and come up with anything more let me know. [20:15:47] yeah, I'll look at it tonight [20:15:48] thanks! [20:16:05] no problem, I would have really liked to see a bad Luminary bug :D [20:16:19] all I got was a boring 0.00° plane error insertion [20:17:21] hahaha [20:17:41] well maybe we can still see one, when we figure out what broke [20:17:54] yeah [20:18:06] just need some pointers where to look in the erasable memory [20:18:19] I could do a full rendezvous, maybe something comes up there [20:23:46] hmmm [20:26:12] ohhhh this might be easier than I thought [20:39:08] hahaha, no, no it isn't [20:39:13] I think it's an indexed store into the pushdown list [20:40:15] luminary 69 has a somewhat similar code [20:40:26] so let's see if I can get something to assemble to the right number [20:42:53] okay! [20:43:00] the instruction it is deciding to execute is: [20:43:04] STORE 311D,1 [20:43:24] so position 311 (decimal) on the pushdown list, indexed by index register 1 [20:43:58] sounds like it depends on what it going on in the AGC at the time [20:44:04] switching from P63 to P70 etc. [20:44:55] well [20:45:12] maybe [20:45:22] nothing here looks like it's really using index registers [20:46:13] so we can probably assume that's zero [20:46:16] so, where is the pushdown list [20:50:10] okay [20:50:13] so it's at FIXLOC [20:51:37] oh no [20:51:46] this might depend on which VAC area got assigned to P70 [20:52:21] lol [20:52:53] okay so that means that one of five locations can be clobbered [20:52:59] so, what are these five [20:53:51] first possibility: EBANKSAV [20:53:56] er no [20:53:58] wrong program [20:54:31] first: MARKEBAN [20:55:05] second: OPTION2 [20:56:05] don't sound so bad so far [20:56:14] third: RN + 3 [20:56:16] that one sounds bad [20:56:34] oh yeah [20:56:57] fourth: DELPEROR [20:57:21] not sure what exactly "for boost" means there [20:57:22] fifth: E32C31RM [20:57:26] ooh [20:57:35] that is the one I bet [20:57:44] well, it's one possibility I guess [20:57:47] I have to check that one [20:57:51] padload [20:58:03] hadn't checked some of those that we set to 0 [20:58:04] as I understand it, the probability of each of these being clobbered is approximately equal [20:58:09] ok [20:58:37] and this is assuming I'm interpreting (heh) this correctly; I'll test this out in the emulator tonight and make sure I'm right [20:58:46] yeah [20:58:54] I'll do some more aborts to test as well [20:58:56] easily done [20:59:13] but that is certainly a valuable erasable [20:59:25] and also that my assumption that the index register will be 0 at this point [21:00:05] can I check that? [21:00:08] uhhhh [21:00:11] not really [21:00:16] interpreter code is super hard to debug [21:00:29] maybe [21:00:30] I'll think about it [21:02:08] how do I look at E32C31RM in a debug string again? [21:02:12] bank 0 [21:02:16] but EMEM1350? [21:03:08] yeah, 1350 [21:04:06] well the banks only go to 0400 [21:06:44] I think I got it [21:10:56] so the chance is 1/5? [21:11:25] working on it [21:11:41] if the index register isn't set to 0 automatically, it might be way more random than I thought [21:17:22] uhhh [21:17:38] yeah this might be re-using some random value as its index register [21:24:35] RN+3 is changing all the time in Average G as expected [21:24:40] the others don't change at all [21:24:59] guess it's not so simple [21:25:10] I hope we can still trigger the bug. Good night! [22:03:59] .tell indy91 so it looks like P70 is started via the phase tables, through an ENEMA. so the VAC area used will be consistent. assuming it's the only job started after the restart, it'll always get VAC1. I believe the index value it uses will simply be from whoever used VAC1 last [22:06:51] .tell indy91 so assuming that, the address clobbered will be VAC1 + 311D - X1 = 1070 - X1 [22:07:57] .tell indy91 for testing, assuming P70 runs for a while, we can check which VAC area it's getting [22:13:53] .tell indy91 it would also be really helpful to know the contents of your phase tables just before the abort [22:27:16] .tell indy91 nevermind, it's not VAC-relative. it's going to always be address 467 minus whatever is in X1 of the VAC being used [22:27:58] .tell indy91 (467 is in the middle of VAC2) [22:28:03] lol [22:28:07] I have exceeded my quota [22:30:42] haha [22:30:45] poor Guenter [22:36:27] night! [22:38:50] Haha. You triggered the spam throttling. It should still execute your commands. [22:39:11] It only does that when it passes the same message x amount of times. [22:39:38] haha, gotcha [22:40:33] Guenter! [11:23:36] good morning [11:23:58] some strange behavior is happening with docking [11:24:39] the first time my vertical velocity went into the hundreds and now the second time when i hit v49 the csm is pointed away from the sivb [11:25:58] weird. But first, the spam from Guenter [11:27:15] what exactly happened when the velocity was into the hundreds suddenly? [11:27:31] i was "translating" alot [11:27:57] also, you mentioned that the S-IVB isn't really pointing right for TD&E [11:28:05] maybe that's why the V49 is wrong? [11:28:10] possibly [11:28:13] it was a few degrees off for me [11:28:16] but not more [11:28:37] the first time the angles were right i used my old angles saved in my tablet [11:29:01] also i am wondering if the V25 N17 actually does anything [11:30:26] it loads an attitude for the error needles [11:30:41] that is what i thought [11:30:51] N17 for the separation attitude [11:31:06] also maybe i can try r1 11103 for the V48 it maneuvers faster [11:31:25] an often used procedure is also to use Accel Cmd for the 180° maneuver [11:31:29] in Pitch only [11:31:45] that is what the procedure is [11:31:58] but for roll it takes some time [11:32:06] for the V49 [11:32:15] yeah, that is a 60° maneuver [11:32:18] at 0.5°/s I guess [11:33:38] maybe you had Accel Cmd on when you did the V49? [11:33:44] possbily [11:33:57] that inhibits auto RCS firings in that axis [11:34:44] the vertical velocity is pretty low before the sivb even maneuvers to the t&d attitude [11:35:05] well you should be in a nearly circular 100NM orbit [11:35:25] well time to try this again [11:35:36] not sure what would be translating in any way [11:36:29] i don't know if you remember but this velocity issue happened the first time i tried 9 a few months ago [11:37:29] I don't understand it yet [11:37:48] what is making your vertical velocity go up? [11:38:01] and when does it happen and to what [11:38:04] CSM? S-IVB? [11:38:11] for my current mission the first docking attempt was fine but by the time i docked the vertical velocity was in the 2 hundreds [11:38:13] before docking, after docking [11:38:46] when does it start happening? [11:38:57] not sure but i am going to attempt it again now [11:39:07] i will be right back [11:39:10] I can't really picture the issue yet [11:41:10] for example, if your CSM suddenly has a vertical velocity in the hundreds, wouldn't it be very far away from the S-IVB suddenly? [11:58:21] i know what i did wrong [11:58:40] on my tablet the docking attitude is above the sep attitude [11:59:01] usually in a pad the dock attitude comes first so that is how i was reading it [11:59:26] sorry the sep attitude comes first then docking [12:01:03] yeah, like on the TLI PAD [12:01:25] i was putting the sep attitude in the V25 N22 [12:01:32] not good [12:02:25] yeah [12:02:37] simple mistake at least, easily corrected [12:02:42] yes [12:06:41] can you explain this vertical velocity issue again? [12:14:21] just docked with no issues [12:14:59] 12 FPS vertical velocity [12:16:01] I just don't understand what would be happening there for a sudden velocity change [12:16:52] guess it's not worth thinking too much about it unless it happens again [12:16:58] yeah [12:17:36] and for my first 9 attempt the velocity issue happened for the first docking attempt then in the 2nd it went away [12:17:38] very wierd [12:18:05] were you suddenly far away from the S-IVB? [12:18:23] no i was about 30 feet i think [12:18:26] in the docking mfd [12:19:02] before the issue happened? [12:19:06] or during/after as well [12:23:08] morning [12:23:25] hey Alex [12:24:15] got the Skylark coordinate system and precession/nutation matrix all figured out. So if (very big if) we ever get Skylark I should be able to make it work quite quickly. [12:24:35] great [12:25:23] and I implement the SCS logic buses yesterday. Not really connected to anything yet, but it has power and works with the switch and CBs [12:25:26] implemented* [12:36:21] oh cool, I didnt know that wasnt implemented yet [12:37:55] yeah those CBs and the Power 2/3 switch don't do anything yet [12:38:20] ah ok [13:08:42] you can do quite precise lunar landings in NASSP, but in the ends it usually is some micro texture crater [13:09:04] so I want to set up a scenario where you land at Brighton Beach, the Orbiter lunar base [13:09:24] and try if it is really possible to land at the center of one of the landing pads with the LM [13:10:49] Im sure it is, using LPD [13:11:00] yeah [13:11:08] and a bit of maneuvering in P66 [13:11:17] Zerlina would make it even easier [13:13:24] the base is at 33°W [13:13:50] so all mission scenarios I could use have it in darkness, haha [13:14:01] guess I need to do some scenario editing [13:14:29] I wonder if it would be possible to locally augment the resolution level (terrain/texture) of the landing sites with online data [13:15:25] Because if I am not mistajen, not all of the Orbiter 2016 moon is at the max possible resolution, everywhere [13:15:49] mistaken* [13:17:26] hmm [13:17:47] I think there was some higher resolution stuff coming, right? [13:17:56] but locally would be good [13:18:07] Orbiter install doesn't need to be 500GB... [13:19:43] yeah [13:32:02] I know some peoples FSX that are over 500GB [14:16:43] alright coming up on SPS-7 [14:17:21] looks like it raises apogee to 210 NM [14:18:45] yes [14:20:34] actual mission did 250NM [14:20:40] it also has a bit of outward velocity looking at the burn table [14:21:15] I guess it uses one of those combined GPM programs [14:22:03] it targets specific apogee and perigee altitudes and rotates the line of apsides right for deorbit [14:22:55] ah right [14:23:09] flight plan has an out-of-plane velocity? [14:23:24] I guess it ensures that the perigee will be over the atlantic at deorbit time [14:23:31] yees [14:23:58] hmm, no [14:24:02] well, -0.2 ft/s [14:24:11] In the burn schedule section. Vz: -73.4 [14:24:18] oh DVZ [14:24:26] yeah, that's for rotating the line of apsides [14:24:31] oh lol right you asked out-of-plane, my bad [14:24:32] minus, so that's upwards [14:24:40] you said outward first [14:24:49] not quite sure what you meant with that, haha [14:25:01] upwards I guess [14:25:23] yeah, I was referring to DVz [14:25:29] I see [14:25:52] I think the main goal there is to allow a minimum DV deorbit one rev after nominal deorbit [14:26:01] and have that land at a specific longitude [14:27:46] the targeting for SPS-7 isn't super accurate yet. That burn probably would require some correction terms for apsidal precession etc. [14:27:50] So why did the real mission end up using 250NM [14:27:55] good question [14:28:03] but it positions the perigee well enough [14:28:53] if you want to achieve specific apogee and perigee altitudes and also want to rotate the line of apsides by a specific amount, then there are only two places in the orbit where that can be done [14:29:06] maybe for Apollo 9 those positions worked out to be in LOS? [14:29:14] so they changed it [14:29:17] not sure really [14:29:57] oh [14:30:02] mission report has something [14:30:21] So in that scenario they would have dropped the apogee constraint maybe and it ended up at 250? [14:30:22] "SPS gauging test was added to the firing objectives" [14:30:30] oh [14:30:36] which required a longer burn [14:30:39] simple as that [14:30:45] hmm [14:30:51] but they added that out of plane [14:30:53] mostly [14:31:12] but that might be because of the out of plane DV [14:32:02] instead of adding lots of extra DV for rotating the line of apsides right, they increased the apogee to achieve a similar effect [14:32:07] 40NM more is quite a bit [14:41:48] saw something interesting in the Skylark documents Mike requested [14:41:52] about VHF ranging [14:42:26] about the range overflow which happens at 327.6NM or so [14:42:38] apparently Skylark can deal with longer langes [14:42:40] ranges [14:43:00] it checks if the expected and measured range are more than 300NM apart [14:43:34] and then adds the max amount to the number it gets from the VHF ranging [14:44:18] have to check if Artemis could already do that [14:44:21] but I don't think so [14:46:51] interesting stuff [14:48:16] So I just got my SPS-7 pad. Everything looks pretty good, DVZ is +69.6, while the burn schedule in the flight plan had that at -73.4 [14:48:58] what's the TIG in the flight plan and yours? [14:49:33] 169:49 on the flight plan, and mine is 169:40:41 [14:50:37] hmm [14:51:27] it's probably ok [14:51:38] have to analyze that a bit [14:51:54] how much 70 ft/s even rotates the orbit [14:51:57] do you want a scn? [14:52:29] nah [14:53:04] ok Ill carry on with the burn [14:53:28] I've had a much different DV even [14:53:38] mostly because my orbit was still very different [14:53:44] +216 DVZ haha [14:56:03] I guess its probably normal that it would be way off from the pre-flight value. DVZ must be very sensitive to the structure of the orbit up to that point [15:01:26] yeah, could be [15:03:19] I guess the fact yours was +216 after a mission that probably had a few burns that were still pre-GPM and now that I have made a full mission with all GPM calculated burns and that its gone down to DVZ +69.6 is a good indicator that the new burn methods are working well I guess [15:31:57] yes, my mission was only properly on track after SPS-7 [15:36:31] Once I finish Apollo 9, I was thinking of posting my scenario lot in a zip file on the forums [15:38:18] It could be a way for people to try mission scenarios while we still wait until they will be officially available in NASSP itself [15:39:39] sure [15:39:54] you could also upload them to orbit hangar [15:39:58] as a scenario pack [15:40:38] probably the better way to release something like that [15:41:27] Well as these are temporary, I can easily amend a forum post with updated scenarios as the beta progresses [15:42:03] Unless orbit hangar allows to easily amend it [15:42:13] never really used it tbh [15:42:41] But in any event the final goal is to have these scenarios included with NASSP of course [15:42:54] But that will wait until just before release [15:45:12] yeah you can easily update orbit hangar releases [15:45:26] forum post works [16:28:28] .tell rcflyinghokie, The MCC update at 187:30:00 on Apollo 9 is missing the uplink checklist after it [16:29:44] is that one of the SV uplinks I added? [16:30:12] yeah [16:30:22] flight plan only says S065 photo update [16:30:30] but you really need a state vector there [16:31:06] and on the real mission they got one [16:31:20] I talked this through with Ryan, weird that he forgot to add an uplink [16:51:04] morning! [16:54:03] hey Mike [16:58:36] hey [16:58:57] your messages confused me more than help me [17:01:28] hahaha [17:01:35] what about my comment on the pull request? [17:02:10] .tell rcflyinghokie, the same thing for the MCC update at 211:28:00 [17:02:28] that one is better [17:02:43] so can I test anything about it? [17:03:38] you could abort a few times and see if different addresses get corrupted [17:03:50] sure, just tell me which [17:04:07] the address will be random and (possibly) unpredictable [17:04:34] but, the data written out will be a copy of the six words starting at J1PARM [17:04:40] ah [17:04:45] so if you know J1PARM and K1PARM, it should be easy to find them [17:04:47] so I can try to find that sequence [17:04:50] yep [17:04:56] that's a good hint [17:05:03] I can already check in a scenario I had saved [17:07:25] wrote it to 0501 and following [17:07:36] hehehe [17:07:43] perfect [17:08:00] and the first 4 were appearing in a different place [17:08:08] probably just temporary storage for the abort constants [17:08:14] yeah [17:08:17] 2620 and following [17:08:41] R60VSAVE [17:09:18] "JPARM EQUALS R60VSAVE" [17:09:19] so yeah [17:09:30] yeah [17:09:31] that [17:09:34] JPARM contains the copy of the parameters being used [17:09:38] either J1PARM or J2PARM [17:10:01] oh right they are double precision [17:10:18] so 501 isn't really harmful, it's somewhere in the VAC2 area [17:10:31] yeah [17:10:32] it could corrupt another job using VAC2 [17:10:35] true [17:10:36] if there was such a job running [17:10:51] what could be there? [17:10:58] probably anything [17:11:11] yeah [17:11:25] most likely interpreter temporary stuff on the push-down list [17:11:51] so the X1 index register in the VAC area your P70 job got was -012 [17:11:52] descent guidance probably uses a bunch of the interpreter [17:11:54] in this case [17:11:58] yeah [17:12:07] well, as much as it can't avoid using it, haha [17:12:17] hehehe right [17:14:07] oh I got the Skylark precession and nutation matrix all worked out. Can generate it as close as it gets without having nutation in Orbiter. [17:14:15] awesome! :D [17:14:18] that was fast [17:14:23] Also, we don't happen to have one of those users guide to the major modes for early Colossus? [17:14:33] I don't think so [17:14:40] I had the script ready a while back, just needed some tweaks [17:14:52] it helped that I knew what the result should be [17:15:30] has a few interesting things that the GSOP wasn't detailed enough about [17:16:11] I don't know if there even was one for early colossus; the Apollo 13/14 version was only revision 1 [17:16:49] too bad [17:20:30] good news on my end, I finally actually sent money for the scans of the 1006323 transistor failure study [17:21:19] the conclusion of the report is that the mode of failure they were studying isn't anything to worry about in practice, and no AGCs should fail in the field due to the problem, even with tens of millions of cycles on the transistors [17:21:29] so one less thing to worry about with powering this thing up :) [17:23:38] history confirms that study [17:24:12] I think these transistors were phased out for the flown ones [17:24:16] not 100% sure though [17:24:45] ah, so even different [17:24:52] and probably not any less reliable [17:26:59] hopefully these were reliable enough :D [17:43:56] they better be [18:02:33] indy91, Looks like Joker on the forums is giving you more work... He wants to launch an Apollo mission in 2018 :D [18:04:32] Skylark would be better for that, haha [18:04:44] I bet [18:05:10] but it's not really possible [18:05:17] well depends on that you want to do [18:05:19] what* [18:05:39] I guess it would need a custom CMC/LGC binary [18:06:01] Like we did with Apollo 14 [18:06:36] Artemis and Luminary 1E got at least some tweaks to make it usable for a longer time [18:12:33] but it might be a good moment to clean up my MATLAB scripts for creating the precession correction terms [18:12:44] and make them public [18:13:43] you are getting an aweful lot of precession from 1972.0 to 2018 [18:15:00] yeah I would imagine [18:16:13] -AY padload would be -0.259° [18:16:20] btw Im coming close to deorbit/re-entry with Apollo 9. Did you want to know any trajectory details (location of periapsis) [18:16:45] altitude of the deorbit burn is enough [18:17:19] ok ill let you know [18:20:10] AGC lunar rotation model is decent enough even for 2018 [18:20:26] so all that stuff could be generated and would be usable [18:20:33] but I am worried about TEPHEM [18:20:39] and any possible overflow [18:20:52] speaking of overflow [18:21:42] thewonderidiot, about VHF ranging, Skylark would be able to deal with ranges greater than the scaling of the range would normally allow [18:22:06] at about 320NM it reaches the limit, 77777 I guess [18:22:13] then it would overlap [18:22:41] I guess I just need to make sure that works properly, so that e.g. 350NM is a small number again [18:22:49] what do I have to do for that? [18:22:53] hmmm, does it go all the way to 77777, or only 37777? [18:23:01] all the way to 77777 [18:23:07] weird [18:23:19] it then splits it up into a double precision numbers [18:23:40] so in RNRAD it's 0 to 77777, but then it gets rescaled etc. [18:23:44] stored somewhere else [18:24:05] so how do I make sure that 350NM is a small number again? [18:25:07] sat->agc.vagc.Erasable[0][RegRNRAD] = (int16_t)(range / 18.52); [18:25:11] this is what I do right now [18:26:02] scaling 0.01NM, therefore 327.67NM is the max [18:26:29] do I have to do anything to make 327.68NM a 1 in the register? [18:27:22] I believe the EMS register in the VHF ranging equipment works the same as the one for the CMC, so it displays 0.01 for 327.68NM [18:31:25] yeah, the new Skylark document explicitly says that 350NM range is 2232 (decimal) in the counter [18:32:14] so 327.68NM is probably 0 [18:33:36] sounds right [18:33:54] that's really funky [18:34:11] so it does two separate transactions with the radar? [18:34:27] does it use a different output bit reading selection? [18:35:23] no [18:35:26] all software [18:35:39] it checks if the expected and measured range is more than 300NM apart [18:35:58] if yes, then it probably has locked on at that larger range [18:36:06] oh, I see [18:36:12] so the radar will automatically change scales [18:36:17] and the software has to guess at which scale it got [18:36:34] yep [18:36:37] weird [18:36:59] guess the VHF ranging system is just adding up bits in the counters [18:37:06] and then it just overflows and keeps on going [18:37:19] yeah [18:37:33] it being their running sum of readings? [18:38:04] the counter itself can't overflow -- that one is a shift register using SHINC and SHANC, not an up or down counter like e.g. the PIPAs [18:38:34] yeah, could be internal in the VHF ranging system [18:38:51] what would happen if RNRAD gets more pulses than it could hold? [18:39:07] it can't [18:39:16] so it would stay at 77777 [18:39:19] no [18:39:22] it's not a counter [18:39:34] it works like the downlink [18:39:37] or uplink [18:39:47] shifts out the whole thing [18:39:49] exactly 15 bits are shifted in from the radar every time, that can be either 1 or 0 [18:40:07] so the register in the VHF equipment will have to be the same size [18:40:12] yeah [18:40:24] so that counter overflow thing has to happen there [18:40:28] yup [18:40:49] unless they're adding together individual readings of RNRAD in software, in some other accumulator [18:41:36] no, I don't think so [18:41:53] I can't confirm it about the EMS though [18:41:57] I thought I had read that [18:42:05] ...EMS? [18:42:10] did Skylark actually use EMSD? [18:42:27] EMS also displays VHF range [18:42:37] ah [18:42:40] and it has a similar counter as it has for the AGC [18:42:57] so I thought I had read that it also would display the short range then [18:43:19] 22.32 when it's actually 350NM for example [18:43:38] but that might still be the case of course [18:43:59] have to figure out when they had lock on during Skylab and ASTP [18:44:06] well in any case [18:44:13] the code I have already makes that work correctly? [18:44:29] sat->agc.vagc.Erasable[0][RegRNRAD] = (int16_t)(range / 18.52); [18:52:22] and then for the higher scale you just subtract off 327.68NM? [18:54:27] no [18:55:06] what would int16_t do? [18:55:21] if range is too large [18:55:57] but I guess I can make it modulo 327.68 quite easily [18:56:27] sorry, I'm not really sure what you're asking [18:56:53] what happens with the code I have if the range is larger than the register can hold [18:57:22] then it would presumably read the wrong thing [18:57:31] but what would it read? [18:57:38] from the AGC hardware point of view, it gets exactly 15 bits of range information from the radar [18:57:42] as prepared by the radar [18:57:51] I don't know how the radar constructs those bits, or how the software interprets them [18:58:20] especially in software we don't have the code for :P [18:58:31] that's not really what I mean. [18:58:35] (int16_t)(range / 18.52) [18:58:46] if the range is 350NM [18:58:49] ok, even easier [18:59:05] is the question about how int16_t's work? [18:59:10] yes [18:59:17] (int16_t)(35000) [18:59:23] what does this result in [18:59:40] technically undefined, but that almost always wrap around and start counting back up from -32768 [18:59:52] that sounds right or not [19:00:02] I don't know [19:00:05] but if it's undefined I better do the modulo myself [19:01:00] that was pretty much what I am asking, if the code that already is there does what I want automatically [19:01:51] but I guess not necessarily [19:02:44] indy91, altitude at deorbit TIG is 176.5 NM [19:02:59] used P21 [19:03:03] ok [19:03:20] close enough to 210NM [19:03:27] and it wouldn't be exactly at apogee anyway [19:03:36] minimum DV deorbit at the next rev would be [19:09:10] sat->agc.vagc.Erasable[0][RegRNRAD] = (int16_t)fmod(range / 18.52, 32768.0); [19:09:13] this should do it [19:13:08] guess I should have specified this was a general question, not about the AGC part of it :D [19:17:11] hehehe [19:17:21] so what do you think the chances are that NARA has a drawing for the AGS itself? [19:17:41] I have a number... LSC 300-330-3 [19:17:49] that is the AEA [19:18:24] for Apollo 12 it there was an additional -10, so LSC 300-330-3-10 [19:18:33] sorry LM-12, Apollo 17 [19:18:46] I think that -10 is the version of the AEA [19:20:22] that would be fun to have [19:24:54] AlexB_88, which mission did you fly where you had issues with RR data transfer to the AGS? [19:25:30] 15 [19:25:36] ok [19:25:50] was just looking through Luminary memos, that wasn't added until Luminary 206 [19:26:16] but 15 uses 210? [19:26:16] hmm [19:26:19] yes [19:26:33] well there were some references to it in earlier revisions already [19:26:54] we'll have to debug that some day [19:27:00] yeah [19:27:19] I just noticed something with panel 382 in the CSM. Even if the panel is covered, the switches can still be clicked, so that can be bad if you accidently click a switch on it, but dont notice because its covered. [19:28:21] oh [19:30:00] write an issue or so :D [19:30:36] sure [19:30:54] Artemis072/Luminary210 limit is a launch on 17 February 1974 [19:31:12] Well heck, I could almost fix it myself, if I follow the same code from the hatch open/close lol [19:31:27] I have no problem with that, haha [19:31:58] ill make an issue anyway I think [19:32:16] just to remind myself ;) [19:34:40] yeah [19:35:22] email sent! so that's Grumman's number for the thing, and TRW called the AEA part number 220000-9 [19:35:41] I'm not sure why... Grumman didn't have their own part number for the AGC or anything [19:37:59] the usual procedure, right? You have a part number but aren't sure if NARA even has it :D [19:38:30] yep [19:38:46] if they have this though then we'll know they have a *lot* of LM drawings [19:39:12] they seem to have a lot of LDW stuff, but if they have LSC, we can get a drawing for almost anything [19:39:29] fun [19:41:43] as usual though I strongly suspect they won't have this :D [19:45:11] I also unsurprisingly haven't heard back from KEMET, lol [19:46:10] KEMET? [19:46:20] the company that made all of the capacitors in this AGC [19:46:34] ah [19:46:49] I sent them a message asking for the datasheet for this capacitor, and any longevity information they have [19:48:10] what's the capacitor state of that AGC again? [19:48:21] great question, lol [19:48:42] well none of them exploded at least I would guess [19:48:52] I know it has ~200 solid tantalum capacitors, and there is an unknown chance for each that it will explode when we give it power [19:49:00] ah, yes [19:49:07] we haven't given any power yet :) [19:49:09] capture that moment on video please [19:49:17] nooo [19:49:22] if it wrecks the AGC at least in an entertaining way [19:49:25] lol [19:49:41] any way to do it carefully? [19:49:48] yes, *but* [19:49:51] or replace all the capacitors before powering it up... [19:50:04] the most careful way to do it involves isolating from the circuit, i.e. cutting the wires going to them [19:50:10] which is unfortunate [19:50:19] yeah, doesn't sound so good [19:50:30] so I need to get and evaluate some capacitor health testers [19:50:43] almost 100 of them can be tested without making any cuts [19:50:49] so those will be the first ones we check out [19:51:36] yeah [19:51:44] before I got distracted with Luminary 130, I started to put together a spreadsheet that catalogs all of them [19:52:03] https://docs.google.com/spreadsheets/d/1XpuFQBrmuI2mqqyh7KQ9qGyxF0GUPSIrTFw18fx0g0M/edit?usp=sharing [19:52:18] oh, should I do a few more Luminary 130 aborts to see where the abort constants end up being copied to? [19:52:29] sure! [19:52:30] or will it be VAC areas for all attempts [19:52:35] oh no [19:52:39] you just got lucky [19:52:55] it's going to take a somewhat large X1 to break you out of the VAC areas [19:52:58] so there still is the potential that really bad things happen [19:53:05] but some programs use complete addresses in X1 [19:53:08] oh yes [19:53:16] that's good motivation [19:53:33] hehehe [19:53:41] nice list [19:53:50] work in progress :P [19:54:12] I did a lot offline that I need to get in it [19:54:16] into it [19:55:34] I am curious to see if the 200 number from R-700 is accurate [20:06:15] interesting [20:06:32] this time, after insertion, the constants aren't anywhere [20:06:38] well, in their normal place [20:06:55] but it must have been some temporary memory that was already overwritten [20:07:16] yeah [20:07:21] must have been [20:07:25] well, that is a good sign [20:07:26] dinner time, cya guys! [20:07:30] see ya! [20:07:40] it would have been disappointing if they always showed up at 501 :D [20:08:02] I might have aborted to late [20:08:09] that could be too [20:08:11] I think it used the second set of parameters [20:08:25] are the J2PARM numbers in JPARM? [20:08:56] yeah [20:09:02] yep, too late! [20:09:12] don't know the exact switchover time for 13 [20:09:17] it's based on phase angle [20:09:26] might have been later for Apollo 14 [20:09:37] that's where I got the 6 minutes or so number [20:09:47] it was before 6 minutes for sure [20:11:26] 5.5 minutes for Apollo 13 [20:11:38] I thought it was before that, but it might have been close [20:18:03] oh crap, I did just get an email from KEMET [20:20:21] they want pictures :P [20:22:28] haha [20:52:22] well, that wasn't helpful [20:52:46] I sent the pictures, and received back a catalog of all of the capacitors they make today, saying basically "maybe they could be any of these" [20:53:37] lol [20:56:18] maybe a KEMEMT group of retirees would be more helpful, haha [20:56:24] yeah maybe [20:56:30] seems like that would be hard to find though :P [21:07:53] good night! [14:07:24] good morning [14:07:32] about to do SPS 1 for apollo 9 [14:08:31] i remember Alex talking about uploading his 9 scenarios could i do that with my 11's? [14:09:45] hey [14:10:16] There is no copyright on NASSP scenarios, haha, if you think they are useful you can surely post your scenarios on the Orbiter Forum or Orbit Hangar [14:24:28] Hmm. That's an interesting thing to talk about. Does copyright apply to save games in general? Since a save game could be considered as an original work by the player. [14:26:44] true [14:27:43] Thymo, can you remember what all we changed in the modified Comanche055 for Apollo 10? [14:27:55] was it star vectors and some lunar rotation parameters? [14:29:13] Yeah, you passed me a list with a bunch of constants to punch in. I think all changes were in FIXED-FIXED_CONSTANT_POOL. [14:29:24] that's Luminary [14:29:33] did you change anything in PLANETARY_INERTIAL_ORIENTATION? [14:29:36] of Comanche [14:30:00] do you still have the source code files for the modified versions? [14:30:32] I'm fairly certain I at least played with COSI and SINI. [14:30:37] Let me check. [14:30:41] ok [14:31:27] someone on the Orbiter Forum wants to set up a mission in 2018, but I don't think it would be possible without modifications [14:31:33] I knew we should have comitted them to NASSP. :P [14:31:40] Probably not know. [14:31:43] or at least a repo only [14:31:47] online* [14:32:26] if you use the normal time reference of Artemis and Luminary 1E (July 1st, 1971) then you get overflow with planetary orientation calculations in early 1974 [14:32:52] if you use an arbitrary time reference then especially Luminary won't find anything anymore [14:33:26] so it's not really possible without modifying hardcoded values [14:34:12] Skylark would work in 2018, but it doesn't have any lunar rotations [14:34:27] and solar ephemeris in erasable memory [14:34:35] Wouldn't be too bad of an idea to move those constants to erasable while I'm at it, then they can be padloaded. [14:34:47] if you know how to do that [14:34:53] Shouldn't be too hard. [14:35:06] Only issue is banking AFAIK [14:35:08] freely modifiable Artemis072 and Luminary210 would be awesome [14:35:10] yeah [14:35:54] And initialization at fresh start or there is a minor chance of getting issues like Sunburst 37. [14:36:11] right [14:37:18] I found a Comanche055NBY69.bin on my server. Haven't found the source yet though. [14:37:58] I guess if we ever modify one again, then we should really put the source somewhere online [14:38:12] I am now fairly certain what we modified [14:39:35] I'm planning on doing a custom rope for NASSP anyhow. I want some nice bleeding feature's to mess around with on my way to Venus. :) [14:40:21] oh right, that custom rope :D [14:41:34] I already started working on it. It has the ability to swap verb banks so I don't have to throw out other verbs that might be useful. [14:44:10] I might have lost the source when recloning the virtualagc repo, or it's hiding in my mess of agc ropes I store everywhere in stupid locations. [14:44:30] If I don't find it, it can probably be reconstructed by diffing the binaries. [14:53:03] Comanche044 is interesting [14:53:16] I know what all the changes in the GSOP are from 44 to 55 [14:53:51] might even be possible to fully reconstruct it [14:58:54] Do we have the PCRs too? [15:00:09] the numbers of them in the GSOP [15:03:04] oooooohhhh man NARA has two versions of LSC 300-330-3 [15:03:06] I forgot we had all the Skylark memos [15:03:12] you are too early Mike [15:03:20] I am too excited :P [15:03:43] haha [15:03:49] is that the AEA schematics? [15:04:22] it's going to be a drawing of the AEA, but it is very possible that following this road will culminate in AEA schematics [15:04:38] awesome [15:05:10] I'm getting scans of both of them [15:08:46] then maybe people could build their own AEAs [15:08:55] not sure why they would if they could also build an AGC [15:08:56] hopefully! [15:09:15] I need something to do after I build my AGC :P [15:09:39] for the 60th anniversary of Apollo 11 [15:11:55] haha [15:12:01] hopefully my AGC is done by then [15:12:13] I've been making staggeringly slow progress ever since I emailed Don [15:14:31] Okay, I found the code that does the verb banking. However it's in a fork based on Retread44. I'm gonna port it to Artemis072 and let that be the base for the custom mission ropes [15:15:11] First change: Making the star vectors available in erasable. [15:16:15] Can't wait till the minigames and popcorn dispensers are in. [15:17:08] I'd already settle for a Artemis072 that isn't broken in Earth orbit :P [15:17:14] you're gonna have to find a lot of things to delete to make room for all of that :P [15:26:17] indy91 why the heck would we reconstruct Comanche 44 when Margaret has a listing? [15:26:23] all you need to do is email her ;) [15:27:54] I even have the beginning of that email written already, haha [15:29:05] hehehe [15:32:51] I'm off to work. Cya! [15:44:01] I too am off to work. be back at the usual time [15:44:28] cya later [16:46:21] back! [16:46:53] I have sent that email [16:47:00] only took you about a year to get me to do it [16:49:10] hahaha [16:49:12] awesome! [16:49:33] I'll be curious to hear what she says :) [16:49:40] in the mean time, I got another email from NARA [16:50:00] turns out these aren't drawings after all, but folders containing reports about particular AEAs [16:50:03] she sent me a few sample pages [16:50:23] https://drive.google.com/open?id=0B3i9WUgD9n2tcUlEaElVOFU4UlROYlZqcmFOSmVDM3hZOEJZ [16:52:02] narrative end-item report is a common document [16:52:15] I have loooots of these for S-IVBs [16:53:12] interesting [16:53:20] can you send me an example? [16:54:54] I guess it's just a common name for such a document [16:55:22] https://ntrs.nasa.gov/search.jsp?R=19700026644 [16:55:41] for the S-IVB there seems to be a different report from different places working in the S-IVB [16:56:21] maybe this type of document is just thing all contractors had to write for NASA or so [16:56:41] wow [16:56:50] this would be pretty amazing to have for an AGC [16:57:34] yeah [16:57:43] for the S-IVB it's basically too detailed, haha [16:57:51] can't get much out of it for NASSP [16:58:00] hehehe [17:24:31] Jimmie's AGC continues to confound me [17:24:59] since I found those wires on the backplane that it really shouldn't have, I went through and cataloged all of the module part numbers and serial numbers last night [17:25:44] and its power supplies are both part number 2003891-011 [17:26:11] and *nowhere* is there a reference to this being a possible power supply number -- not in the handbook, not in either version of ND-1021042, or anything [17:26:37] the closest one is the power supply for the flight AGCs, which was 2003892-011 [17:27:00] which is strangly close, but this is also clearly an earlier power supply [17:28:10] and there's a single module, A28, that isn't marked with an X, and I don't know why [17:35:27] sounds like an AGC with a long history of being used for testing really [17:36:24] a bit patchwork-ish [17:38:53] haha [17:39:00] yeah, I mean, I was expecting that stuff [17:39:12] but a completely undocumented (from what we have) part number is weird [17:39:40] right [17:39:59] https://docs.google.com/spreadsheets/d/1WOPp4fDcvFGQPMcvP6UMJ1WpBss0nGDiG_zwDqmeeqQ/edit?usp=sharing [17:40:21] I think I'm going to expand this to include 200M as well, and whatever other AGC I can catalog [17:46:51] also Lynda says Volume II of ND-1021041 should be online next week, completing our Block I schematics :) [17:48:14] finally [17:49:33] haha yeah [17:49:50] I reeeaaaallly hope this gets Francois motivated enough to go back to Corona [17:51:14] the main ambition for NASSP is probably to have some automated missions running, like Apollo 4 and 6 [17:51:28] similarly done as Apollo 5 [17:51:34] just more of a show than something to do [17:51:57] all I have heard about the Apollo 1 software is that it was pretty bad and buggy [17:52:15] not sure if a manned Block I mission makes much sense or would be much fun [17:52:18] if we had the software [17:53:11] but an automated mission that basically is orbital insertion, TLI, direct return abort, reentry would be quite fun to see [17:53:41] yeah, for sure! [18:56:33] time to listen to more RETRO audio loop from Apollo 11 [19:20:21] guess I know the phone number of an off duty flight controller now... [19:22:08] hahaha [19:22:45] Chuck Deiterich actually [19:23:01] on the loop they were discussing a maneuver being heads up or heads down [19:23:17] everybody says heads down, but pre flight Chuck must have said heads up [19:23:22] and now they want to call him at home... [19:23:43] the loop is entertaining in some strange ways [19:24:10] and my new phrase for everything going right "I've never been greener" [19:25:14] just haven't figured out which maneuver they are even talking about [19:25:24] either the evasive maneuver or one of the post TLI aborts [19:26:21] phone ringing! [19:26:56] and there is probably Chucks wife on the phone [19:27:00] this is hilarious [19:27:30] live on the RETRO loop [19:29:53] Chucks says use heads up or heads down to make it 180° roll gimbal angle [19:31:13] sounds like they talk about post TLI aborts in general, but the TLI+90 abort specifically. [19:31:31] Which ends up having this attitude: Roll, 180°; Pitch, 193°; Yaw, 000° [19:31:53] so that concludes the "Call Chuck at home to ask him for heads up vs. down" saga [20:01:54] hehehehe [20:01:59] haha, wow [20:02:01] that's awesome [20:18:31] at 1:30 GET now, I bet there will be still much more gold to find [20:18:36] anyway, good night! [12:29:01] .tellindy91 just when you get on the chat do you know the dv's for the apollo 12 sps evasive maneuver? [12:29:49] .tell indy91 just when you get on the chat do you know the dv's for the apollo 12 sps evasive maneuver? [13:08:13] .ask indy91 Do you still happen to have a list of the star vector constants? [15:36:53] Hey [15:37:03] hey, good evening [15:37:40] which ones? [15:38:32] we used different ones for different AGC versions we created [15:39:14] I'm gonna use my form of Artemis072 and want to move them into erasable. I just don't know which ones I need. [15:39:53] you mean where they are in fixed memory? [15:39:54] s/form/fork [15:40:05] What they're called, yeah. [15:40:47] https://www.ibiblio.org/apollo/listings/Artemis072/STAR_TABLES.agc.html [15:42:25] there they all are [15:43:40] That's all that I'd need to move into erasable? What about the constants in planetary_inertial_orientation? [15:49:10] well you asked about star vectors [15:49:37] what is yor goal with moving it to erasable? [15:50:07] making the AGC work for a differernt epoch? [15:52:49] astronauthen96__, there is no Apollo 12 SPS evasive maneuver [15:52:52] Sorry. That's indeed what I meant. Just like we changed Comanche055 and Luminary 210, I want to do that again but make them pad loadable so they can easily be updated. [15:53:59] then also the ones at the bottom of PLANETARY_INERTIAL_ORIENTATION, yes [15:55:39] then you could easily update the AGC for another epoch, so any year you want [15:56:43] Cool. I'll move them and upload them to github this time so it doesn't get lost. [15:56:46] there were a few more we had to do for the LEM [15:57:12] the LGC doesn't have a padloaded solar and lunar ephemeris but much more simple hardcoded ones [15:57:27] we had to change those for Luminary210 for Apollo 14 [15:59:00] in Artemis it's just the stars and Earth and Moon rotation stuff [16:00:28] Ah so lunar ephemeris data is already padloaded in artemis. [16:01:28] yeah, lunar and solar ephemeris is already in erasable [16:01:36] in all Colossus versions [16:03:52] Found them. Under Conisex storage: TIMEMO, RESO, etc. [16:05:22] that's the ones [16:06:30] lunar one is a 10th degree polynomial, so a lot of numbers in the erasable [16:06:40] Hmm. yaYUL only outputs fixed memory bank usage info. I guess I'll have to find space some other way. [16:08:33] don't think there ever was much spare erasable memory since the first revision of Colossus, haha [16:13:03] wishes we had the aux. memory modules [16:14:39] morning! [16:14:58] hey Mike [16:15:22] Got an AGC related email... from Fabrizio asking more questions about their CSM and LM simulators, like last year .D [16:15:23] :D [16:15:35] Hey Mike [16:16:52] nice, how's that going? [16:18:23] they seem to have a working SCS now, LM simulator is quite new [16:18:36] he needs help with padload stuff for both CMC and LGC [16:20:22] he was trying to convince Jimmie and me to go to Rome for this event, with Jimmie's AGC and other hardware, but Jimmie doesn't like the idea of flying to a foreign country and leaving all of his hardware with people he doesn't know for a week [16:21:00] yeah, understandable [16:21:26] and I'm worried about this AGC's erasable memory module, since accumulated shock and vibration will eventually break the wires inside it [16:23:07] yeah [16:24:59] in other news, one of the curators (I think) at Space Center Houston is quite interested in all of this and wants us to do the power on event [16:25:08] and miiiight be able to get me some of those things on the restricted NTRS list :D [16:25:29] do the event at Space Center Houston that is [16:26:07] sounds like a good place for it [16:35:26] I really hope he can get me those manuals :P [16:36:12] 50th anniversary is opening doors it seems [16:54:14] @indy91 starting apollo 12 [16:54:23] using some checklists for nassp [16:54:39] we have a bunch of Apollo 12 ones [16:54:43] including launch checklist [16:54:56] on Apollo 12 only the S-IVB did evasive maneuvers [16:55:06] these ones http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2772.0 [16:55:19] you'll need to uplink commands to S-IVB with the PAMFD for that [16:56:02] i will try to at least make it into lunar orbit [16:56:10] page doesn't load for me [16:56:15] but first i am going to the casino [16:56:16] damn unreliable old forum [16:56:21] https://history.nasa.gov/afj/ap12fj/index.html [16:56:27] here are lots of checklists you can usr [16:56:28] use [16:56:35] "Apollo 12 Launch Operations Checklist" [16:56:41] this is the first one you will want [18:00:41] Fabrizio says: "I met Don [Eyles] last month in NYC and he was very curious about the Zerlina video. He saw that of course!" [18:05:02] I expect that he had a bunch of "wait, how did they..." moments while watching that [18:06:46] hahaha [18:07:08] awesome :D [18:07:57] and the answer to all "wait, how did they..." questions is of course: with immense difficulty [18:08:14] Zerlina didn't really make it easy on us [18:09:04] haha it really didn't [18:20:29] I should be able to fit the star table into ebank 7 with 152 words to spare. [18:23:00] really? what all are you changing, haha [18:23:26] there's 7 whole overlays in that bank, and you'd have to remove all (up to) 7 for each word [18:25:04] Wait [18:25:35] How does yaYUL display those addresses again? [18:25:41] E7,1426 E7,1754 [18:26:02] I don't know what the first one is, I never figured that out [18:26:11] I used that. Wrongly so obviously. [18:26:12] the second one is the actual address being assigned [18:26:17] Yeah, I see that now. [18:26:37] they were so tight on erasable that most locations are used for several things [18:26:48] so to free up one word, you need to find all uses of it [18:26:55] 7 overlays, lol [18:27:02] I shouldn't be surprised [18:27:04] yeah, ebank 7 is pretty intense :P [18:27:08] The left one is only incremented when something is allocated using ERASE. [18:29:56] weird [18:30:04] Where am I gonna find 222 contiguous words? :P [18:30:13] you're gonna have a bad time :P [18:31:05] for your purposes, the original listing is going to be more useful than yaYUL [18:31:06] https://archive.org/stream/Artemis072J2k60/Artemis072-j2k-60#page/n1568/mode/1up [18:31:15] GAP puts out some pretty nice tables at the end [18:31:27] that table gives all of the names given to each erasable location [18:32:32] but, you're looking for a whole 11% of the total erasable to be freed up, which is a pretty big ask [18:33:00] before they even started adding new features Skylark they deleted so much from Artemis [18:33:27] most of the first 20 SKylark PCRs are just deletions [18:33:49] even P37 which is quite sad [18:33:57] they had to; towards the end of the program, finding an optimization that saved even just 20 words was a huge thing [18:33:58] works well enough for LEO [18:34:20] what does P37 do? [18:34:28] Return to Earth program [18:34:41] oh, who needs to go back there :P [18:35:15] but the code is very intertwined with stuff you only need when you are far away from the Earth [18:35:29] no good way to make a LEO version out of it [18:35:45] and it should be quite large, so a good thing to delete [18:36:05] I'm sure they developed good procedures for a complete loss of comm [18:39:05] yeah, same as for Apollo, block data for contingency deorbit maneuvers [18:39:23] at least for ASTP that is the case [18:42:40] Well I guess that's it for erasable star tables then, unless I start doing some serious cleaning. [18:45:44] yeah. I'm sure the original devs would have loved to have done this, if it was possible, but the AGC just has too little memory [18:46:21] bank 7 isn't the only bank that has words used up to 7 times :) [18:50:12] they put the solar ephemeris in the erasable in Skylark, but it's a much smaller number of addresses you need [18:50:38] star vectors were referenced to epoch 1973.0 [18:51:07] The major problem is that the star tables are padloaded and need to stay resident the whole mission. Contrary to stuff for P11 that can be thrown away after insertion. [18:51:16] yep [18:51:22] can't throw away the stars [18:57:22] now I kind of want to know what would have happened if you had loaded all of the star data into ebank 7, starting at 1426 :P [18:57:53] worse things than in Luminary 130 [18:58:31] oh, I guess I never mentioned this [18:58:49] Luminary 130 can only corrupt unswitched erasable [18:59:04] that bad instruction explicitly selects ebank 1 to be mapped to the switched area [18:59:16] so ebanks 3-7 are safe [19:00:50] I'm sure astronauts feel very safe knowing that [19:01:38] lol [19:04:32] more Apollo 11 RETRO loop for me now [19:06:02] let's see if there is anything weirder than calling Chuck Deiterich at home live on the loop [19:07:24] all people using the RTCC MFD are definitely spoiled. Generating one PAD takes a lot of work and discussions, haha, not just one button click [19:13:02] you have made things too easy for them :D [19:21:17] one thing I will make more difficult soon-ish [19:21:24] finite burntime compensation [19:21:39] most RTCC processors just outputed an impulsive DV for maneuvers [19:22:06] and the maneuver planning table was then used to generate a compensated solution [19:22:16] with more options than possible right now in the MFD [19:22:28] even S-IVB LOX venting could be used a thruster there [19:23:45] RETRO loop is super quiet when a Maneuver PAD is passed to the crew [19:24:13] guess it's not just the CAPCOM reading numbers, some flight controllers and back room people are also checking every number while it is read up [11:56:24] hey [11:56:57] hey Alex [11:59:06] Ive continued listening to the Apollo 11 RETRO loop and it's been quite entertaining [12:00:12] they were unsure if some maneuvers should be calculated in heads up or down, so they called the off-duty lead RETRO Chuck Deiterich at home, live on the loop [12:00:47] haha [12:00:50] first Chucks wife was on the phone, then he got Chuck and he answered the question [12:00:55] she* [12:01:14] lol [12:01:34] yeah, a bit bizarre :D [12:01:46] didn't quite expect that [12:01:54] so she relayed his answer I guess [12:02:09] no, he was on the phone then [12:02:24] but first his wife [12:02:55] right [12:03:30] Its also funny because these are the same question I sometimes ask myself when flying a mission w/RTCC MFD [12:03:44] yeah, same [12:04:04] it was about the post TLI direct aborts I believe [12:04:25] everyone thought the answer was heads down, but the on-duty RETRO remembered Chuck saying heads up [12:04:43] and the final answer from Chuck was: whatever give 180° gimbal angle [12:05:36] I guess the questionj was mostly about the TLI+90 abort, because that's the only full Maneuver PAD the Apollo 11 crew got [12:06:07] I'm shortly before TLI now with this RETRO loop file [12:06:24] faintly in the background you can also hear the FIDO and his people quite often [12:06:43] makes sense that their duties are connected [12:07:46] the topics in the loop were mostly assemblying data for the PADS [12:07:53] PADs* [12:08:07] abort PADs and the pitch angle for a TLI+10 minute abort on the TLI PAD [12:08:31] it's definitely the opposite from the RTCC MFD where you click one button and the PAD is ready [12:09:00] and another common topic is the state vector with which the abort maneuvers are calculated [12:09:33] CMC state vector was quite off in the out-of-plane component from the IU state vector for example [12:10:02] the best tracking can be done over the US, but at that point they already had to read the PADs to the crew [12:10:49] that kind of thing [12:13:47] makes sense they didnt have time to do the best tracking before TLI [12:14:43] I was curious about something, I see some new text files in the main directory "ProjectApollo Saturn5" and "ProjectApollo PanelSDK" [12:14:54] Is that for debugging? [12:15:08] where? [12:15:23] oh, log files? [12:15:36] I believe that is used when you build in debug mode [12:15:48] wait those are not new, they have a timestamp of march 13th [12:16:02] then you ran NASSP in debug mode then [12:16:08] oh I guess I had accidently built in debig mode back in March yeah [12:16:13] debug [12:16:46] yep [12:17:07] good morning [12:17:16] have any of you flown 12? [12:17:23] I just saw the new PrecessionData file, nice stuff [12:17:27] hey [12:17:50] astronauthen06__, I have [12:17:53] hey [12:18:14] oh and sorry for making you 10 years younger [12:18:46] AlexB_88, I converted my MATLAB scripts for the precession/nutation/libration correction vectors and added them to the AGC ephemeris page, yeah [12:18:48] i will probably make it to lunar orbit but landing and rendezvous will not be easy [12:19:44] the resulting octals are not the same as we use in most padloads, lol [12:19:51] I wonder if I got the scaling wrong in the past [12:20:11] hmm, really? [12:20:53] Well Ive definelty had pretty accurate lat/longs in all the missions Ive flown [12:20:54] the new octals look to be larger than in padloads [12:21:12] oh yeah, it is usually correcting only for a few 100 meters [12:21:26] not for all missions though. For some they are quite close [12:21:34] to the old octals [12:22:02] I wonder if that would take care of the final few feet of error we were seeing in longitude on lunar landings [12:22:21] it's never 100% identical because I had experimented with the Earth's axial tilt in the MATLAB files I believe [12:22:23] could be [12:22:38] also, you will see a bit of an increase in error for long duration lunar stays [12:22:47] right [12:22:56] the correction vectors in the LGC are optimized for the time of landing [12:23:42] So at this point I guess we can build a custom mission with full padloads at any time within the CMC/LGC's validity period [12:24:05] yeah, you just need to figure out a whole bunch of MJDs as inputs [12:24:42] but now the padload worksheets plus RTCC MFD should have everything you need [12:27:59] and about the scaling, some tests with the AGC and the planetary inertial orientation routine might be needed to 100% confirm that the correction vectors work right [12:30:52] how would these tests be done? [12:30:59] good question [12:31:28] maybe displaying temporary memory locations used in e.g. P21 [12:31:51] MATLAB scripts and RTCC MFD definitely give the same engineering values for the correction vectors [12:31:57] so that is worknig right [12:32:50] oh [12:33:04] LGC padload for e.g. Apollo 15 is correct [12:33:29] but CMC one is different [12:34:17] oh right [12:34:27] LGC uses landing time for the 100% accuracy [12:34:33] CMC uses mid mission [12:35:39] still, CMC padload doesn't look right [12:35:52] unless the scaling is different [12:37:13] I think the scaling in the CMC padload worksheets is wrong [12:37:40] yep, I think that is the issue [12:38:14] the MATLAB scripts have the right engineering values, I put them in the CMC padload worksheet and there the scaling is done wrong [12:38:17] Ah interesting [12:38:28] it's not in revolutions, but in radians [12:38:36] hence the octals became too small [12:39:00] so I guess I have to correct most of the CMC padloads [12:40:07] Btw I was looking at the code for the RR XMTR that you added recently. It looks pretty simple so I decided to try and add the same for the LR ALT/VEL XMTR and I got that working in my local copy [12:43:22] The only thing I guess is that both the ALT and VEL call the same function "GetTransmitterPower()" and return 0 if it unpowered. The question is should that be split into separate functions for both the ALT and VEL? [12:46:40] I mean it could be separate functions like LEM_LR::GetAltTransmitterPower() and LEM_LR::GetVelTransmitterPower() with them both identical (a check for if powered) for now but at least it will be ready when we want to develop the separate XMTRs more [12:54:54] the LR self-test seems to have slightly different normal readings for ALT and VEL (3.4v & 3.3v) So I guess yeah it should be separate [12:56:16] LR self-test checklist* [12:57:17] the expected voltages are also not really consistent from mission to mission [13:03:35] I don't see how the LR test circuits are connected to the transmitter though [13:04:31] hmm, well, it might be [13:06:45] no, probably not [13:06:53] it's only temperature dependant [13:07:05] so maybe during the testing the temp is not fully up yet [13:07:39] AOH says to expect at least 2.1V, 3.0V is expected [13:07:48] and that's before the testing is switched on [13:08:19] so I think it's good enough if both alt and vel transmitter have 3.0V fixed when the LR is on [13:08:27] ok [13:13:35] scaling was wrong in Artemis072 and Artemis072 padload worksheets [13:13:39] it's right in Comanche055 [13:14:45] and the previous versions [13:15:04] so I guess only the correction vectors for the Moon for Apollo 14-17, only the CMC, have to be redone [13:17:39] great [13:17:59] I got a PR ready with the Alt/Vel XMTRs [13:20:37] I don't see one [13:20:43] now I see one [13:22:08] merged [13:23:03] thanks [13:27:47] I've started working on the two segment abort constants for Apollo 12 and alter [13:27:49] later [13:28:20] I am pretty sure there is an error in the document with the program flow for this, so I have to fix that first [13:51:12] yeah, I think I figured it out [13:51:22] probably solves the iteration issues I had before [14:45:11] AlexB_88, had you finished Apollo 9 yet? [14:56:29] I still have to actually fly re-entry [14:56:51] right, I knew you told me the altitude at TIG but not anything after it [14:57:13] just your standard Earth orbit reentry [14:57:28] But I havent had time to fly it yet as I am on a stretch of work for the past few, and next few days [14:57:29] bit more time from deorbit to EI than you ever had before [14:58:10] you did all the things I needed to know about, fly the mission through SPS-7 with the new targeting [15:00:15] Ill be off to work soon, and will probably be able to actually fly the re-entry on Wednesday [15:00:45] But in the mean time, here is the scenario for the last final orbit before re-entry if you want to analyze it. [15:01:20] https://www.dropbox.com/s/oa7d33u9os4ugic/Apollo%209%20MCC%20-%20Final%20Orbit.scn?dl=0 [15:01:48] thanks [15:15:20] gotta go! cya [18:25:26] morning! [18:28:06] hey [18:31:03] what's up? [18:32:08] not much [18:32:17] listened to the RETRO loop through TLI [18:32:30] worked a bit more on descent abort constants calculations for Apollo 12 and later [18:34:23] anything new entertaining on the loop? [18:35:03] no, not really [18:35:11] and I'm sure it will quiet down after TLI [18:35:19] just a few aborts to calculate [18:35:29] might be interesting again in lunar orbit [18:35:50] might rather listen to the FIDO or GUIDO loop after TLI [18:36:24] midcourse planning, rendezvous planning, there should be a bunch of interesting things hidden in the hours of audio files [18:38:11] RETRO loop got especially interesting when the RETRO had to explain something to a clueless support crew member [18:38:49] hahaha [18:39:26] he was confused that the solution for a abort maneuver was way off from the Maneuver PAD the crew got [18:39:43] but the Maneuver PAD is based on a calculation taking into account the state vector loaded in the CMC [18:39:51] not the current best estimate on the ground [18:40:18] that kind of thing is always interesting to hear for me [18:41:25] oh huh [18:41:28] that is really interesting [18:45:06] oh and I sent Fabrizio an Apollo 9 CMC core file yesterday, seems like that contains most of what he needs for any CSM simulation [18:45:50] nice :D [18:45:59] and a pre PDI scenario of ours will probably cover anything you would need for the LM [18:46:38] trying to come up with an LGC state in a manual way that even just passes the P63 ignition algorithm would be a terrible, terrible nightmare [18:46:48] hahahaha [18:47:06] everything has to be right for that [18:47:14] state vectors, REFSMMAT, padload etc etc [18:47:58] that's how they would have to have done it for simulations back at MIT though, right? [18:48:38] and MSC [18:48:58] I mean the MIT guys probably knew the minimum amount of stuff to load [18:49:25] we should have that in the descent simulations from Don [18:50:15] there are MSC documents for every mission with simulation reset points [18:50:26] so for those they probably had the state of the AGC stored [18:51:12] aha, right [18:52:10] I really rather fly a whole mission to a specific point thna having to edit octals [19:13:01] I made good progress on the capacitor census yesterday [19:13:10] I've got all of them listed (197 total) and pictures for 104 of them [19:13:13] https://docs.google.com/spreadsheets/d/1XpuFQBrmuI2mqqyh7KQ9qGyxF0GUPSIrTFw18fx0g0M/edit?usp=sharing [19:14:44] that's a lot of pictures [20:00:21] Apollo 12 AGS abort constants agree beautifully with the RTCC MFD calculated ones [20:00:41] have to convert the PGNS ones to octals to see if the one from the Apollo 12 digital simulation are also close [20:01:06] but they are based on the same calculation, so I expect good things [20:01:52] the way the abort constants works is one of the things the LGC stole, I mean copied from the AGS :D [20:03:52] haha oh really? [20:04:00] I didn't know they took anything from the AGS [20:04:56] Apollo 11 LGC had two overcomplicated polynomials for the insertion horizontal velocity [20:05:16] one for direct ascent state abort, one for taking the descent stage back up as long as possible [20:05:37] but FP6 had a fairly simple scheme that then was used from Luminary116 on [20:05:56] but Luminary had to be better than the AGS of course, so they implemented a two segment scheme [20:06:01] for two different rendezvous profiles [20:06:07] the early and late aborts [20:06:36] so on Apollo 12 the LGC already supported that, but FP6 was flown again [20:06:49] so they had a chart for a tweak maneuver, bit messy [20:07:03] from FP7 on to the end of the program LGC and AGS basically used the same scheme [20:07:14] which indeed originated in the AGS [20:07:26] neat [20:07:43] Luminary069 was even worse in some ways, had a fixed horizontal velocity for early aborts and another one for late aborts [20:07:51] I've tried it, works well [20:08:09] just probably super bad procedure wise [20:08:30] and hardcoded, so nothing to calculate for me [20:08:46] for supporting Apollo 11 vs. 12 vs. 13 is already annoying for me [20:08:50] but* [20:09:09] because they all had major changes with the descent abort stuff [20:09:27] 13 to 17 should be all the same from the LGC and AGS point of view [20:11:24] I just never figured out the LR issues with Luminary069, other than that we could probably do landings with it [20:12:02] LGC doesn't like any of the LR measurements in L069 [20:15:18] but then again, why would you want to land on the Moon with Luminary069 [20:15:39] it's 30 revisions short of the fairly buggy version flown on Apollo 11 :D [20:17:24] hehehehe [20:18:03] you said 116 was the first really good one, right? [20:18:23] 116 has fixed a lot of buggines to do with the LR [20:18:33] as you know we have to reset a flag in Luminary099 [20:18:39] because the LR test messes it up [20:18:53] yeah, 116 is a good one [20:19:54] if you read the Luminary memos between 99 and 116 then lots of them have to do with the LR [20:20:39] and of course the simple and elegant descent abort scheme [20:23:21] Luminary210 is still my preferred version [20:26:39] about the capacitors, do you "only" have photos of 104 of them or have you just not added the rest? [20:30:33] I haven't added the rest [20:30:43] there's only one I won't be able to include pictures of [20:30:56] I only realized it was there last night and am now afraid of it :P [20:31:52] lol [20:32:06] you took a lot of pictures at Spacefest then, haha [20:32:21] yeah, I took multiple pictures of the front and back of every single module [20:32:34] but I guess if you want to power this thing up without breaking it, then you better put in this effort... [20:32:38] yup [20:32:45] this one capacitor I'm afraid of... [20:32:58] it turns out there is one tantalum capacitor in the oscillator module after all [20:33:11] and I'm pretty sure that one is potted, so there's no testing or replacing it [20:33:50] luckily it's the exact same type as the one used almost 100 times in the interface modules, so we can get a really good sample size to figure out its likelihood of working [20:34:17] yeah [20:34:29] let's hope it's more than 50%, lol [20:34:33] seriously [20:35:07] the god of retro computing wouldn't let an AGC break like that, no way [20:35:37] just have faith and spare capacitors (for the ones you can replace) [20:36:09] that's the plan :D [20:40:03] hmm, I have to test some Apollo 12 aborts, but I trust my abort constants calculated with the RTCC MFD more than the one in the digital simulation [20:40:11] the switchover point is suspect [20:41:12] the Apollo 12 AGS tweak burn chart (for late abort) starts with the same phasing angle as the switchover point [20:41:24] 7 vs. 19° is a big difference [20:42:26] ah [20:42:36] it's the phase angle at the abort, not insertion [20:42:54] thanks for not giving me that information MSC document! [20:45:39] hehehe [20:45:54] "propagate CSM vector to t_ins and calculate phase angle" is super misleading [20:46:11] but then I also had to fix what is probably a typo in that document [21:02:22] good night! [16:49:10] morning! [16:56:14] hey [16:58:33] what's up? [16:59:46] oh not much [17:01:06] sounds like something somebody with a lot up would say :D [17:02:33] not much in NASSP land, haha [17:03:01] what about you? [17:03:33] a couple things [17:03:42] second volume of block 1 schematics is done scanning and is undergoing processing [17:04:09] great [17:04:52] also somebody else that owns an AGC also has cables, and might be willing to lend them to us [17:05:16] another AGC? [17:05:25] yeah [17:05:31] don't know anything about this one yet [17:05:48] it better has Skylark ropes :D [17:06:08] haha, sorry about raising your hopes there :P [17:06:24] it's unlikely, because I think this AGC is more likely another of the original 15 [17:08:42] but who knows :D [17:08:58] I also learned that all of the later AGCs were made with not just magnesium... but thoriated magnesium [17:09:04] so they're radioactive [17:09:13] which might be why they liked using the aluminum ones in the simulators :P [17:09:22] makes sense, yeah [17:09:56] I worked a bit more on abort constants today. Part of that is a simulated powered descent. And using values from padloads can be really frustrating. [17:10:10] the padload has the right numbers loaded as a negative value [17:10:10] oh yeah? [17:10:15] heh [17:10:25] simply for LGC internal calculation simplification or so [17:10:55] so I was using the wrong numbers for the ignition algorithm the whole time [17:11:01] yeah, probably made it easier to CCS or something [17:11:05] oh wow [17:11:14] well, three of them [17:11:30] and only for the PDI PAD and descent abort constants calculation of course [17:11:57] and the target jerk also has an annoying 8.0x factor [17:12:10] but now the numbers seem quite good [17:12:18] nice [17:12:19] predicted PDI TIG within a second [17:12:24] :D [17:13:09] every mission flew different descent targets, which I thought I had to compensate for [17:13:25] but it was just the wrong sign on some of the padloaded parameters that were off [17:14:11] so just another day in working with the Virtual AGC, getting tricked by scaling and signs [17:15:39] hehehe [17:15:45] all Dons fault [17:16:05] you should send him an angry email :D [17:17:16] nah, I'm sure it all had its purpose [17:18:19] sometimes the source code is helpful [17:18:25] in the comments [17:18:43] it has "as publish" (in the GSOP) versus "as programmed" [17:18:46] published* [17:20:05] and of course the padload document has values for the "as programmed" variant [17:20:53] as a "scholar" of GSOP documents and not so much of AGC source code that tends to confuse me [17:20:56] oh that is nice [17:20:59] haha [17:27:08] oh also, I got all of the Tray B capacitors added to my spreadsheet yesterday [17:27:13] so only the power supplies remain [17:27:30] and the construction of those is super complicated so I think I'm going to need to generate full as-built schematics to find all of them [17:28:22] also I got in a capacitor health checking tool, and some representative ~1965 tantalum capacitors I have passed with flying colors, so I'm feeling pretty good about all of this :D [17:32:35] you just randomly had capacitors from 1965 of course :D [17:32:46] haha of course :D [17:33:05] broke up an AEA for it probably [17:33:13] yeah, who needs the rest of the AEA [17:33:34] nah, I got them from Jimmie for this purpose; they're in a radiation, inc. logic module that has three of these capacitors in it [17:34:08] although speaking of AEA..... if, hypothetically, we had access to a real AEA, is there anything useful we could do with it / get out of it? [17:35:16] a flight program? [17:35:38] that would be really hard to do without any schematics or anything :D [17:35:45] true [17:48:00] also I need to find a geiger counter, apparently :P [17:49:12] Jimmie's AGC is aluminum... but its Tray A cover looks like it is from a magnesium AGC [17:58:15] can't have a real Apollo experience without some deep space radiation [18:17:26] I'm gonna give the box a quick reboot (it needs a new kernel feature). Shouldn't take longer than 3 minutes. [18:17:29] .stoplogging [18:17:31] Log ended by Thymo, total logging length 785424 seconds [18:17:32] .endlogging