[00:41:11] NASSP Logging has been started by thymo [00:41:45] should make the log auto rotate every 24h because he keeps forgetting. [00:46:11] Hey how goes the CWEA? [00:47:57] I put it on hold for a little with my college exam period. I plan on getting back to it later this week, [00:48:25] One more exam to go, object oriented programming in Java on Wednesday. [00:48:28] Totally understand [00:48:42] Work has been killing me lately I have barely been able to do ECS stuff [00:50:15] I haven't got anything at college tomorrow so I'm happy I can finally get a proper night rest . :) [00:50:35] No, all nighter on NASSP...GO! [00:50:53] Haha, yeah I should go to bed here in a minute. [00:51:43] I am doing the same, moved the LM power and press to after its created and now I am trying out a quick valve change to see if lm pressurization happens quicker [00:51:46] Still got a little bit of prepping to do tomorrow. Need to review how JSON sticks together and do a practice exam. Pretty relaxed. [00:51:50] Took 3 and a half hours last time [00:52:06] Supposed to take 30 minutes or so I believe [00:52:11] Yep. It really can suck you in like that. [00:53:15] I've had plenty of quick fixes which I'd still be working on 4 hours later rewriting a large piece of some code and heavy crying sessions. :P [00:53:56] Haha [00:56:10] Alright I'll be off to bed then. Goodnight! [00:57:37] Night! [01:00:52] hey [01:01:33] so when i get to loi ignition, the whole csm/lm stack bounces all over the place, and those gauges above the gimbal motor switches are going up and down [01:03:26] Have you been charging your batteries? [01:03:42] Also do you have the correct DAP load [01:03:57] it was someone elses scenario [01:04:12] Send it to me I can check [01:04:15] when it went to terminate battery charge it was already off [01:04:30] and the dap load was 21102, 21111 or something like that [01:04:38] okay i will send it on dropbox [01:05:13] Ok yeah 2 is the correct first number for that [01:05:24] What about your weights and gimbal angles in DAP [01:08:55] https://www.dropbox.com/s/arbgzq238iw0isj/Apollo%2010%20MCC%20-%20Launch%200001%200002%200001%200002%200003%200003%200001%200001%200008%200002%200001.scn?dl=0 [01:09:15] 5 minutes till ignition [01:09:47] Ok let me look [01:11:39] The spacecraft was in SCS [01:13:14] And the DAP R2 was 21111, that first number should only be a 0 or 1 [01:13:41] oh [01:14:11] Not sure if that was the problem just an observation [01:14:12] i think it called for 0 [01:14:39] yeah [01:14:41] bats look good [01:14:46] I will see if I get a good burn [01:16:43] 30 seconds [01:17:23] Same problem [01:17:33] We might have a gain issue here [01:17:56] That is something in the padload [01:18:39] would you be able to fix that [01:18:51] .tell indy91 I just messed with one of astronauthen96's Apollo 10 scn's for LOI, and it looks like the SPS gimbal gain issue might be happening for Apollo 10 [01:18:59] No indy91 is the padload master [01:19:12] We had this issue before [01:19:13] would it be the same for apollo 11 [01:19:18] I think Apollo 11 is working [01:19:30] its a padload for the individual mission, I know it was fixed for 9 and I think 11 [01:19:36] I dont know if it was for 10 [01:19:53] Now you can fly the LOI using SCS [01:20:26] would that work [01:21:20] Yes [01:23:38] I am trying it again verifying the spacecraft configuration [01:24:34] it appears to be stable [01:25:16] but something happened with the dsky [01:26:08] Probably not happy about bring in SCS haha [01:26:17] The EMS will shut down the engine in SCS I believe [01:27:06] but it was stable [01:28:13] The wobbling is mostly likely a padload [01:28:30] would indy be able to fix that [01:28:35] Yeah [01:28:39] We have that info [01:28:49] It just may have not been corrected for all missions with a LM [01:28:57] okay [01:29:05] and what is your get for 11 [01:29:07] I will mention it again when I am on tomorrow if he doesnt get my message [01:29:21] Oh I havent flown it today, 25 hours or so? [01:29:42] well i forgot to save again so i am at 28 hours [01:29:49] i will remember next time [01:29:56] Haha [01:30:00] You will learn ;) [01:30:22] I have tons of saves from all over the mission though [01:30:27] If you want one [01:30:41] from 11 [01:30:51] 9 10 11 and 12 [01:31:02] I tend to hang on to them [01:31:04] sure [01:31:10] Where in 11? [01:31:15] are they outdated [01:31:20] They should work [01:31:58] how many do you have for 11? [01:32:08] Hmm all mine are lunar orbit or later [01:32:40] sure you can send them? [01:33:00] I have one right after LOI [01:33:08] So you can do LOI 2 and prep for landing [01:33:19] okay [01:34:14] LM is unpressurized still as well [01:34:21] And you will have to skip forward in checklist MFD [01:34:24] https://www.dropbox.com/s/0aqsdm6lrc8cgff/Apollo%2011%20MCC%20-%20LOI2.scn?dl=0 [01:34:40] This was saved before some major checklist changes and the LM ECS [01:34:43] But it should work [01:34:59] Oh and the latest build is up with ECS fixes [01:35:09] I still can't believe you guys banged out the ECS so quickly [01:35:30] Started thanksgiving week had it comitted before the new year [01:35:34] Not too shabby [01:35:35] "saved before the LM ECS" is really not that long ago, haha [01:36:05] As soon as I get a day off I am finally going to start the ECS tweaks [01:36:22] I started the pressurization today I have it faster but not fast enough [01:36:28] But I only spent an hour on it [01:36:37] busy times at work? [01:36:40] Yeah [01:36:51] I am looking forward to switching to flying [01:37:12] I mean I love process engineering its fun but its become mundane quickly [01:37:17] yeah that will be awesome, I'm looking forward to it too :D [01:37:20] wants more pictures [01:37:27] I will be sure to take many more! [01:37:39] excellent [01:38:02] astronauthen96, if you have any other questions feel free to use .tell for myself or indy, but I need to get some sleep [01:38:13] Have a good night all [01:38:18] goodnight! [14:45:16] hey [16:35:32] hey [16:35:55] that is an old scenario [16:36:05] before I changed the DAP settings [16:36:25] astronauthen96, and you were right, something is indeed wrong with the Apollo 17 launch. [16:36:40] always great when you fix one thing, just to break one other thing... [16:36:47] I'll look into it [16:39:42] although you could have flown it into orbit manually :D [16:40:49] hey [16:41:02] so the attitudes worked it was a bad alignment i think [16:41:11] good to hear [16:41:18] but then you got issues with LOI? [16:41:32] yes it was bouncing all over the place [16:41:57] i can post a scenario 5 minutes to ignition if you want [16:42:09] yes and I know exactly what needs to be fixed in it [16:42:14] okay [16:42:23] that has to do with the Orbiter Beta. Orbiter 2016 still calculated the behavior of the CSM+LM docked in the wrong way. [16:42:36] will it be an easy fix? [16:42:43] but in that older Apollo 10 scenario we configured the CMC to deal with Orbiter 2016 [16:42:45] yes, quite easy [16:42:54] just have to change a few variables in the CMC memory [16:46:14] it's just three lines, so it might be easier if I just tell you what to change in that pre LOI scenario [16:48:51] hmm [16:52:03] okay [16:52:13] i will be right back just making coffee [16:56:55] ok, right now I am not 100% this is even right, but you can test it for me :D [16:57:03] in your scenario, find the following lines [16:57:04] EMEM3016 17433 [16:57:05] EMEM3017 4510 [16:57:05] EMEM3020 333 [16:57:25] and change them to [16:57:45] EMEM3016 37071 [16:57:45] EMEM3017 2244 [16:57:46] EMEM3020 156 [16:57:49] how do i edit the scenario? [16:58:00] notepad or something like that [16:58:03] it's a text file [16:58:13] any text editor will work [16:58:31] okay [16:59:02] can you post those numbers again, i am on my computer which has the scn file [16:59:16] in your scenario, find the following lines [16:59:21] EMEM3016 17433 [16:59:25] EMEM3017 4510 [16:59:30] EMEM3020 333 [16:59:35] and change them to [16:59:40] EMEM3016 37071 [16:59:45] EMEM3017 2244 [16:59:48] EMEM3020 156 [17:00:36] just to be sure is this only Apollo 17 that needs the update? Im restarting Apollo 11... [17:00:55] i only tried 17 [17:01:36] AlexB_88, not sure, but the missions with LVDC presettings might not be affected [17:01:44] I did test Apollo 8 and it was fine [17:03:12] wait, are we talking of TVC DAP issues? [17:03:21] yeah [17:03:25] in an older scenario though [17:03:46] ah ok [17:04:54] it appears to be stable [17:04:59] it's so annoying, we have all the Apollo 12 and later padloads [17:05:05] but this was changed between 11 and 12 [17:05:23] and we have no good source for earlier, so... [17:05:30] those gauges below the fdai are bouncing slightly but the attitude seems to be stable [17:06:13] would my 11 scenario have this problem? [17:06:30] probably not, I think you flew it from launch fairly recently, right? [17:06:34] I fixed this in October [17:06:46] in the last week [17:07:22] should be good then [17:08:12] just testing now with 11 [17:09:33] one minute to go [17:09:57] looks good attitude held nicely [17:10:30] @alexB_88 are you flying 11? [17:10:37] yes [17:10:49] LOI? [17:11:04] and for the LVDC issue, I don't even think it's a bug, it's just wrong presettings now. [17:11:16] I had flown up to MCC-4 but with the LM ECS fixes Ive now restarted from launch [17:11:22] okay so, the orbit is 166.4 x 58.4 [17:11:31] not bad [17:11:39] but there is an loi 2 i think [17:11:42] for apollo 10 [17:11:44] yes [17:11:48] 2 orbits later [17:12:07] Im going to test all the new things from launch, like the new weight vector method, new checklists and LM ECS fix [17:12:09] and residuals were -1.3 [17:13:03] those 1.3 might be the difference between 166.4 and the actually targeted 170.0 [17:13:09] but not critical at all [17:13:26] its 167 [17:14:40] yeah, small difference [17:14:47] on the dsky it shows 169 x 60 [17:15:56] would the dsky be more accurate then the project apollo mfd? [17:16:18] no, the PAMFD shows your actual orbital parameters [17:16:43] oh, there is one difference [17:16:56] PAMFD calculates altitude relative to the mean radius of the Moon [17:17:05] the DSKY calculates altitude relative to the landing site [17:17:17] and the landing site is about -1.7NM or so below the mean radius [17:17:24] so there is an expected difference there [17:18:09] and the 60x170 is also relative to the landing site [17:18:22] so the ideal display on the PAMFD would be 58.3x168.3 then [17:19:39] its 58.4 x 167.4 [17:19:44] so its close [17:20:32] yep [17:23:10] morning! [17:27:44] hey [17:28:32] praise @indy91 [17:28:55] the RHC is stumping me [17:29:05] praise me when I fixed Apollo 17 (and 15, and 16 and maybe others) again :D [17:29:11] yeah [17:29:20] I'm like 96% sure AGCs in LM-4 and later were electrically different from LM-3 and earlier, but I can't find any documentation explicitly saying so [17:29:27] and praise all of the developers too [17:29:58] different in what way? [17:30:01] are 15 and 16 now working? [17:30:08] not* [17:30:09] I don't think they are [17:30:36] well i would try them but i'm gonna focus on apollo 11 for now [17:30:37] just a little guidance problem, you could fly the Saturn V into orbit according to the backup procedures though [17:31:06] different in that a couple of resistors in the interface modules were changed to make the counts at max RHC deflection 42 instead of 32 [17:31:40] the RHCs themselves definitely did not change, because for all LMs max deflection fed the same voltage into the AGC [17:32:18] and the code in Aurora and Sunburst 37 is clearly expecting 32 for max deflection... and I am pretty sure, although not totally sure, the same is true for Sundance [17:33:02] it may have been coincident with the change to a quadratic scaling, which happened in Luminary 61, but the memos don't mention hardware changes at all [17:33:03] if we had activation checklists for Apollo 9 or 10 then we might have a hint [17:33:36] 10 definitely expected 42, we'd need 9 [17:33:40] Apollo 12 is expecting 052 [17:33:41] or its GSOP [17:33:50] 051* [17:33:56] 051? [17:33:57] so 41 counts in octal [17:34:00] uhh [17:34:03] the other way around [17:34:11] it should definitely be 42, not 41, heh [17:34:34] unless that last count was on the edge [17:34:38] where did you get that number? [17:34:39] does it count +0 and -0? [17:34:42] no [17:34:47] Apollo 12 LM Activation Checklist [17:34:56] what does it say, exactly? [17:35:05] soft stop is 00051 and 77726 [17:35:10] V15 N01E 42E [17:35:37] well, that's interesting [17:36:06] could just be an ACA specific thing though [17:36:11] MASK DAPBOOLS # MAXIMUM COMMANDED RATE (AT 42 COUNTS) OF [17:36:11] CCS A # 20 D/S (NORMAL) OR 4 D/S (FINE), SCALED [17:36:12] CA NORMAL # AT 45 D/S. [17:36:32] Luminary 116 program comments expect, and math works out, to 42 [17:36:36] *but* [17:36:38] the Apollo 12 ACA didn't cause the full deflection for the counter [17:36:44] other missions have a different value there [17:36:46] I think [17:36:48] le tme check [17:37:40] 1 count could certainly be within the expected range, not every ACA was manufactured perfectly [17:38:05] it may be on the part of the AGC too, the resistor values they show in the ICD are more likely to produce 41 than 42 [17:38:11] I guess they didn't care that much [17:38:23] Apollo 14 LM Activation [17:38:29] V15 N01E 42E [17:38:37] it actually expects a range [17:38:41] 00045 to 00057 [17:38:46] and 77720 to 77732 [17:38:48] haha [17:38:49] okay [17:39:03] RHC is not an exact science I guess [17:39:04] so if it wouldn't be in that range, that specific ACA would be NO GO [17:39:26] yes, the AOH says soft stop at X° +/- 0.5° or so [17:40:00] anyways, I've coded it to calculate 42 counts always at max deflection [17:40:09] but I would really like to know what Sundance used [17:40:15] the Apollo 12 checklist might have been written with a preflight test in mind [17:40:24] yeah [17:40:49] Apollo 15 LM Activation has the same as 14 [17:40:51] UCHL has a study guide for the Sundance 306 DAP, which is very close to the flown 306 and likely discusses this, so I'm going to request it [17:41:00] er, it's for Sundance 302 [17:41:02] do we not already have that? [17:41:04] nope [17:41:16] the only study guide from this group we have is for Computer Utility Programs [17:41:20] for Sunburst 20 or so [17:41:28] we have the Study Guide for Sundance 302 [17:41:43] oh wait [17:41:45] we do [17:41:48] you're right [17:41:53] https://www.ibiblio.org/apollo/Documents/HSI-208409.pdf [17:41:59] one of Ron's requests? [17:42:01] lol [17:42:19] no, I think at one point you had either Ryan or Alex request everything with Sundance in the name [17:42:27] I forgot about that [17:45:08] Ryan I think [17:46:04] so the answer may be in there somewhere [17:47:37] so im reading the apollo 15 launch checklists and there is a tli program 15, will that be implemented? [17:50:54] we have the CMC version flown on Apollo 15-17 [17:51:07] and that indeed has P15 [17:51:16] but it's not as exciting as you might think [17:51:27] it's just for monitoring TLI, it can't really control TLI [17:51:40] it can command ignition and shutdown of the S-IVB engine at least [17:52:06] indy91, SV error was 1500 m at insertion, and the normal LV SV update was done at TB5+100 and SV error indicates 0 at that point. I am noticing its jumping wildly after that IE: [17:52:40] [5+1155.662765] SV Accuracy: 3035.560864 [17:52:55] [5+1844.560150] SV Accuracy: 106.864318 [17:53:13] just 2 snapshots I took from the same LVlog [17:53:54] Im thinking its the SVcompare function that is the issue and not the actual LV SV [17:54:17] I can give you the whole LVlog if you want? [17:55:18] no, I've seen that behavior after the SV update [17:55:23] not sure what causes it [17:55:34] ok so the LV SV is indeed ok [17:55:53] I hope so :D [17:56:02] Ill find out soon :P [17:58:02] so the launch worked without issue? [17:58:16] when did you start from the T-4h scenario? Today? [18:00:24] yes [18:00:37] and no issues so far [18:00:49] just doing the 1st P52 now, TLI next [18:00:51] interesting, so the issue with Apollo 17 and others are the default parameters [18:01:00] LVDC parameters [18:01:08] because Apollo 11 isn't using many of them [18:01:50] what I got was the S-II falling a bit below 100NM and in the lvlog the Delta V for the S-IVB stage flight was negative [18:02:03] and then after staging I got the LV GUID light [18:02:41] with Apollo 17? [18:05:27] yes [18:06:21] it was a nice failure as per requirement, haha. Last attitude error command is held until CMC takeover is done, then the LVDC sends no commands to the FCC anymore. [18:06:29] Haven't tried any of those scenarios lately, so all the launch scenarios with no presettings are broken I guess? [18:06:35] might be [18:06:46] Apollo 9 and 10 have proper masses, so they could be good [18:07:07] one thing I want to do is change the default parameters to Apollo 11 [18:07:14] so this would be not a bug but just a lack of proper presettings? [18:07:24] yes, that is what I think [18:07:52] the LVDC development started with the parameters from the 1967 Boeing document. Then a bunch of things were changed to Apollo 8 by default. [18:07:58] well it means you did a very good job then :D [18:08:00] Most if it is like Apollo 8 right now [18:08:04] of* [18:08:24] but Apollo 8 is lighter than your average Saturn V, so really, some of those later missions should be the default [18:08:32] Apollo 11 seems like a decent choice [18:11:29] yeah, I am already seeing some big differences between the Apollo 11 presettings and what we are using by default [18:16:21] interesting [18:20:51] thewonderidiot, I even checked the transcripts, haha, during the Apollo 9 LM activation they were reading a lot of the checklist aloud, but not how many ACA counts the DSKY showed :D [18:24:29] bastards! [18:26:29] they say left, right, up, down, "looks all good" [18:26:50] >:( [18:31:33] GSOP change log has "Rotational hand controller scaling" [18:31:55] which is a different PCR than the "make the DAP rate command a nonlinear function of LM hand-controller deflection" [18:31:59] both in December 1968 [18:37:29] oh really? [18:37:37] that sounds very promising [18:38:24] that PCR went into Luminary 56 [19:04:17] day three has begun [20:12:36] just moving the MRS a bit already prevents the LVDC guidance failure, but the S-IVB has to pitch up to 40°, so more tweaks are necessary [20:42:10] that is quite a maneuver, heh [21:05:52] not sure the Sundance study guide has enough info to determine if 32 or 42 was used :( [21:17:40] ah [21:17:57] NARA Fort Worth has the Sundance GSOP section that will contain the answer [21:18:18] more GSOP is always good [21:18:27] yes [21:18:39] it just hard to get there [21:19:00] UHCL also has a bunch of Sundance 306 GSOP docs [21:19:27] just not the DAP section [21:19:32] ah, we of course already have those, haha [21:19:56] yep, again thanks to Ryan, haha [21:26:47] I always forget that 90x90 is the right orbit for Apollo 15-17 [21:26:57] so no, dropping below 100NM isn't so bad after all [21:28:33] haha [21:29:40] and the lower orbit might also be the main issue [21:43:38] night [23:11:26] rcflyinghokie, just restarted Apollo 11 with you latest checklist [23:11:33] Awesome [23:11:48] I put the LM Press stuff into their own groups and moved them to after ejection [23:12:03] The only thing I havent tested is the timing, I hope it doesnt impede with the SPS evasive [23:12:08] just did the evasive burn and now doing press. equalization check [23:12:13] You may have to do that while the LM is pressurizing [23:12:19] Oh good [23:12:30] It still takes a while [23:12:40] I have been slowly working out the valve sizes [23:12:47] I have press down to an hour and a half [23:12:52] But still more tweaks to go [23:13:40] yeah I noticed it takes a bit less time now [23:13:55] Oh it will take even less when I push my changes [23:14:08] We think we fixed the stabilization bug [23:14:16] Where it goes to NaN during time accel [23:14:27] timing is not bad as the pressure equalization check seems to be called after the evasive which works out nicely [23:14:33] And I need to go back and test and adjust the glycol loops back [23:14:49] Ok good, I thought that was the best place to put it [23:15:39] I think the repress package in the CSM is way too small [23:15:39] maybe the only thing is that it does impede into the maneuver to slingshot attitude at 4:50 MET [23:16:06] Yeah you possibly have to let it just pressurize in the background while maneuvering, its not ideal but it works for now [23:16:55] Well damn, got a NaN in 10x [23:17:05] maybe the press equalization can be moved to after the maneuver to slingshot attitude? Might may the flow easier and would only delay it like 20 mins or so [23:17:42] of course temporarily [23:18:05] .tell indy91 I still am getting NaN errors during LM press, not every time, and not as many tanks are affected but everything went off scale high and then cabin press and temp in the CSM went to NaN as did the LM [23:18:13] Sure I can do that [23:19:20] I think the LM PWR to CSM can stay where it is, sandwiched between the evasive burn and slingshot maneuver, or maybe just bump both the LM PWR and pressure checks to after evasive... [23:19:54] after slingshot maneuver* not evasive [23:20:21] sucks that you got the nan's [23:20:42] I kept LM power where it was, and moved the LM Press to after the V49 for the slingshot I think that is a good spot [23:20:48] Yeah I didnt have any yesterday [23:20:54] I hope its not my valve changes [23:22:18] I know indy91 said he reduced the some valve sizes I think to stop the errors [23:22:41] Yeah [23:22:41] and sounds perfect for the checklist change [23:22:52] I am increasing just the ones that connect the tunnels [23:22:58] right [23:23:26] doesnt sound like easy stuff to get right lol [23:23:55] Its a challenge for sure [23:24:09] Working the ECS I am a lot more comfortable making changes [23:24:24] However its always a puzzle to find a system of what to change and how much [23:27:19] yeah [23:27:42] Ooh slingshot burn now works, just watching the show now [23:29:35] I noticed that! [23:29:43] It caught me off guard I thought it was a comet [23:31:20] wonder if it actually ends up on the correct trajectory [23:32:04] damn, got the nan's [23:32:23] at 10x [23:32:42] maybe 5x would work? Ill try that [23:32:46] Yeah I think we nipped it in the butt but didnt stop it [23:32:54] I did many pressurizations yesterday no NaN's [23:33:06] And I am doing one right now at 10X no NaN [23:33:12] 50 minutes in [23:33:34] and once its completely pressurized with non errors, should it be stable thereafter, with 30x? [23:33:52] Nik ran a few tests with that and it was [23:33:56] He did his at 50x [23:34:17] It was something to do with the code and how it treated the tanks each timestep [23:34:28] ok [23:34:28] And reducing valve sizes helped [23:34:39] I dont think the code was changed itself [23:40:10] is i normal that when at CAB pressure 4.5 and LM/CM DP 3.1 It says to close the pressure equal valve. I do that and the LM/CM DP does not stabilize, it slowly goes back up to 3.5 - 4 [23:41:24] Could be the valve sizes are small that it is flowing from the tunnel into the LM therefore decreasing the pressure [23:41:36] I am trying to get it so the LM pressure stays close to the tunnel [23:43:03] Hmm looks like my slow pressure is actually Niklas' code being my bottleneck [23:43:12] I was wondering why I wasnt getting better results [23:49:32] haha [23:49:37] it is Niklas's fault :D [23:52:01] crap 5x as well, happened later into it though [23:52:25] I have done 5 now on 10X with no nans [23:52:50] And no that was my fault for not looking there for flow regulation :P [23:53:07] The code contains the connection for the CSM tunnel to the LM tunnel [23:53:22] And the CSM pressure equalization valve [23:56:03] with the new code? [23:56:28] This is from when we made the tunnels connect [23:56:47] Its the flow on the pressure equalization valve [23:57:37] hmm I have the latest update but still get them every time [23:59:04] I have only had 1 the last 2 days [23:59:09] now trying 3x [23:59:10] And it was the one I mentioned [23:59:18] I have been on 10x every time [23:59:41] On yours, do your cabin and suit pressures in the csm both vanish? [23:59:45] Or just the cabin [23:59:57] I think both [00:00:11] That was the old issue, mine was only the cabin side for whatever reason [00:00:21] So maybe something still is causing that in the LM [00:00:32] actually may have been the cabin only [00:00:34] If you get it again, can you save and send me the scn [00:00:39] sure [00:00:43] I want to see which tanks are nan [00:06:30] Dialing in the LM Press time :) [00:06:44] Haha I got it down to 10 minutes, now to go the other way [00:08:36] 10 minutes! that would make you ears pop [00:09:21] Possibly [00:09:49] Its good to know that I could get it down that fast, because I can dial it up to time it right now [00:11:01] should be like 30m? [00:12:09] Yeah [00:12:15] I am aiming between 30-40 [00:12:39] Because my LM can hold more O2 because of the necessity of making suit circuit tanks bigger for stability [00:14:34] Still no NaNs anymore on my end [00:15:06] down to 1.5 DP at 3x [00:15:33] anything higher then 3x and I get em [00:18:05] Really [00:18:26] I was getting them almost every time and now only the one still [00:18:52] you must of fixed something then [00:19:03] Maybe? [00:19:05] Haha [00:19:10] I have been working valve sizes [00:19:31] Oh, side question, any idea how large the O2 repress package is in the CSM? [00:19:37] I cannot seem to find a good source [00:20:04] Our current one is 0.9628L [00:20:17] But that is supposed to last a few represses from 4-5.7 [00:20:22] I can barely get 1 [00:24:20] hmm no idea [00:24:56] Im getting an intermittent FC 3 CW coming on btw [00:25:09] Whats triggering it? [00:25:17] have you seen that on your end during LM press equalization? [00:25:26] No [00:25:46] I dont know yet im investigating... all the FC 3 needles are in the green bands [00:26:00] its intermittent [00:27:20] Anything close to the top? [00:27:33] I know FC 3 temps float high [00:27:44] All of Main B and AC 2 are on it [00:29:46] ah I think its the COND EXH that skims the top [00:30:10] got more nan's [00:30:19] stby for a scenario [00:30:28] https://www.dropbox.com/s/g6szu1tyee5is1z/Apollo%2011%20MCC%20-%20Launch%20T-60s%200047%200003%200013.scn?dl=0 [00:31:08] I bet I know why, the o2 fans or heaters probably kicked on [00:32:03] And I will look at the scn [00:34:43] Wow the LM is polluted with them [00:34:49] Even the water tanks [00:35:36] Are you getting the nans in the CSM or are you looking at the LM [00:35:46] Rather are you getting the missing gauges in the CSM [00:36:20] Because it looks like the NaNs are all over the LM but the CSM is just almost empty [00:37:37] only lose the cabin press needle [00:37:55] i havent stepped into the LM yet [00:41:27] Thats what happened to me [00:41:37] But another test at 30x just now no NaN [00:43:12] I think I have the time close, I am trying to get the sizes to allow 3.1 PSI on the dP gauge when the cabin reaches 4.5 [00:43:16] I am at 2.9 [00:43:19] so close! [00:43:27] A little less flow [01:04:27] Got the flow where it should be I think but my cabin repress is too small [01:06:49] Ah the flow is so slow in the end [01:06:59] dP of .5 after 48 minutes [01:07:16] Which isnt bad I guess [01:10:13] And still no more nan's on my end even using 30x [01:11:06] lol im jealous, I cant manage above 2x haha [01:11:28] Maybe my changes helped? [01:11:46] probably [01:12:01] You can grab them from my branch if you wish [01:12:24] I am not pushing them to upstream yet because they would join a PR I have up and I prefer to keep them separate [01:13:04] One thing is that I am running a fresh scenario from this morning. Is it possible that your running from an older scenario that has some saved variables? [01:14:49] Unlikely, this was a fresh scn only a few days ago [01:14:58] ah ok [01:16:35] I have cabin press to about 45 minutes [01:16:43] nice [01:16:46] I think considering the extra volume in the LM that isnt bad [01:17:53] on my end I have it nicely tuned to about half a day :D [01:18:24] Yeah it took me a while before [01:19:17] I guess I can just add it to my PR, I wish you open a second PR with other stuff [01:21:21] Its on my Orbiter2016 branch if you want to merge it into yours [01:22:48] Ill wait for it to be merged into the main branch [01:23:42] Ok [01:24:08] The only thing you have to do differently is you might need to keep the repress package on fill [01:24:28] Because it doesnt seem to have enough o2 to bring the CM from 4-5.7 even one time [01:33:42] so press equalization valve stays open during TLC? [01:37:47] According to the Apollo 15 systems checklist it isnt closed at the end [01:38:53] And in the apollo 11 decal it doesnt say close it [01:38:57] http://www.collectspace.com/review/aneedell/cm107_yellowstain01-lg.jpg [01:44:36] ahhhh actually I think the sundance study guide might indicate that Sundance was already using 42 counts instead of 32 for RHCs [01:46:19] Random :P [01:47:16] haha sorry [01:47:24] the math just clicked [01:49:26] Haha totally understand [01:51:26] It looks like it is closed during the pre sleep checklists [01:52:14] Regarding AlexB_88 's question [01:59:31] yeah makes sense [02:03:58] I will tweak the pressurization even more when I start going through the other valves but I think I sped it up nicely [02:04:17] I manually did the changes from your PR but I get a CTD [02:06:02] Where did it CTD? [02:06:13] oh lol never mind I did a very bad job of manually merging the PR [02:06:21] Ah I have done that :P [02:06:46] more precisely I loaded LEMsystems as an html in orbiter lol [02:06:47] Its 4 or 5 valves in the configs and the equal valve in the project file [02:06:55] But you can see it all there I am sure [02:08:54] And you can add the debug lines if you want to watch the LM tunnel and LM cabin pressure while in the CM [02:16:43] Hopefully those changes help [02:16:50] I am calling it a night, take care! [02:17:23] night! [11:52:29] .tell indy91 so i completed the lem stuff for day 3 and then for day four the crew suddenly died [11:53:04] .tell indy 91 so i completed the lem stuff for day 3 and then for day four the crew suddenly died [11:53:47] .tell indy91 so i completed the lem stuff for day 3 and then for day four the crew suddenly died , sorry i had to do this three times i had to change my username [12:12:55] hi [12:13:08] hey [12:13:42] guess the LM ECS is not fully fixed yet [12:13:51] nope [12:13:58] the LVDC is though [12:14:06] so Apollo 17 and other launches will work again [12:14:21] would i still be able to do loi even if the crew is dead [12:16:03] hmm, that probably was caused by the LM ECS bug though, right? [12:16:11] Do you have any ECS displays? [12:16:19] are they off scale high or are the needles gone? [12:16:21] in the CSM that is [12:16:22] yeah it was after i entered the lem [12:16:27] needles gone [12:16:34] that's the ECS bug then [12:16:41] so, I wouldn't continue with that [12:16:53] the crew being dead is not so much the issue [12:17:09] there is no simulation of e.g. switches not working because of that [12:17:23] but your whole ECS and cooling loops and other things are now all bad [12:17:50] so I would wait for the bugs to be fixed and then continue with a scenario where the crew is still alive [12:18:00] okay [12:18:25] do you think that might be done today or maybe tomorrow? [12:19:40] no idea, these ECS issues are really annoying [12:19:52] if I quickly find the issue then it could be today, sure [12:30:37] astronauthen96, did rcflyinghokie do any changes to your scenario yesterday evening? [12:51:28] nope [12:51:44] i messed with the lem pressurization before entering it [13:57:45] Good morning [13:58:49] hey [13:59:04] so there are still ECS issues [13:59:15] Yeah [13:59:32] Alex had a bunch last night [13:59:33] your LM pressurization changes aren't very stable at time acceleration either, quite large valves [13:59:40] I had 2 out of about 20 tests at 30x [13:59:52] These were without the press changes [14:00:02] but the first NaN I encountered was in SUITCIRCUITHEATEXCHANGERHEATING [14:00:13] I haven't tweaked the suit loop at all yet [14:00:21] most valves are 0.5 in size [14:00:26] I might try 0.05 [14:00:45] I can probably reduce the valve sizes in the pressure equalization, the size in the code seemed to be the key to the timing [14:01:03] unfortunately it's very difficult to track down the first NaN for mass, pressure or Q [14:01:06] But I want to keep the valve size connecting the tunnels large [14:01:35] Yeah I can imagine [14:01:35] I can find the first NaN when the tank is updated, but at that point it's already full of NaN substances [14:02:01] so it happens during flow or thermal update or something like that [14:02:39] Yeah [14:05:11] Be careful with the suit loop though, reducing flow sizes around the co2 absorber made it very ineffective in scrubbing [14:05:18] Same with the water sep [14:06:38] well, what can I do? I have no other idea what to change [14:07:07] Well, go ahead and change them, but I just mean make sure you check and see how much flow is still going through them after [14:07:50] no flow at all, I have only tested with an unpowered LM so far [14:08:26] Yeah you get hardly any flow without the suit fans [14:08:55] That creates the pressure differential that makes the flow increase through them [14:09:21] yeah [14:09:25] if the LM doesn't even survive TLC then there is not much point in tweaking CO2 scrubbers [14:10:02] so, what caused some of the NaNs was the negative Q thing [14:10:13] that made some stuff go to NaN instantly [14:10:26] but the issue we have right now is mostly numerical precision I think [14:10:53] at time acceleration some tanks still get tiny masses [14:11:11] and then a little bit of Q makes the pressure and other things explode [14:11:43] Could more isolation help? [14:12:14] maybe [14:13:02] one thing I could do is use a feature of the systems simulation [14:13:13] I do see things like small increases in pressure during coast [14:13:15] I can limit the timestep length of a systems update [14:13:40] so at e.g. 50x it would update the systems 10 times or so per timestep [14:14:04] that will be bad for performance of course [14:15:06] Right but there is a little margin (at least on my system) that would handle it I think [14:15:58] @rcflyinghokie my crew died on day four [14:16:15] Were you flying with NaN's? [14:16:16] yeah, if the NaNs reach the CSM then the crew dies [14:16:30] yes [14:16:40] Oh I forgot to ask, was that Apollo 10 scn you sent me older? [14:16:43] and of course i entered the lem on day three [14:16:55] yes it was from i think september 2017 [14:16:58] Because it probably had old SPS gains [14:29:44] hmm, there already is some trouble on the very first LM timestep [14:29:52] SUITCIRCUITHEATEXCHANGERHEAT [14:30:19] it tries to remove more Q than there is in the connected tank [14:30:43] which SUITCIRCUITHEATEXCHANGERHEATING [14:30:46] which is* [14:31:16] we have some protection against that, but it's really not ideal [14:34:10] we probably should implement a better heat exchanger equation [14:34:23] double Q = (source->GetTemp() - target->GetTemp()) * length * dt; [14:34:27] that is super simple [14:36:26] Yeah [14:37:13] They are always on as well [14:37:34] I wonder if we can throttle them based on flow or something like that [14:37:49] Effectively turning them off or almost off when nothing is flowing through the tank [14:40:14] Or if the tank is below a certain level [14:40:39] or do our research and implement some better and more complicated equation [14:40:44] Or simply adding some code that checks how much Q is available to transfer and creates a limit [14:41:19] That way it cannot cause a negative Q condition [14:41:45] that is already done [14:42:49] void h_Tank::thermic(double _en) { [14:42:50] if (-_en > space.Q) [14:42:50] _en = -space.Q / 10.0; //not really possible, [14:42:51] //but happens on small tanks combined with large [14:42:51] //time acceleration [14:43:38] Then how does it pull more Q than is available? [14:44:07] it doesn't, it just tries to [14:44:18] "we have some protection against that, but it's really not ideal" [14:44:37] but what this will cause it the Q becoming lower and lower anyway [14:44:38] I think [14:44:50] just not instantly [14:47:39] What about an additional check that stops the HX if Q reaches a number close to zero in a tank? [14:47:54] yeah, might be possible [14:48:11] but still, I instead would like to have a better calculation method that takes that into account anyway [14:48:12] It doesnt break any thermo laws technically [14:48:29] Ah I see what you are saying [14:50:39] or maybe just an equation that does an estimation of temperature change to due the Q flow [14:50:45] due to* [14:51:05] because the problem really is, the Q is calculated from the initial temperature [14:51:21] but a tank that is nearly empty will very quickly change its temperature [14:51:36] that is not considered for the Q flow though, only at the next timestep [14:52:02] Is temperature and length the only thing that takes into account? [14:52:14] No heat capacity or mass? [14:52:37] seems like it [14:53:15] well heat capacity would be tricky [14:53:29] because more than one substance can be in the tank [14:53:41] True [14:54:58] For a gas mixture a mole fraction could be used to calculate the heat capacity [14:55:04] just a quick interjection, is there any way we could obtain a scan or photos of this: https://www.si.edu/object/nasm_A19980018000 [14:55:36] Could be possible, I was considering going there this weekend as it is [14:55:47] I meant to ask you something before you moved to Alaska, it might have been that, hahaha [14:56:11] Haha well Alaska got pushed back a month or so [14:56:16] ah, I see [14:56:17] So I am in DC a bit longer [14:56:35] I dont know how they treat things on display, assuming that is on display [14:56:44] it might be [14:56:53] I will send an email and see if I get any info [14:57:11] That would be great to have [14:57:50] For the heat capacity thing, an approximate heat capacity can be computed for a gas mixture, and of course all the liquids are one substance [14:58:15] Then you could use a simple Q=mCdT style computation [14:58:30] That would take mass in the tank into account [14:58:48] yeah, that specific one has the backup erasable load [14:59:06] I especially want that for the DAP [14:59:37] the G&C Checklist, or Operations Checklist as it was still called during 11 is not on display, it says so on the page [15:00:00] I'm surprised that is not taken into account at all [15:00:04] hmm [15:00:19] of course it's a heat exchanger, so the two part of it don't directly touch each other [15:05:14] There are some differential equations that govern heat exchanging its been years since I have used any of them haha [15:05:29] Back in a sec [15:22:50] When i get hone tonight ill request info on that doc from the archive and see if i can make an appointment [15:22:53] Home [15:23:59] that would be awesome [15:24:31] unless we find yet another CSM Data Book that checklist is the best padload source for Apollo 11 CMC [15:25:01] so in doubt, all I need is a only a few pages of it [15:25:55] did you get my last 3 messages? [15:26:04] No i lost connection [15:26:08] that would be awesome [15:26:10] unless we find yet another CSM Data Book that checklist is the best padload source for Apollo 11 CMC [15:26:12] so in doubt, all I need is a only a few pages of it [15:26:23] Well hopefully they give me an ok [15:26:39] I dont know how stingy the NASM is on those [15:26:58] Apollo 10 would be equally good, and that checklist has been for sale, but they only have photos of other pages [15:27:21] I guess it's the most boring page to photograph [15:27:26] just a bunch of numbers [15:27:41] Haha they want to make it look all technical [15:28:23] You could request a page pic from the seller to verify authenticity maybe [15:28:44] nah, these are sales that were many years ago [15:28:50] Oh gotcha [15:29:07] double Q = (source->GetTemp() - target->GetTemp()) * length * dt; [15:29:07] [15:29:08] if (source->energy < Q) [15:29:08] Q = 0; [15:29:15] the most simple solution :D [15:29:58] Hm would a zero Q create a divide by zero problem though [15:30:10] no, I have checked [15:30:19] Excellent [15:30:27] that Q just gets added or subtracted [15:30:36] and then the Temp gets recalculated [15:31:04] Using the old equation? [15:31:24] Yep that line was cut off on my phone [15:31:25] in the thermal function of the tank class [15:31:54] which I won't mess with [15:33:28] Do you think keeping the valve size large between the tunnels will cause a problem? [15:34:07] I can reduce the others and increase the size of the press equal valve to maintain press times [15:34:39] it's a bit unstable at high time acceleration. But it's going to cause any NaNs, I think [15:34:51] I will still play with it [15:34:59] e.g., the dP needle goes to 0 or below 0 even during LM pressurization [15:35:16] and when you then switch to 1x again it's back where it should be, 2 PSI at the time [15:35:55] So same as say the glycol pressure during acceleration [15:36:10] Goes hack to normal when 1x is resumed [15:36:26] Back [15:41:41] evaporator has the same issue [15:43:49] only ever in the LEM, but that has to do with tanks that are nearly empty [15:45:49] so it definitely not that you just did a bad job with creating the LM ECS and its valve sizes and so on, haha, the unpressurized and unpowered LM is causing us issue that we never had before in the CSM [16:06:46] here is another thing I don't understand [16:06:54] thermal class has a parameter "energy" [16:07:19] hydraulic class has a parameter h_volume which has a "Q" [16:07:29] these two are getting syncronizes occasionally [16:07:37] but it's two variables for basically the same thing [16:08:06] Weird [16:08:30] I did notice my last nans were also in the water tanks [16:10:07] should all heat exchangers work in auto mode? [16:11:01] SUITCIRCUITHEATEXCHANGERHEAT and SUITCIRCUITHEATEXCHANGERCOOL are always on [16:11:06] -1 in the config [16:12:42] as are some others [16:14:26] so these sometimes try to pull more Q out of the target tank, not just the source tank [16:19:32] Well they only heat not cool, i thought we decided leaving them always on was more realistic [16:19:58] The only other present option is a temperature controller which isn't realistic fir these [16:22:28] ok, then I'll just extended the check for the Q flow to both connected tanks [16:22:32] this is just testing anyway [16:39:50] hey [16:40:15] hey Alex [16:40:37] still getting nan's unfortunetly [16:41:13] yes, working on it [16:41:19] probably caused by the suit loop [16:41:25] which I hadn't modified yet [16:46:54] https://www.dropbox.com/s/g6szu1tyee5is1z/Apollo%2011%20MCC%20-%20Launch%20T-60s%200047%200003%200013.scn?dl=0 [16:47:05] Thats the scenario after it happened, if it helps [16:47:55] CABIN 6170.000000 1 1 1 1 0.30000001 0.60000002 0.01000000 0.01000000 [16:47:56] CHM 0 0.000005364710 0.000005359288 147809018955598790656.000000000000 [16:47:56] CHM 2 0.000005909867 0.000005909828 366028685065665445888.000000000000 [16:47:56] CHM 4 0.000003379291 0.000003379291 43906355150805303296.000000000000 [16:47:57] [16:47:58] CSM cabin, haha [16:48:05] looks a bit unhealthy [16:48:28] but this is the numerical precision kind of issue [16:48:37] the other cause of our issues should be fixed [16:49:25] rcflyinghokie, any objections to changing the suit loop valve sizes to 0.05? Let's get this NaN nonsense under control before we worry about anything else. [16:49:51] and I have a few other things making sure the energy levels of a tank don't drop too much [16:57:21] Nope go for it [16:58:09] If you want to bring the tunnel valves down you can as well, i will adjust the press eq valve to compensate [17:00:12] so, the biggest issue is that the dP between CSM cabin and tunnel goes down to 0 with time acceleration [17:00:37] so that prevents the LM from pressurization any further [17:00:41] or at least not as quickyl [17:00:57] but that is not causing any NaNs, I think, so I let you do any adjustments to that [17:01:43] update pushed [17:01:59] I am not confident that this will fix all of the remaining issues, but it might make it better [17:02:46] I am better at fixing the LVDC, which I did earlier today :D [17:03:57] the IGM needs initial values for the pre and post MRS S-II flight times [17:04:14] and I changed only the pre MRS time when I implemented the S-II inner engine cutoff [17:04:18] the default parameter for this [17:04:31] now I also changed the post MRS time and it all works again [17:07:03] Apollo 8 and AS-504 as planned in 1967 did the S-II MRS much earlier than later missions. Hence the default parameter issue. [17:08:27] Sorry was driving. I never had that issue with dp in time Accel [17:08:35] Not after my changes [17:08:57] at 50x that happens [17:09:03] it's not as bad in 10x [17:09:48] Ah i never went above 30 [17:12:10] 50x I was I usually use during TLC [17:12:55] now that I think about time acceleration issues, I still have to do a LVDC fixes for that as well [17:13:06] AlexB_88 knows that time acceleration beyond 50x is bad for the LVDC :D [17:13:29] Haha [17:13:51] I have many SIVB's in solar orbit because of it [17:15:33] indy91, Ill try the update right now! Will my post LM ejection scenarios still work (post-lm ejection, but before the nan's) [17:15:52] Or I may just backtrack to before LM ejection [17:16:48] I've changed some things in code and reduced the size of the suit loop valves to 1/10 of the former size [17:17:01] so some of the changes can be used in your current scenario [17:17:21] you could continuing until you get NaNs, then revert to LM ejection [17:17:23] up to you [17:17:48] Ill just go back to LM ejection, I wasnt very far ahead anyway [17:17:58] ok [17:18:16] Tell me how the new spot for lm press works put [17:18:27] Out [17:21:46] new spot for LM press? [17:21:47] Here is my pre-lmejection scenario from yesterday: [17:21:48] https://www.dropbox.com/s/mqsrk772u6rzkdm/Apollo%2011%20MCC%20-%20Before%20LM%20Ejection.scn?dl=0 [17:22:19] I used the scenario that you created a few days ago and did the Saturn Systems modifications manually [17:22:22] morning! [17:22:30] hey Mike [17:22:42] the CSM tunnel and press equal valve stuff [17:22:50] maybe I did it wrong [17:23:00] could explain the dP issue I was getting at 50x [17:24:02] thewonderidiot, Skylab document there yet?? :D [17:24:38] checks his email [17:25:52] no, it is in Richmond [17:26:00] I have no idea which Richmond because they didn't bother to put down a state :P [17:26:30] oh wait [17:26:35] ebay's tracker is just bad [17:26:40] USPS says it is out for deliver [17:26:41] y [17:26:43] so tonight! [17:26:49] awesome [17:27:15] in other news, yaAGC did its first cycle-accurate radar interaction this morning [17:27:25] we have too many cities and villages with the same name in Germany, even specifying the state wouldn't always help [17:27:36] haha [17:27:45] indy91, I noticed that Apollo 11's SIVB actually does the slingshot maneuver now. Is the resulting trajectory accurate? [17:27:46] usually they use geographic features, a river or a mountain or something like that [17:28:36] https://pastebin.com/raw/A3YJmu0M [17:28:53] it started with an old reading in RNRAD, and correctly shifted in the desired answer with precisely the right timing :D [17:28:56] AlexB_88, it's only doing the LOX dump right now, not the APS burn to depletion [17:29:07] ah, ok [17:29:09] so it might or might not hit the Moon [17:29:31] well, it's doing the Apollo 8 LOX dump for all missions right now [17:29:37] If its richmond va im near it kinda [17:30:22] thewonderidiot, awesome [17:30:59] USPS tracking doesn't even show richmond, so I have no idea what ebay is doing [17:31:16] anyways... I discovered a new way to break the radar interface last night [17:31:20] Apollo 8, 10 and 11 slingshot maneuver is letting the S-IVB fly past the Moon on the opposite side of the Moon as the CSM(+LM). So with only a partial DV it might hit the Moon right now [17:31:41] I've never tried it, AlexB_88, so you will see :D [17:32:28] thewonderidiot, another way than what a bunch of Tindallgrams were worrying about? [17:32:37] yeah [17:33:11] the software never would have done this, it was probably obviously a bad idea [17:33:30] but you should never try to stop a radar cycle after you have started one by clearing channel 13 bit 4 [17:34:38] https://i.imgur.com/SJVtNWg.png [17:34:49] it stops the gate pulse counter from counting, but doesn't stop the gating pulses from going out [17:35:03] so if you unset the bit, the radar is measuring indefinitely [17:35:16] until you set the bit again and let the counter continue [17:38:56] yeah, I am sure this was pretty clear to the software people [17:39:07] yep [17:40:08] anyways, yaAGC simulates it, along with the counter wrapping at 16 if you so happen to decide to simulate a random initial count there [17:40:43] I'm not simulating the Tindallgram problem yet -- the closest I can do in yaAGC is detect when the probability of it happening is about 33% [17:40:50] or 25% rather [17:41:49] because I can tell if a sync pulse is going to happen at the same time something is writing to channel 13, but the sync pulses only covers about 3 timepulses of the 12 that make up an MCT, and one particular timepulse of the 12 must be covered [17:42:00] and the phasing is totally random [17:45:30] rcflyinghokie, it may be a good idea to include LM PWR switch to RESET before going to CSM in the checklists. I remember flying a mission where I omitted to do that before going to LM PWR - CSM and it never actually charged the LM batteries, and had to manually edit the scenario before PDI [17:46:04] this problem may have since been fixed though, im not sure [17:46:17] Ah probably smart was that in the actual lm pwr checklist? [17:46:35] hmm let me check again [17:58:14] in the Apollo 12 checklist it does not say to go to RESET actually, just: [17:58:21] SYS Test - 4D [17:58:29] LM PWR - CSM [17:58:51] I guess it should work without having to 1st reset afterall [18:01:12] i see you guys changed the checklist [18:13:10] Thats what i thought [18:13:23] I think i habitually reset first though haha [18:13:35] Just rearranged some things [18:21:59] oh, indy91 [18:22:12] I think I figured out that Sundance used 42 counts for its RHCs yesterday [18:22:43] I'm making the assumption that the rate command ends up scaled 45 deg/sec, but that is true for Aurora, Sunburst, and Luminary, so it makes sense that Sundance would have a consistent scaling [18:23:36] I think the RHC scaling PCR mentioned in the GSOP is a different thing [18:24:11] apparently during Apollo 9 they found the RHC to be too sensitive for fine maneuvers, so they scaling was reduced to make it less touchy, and that felt better on the simulators [18:24:37] but they decided they wanted to keep the 20 deg/sec at max deflection, so the quadratic equation was implemented a few revisions later as the answer [18:38:01] lol [18:38:52] the timeline of the report I am referencing there clearly has it wrong, though, since the quadratic equation was implemented in Luminary before the Apollo 9 launch [18:53:22] woohoo I finally have a pressurized LM! [18:56:46] :D [19:00:01] took 2 hours btw [19:04:55] thewonderidiot, yeah, the scaling is 0 to 20°/s linear with the ATCA and that is everything but sensitive [19:05:10] uhh, everything but fine control I mean [19:18:09] haha right [19:18:40] the study guide says for normal control, the RHC counts are multiplied by 177 decimal to calculate the rate command [19:19:25] with 42 at max deflection, that works out to 20.4 deg/sec with 45 deg/sec scaling [19:19:47] for fine control it is multiplied by 34, which works out to 3.92 deg/sec [19:20:35] yes, 4°/s and 20°/s is the usual [19:20:56] but that's all in software, right? [19:21:02] V48 setting [19:21:05] yep [19:21:35] but that is what makes me think 42 is the right answer and not 32 [19:21:40] yeah [19:22:11] can the press. equal valve safely stay opened with 30x time accel during the entire TLC? [19:22:40] I think so [19:25:29] as soon as i open that valve it goes to NaN [19:27:31] so, when this NaN thing gets fixed will my scenarios have to be fixed? [19:30:01] Did you build the latest update from this morning? [19:30:21] yes [19:30:39] old scenarios will need changes again, yes [19:30:44] okay [19:31:24] if everything goes to NaN when you open the press equal valve, then you LM is already broken [19:31:28] yor* [19:31:29] your* [19:31:54] could that be fixed? [19:32:03] astronauthen96, what I did after todays update is go back to a scenario before the LM was created, like just before LM ejection from the SIVB [19:32:44] and do you get the nan [19:32:50] no nans up until now (MCC-1) [19:33:03] are you using time acceleration [19:33:10] yes 30x [19:33:20] you need a fresh LM basically [19:33:29] i have one scenario before lem ejection [19:33:39] yeah that should work [19:34:02] did you scrub mcc1 [19:34:21] nope, 17 fps [19:35:11] you pretty much have to do MCC-1 on Apollo 11 [19:35:23] in real life they didnt i dont think [19:35:28] you could delay to MCC-2 if you want [19:35:37] they did a 20fps burn for mcc2 [19:35:43] they may have done MCC-2 right [19:35:56] yeah im reading the mission report [19:36:31] mcc2 was 21,2 fps [19:37:27] when i load my scenario the lem to csm power is on do i have to just go to reset? [19:38:07] well technically according to the procedures, no. But I like to do it just to be sure lol [19:39:14] I do LM PWR - RESET, then LM PWR - CSM [19:45:10] so is the NaN fully fixed or no? [20:12:47] we don't know. [20:12:56] I have fixed a few more things today that might prevent it from happening. [20:28:18] indy91, btw just a report on the TLI performance from yesterday: Went very well EMS resulting DV was about 50 fps but that is about the same as before. MCC-1 DV was 17 fps [20:28:50] and I guess there was an evasive maneuver in between [20:28:55] lem/csm pressure difference is going down [20:28:56] yes [20:29:20] EMS difference could be more an RTCC MFD issue than LVDC [20:29:37] do you remember the DVC? [20:29:45] and for the evasive maneuver the residuals were -6.0 [20:29:51] MCC-1 DV before evasive: 15 fps, and after evasive 17fps. Surprising considering the evasive itself is 19 fps [20:30:23] EMS DVC was 10485.0 [20:30:38] astronauthen96, you are always getting these high numbers. You sure you are setting the right number in the EMS counter? [20:30:49] yes [20:30:51] 19.7 [20:31:01] total DV [20:31:07] yep [20:31:11] hmm [20:31:37] 6 ft/s difference is a lot considering the burn is only 19.7 [20:31:56] maybe he meant -0.6 [20:32:03] nope [20:32:06] jalexb88, "Delta-VC prime: 10,435.6 fps" is the historical PAD number [20:32:20] it was a long rcs burn for the residuals [20:32:50] and @jalexb88 how long did it take to to pressurize the lem? [20:32:51] wow then thats precisely what the LVDC did burn then 10485 minus 50 [20:32:54] what did you all set in V48? mass for both CSM and LM and also pitch and yaw trim gimbal angle? [20:33:17] that was to @astronauthen96 [20:33:20] astronauthen96: 2 hours [20:33:39] well i calculated a maneuver pad for the weights [20:33:53] and the trim angles were 00082 and 00036 [20:34:02] this was before i maneuvered to the attitude [20:34:07] who I know hat happened [20:34:29] you put in the LM weight of LM+SIVB as the pad is calulated before LM ejection [20:34:44] oh [20:34:47] I almost made that error too :D [20:35:02] LM weight is 33863 [20:35:03] it was before lem ejection [20:35:23] yeah the lem weight i entered was 63534 [20:35:49] yeah the checklist calls to make the maneuvver pad for the evasive burn, when you're still attached to the SIVB, and RTCC MFD will wrongly take that weight into account too [20:35:51] that explains it [20:36:03] the CMC will then have used the short burn logic as well [20:36:12] in a quite wrong way [20:36:34] with the short burn logic (burn time smaller than 6 seconds) the CMC already calculates the cutoff time before ignition [20:36:40] so i guess mcc1 might be a bit longer [20:36:41] so the measured acceleration is never relevant [20:36:50] yeah, but not too much longer [20:37:41] so the latest build says it reduced the lm pressure time to 45 minutes [20:38:00] "Record Evasive Maneuver PAD" is before LM ejection in the flight plan [20:38:30] so, when I work on the MCC for Apollo 11, I will figure out some logic for this, so that you don't accidentally plan a maneuver docked to the S-IVB [20:38:34] yeah the checklist is indeed correct [20:38:53] @jalexb88 you said it toke you two hours? [20:38:57] took* [20:38:58] yeah [20:39:07] I guess rcflyinghokie lied to us :D [20:39:17] I may not have followed the procedure completely correct though [20:39:52] oh, you should probably overpressurize the CSM a bit [20:39:56] that makes it quicker [20:40:56] right [20:41:13] initially is says to open direct 02 to get the CM to 5.7 [20:41:25] but it takes way more then 2 minutes to do that [20:41:49] I probably carried on with only like 5.1 [20:42:20] maybe opening the 02 repress valve to help it would have helped [20:42:34] O2* [20:43:24] that worked [20:45:32] opening the repress O2 valve? [20:45:55] yes [20:45:56] the S-IVB vessel docked to the CSM even contains the mass parameters of the LM, so for the Maneuver PAD I could let it get those numbers and use that for the LM mass calculation [20:46:01] its at about 5.7 now [20:46:15] but i am still getting an o2 high warning light [20:46:26] great [20:46:32] yeah I think thats normal [20:46:37] well, for now [20:46:44] the CSM needs some ECS rewiring as well [20:47:07] let us know how long it takes to pressurize the LM [20:47:08] the wrong tank or pipe is used for the O2 Flow High sensor [20:47:24] its at about 2psi [20:47:43] @jalexb88 did i tell you that my crew died on day 4 [20:48:34] I hope you had a sad and meaningful speech ready for you fallen hero astronauts [20:49:11] the CSM simulates the conditions under which a crew can die (lack of O2, too much CO2 or acceleration) [20:49:14] LM doesn't yet [20:49:16] not yet but i might prepare one [20:49:25] but the whole NaN business caused this, for sure [20:50:19] and does the hatch even open? [20:50:30] suddenly the atmosphere became filled with sodium nitride [20:50:34] yes, it does, when the pressure difference is really low [20:51:12] does it make a noise when it opens? [20:51:38] yeah, I think so [20:51:43] and the hatch bitmap will change [20:52:10] what about the hatch in the lem? [20:52:24] both forward hatch and overhead hatch can be opened [20:52:30] now im at 1.5 psi with no time acceleration [20:52:39] pressure difference? [20:52:45] you need 0.08 PSI dP [20:52:54] yes [20:53:11] 0.08 or lower [20:53:14] I dont get it I could find no mention of NaN's anywhere in the transcripts [20:53:16] :p [20:54:00] did you check the anomaly report supplements? [20:54:00] haha, is there any AGC program alarm like that? [20:54:24] maybe 13 had a few NaN's [20:54:26] there is a square root failure alarm I think [20:54:42] everything is a number to the AGC :D [20:55:56] speaking of that, in the LVDC it can happen, if your S-IVB can't make orbit, that the log function returns NaN [20:56:18] yeah, sqrt called with negative argument in the interpreter is 1302 [20:56:19] I might replace that math library function with the one actually used in the LVDC [20:56:21] probably the closest thing [20:56:24] heh [20:56:24] the EDD has the functions used [20:56:27] nice [20:56:35] sounds like a good plan [20:56:51] especially for log I want to do that [20:57:11] that is what has been causing CTDs in the past. And LV GUID light currently [20:57:18] but only because I check for NaN [20:58:52] during the IGM iteration, if more than the complete mass of the S-IVB has to be burned to make it into orbit, then the logarithm becomes bad [21:00:15] how does the AGC do it? [21:00:37] not that it ever really has to solve thrust integrals... [21:00:58] I don't really know anything about that [21:01:04] @indy91 was it just you that did the ecs changes? [21:01:05] probably unsurprisingly :P [21:01:41] astronauthen96, most of the LM ECS has been implemented by rcflyinghokie. I did a bunch of coding and code fixes. [21:01:54] and the CSM ECS has been implemented before I was a NASSP dev [21:02:37] well in that case, praise both you and @rcflyinghokie [21:02:43] you probably knew i was going to say that [21:03:15] haha, thanks [21:04:07] pressure difference is at 1psi [21:05:10] @jalexb88 i cant remember have you use time acceleration yet? [21:05:18] 30x [21:06:05] did you stop it exactly at zero? [21:06:24] stop what? time accel? [21:06:32] no the pressure difference [21:07:04] I left the pressure equalization valve open, even after reaching 0, as per the checklist [21:07:28] the needle will settle at 0 on its own [21:08:59] flow goes in both directions [21:09:04] so naturally, it will equalize [21:09:54] thewonderidiot, https://github.com/virtualagc/virtualagc/blob/master/Comanche055/CSM_GEOMETRY.agc#L259 [21:10:08] that's all I found [21:11:59] the LVDC algorithm only accepts an input parameter range from 0.125 to 8.0 [21:12:20] so not exactly close to 0 [21:13:14] right [21:15:44] well just had a big self inflicted NaN, I hit CTRL-D instead of CTRL-S... [21:17:58] hmm, that should call clbkDockEvents [21:18:27] and so undock the CSM and LM "safely", as in, the ECS are disconnected properly [21:18:47] but there are giant valves sucking in all the air from both vehicles at that point [21:18:53] I guess you can the hatches open... [21:18:55] had* [21:19:09] I didnt actually check if I had a NaN, probably didnt [21:19:31] as far as I can see, that would be a bug if you had NaN. [21:19:51] a stress test for flow out of the cabin :D [21:19:55] I could have just re-extended the docking probe and redocked, and re-pressurized the LM [21:20:20] but Lazy me I just went back to my previous save :D [21:22:55] I may pull the D key out of my keyboard [21:23:33] it's pretty overrate [21:23:48] I know I never use it hehe [21:26:06] and then you remember P52 [21:28:03] I can just maneuver with RCS when I need to slew it right [21:28:41] ok ok not a good plan to take the D out of my keyboard :D [21:28:48] that's such an inaccurate Grumman procedure [21:36:32] I figured out the LVDC algorithm for the natural logarithm in code, but just when I was done I remember that we actually have more documentation on that. [21:37:27] ah no, we have that for the RCA-110A [21:38:02] @jalexb88 were you using time acceleration when the pressure was dropping because when i do 10x it seems to go up a bit [21:39:56] yeah I did 10x during the whole LM pressure equalization [21:40:26] whats your cabin pressure now? [21:40:37] just below 1 [21:40:43] cabin pressure [21:40:49] oh [21:40:53] on the main panel [21:40:59] under 5.5 [21:41:13] under 5 [21:42:08] you can use the repress O2 valve to bring it back up to 5.7 that may help speed things up [21:42:18] okay [21:43:21] so i just leave the hatch valve open? [21:43:47] after you do that the delta pressure will initially go up a bit maybe to 1.5-2 dPSI which is normal as youve increased the CM side pressure [21:43:54] then will go back down after [21:44:04] yes leave the hatch valve open [21:45:19] thewonderidiot, how do you think would the LVDC react to an input value outside the allowed range? [21:45:26] oh and you have to refill the repress package quite often [21:45:33] would it have the log stored for 0.125 and 8 and return that? [21:45:46] I have no idea [21:45:50] does the document not say? [21:46:04] unfortunately not [21:46:14] that's not an unreasonable guess [21:46:20] it dosn't even give the algorithm itself [21:46:23] just the equations [21:47:25] oh, 0.125 and 8 are quite convenient for that [21:47:52] it's the same value to return just with plus and minus [21:47:59] -2.07944 and 2.07944 [21:48:22] so one memory slot saved :D [21:54:05] hahaha [22:02:48] night [22:11:37] well im off too, night! [22:29:42] Good morning/afternoon/evening/night! [22:33:56] HEY [22:34:07] s/EY/ey [22:34:09] :P [22:34:40] hi [22:35:53] What's up? [23:04:57] just restarting apollo 11 all over again [23:05:41] i think indy91 fixed the lem ecs bug so i had to get a scenario before lem ejection i was on day 4 loi day [04:17:15] .tell rcflyinghokie so, indy91 might have fixed that nan bug and those scenarios that you fixed for me seem to be fixed too and i have some more that need to be fixed as well i will post the scenarios here [04:22:05] .tell @rcflyinghokie https://www.dropbox.com/s/opaklussg7bhq2h/END%20OF%20DAY%202.scn?dl=0 [04:22:46] tell @rcflyinghokie https://www.dropbox.com/s/bftp66chzmig6ep/BEGIN%20DAY%203.scn?dl=0 [04:23:13] .tell rcflyinghokie https://www.dropbox.com/s/bftp66chzmig6ep/BEGIN%20DAY%203.scn?dl=0 [04:23:47] .tell rcflyinghokie https://www.dropbox.com/s/l5vv7rfrxxebc5v/END%20OF%20DAY%203.scn?dl=0 [06:56:02] .tell indy91 https://drive.google.com/open?id=1idlUtzPfPjnoPk9YWetFXX7wSASlTiAq you're welcome [11:49:11] . [12:00:38] hey [12:02:28] @indy91 for those scenarios that @rcflyinghokie changed for me, if i dont get the NaN when i open that lem pressure valve, does that mean i have a good lem? [12:06:00] hey [12:06:18] well, that means your LM is still good, yes [12:06:28] doesn't guarantee the issue doesn't happen later though [12:10:49] i have three scenarios that still need to be fixed [12:10:57] from day three [12:12:02] fixing them is tricky, I'm not sure I can properly do that. You might have to refly the mission. [12:12:09] yeah [12:12:55] if rcflyinghokie gives me a pressurized lem do you think it would fix it? [12:14:10] sure, but there is still no guarantee that it will stay that way [12:14:33] I hope the issue doesn't happen anymore, but only lots of testing will tell [12:15:00] yeah i am on a scenario saved on day two and so far i am not getting the NaN [12:15:33] when i open the vavle the pressure gauge goes down slightly [12:16:29] is that a scenario where the LM is already pressurized, or not? [12:16:42] it was on that rc fixed [12:16:45] one* [12:16:59] that was before you made those changes [12:17:18] yeah the lem is pressurized at is just above zero [12:26:57] and, would it be possible to copy the lem state from my current scenario to the other ones that need to be fixed? [12:28:14] yes [12:28:30] in the LM part of the scenario you will have to copy over everything between [12:28:43] and [12:29:13] i will try that [12:44:06] so i created a backup copy of the unfixed scenario and i lost all power [12:44:31] do you think you could try to do it for me when you have the time? [12:47:39] I can try [12:48:11] can i send them on dropbox [12:50:28] here is the one with the pressurized lem https://www.dropbox.com/s/6v2ewit2du8tdaq/BEGIN%20DAY%202.scn?dl=0 [12:51:05] and i will give you the ones that need fixing [12:51:22] https://www.dropbox.com/s/opaklussg7bhq2h/END%20OF%20DAY%202.scn?dl=0 [12:51:35] https://www.dropbox.com/s/bftp66chzmig6ep/BEGIN%20DAY%203.scn?dl=0 [12:51:45] https://www.dropbox.com/s/l5vv7rfrxxebc5v/END%20OF%20DAY%203.scn?dl=0 [12:58:45] https://www.dropbox.com/sh/s1u13bge3l84rug/AAA5puxRDUJ9O608RWziiv6ja?dl=0 [12:59:01] can you access that? [12:59:12] yes [13:02:47] good, I hope those scenarios are fixed [13:04:08] still getting the NaN i will just wait for rc to try and fix them but for right now ill just start day 2 and use time acceleration [13:06:44] oh, I see, in those scenarios the CSM is already broken as well [13:06:49] I only fixed the LM [13:07:23] oh [13:07:43] what do you mean broken? [13:08:29] CSMTUNNEL 117.600000 1 1 0 1 0.00100000 5.00000000 0.00010000 0.00010000 [13:08:30] CHM 0 0.000000000000 0.000000000000 nan [13:08:30] CHM 2 0.000000000000 0.000000000000 nan [13:08:31] CHM 4 0.000000000000 0.000000000000 nan [13:08:32] [13:08:37] just the tunnel though it seems [13:08:54] do you think you could fix it [13:09:03] from the begin day one scenario [13:09:11] or day two* [13:11:05] yeah, in some of the scenarios only the CSM tunnel has the nan [13:11:33] what about the good scenario [13:11:34] because the tunnel in connected to the LM, with the pressure equalization valves closed it's not connected to the CSM cabin [13:11:44] End of Day 3 is more tricky [13:11:47] has more issues [13:12:32] if you CAN fix them you dont have to do end of day three [13:12:39] I'll try [13:12:44] End of Day 2 is now fully fixed [13:12:48] no NaNs at all [13:13:19] Begin Day 3 as well [13:13:23] great [13:13:25] thanks [13:13:29] I can copy over the state of the CSM over to End of Day 3 [13:15:24] I'm uploading the fixed scenarios [13:15:26] same link [13:15:38] I have searched through the scenario, can't find any NaNs anymore [13:15:41] i lost the link sorry [13:16:19] https://www.dropbox.com/sh/s1u13bge3l84rug/AAA5puxRDUJ9O608RWziiv6ja?dl=0 [13:17:31] Usually I would tell you to refly the mission or wait until things are properly fixed, but I might as well use you as guinea pig for the latest ECS fixes :D [13:18:30] although, your scenarios now do not have ALL of the recent updates [13:18:38] some valve sizes are still different [13:18:47] so i guess im the bug reporter [13:18:56] yep [13:19:04] and it's not difficult to tell if thing went bad [13:19:17] because usually all the ECS indications are gone at that point [13:19:44] I've done some other fixes, too, so those scenarios could be good now [13:20:09] End of Day 3 means just before the sleeping period before the landing, right? [13:20:32] If you can avoid it, don't use high time acceleration for now [13:20:55] before loi [13:21:04] day 4 is loi day [13:21:35] i typically use 30x [13:21:35] ah, right [13:22:08] would 30x be good or no [13:22:48] difficult to say. I am quite convinced that 10x is no problem right now. I usually use 50x and I give it about 50/50 that things are fixed for 50x. 30x could be ok, too [13:23:05] if things are not good then I can do some more fixes to your scenario [13:23:22] .tell rcflyinghokie you dont have to fix them now @indy91 gave me a good lem with no NaN's [13:23:32] okay [13:25:50] and as for loi, mcc4 probably wont be required so should i do that landing site refesmmat with the mcc option just like with apollo 10? [13:26:16] not the ls during tlc [13:28:39] yep [13:29:10] did you burn MCC-3? [13:29:36] procedure wise Apollo 10 and 11 are very similar [13:31:50] i think i did mcc3 [13:32:27] i think the ls during tlc refesmmat is for two maneuvers right? [13:33:21] yes, it was a bit difficult to take two maneuvers into account, so I added that as a separate REFSMMAT calculation option [13:33:27] it's named a bit bad [13:34:33] because even with a scrubbed MCC-4 you are calculating the LS REFSMMAT during TLC [13:34:52] but you are not using the "LS during TLC" option for it [13:34:58] so I have to come up with a better name for it [13:37:23] Good morning [13:37:49] hey Ryan [13:37:53] Haha hey [13:37:56] TL;DR I fixed the scenarios [13:38:05] Got it :) [13:38:59] I emailed the NASM last night about the checklist as well I will keep you apprised of their reply, and I will probably still go in person next Tuesday and talk to them in person anyways [13:39:09] awesome [13:39:24] Mike got the Skylab document he bought [13:39:38] Oh nice, what were those operational commands, what we thought? [13:39:39] finally we have a full list of the LVDC input discretes [13:39:59] do you mean the list of programmed events? [13:41:33] The operational command listing wasnt that the doc? [13:42:10] "Interface Control Document Definition of Saturn SA-513/Skylab 1 and SA-515/Skylab Backup Flight Sequence Program" [13:42:43] I'm not entirely sure what you mean with operational command listing [13:43:16] It was something you mentioned I think a while ago [13:43:19] Not Mike [13:43:24] Got it mixed up [13:43:57] commands sent to the LVDC via the digital command system? [13:44:00] "Skylab operational Command Listing", I wonder what that would be That's what I remembered [13:45:39] oh, now I remember [13:45:44] I found a reference to that [13:45:51] that's why I mentioned it [13:46:35] no, we don't have that document [13:46:55] but I'm sure it will be interesting as well [13:47:02] not that I really know what it would contain [13:47:31] in any case, this document Mike got is quite useful for Saturn V LVDC in general and extremely useful if we ever want to simulate the Skylab launch [13:48:05] at 68:50:00 and no NaN so far [13:48:18] Oh excellent, to both of you [13:48:41] astronauthen96 any time acceleration? [13:48:46] 30x [13:48:49] great [13:49:01] Oh did you get that Apollo 10 SPS thing resolved? [13:49:06] yes [13:49:12] indy fixed it [13:50:46] and for lunar orbit i am seeing go to orb rate, and go intertial what does that mean? [13:51:23] That involves the ORDEAL [13:52:13] orb rate means your pitch rate keeps you at a fixed attitude relative to your angle on the horizon and inertial keeps you at a fixed attitude with respect to the stars [14:04:47] so for mcc4 the dv is 12.5 [14:04:56] sps burn is 2 seconds [14:05:03] rcs is 1 minute and 15 [14:06:10] oh, so MCC-4 is required after all [14:06:14] which option did you use? [14:06:21] option 1 [14:06:29] I wonder if those are the default parameters [14:06:38] and not ones calculated with option2 [14:06:50] just as a test, what is the latitude it shows on the calculation page? [14:06:58] for option 1 [14:07:45] 0.17831 [14:08:59] first i calculated option two and then option 1 [14:08:59] that should be from the option 2 calculation then [14:09:05] yes [14:09:44] so am i good [14:10:00] well, the actual procedure is to use option 2 for MCC-1 and 2 and keep the parameters option 2 calculated for the option 1 page [14:10:16] and then use those option 1 parameters for MCC-3 and 4 [14:10:35] using option 2 after MCC-2 is not quite right [14:11:11] Indy91, is there any better solution to making the two tunnels basically be one other than a large valve? [14:12:07] astronauthen96, 12.5 ft/s for MCC-4 is never good [14:12:47] rcflyinghokie, I don't think so, we just have to juse a large valve for it [14:12:53] on both ends of course [14:12:57] I have it at 100 [14:13:06] @indy91 should i just burn it anyways? [14:13:07] does that make things unstable [14:13:21] astronauthen96, yes [14:13:26] okay [14:13:53] I dont know it needs more testing, i just need to find a size that makes both tanks virtually act as one [14:13:55] with sps or rcs? [14:14:29] I think i can also reduce the other valves to maybe 1.0 but i need to test it still [14:15:35] Also the repress package in the csm i think is way too small, i cant even get one repress from 4-5 psi out of it [14:15:39] astronauthen96, SPS [14:15:51] its 2 seconds [14:15:59] is that fine [14:16:06] yes, there is a chart for this [14:16:24] https://history.nasa.gov/afj/ap15fj/csmgc/5-11.gif [14:16:46] Astronauthen96, this may seem silly, but when calculating your buts do you have CSM/LM selected in RTCC? [14:16:54] Burns not buts [14:16:56] haha [14:16:58] yes [14:17:00] Bad autocorrect [14:17:02] Ok [14:17:31] so with a heavy CSM+LM you use the SPS for burns as low as 3 ft/s [14:17:53] the guideline is basically, if the SPS burn would be 0.5 seconds or more, use the SPS [14:17:56] if not, use the RCS [14:18:39] astronauthen96, an regarding the option 2 calculation, it's actually realistic that option 2 would result in a larger DV for MCC-4 [14:18:53] option 2 has the tendency to shift DV from LOI-1 to the MCC burn [14:22:09] which is undesirable for MCC-4 because accurate ground tracking becomes more difficult. Not really an issue in NASSP of course. [14:22:58] when using the RTCC MFD you need to not only play astronaut but flight controller as well, haha [14:26:21] for the ls during tlc , the attitude it gives me is always in gimbal lock [14:28:10] just lost my attitude good thing i saved before the uplinks [14:28:37] the mission rules have something about that [14:29:01] if MCC-4 would be in gimbal lock with the LS REFSMMAT, then a P30 REFSMMAT is used instead [14:29:08] okay [14:29:20] which has 0,0,0 as the IMU angles for the burn [14:29:22] i meant the sighting attitude for the p52 [14:29:37] oh [14:29:48] so the burn attitude is ok [14:29:57] Indy91 did you look at the co2 or water separator flow by chance after the valve changes? [14:30:06] not sure but i was away from the computer when it went to gimbal lock [14:30:30] rcflyinghokie, I didn't look at any flow [14:30:41] but usually i stop it and then i go to p52 and it gives me another attitude which is fine [14:30:43] I only tried to fix things for an unpowered LM during TLC [14:30:46] Ok ill try to look at that tonight [14:31:02] That and reducing tunnel valves [14:31:22] at the point we are right now with the LM ECS any functionality is a bonus. We really have to get these NaN under control before anything else. [14:31:34] Agreed [14:31:47] Just making a mental list of things to check [14:32:25] yeah, unfortunately my tweaks were rather "brute force" and any previous fine tuning you have done could be bad, sorry, haha [14:32:50] I can make it work i am pretty sure [14:33:13] Were you able to implement the pump pipe? [14:33:38] yes, the pumps are now letting flow through them when they are off [14:33:45] Great [14:33:52] but, I think some other systems still need that [14:34:35] Which ones? [14:36:09] AtmRegen class [14:36:15] only the CSM uses that though [14:36:24] so that's why I hadn't changed it yet, now I remember [14:36:29] never touch a running system [14:39:54] and no NaN yet so far [14:40:48] I guess the next critical phase for that will be during the sleeping period after LOI [14:41:01] once you start powering up the LM the chance for any issues is much smaller [14:41:03] Yeah leave the flowing in the lm [14:41:13] Csm will get changed for v9 [14:41:34] The only other csm change I might make is the repress package size [14:42:15] so which refesmmat option should i use [14:42:57] astronauthen96, is the burn attitude in gimbal lock? [14:43:07] no just the sighting attitude [14:43:12] do you want to change the REFSMMAT before MCC-4? [14:43:35] well i just started over i am calculating the pads right no [14:43:43] now* [14:44:00] if you have to do MCC-4 then you need "LS during TLC" [14:44:05] okay [14:44:38] and the refsmmat uplink always comes last right? [14:44:53] yep [14:56:40] Going into a meeting you all take care [15:08:36] the burn attitude is pretty much in gimbal lock [15:22:58] @indy91 so should i do a p30 refsmmat? [15:31:04] for MCC-4, yes [15:31:16] and then switch to the LS REFSMMAT after MCC-4 [15:31:30] okay [15:31:56] and should it be mcc or direct for the ls refsmmat [15:32:29] MCC, with the LOI-1 maneuver taken into account [15:44:19] hey [15:47:35] hey Alex [15:49:46] just completed LOI-2 and no NaN's up to now [15:56:41] that sounds good [15:57:08] if it survives the sleeping period with time acceleration then the ECS is really mostly safe now [15:58:19] yeah I did 30x [15:58:40] maybe we should try 50x too, to be sure [15:59:11] yeah, do a good safe before the sleeping period and then try 50x for a while [16:01:38] and should the p30 refsmmat be heads up or retro? [16:03:26] not retro [16:03:44] not sure about heads up/down though [16:03:49] it doesn't really matter [16:03:59] you just have to use the same option on the Maneuver PAD then [16:06:20] what burn are you making, astronauthen96? [16:06:53] mcc4 [16:07:06] ah ok [16:07:18] yeah shouldn't matter, I do heads-up for MCC's [16:37:31] what does "LM PRESS" do on the LM tunnel vent selector? [16:41:35] pressurize the LM, that's a backup method if there is a problem with the pressure equalization valve [16:41:39] but it's sloooow [16:47:32] It says to select LM PRESS before the sleep period from 85 to 94 hours [16:48:59] I did but with time accel during the sleep period, the 02 pressure gauge fluctuates a bit and the cabin temp indicator swings from normal, up to full scale high (120) and back to normal, and then repeats that weird cycle very few minutes [16:49:16] So I went back to LM/CM dP and it seems normal now [17:00:49] actually, its not because I selected LM PRESS, it does that ever since I left the CM and LM hatches open [17:02:18] I don't think those hatches were open all the time [17:02:47] and LM PRESS doesn't do anything with the hatches open, it's just a method to keep the CSM and the tunnel (and LM) at the same pressure [17:14:20] makes sense [17:14:47] Here's a fresh before LM activation scenario at MET 96:20: [17:15:02] https://www.dropbox.com/s/4ir5wh3g6vo3i44/Apollo%2011%20MCC%20-%20Before%20LM%20Activation.scn?dl=0 [17:15:34] and time acceleration didn't kill the LM ECS? [17:15:51] thats a negative [17:16:18] from what I can see in-sim, maybe you can confirm with the scenario file values? [17:16:31] theres no nan's thats for surre [17:17:19] the only nans in the scenario are saved values for the highgaiNANtenna [17:17:34] and a MESC relay [17:17:47] so it looks good [17:17:58] yes we have many nantennas [17:18:10] LETJETTISOnanDFRANGIBLENUTSRELAY [17:19:05] now, I totally expect the changes I did aren't very helpful with actual LM ECS functionality [17:19:31] but you will notice during LM activation [17:19:38] yeah [17:26:01] ill be out for a few, cya [17:29:07] morning! [17:31:20] hey Mike [17:34:02] that Skylab document is great [17:34:33] quite useful for the Saturn V LVDC in general, extremely useful for when we create an Skylab scenario [17:37:06] the LVDC gets input discretes for every stage separation, but I don't think the software is using that too much [17:37:24] the Saturn IB LVDC certainly doesn't use the S-IB/S-IVB separation input discrete [18:18:37] back, got pulled into a meeting [18:18:40] that is good to hear [18:20:26] hopefully we can find more of them :) [18:20:50] I have another fun thing for you this morning [18:21:35] last night I wrote an AGC program that tried as hard as it could to trigger the real radar interface bug [18:21:42] and I managed to get one to happen [18:22:05] https://i.imgur.com/NY4Q4Mo.png [18:22:38] the sensitive timepulses are timepulse 5 of WRITE and WOR, and timepulse 7 of WAND [18:22:54] this LR sync pulse overlapped with timepulse 5 of a WOR [18:23:11] haha, awesome [18:23:47] when WOR generates the WCH (write channel) control pulse, during the CT (clear time), the half of the flip-flops of channel 13 get temporarily cleared [18:24:01] so in this case the radar would have shifted out two bits instead of one, and the AGC would have rejected the second :D [18:26:10] WOR is quite long it seems [18:26:26] it's two MCTs, same as most instructions [18:26:33] the WOR0 signal is only high for the first half of it [18:26:41] but yeah, the AGC is slow at executing instructions, heh [18:27:01] haha, who would have thought [18:27:24] what is that momentary 0 of LRSYNC? [18:27:35] that's the bug! [18:27:41] right [18:28:02] it shouldn't be there, but it is because CH13 is temporarily cleared during writing, and LRSYNC can't be generated if a valid LR channel isn't selected [18:28:32] LRSYNC is the line that goes directly to the LR to make it send out data [18:28:38] ah right, the radar bits [18:28:43] yep [18:29:04] bits 1 and 3, which were the ones I had selected here, configure for Y velocity [18:30:28] yep [18:31:09] in other other news, yaAGC did its first cycle-accurate gyro drive this morning [18:31:27] and I have the counters for the CDU drives implemented but not tested [18:32:09] fun [18:32:31] what do you think we should begin with once you are ready, RHC? [18:32:38] for NASSP I mean [18:32:41] sure! RHC is a fun one [18:33:04] you just have to tell me what to send to the AGC [18:33:24] will the RHC also have a certain update rate requirement? [18:33:33] or can that stay at frame rate [18:37:33] that's up to you [18:37:58] RHC is by far the easiest one of these, you just update the voltage for each axis and I handle everything from there [18:38:10] so however fast you want to update the voltage will work [18:38:36] as fast as the simulation would be able to update, so frame rate [18:38:41] yep [18:38:47] same for ACA I guess [18:39:14] of course on your end that's all the same [18:39:33] I'm expecting -3.96 to +3.96 volts on each channel [18:39:33] yeah [18:40:26] void SetInputVoltage (agc_t * State, int Millivolts); [18:40:37] so, that's for the DC bus voltage [18:40:48] that should be above 20.6V for operation of the AGC or it'll get stuck in restart [18:41:17] that will get updated once per timestep then [18:41:26] I don't have a function for setting the RHC input voltage right now but I can add one [18:41:54] right now it's just looking at the State variables int RHCVoltagemV[3]; [18:42:22] oh no, an int [18:42:33] I can make that a different type if you'd like [18:42:37] it could be an int16_t [18:42:39] haha, no problem [18:42:55] I will start with -1 to 1 as the deflection [18:43:00] then convert that to voltage [18:43:18] just multiply by 3960 and you are good to go :D [18:43:23] at which point it is still a double [18:44:19] how do I even get from double to int[3] [18:44:35] the [3] is just one per each channel, X, Y, Z [18:44:46] but you can just assign a double to an int and it will truncate it [18:44:57] (int)double_value if you want to be explicit [18:45:29] ah, of course, it's for the three axis [18:45:34] yep [18:46:02] so -1 to 1 maps to -3960 to 3960 mV [18:46:06] yep! [18:46:46] I might start with the ACA not the RHC, I already made the ACA a separate class [18:46:47] that's the peak voltage of the AC signal, and I'm using sign to denote a 180 degree phase shift, since the signal from the RHCs is AC [18:46:55] buuuut that's not really important for this [18:47:24] is the RHC counter stuff ready for testing? [18:47:35] oh well if you're going to use the right names for everything [18:47:49] the RHC in the CM doesn't go through this interface at all, it was only used in the LM [18:47:55] so it's really only the ACA that needs this [18:48:20] it's just called "RHC" in the LM in all of the documentation that I reference so that's the name I default to [18:48:42] and yeah, it should work [18:48:43] yes [18:48:54] I think Artemis uses it though [18:49:00] oh really? [18:49:37] let me check [18:49:51] Artemis manual control through the CMC is quite different [18:50:54] I don't see any references in Artemis to BMAGX, BMAGY, or BMAGZ [18:51:22] and I don't see any aliases for those counters in ERASABLE ASSIGNMENTS at least [18:52:05] you know what, it works without the counters [18:52:24] in FREE the RCS fires on command, so the input bits. It doesn't enforce any attitude rate [18:52:28] yeah, it just looks at the out-of-detent and digital bits [18:52:46] in ATT HOLD the attitude rate is either 0°/s or X°/s, whatever is selected in V48 [18:53:32] because this variable attitude rate in FREE doesn't work like that pre-Artemis, I got confused and thought it was depending on RHC deflection [18:53:42] gotcha [18:53:51] so yeah, it is just the ACA that uses these counters then [18:53:52] but it's really just continuously firing [18:56:35] barely anything will have to be changed for the ACA [18:57:03] just a different scaling factor and a different input method to yaAGC [18:57:11] right now it is [18:57:12] WriteMemory(042,rhc_count[1]); // PITCH [18:57:54] that is LEMcomputer::WriteMemory [18:58:17] which calls a generic yaGGC write method [18:58:24] and then directly changes the AGC memory [18:58:36] ApolloGuidance::GenericWriteMemory(unsigned int loc, int val) [18:58:42] bank = (loc / 0400); [18:58:42] addr = loc - (bank * 0400); [18:58:43] if (bank >= 0 && bank < 8) [18:58:43] vagc.Erasable[bank][addr] = val; [18:59:04] yeah, like I said, this one is the easiest :D [19:00:22] since the notion of pulses and counts is entirely internal [19:00:41] all of the other counters send out or receive in pulses of some sort so we'll have to work through those in more detail [19:05:48] before I do any of this I have some LVDC stuff to do [19:06:14] that's fine, I still have several counters to go [19:06:53] and it's going to be a pretty big undertaking [19:08:01] yep [19:09:46] so, for the p30 refsmmat i get a burn attitude of 000 000 000 [19:10:00] that is correct [19:10:10] oh [19:10:24] that's the point of that REFSMMAT, really :D [19:10:39] hehehe [19:10:59] if you can't use the LS REFSMMAT due to gimbal lock issues, then you might as well use one that is useful for the burn [23:13:40] hey@jalexb88 [23:15:39] @jalexb88 how far into apollo 11 are you [23:15:39] hey [23:16:03] halfway through LM activation just setting up AGS right now [23:16:34] nice [23:17:04] just wondering what does go to orb rate and go intertial mean, [23:17:20] i think someone told me but i dont know how to do it exactly [23:19:21] orb rate means you pitch the spacecraft so that in 1 orbit your ship does a full 360 in pitch [23:20:11] in the flight plan i see different attitudes at different times [23:20:19] in other words you pitch so that the spacecraft follows the orbit. If your in level attitude with the horizon, you pitch down to keep the horizon in view [23:22:45] yes, you go to the attitude it says, then if it says "begin orb rate" you start pitching to maintain the same spacecraft orientation with reference to the moon [23:23:18] if it says "inertial" you keep that attitude [23:29:54] okay [00:16:41] my loi was terrible [00:17:09] for ha i got about -3.4 [00:19:07] Oh no! [00:19:25] i will go back and look at mcc4 [00:20:18] for mcc4, the attitudes were 000, 000, 000 [00:31:43] Lets see if I can make more valves smaller [00:36:51] astronauthen96 even if your angles were 0,0,0 you could still have a bad REFSMMAT [00:37:18] that would be my guess [00:37:30] Did you do a MCC4? [00:37:35] yes it was 12.5 [00:37:39] dvc [00:37:46] And you used LS during TLC REFSMMAT [00:38:08] nope i did p30 because the ls during tlc gave me gimbal lock [00:38:20] And what REFSMMAT did you use for LOI [00:38:23] i could try the ls during tlc and keep trying the different attitudes [00:38:30] i used landing site [00:38:37] Computed after MCC4? [00:38:41] yes [00:38:57] Hmm that should have worked [00:39:03] Have a scn? [00:39:15] i have lots i dont know which one you need [00:39:38] How about one before LOI when you have the burn computed [00:40:18] I can check your computations [00:40:36] okay [00:42:37] https://www.dropbox.com/s/8tezujz3nz1o4x1/APOLLO%2011%20LOI%20PREPERATION%20FINAL%200002.scn?dl=0 [00:44:40] Ok where are you in this mission as far as burn calculation [00:45:13] maybe 20-30 minutes till loi [00:45:28] the p30 is complete [00:46:18] Ok [00:49:32] Ok RM looks good [00:49:47] Lets see what the burn numbers look like [00:51:30] Good SV [00:52:55] So you used LS REFSMMAT and your burn had 0,0,0 for the attitude? [00:53:21] no i used the p30 heads up and it gave me 0,0,0 [00:53:42] I thought you had the LS REFSMMAT? [00:53:47] You do [00:53:57] So you need to use that to compute the maneuver PAD [00:53:58] i did the ls refsmmat after mcc4 [00:54:02] Right [00:54:14] Which means the burn is at 000,228,348 [00:54:19] Not 0,0,0 [00:54:37] for the loi [00:54:39] Yes [00:54:41] ? [00:54:49] okay [00:55:04] Think about it, you are burning on the other side of the moon from the landing site [00:55:10] the mcc4 burn was 0,0,0, [00:55:12] not loi [00:55:22] So theres no way you can have 0,0,0 unless you uplink and change your REFSMMAT to a P30 [00:55:32] MCC4 looked like it was fine [00:55:58] I have a good burn computed for LOI [00:56:28] Actually you do have the right attitude for burn already in [00:56:43] I don't know what went wrong I will try the burn myself using your data [00:56:56] okay [00:57:06] when i get to the sps 40 the pitch changes slightly [00:57:43] your P30 numbers are wrong [00:57:50] Hm the DVZ in your P30 is way off [00:57:58] No wonder your Ha is negative [00:58:15] i uplinked the p30 [00:58:26] Must have computed wrong [00:58:39] Did you do LOI w/o MCC when you calculated it? [00:59:07] do you remember what numbers for X/Y/Z DV you had for LOI-1? [00:59:19] i calculated the loi after the mcc4 burn [00:59:46] I have his P30 up, -2795.8 -0437.8 -0758.1 [01:00:20] I just computed LOI in his scn using RTCC and get -2896.2 -0437.8, and +0061.1 [01:00:21] should be -2896.2 -437.8 +61.1 [01:00:28] yeah [01:00:40] Yeah so somehow the calculation before uplink was incorrect [01:00:56] And that large Z component caused the apolune to be negative [01:01:29] So astronauthen96, I do not know how you calculated the uplink P30 but the Z component was wrong :P [01:01:40] i guess i will do it manually [01:01:54] i did w/o mcc [01:02:07] did you use LOI-1 (w/o MCC) or (w/MCC)? [01:02:15] w/o [01:02:30] yeah that should be correct [01:02:32] thats what I just used [01:02:37] i assumed that would be right because it computed it after the mcc4 burn [01:02:45] correct [01:02:47] i* [01:02:53] I just dont know how you got that Z component [01:03:18] Because I am getting a good calculation [01:03:27] did you do the 1st pass through P30/P40 for the gimbal test? [01:03:38] Like the checklist says? [01:03:55] yes [01:04:02] I think thats the issue [01:04:19] you probably recalled P30 after for the actual burn [01:04:27] Ah [01:04:39] i did two p30s during that period [01:04:51] Yeah load the scn you sent me, recalculate the burn and uplink [01:05:01] but the numbers in P30 will have been modified from the P40 routine. So you have to re enter them from the PAD on the second P30 [01:05:02] Let us know what numbers you get [01:05:04] okay [01:08:30] -2896.2, -0437.8, +0061.1 [01:09:19] is that good? [01:10:17] Yep! [01:10:36] And what did your maneuver pad give you for an attitude? [01:10:59] 179, 244, 004 [01:11:46] but [01:12:15] the p40 sps thrusting gives me 35472, 21153,34704 [01:12:42] You need to change the REFSMMAT in RTCC [01:13:06] Go to UTL, and the REFSMMAT page [01:13:12] Change it to LS [01:13:34] landing site? [01:15:00] new attitudes are, 000, 228, 348 [01:15:07] Good [01:15:12] Burn that [01:15:13] do i have to do a p52 [01:15:24] No you already have that RESFMMAT loaded [01:15:28] okay [01:15:37] You did uplink that one before right? [01:15:50] It looked like you did [01:16:30] you mean the landing site? [01:16:52] Yes [01:16:56] yep [01:17:49] Yeah you are good [01:17:54] Looks like the bad P30 was the problem [01:19:20] Go for the burn [01:21:31] roger understand [01:21:47] wait [01:22:29] should i change the ems counter [01:24:04] just restarted the scenario [01:26:38] yeah in the flight plan it says for the p30 to reload the noun 81 with the pad values [01:27:56] Yeah [01:28:06] And yeah change the EMS counter to the new pad DVC [01:29:28] 2928.6 [01:31:41] Looks reasonable [01:39:31] How long till your burn [01:40:12] less than 10 minutes [01:41:20] Awesome [01:41:30] I think you will get better results than a crash :P [01:43:45] burning [01:50:17] Hows the orbit look? [01:53:21] not good [01:54:34] when i enter p40 the pitch changes [01:56:24] What do you mean? [01:56:49] the pitch goes down a bit i think thats whats wrong [01:57:55] As in the pitch goes down when you start burning? [01:58:14] Did you uplink the new burn data? [01:59:28] no when i start the p40 [01:59:46] it is supposed to be at 248 then it goes down to 211 [01:59:59] After the uplink did you run a P30? [02:00:06] no [02:00:12] Ah [02:00:15] You need to [02:00:25] Every time you uplink burn data you need to redo P30 [02:00:35] The P40 still had old info [02:02:04] that worked [02:04:58] Btw you have your waste water dump still open :P [02:05:40] Get a good burn or just good P40 data [02:06:00] good p40 and yes i turned the dump off [02:06:21] Ok now you should get a good burn :) [02:06:28] I am testing yours now [02:08:27] Looks like I have to do a bunch of tuning to the LM ECS to compensate for valve changes :( [02:08:33] But it was to be expected [02:08:47] and a throbbing headache just waiting for the tylenol to kick in [02:08:59] Ugh I hate that [02:09:09] I am 2 minutes into your burn looks good [02:12:28] my poor astros are breathing pure C02 [02:13:06] Also looks like somethings up with the cooling in the CSM, the radiator temps are pegged [02:13:18] I have a normal CO2 amount in the scn you gave me [02:13:31] And I got a good LOI [02:13:40] It just went up for some reason before PDI [02:13:48] can I show you the .scn? [02:14:02] maybe im missing something [02:14:48] https://www.dropbox.com/s/4r5hdxz09f7rt0g/Apollo%2011%20MCC%20-%202%200016.scn?dl=0 [02:15:29] CO2/ [02:15:31] ? [02:15:44] Yeah I know why [02:15:48] Part of the changes [02:16:11] Because Nik reduced the valve sides for TLC stability, there isnt enough flow through the O2 system, including the CO2 scrubbers [02:16:17] I figured this would be a result [02:16:28] I need to go back and tune the O2 and glycol loops to compensate for those changes [02:16:30] ah [02:16:46] I started the glycol loops tonight I should be able to get more O2 looked at this weekend [02:16:54] But frankly eliminating the NaN's was priority [02:17:03] I can tweak from there to get results [02:17:30] So just tell your LMP to hold his breath, you will be fine :) [02:17:52] my indicator is at 16 mm :D [02:17:57] Im sure Neal can take it [02:18:00] Niklas apologized to me today for breaking my ECS :P [02:18:18] I will get it back up to par I am certain [02:18:56] Im just happy to have a stable ECS through to PDI :) [02:19:35] Yeah now the real work begins [02:19:56] I am glad I kept all those debug scripts commented out [02:20:04] I will need many of them [02:20:47] Oh, side note, I have contacted the National Air and Space museum to see if I can get photocopies or scans of some Apollo 11 checklists they posses [02:20:50] possess [02:21:13] burn was good [02:21:24] that would be neat to have [02:21:28] Awesome [02:21:29] the 11 checklists [02:21:34] Yeah they have a few [02:21:48] I am going to go there next week and speak to them in person [02:21:53] No reply to my email yet haha [02:24:41] And astronauthen96 now you have LOI 2 coming up [02:24:47] That is an easy burn [02:24:55] You use the same REFSMMAT you have [02:27:29] Well the glycol will take some work too but that will wait till this weekend, I need to get some sleep [02:27:31] Night guys [02:27:44] i m gonna take a break tonight [02:27:55] Well after LOI2 its all about the LM [02:27:58] unless my headache goes away [02:28:00] The fun part begins :) [02:28:04] Feel better and goodnight [02:54:44] .tell indy91 apollo 11 is in lunar orbit [02:59:21] @alexB_88 so how is lunar orbit going? [03:01:53] just about to burn DOI [03:02:01] then PDI later tonight [03:06:13] do you have a scenario before doi? not right now but maybe later? [03:08:12] sure. Ill do the landing, then Ill post one [03:08:25] Do you want before PDI too? [03:08:32] sure [03:08:37] thanks [04:15:09] Here is a before PDI scenario: [04:15:10] https://www.dropbox.com/s/kec13exi24c3aw2/Apollo%2011%20MCC%20-%20Before%20PDI.scn?dl=0 [04:19:41] thank you [04:54:50] night [12:35:07] . [12:41:43] hey [12:45:37] hi [12:50:37] apollo 11 is in lunar orbit now [12:51:57] great [13:04:48] Good morning [13:05:59] hey [13:13:18] Looks like a bunch of tweaks will need to be done to the ECS [13:13:21] As expected [13:13:41] Alex's LM was at 16 on the CO2 gauge haha [13:13:50] I started that work last night [13:14:09] Do we "think" we have the TLC NaN's figured out? [13:14:45] not really [13:14:57] increasing valve sizes probably will make them happen again [13:17:10] Well I am determined to fine other ways to stabilize the system [13:17:18] And not touch the valves [13:17:29] find* [13:18:02] I mean, the valves should probably be adjusted again, but, try to not increase the size by a magnitude [13:18:15] Yeah I will stay within the current magnitude [13:18:28] I think I will have most of Saturday to work on and adjust that [13:18:49] I fixed the total masses of the glycol system last night [13:19:05] Gets hotter faster now [13:19:31] But it works, just will need tweaks (ie which tanks need to be bigger/which need to be reduced to maintain constant mass/volume) [13:19:55] I also have that +/- 10% I can play with with those masses if I need to use it [13:21:02] In other news, my request for the checklist scans has been forwarded to the archive department of the NASM so theres progress I think [13:21:15] "Each museum and office grants rights to reproduce research it has published and to objects and images in its collections. I have forwarded your request to Rights and Reproductions staff at the Air and Space Museum for review and response; they can provide you with a scan and explain acceptable uses. " [13:22:47] luckily it's not the actual page I want, haha, just the numbers on it [13:23:06] well, the rest of the checklist would be nice as well [13:23:44] so I really don't care what their acceptable uses are, you can't copyright AGC padloads, can you? :D [13:23:56] I wouldnt think so [13:24:18] I am going to try to get the whole thing [13:24:23] If not I will get your padloads [13:24:40] yeah, it will have quite a few useful things [13:24:41] If getting the whole thing is easy, I am going to try to get all their Apollo 11 checklists :P [13:25:02] as we have none from 11 that seems like a useful goal [13:25:21] we have the crew charts from 11 [13:25:43] in the actual flight data file they will be spread out over the checklists [13:26:25] They also have the operations checklists and launch checklists I think [13:27:18] yeah [13:27:24] Launch Operations checklist [13:27:38] that was renamed to Launch checklist, and the Operations checklist is the G&C Checklist [13:28:00] That could be helpful as well [13:28:48] yes, I'd love to see the TLI Backup procedure [13:29:05] I'm not quite sure what Comanche 055 is capable of [13:30:24] unfortunately the backup padload won't have the numbers for any erasable memory program for TLI, if there was one [13:31:15] I dont think there was one [13:31:23] Apollo 12 had one [13:32:59] A P15? [13:33:23] an erasable memory program to start TB6 through the CMC [13:33:33] one that was padloaded [13:33:43] Oh [13:33:50] the procedure for using it is in the TLI checklist [13:34:08] I think I have tried it in Comanche055, but it didn't work [13:34:11] Haha [13:36:28] The smithsonian site for the checklist has a picture of TLI backup guidance [13:36:51] But I think its just the ORDEAL method [13:38:32] yeah, that is the same page as in the Apollo 12 checklist [13:38:41] Yeah [13:38:52] so either the procedure doesn't work in C055 or they simply hadn't developed it yet [13:39:25] the CMC/IU interface also would have to support it, which might not have been the case yet [13:46:02] Well maybe I can get that checklist and we can find out :) [13:46:53] it seems to be on display right now [13:47:06] so that would complicate things I imagine [13:47:47] Yeah [13:47:59] Maybe a good page is displayed and I can take a picture [13:48:16] haha, that would be fun [13:48:27] the page they did changes on during the flight was F2-20 [13:49:00] but the padload will be up to 4 pages [13:49:29] https://airandspace.si.edu/sites/default/files/images/collection-objects/record-images/A19980018000cp03.jpg [13:49:40] you can almost figure out which pages it would be :D [13:51:40] I plan on going there on Tuesday [13:52:01] Also just got a reply back, they want my postal address so they can send me information to send back to request the scans [13:52:08] That seems awfully convoluted [13:52:21] I emailed back asking if I can show up in person to expedite things haha [13:58:02] yes, that seems like at least one step too much to make sense [13:58:32] Agreed [13:58:40] "Though this may be the final step (again, we have not done any research yet, so I’m not sure what the end result may be), this is the first step for us to log in the request." [13:58:53] That was the reply but seems like I am real time talking to a real person now haha [13:59:10] Mike probably already has some experience with this process [13:59:19] Ah thats right [13:59:29] getting the Margeret Hamilton documents like the Colossus memos [13:59:33] I am just hoping my ability to go in person readily will help [14:02:05] I will keep you posted, I need to take off [14:02:06] Later [15:28:42] hey [15:29:33] hey Alex [15:30:23] got the infamous 522 before PDI [15:31:47] fun [15:34:42] V25 N01E 110E 40E 0E [15:35:07] that sets the flag responsible for the 522 alarm in the right state [15:41:27] thanks [15:45:37] I had managd to get by it last night by cycling the LR POS switch and running a V63, followed by a good landing. But I knew that wasn't a proper solution [15:47:09] I am quite sure Apollo 11 had to do some procedure to avoid this issue [15:47:14] during the LR self test [15:47:24] but, we don't have the LM Timeline Book [15:47:26] right [15:47:56] the flown LM Timeline Book was sold as a complete document, and not as single pages. For $250K [15:48:21] hmm let me check my wallet [15:48:28] so not a lot of pictures are available of it [15:48:34] it's also not been resold again [15:48:45] to bad its so expensive [15:48:57] So it might have vanished forever in some private collection [15:49:11] there should be some unflown copies of course [15:49:22] but not many of them were printed for each mission [15:50:18] btw the ECS mostly held up to landing except for some weird behavior with the C02, it went up to like 16 mm, way above the green band [15:50:33] other indications were normal [15:50:55] I think Ryan said it was expected with the stability changes as now less 02 is going through the crubbers [15:51:04] scrubbers* [15:53:15] yeah, I made the valves in the suit loop 1/10 of the previous size [15:53:20] that will be the cause [15:54:16] another issue is the hatches on the LM both disappear for some reason, at lunar contact [15:54:40] meshes are reloaded at lunar contact, because of the probes [15:54:50] ahh right [15:55:23] I forgot to add the visibility flag there [15:56:36] hey [15:56:57] @indy91 did you get my message about the checklist [15:57:12] no [15:57:35] well, there is a gimbal test before loi and there are 2 p30s [15:57:48] for the second one you have to reload the noun 81 values [15:57:55] LOI-1? [15:57:58] yes [15:59:03] ah, I see [15:59:16] I'm not quite sure how far you have to go into P40 [16:00:13] probably all the way through when P40 counts down to ignition [16:00:16] and then exit P40 [16:00:21] yes [16:00:28] what is your question then? [16:00:45] i made that error and got a bad loi the first time [16:00:54] oh, I see [16:01:03] so, the AGC knows that the LOI burn is not instantly [16:01:12] astronauthen96, you either have to re-uplink the burn target, or re enter the P30 with the PAD values [16:01:13] but it takes a few minutes of course [16:01:21] i had to recalculate my loi then uplink and then do another p30 and then the attitude was good [16:01:53] all you would have to do is go through P30 again and reload the PAD values manually [16:02:07] the short explanation is, entering P40 messes with the N81 values [16:02:30] so when you enter P40 and exit it you need to go through P30 again, with the right DV values [16:04:16] and i am having trouble going to local horizontal [16:04:47] on the ordeal when i set it to orb rate should pitch to zero [16:05:23] indy91, V25 N01E 110E 40E 0E, is there a number missing there? Those get me up to R2, what goes in R3? [16:06:13] couldn't read my own handwriting [16:06:15] it's N07 [16:06:26] ah thanks [16:06:31] astronauthen96, you have to do a few settings for the ORDEAL to work [16:07:10] you need to use V82 and V83 to initialize it [16:07:34] https://history.nasa.gov/afj/ap15fj/csmgc/7-05.gif [16:07:42] PGNS ORDEAL Initialization [16:08:37] it says in the flight plan to go to 180, 315, 000 so i will try that and initialize the ordeal [16:09:54] an underscored pitch angle means relative to local horizon [16:09:58] P315/295 [16:10:12] 295° inertial pitch, 315° pitch relative to local horizon [16:10:21] okay [16:10:22] and that's what the ORDEAL is used for [16:10:32] to drive the FDAI at orb rate [16:10:56] kind of makes it work like the artifical horizon in an aircraft [16:15:57] i am getting earth rise now [16:16:10] should DEDA 231 be entered before PDI? [16:16:34] my AGS altitude differs from PGNS, both SV's agree though [16:18:25] yeah, 231 might need a better number then [16:18:54] AEAPAD 231 255603 [16:18:59] that is the padloaded one [16:19:12] is that what you have in 231 right now? [16:19:24] oh wait, that is not the DEDA display format [16:19:39] might have to check in the scenario [16:22:32] MEM0231 255603 [16:23:58] of course there is also the difference between planned landing site radius and actual [16:25:55] yeah [16:26:09] I updated it with 231+56923 [16:26:21] as per the PDI PAD in RTCC MFD [16:29:24] and now there is a difference? Or was that before? [16:44:25] yeah it made it better, but still like a 2000 foot difference [16:44:54] but probably due to the PGNS having the same padloaded landing site rom preluanch [16:46:52] Here is the touchdown coordinates after my landing: PAMFD: +0.76, +23.71 LGC: +0.72, +23.70 [16:47:04] still a bit of a lateral error [16:47:43] but this is of course from a pre-DOI SV update, as per the flightplan [16:47:57] I did not do a SV update before PDI [17:03:09] the Apollo 11 PDI demo scenario has 0.04° error in both latitude and longitude [17:19:39] morning! [17:23:50] yaAGC now accurately simulates the THRUST and EMSD counters, and again I have found an unexpected behavior in them [17:24:30] with THRUST it is very very important that you not change the sign of the value in the counter before the last value has been counted out or you manually switch off its enable bit in channel 14 [17:24:51] when generating output counts it only checks that a plus count or a minus count have ever been generated [17:25:35] and so if during the same enable time you switch signs, it will generate both plus and minus counts to the throttle at the same time, forever until disabled [17:28:01] same goes for EMS [17:29:31] hey [17:30:33] those are both output counters, right? [17:34:33] yep [17:34:48] I've only got two output counters left, OTLINK and ALT [17:35:08] and then the only ones I'm not doing anything with are PIPA and CDU inputs, and INLINK [17:35:26] although I'm probably going to put it in a bit of INLINK logic when I'm done with the output counters [17:35:51] I figured I was just going to leave PIPA and CDU counters alone so we could work through the best way of handling those together [17:35:59] yes [17:36:04] how do I have to deal with the output counters when it's done? [17:36:14] right now it uses fictional output channels [17:38:12] that is an open question that we will have to work through too :D [17:38:27] right now I'm just counting outputs to placeholder variables I put in State [17:39:03] now that the timing is correctly simulated, it is very easy to change what the interface looks like [17:39:59] right now we deal with those output channels whenever the AGC writes to them [17:40:13] so this will not have to be included in any special timestep [17:40:32] on the MCT or frame time scale? [17:40:35] but instead an interface similar to what we have right now [17:41:24] looks like in yaAGC it is checking if the value in the counter is -0 or +0 [17:41:33] and if not then it's calling the ChannelOutput function [17:41:57] also the relevant output channel bit for the counter [17:42:15] it checks that as well I mean [17:42:22] right, so those are going to count down themselves now, so you can't just step agc_engine() a bunch of times and then look at the value in the counter or output channel [17:42:39] I was thinking of "integrating" the pulses over a frame or something like that [17:42:59] so say THRUST counts 100 times in a frame [17:43:06] and you load it with 5000 [17:43:23] what exactly is leaving the AGC for this? [17:43:27] how is it wired [17:43:33] plus and minus count? [17:43:37] for all of these counters, two wires [17:43:38] yeah [17:43:48] one makes a plus, on the receiving device, and one makes a minus [17:44:10] most of them count out at 3200 pulses per second [17:44:30] so the actual counter is outside of the AGC [17:44:37] e.g. in the DECA for the LGC throttle commands [17:44:58] well, the counter is just an erasable memory location that gets automatically decremented at 3200pps [17:45:05] ok [17:45:09] there may or may not be a mirrored counter in the DECA [17:45:16] but it's counting out pulses [17:45:23] yeah [17:45:26] why not call a function for every pulse [17:45:40] I could do that [17:46:09] if that would be easiest for you [17:46:30] sure, the pulses are collected in the DECA counter [17:46:38] that would have to be implemented [17:46:46] but it's just some variable that stores the pulses [17:46:47] what I had kind of been thinking might be easy would be to have a counter start at 0 every frame, and add up the plus and minus counts on it over the AGC timestep, and then deal with the amount something would have changed [17:46:50] maybe with some logic [17:47:06] yeah [17:47:10] that would definitely work [17:47:19] so the counter would change whenever a pulse comes from the AGC [17:47:37] yep [17:47:39] and then during the actual DECA timestep it's doing something with the total count [17:48:05] that's not much more DECA code than there already is [17:48:21] but I would like this to be some general interface function [17:48:27] here's what the placeholder code for THRUST looks like right now [17:48:37] with some ID of the wire [17:48:39] this is run at 3200pps: [17:48:55] if (State->InputChannel[014] & 010) [17:48:55] { [17:48:56] if (State->ThrustPlusActive) [17:48:56] State->ThrustOut++; [17:48:57] if (State->ThrustMinusActive) [17:48:57] State->ThrustOut--; [17:49:11] so I can easily replace ThrustOut with calls to such a function [17:49:31] yes, similar to ChannelOutput [17:49:54] but without any value it sends, just, whenever the function is called one pulse is sent [17:50:01] right [17:50:04] I can do that [17:50:31] with a plus or minus as the other argument [17:50:43] not even that [17:50:45] the Systems Handbook has some number associated with the pulse [17:50:54] "354 INCREASE THROT" [17:50:59] "353 DECREASE THROT" [17:51:04] oh, you mean assign a different ID to both wires, okay [17:51:25] I like it :D [17:51:26] are those numbers from the ICD something? [17:51:30] or* [17:51:33] let me check [17:52:04] ....no [17:52:17] so something LM (LGC) specific [17:52:21] not so great [17:52:32] increase throttle is on pins 72 and 73 of connector 56P7 [17:52:37] no that might be a very good thing [17:52:46] I have a date with the systems handbook now [17:53:02] there is a distinct possibility that that is a pin number on the AGC connector itself [17:53:11] it just has to be something generally applicable for both CMC and LGC [17:53:16] which is information I have been searching for for like a year [17:53:23] lol [17:53:29] yeah definitely [17:53:30] NASSP deals with it from the interface on [17:53:41] so just to be sure [17:53:49] ALT will behave almost exactly the same way [17:53:59] except there is a ONE and ZERO output wire, instead of a PLUS and MINUS [17:54:10] for data shifted out to the tape meters [17:54:47] you will know when a full piece of data has been formed when bit 16 of your counter becomes a 1 [17:55:04] then you can apply the value and reset your counter to 0 [17:57:34] oh, the ALT and ALT RATE signal is already split up in the LGC [17:57:46] right now we do [17:57:47] if (val14[AltitudeRate]) [17:57:48] { [17:57:48] lem->RadarTape.SetLGCAltitudeRate(val.to_ulong()); [17:57:49] } [17:57:49] else [17:57:50] { [17:57:52] lem->RadarTape.SetLGCAltitude(val.to_ulong()); [17:57:54] } [17:59:03] but that shouldn't be an issue [17:59:36] I would imagine it works very similar, even with "0" and "1" [18:00:11] so less work for NASSP :D [18:00:27] I need ALT "0", ALT "1", ALT RATE "0" and ALT RATE "1" then [18:03:25] haha [18:03:26] yep [18:03:28] I can handle that [18:03:29] The VEL light on eagle did not light up before PDI ignition [18:03:46] and I will also split up the gyro pulse torquing pulses internally [18:04:43] AlexB_88, Luminary 099 doesn't look for velocity readings from the LR until 30k feet [18:04:53] ah ok [18:05:07] LR worked better as expected at higher altitudes so they changed that for later versions [18:05:26] I have a PR that fixes the hatches disappearance at contact [18:06:45] great [18:07:22] sent [18:07:31] thewonderidiot, so right now when the AGC spits out something in the ALT counter the result gets added or subtracted from some counter we have in tape meter code [18:07:45] perfect [18:08:10] I can't say I fully understood in the two lines starting with "you will know when" [18:08:20] -in [18:08:27] bit 16 of what? [18:08:45] oh, so the ALT data is shifted out instead of counted out [18:09:06] so the raw value itself is shifted into whatever is driving the tape meters [18:09:20] so it's not pulses [18:09:36] it's still two wires, just a pulse on one means a 1, and a pulse on the other means a 0 [18:09:57] the counter itself is 15 bits, and the AGC always generates a leading 1 pulse before the data, so every ALT output will have exactly 16 pulses [18:10:38] the 1 is sent out first so that you know, if you have a 16-bit counter, that the transmission is complete when bit 16 becomes a 1 [18:10:56] this is why there's a leading one on those uplink commands we worked out, the AGC has similar logic internally for uplink [18:11:13] the leading 1 being shifted into position 16 is what causes UPRUPT [18:14:16] ah, I looked wrong at our code [18:14:24] it's not increments [18:14:35] what gets shifted out of the AGC is the full altitude or altitude rate [18:15:16] yep [18:16:04] so when would the AGC call the new output function [18:16:19] would it permanently send 1s over e.g. ALT "1"? [18:16:22] when it's off [18:16:37] oh, one leading 1 pulse [18:16:46] I read a stream of 1 pulses [18:16:49] I think it should be identical to the plus and minus counts for the other counters [18:16:53] nope [18:17:20] so the logic would be, every time you get a pulse, shift your counter up and either add a one or not [18:17:26] so the tape meter has to process 16 pulses [18:17:52] and as soon as bit 16 becomes a 1, you have a full reading, and zero your counter so the next leading 1 has to make it all the way up to bit 16 again [18:17:52] yeah [18:18:08] I can capture waveforms of this on the hardware sim if it would help [18:18:41] no, it wouldn't help [18:18:44] those mostly confuse me [18:19:06] maybe it's helpful for electrical engineers [18:19:10] but I am not one :D [18:19:19] hehehe [18:20:10] so when the counter is full I should convert that into a double value for the display itself and then zero the counter [18:20:26] yep! [18:20:33] that should work perfectly [18:20:38] in the receiving function I would add a check for that then [18:20:46] yup [18:21:18] this is the DEDA all over again, processing something bit by bit is not my strength [18:22:13] so basically it is: bitwise shift, add 0 or 1 in the last digit [18:22:18] check for bit 16 [18:22:27] if yes, convert to double and zeor counter [18:22:30] exactly [18:22:31] zero* [18:23:09] and OUTLINK wasn't used so I think ALT is the only one like this you have to care about [18:23:27] found it in the Systems Handbook [18:23:45] the electronics for the tape meter have 4 counters [18:23:58] four? [18:24:01] two for digital input from the PGNS (alt and alt rate) [18:24:39] and some stuff coming for the LR and RR directly [18:24:54] ahhh [18:24:57] right [18:25:20] AGS uses the same counters as the LGC actually [18:25:50] oh interesting [18:26:02] so it is probably a bad idea to let both try to drive the meters at the same time [18:27:38] there is some mode select logic [18:30:09] I have to streamline that code a bit, the AGS alt/alt rate are currently stored in AEA interface code [18:32:23] thewonderidiot, would incomplete sequences be a problem when the AGS is also using it? [18:32:39] not sure [18:32:55] I haven't emulated this counter yet so I don't know what its quirks are [18:33:05] the "Range Digital Input" counter is used by 3 systems even [18:33:07] but I suspect that once it starts counting out the 16 bits it won't stop unless you turn off the AGC [18:33:29] I'm not sure what would happen in the peripherals :) [18:33:31] PGNS altitude, AGS altitude, LR altitude [18:33:48] although LR altitude is really slant range [18:34:04] but it's quite close especially closer to the landing [18:34:07] so it's a decent backup [18:36:36] I just did a very successful calculation where the input was the exact same as the output. Sounds a bit crazy, but now I have better conversion methods for LVDC coordinate systems, haha [18:36:52] haha [18:36:54] awesome! [18:36:58] that is always a good test :D [18:37:02] yeah [18:38:30] the LVDC is in close competition with the AGC for to the number of coordinate systems they use [18:38:48] hehehe [18:38:53] well, the powered descent is rather insane with that, so the AGC probably wins [18:39:21] in the GSOP the section about powered descent begins with explanations of the coordinate systems even [18:39:31] or else things get confusing quite quickly I guess [18:40:20] 6 of them which get used by P6X throughout [18:40:44] holy cow [18:41:00] that was fun when I implemented the LR [18:41:26] the direction in which it points is quite complicated to calculate [18:43:18] I still wonder if I did some small mistake with the conversion, which could be causing some navigation inaccuracies during the landing [18:45:08] coordinate system transformation problems are such a pain to debug [18:45:32] yep [18:46:05] I'm normally more on the embedded side so I only interact with it rarely, but I have definitely felt my GN&C coworkers' pain when they are trying to debug such things [18:49:16] so what do I do with this newly won knowledge... [18:49:35] hm? [18:49:50] better coordinate transformation calculation [18:49:58] hehe [18:50:01] it probably fixes the long standing bug for the sep attitude on the TLI PAD [18:50:06] AlexB_88, when does that happen [18:50:14] with e.g. Apollo 11? [18:50:23] so full LVDC presettings [18:50:31] or when the LVDC was updated via the RTCC MFD? [19:17:44] @alexB_88 so have you landed yet? [19:27:57] indy91, yeah it happens with or without presettings for me [19:28:14] astronauthen96, yep landed at tranquility [19:28:34] did you give the scenario I posted a try? [19:29:32] did some of it [19:30:31] you'll have to do a special procedure that is not in the checklist btw [19:30:46] before PDI do, V25 N07E 110E 40E 0E [19:31:17] one of the landing radar position flags is not set correctly, so this will fix that [19:32:14] AlexB_88, did you have the issue with Apollo 11 this time around? [19:34:15] yeah [19:34:44] your fix does the trick though [19:34:57] does it matter when i do it? [19:35:17] AlexB_88, what trick? [19:35:23] Must be because we're using the wrong LR test procedure [19:35:32] V25 N07E 110E 40E 0E [19:35:38] before PDI ignition [19:35:45] prevents the 522 alarm [19:36:50] astronauthen96, I did it right at the start of the PDI scenario so TIG-4 mins. The alarm appears after DSKY blanks at TIG-35 seconds, so I would do it before that at least [19:37:49] okay i wrote it down [19:41:31] the Apollo 11 G&N Dictionary has a similar procedure for P64, in the case you get a 523 alarm [19:41:34] so after loi 2 do things get kind of difficult? [19:42:12] in that case you also have to reset a flag. So I wouldn't be surprised if this 522 alarm procedure was in the actual checklists [19:42:14] indy91, here's my latest PDI scenario if you need it to test [19:42:16] https://www.dropbox.com/s/kec13exi24c3aw2/Apollo%2011%20MCC%20-%20Before%20PDI.scn?dl=0 [19:42:20] thanks [19:42:42] I think in the transcripts they even talk about it [19:42:53] oh, where? [19:43:08] I'm using your Pre TB6 scenario to finally fix this sep attitude bug [19:43:24] astronauthen96, after LOI-2 you have the difficult task of sleeping for a few hours [19:43:37] after the sleeping period LM activation soon begins [19:43:41] 102:26:55 Aldrin: And, Houston, we got a 500 alarm (code) early in the program. Went to Descent 1, proceeded on it, and we're back at Auto again. Over. [19:43:43] that is challening indeed [19:44:08] AlexB_88, but that is an actual 500 alarm, not 522 [19:44:21] and there is a procedure on that G&N Dictionary page for that as well [19:44:34] exactly as Buzz describes it [19:44:52] https://historical.ha.com/itm/explorers/apollo-11-lunar-module-flown-lm-g-and-n-dictionary-lunar-module-landing-sequence-pages-pgns-/a/6158-52053.s [19:45:47] full of hacky backup procedures [19:46:59] ah I see [19:47:22] So if they had a flag to reset, they would have done it earlier [19:48:33] it might have been with the LR self test procedures [19:48:40] first task after undocking basically [19:48:45] so in the LM Timeline Book [19:52:17] Our Apollo 11 checklist MFD has a manual switch to LR POS - HOVER late in the landing. I think that should not be performed unless we get a 523 at P64 [19:54:24] that might be from one of the outdated documents [19:54:37] yeah [19:55:49] or not [19:56:17] it's on the PDI page from the timeline book [19:56:43] https://www.astronomyclub.xyz/lunar-landing/images/4806_105_57.jpg [19:56:57] that is from [19:56:58] (Apollo 11 Flight Data File, LM Timeline Book, Rev. "N." July 12, 1969, 9. Grumman Aircraft Corporation Archives. Courtesy of Paul Fjeld.) [19:58:01] somehow I feel we knew about this document [19:58:15] or we talked about contacting Paul Fjeld or so [20:00:26] Ron can contact him [20:00:40] last time he came up we were talking about the LM Data Book [20:00:48] which we thought he had but it turned out the MIT Museum had it [20:01:09] ah, LM Data Book it was [20:03:13] not sure where he got that, but it's not in the CSDL collection finding aid like the LM Data Book is [20:04:27] CSDL? [20:06:32] Charles Stark Draper Laboratory :P [20:08:13] ah [20:08:26] well, as I quoted above, "Grumman Aircraft Corporation Archives" [20:22:02] oh wow I read right over that [20:22:08] is that a thing that we can get access to?! [20:23:04] no idea [21:58:43] so how did it go, astronauthen96? [21:59:02] how did what go? [21:59:19] did you manage to land? [21:59:26] not yet i just had a little nap [21:59:33] i am still confused about the orb rate [22:00:30] so i hit the verb 83, pitched to that angle on fdai one with orb rate selected and i am pitching up to zero and it seems to be level with the horizon am i doing it right? [22:02:19] yes, you set up the ordeal and slew the FDAI to the angle that is in R3 of V83 [22:02:58] but you dont necessarily have to after pitch the CSM to 0, you can stay in that same attitude, but just pitch enough so that the CSM follows the orb rate [22:03:04] do i pitch up to zero? [22:03:11] okay [22:04:17] If the flight plan says, maneuver to an attitude say 000,090,000, and start orb rate, then you maneuver to that attitude, and begin orb rate from that attitude, [22:04:41] yeah its 180, 315 with the underscore, 000 [22:05:31] man, ordeal is such a great name [22:05:34] 315 is you orb rate additude. Put simply, once you set up the ORDEAL for orb rate on the left FDAI, keep 315 [22:05:48] okay [22:05:50] haha yeah [22:06:35] and what does the other pitch angle mean [22:06:41] there is two of them in the flight plan [22:06:52] the underscore pitch is the ORDEAL attitude, and no underscore = normal attitude [22:23:30] Good evening [22:23:53] hey [22:24:06] hey Ryan [22:24:30] I saw you got a reply from the Smithsonian this morning [22:24:36] real talk [22:24:37] .endlogging [22:24:37] Meeting ended by thewonderidiot, total meeting length 337406 seconds