[23:08:16] NASSP Logging has been started by thewonderidiot [23:08:20] GuenterWendt! [15:24:50] hello [15:46:30] I had a crazy idea I was thinking about last night. do you think the CSM+LM would have enough DV for a polar orbit, lunar-orbit-only mission? [15:53:44] by which I mean, using DPS and SPS for maneuvers [15:54:43] hey [15:55:05] yeah probably [15:55:18] I would do a three step LOI and TEI for that [15:55:30] LOI-1 with a higher apolune than usual [15:55:37] LOI-2 as a plane change at apolune [15:55:45] LOI-3 for circularization [15:56:03] would be the most efficient way to do it [15:56:36] they would do a similar LOI-1 if they had to do it with the DPS [15:56:51] not sure I ever saw a definitive apolune height for that kind of a maneuver [16:00:01] morning! [16:04:29] hey Mike. [16:04:45] indy91, well I may give it a try. [16:04:52] hey [16:05:19] there might be some parts of the AGC that don't like polar orbits [16:05:44] but I don't think anything important will break [16:06:33] I would use at least a 1000NM apolune for DV savings [16:06:49] but non-spherical gravity can become tricky if you go much higher [16:07:29] if you go really high and slow then Earth and Moon are both pulling and you and the sun says "I'm pushing from the side", making your orbit impact the Moon [16:07:38] on you* [16:08:05] that can happen in some LOI and TEI abort cases, where you need another burn just to not impact [16:09:34] not sure how useful it is, this is a Bellcomm memo I was reading when I was considering flying to Tycho crater with a three impulse LOI: https://web.archive.org/web/20100520034726/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19790072409_1979072409.pdf [16:13:31] in terms of targeting, LOI-1 and 3 would be easy, LOI processor, coplanar solution. All plane change done with the LOI-2 at apolune. [16:16:04] hmm, well maybe LOI processor for LOI-3. If it's circular better LDPP, like a normal LOI-2. [16:25:29] Hi! [16:26:43] I'm on the LGC Clock Sync and TEPHEM update, i'm required to input the dT into the LM's DSKY, is this just mission time? [16:27:54] V55 is a time increment [16:28:27] where do we have the correct procedure for this... [16:29:59] so for Verb 55 we have a special button in the PAMFD that presses the ENTR key on the DSKY in the LM and also the CSM at the same time [16:30:23] before you do that, have V16 N36 on both DSKYs, which will show the mission time [16:30:57] and then you can take the difference between the two times and input it as the DT for V55 [16:31:16] or no, V06 N65 not V16 N36 [16:31:26] like in the activation checklist [16:33:32] before or all that you will already have done the V25 N36, initializing the LGC clock to close to the correct time already [16:33:46] Yeah i've done that part. [16:36:45] PAMFD, LGC page, ENT button [16:36:56] that causes an ENTR press on both LM DSKY and CSM DSKY at the same time [16:37:10] which is like the procedure where two astronauts do that [16:37:26] you just have to have the V06 N65 ready, so that the ENTR press shows the time [16:37:33] on both DSKYs [16:38:20] and then V55 DT = CSM N65 - LM N65 [16:39:08] Yeah that's done. LM's Seconds = +01258 CM's = +01313 [16:39:48] ah ok [16:40:12] so you need a 55 centisecond increment for the LGC [16:40:27] V55E +00000E +00000E +00055E [16:42:31] and then repeat the procedure with N65 again to see that the times in CMC and LGC are identical [16:43:01] Now I have to input the TEPHEM after a V25 N01 [16:43:11] there could be a 1 centisecond difference, I wouldn't bother trying to fix that :D [16:43:23] XD [16:43:35] PAMFD shows the TEPHEM from the CMC. You want to copy that over. You can also look in the CM DSKY [16:43:52] that would be the same as "verify TEPHEM" [16:43:57] V05 N01E, 1706E [16:43:59] in the CM [16:46:33] Done! Thanks :D [16:46:50] It's been awhile since i've touched the LM. [16:47:15] no problem [16:47:25] are you following with the Apollo 15 activation checklist? [16:47:54] almost the whole Apollo 15 flight data file can be found online here: https://readux.ecds.emory.edu/collections/emory-control:LSDI-Apollo15/ [16:58:51] Those versions of the checklists are incredibly useful. [16:58:57] Wow! [16:59:14] There's some weight differences for DAP Load. [17:00:03] RTCC MFD has a DAP PAD under Utilities. I think for Apollo 12 and later we don't have the weights fine tuned yet [17:02:42] or under PADs probably, not Utilities :D [17:03:03] Is a Landing site refsmmat for the LM a Landing Site Vector Update? [17:03:15] Doing MSFN Uplink [17:03:19] '=D [17:04:03] No the REFSMMAT is a matrix, landing site vector is the position of the landing site [17:04:30] so Utilities, REFSMMAT [17:05:24] Gotcha, so I press upload and i'm given a bunch of options. [17:05:59] On the REFSMMAT page or the uplink page? [17:06:44] In Utilities REFSMMAT? [17:06:47] ah [17:06:56] Nvm [17:06:57] Ignore me [17:07:00] you want the option Landing Site there [17:07:19] the time it gives should be close to the landing time, usually no change needed [17:07:36] Desired REFSMMAT? [17:07:42] nope, not in this case [17:07:49] Okay so actual. [17:07:52] yep [17:08:05] LGC doesn't have a REFSMMAT yet and the alignment is done by docked alignment technique [17:08:42] it's almost always desired REFSMMAT and then a P52 option 1, this is an exception [17:09:27] although on Apollo 15 I believe there is a docked P52 [17:09:46] but doesn't matter for the REFSMMAT [17:10:08] Yeah docked P52. [17:11:08] if you have flown the LM before, P52 and P57 in Luminary 1E are quite different [17:15:06] When I input the Gimbal Angles, am I supposed to press enter or pro? [17:15:15] Neither one does anything. [17:15:34] And V40 N20 gives me a 210 Alarm. [17:16:23] Nevermind. [17:16:27] It's Verb 41. [17:17:03] yeah V41 first, enter gimbal angles [17:17:09] V40 N0E has nothing to enter [17:18:12] Am I looking at V42 for Gimbal Angles? [17:18:21] or the LM O/I/M [17:18:52] "LM O/I/M" [17:19:04] V42 is an angle increment [17:19:07] like V55 for time [17:19:22] right, I wanted to make the PAMFD clearer there [17:21:00] I include a plus before those values in the DSKY too? [17:22:58] yeah [17:23:07] always a plus or minus unless it is octal [17:23:12] the TEPHEM was octal [17:24:13] Got a 211 during the torque. [17:25:34] "Coarse Align Error > 2°" [17:26:10] I hope it's not the same issue as we got on Apollo 9, got some 211s there and couldn't figure out the cause [17:26:24] G&N Dictionary says "Reduce S/C Drift and continue" [17:26:35] not sure if that is helping you much haha [17:26:53] hmm yeah. [17:27:00] I don't think i'm doing anything wrong? [17:27:10] I can see the values changing constantly. [17:27:12] probably not, although I can't remember getting that alarm [17:27:21] CSM in is attitude hold? [17:27:53] even in att hold the angles will always change a bit [17:28:02] Yeah Min Deadband Att hold. [17:28:10] Did it again and got the same alarm [17:29:15] probably unrelated did you work with the Apollo 15 Activation Checklist the whole time? Or did you use the 12 one for some parts [17:30:36] I used a mix of the NASSP Checklists on the MFD and the 15 one. [17:31:20] oh, didn't know our generic MFD checklist convered everything [17:31:49] It covered some things but I had to go to the activation checklists for 15 for some parts. [17:32:25] don't think that could screwed up your LGC so far [17:33:07] you can probably simply continue [17:33:18] V42 will fix the remaining IMU error later [17:35:07] hmm [17:35:22] is there even a V42? The P52 comes next [17:35:29] Then the P52 has to fix the errors Ö:D [17:35:30] :D [17:37:02] Should I just reload and skip the V41 N20? [17:37:15] The NO ATT Light just sticks on. [17:38:48] can't skip the V41 [17:39:12] V40 N20 afterwards makes the NO ATT light go off [17:39:42] Gotcha. [17:39:51] without the V41 your IMU has no attitude at all [17:40:06] Thanks for guiding me through this, its weird doing 15 because of the differences in software and mission profile. [17:40:11] It's been fun so far though. [17:40:45] no problem. NASSP doesn't fully support Apollo 12+ with checklists etc., so a bit of guiding will always be required [17:41:00] Verb 40 Noun 20 gives me the same program alarm [17:41:11] Yeah! ;D [17:41:14] :D [17:41:15] 210 or 211? [17:41:19] 210 [17:41:22] oh [17:41:32] but 211 during the V41? [17:41:49] Let me reload and i'll get back to you. [17:41:52] 210 is "IMU off when should be oN" [17:42:30] so either the IMU is still off (CB not in) or some input bit to the LGC is not set, making the LGC think it's not on [17:42:58] IMU STBY is in. [17:43:29] that's a heater [17:43:34] IMU OPR [17:44:09] IMU OPR Also [17:44:10] checklist has that one pushed in just after activating the LGC [17:44:20] Both are in. [17:44:32] that's really strange, how can there be a 210 alarm if the IMU is on... [17:45:11] So I get a 211 on the N41 V20 [17:45:18] V41 N20 [17:45:20] * [17:45:45] And a 210 on 05 09 [17:47:10] maybe I need to take a look at the scenario, if there is a bug... [17:47:28] I can pop the scn file if needed. [17:47:35] yeah, might be good [17:47:40] Anyway I could do that on IRC? [17:47:45] I'm too used to discord haha. [17:48:21] in fact i can just upload it [17:49:05] hmm, don't think so. I usually put it on Google Drive, others put it on Dropbox [17:49:16] hmm [17:49:27] although in my IRC client if I right click on you I have a "send file" button [17:49:28] https://drive.google.com/file/d/1QdJSUDFnkYpuKHl3ONoM8a3tP5gL-Gmg/view?usp=sharing [17:49:44] don't have access [17:49:55] try now [17:50:08] that worked [17:51:55] oh you get the alarm before you can even enter angles [17:55:02] hmm [17:55:14] is it possible that you gave power to the IMU first? [17:55:18] and LGC later? [17:55:41] oh and ignore that about the alarm, I think I confused V40 and 41 like you :D [17:56:46] IMU doesn't move at all with V41 [17:57:34] I think I may have given power to the IMU First. [17:57:40] I think what could have happened is this. You turned on the IMU first. That tries to set an input bit in the LGC, but LGC was still off, so it wasn't allowed to set the bit. [17:57:41] I'm not totally sure on that one. [17:58:00] Then you switch on the LGC, but the IMU doesn't persistently try to set the input bit. Only when the IMU gets turned on. [17:58:10] Which is basically a bug. One we had a few times in different places. [17:58:25] The G&N Dictionary suggested solution will work for you then. [17:58:40] Cycle the IMU OPR breaker, wait until NO ATT light is off and try V41 again [17:59:41] and we need to change the logic for the input bits, so that it works even if you close the breakers in the wrong order [18:01:45] yes that works [18:01:53] the IMU is on, but LGC thinks it's off [18:01:59] cycling the breaker fixes that [18:05:03] hey [18:05:12] Hi Alex. [18:05:18] Yeah I think that worked. [18:05:22] No alarms. [18:05:43] Just did my V40 N20 [18:05:45] Smooth! [18:06:23] hey Alex [18:12:20] Ah bloody hell. Got a 1520 now. [18:12:51] This was after SET REFSMFLG [18:13:06] V37 N51E [18:13:52] you mean "V37E 51E" [18:14:04] Yeah. [18:14:15] After doing that I get a 1520. [18:14:43] you did the V40 N20E? And waited until the NO ATT light was off [18:15:06] Yep! [18:15:20] 1520 is "V37 Not Presently Allowed. Reselect V37" [18:16:00] just try again I would say [18:16:19] the V37E 51E [18:19:17] Its during the bit set check. [18:20:40] During the V01 N01 77E [18:20:54] hmm? [18:20:59] what is then [18:21:02] If I input the V37E 51E during that it doesn't allow it. [18:21:14] that's weird [18:22:05] not sure how a V01 N01 could disable V37... [18:26:04] I didn't get the 1520 alarm [18:26:16] maybe you need to wait more after the V40 [18:26:21] the NO DAP light goes out at some point [18:26:28] maybe you can't do V37E before that [18:33:02] I have no lights on during this process. [18:34:42] Yep i tried it again. [18:34:43] Same problem. [18:35:35] I tried your scenario, didn't get the alarm [18:35:48] https://drive.google.com/file/d/1vFj_sGrpAedOLOND9VRQW94P0I8okrzE/view?usp=sharing [18:37:00] COMP ACTY light is on [18:37:12] probably has to do with that [18:38:21] I don't think it's doing good thinks [18:38:23] things* [18:39:15] the LGC has a bad CSM state vector [18:40:03] it does orbital integration far into the future, that's why the COMP ACTY light is on. And probably also why no V37 is allowed [18:40:04] ah... [18:40:24] what did you uplink? [18:40:38] both of them? [18:40:44] or one of the state vectors and then V66 [18:42:31] but you definitely need to do V96 to stop the integration and then uplink a new CSM state vector [18:42:44] I uplinked a REFSMMAT to the LM before all of this. [18:42:53] I did a State Vector then 66 [18:42:57] Per checklist [18:43:18] hmm [18:43:31] should have been good enough [18:44:17] Anyway to resolve this? [18:45:40] if the LM state vector is good then V96 to stop the integration and then V66 [18:46:02] the time tag of the CSM state vector in the scenario is still like before launch [18:48:08] really? [18:48:15] huh [18:48:35] yeah looks completely empty for the CSM state vector [18:48:46] X) >.< [18:48:50] either it didn't take the V66 somehow or you reverted to an earlier scenario or something [18:48:59] I've updated the state vector many times [18:49:02] and done a v66 [18:49:08] in the CSM [18:49:34] was the COMP ACTY light on when you did the V66? [18:50:12] probably not something one would remember haha [18:50:18] Yeah I have no clue. [18:50:52] in the padload the CSM and LM state vector time tags are set to the highest time possible [18:51:05] so that it thinks the SV is far in the future and doesn't need to be updated (yet) [18:52:27] whenever the COMP ACTY is on 100% of the time you can be sure it's doing orbital integration. And the AGC isn't very useful for anything else during that time. [18:53:10] so maybe it just didn't take the V66 or so. Weird, I kind of would expect there to be a program alarm or so, like the 210 for the IMU [18:53:47] Yeah i'm really confused honestly. [18:53:54] I thought the state vector would have been fine. [18:54:21] I updated the CSM State Vector. [18:54:29] And did v66 [18:54:34] And now I can do the P51 [18:55:32] the two seconds of P51 yeah haha [18:55:48] I think you only start P51 there because it conveniently sets some flags [18:56:45] HAHAHA [18:56:47] oh dear [18:56:57] I don't even know whats even happened. [19:00:10] So the problem is the state vector is what was set at launch? [19:00:14] For the CSM? [19:01:00] I don't know what the problem was. I just know that the CSM state vector was still like before launch. [19:01:20] So no CSM state vector was uplinked and no V66 was done (or at least not successfully) [19:02:21] I absolutely did a State Vector update many times and V66. [19:02:28] So something has for sure happened. [19:04:50] maybe it started orbital integration right after the LM state vector uplink [19:04:56] and then it didn't take the V66 [19:05:20] so something a bit LGC specific as the state vectors are still empty before LM activation [19:07:29] something like that happened on Apollo 11, too, and the flight controller then uplinked a V96 himself [19:08:08] Ahh [19:08:37] I don't know why they didn't change procedures after that haha [19:08:57] 098:56:00: Wrong order of uplinks, V96 needed. LM vector first, tried to integrate to 745h. [19:09:04] 098:56:50: Uplinking V66E. [19:09:12] my notes from listening to the GUIDO audio [19:09:32] 745h is the time tag of the state vectors at launch [19:11:07] 098:56:06 Duke: Eagle, Houston. On our load - during our load, we had to do a Verb 96 to stop integration. We're going to start over again on this load. Over. [19:11:54] I guess if you see this in the future (COMP ACTY light after uplinking that initial LM state vector) do a V96 and then the V66. [19:12:04] but the Apollo 11 crew probably didn't know about this either [19:12:30] Do i do the V96 in the LM? [19:12:36] yes [19:12:43] And then do the State Vector and 66 in the CSM. [19:12:59] only V96, wait until COMP ACTY light is out, and then V66 [19:13:01] I think that is enough [19:13:07] in your scenario [19:13:59] and then you can continue with P51 [19:14:27] V96 is killing orbital integration, so usually not good to do. But the right solution for this case. [19:14:43] only because it tries to do orbital integration to 700 hours GET :D [19:14:53] that would take a while haha [19:16:49] That fixed it. [19:17:06] Thank you so much. [19:17:46] found the discussion on 11, starting with flight controllers being annoyed about the astronauts typing on the DSKY before the uplink is 100% done: https://apolloinrealtime.org/11/?t=098:54:40&ch=22 [19:18:05] and then a discussion about V96 and 66 [19:18:39] I hope Ben Fiest and the other's can get the rest of the Apollo missions done. [19:18:47] For Real Time. [19:18:50] it would be a great help for me [19:18:59] although I still have so much to work through with 11 and 13 [19:19:05] I usually listen along while I do NASSP. [19:19:54] I can get so much information from the FIDO, GUDIO and RETRO audio, but it's a lot of hours [19:21:24] It fixed it for P51. [19:21:29] But once I do p52. [19:21:35] It shows the 1520 again [19:33:25] COMP ACTY light on permanently? [19:36:42] the few times I have gotten 1520 alarms I was just too impatient [19:37:03] and didn't let the computer what it was doing [19:37:07] finish what* [19:37:37] of course with the state vector problem that would take forever, but I kind of doubt it's that same issue again [19:47:53] It turns straight off after the V96. [19:47:56] Then I do a V66 [19:48:39] V37 51E goes fine. [19:48:46] And on the P52 it just errors again. [19:50:28] scenario #3? [19:50:29] :D [20:01:06] by that I mean I need another scenario from you haha [20:09:03] https://drive.google.com/file/d/1pN6GBMg-tnXmlVX4UG3d9OmLSZpBMxlN/view?usp=sharing [20:09:16] Sorry for the wait, just making tea. [20:10:14] no problem, just wasn't sure I properly communicated what I wanted [20:12:09] still has a bad CSM state vector [20:13:06] so after V37E 51E PRO V37E 00E it is stuck on COMP ACTY [20:13:20] and doesn't let you do anything, hence the 1520 alarm [20:13:47] don't be surprised about 1520 alarms if the COMP ACTY light is on 100% of the time, I just wouldn't do any DSKY inputs while that is the case [20:14:09] of course this scenario still has the CSM state vector problem, normally the COMP ACTY would stop quickyl [20:14:56] you probably reverted to an earlier scenario and forgot to do the V66 again or so [20:15:32] yeah [20:15:33] EMEM1570 37777 [20:15:34] EMEM1571 37777 [20:15:39] and EMEM 1572 to 1626 are 0 [20:15:47] so no CSM state vector at all [20:17:40] On the RTCC the state vector uplink is 00 correct [20:17:46] CSM Navigation update> [20:17:52] ? [20:17:53] for the CMC yes [20:18:04] there are four uplinks [20:18:10] state vector uplink types [20:18:37] all that was missing is the V66 [20:21:18] Is it normal for the light to come on again after the V37 51E? [20:21:33] I did the V96 + V66 [20:21:44] for a short time maybe [20:22:05] if it's stuck on it could be bad [20:22:38] Yeah its stuck on. [20:22:43] Even after waiting for 5 mins. [20:22:47] did you wait until V96 was done? [20:22:58] Absolutely. [20:23:01] before doing the V66 [20:23:05] Yes. [20:23:14] 100% [20:23:19] then guide me through the inputs you are doing, I'm seeing a scenario that clearly never had a V66 haha [20:23:39] which scenario should I try, the most recent one? [20:24:04] That scenario is before I do the V96 and 66 [20:24:10] ok [20:24:21] well when I load the scenario the light isn't stuck on yet [20:24:25] so no V96 necessary [20:24:50] oh I can teach you something so that you can also check this [20:24:54] RTCC MFD [20:25:01] MCC Displays [20:25:15] display 1591 [20:25:19] Vector Panel Summary [20:25:27] and there the TLM button [20:25:40] that downlinks all the state vectors in the current vehicle to the RTCC [20:25:48] in this case from LGC and AGS [20:26:07] some time tags will appear [20:26:12] in GMT actually, not GET [20:26:34] and the LGC CSM state vector then has a time tag of 759:13:14 [20:27:05] I do V66E on the DSKY, TLM button again and the time tag is the same as for the LGC LM state vector [20:28:24] and then I do the procedure with P51 [20:28:30] and the COMP ACTY light is on [20:28:35] for 10 seconds or so [20:29:15] actually another trick, V16 N38. That shows you the clock time of the currently being integrated state vectors. Starts at a time before "now" and when it reaches "now" the COMP ACTY light goes out [20:29:40] oh [20:29:52] and then I do V37E 52E and I get a program alarm haha [20:29:58] 220 [20:30:13] ah [20:30:54] I think the scenario name "After Bit Set" isn't correct [20:31:28] because that wasn't done yet [20:37:13] https://drive.google.com/file/d/17s5778mqc_dpyOq0_MAA8EnoqL8dc_fJ/view?usp=sharing [20:37:16] Yeah there's another [20:37:53] This is during the P51 [20:39:40] this scenario did not have the V66 done successfully [20:39:51] hmm. [20:39:58] I think you are getting your scenarios confused, which one you loaded, which one you did what fix in [20:40:24] This one is new. [20:40:45] this scenario is in P51 [20:41:03] I'm not seeing a program alarm or so [20:41:54] did you clear it already? [20:42:09] Yeah. [20:42:12] So this is during P51. [20:42:16] yeah [20:42:17] Everything is going well during this. [20:42:25] V66 hasn't been done [20:42:42] I absolutely did it during this scenario. [20:42:58] I'm typing V66 inside the CSM. [20:43:04] uhhhhhh [20:43:06] To transfer the state vector. [20:43:09] nooo [20:43:18] ? [20:43:35] the Command Module Computer (CMC) has a state vector for the CSM and a state vector for the LM [20:43:51] the LGC also has those two state vectors [20:44:20] a V66 always transfers a state vector internally inside a computer [20:44:29] it doesn't transfer it from CMC to LGC or back [20:44:40] So I should be doing this inside the LM? [20:44:44] yes [20:44:53] jesus christ lol [20:44:54] hahaha [20:44:56] V66 in the LGC copies the LGC LM state vector to the LGC CSM state vector [20:45:05] so that they are the same [20:45:23] there is no link between CMC and LGC [20:45:52] other than astronauts reading data out of their computer and telling the numbers to the person using the other computer [20:46:00] like with the clock initialization or TEPHEM [20:46:41] Right I gotcha. [20:46:42] in the CMC V66 transfer the CMC CSM state vector to the CMC LM state vector. So it's always "this" vehicle to the "other" vehicle. [20:46:43] haha [20:46:53] but always internally [20:47:09] there is a link between LGC and AGS [20:47:22] you can send a state vector from the LGC to the AGS [20:47:53] and after ascent from the lunar surface mission control downlinks the LGC LM state vector and uplinks it to the CMC as its LM state vector [20:48:16] P52 works properly now. [20:48:20] Ahh okay. [20:48:24] great haha [20:49:25] V66 is a typical procedure while docked. After undocking you never want to do it, as you would erase your own computers knowledge of the other vehicle state vector [20:53:07] Gotcha. [20:53:09] Time to do the P52. [20:54:01] I hope the alignment was ok in this scenario [20:54:13] the docked alignment [20:55:34] Yeah, I can't remember what happens with the docked alignment. [20:55:42] Does the LM need to move during this? [20:56:27] no I don't think so [20:56:32] it uses the spirale [20:56:34] like P57 [20:57:10] star codes in the activation checklist can be used as long as the CSM is in the right attitude [21:00:01] might take a bit of practice to do the docked P52, I remember it being a bit tricky to get good results. [21:08:54] and I'm going to fix that IMU turn on thing. You did something out of order but it's still a bug. [21:12:38] that "IMU operate" input bit is simple at least. Some of the other signals from the IMU are a bit trickier. [21:31:32] Gotcha. [21:54:13] it's not coming home [21:54:43] night! [15:32:04] hey guys [15:40:57] rcflyinghokie, https://www.orbiter-forum.com/threads/lunar-module-p57-explanation.39997/ [15:42:32] morning [15:42:52] I'll answer it :) [15:48:36] cool, figured I'd send up the bat signal for that one. [16:05:05] hey [16:05:40] Hi. [16:14:26] afternoon [16:14:27] what's up? [16:17:25] Just gave a long rundown of a P57 haha [16:17:40] ah yes, I see [16:18:13] :] [16:19:39] Its one of those things though that explaining and doing are vastly different in terms of retention [16:20:47] yeah you can of have to go back and forth. Read about it, try it for a bit, read more about what you did right and wrong, and then just practice [16:20:52] kind of* [16:22:37] exactly [16:23:10] took me a bit for sure to internalize it [16:32:46] I had a moment with P22 like that last night. [17:07:03] morning! [17:13:59] morning mike [17:15:35] what's up? [17:16:34] Doing a Docked P52 at the moment for 15, good bit of fun. [17:17:22] nice :D [17:43:16] hi Mike [17:44:43] indy91, how difficult do the new moment coefficients make low altitude P52s? [17:50:17] worst case scenario is building up 0.2°/s in 4 minutes [17:50:36] that is 90NM altitude and 90° pitched up from local horizontal [17:50:47] that's what Apollo 7 experienced [17:51:01] I'm getting similar numbers [17:51:35] Apollo 7 Mission Report page 5-19 has a nice figure [17:54:48] so in this worst case I would say, it can be annoying for P52 [18:01:42] okay. cool [18:02:47] and for Apollo 9 example, the docked DPS burn attitude that is fully out-of-plane it will also want to go back to in-plane [18:02:52] but that's for the RCS to deal with [18:55:53] well I'm excited to try it [19:09:47] I didnt think about that! [19:10:16] doesnt it burn close to apogee though? [19:10:36] so less effect? [19:18:27] right, could be. The Apollo 9 mission report just says that in that attitude it wants back to in-plane, not specifically during the burn, but they spend a bit of time in that attitude I guess [19:18:43] yeah they do [19:18:56] I don't have moment coeffcients for the LM [19:19:32] but the CSM alone might already pull the CSM+LM around, or at least try to [19:19:55] just enough so that it is noticable [19:20:04] won't give the RCS much more to do [19:20:06] yeah if anything it might be more pronounced without any on the LM [19:21:03] the update will take a while still though, it needs a lot of changes to Apollo 7 and 9 in the RTCC/MCC. I've transitioned to having it more as a long term project, or else I am stuck with only working on this one topic for the next few months. [19:21:30] haha totally understandable [19:21:55] after we finish this move I want to go back and look at the electrical and batteries [19:22:03] still making some changes to MCC rendezvous calculations for Apollo 7. At the moment the MPT doesn't like it if I include an ullage burn for the NSR maneuver, hmm [19:22:26] just using the MPT for testing right now, but I might make the MCC use it [19:22:35] would require less code in the MCC for each maneuver [19:23:12] less code is always good [19:26:48] at some point I ideally only want MED inputs in the MCC [19:27:08] and Orbiter API calls for e.g. state vectors [19:30:50] S-IVB drag was also interesting on this latest attempt to get to the Apollo 7 rendezvous [19:31:02] like the real mission power is lost at about 16h GET [19:31:13] until then it still flies engine forward [19:31:30] but then it starts tumbling, which is a lot draggier [19:31:49] but it's quite random how much drag it actually has [19:32:28] targeting will not become more precise with drag [19:32:38] hopefully the trajectories though [19:33:28] although my main reason for implementing drag is actually based on a wrong assumption. The S-IVB experienced some venting, not bigger than predicted drag, which made the 7 ft/s second phasing maneuver necessary [19:35:39] ah interesting [19:36:21] was it through the engine bell? or elsewhere on the vehicle [19:36:27] they don't know [19:36:53] probably some scheduled venting that should have been non-propulsive [19:37:47] if anything the S-IVB had less drag than predicted because it had attitude control for a lot longer than predicted. Although I am missing one revision of the operational trajectory where they revised the first phasing maneuver due to that [19:38:13] haha its funny how non propulsive vents tend to be propulsive [19:38:32] I think they figure that out on the later missions [19:43:17] the Apollo 13 S-IVB had a DV event when the LVDC died [19:43:39] but it can't have been that on Apollo 7 as the vent happened earlier than loss of power and attitude control [20:08:05] ah great, the NSR maneuver ullage issue in the MPT was a fluke. Random, awesome... [20:22:05] On missions where the S-IVB went into a heliocentric orbit, how long after T&D were the S-IVB's tracked and how long could they have been powered for? [20:25:53] final loss of signal on Apollo 11 was at 11:55:12 GET [20:26:00] probably typical for those missions [20:29:04] after that they wouldn't be able to use the transponder [20:29:18] I can imagine the thermal conditions during the later part of the mission wouldn't be as forgiving with the SLA's gone. [20:29:26] so maybe that's the cutoff time for any tracking state vector, anything else would be extrapolated [20:30:03] on the last few missions they even made the S-IVB do a PTC [20:30:11] we don't simulate that yet [20:30:20] they had a different name for it though [20:30:55] "solar heating avoidance" or so haha [20:32:04] I'm pretty sure on later missions i've seen the inside of the SLA coated with the same mylar on the LM. [20:32:35] they definitely wanted to have functioning systems until lunar impact yeah [20:52:22] does our MCC use tcp for uplinks? [20:57:01] nope [20:57:11] there is extra logic for the MCC [21:00:06] ahh, okay. [21:00:54] I'm still trying to wrap my head around telemetry in NASSP [21:01:26] I think I have the real one figured out [21:02:07] but I want a solution that doesnt absolutely kill performance [21:06:41] right [21:06:45] good night! [15:09:47] hey [15:10:55] hey Matt [15:34:46] found the issue I was having yesterday with the MPT. Something iterates on the argument of periapsis, but it's not very well defined if the eccentricity of the orbit is quite small [15:38:29] ahh, good find. [15:39:00] I have an Apollo 9 document which talks about a MSC internal version of a mission plan table [15:39:15] and it has some logic that the IBM documents didn't mention [15:39:35] if the eccentricity is below X then switch off argument of periapsis as dependent variable [15:41:08] in some other parts of the RTCC small eccentricity is below 0.005 [15:41:16] and my problematic case was just below that [15:41:29] so that's what I chose [15:47:41] I'm interested in implementing some telemetry array classes. from our "RTCC++" perspective, is it more preferable to replicate the bit wise structure of the array (e.g. set some bits in a uint32_t for vehicle type), or do it in a more modern style, (enum vehicle_type) [15:51:46] you can make it modern I think. Whenever I've tried to do something as in the IBM flowcharts it just looks bad and is meant for FORTRAN anyway. [15:52:01] So unless you are doing it in FORTRAN just use the tools C++ gives you [15:53:27] okay, good, that's the direction I was leaning in. [15:53:45] will make debugging easier(possible) [16:03:21] MPT also has a funny issue with Apollo 7. There is only one default value of SPS propellant for all mission right now [16:03:32] and it's larger than the total CSM mass [16:03:42] oh boy [16:03:53] the DV remaining calculation doesn't like that :D [16:06:15] I'm guessing it overestimates a bit [16:06:37] nah it gives NaN [16:07:03] oh, haha [16:07:27] it does a log of a negative number [16:07:33] logarithm [16:08:03] ln(m2/m1) [16:08:25] where m2 < 0 [16:08:34] yeah basically [16:09:13] negative mass after all fuel mass has been burned [16:09:28] so is the MCC, going to start using the MPT? [16:10:36] in a very limited way it already does it! [16:10:39] for TLI [16:10:58] TLI PAD from the MCC is currently more accurate than the TLI PAD in the RTCC MFD [16:11:06] as it uses the TLI simulation [16:11:33] but yes the MPT will be used more often with each MCC update I would imagine [16:12:04] it would help with Apollo 7 and targeting e.g. the NSR burn in the case where NCC-2 is necessary [16:13:49] awesome! [16:15:26] the FIDO audio from that would be quite awesome. A bunch of calculations and decision making just after the NCC-1 maneuver [16:15:35] ok, any audio from Apollo 7 would be awesome... [16:38:06] yes it would [16:38:55] do the apollo in realtime guys have plans to add more, after the archives open? [16:45:01] yes, I think their next project was Apollo 16 [16:45:52] I'm sure they will do all of them given the time. They have the last(?) working machine that can actually read this type of tape, so before that machine breaks in a few years/decades they better put it to use [16:56:25] well I hope they're taking very good care of it. [16:56:35] (I'm sure they are) [16:57:34] the computer soup, ccats, and network controler loops have been my interest lately [16:58:32] morning! [16:58:59] :wq [16:59:19] hey mike [17:03:54] what's up? [17:06:14] hey guys [17:06:32] Thymo, vim commands dont worn on me, haha [17:06:44] *work [17:11:14] hey guys [17:27:56] n7275: :qall! [17:38:26] the auction for Jimmie's AGC is starting in ~22 minutes [17:43:52] It's a shame it's most likely not going to a museum [17:44:41] ehhhh [17:44:45] I dunno [17:44:55] museums are black holes, and if it were in a museum the restoration would have never happened [17:47:02] if it goes to a museum then we lose access to it and its ability to extract programs out of core rope modules =/ [17:47:20] someone tell Elon about the auction [17:47:25] haha [17:49:45] or maybe Steve Jurvetson... [17:50:06] oh Steve knows about it [17:50:31] he brought it up last time we were at his office heh [17:50:50] you never know with these auctions, suddenly you have a Dubai sheikh and your chances are gone [17:51:02] yeah [17:52:17] maybe the auction has some nice photos of checklists or so, that's my main interest in them [18:20:46] hmm, not online yet, but I did find a video [18:20:53] looks like they also have an AP-101S [18:27:44] oop [18:27:45] https://www.sothebys.com/en/buy/auction/2021/space-exploration?locale=en [18:27:46] online now [18:34:48] give it 15 years in auctions and we have the whole Apollo 11 LM Activation Checklist haha [18:36:07] hehehe [20:23:35] https://www.sothebys.com/en/buy/auction/2021/space-exploration/gibeon-meteorite-from-the-iron-core-of-an-asteroid [20:23:42] Current bid: 1USD haha