[19:36:19] NASSP Logging has been started by n7275 [19:36:21] indy91, good news about NTRS, I forgot to mention that I submitted a ticket about the missing documents, they were aware of the issue and were working to resolve it. No purge, thankfully. [19:51:52] ah, great [20:12:49] Yikes some Apollo 7 issues for sure [20:12:58] Just seeing that post [20:16:48] state vector is bad [20:21:41] I wonder if it had to do with the 50x [20:22:14] Maybe translation imparted with all the firing of RCS [20:26:39] this is the same guy that had a whole bunch of issues installing the other day. I'm still not convinced that he did it correctly... [20:28:19] IU state vector is also not great. But it's not "-600 NM perigee" bad at least haha [20:28:52] this is probably a scenario before the 50x time accel [20:29:04] whoa what happened now? [20:29:28] just Radar_Contact on the forum having some Apollo 7 trouble [20:29:44] ah roger [20:30:57] I might be with n7275 on the potentially botched install theory [20:51:25] it would be great if someone was looking at my PR. I have a few smaller updates in the pipeline and not pushing directly is holding me up a bit [20:53:07] I could put up 5 PRs, but sometimes they are incremental so that doesn't really work. [20:53:20] But doing a PR that does 10 different things isn't good either [21:08:37] Ahh didnt see it [21:10:09] that is what we wanted, right? Just make it so no uplink is done with the MCC-6 decision [21:10:33] just a PAD and that only if MCC-6 isn't getting scrubbed [21:11:59] Yeah just a pad at the decision [21:12:15] And if its a go, then an uplink at the next MCC6 part? [21:14:02] yeah for MCC-6 it does the maneuver calculation again [21:14:43] and then [21:14:55] scrubbed: no PAD, but SV and entry target uplink [21:15:15] not scrubbed: PAD and SV and retrofire external DV uplink [21:15:49] so in theory it can happen that the decision says one thing and the actual MCC-6 update says something else. [21:16:06] but only if your trajectory has been perturbed in the mean time [21:16:16] very unlikely unless you do something wrong [21:20:00] Yeah that sounds all correct [21:22:37] great [21:24:05] my Apollo 7 MCC update is ready that does a bit of restructuring. You can take more time to check on that haha, no hurry there [21:25:53] ok what next... Apollo 9 Maneuver PAD. I'll display that a bit differently than the 7 one so that it is closer to the one for Apollo 9 [21:27:04] and for the Apollo 10 TLI overburn, it would be more realistic if I changed all the targeting presettings and let the cutoff bias as it is. But it's not based yet on real presettings anyway, so it's just easier if I keep the targeting as it is and change to the cutoff bias in the LVDC to the actual value, not the biased one [21:36:14] yeah doing that changes a predicted flyby maneuver at the time of MCC-1 from 19.1 ft/s to 6.8 ft/s [21:36:18] so a lot more free return [21:37:33] Oh yeah [21:38:31] won't be exactly zero because of the evasive maneuver not taking out the TLI bias exactly. What we talked about a few days ago. [21:41:08] Right [21:41:23] What does this do to the LOI time compared to the flight plan [21:41:36] Or PC time, more specifically [21:41:54] good question, let me check [21:43:08] MCC-1 would be 58.2 ft/s [21:43:12] flight plan has 57 ft/s [21:43:42] pretty good [21:45:37] LOI-1 TIG 4 minutes off flight plan [21:47:10] if I postpone the midcourse until MCC-2, like the real mission did, it's 14 minutes later than the flight plan [21:47:34] with MCC-1 it was 4 minutes later [21:47:45] so that checks out [21:47:52] What was the actual mission result? [21:48:01] I cannot remember [21:48:19] LOI planned vs actual [21:48:44] 75:45 flight plan [21:49:07] 75:55 actual [21:49:13] Not bad [21:49:57] What about the dV for MCC2 [21:50:03] 61 ft/s [21:50:10] which differs quite a bit from the actual mission I think [21:50:38] ah well, actual was 48.7 [21:50:43] so not too bad [21:51:03] could be TLI errors [21:51:28] but I would expect the DV to grow from MCC-1 [21:51:50] under ideal circumstances, like with the MPT pre TLI [21:52:31] you guys, haha, I wanted you to quickly approve the previous PR because it was very small. This Apollo 7 update could actually use some scrutiny I'll not even merge it yet myself :P [21:54:01] although when I see "Large diffs are not rendered by default" with PRs from others I tend to get lazy and think that I'm sure you guys know what you are doing :D [21:54:52] How do I know what names to use in VESIM? ACA Yaw is hooked up to my throttle.. [21:55:57] oh btw Thymo, before I forget, you got disconnected when I was linking you to an earlier LM AOH Volume 2. Did you still want that? [21:56:39] Oh yes. My server crapped out with disk read errors around 17:30 so I lost everthing between then and about 20:30 [21:57:01] https://de.scribd.com/document/66115251/Apollo-Operations-Handbook-LM-5-and-Subsequent-Vol-II [21:57:12] Awesome thanks [21:57:17] if your questions are about Apollo 9 though I would recommend the G&N Dictionary [21:57:24] there are some relevant differences [21:57:55] I'm not sure about VESIM, I've managed to get it working once with a lot of handholding from ggalfi. Haven't tried it much since. [21:58:00] Yep, I'm also intereseted in the non G&N procedures [21:58:28] signs up for scribd to download a public domain document [21:58:52] yeaaaah [21:58:59] I guess I did the same a few years ago [21:59:01] https://www.ibiblio.org/apollo/Documents/apollo_9_final_dictionary.pdf [21:59:18] I can put it on my google drive. Or I'll just send it to Ron who well get upset that it is only on scribd [21:59:46] I got it. Ron might like to mirror it yeah [22:02:19] Axis can be X,Y,Z,RX,RY,RZ [22:03:32] It's not RX [22:03:36] It was Z initially [22:03:59] Now Yaw is the thumbwheel lol [22:05:09] Yeah it took me a while to go through that honestly [22:05:51] good night! [22:05:55] night! [22:06:09] Night [22:08:48] Aha [22:08:49] RZ [22:09:14] That's the X52 stick twist rudder [22:10:11] This RCS Cold fire checklist is really useful [22:14:49] Hmm no RCS output on TTCA fwd or aft [22:15:58] Oh right [22:16:18] Up down is forward aft and fwd aft is yaw left and right [22:18:01] Haha [22:20:22] All changed about for translation [22:20:34] I remember that when I was using a stick for NASSP [22:48:19] well there [22:48:36] turns out I need a bit more swap... [22:50:55] Hehe IRC got OOM killed? [22:52:39] http://turnoff.us/geek/oom-killer/ [22:53:03] I'm stuck with gcc/g++/fgortran 8.3 prebuilt for the pi, so I decided to rebuild 11.2 "-j4". 800MB is not much to work with, while also running znc, and docker httpd [22:53:42] haha [22:54:08] You should probably just do that in a VM. Pi's are not really built for compiling stuff [22:54:46] Also I have killed many SD cards with swap so beware of that [22:55:48] yeah, I could(should) just target arm and build on my desktop [22:56:33] 24 cores would make quick work of it [22:56:56] If you want to cross compile it is stupid easy to do on Gentoo. You can built pretty much any toolchain you want with a single command. [23:00:46] I'm probably going to spin up my old desktop (Q6600) as a server after I move [13:53:06] Interesting I never noticed the APS firing during SIVB boost, I assumed the engine gimbals would take care of that [15:11:04] Also isnt coming back from P06 supposed to turn on the CMC CW light? [15:40:55] hey [15:42:03] rcflyinghokie1, APS fires for roll control and during coasting phase before S-IVB ignition [15:42:32] P06 is also supposed to cause a restart I think, which it didn't do for me on Apollo 12... [15:43:14] Yeah procedures say it should cause the CMC CW light [15:43:28] And it was firing the APS a bunch after ignition [15:43:49] Maybe for that roll still [15:44:21] there is also a short phase where no thrusters are firing at staging [15:45:32] and the S-IVB ullage rockets cause a small attitude excursion which needs to be corrected [15:48:00] rcflyinghokie1, the first scenario that Radar_Contact posted is at T+38min and that already has the bad state vector [15:48:12] so before the LOX dump [15:48:28] must have been caused by the launch, but I am not getting that issue [15:48:41] I flew his mission all the way to the P52 [15:48:55] Ah I didnt check that one, only the launch scn [15:53:00] he didn't do the V75 early which would be an easy mistake [15:53:13] the IU state vector is also not great, but a lot less bad [15:53:26] than the CMC [15:53:41] so no idea really [15:53:56] Yeah I flew it normally and used 10x in orbit [15:54:05] SV was good as was the P52 [15:55:29] yeah even in his on-orbit scenario the P52 was good once the SV was fixed [15:55:46] I just mean I couldnt replicate the bad SV [15:57:30] me neither [15:57:43] the bad SV is the only issue I think [15:58:04] wonder what would have caused that, I guess the launch itself [15:58:17] Could be tied into the rates issues earlier [16:02:32] maybe [16:13:47] morning! [16:24:42] Good morning [16:29:46] what's up? [16:33:59] Fighting with IT to get 64 bit office on my work computer :P [16:34:10] I get OOM errors with 32 bit because of my data file sizes [16:35:24] hahahaha [16:35:30] oh dear [16:36:58] And sadly I am relegated to use excel for my databases :P [16:37:39] oh lord. thats horrible. [16:46:13] There is no consistency in government databases [16:50:20] indy91 any thoughts on the CMC light after coming out of P00? [16:52:27] Also I wonder if its supposed to be on solid or just flash on and off, I think in the LM, coming out of P06 flashes the LGC light on and off but I don't remember for sure [17:07:51] well the CMC light would be caused by the restart I think [17:08:04] and if we get no restart we get no light [17:08:58] maybe there is something still wrong with standby mode [18:12:00] Hmmm could be [18:12:23] Still also need to figure out why the AGS doesnt throw an alarm when started up a second time [18:13:55] right [18:14:06] I'll go ahead and merge the Apollo 7 MCC update now. Should be good. [18:15:07] next up that Apollo 10 TLI fix, after that the Apollo 9 Maneuver PAD changes [18:15:33] Excellent [18:18:30] and then maybe the battery C charging thing [18:21:07] Ah yes [18:28:24] I think I missed it -- what is the CMC light doing that it shouldn't be? [18:29:03] not being when coming out of standby [18:29:07] not being on* [18:30:08] Yeah I get PROG light but no RESTART, and therefore no CMC CW light [18:30:09] because of no restart I guess [18:30:44] ISS light comes on but no CMC [18:30:55] hmmmm... yeah sounds wrong [18:31:09] I think? [18:33:27] At least looking at procedures [18:36:45] "CMC warning, RESTART, PROG ALARM" [18:40:02] ah but I am also checklists where it says "possible" [18:40:34] Hmm [18:40:58] In a G&C checklist? [18:41:30] yeah, "possible" was my understanding [18:41:45] I need to review the relevant parts of the AGC logic... [18:42:42] AOH Volume 2 [18:42:50] All the G&C P06 procedures dont mention possible [18:43:09] At least looking at 8, 11, and 15 [18:43:37] but even if possible what causes it [18:44:09] that was CSM AOH, LM AOH also says possible [18:44:20] "RESTART lt and/or PROG lt may go on due to LGC startup transients" [18:46:41] wonder what the observed behavior was [18:46:53] considering there is no possible mentioned in the checklists [18:47:21] Get the prog alarm consistently 07777 [18:48:41] Apollo 9 debriefing talks about it [18:48:48] pages 7-18 and 7-19 [18:50:58] https://www.ibiblio.org/apollo/Documents/Memo-Edmonds-1969-10-30_text.pdf [18:51:15] "Information applicable to any PGNCS power down", item 3 [18:51:31] from a memo written in October 1969 [18:52:48] oh [18:52:58] we have a Digital Development memo that goes into exactly why this may or may not occur, with timing diagrams [18:53:00] https://www.ibiblio.org/apollo/Documents/dd_memo_363.pdf [18:54:29] haha great [18:55:14] because of course we aren't the first people to ask about that question :D [18:59:56] so it depends entirely on how long it takes STRT2 to go low, which has a wide spec range and will vary both from AGC to AGC and also over temperature [19:00:19] and virtualagc doesn't simulate to quite that level of detail [19:03:32] right [19:09:17] interesting [19:16:07] So I guess ours not illuminating is a feature not a bug :P [19:16:20] Same idea for the LGC? [19:17:05] yep [19:21:49] yeah, CMC and LGC hardware is identical [19:22:09] Now what about the AGS [19:22:42] What causes the AGS light on the second powerup [19:23:14] the AGS, we know significantly less about. certainly nothing to this level of detail [19:23:47] we need to find the AGS equivalent of Don [19:47:54] preferably someone who has a FP7 listing [19:49:15] hahaha yeah [21:14:42] indy91, what does this Apollo 10 TLI change do? [21:15:29] I bet it changes TLI, probably for Apollo 10 :P [21:18:08] haha [21:18:16] ok, it's a bit difficult [21:18:34] on Apollo 10 and 11 (and probably more) TLI is targeted for free return [21:19:02] but after was trouble on Apollo 8, they added a 19 ft/s evasive maneuver with the SPS to the flight plan [21:19:07] after some* [21:19:27] and they didn't want to or couldn't update the TLI targeting to account for that [21:19:37] at least not the normal targeting parameters [21:20:01] but they could change the cutoff bias, the DV that still occurs after cutoff signal [21:20:10] in the AGC that is a time, but in the LVDC that is a DV [21:20:19] so the actual DV there is about 3.7 m/s [21:20:41] but in the Apollo 11 LVOT that value was changed to 2.35 m/s [21:20:51] so that leads to an overburn at TLI [21:21:00] and then you do the evasive maneuver [21:21:06] and ideally that cancels each other out [21:21:19] for Apollo 10 we have no LVOT [21:21:31] so we don't know the actual LVDC presettings [21:21:53] but I know the procedure is the same as on 11 so I set that cutoff bias to the same values as on Apollo 11 [21:22:19] buuuut now the problem. I used the actual cutoff state vector from Apollo 10 to generate TLI presettings [21:22:25] and that state vector has the overburn in it [21:22:31] the intentional overburn [21:23:12] so previously we basically did the correction to get the overburn twice. Once with the targeting parameters and once with the intentionally wrong cutoff bias DV [21:24:52] the slightly more correct fix for this would have been to re-calculate all the targeting parameters with a bias TLI cutoff state vector. But that would be more work :D [21:25:17] and the fix I actually did of course was to set the cutoff bias to 3.7 m/s [21:25:25] which is close to what we actually get in NASSP [21:25:58] end of story haha [21:30:19] okay, that makes sense I think [21:33:11] if we find an Apollo 10 LVOT then all the numbers will be changed anyway [21:33:17] targeting and cutoff bias [21:58:29] night! [22:35:27] The possibility of restart coming on is known. It not coming on in NASSP is by design, as Mike said the variables that trigger it make it essentially random and since NASSP assumes nominal behavior this never happens. [22:35:48] The program alarm is because your IMU is off and unrelated to standby [14:54:21] good morning [14:57:36] hey [16:11:44] morning! [16:34:50] I have a really odd checklist case here...For some reason, during Apollo 9 CMC/IMU powerup, the auto checklist doesnt seem to press the "7" when it commands V37E00E [16:35:05] I cant replicate it on other missions, only after a long standby [16:35:29] maybe the button is sticky :P [16:36:56] I mean its pressing it, I see the flash hear the click and everything but it wont register as pressed [16:37:11] Works pressing it with the mouse [16:37:18] strange [16:38:46] Feel free to see if it does it for you all https://www.dropbox.com/s/3q3fb5fzvucemnt/Autochecklist%20Stuck%207.scn?dl=0 [16:39:06] will do [16:40:15] Huh [16:40:23] Even if I press it manually its not reading the 7 [16:40:28] On the first press [16:40:37] If I do it again it works [16:41:04] Wonder if its the CMC because its still integrating the SV [16:41:57] yeah same problem here [16:42:28] the first 7 press doesnt register at all [16:42:59] DSKY inputs should have priority [16:43:10] could it be a bug with the actual computer code? [16:43:13] I'm not sure how that can happen [16:43:34] these procedures are still possible on other missions, yeah? [16:43:39] did you give it a try indy91? [16:43:47] will do right now [16:43:54] Yeah I couldnt replicate it elsewhere [16:44:09] But I also did have a long powerdown save from another mission [16:44:13] didnt* [16:45:08] it's not nominally performed but perhaps you could try doing it before a sleep period in another mission and then powerup after the period ends [16:45:32] well its performed on every rest period on 9 [16:45:42] so thats exactly what this case is [16:45:57] right but it's not performed at all in, say, 10 or 11 or onwards, right? [16:46:06] no [16:46:09] hahaha [16:46:16] the button is already pressed when you load the scenario [16:46:23] so pressing it once depresses it [16:46:24] wait what? [16:46:24] ohhhhhhhh [16:46:30] well that would cause it [16:46:34] very odd [16:46:48] maybe you accidentally shift clicked on it before saving the scenario [16:47:02] that I am sure I didnt do lol [16:47:16] how do you put the CMC in standby anyway? [16:47:20] P06 [16:47:27] ah, then nvm [16:47:43] V37E 06E, then press and hold PRO for >=640ms [16:48:11] Ahh the save I was given to troubleshoot has it pressed [16:48:18] ahhhh [16:48:32] Mr. Residuals? [16:48:36] yes [16:48:51] whoops [16:49:16] though in fairness it doesn't make a lot of sense for DSKY keys to be pressed and held via Shift-clicking, right? [16:49:40] I wonder if it could be disabled for them somehow [16:50:22] Still need a hold command though, so I dont know if the shift part could be stopped purely for the DSKY [16:50:35] checklist controller has a hold it can use [16:50:47] that's fair [16:50:50] just a thought [16:51:27] Indeed [16:53:55] thewonderidiot, isn't there some weird computer reset procedure where you need to hold buttons pressed? [16:54:10] like mark reject and some DSKY key or something [16:54:21] yeah something like that [16:55:11] but holding down a regular (non-PRO) DSKY key really can't get you anywhere... the computer logic can't register another keypress until the last key has been released [16:55:47] ah fun [16:55:55] TC LIGHTSET # EXIT TO DOFSTART IF ERROR RESET AND [16:55:56] TC STARTSB2 # MARK REJECT DEPRESSED SIMULTANEOUSLY [16:55:57] CS INTMASK # RESET INTEGRATION BITS [16:56:07] so what if some CMP who thinks he is funny has a button pressed on the LEB DSKY [16:56:22] while CDR and LMP try to use the MDC DSKY? [16:56:41] oh, the LEB DSKY and MDC DSKY have different input channels that operate independently [16:56:45] ah true [16:56:48] so the MDC DSKY would still operate like normal [16:57:04] they share a PRO line though, so he could screw them up that way [16:57:14] GO JAM right? mark reject and reset? [16:58:04] just a fresh start [16:58:18] GOJAM is a hardware thing; the mark reject + reset is a software feature [16:59:13] Then what is GOJAM [17:00:02] "Simultaneously press RSET and MARK REJECT, (GO JAM), V37E 00E" [17:00:47] GOJAM is a wire in the computer that gets set high with any hardware alarm (tc trap, rupt lock, parity, etc.), or by the power supply stability signals. it resets a lot of flip-flops in the computer to a known state, and sets the opcode and stage registers to force a GOJ1 unprogrammed subinstruction to be executed [17:01:06] that checklist was written by somebody who thought they were smart, but didn't know proper AGC terminology :) [17:01:34] Haha Apollo 11's on board ops checklist [17:03:27] to their credit, a GOJAM also causes a fresh start, so the end effect is the same [17:03:33] but "fresh start" was the word they were going for there [17:04:04] actually I think... will need to double check that [17:06:15] I mean its the same procedure in Apollo 15's as well [17:06:41] Almost as if its implying the holding the two buttons is the GO JAM [17:06:58] lol it's definitely not [17:07:05] I can walk through schematics and code with you if you want [17:07:09] but it is 100% the wrong terminology [17:07:31] just because they said the same thing twice doesn't make it right :P [17:10:15] ahh sorry, I must have written that checklist back in the 70s :P [17:10:23] Yeah I wonder why its written that way [17:10:58] same reason they had the later checklists pull the RR breaker for the 1202 problem presumably [17:11:09] slight misunderstandings [17:12:56] would pulling that breaker have actually helped at all? [17:13:25] Funny how nothing gets changed because it was never used I suppose [17:14:55] I would also bet that somebody from MIT saw the problem, realized that they meant almost but not the quite same thing, and couldn't be bothered to do the paperwork to get it changed [17:16:12] I was wondering why I had to pull the RR breaker before PDI in my A12 mission, since I thought that having range/range rate data was important for powered descent guidance somehow [17:17:07] it's not really [17:17:23] they had you pull the breaker because they fundamentally misunderstood the cause of the 1202 issue :) [17:17:45] that will still happen regardless of whether that breaker is in or out, but mission control didn't quite grasp that [17:17:49] range/range rate was only to the CSM [17:18:04] had no impact on PDI, was just a reference in the event an abort was needed [17:18:10] roger, I get that now, just for rendezvous and state vector updating [17:18:39] but yeah in reality they'd need to turn off the CDU to prevent the 1202, or just... use the software fix they already implemented for A12 [17:18:43] RR is important during PDI not for powered descent guidance but if powered descent guidance is failing, so for an abort. Then you are already locked on. [17:18:48] Yeah no RR marking was done until ascent...it caused problems with P63 if marking was used before [17:18:56] oh I see [17:18:58] you could also pull the ATCA breaker [17:19:17] I can't recommend that haha [17:19:22] which one [17:19:36] pulling the ATCA breaker :D [17:19:50] might as well pull all breakers, that also prevents 1202 alarms [17:19:57] hehehe [17:19:59] lol [17:20:00] Yeah, 3 choices [17:20:07] just turn off the computer, ez [17:20:13] ATCA ATCA(PGNS) ATCA(AGS) [17:20:14] one sec, let me consult the schematics [17:20:34] just let the astros fly the descent by hand :P [17:20:45] Well, I have flown it with just AGS :P [17:20:53] daaaaamn [17:21:00] also rcflyinghokie while I'm splitting hairs, technically verb 69 actually really causes a GOJAM, but the G&N checklist just says "cause restart" :P [17:21:02] Landed safely...no idea where [17:21:24] lol [17:21:27] Haha its incredible how many inconsistencies were littered throughout [17:21:44] with thousands of documents it's hard to perfectly fact-check everything [17:22:04] and at least they got the essence right [17:22:05] Just used the AGS for steering and engine control, and landing radar for final approach [17:22:06] especially if you want to be pedantic [17:22:37] I'm pretty sure "being pedantic" is what we do here ;) [17:23:21] easy to now for sure [17:28:48] rcflyinghokie, I'll confirm with the EFDs later, but according to the LM-8 systems handbook, you would need to pull the STAB/CONT ATCA breaker on panel 16 to make the required signal go away [17:29:13] instead of the RR breaker like they have in the checklists [17:30:55] the CB names really aren't that helpful [17:31:23] the ATCA has circuits for AGS and PGNS. So there is a ATCA (PGNS) breaker for PGNS only stuff [17:31:33] and then ATCA (AGS) only for the AGS [17:31:42] and all the rest is covered by the ATCA breaker [17:32:12] what does ATCA stand for? [17:32:41] Attitude and Translation Control Assembly [17:32:44] Attitude and Translation Control Assembly [17:32:45] LMAO [17:32:50] hah! beat you :P [17:32:55] not on my screen! [17:32:57] not on my screen [17:33:02] oh wow [17:33:12] but it shows the same second [17:33:13] oh man that was hilarious [17:33:24] and I knew what it stands for, but I looked it up to be 100% sure haha [17:33:36] didn't want to spread misinformation [17:33:39] like certain checklists [17:33:49] Grumman really really likes to name things assemblies, so the "A" at the end is almost always Assembly [17:33:54] something something something Assembly [17:34:14] oh yes, everything is an assembly in the LM [17:34:52] you really can't land with the ATCA breaker out. [17:35:03] Loss of AGS auto & att hold/rate cmd cont modes [17:35:10] Loss of FDAI rate indication & error ref [17:35:24] Loss of gimbal & throttle capability (DPS start at max thrust) [17:35:41] and some others for the AGS or that aren't super important [17:36:04] and of course: "Loss of RR auto track & slew modes. Loss of slewing power. LGC mode available" [17:36:11]