[17:18:31] NASSP Logging has been started by rcflyinghokie [17:18:33] so just those 3 RTCC values? MCLABN MCLBSN MCLCBN? [17:18:58] yeah, just zero them, they aren't used by the Apollo 9 MCC yet [17:19:06] got it [17:19:21] or maybe... open the RTCC MFD, just once [17:19:30] might also fix it [17:20:02] no CTD after zeroing [17:21:16] good [17:28:14] the AGS does the math differently for the theta calculation [17:28:25] have to put both in MATLAB and compare them [17:52:52] hmm didnt get any SPS gimbal angles from MCC [17:56:25] about 4h4m before the SIVB restart [17:56:32] 4h40m* [17:56:57] I think I was lazy and never added that update [17:58:18] ah gotcha haha [17:58:53] I don't think the actual mission got that update [17:59:31] ah not quite true [17:59:39] they got it combined with the SPS-1 Maneuver PAD [18:00:21] I have basically set it up like the real mission [18:00:39] Maneuver PAD has the IMU angles for the launch REFSMMAT [18:00:58] the REFSMMAT for the burn is a preferred one, so 0,0,0 angles by definition [18:02:32] the flight plan has it early, maybe to allow the crew to go to that attitude early [18:13:51] ok sounds good [18:13:59] I can remove it from the checklist then [18:49:40] sure [19:18:37] I think I can replicate the difference between V83 and the equivalent in the AGS [19:18:46] now I just need to understand it... [19:42:00] :D [19:49:53] https://i.imgur.com/KGPYliV.jpg [19:50:04] I believe this closely matches the behavior for Apollo 11 [19:51:41] with 0° roll angle [19:51:59] although interestingly, the amplitude of the difference becomes smaller with a roll angle closer to 90° [19:52:10] which would be gimbal lock so probably expected and meaningless [19:52:52] the AGS calls the angle [19:53:06] "Inplane angle between Z body axis and local horizontal" [19:53:22] for the PGNS it's definitely not in plane [19:54:26] those jumps seems weird to me, otherwise I would say all there is to this is a difference in angle convention [20:02:58] whoa, yeah [20:04:01] 0° roll and of course 60° yaw [20:04:16] which leads to maximum difference of also 60 [20:15:39] and I would also trust the AGS over the PGNS [20:15:58] in-plane angle sounds more correct for the ORDEAL [21:51:50] night! [14:38:35] good afternoon [15:12:51] hello. [15:13:02] how's it going today? [15:27:08] very good [15:27:10] and you? [16:11:06] good as well [16:15:03] been testing the new center of gravity of the ascent stage a bit [16:15:15] the LM VC seems to have some issue, but they might not be caused by that [16:17:10] issues* [16:32:20] but otherwise it's a lot of fun seeing the DAP struggle during any APS burn [16:47:24] you were saying yesterday that it looked pretty close to the 16mm films? [16:50:00] yeah, in the way the attitude control behaves [16:50:19] just after liftoff the APS isn't pointing through the CoG at all [16:50:33] so the RCS needs to do a lot of working keeping the LM on track [16:50:49] and now that I have seen that once in the simulation it's all I can see in the videos [16:51:07] Yeah its pretty obvious lol [16:51:19] Do we have the cant angle modeled? [16:51:23] nope [16:51:27] well I have! [16:51:33] Wonder if that would help [16:51:33] currently testing that [16:51:58] I have both a realistic center of gravity and the APS cant in my local copy right now and doing a bunch of tests [16:52:20] I'm really enjoying looking at it [16:52:45] the dynamics are basically like this [16:52:54] the APS cant angle is overcompensating at lunar liftoff [16:53:19] so the APS causes an angular acceleration in pitch of about 7°/s^2 [16:53:50] that's as much as 1.5 RCS thruster can do [16:54:16] so the DAP has two RCS thrusters on about 75% of the time [16:54:27] during ascent the center of gravity shifts [16:54:49] shortly before cutoff the APS is almost exactly point through the CoG, at least in the pitch axis [16:54:53] pointing* [16:57:38] That sounds like its correct [16:58:04] and that's indeed very noticable in the videos [16:58:22] RCS off, APS is starting to rotate the LM [16:58:40] DAP doesn't like the attitude rate and errors and is switching on two RCS thrusters [16:59:09] and then once it is happy it switches them off and the cycle begins again [17:00:04] one cycle of this is about 3 seconds long I think [17:01:34] hmm [17:02:32] what we are getting now is just a bit of bouncing back and forth in the deadband [17:03:11] do we have any good telemetry of an ascent with respect to RCS firing? [17:03:58] I've been looking at the Apollo 11 DAP postflight analysis [17:04:18] https://ntrs.nasa.gov/search.jsp?R=19690031184 [17:04:39] I know the AGS took into account the cant angle, did the PGNS have the same? [17:05:48] hmm, well for guidance the PGNS simply measures the thrust vector and points it to the desired direction [17:06:47] have to check if e.g. P42 chooses the ignition attitude with the cant angle [17:07:26] for attitude control, there are two padloads, in pitch and roll axis, for the expected angular acceleration at lunar liftoff [17:07:34] to help the DAP out initially [17:07:49] would that be analogous to the cant in AGS? [17:08:40] I think the AGS just doesn't have the smart logic to measure the thrust vector like the PGNS can [17:08:42] theres an X an Y address I believe in the AEA [17:08:59] so you have to tell the AGS that the burn is with the APS [17:09:03] Rather, P and Y [17:09:10] or you get a constant pointing error of 1.5° [17:10:40] ah yes [17:10:54] AGS has addresses for cant in pitch and roll plane [17:12:11] but the Apollo 11 mission constants set the one in roll to 0 [17:13:43] and also [17:13:49] "The APS cant angle data previously input via the [17:13:50] DEDA to cornpensate for canted thrust direction has been deleted in FP8." [17:16:52] yeah I remember that change [17:17:18] and no, PGNS doesn't calculate the ignition attitude using any cant angle [17:17:23] not even for the DPS [17:17:33] But I dont remember if it was due to it being unnecessary or changes to the CG [17:17:37] the CMC does it with the SPS trim angles [17:18:25] the FP8 manual goes on [17:19:35] "DPS or APS misalignments of less than 2 degrees with respect to the [17:19:36] assumed thrust directions result in lateral cutoff velocity errors of [17:19:37] less than 3 fps. This type of error is sensed by the navigation [17:19:37] equations and consequently can be removed by performing a DV trim maneuver using axis-by-axis RCS thrusting (See Section [17:19:38] 28.0)." [17:20:26] and as far as I know, the APS was canted at 1.5° in the pitch plane and 0° in roll for all missions [17:20:36] although I have to check, LM-1 might be an exception [17:21:07] Ah ok [17:21:53] I am surprised they didnt have to change anything for the J missions [17:23:05] probably not large enough to make a difference [17:23:17] that initial guess for the angular acceleration caused by the APS does vary [17:24:57] Apollo 11 padload has 7.8°/s^2 [17:25:06] Apollo 17 has 5.335 [17:26:16] heavier LM [17:26:41] yeah, must be heavier in the front [17:32:05] morning! [17:33:09] I think you're right that LM-1 was an exception [17:33:33] LM-3 ascent engine installation drawing: https://archive.org/stream/apertureCardBox503NARASW_images#page/n468/mode/1up [17:33:41] LM-1: https://archive.org/stream/apertureCardBox502NARASW_images#page/n1491/mode/1up [17:38:52] hey Mike [17:40:15] so no cant angle on LM-1 [17:40:37] makes sense, I believe the astronauts are the main difference that is putting the CoG so far forwards [17:40:57] hmm [17:41:12] so I have to make the CoG calculation check if the astronauts are there or not [17:41:19] and make the cant angle optional [17:43:14] or be lazy and do neither of these things as they partially cancel each other out :D [17:48:12] but yeah, seems like LM-1 did not have any signficant shift in the center of gravity in the Z-axis, only 0.2 inches [17:48:55] near burnout, where the APS is nearly pointing through the CoG, it has 4.3 inches in Z axis [17:50:13] https://www.youtube.com/watch?v=GyoW3Op0-LA [17:50:22] made a quick and dirty video of the first minute of the ascent [17:50:35] look at pitch rate on the FDAI and listen to the RCS [17:50:40] and enjoy the outside view [17:57:36] oh wow, that's really cool [17:57:51] and you're right, that behavior is obvious in the videos [18:02:41] just hugs that deadband [18:04:05] and not just in attitude error but now also attitude rate [18:04:28] and the same in roll, just weaker [18:04:43] 0.5°/s^2 in roll at ignition [18:05:03] goes up to 2 at cutoff [18:29:14] quick question on AGS: while setting up for PDI, when the checklist says "240+(231 RLS)", am I correct in thinking that I'm supposed to read the value out of address 231 and then enter it into 240? [18:29:47] yep [18:30:00] or from the PDI PAD [18:30:05] 231 is on the PDI PAD [18:30:40] ah, is that another MFD screen? [18:31:17] should be a MCC PAD [18:32:00] there is a PDI PAD in the RTCC MFD, but I meant the physical PAD, in the LM Data Cards [18:32:13] I think in our pre PDI scenario the PDI PAD is not the latest one [18:32:26] so it's not saved there [18:32:54] Maybe I should add the PDI PAD to the scenario description [18:34:11] yeah the Before PDI scenario has the P76 PAD for the CSM saved [18:35:17] that's the last one that the MCC gave the astronauts [18:35:24] 231 is padloaded as well, correct? [18:36:07] I think so [18:36:29] yeah it is [18:37:07] so pulling 240 from 231 should be fine unless MCCH changed the RLS [18:37:39] pretty sure that you would have updated 231 then as well [18:37:42] and you want them to be the same [18:38:01] 240 is part of the cheaty lunar surface state vector update [18:39:00] thewonderidiot, PDI PAD is hidden away in the RTCC MFD under Pre Advisory Data, Maneuver PAD and then press the OPT button twice, if you need it. [18:39:18] aha, great, thanks :D [18:39:20] might not work in the old NASSP version though [18:39:27] not without updating the REFSMMAT [18:39:41] I updated to the latest orbiter beta and NASSP over the weekend :) [18:39:52] ah nice [18:39:58] so I'm now using your brand new Apollo 11 scenarios [18:40:10] then the attitude on the PDI PAD will be wrong, but it at least calculates the PAD right :D [18:40:18] hehehe [18:40:39] to get it fully correct in the pre PDI scenario also update the REFSMMAT. Utilities, REFSMMAT and use DWN to downlink the REFSMMAT to the RTCC MFD [18:40:43] and then calculate the PDI PAD [18:41:55] that sounds like a problem for future Mike [18:44:37] haha [18:46:25] 99R0 or 99R1? [18:48:34] last night I was flying 99R1 [18:48:46] and was able to do some AGS aborts successfully [18:48:59] tonight I'm going to do 99R0 and see how the AGS responds to being upside down from LNY-77 [18:50:25] initially I started with the pre-DOI scenario to start a bit further back, but I started getting tripped up on some of the other subsystems (like how to manually acquire the CSM with the RR) so I went back to the pre-PDI scenario :P [18:51:13] Mike needs more flight time in the LM :P [18:51:28] sounds like he is getting that at the moment haha [18:51:33] +00102 HRS TIG [18:51:34] +00038 MIN PDI [18:51:34] +025.39 SEC [18:51:35] XX09:50 TGO N61 [18:51:36] -0000.1 CROSSRANGE [18:51:36] XXX180 R FDAI [18:51:37] XXX287 P AT TIG [18:51:38] XXX000 Y [18:51:40] +56923 DEDA 231 IF RQD [18:51:42] that's your PDI PAD [18:52:30] aha, okay [18:52:45] I feel like +56923 is very close to, but not exactly, the number I was reading out of 231 last night [18:53:03] should be [18:53:09] is this 11? [18:53:16] yep [18:53:34] maybe it is exact and sleep has muddled the numbers in my head [18:53:49] I would have said that the number I was entering last night was +56919 [18:55:25] hmm, I don't think the MCC updates the landing site vector until after landing [18:55:38] but [18:55:46] 231 has +56919 in that scenario [18:56:44] ah [18:56:51] I just let the auto checklist run [18:57:00] it uses 56919, which is nominal I guess [18:57:20] should probably be eventually changed to whatever the PAD contains [18:57:36] although why that difference... [18:57:53] I never trusted the landing site coordinates in the flight plan lol, but that's what we are currently using [18:58:09] I know better now from MOCR audio [18:58:23] padloaded for 11 was 56936 [18:58:25] hehehehe [18:59:05] 937.051NM is what the RTCC had loaded pre landing [18:59:27] that is 56936 [18:59:51] where does 56919 come from... [19:00:17] ah [19:00:23] LM Timeline Book has that handwritten in [19:00:26] so actual mission [19:01:03] ah [19:01:26] is 56936 still padloaded in the scn though at launch? [19:01:43] and 56919 put in later (I cant remember) [19:04:24] yes [19:04:32] that is loaded in the AGS [19:04:40] 56936, at launch [19:06:41] not sure how they came up with 56919 [19:06:52] but that's on the actual PDI PAD [19:07:35] https://www.youtube.com/watch?v=gYQwuYZbA6o [19:10:00] I'm pretty sure that the actual mission had 56919 kft (936.766NM) loaded for PDI, in PGNS and AGS [19:10:16] so they uplinked that at some point [19:10:34] can't find anything about that in my notes from the FIDO loop though [19:10:57] must have been GUIDO who changed it [19:11:23] in RTCC, PGNS and AGS [19:15:48] sky crane makes a nice Mars sandstorm [19:19:19] haha yeah it does [20:12:09] pretty incredible shots [20:20:23] before P22 they had a "biased target" with the radius 936.728NM, 56917 kft [20:20:37] maybe based on the P22 on LOI day [20:20:59] I'm listening to the GUIDO during the P22 a few hours before landing [20:27:16] classic, P22 uses an altitude input, relative to mean lunar radius. GUIDO (or rather his sidekick callsign "Yaw") wants to know the value of that radius in nautical miles [20:27:29] so the AGC controller first has to convert that from metric for him... [20:28:26] not the first time where AGC is asked for a value and he only has it in metric, instead of a unit everyone else there uses :D [20:29:13] haha funny how that worked out to not cause any major issues [20:30:35] the last time this came up was the lunar sphere of influence the AGC uses. That time FIDO wanted it in Earth radii so that it is useful for the RTCC people... [20:35:22] Oh on 9, prior to first rest period, the FP calls for "6-4 Deorbit TIG" [20:35:37] I see no mention of this in the transcript unless I am totally missing it [20:35:45] about 8h50m [20:36:57] I see the block data prior to it [20:38:04] I think that IS the time of 6-4 deorbit [20:38:10] and not an update to the crew [20:38:29] 6 stands for rev 6 [20:38:33] and that is rev 6 [20:38:49] Ahh ok that makes sense [20:39:01] and Block Data 1 is preflight [20:39:37] they have that written down in some checklist already before the mission [20:42:11] did they have an attitude for drifting flight? [20:43:33] don't think so [20:47:21] Gumdrop is resting for the first "night" [20:47:50] nice! [20:48:50] a few checklist tweaks and procedure tweaks but nothing major to report [20:50:10] probably not much either on the next day [20:50:58] but then the LM fun begins [20:52:32] oh this is interesting [20:52:42] "What are you doing there friend, wait till you are out of P27" [20:53:02] during an uplink to the LGC [20:53:41] related to this [20:53:41] 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. [20:54:06] they uplink a state vector, it does integration immediately after, so they can't continue uplinking [20:54:41] I've seen that a few times, although thought it was my fault not setting up MCC uplinks correctly [20:54:51] but at least they got the same issue in reality... [20:55:31] "I can't believe we get caught with integration so many times" [20:55:59] hahaha [20:56:26] re-discovering issues they had during the real thing independently will forever be one of my favorite parts of this [20:57:36] "Well, I think what happened there [complicated explanation]... oh jeez, I don't know what happened, something like that" - Jack Garman [20:58:52] oh wow they had to uplink the V96 to stop it? [20:59:37] I just listened to them type in V96E from mission control [21:01:01] the order of things matters with the state vector uplinks, they just got that wrong [21:01:32] it has the maximum number padloaded for the state vector times, so that it doesn't do any integration before an uplink [21:03:12] when you uplink the wrong state vector first it will then try to integrate to that maximum time, 700 hours something [21:03:27] so V96 definitely called for [21:04:18] oh yikes [21:05:12] Oh my transcripts are a real gem, I have read through so many and still find little things like this that make the immature side of me come out: [21:05:13] 007:57:25 Schweickart (onboard): Boy, you know, swallowing all of this gas, you can't help but fart all over the place. [21:05:25] 007:57:37 Schweickart (onboard): That's a real challenge for that poor lithium hydroxide. [21:05:47] hahahaha [21:06:54] yeah the tone of the conversations can be slightly different between onboard and air-to-ground [21:24:46] boys will be boys [21:31:09] "Just as a matter of interest, the far future time tags on your state vector are really going to slow down the timeline on the next steps. Really slow it down. [21:31:10] We are in low lunar orbit with the R2 model, it takes forever to integrate back an hour and a half. We've had verb 47 sitting here for the last 2 or 3 minutes while it is integrating." [21:31:23] THANK YOU [21:31:40] exactly what I was thinking when reading mission techniques and flight plan [21:36:21] but I guess they actually did that then [21:36:25] heh [21:36:37] even if it means long integrations on any V47 and V83 [21:41:45] didnt we have issues with that at one point when we had future SVs uplinked? [21:41:50] I remember some took a long time [21:43:38] yes [21:43:52] I might have partially taken those out again and uplink current time state vectors instead [21:44:05] but apparently they did it like flight plan and mission techniques want it [21:44:51] for Apollo 11 the LM state vector got a DOI-10 time tag, CSM PDI+25 [21:45:08] PDI+25 minutes is probably the main issue [21:45:24] that is a long while away at the time of uplink [21:46:01] but I actually started too late in the GUDIO audio, they had already calculated those uplinks [21:46:05] just not uplinked yet [21:46:12] so I am not 100% sure about their time tags [21:46:20] probably close [21:48:03] nobody has forced Bill Tindall to watch a DSKY while it integrates a state vector for multiple minutes [21:48:17] the mission techniques would have looked different if they had done that [21:50:16] Haha my fiancee just looked over at me funny when I cracked up at that comment [21:50:43] I just told her she wouldnt get it (she loves apollo and works in aerospace, but not as deep as us) [21:53:15] haha [21:56:05] heheh [21:56:10] it is very true :D [21:56:23] also indy91, I found another annoying set of dates [21:56:42] http://www.ibiblio.org/apollo/Documents/ksc_rope_module_status_71.pdf [21:56:53] PDF page 2 of that has estimated arrival dates for rope modules to KSC [21:57:11] which sounds great, but I don't know how much I trust any of them.... [21:57:59] for example, Comanche 45-2 being delivered to KSC on 4/4/69, even though they weren't even directed to add the R-2 model to it until 4/1/69 [21:58:23] unless that's the date the Comanche 45 rev 0 module showed up [21:58:29] hmm right [21:59:36] Luminary 69-2 certainly didn't show up at the beginning of February, heh [21:59:47] although that is believable for just 69 [22:00:08] so, the 6/24 and 6/25 seem a tad early, but maybe possible? [22:00:27] the numbers for the banks, do we know they are correct for one of the revisions? [22:00:46] hmm, what do you mean, numbers for the banks? [22:00:58] the rope modules I mean [22:01:04] dash number, serial number [22:01:07] oh [22:01:14] this is our only source for flown serial numbers [22:01:20] great :D [22:01:21] well, this one and the equivalent one from 1972 [22:01:31] but yes, the dash numbers are all expected [22:01:52] I actually reverse-engineered the dash numbering for most of the modules from this document before we got all of the NARA drawings [22:02:57] https://archive.org/stream/apertureCardBox467Part2NARASW_images#page/n40/mode/1up [22:03:15] the Computer Program Assembly drawings give the expected dash number configuration for different releases [22:03:29] ...the "Luminary 99" at the top of that page I linked is actually 99/1 [22:03:37] but the key feature of 99/1 is the -1071 for module B1 [22:04:04] Luminary revision 99 would have -1041 for module B1 [22:05:50] Comanche 55, ship date June 4th, arrival at KSC May 29th. Hmm [22:05:53] and what is MKE [22:06:02] hahaha [22:06:06] that one took me a bit [22:06:14] must be a typo [22:06:16] MKE is Milwaukee, where AC Electronics was located [22:06:38] right, I had already googled Raytheon Milwaukee [22:06:43] didn't think of AC [22:06:47] so they must have shipped them from Raytheon to AC and then to KSC from there [22:06:58] the ship date to arrival date is usually quite constant [22:07:20] if we take 6/4/69 and believe it is actually 5/4/69 [22:07:31] then the outlier is Luminary 99 [22:07:34] yeah that seems likely [22:07:50] so that ship date is probably revision 0 [22:08:03] while arrival date refers to R1 [22:08:03] the MKE->KSC for 99 makes sense, I think, since they probably decided to overnight it to get it there ASAP [22:08:04] maybe [22:08:21] yeah [22:09:22] let's see, when was 99/0 released... [22:09:47] some time in may [22:09:51] yeah that ship date is probably 99/0 [22:10:41] hmm I am trying to remember why I have a nav check in each SPS burn procedure [22:10:42] 6/24 arrival at AC is even more crazy, if 6/17 was the release to Raytheon date [22:14:56] rcflyinghokie, the Maneuver PAD has a nav check section [22:15:06] weird Apollo 7 and 9 only procedures [22:15:10] Ohh thats right [22:15:27] Thanks [22:16:36] maybe if I waited for the maneuver pad I would have noticed :P [22:22:52] night! [14:47:21] good morning [14:49:47] hey [14:51:28] so Mike and I were playing around with the EMP last night and we discovered some interesting behavior with aborts [14:51:39] Not sure if its accurate or not in the sim [14:52:27] So in one test case, abort is used in PGNS and fails (frozen P70) so guidance is switched to AGS and it starts working as advertised..... [14:52:45] If an abort stage is called while the DPS is burning, it stages and lights the APS etc.... [14:53:05] However, if an abort stage is called after the DPS is depleted, it will not fire the stage in AGS [14:53:26] the only work arounds were engine arm ascent and engine start, or switching back to PGNS [14:53:51] interesting [14:54:09] tested it numerous times same results [14:54:32] could be an AGS software problem [14:54:38] or our control electronics [14:55:03] yeah i couldnt find anything that would point to abort stage not functioning in that case [14:56:33] I wouldnt think it needs to sense DPS running to work [14:56:34] and that works without the EMP? [14:56:45] actually we didnt try it without [14:56:52] shouldn't matter [14:56:56] but it was the AGS that wouldnt fire the stage [14:57:03] yeah [15:03:12] I wonder if I just configured the AGS wrong [15:03:48] which scenario did you use for this? [15:05:47] I didn't do 400+1 in my testing scenario [15:05:55] which I have to Mike [15:05:57] gave* [15:06:37] what causes staging is abort stage plus an engine on signal from the computers [15:11:34] but I can replicate this [15:16:00] saved a scenario with this condition in progress [15:16:07] I guess I'll look through it relay by relay :D [15:17:38] sorry got pulled in a meeting [15:17:50] it was the apollo 11 pre pdi [15:18:14] 102h28m [15:19:05] also another thing, what is the ONAME in the scn file? [15:19:18]