[20:57:49] NASSP Logging has been started by thymo [21:00:08] I'm really curious why DIM generates a WOVR [21:00:20] I can't figure out when it would that would make anything happen [21:01:56] Memo #9 doesn't even mention that DIM could potentially cause interrupts [21:02:09] I guess they just didn't bother gating it out since it's not really possible [21:11:14] also... wow [21:11:25] our PINC and MINC instructions have been doing one's complement wrong for...ever [23:19:22] it lives!! [23:21:06] oh wow [23:21:10] it is angry though [23:21:13] Borealis kills it hard [23:46:20] alright, fixed the first problem, the rupt lock timing was way too fast [23:46:39] still taking a (much less violent) restart during the self-check though [00:29:03] it can pass Aurora's tests, though, which is good [00:34:26] oh!! it's because I actually test TIME6 in Borealis, and I haven't implemented that yet [00:34:30] Aurora doesn't touch it :D [00:53:20] alright, Borealis totally passes :D [01:03:05] Sweet [14:32:29] Hey [14:33:42] Good morning [14:33:51] Are the forums down for you as well? [14:34:14] macieksoft messaged me through my youtube channel asking me about it its been down for a few days [14:43:50] Yeah. It has been. Don't know what happened/ [14:44:15] Maybe more people will come on IRC :P [14:44:24] Blame it on not being updated for 9 years. [14:46:45] I get gateway timeouts even using curl. [14:50:21] Yeah I have tried many points of access [15:20:14] I am trying to figure out a good way to compute heat generated by the ECA's [15:33:28] Side note, I am trying to attach orbiter to VS to debug, yet when I do this comes up in the output: [15:33:32] orbiter.exe' (Script): Loaded 'Script Code (Windows Internet Explorer)'. [15:33:36] That seems wrong [16:12:02] I've never seen a message like that. [16:17:33] It comes up right when i attach the prcess [16:17:35] process [16:24:31] https://www.dropbox.com/s/6sm2mf4fprljomi/Untitled.png?dl=0 [16:43:12] Any idea why it would do that? [16:43:34] Or how to fix that [16:45:51] Wasn't there some option related to what it would attach to in the options? I recall seeing 3 options, scripts was one of them. [16:49:41] Yes [16:49:55] In automatic mode it detected script when i selected orbiter [16:52:31] https://www.dropbox.com/s/cb8i5vry1obk592/Screenshot%202018-01-21%2011.52.15.png?dl=0 [16:56:13] And if I run orbiter nothing happens in VS [17:10:10] I am just confused [17:20:05] Mine is set to native code [17:20:11] not script code [17:32:09] morning! [17:38:45] Hey Mike [17:39:43] what's up? [17:50:47] Yours automatically selects script for orbiter, Thymo? [17:51:05] or native rather [17:51:21] That worked! [17:54:59] Yep. [17:55:43] thewonderidiot: Nothing much. Spend the majority of the afternoon watching some videos and doing random things around the house. [19:44:00] hey Niklas [19:45:41] hey [19:46:15] what's up? [19:46:41] just came back from a busy weekend [19:54:55] have you tried to fly Apollo 5 any further? [20:02:19] not yet [20:02:26] I should do that [20:02:47] been tinkering with virtualagc some more -- it runs again and can pass everything in Borealis [20:03:06] sounds good [20:06:34] it turns out PINC has been counting incorrectly all these years... it counted from -0 to +0 which shouldn't happen [20:09:07] hmm [20:09:20] how much DV is one pulse? [20:09:23] Delta V* [20:09:36] it's different between the CM and LM [20:09:42] but I don't remember the number offhand [20:09:45] ah right [20:10:17] LM: 1 pulse = 1 cm/s [20:10:23] CSM: 1 pulse = 5.85 cm/s [20:10:46] now I wonder. We have been using PINC for the PIPA accelerations before [20:11:12] and there is this weird behavior that could be explained by one pulse being lost in the acceleration calculation [20:11:55] it happens during nulling residuals or doing a very small maneuver with the RCS [20:12:13] is it possible to explain this from the -0 to +0 thing? [20:12:14] and you use CounterPINC() for that? [20:12:33] yeah [20:13:10] UnprogrammedIncrement(&vagc, RegPIPA, 0); // PINC [20:13:10] actually maybe I'm wrong [20:14:25] yeah nevermind, I must have accidentally deleted these lines in my local copy or something [20:14:54] so, no explanation for it then [20:18:11] 5.85 cm/s is about 0.2 ft/s [20:18:17] that alone might explain it, haha [20:18:34] what do you mean? [20:18:52] you can't exactly get your residuals any finer than 0.2 ft/s, if that is one PIPA pulse [20:18:59] oh, yes [20:19:00] haha [20:19:34] especially if you are firing for e.g. 0.19 ft/s and wait for a reaction on the DSKY [20:19:38] but you won't get any [20:20:03] yep [20:20:04] then you fire for slightly longer, let's say 0.22 ft/s and you got double the DV you actually wanted [20:20:28] that seems consistent with my experienc [20:20:29] e [20:20:40] good to know where it is coming from [20:22:27] and you won't get any of this in the LM [20:22:37] the scale shown on the DSKY is in 0.1 ft/s [20:23:48] I was actually reading something about the Apollo 5 alignment on the launchpad related to this [20:24:14] some overflow would have occured, if they had used an alignment like a CMC has at lauch [20:24:16] launch [20:24:47] I think that was total acceleration though [20:25:04] just before S-IB staging I guess, at 4.5G or so [20:25:19] yeah sounds right [20:28:09] of course another reason for the Apollo 5 alignment was the various attitudes of the DPS and APS maneuvers [20:28:19] and no astronaut to do a IMU realignment [20:30:07] luckily I already did all the work to understand the alignment last year in a MATLAB script :D [20:30:16] hehehe [20:33:23] I also noticed that with the EMS and AGC diverging during maneuvers. Especially when nulling residuals. [20:34:27] yeah, our EMS won't have any restrictions like a PIPA pulse [20:34:46] I've always trusted the EMS more for nulling residuals [20:36:42] Also, don't know if you've noticed. The forums have been down for days now. [20:41:54] yeah, they were down on Friday when I last checked and then today again/still [20:54:26] night [21:17:21] hey [14:17:41] Good morning [14:18:41] Hey [14:18:53] Bye [14:19:06] Haha [14:19:42] hey guys [14:20:01] Spend about 4 hours installing citrix receiver for college today. [14:20:29] Forgive my ignorance, but that is? [14:21:17] Kind of a more feature rich variant of remote desktop. They want to start using it for the programming exams. [14:21:33] Ah gotcha [14:21:40] We log in to a session using that and make the test on there in a monitored environment. [14:21:57] But it required webkit and that took like 2 hours to compile. [14:22:29] The rest of the time was mostly spent on figuring out how to get rsync (to fetch the packages) working behind their firewall. [14:22:39] We had something similar years ago called Dyno so we could log in and participate in class take quizzes view the lecture slides in real time etc [14:22:49] Ended up setting up a proxy to my home and redirect rsync over it. [14:23:30] Citrix throws you into a win server 12 session that is hosted...somewhere [14:25:46] Oh indy91 i have been having the same ECS problem where values go to NaN when i try to press the LM, this is in a fresh apollo 11 launch scn [14:27:05] so, my only theory on that so far is that a very tiny amount of CO2 is going into the suit tanks in the LM and that somehow causes a floating point precision issue [14:27:23] not necessarily CO2 [14:27:40] Blah stupid 3g to 4g switch [14:27:52] did you get my first answer? [14:27:56] No [14:27:59] so, my only theory on that so far is that a very tiny amount of CO2 is going into the suit tanks in the LM and that somehow causes a floating point precision issue [14:28:08] not necessarily CO2 [14:28:23] on Apollo 5 I had the same issues and when I properly pressurized the suit circuit as well then the issue didn't happen [14:28:42] maybe it's some pump accidentally running there, that could be the issue as well [14:29:20] I will look into the suits and try to find a better solution to the current plumbing [14:29:43] at least I am pretty sure it has to do with the suits [14:29:47] or suit circuit [14:30:18] I wanted to leave that part of the ECS unpowered for Apollo 5, but I always got the issue with that approach [14:32:36] Cabin should pressurize the suit circuit through the cabin gas return set to auto [14:32:36] But the suits stay isolated in disconnect [14:32:53] maybe the issue is related to that then [14:33:00] speaking of Apollo 5, today is the anniversary! [14:33:06] I didn't have time to make a video or so [14:33:09] Oh very nice [14:34:58] Happy anniversary 5! :) [14:40:21] Ill see if i can debug that suit thing though [14:40:59] Seems weird though that the csm gauges and glycol in both spacecraft go to nan [14:41:40] it's all connected [14:42:12] only constantly closed valves will stop the issue from propagating [14:42:26] not even the valves in the LM hatches are save [14:42:29] safe* [14:42:42] when they are in auto then they check for a pressure differential [14:42:53] and that will be between NaN and 0-5 PSI [14:43:06] so anything can happen with the valve in that case [14:44:09] and of course what is really spreading is the NaN energy state [14:45:53] so that is how it is getting into the glycol [14:46:41] Ah that makes sense [14:49:54] the issue could also be that some system just isn't working properly in near vacuum [14:50:05] then we need to do a few fixes in the code of them [14:50:39] after all we haven't really simulated much with EVA or repressurization even in the CSM [14:51:07] Ive done a bunch in the CM but of course its a simple system [15:11:18] haha, another PR that will cause Thymo some headaches [15:11:53] Thymo, is there any way you can release a version of your CWEA soon that at least doesn't sit in lemsystems.cpp anymore? [15:12:13] the CWEA interacts with so many systems, it's just not possible for us to completely leave it alone [15:13:42] Ehh. Yes and no. I could PR an earlier commit, I already started ripping out some of the old logic (everything concerning the ECS) out of the old CWEA. [15:17:52] then we will continue to create merge conflicts for you [15:20:08] rcflyinghokie1, you actually "fixed" British English into American English with your PR, haha [15:20:23] aluminium is perfectly right [15:20:46] aluminum sounds strange to me, but I guess it's correct in some places on this planet [15:22:35] "Aluminium has the edge in scientific writing even in North America. This is primarily because several influential scientific organizations and publications prefer the spelling." [15:22:38] PR rejected :P [15:26:32] It's fine. I'll figure it out. [15:27:47] ok [15:44:09] hey [15:44:45] hey Alex [17:23:56] quiet day today [17:24:27] morning! [17:24:34] hey Mike [17:24:36] happy Apollo 5 anniversary :D [17:24:43] oh right [17:39:53] hey [17:40:13] you all could celebrate Apollo 5 by beta testing the scenario [17:42:20] I will do that as soon as I get home tonight [17:42:38] also might see if I can get a basic telemetry viewer working so I can watch the mission timers and whatnot [17:42:43] I already found one: The LM is missing its legs :p [17:43:10] the legs are coming on Tuesday [17:44:15] for an actual bug, the descent stage will still have legs [17:44:50] thewonderidiot, telemetry viewer would be awesome [17:45:30] :D [17:45:48] the LM does send telemetry, right? [17:46:18] for the LM it's untested [17:46:27] haha, but it's theoretically implemented? [17:46:33] I think so, yes [17:47:12] cool [17:48:33] but I don't even know how it works. Our telemetry client only connects to the CMC [17:48:42] oh boy [17:48:51] how does it differentiate between CMC and LGC even? [17:48:53] okay I'll have to look into it [17:48:55] no idea [17:49:07] different ports? I assume it's socket-based? [17:49:15] might be, yeah [17:50:29] in other news, I tested standby in the refactored virtualagc and it seems to be working :D [17:50:55] after an initial mix-up in which I had channels 3 and 4 backwards, so it thought 2.5 hours had elapsed after I had it in standby for a minute or two [17:50:56] service.sin_port = htons( 14243 ); // CM on 14242, LM on 14243 [17:51:06] maybe this? [17:51:06] ah nice [17:51:09] yeah [17:55:21] looks all identical in CSM and LM telecom code [17:55:29] so it should probably work [17:55:31] great [17:55:50] I guess you need to do layout etc. on your own? [17:55:54] yeah [17:56:08] the AGC sends the downlink list ID I would guess, but nothing more [17:56:09] going to need to work out what the downlist even is, since the code for it is much more convoluted than Luminary [17:56:26] what do you mean? [17:56:41] well, there are several types of downlink lists [17:56:50] at least in Colossus/Luminary [17:57:36] so what does the AGC send? Downlink list number and then just a stream of data that must be interpreted by the receiving end? [17:57:53] I don't think sunburst has multiple downlists [17:58:21] that's good [17:58:28] but how does that work in general? [17:58:38] in general, yeah [17:58:51] there's a sync bit that gets set along with the first word of the downlist, that is zero for all other words [17:59:00] so until the ground sees that sync bit it doesn't know which word is what [17:59:38] right [17:59:48] just found it in our telemetry client code [18:00:04] -0 is COAST/ALIGN, -1 is ENTRY/UPDATE and so on [18:00:37] what are those numbers? [18:00:44] some half word [18:01:08] haha [18:01:31] probably the first one it sends, it also talks about SYNC1 [18:02:11] but Sunburst won't have that, so the whole format will be different [18:02:48] if(cmc_w1 == 077340){ // Check for SYNC 1 [18:03:36] aha [18:03:39] yeah that's LOWIDCOD [18:03:45] Sunburst does have that [18:03:48] and it's different [18:04:08] 00437 instead [18:04:18] interesting [18:05:07] yeah it's only different for Aurora and Sunburst 37/120 [18:05:19] Aurora's comment on the line is "FOD's CHOICE." [18:05:53] https://en.wikipedia.org/wiki/Flight_controller#Flight_Operations_Directorate_(FOD) [18:06:27] hmm, maybe not [18:10:25] I wish there was a Delco Guidance and Navigation Information-type document for Apollo 5 [18:10:41] GSOP would also help [18:10:50] section 2 [18:12:16] yeah definitely [18:13:43] NARA has volumes 1 and 2, for Burst 116 [18:13:59] July 1967 [18:15:03] 350 pages though so it would cost a lot to have it scanned [18:18:55] isn't all you need in the Sunburst comments? [18:19:21] the first part of the downlink is very similar to other AGC versions [18:19:26] it starts with the state vector [18:19:40] oh yes, of course [18:20:39] I was just thinking that because the Delco documents show telemetry screen layouts, if I recall correctly [18:20:54] oh, right [18:20:59] let's see what the RTACF had [18:22:55] ah, just the displays in the RTACF itself (state vector conversion and update etc.) and the display for FIDO [18:23:59] so that is of course processed telemetry data if anything [18:24:03] yeah [18:24:10] ah well, I can come up with something [18:24:24] speaking of the Delco documents, I might start requesting more of those [18:24:33] they're pretty nice and we should be able to get them for most missions [18:26:58] yeah, they are great documents [18:27:09] UHCL has 10, 11, 12, 14, 15, 16, 17, and ASTP [18:28:05] and "GUIDANCE AND NAVIGATION INFORMATION" for 7 and 8, which may be the predecessor document [18:29:34] ASTP should be interesting [18:29:46] probably has some nice info on Skylark [18:30:13] yeah definitely! [18:31:40] I think I'll start with 11 and ASTP [18:32:09] we can't let UHCL become bored [18:32:23] hehehe [18:36:04] the 11 one is dated July 16, so it will be interesting to see what version number it has for Luminary [18:36:12] not that I have any strong opinions about which version flew or anything :D [18:39:11] Luminary flew [18:42:47] a buggy Luminary version nobody wants anyway [18:42:58] hahaha [18:43:14] fair enough [18:43:23] if you had to choose between Zerlina 56 and Luminary 210, which would you go with? [18:43:59] Luminary 210 [18:44:02] flight tested [18:44:04] three times [18:44:55] Zerlina 56 is fun, but not the one I would choose if I had to choose one for an actual mission [18:45:30] haha [18:45:50] come on man, your nick is named after Indiana Jones, where's your sense of adventure :P [18:46:17] the adventure is going to the Moon at all [18:46:24] lol [18:48:07] but I also would take Zerlina 56 over Luminary 099 [18:48:30] sure, it's got almost all of the 210 features and fixes [18:48:44] and all the fixes and changes for the better from 99 on [18:49:05] even the throttle delay fix, right? [18:49:15] good question, I'm pretty sure [18:49:47] yep [18:50:21] https://github.com/virtualagc/virtualagc/blob/master/Zerlina56/CONTROLLED_CONSTANTS.agc#L144 [18:50:59] seems like this kind of information was never communicated very well to MIT... [18:51:53] throttle lag, thrust buildup during the first burn [19:01:42] all unimportant details [19:01:49] oh shit the forum is up [19:02:12] a wonder! [19:04:17] might not be a bad idea to back up any important information from it while it's there... [19:06:52] is it possible to proper forum backups? [19:06:55] to do* [19:08:16] I would assume so [20:40:06] You can backup the wiki alright. Forum not so much. Maybe dseagrav since he has a privileged account. [08:35:51] hi [13:16:51] hey [13:17:23] hey [13:18:19] just have one problem so in apollo 11 i am 6 hours in and when i try to do the p23s i enter in the codes and when i press pro i get an opp err light [13:19:53] sounds like you forgot to press enter or chose a wrong code or something like that [13:20:49] what code did you use? [13:21:58] 6 hours in probably means it's the first P23 [13:22:15] the flight plan has "STAR 02 ENH (R3-00110)" for this [13:23:49] yes that is what i did [13:24:49] so for Noun 70 (the P23 code) that means: [13:24:54] R1: 00002 [13:24:59] R2: 00000 [13:25:03] R3: 00110 [13:25:08] no + or - [13:25:18] shouldnt r2 be 00100? [13:25:32] for the earth option [13:25:43] only for the Earth landmark option [13:25:51] but you are doing horizon marks [13:25:59] either R2 or R3 is always going to be all 0s [13:26:26] https://www.ibiblio.org/apollo/Documents/A8-CMP%20checklist-1004.pdf [13:26:32] this is the Apollo 8 CMP Checklist [13:26:50] PDF page 20 has something useful for this [13:27:50] that was probably the problem [13:28:00] yeah, probably [13:28:23] R1 is for the star, R2 is the option code for the landmark, R3 is the option code for the horizon tracking [13:28:34] and I think on Apollo 11 you only do the star/horizon method [13:29:07] and as for the sep attitude for tli if i was to start a brand new scenarios would the sep attitude be the same everytime [13:30:02] very close to the same, yes [13:31:22] okay thanks [14:33:48] indy91 got your message about the aluminum spelling, I must have changed that while sick and not thinking clearly. I do know that both spelling's are correct :P [14:34:51] I even had a professor in college teaching inorganic chemistry from England who pronounced it that way and spelled it that way, threw his majority American class of chem students off :P [14:36:03] Also, before I go, I have a Docked DPS burn vid up on youtube if you haven't seen it :) [14:36:07] https://www.youtube.com/watch?v=S7qu-GqQDJw&t=342s [14:49:44] hey Ryan [14:50:01] haha, I was mostly amused by the aluminum change [14:50:12] and I've seen the video [14:50:17] steady like a rock [14:53:16] and good news, in my experiments I found a solution for the GetWeightVector issue [14:53:52] Oh? [14:53:53] if that function returns a 0 vector, as it usually does while a vessel is landed, I am simply calculating that vector on my own, with the current position [14:54:52] Is this for "docked" vehicles on the ground? [14:55:01] basically yes [14:55:11] our hack with unsettling the vessel by adding a force to it when a new Orbiter session was started can be removed [14:55:23] we've had to do that for the landed Saturn and LM [14:55:35] or else the accelerometers wouldn't properly work [14:55:39] Oh great! I remember that cheat [14:55:53] and for docked vessels on the ground that hack didn't work [14:56:17] because the relevant vessel (S-IVB with the IU) doesn't actually touch the ground [14:56:45] and then the weight vector is always returning 0, even in the unsettled state [14:56:50] So is this going to start the initiative to separate the vehicles out individually early instead of spawning them later? [14:57:07] it's one step closer to making that possible, yes [14:57:36] this new method is still a hacky, a more complex but all around superior hack though :D [14:57:57] Oh that reminds me i added earth to the LM config if you wanted to use it for apollo 5 [14:58:27] I guess it can be coded like the CM during launch [14:58:39] To relieve atm pressure [14:58:40] maybe, I also want to add a more general atmosphere tank class or so [14:59:01] That could be useful [14:59:08] which would always have the exterior conditions of the vessel [14:59:29] Pressure and temp based on altitude [15:00:17] yep [15:00:37] it just has to emulate the functionality of a normal tank [15:01:00] but it wouldn't actually do the calculations for one, like pressure, temperature, energy state [15:01:41] Just a static number based on altitude [15:02:50] yeah, the refresh function would just use the exterior conditions every timestep [15:04:38] do we simulate N2? [15:06:03] That refresh would eliminate a bunch of code in the csm for a launch [15:06:50] Eliminate the need for it anyways [15:07:43] do we simulate N2? [15:08:22] The substance is there yes but i dont remember if the earth tank has it [15:09:08] I dont think N2 is simulated as an atmosphere component [15:09:10] ah, that might get complicated, after all the mixture in the CSM at launch isn't the same as Earth atmosphere [15:09:26] 60 40 I believe [15:09:27] oh, in that case, it's simply oxygen [15:09:36] if we don't simulate N2 so far [15:09:42] Yeah [15:10:14] I mean we could simulate it and the subsequent cabin purge [15:11:01] Prime crew ingress could set the ratio in the cabin but the suits would need pure oxygen [15:11:36] Id be curious to play with that when we start messing with the cm ecs [15:11:52] yeah [15:13:21] ok, the accuracy of the calculated weight vector (instead of the one from the Orbiter API) seems acceptable. I have to do it on a case by case basis and while landed in Earth the gravity of the Moon is neglected. [15:13:25] but that is tiny anyway [15:13:57] and this is only important for EMS and LV IMU anway [15:13:59] anyway* [15:14:22] EMS has certain accelerometer accuracy requirements, but it's good enough to pass the EMS tests [15:14:33] and LV IMU is only running for 17 seconds before liftoff [15:14:47] and the hack isn't needed anymore once the engines are starting up [15:15:17] Would this mess with the LM T/W in lunar influenxw? [15:15:20] Influence [15:15:39] the mechanical accelerometer? [15:15:49] I've given it the same hack [15:15:49] Yes [15:16:26] and the hack is only used at all if the Orbiter GetWeightVector function is return a vector with all 0s [15:16:32] which can only be the case while landed [15:17:01] we have a bunch of accelerometers, but I've the same function everywhere [15:17:19] IMU, LV IMU, EMS, mechanical accelerometer (in CSM and LM), ASA [15:17:28] I've used* [15:18:38] I've used a "length(w) == 0.0" check and only if that returns 0 then the weight vector is calculated instead of taken from the API [15:21:46] Ok [15:22:30] so there shouldn't be any noticable change [15:23:11] our vessels, especially the Saturn IB, tend to move and rotate a bit when the force was added [15:23:25] that should also not happen anymore [15:29:09] Great [15:31:55] IU state vector accuracy seems to be the same as before, so that is good [15:32:07] no "transient" between using the calculated and API weight vector [15:34:40] How is the SV accuracy doing any improvement? [15:35:06] not really [15:35:18] especially the Saturn IB is quite bad [15:35:26] some update I did to the LVDC is the cause, I am sure [15:35:44] but the accuracy is good enough [15:36:05] 2800 meters for the Saturn IB it was [15:36:07] at insertion [15:36:21] and I am just testing an Apollo 8 launch [15:37:25] 800 meters at insertion [15:37:33] not bad [15:37:56] still, twice of what we usually got in Orbiter 2010 [15:51:31] now I can test the docked Saturn IB launch again [15:51:42] last time it did a fun spin [15:52:06] it reached space actually, but not exactly in a controlled fashion :D [16:14:51] seems to be working [16:16:19] What about the SV [16:16:22] Saturn V [16:17:10] that is just one or more stages added on top [16:17:19] I should say, what I currently have is very primitive [16:17:43] our S-IB stage was not much more than a mesh that could be shown falling away [16:17:55] all the relevant code only exists in the Saturn class [16:18:05] so that will be a lot of work to move the code over to the S-IB vessel [16:18:51] I'll show you a picture of my test setup [16:18:59] just a S-IB and S-IVB docked together [16:19:17] https://i.imgur.com/IRGaQ6O.png [16:19:46] the S-IVB code can't properly handle closed panels [16:20:00] well, I would have to change the scenario a bit, then it probably can [16:22:15] but I don't have to do much, close the panels, dock a nose cap on top of it, give the stages the right amount of fuel [16:22:23] and then I basically have AS-203 [16:23:21] if I can do that and get a good insertion, all without too much hacky changes, then it's probably worth the effort to pursue the separate stages project [16:32:56] Would that help with a variable CoM in the LM? [16:46:48] oh yes [16:47:08] having separate ascent and descent stage vessels would solve it completely, at least for the DAP [16:48:47] I just found that we have Little Joe meshes [16:49:08] with separate vessels we could easily dock a CM or CSM to any other stage we would like [17:33:39] morning! [17:35:25] hey Mike [17:35:58] what's up? [17:36:36] I fixed one major obstacle for us to have the Saturn stages as separate vessels in Orbiter [17:36:50] nice!! [17:37:21] so now I can try to recreate AS-203. And if that works, accurately and without major hacks, then this can be done with all the Saturn stages, CM, SM and the LM stages [17:38:15] hah, no wonder I didn't know what AS-203 was -- it didn't have a CM at all [17:38:47] that's awesome [17:39:57] so I tried to fly Apollo 5 again last night [17:40:30] it started well, and S-IVB/LM separation is very pretty [17:40:45] yeah, AS-203 would just be S-IB, S-IVB and a nosecap vessels [17:40:50] most simple case [17:40:55] yep [17:41:33] so I was fiddling with the telemetry client in the background, and at some point orbiter popped up that it had lost its connection to directx, and that I should close the client and reopen it [17:41:51] ah, that is an annoying thing with the DX9 Client [17:41:53] and when I did so the LM was tumbling and it had a program alarm, that I couldn't read because the DSKY displays were all garbled [17:41:56] I used to get that very often [17:42:06] yeah, if that happens the simulation is broken [17:42:12] booo [17:42:22] surely you saved very often :P [17:42:28] back to launch for me! [17:42:30] :D [17:43:03] it still did DPS-1 at least [17:43:06] I haven't gotten that DX9 Client "crash" in a long while [17:43:10] just, while it was tumbling, and it deorbited itself [17:43:14] haha [17:44:06] what I noticed was that when I had the browser open then opening certain websites could make the DX9 Client fail [17:44:25] might even be adblocker related [17:44:31] I am fairly certain this was my fault [17:44:51] because I was going through different versions of Visual Studio trying to get the telemetry client project to even open [17:44:59] I was tempting fate with that one [17:45:17] yeah, this doesn't happen completely on its own. Some outside application messing with the graphics, in some way. [17:45:36] setting up a new visual studio seems like a very likely candidate [17:45:48] could be, yeah [17:46:10] so next time all you have to do differently is save once in a while :D [17:46:15] yep! [17:46:21] especially after major events [17:46:27] and if possible in P00 [17:46:40] saving while accelerometer readings are done doesn't work so good [17:46:53] really, though, I wasn't too mad, since yesterday was the 50th anniversary, and it's in the spirit of things for everything to go terribly wrong at DPS-1 [17:47:02] true [17:47:18] so about the telemetry client [17:47:32] ours or your new one? [17:47:33] I am not too surprised that dseagrav deleted it, heh [17:47:36] yours [17:47:41] ok [17:47:50] I've never successfully build it [17:47:50] I wasn't able to import it into visual studio 2017 at all [17:47:53] the exe is working fine [17:48:10] visual studio 2013 was able to import it but gets several thousand compile errors [17:48:16] ouch [17:48:26] I wasn't even able to run the EXE [17:48:31] it said my system wasn't supported [17:48:34] although [17:48:37] that might be Thymo's fault [17:48:38] oh, weird [17:48:39] I should try again [17:48:58] I've always used the exe that was build about 10 years ago [17:49:14] I started with Thymo's repository, and all of the files in that have all of the CVS metadata at the beginning, which took a while to figure out, because VS was just complaining about corrupted files [17:49:32] I think the EXE probably had the same problem :P [17:50:57] I'll play with it a bit more but it might not be a bad idea to make a new one [17:51:25] yeah [17:51:45] we have all the old code, so I am sure some of it can be reused [17:51:49] just in a new VS project [17:52:14] new VS project and probably a new GUI [17:52:31] most of the problem seemed to be that newer VS versions don't support how the GUI was made anymore [17:52:47] even back in 2010 it was deprecated, I think [17:53:32] yeah, the original VS solutions are for 2008 and 2005, I think [17:53:40] yep [17:56:18] Hey. Busy day. [17:56:31] hey Thymo [17:56:37] The telemetry client is written in .NET 2005 or something so you'll need the redists. [17:56:51] CVS is a pita with all that metadata. [17:57:09] I'd also go for a rewrite in C++ or Python. Anything but .NET. [17:57:25] heh, yeah, I was strongly considering making a python thing [17:57:31] The exe from the repo works, I tried it. Might be a missing dependency. [17:57:43] nah, I'm fairly certain the metadata is the problem [17:58:50] mike@elnath:~/Downloads$ hexdump -C GroundStation.exe | head -n7 [17:58:51] 00000000 68 65 61 64 09 31 2e 31 3b 0a 61 63 63 65 73 73 |head.1.1;.access| [17:58:51] 00000010 3b 0a 73 79 6d 62 6f 6c 73 3b 0a 6c 6f 63 6b 73 |;.symbols;.locks| [17:58:52] 00000020 3b 20 73 74 72 69 63 74 3b 0a 63 6f 6d 6d 65 6e |; strict;.commen| [17:58:53] 00000030 74 09 40 23 20 40 3b 0a 65 78 70 61 6e 64 09 40 |t.@# @;.expand.@| [17:58:53] 00000040 62 40 3b 0a 0a 0a 31 2e 31 0a 64 61 74 65 09 32 |b@;...1.1.date.2| [17:58:54] 00000050 30 30 37 2e 30 31 2e 30 32 2e 30 31 2e 35 34 2e |007.01.02.01.54.| [17:58:55] 00000060 34 33 3b 09 61 75 74 68 6f 72 20 64 73 65 61 67 |43;.author dseag| [17:59:09] pretty sure that is not supposed to be in an EXE :D [18:00:00] the telemetry client did actually make it to github in dseagrv/NASSP, so I got it from there instead [18:00:16] it was deleted in late 2015, just gotta go back far enough in the commit history [18:00:34] yeah, he wanted it to be a separate project [18:00:42] didn't need to be in the NASSP download [18:00:48] yeah that's fair [18:06:20] hi indy 91 [18:06:58] do you still have that procedure for the p23 cislunar navigation with the codes because i think i may have lost it [18:07:44] https://www.ibiblio.org/apollo/Documents/A8-CMP%20checklist-1004.pdf [18:07:47] PDF page 20 [18:07:53] thank you [18:07:58] no problem [18:15:52] so how is the lem coming along? [18:17:26] most systems are implemented. caution and warning system needs a lot of work, ECS is in the fine tuning phase. [18:18:10] thats good [18:20:19] and for the p23 what is the difference between the torque and coarse options? [18:21:42] uhh, P23 has that? [18:21:50] yeah [18:21:54] what does the DSKY show for that? [18:21:55] for apollo 11 [18:22:44] cant remember but i think in the checklist mfd it says pro for torque and fail for coarse [18:23:24] oh, the Checklist MFD. I wonder if that is just wrong terminology chosen for the checklist. [18:24:16] i tried both and the dsky gave me different options [18:25:23] torque and fail would be options for P52, IMU alignment. But P23 also has an option like that [18:25:49] it would show V06 N49 [18:26:18] then pressing PRO would change your onboard state vector based on the P23 markings you did [18:27:23] I'm looking at the Apollo 11 Checklist MFD file, it doesn't have torque or coarse align, but it has "dR,dV >0050.0 Fail to Reject" [18:27:36] where you would press PRO on the Checklist MFD to continue, or fail to try again [18:27:46] yeah i might have the p52 and p23 mixed up [18:28:02] i know it said it for one of them [18:28:51] torque and coarse align is two different methods of changing your IMU alignment after P52 marks. [18:29:44] usually you would choose torque for a small angle difference, that should be the case for most P52 option 3 [18:30:07] and coarse alignment for larger IMU angle changes. For P51 or P52 option 1/2. [18:31:21] okay [18:31:24] thanks [18:32:12] torquing can take a while, but the IMU stays inertial the whole time and it stays accurate the whole time. [18:32:56] coarse alignment is very quick, but it fixes the IMU for a few seconds. So if your CSM is rotating a little bit, then you will loose that attitude information and your alignment is not perfect. [15:59:46] morning [16:01:13] hey Alex [16:01:47] I've worked out a fix for the AddForce hack we have to do [16:02:45] and now I am experimenting with launching docked S-IB and S-IVB into orbit [16:03:59] oh great [16:04:09] how did you fix it? [16:05:13] if the Orbiter GetWeightVector function returns a 0 vector, then our accelerometers are now calculating that vector on their own, based on current position [16:05:35] it calculates the gravity of the current major body (Earth or Moon) and the Sun [16:06:02] this will only work accurately very close to the body, but this new hack inly has to be done while landed anyway [16:06:09] only* [16:07:06] So I guess the plan of launching a docked stack is back on the table [16:07:25] yep [16:08:05] I already managed to get docked S-IB and S-IVB into orbit. The IU state vector is fairly bad though, 8000 meters or so at insertion [16:08:23] and there is a jump at liftoff, from 11 meters to 400 meters [16:10:24] https://www.dropbox.com/s/wil58jg7jpd3tl0/crash.png?dl=0 [16:10:53] haha, yeah, I remember [16:11:07] and I haven't docked anything to the ML or a launchpad (yet) [16:11:09] I think your doing a better job than I did :D [16:11:12] just S-IB+S-IVB [16:11:21] right [16:11:28] and tweaked the touchdown point definition to get that to work [16:12:10] Have you managed a docked ascent yet? [16:13:27] oh yes, it reaches orbit. Some mass or thrust parameters are probably off, the achieved orbit is a bit too high and not circular [16:13:42] and the SV isn't too accurate [16:13:57] but the LVDC controls the whole thing [16:14:19] nice [16:14:21] the only major code changes were for sending commands from the S-IVB vessel to the S-IB [16:15:37] it doesn't even need any fancy connector class [16:15:49] I just check every timestep if there still is a vessel docked [16:15:55] and what kind of vessel it is [16:16:09] if the right vessel is docked (S-IB) then commands can be sent to it [17:07:30] hi [17:08:02] so im getting that crash to desktop again at the lem ejection but it only happens sometimes [17:10:04] I'll try to debug that issue soon [17:10:17] okay [17:11:13] it doesn't happen everytime though [17:13:03] do you have a recent scenario that I could use for debugging this? [17:13:15] yeah [17:13:21] that would speed up the process of finding the bug causing this [17:13:33] can you put it on Dropbox or so? [17:15:27] yeah i have to create an account [17:16:05] or put it somewhere else, it's just a text file [17:16:11] pastebin maybe [17:16:40] https://thepasteb.in/p/vghOg7DqK88c3 [17:17:11] does that work [17:19:15] yeah, I think so [17:19:21] thanks! [17:19:48] it might have been created it orbiter 2010 though [17:20:13] oh [17:20:15] hmm [17:20:23] well, I will try it [17:20:27] okay [17:20:53] the scenario is at around GET 3:40:00 [17:22:41] seems to work, I can eject the LM right away. Now I have to cause the CTD... [17:23:34] the CTD happens in the most recent NASSP version for Orbiter 2016 though, right? [17:23:44] yes [17:23:57] morning! [17:24:55] actually the most recent one i have i think was from three days ago [17:25:18] recent enough [17:25:37] there has been some changes to the docking/docking probe code a few months ago. I am sure this CTD has to do with that. [17:25:42] hey Mike [17:25:48] yeah [17:26:00] tried it 6 times, no CTD so far [17:26:11] so it's really inconsistent, unfortunately [17:26:27] did you do it excactly at 4:09:45 [17:27:38] no, I did it right at scenario start [17:27:51] yeah when i do that it doesnt ctd [17:27:52] well, first had to arm the pyros etc. of course [17:28:06] I'll do a bit of time acceleration and try it again [17:28:10] okay [17:29:43] and did you use the checklist mfd? [17:31:41] no, I only did the few steps necessary to be able to eject the LM [17:32:27] yeah it only happens during lem ejection but after that everything is fine [17:36:12] didn't CTD even at the nominal LM ejection time. I guess I will try this again a few more times over the next few days. Once it does the CTD I should be able to find the issue with the Visual Studio debugger. [17:36:29] okay [17:37:57] and can you use the checklist mfd when you do it? [17:38:29] because when i do it right at the beginning of the scenario it usually never crashes to desktop [17:40:01] I've had the Checklist MFD in auto-execution mode, where it automatically sets all the switches itself. But I guess you were using the normal "Auto" mode, right? [17:40:16] yes [17:40:27] and i was using the rtcc mfd for the weights of the lem and csm [17:40:50] and it was happening when i switch the view or press a button [17:40:59] oh, interesting [17:42:35] and do you have ANY scenarios after the lem ejection? [17:44:40] yes, probably. Just outdated. [17:45:00] did you change the view very shortly after doing the LM ejection? [17:45:09] before [17:45:12] and after [17:46:52] when i say change views i mean like viewing other panels like the pyros on the left side [17:48:40] ok [18:12:43] alright, I've requested the G&N summary docs for 11 and ASTP, and the Apollo Guidance and Navigation Information document, which may or may not be an early equivalent of the summaries [18:22:02] great [18:29:52] also getting close to finishing the initial rework on yaAGC [18:30:41] I'm missing support for parity-induced restarts and I want to streamline channel 163 updating [18:30:53] but everything else appears to be working [18:32:12] I think I'm going to request some of the G&N study guides soon to, because I've caught wind that there may be a couple of JDCs hiding in one or some of them [18:32:23] *too [18:56:25] yeah, sometimes you find the good stuff in the non-obvious places [12:45:13] hi [12:47:33] so i managed to get up to the sleep period with apollo 11 [12:48:40] hey [12:49:19] and for the p52 for the first star it seemed that the lem was in the way of it [12:49:27] ah yeah, that can happen [12:49:42] but i pressed mark and then it gave me 00004 [12:49:51] and the second star was fine [12:50:17] the AGC can't do any calculations for that, so often MCC would tell the astronauts to maneuver to a better attitude. Or give them the stars to use, instead of letting the AGC decide. [12:51:14] +00004 isn't great, but good enough. [12:51:25] Although, I think the threshold to repeat the P52 is +00003 [12:52:01] what you can do is simply mark on another star than what the AGC told you. But then you have to change the star ID after the mark. [12:53:11] and how do you change the star id [12:53:24] so you see that the LM is in the way of the star you actually wanted. Then you move the optics and mark on another star. Then you get the 00016 press PRO and it displays the star code once again. At that point you change the number with V21E [12:53:58] okay [12:54:13] so when the flasing V01 N71 is up, that's when you change the star code [12:54:16] flashing* [12:55:37] you said you got up to the sleep period, how did MCC-1 go? [13:01:25] good [13:01:37] just had to input the tig [13:02:15] great. Are you using Orbiter 2016 or the Orbiter Beta? [13:02:20] beta [13:02:23] ok [13:02:51] tried that scenario that i posted yesterday and got no ctd [13:02:59] tried it twice [13:03:05] yeah, seems very inconsistent [13:03:20] yeah but like i said it only happens sometimes for some reason [13:04:22] and i think you said that the max time acceleration was 50 for the trans lunar coast? [13:07:03] yeah, that is the maximum I have been using. It's probably possible to go faster, but it becomes more likely then that a small frame rate drop could break your scenario. [13:07:19] So I've been playing it safe [13:07:49] an 8 hour sleep period is only 10 minutes at 50x, so it's not so bad, I think. [13:17:14] yeah [16:03:02] hey [16:08:23] hey Alex [16:08:53] I got annoyed about the LVDC, the IGM always seemed to overshoot the altitude in my tests. So I started a bit of bug hunting. [16:09:28] and I think I found a few things [16:11:35] interesting [16:11:54] One bug had to do with the guidance cycle during IGM, which is 1.7 seconds long. Because this is a fairly significant long time to generate steering angles, the IGM has some calculations to compensate for that. [16:12:17] And those calculations were basically not used, because the time constant for this which should be 1.7 seconds was set to 0. [16:12:52] not good [16:13:16] sounds like an easy fix though [16:13:20] yeah, the effect is basically that the Saturn was pointing in the direction where it should have been pointing 1.7 seconds ago [16:13:27] or maybe 1.7/2, not sure [16:13:33] yeah, it is an easy fix [16:13:38] just testing it [16:14:16] so as you can imagine, the Saturn will now pitch down slightly earlier [16:14:27] on my end im re-flying Apollo 11 [16:14:33] because it anticipates where it should be pointing [16:14:51] this will also effect the Saturn V, same bug. [16:15:04] so the ascent should be smoother all in all [16:16:39] Yep, it seems to help. [16:16:56] In the Apollo 5 scenario Sunburst can now properly do a COI [16:17:30] previously the stack had too much of a negative altitude rate when I commanded S-IVB cutoff [16:18:02] now it overshoots the insertion altitude not so much and it tries to achieve that altitude earlier, and not at the last minute [16:18:17] I'll do one Saturn V test run, just to see how that performs now [16:20:11] and the other fixes I did make the transition from pre to post MRS smoother [16:20:16] just for the Saturn IB though [16:20:33] I'll have to check if the same equations (and same bugs) apply to the Saturn V one [16:21:10] Have you stacked the docked Saturn V yet? [16:21:16] no, not yet [16:21:43] I was doing AS-203 tests and got annoyed about these IGM bugs, so I've only been looking into that [16:21:58] right [16:22:18] Apollo 11, are you at LM ejection yet? [16:22:32] Ryan also did some ECS tweaks [16:22:43] so maybe the LM pressurization works better now [16:22:50] Im about to fly TLI [16:22:55] ah, I see [16:22:59] Need some testing scenarios? [16:23:18] sure, one pre TB6 and one pre LM ejection would be good [16:23:25] sure [16:27:37] even with these IGM bugs fixed, there still are some LVDC navigation issues in my docked Saturn IB, which are worse than in the undocked version. [16:30:15] bummer [16:32:18] yeah, I'll have to figure out what causes that before I can make the recommendation to break NASSP for a months to rebuild it with separate Saturn stages :D [16:33:07] yeah, maybe what we have now is good enough for NASSP 8? [16:33:52] hmm, good point, maybe the separate stages is better for NASSP 9 [16:34:22] NASSP 8 would still need: CWEA, MCC for Apollo 9-11, LM ECS tweaks, bug fixes [16:34:30] I mean we're already pretty far along with NASSP 8 [16:34:37] yeah [16:34:43] so maybe I'll work on the MCC next [16:35:06] I guess we need to coordinate CWEA with Thymo [16:35:39] I'll do a few more days of experimentation with the docked stages, but I won't start the actual work for that then. [16:36:06] Yes, I've got 2 more projects to hand in tomorrow and then two exams on Monday and Wednesday. After that I'm fully available again. :) [16:36:20] great [16:36:55] it will be nice to have a working CWEA, looking forward to that [16:38:22] I'm not sure I am looking forward to the warning tone :D [16:39:30] I will have to coordinate with Thymo what still needs to be added to the SCEA. Whenever you see a box with SC1 or SC2 in the Systems Handbook, then I have to implement that and the CWEA needs to get its information from the SCEA and not directly from the ECS. [16:43:07] makes sense [16:44:01] LVDC fixes pushed [16:44:26] this will mostly affect the Saturn IB ascent, Saturn V not so much it seems [16:44:52] Apollo 5 and 7 are definitively better [16:45:58] and this push also had the accelerometer hack [16:46:07] with all AddForce removed [16:47:22] AlexB_88, it never should make a difference in orbit, but on your way on the Moon you will find bugs with these accelerometer changes, if there are any. [16:48:37] Ill keep a watch [16:49:41] will this update break my current scenario? [17:00:39] no [17:24:48] Is SM RCS jets while still attached to the SIVB still in the works? [17:25:31] that will be much easier with the docked stages, haha [17:25:35] but I'll think about it [17:26:36] no worries, its not overly important haha [17:29:21] you just want to try ALL of the TLI backup procedures, I know [17:30:12] morning! [17:33:01] hey Mike [17:33:24] I have a small research project for you [17:33:28] oh boy [17:33:31] or rather, find a document [17:33:40] because you are quite good at that :D [17:33:41] lol [17:33:45] what do you want? [17:34:04] I was looking for more information on the Saturn IB/V countdown, especially the terminal countdown sequence [17:34:16] and I found what document probably has that [17:34:40] https://i.pinimg.com/originals/ca/9d/7e/ca9d7ea61cd0d50a40b07b698c0f24e5.jpg [17:35:12] volume 2 of that document is avilable [17:35:13] https://ntrs.nasa.gov/search.jsp?R=19720020267 [17:35:25] volume 2 deals with turnaround from scrub, as the title says [17:35:35] volume 1 would have the normal countdown [17:36:00] damn [17:36:10] lol [17:36:16] interestingly, this document is sold on amazon [17:36:17] https://www.amazon.com/Americas-Apollo-Moon-Rocket-Countdown/dp/1893472205 [17:36:40] hmm [17:36:50] so, there are a lot of things that are similar to that on ebay quite frequently [17:36:56] and I found this document for SA-7 actually, which is just a liiiitle bi too early [17:36:56] https://www.ebay.com/itm/APOLLO-6-AS-502-UNMANNED-OPS-SUPPORT-VEHICLE-LAUNCH-COUNTDOWN-MANUAL-VOL-1/323027821112?hash=item4b35f56238:g:qhUAAOSwB4NWx97- [17:36:58] bit* [17:37:09] heh [17:37:09] yeah [17:37:11] indy91, [17:37:13] https://www.dropbox.com/s/mrjjexdnan84kdv/Apollo%2011%20MCC%20-%20Before%20TB6.scn?dl=0 [17:37:15] there's been a lot of those and they pop up frequently [17:37:19] AlexB_88, thanks! [17:37:30] https://www.ebay.com/itm/APOLLO-12-AS-507-LAUNCH-VEHICLE-OPERATIONS-ASSEMBLED-FOR-CDDT-MANUAL-VOL-1-ONLY/323013029351?hash=item4b3513ade7:g:1cMAAOSwdGFYw62h [17:37:33] that's for AS-507 [17:38:06] I adn't seen the AS-502 one [17:38:08] hadn't* [17:38:11] unfortunately they're a bit... ambitiously priced [17:38:35] yeah [17:38:43] surely they are in some archive [17:39:16] Atlanta NARA, almost guaranteed [17:40:52] not that that does us a lot of good until somebody goes there [17:41:33] right [17:41:44] "Apollo/Saturn V Launch Vehicle Countdown [17:41:45] (Released for AS-506)." (KSC. K-V-0513-2 (TCP [17:41:45] V-40300). July 3, 1969.) [17:41:51] Bellcomm Collection [17:42:03] https://sirismm.si.edu/EADpdfs/NASM.XXXX.0093.pdf [17:42:17] oh! so we can send Ryan or somebody can request to have it scanned [17:43:26] send Ryan is a good plan [17:43:33] any objections? [17:43:36] no, good [17:43:39] lol [17:44:04] we've only got a month before he moves to Alaska so we should figure out if there is anything else there for him to look at [17:45:33] ah, right [17:45:53] in other news, I found some bugs in our LVDC and now the ascent to orbit is a bit smoother for the Saturn IB. [17:46:04] Which leads to the LM being able to do the COI [17:46:08] oh sweet! I will try it out tonight :D [17:46:52] I tested cutoff at the same time as one of the Sunburst test runs (7400 m/s) and it reached the right insertion conditions [17:47:02] that's awesome [17:47:03] it's still really close [17:47:18] it looses a lot of altitude and then has to fire upwards a lot [17:47:37] but that should be fairly close to how an actual COI would have worked [17:47:58] yeah, I was following along with the SCOT during my first launch and that seems pretty expected [17:48:20] from the Apollo 5 Technical Information Summary I know that the S-IVB cutoff sequence was one single uplink [17:48:38] right now you have to do 3 uplinks to the LVDC [17:48:41] with the PAMFD [17:48:52] S-IVB cutoff, nosecap jettison, SLA deployment [17:49:07] but that was stored as an alternative sequence in the LVDC. So I am adding that to the PAMFD [17:49:26] so all you will have to do for the COI test is that uplink to the IU and then the COI uplink to the LGC [17:49:44] excellent [18:00:56] I guess the most realistic COI scenario would be some S-IB engine failure, which results in the S-IVB not having enough propellant to reach orbit. Close, but not quite enough. [18:01:12] an actual S-IVB engine failure within 15 seconds of orbital insertion seems not very probable [18:09:48] yeah that sounds pretty darn unlikely [18:10:24] 15 seconds early is what the Sunburst test used [18:10:38] of course the LM needs much longer for that [18:30:02] I guess Ryan hasn't changed the LM ejection checklist yet so that the pressure equalization is done after ejection [18:30:37] or do we want to keep it as the real time line? [18:32:47] hmm, Checklist MFD should probably be like it works in NASSP [18:35:13] yeah, I remember him saying he changed the order to work with NASSP, maybe he just didn't have a chance to fix it on Apollo 11 [18:35:56] could be, yeah [18:45:13] https://www.dropbox.com/s/78aqezg6q23hxl8/Apollo%2011%20MCC%20-%20Before%20LM%20ejection.scn?dl=0 [18:45:30] thanks! [18:46:32] in that scenario, the checklist MFD is at the proper page for LM etraction, but you then have to manually go back to the CM/LM pressure equalization checklist/LM POWR - CSM as I skipped it since the LM isnt created yet [18:46:47] ok [18:47:19] So hopefully Ryan will re order it correctly for that reason [19:04:19] crap I lost all pressure indications [19:07:14] https://www.dropbox.com/s/t5sqcpfxz1amaqn/Apollo%2011%20MCC%20-%20Launch%200004%200011%200021.scn?dl=0 [19:09:43] thats right before it happens, that scenario is during pressure equalization, press equal valve has been open for about 20 mins and pressure slowly equalizing then boom all my pressure indications disappear and there's a bunch of nan's in the ECS section of the quicksave [19:15:02] yep, I've had that a few times as well [19:15:16] it's something with the suit circuit, I believe [19:15:25] Ryan hasn't found the cause yet [06:17:47] .tell indy91 I've been looking through Sunburst padloads and I think I have a tweak for you [06:19:10] .tell indy91 we should try setting our old pal FORCETRM to +200 instead of -0 [06:19:14] .tell indy91 http://www.ibiblio.org/apollo/listings/Sunburst120/Q_R-AXES_REACTION_CONTROL_SYSTEM_AUTOPILOT.agc.html#54524D434845434B [06:20:13] .tell indy91 "CHECK IF TRIMCNTR HAS BEEN COUNTED DOWN TO ZERO, INDICATING THAT 20.0 SECONDS HAVE PASSED SINCE DPS ON AND CONTROL SHOULD BE TRANSFERRED TO GTS." -- and it's decremented once every 100ms to -0 [13:26:15] hi [13:26:30] just having a problem with the p23s [13:26:49] it is kind of difficult to control the yaw [13:27:20] i read somewhere on the forum that there might be a minimum impulse controller [13:37:00] hey [13:37:53] so, the minimum impulse controller is used with the AGC [13:38:17] but the SCS also has a minimum impulse mode [13:39:23] the minimum impulse controller is in the lower equipment bay, so it would be used by the astronaut doing the P23s [13:39:33] I think it is used with shift and the numpad keys [13:39:35] I'll check [13:40:16] no, it's actually Shift + WASD [13:40:26] and Q and E [13:40:38] http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2922.msg24957#msg24957 [13:50:26] shift doesnt work [13:50:45] its just the yaw im having problems with [14:43:28] if the minimum impulse controller doesn't work, then you can use the minimum impulse mode of the SCS [14:44:13] yeah its just the yaw is hard to control for me [14:45:04] do you mean roll? [14:45:35] it confuses me too, the CSM and LM have different definitions for roll and yaw, haha [14:45:56] nope its the yaw [14:46:05] left to right [14:48:05] and the pitch [14:48:20] too much control authority? [14:48:59] too little [14:50:07] the roll is easy [14:50:38] oh, so you mean it's not maneuvering enough in pitch and yaw when you deflect the RHC? [14:50:53] yeah [14:50:56] using the minimum impulse modes would make that even worse [14:51:21] minimum impulse means the RCS is firing as short as possible [14:51:26] yeah [14:51:42] i could try rate command [14:51:55] yeah, that is better [14:52:02] maybe minimum impulse for roll [14:52:08] yeah [14:52:21] but not pitch and yaw when you have the docked CSM and LM, both still full of propellant [14:52:58] I guess you will have to get used to it, that's simply how CSM+LM docked behave [14:54:37] yep [15:21:32] morning guys [15:22:39] hey [15:25:46] In light of the issues I have with pressure equalization, I think ill skip pressurizing the tunnel/LM via the CSM until LM activation where Ill pressurize the LM from the LM ECS only [15:28:39] if you want to help debugging this, then a scenario just before everything becomes NaN would be great [15:29:01] how long did that take anyway? [15:29:17] I've been trying to replicate it in the scenario you have me, pre LM ejection [15:29:20] gave* [15:31:22] here: [15:31:23] https://www.dropbox.com/s/t5sqcpfxz1amaqn/Apollo%2011%20MCC%20-%20Launch%200004%200011%200021.scn?dl=0 [15:31:40] Its fine in that scenario and then after 1-2 minutes, it happens [15:31:53] ah, great [15:32:12] you know what, I didn't properly read your comment yesterday [15:32:27] I thought the scenario you posted was just AFTER the issue [15:32:42] haha I could have worded it better lol [15:34:44] hmm, interesting, the LCG pump is on [15:35:01] if it tries to pump a near vacuum then bad things could happens [15:35:54] it's wired correctly [15:37:48] CB is open, so it shouldn't actually pump [15:39:05] took 5 minutes, but then it happened [15:39:13] this should be a good scenario for testing [15:39:56] I have seen the same issue happen in the LM alone once, too [15:40:14] yeah, it certainly originates in the LM [15:40:48] Or at least I think it was the same issue... I was in lunar orbit and playing around with ECS and suddenly lost all indications for pressure/temps [15:41:07] it happens when it some part of the LM there is very low pressure [15:41:29] it happened in my Apollo 5 scenario as well, when I had all the suit circuit related CBs and switches in off [15:41:50] maybe some initial values that are not correct/too low? [15:41:52] but it didn't happen if the suit circuit controls were in the nominal config [15:43:26] interesting, in the LM glycol loop the energy state is NaN, but not the masses [15:43:41] but in other parts the mass is NaN as well [15:43:58] H2OSURGETANK has NaN mass [15:51:13] weird [15:51:43] so would that point to the glycol loop maybe? [15:52:39] actually no, the glycol loop only does an energy exchange with the suit circuit [15:52:49] so the actual issue is somewhere else [15:59:44] I added some code to the thermal calculations, that detects if a component mass is NaN. Let's see where this points to... [16:04:48] ah, the first tank that has a NaN component is called SUIT [16:06:02] uhh, that is in the CSM [16:14:17] also interesting, it happens more easily in time acceleration [16:16:19] at 1x it takes longer, if it happens at all [16:28:01] hmm hadnt tried it at 1X [16:30:42] I'm trying to find the initial NaN step by step [16:31:08] the water separator and CO2 scrubber are the first to break down, but at that point the connected tanks are already bad [16:39:18] interesting, I have a NaN on the first timestep [16:39:23] CSM O2 Tank 1 [16:39:32] partial O2 pressure [16:39:43] it tries to divide by the air volume of the O2 [16:39:48] but it's all liquid, so... [17:25:30] morning! [17:30:32] hey [17:31:17] what's up? [17:32:00] tracking down the bug that causes the LM ECS to go all NaN [17:32:41] I could remember that we talked about FORCETRM last year, but I don't know what it was all about [17:33:17] http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=178.msg26106#msg26106 [17:35:48] that's what was causing your DPS alarm, because it was added between 116 and 120 and wasn't in the padload document [17:35:58] the solution at the time was to set it to -0, but based on comments I think it should be +200 [17:36:22] it'll delay activation of the GTS until 20 seconds into the DPS burn, or something like that [17:37:22] you mean the alarm during the COI? [17:37:28] 1412 or whatever it was [17:38:03] pretty sure this was in DPS-1 [17:38:34] ah, we got an alarm when it was +0 [17:38:37] yep [17:39:01] the code tries to count it down from some positive number to -0, so +0 is impossible [17:39:05] -0 skips that countdown [17:39:19] 200 for 20 seconds? That seems like an odd unit to use. [17:39:40] I've never seen deci seconds in the AGC, only centi seconds or seconds :D [17:39:46] haha [17:39:57] not 20 or 2000? [17:40:00] and what scaling? [17:40:33] it is entirely possibly that I'm wrong, but P-AXIS AUTOPILOT decrements it by one every time it runs, and the comments say that runs once every 100ms [17:40:52] allegedly [17:41:01] ah, that would cause the weird unit [17:41:21] and what exactly does this do? No GTS for the first 20 seconds? [17:42:22] something along those lines [17:42:38] "INDICATING THAT 20.0 SECONDS HAVE PASSED SINCE DPS ON AND CONTROL SHOULD BE TRANSFERRED TO GTS" [17:43:25] RCS is in control before that, looks like [17:43:29] ah, ok [17:43:52] let's see if I can find a source on that actually being used during the flight [17:52:27] from when is the final Sunburst version? [17:52:30] assembly date [17:55:00] one sec [17:55:39] initial release of a version number I don't know, Feb. 1967 [17:55:46] Sunburst 116, April 1967 [17:55:56] and Sunburst 120 in October [17:56:03] oh, October [17:56:37] one of the test runs was a DPS-1 with gimbal trim failure [17:56:44] failed at 16 seconds into DPS1 [17:57:51] and that resulted in the gimbal system being used for only 10% of the burn [17:58:15] how long is DPS-1? [17:59:16] 26 seconds at 10%, and then 12 seconds at 100% [17:59:28] hmm [17:59:58] and during a nominal run it said the gimbal trim system was used for 41% [18:00:50] I'm not sure if the GTS has a deadband [18:03:12] the mission report amendment for the DAP doesn't even talk about the GTS [18:03:23] I guess it was only used for 4 seconds anyway, if at all [18:03:47] right yeah [18:06:00] so then, not sure what number they launched with, but it was probably not -0 for "use exclusively the GTS" :D [18:06:57] oh, it doesn't exclusively use the GTS [18:07:06] the SPS does, with RCS for roll [18:07:13] right [18:07:26] but the RCS still fires in the LM, even if the GTS is active. The RCS has some kind of deadband [18:07:27] so then -0 just means "use the GTS the whole time" vs not using it [18:07:31] yep [18:07:34] gotcha [18:08:09] I don't think it will make much of a difference, so to our best knowledge they used 20 [18:08:12] seconds [18:08:17] yep [18:08:40] I'll do a test with a trim gimbal angle debug string [18:09:13] just +200 in octal I guess [18:10:29] 310 octal, 200 decimal [18:10:35] yeah [18:11:19] should be easily noticable in the debug string if that number is actually 20 seconds [18:11:35] it would be 6 seconds before throttle up [18:12:06] the whole point of the 26 seconds at 10% is to give the GTS time to find the CoG [18:12:19] so this must be an extra challenge for the GTS then [18:15:24] hahaha [18:23:47] in other news, I flew Apollo 5 from launch through APS-2 last night :D [18:25:18] for some reason APS-2 deorbited me [18:26:23] there was a pretty big attitude change after ignition that might be responsible -- for most of the burn it wasn't pointed along the local horizontal, like the other burns, but 20-30 degrees "up" [18:30:25] hmm, weird [18:30:41] I'll check the padload in the T-60s scenario [18:30:55] I thought I had given it all the right numbers [18:31:17] what was your orbit before APS-2? [18:31:31] hmm, I should have written it down [18:31:41] I'll try again tonight and upload a scenario [18:33:10] it wasn't that far off from the SCOT [18:33:15] ignition was about 20 seconds late [18:33:38] oh, that might be it [18:33:40] I thiiiink by that point it was still within 10km of SCOT apogee/perigee [18:33:51] I was running late for most of the mission [18:33:55] hmm [18:34:01] by SCOT times [18:34:17] do the mission timers in Sunburst already start running before liftoff? [18:34:30] good question [18:35:40] hmm [18:36:08] the routine the processes them "is entered once each second for most of the duration of the flight, once lift-off has occurred" [18:36:26] ah, so it shouldn't be an issue at T-60s [18:36:43] I changed it manually in that scenario [18:36:46] for APS-2 [18:43:28] wait, 20 seconds late? [18:43:49] approximately, yeah [18:44:08] I don't remember how late I was for the other burns [18:45:32] the padload change actually made MP13 2 minutes later [18:45:41] hmmmm [18:45:43] so, I don't think that is the issue [18:45:52] maybe I'm misremembering [18:45:55] the APS-2 targeting parameters are pretty sensitive [18:45:56] it was getting late [18:46:09] maybe something is not quite working out [18:46:28] or something threw off your state vector [18:46:53] I limited my time accelerations to 10x, because 20x seemed to be enough to start to go unstable [18:47:36] well, in P00 that wouldn't matter [18:47:44] right [18:49:30] I actually checked the Sunburst coasting integration earlier today, because I was curious how it worked. [18:49:46] would be about the same as any Earth orbital AGC version [18:55:09] whelp, looks like we are not getting the Apollo 11 and ASTP manuals after all [18:55:16] Lauren says they "aren’t able to be scanned because they are tightly bound book form." [19:16:13] are those the Delco manuals? [19:23:58] yep [19:24:31] there's some at Virginia Tech that Ryan can try to get at some point, but not 11 or ASTP [19:24:50] wouldn't they all have the same format? I wonder how the other ones were scanned [19:26:58] I think the ones that were scanned had their bindings destructively removed, and Lauren isn't willing to do that [19:27:25] oh, totally understandable [19:28:59] just wondering are the p23s required to the complete the mission? [19:30:19] no, they are not required. Before you do a maneuver the SV is uplinked [19:30:52] for the p52s most of the time the star is lined up right away [19:30:57] They would only be required in the case of lost coms with MCC [19:31:47] indy91, any luck with the nan's? [19:33:48] and for the mcc1 i get a 3.4 dvz is that good? [19:46:31] not yet [19:50:26] Mike distracted me [19:57:49] :D [19:57:53] haha [19:57:55] another thing I am good at! [19:58:14] a man of many talents [19:58:44] I might have found the source of the NaNs, but that is not where the issues begin [19:58:59] an energy state of -38606545750605.836 Joule is bad, right? :D [19:59:22] id say yeah lol [19:59:30] ah, no, the Pressure is already "-nan(ind)" [19:59:54] no wait, that was calculated just right now [20:00:12] it seems to start in the PRIMGLYCOLSUITHXCOOLING tank anyway [20:03:08] ill be out for a bit, cya! [09:39:38] hi [10:29:22] hi [10:30:37] so i'm not there yet but for mid course correction 2 which option should i use? [10:31:50] hey [10:31:53] same as MCC-1 [10:32:05] okay [10:32:06] just the different TIG [10:32:19] how much DV was MCC-1? [10:32:45] i got 10.1 [10:32:50] with the sps [10:32:57] is that alot? [10:33:06] not at all [10:33:09] that's pretty good [10:33:27] but for the residuals i got 3.0 if i recall correctly [10:34:19] on the EMS or the DSKY? [10:34:26] ems [10:35:15] interesting [10:36:01] and for the p40 sps thrusting i put in the verb 49 roll 181 pitch 281 yaw 005 and for the p40 it gave me a different attitude is that suppose to happen and i forgot to save it so i am doing it again [10:36:01] the DSKY showed close to 0 residuals? [10:36:18] how different was the attitude? [10:36:25] cant remember [10:36:52] it wasnt that big of a difference [10:37:12] is there a way to change the attitudes for the p40? [10:37:13] might be the trim gimbal angles [10:37:53] the P40 attitude is based on the DV vector you used in P30, not really a way to change it once you have entered P40, no [10:37:57] only in roll [10:38:37] would that affect the trajectory? [10:39:41] it could affect the trajectory, but your DV is pretty small anyway, so it won't be a large effect [10:40:17] you might have to burn MCC-2, usually that can be scrubbed if MCC-1 was precise [10:40:38] how could i tell if it was precise? [10:41:15] MCC-1 and MCC-2 use the same calculation method, so executing MCC-1 perfectly would result in close to 0 ft/s for the MCC-2 calculation [10:41:24] okay [10:41:59] the attitude difference could be due to the trim gimbal angles. Did you use the angles from the Maneuver PAD in V48? [10:42:27] you mean verb 49? [10:42:46] no, Verb 48, the DAP settings [10:43:04] yes i put in the angles [10:43:54] the order is important there, the V48 has to be done before P30. The Apollo astronauts got this wrong a few times during the actual missions, haha. [10:44:08] wow [10:44:14] i cant remember which one went first [10:44:32] it's not critical to get that right [10:44:44] but it would explain the slightly different attitude in P40 [10:45:02] could be off by about 2° in pitch and yaw then, but just the initial attitude [10:45:40] and the ha and hp were fairly close to the ones in the Maneuver pad [10:46:12] that is good. Although those numbers don't mean much in cislunar space [10:46:56] HA is offscale high anyway, +9999.9 shown on the DSKY [10:47:02] yeah [10:47:52] have you completed a full mission recently like with the new lem systems? [10:49:40] no, I haven't. I am trying to find a pretty bad LM ECS bug [10:50:37] the LM ECS is currently getting fine tuned, so we are developing our way through LM pressurization right now [10:50:54] but all the other LM systems should be in a good state for a full mission [10:51:00] CSM as well [10:51:00] and are any of the wip scenarios functional, i tried apollo 17 and during launch near earth orbit insertion the lvdc starts going badly off course [10:51:22] hmm, that could be some bug, those scenarios should actually work fine [10:51:30] I'll put that on my list :D [10:51:37] okay [10:52:24] and luck with that ctd during the lem ejection [10:52:30] any^ [10:52:58] no, haven't been able to reproduce it [10:53:06] I'll try again when the LM ECS is fixed [10:53:59] and after the lem systems are implemented what will be next? just curious [10:54:25] MCC support for Apollo 9-11 is a important one [10:55:02] Apollo 9 and 10 need some better LVDC parameters [10:55:06] will the sep and exctraction attitudes be the same for 11 [10:55:18] the Apollo 9 S-IVB has to do a TLI on its own [10:55:46] you mean, if those attitudes will change? [10:55:50] yeah [10:56:26] no, the Apollo 11 LVDC is fully configured already. So the attitudes will be the same. [10:57:22] and as for loi are the parameters pre loaded like for the mccs? [10:57:28] for the rtcc mfd [10:57:34] yep [10:57:43] not sure what you even need to input there [10:57:50] not TIG anyway [10:58:16] so the trans lunar coast should be easy then [10:58:57] yeah, you can probably skip 2 of the 4 planned MCCs, and those remaining MCCs will be short [10:59:11] the only difficulty with the LOI-1 targeting is using the right option [10:59:32] there is "LOI-1 (w/ MCC)" and "LOI-1 (w/o MCC)" [11:00:52] an MCC, e.g. MCC-4 changes your trajectory of course. So to be able to calculate the LOI-1 maneuver BEFORE having executed MCC-4, you need the "LOI-1 (w/ MCC)" option, to take the MCC into account. That is required for some calculations. [11:01:28] the final LOI-1 calculation just before doing the LOI-1 uses the option without taking a MCC into account [11:02:48] so i should figure it out before 70:00:00 [11:03:00] that is when it asks to copy the maneuver pad [11:03:58] the relevant thing for Apollo 8 is the uplink just before that [11:04:01] Apollo 11* [11:04:13] "Desired Orientation (Landing Site)" [11:04:37] that is a REFSMMAT uplink [11:05:04] and that calculation needs MCC-4 and LOI-1 calculated in the RTCC MFD [11:05:22] it's fairly tricky to get that all right, but I can help you with it once you get there [11:05:28] okay [11:05:34] have you uplinked the PTC REFSMMAT yet? [11:05:46] scheduled at 12h GET [11:05:54] so just after MCC-1 [11:05:58] not yet i forgot to save it i am at about 5 hours but last time i did [11:06:20] yeah, saving often is a really good thing to do [11:06:25] yes [11:07:05] in the checklist mfd it says preferred refsmmat so in the rtcc should i use desired refesmmat [11:07:49] never mind in the flight plan it says desired [11:08:12] ah, that is kind of the same thing, just different terminology [11:08:32] a preferred REFSMMAT is how P52 option 1 calls it. [11:08:49] and if i recall it was verb 21 to change the star code [11:08:55] yes [11:09:01] V21 is always "change the data in R1" [11:09:40] The desired REFSMMAT is stored in the AGC. When you uplink a REFSMMAT to the AGC then this is usually where it should go. [11:10:10] If you directly uplink something to the REFSMMAT memory address, then your AGC might loose its knowledge where the stars are etc. [11:10:49] so "Desired Orientation" in the flight plan always means that you should choose that option in the RTCC MFD [11:12:07] and for nassp is actually required [11:12:23] is the ptc required for nassp [11:13:03] cause when i go beyond 30x it gives me slower frame rates [11:13:09] during ptc [11:13:25] which isnt a big problem [11:14:23] it can be a bit of a problem, yes. Heat from the sun is simulated, so if you permanently point e.g. a SM RCS quad in the direction of the Sun, then after a few hours it will overheat, triggering a master alarm [11:15:00] regarding frame rate, I would suggest using the outside view, or at least not the CSM main panel during time acceleration [11:15:18] on the CSM main panel you will get the worst frame rate [11:15:38] outside view is usually much better, and smaller panels without so many interactive elements [11:16:13] When using my crappy netbook with NASSP I was usually using the LEB panel with the mission timer [11:16:29] so I could always see when to stop the time acceleration, because some flight plan event is coming up [11:16:55] do you have a physical copy of the flight plan [11:17:45] I don't, but some people like to print them out when flying a misison [11:17:47] mission* [11:18:09] I printed a bunch of checklists when I flew Apollo 8 proper, so not for development reasons, but just to fly the mission [11:18:20] yeah i bought two of them on amazon for $25.00 each [11:18:46] oh, I didn't know you could buy them [11:19:16] yeah but the price went up to 70 bucks [11:19:20] each [11:19:22] it's all available as PDFs online, so you can always print it yourself. But getting a nice copy might be more convenient [11:19:36] yeah its the reformatted version [11:20:18] I really like that version [11:20:32] it introduces a few typos unfortunately, but it's not so bad [11:21:21] and when do you think you will start making scenarios? [11:22:39] once the LM ECS is fully done. Some of the ECS parameters are saved in the scenarios, so we would have to edit them all manually, if we wanted to make changes later. [11:23:01] is it close to being finished? [11:23:21] it's buggy and needs tweaks, at least a few weeks. [11:25:25] so will v8 support only 9-11 [11:26:15] it will fully support those missions, minus EVA [11:26:24] but the later missions should be flyable [11:26:40] and if there are any bugs, like potentially in Apollo 17 right now, then they will be fixed [11:27:10] so if i wanted to fly apollo 17 could i use the original flight plan and be able to go to the moon and back to splashdown [11:27:12] V8 will just not have the lunar rover, the changes done the CSM and LM for Apollo 15-17, and that kind of stuff [11:27:45] Apollo 15-17 had extra O2 and H2 tanks for the Fuel Cells in the CSM [11:27:53] only with that they could fly the longer missions [11:28:07] so what will happen is that you run out of power when flying home on Apollo 15-17 [11:28:13] because we don't simulate those tanks yet [11:28:56] yeah i like 17 because of the night launch [11:33:11] nassp is worthy of praise [11:35:12] thanks [11:35:40] it's quite the old project, I've only been active in the last few years. So I am standing on the shoulders of giants! [11:36:11] yeah and i believe v7 was only released just last year? [11:36:48] yeah, February [11:37:14] NASSP had stagnated for a while, between 2010 and 2015 not much development was going on [11:37:51] a few tricky issues that kept the V7 release from happening [11:38:15] yeah i discovered nassp after the v7 release [11:38:23] oh, so fairly recently [11:38:28] yes [11:39:16] a lot of users knew about it years ago, because it has been in development for so long, and are coming back to check out if there was any progress [11:40:42] and for the lm/csm pressure equalization am i supposed to get the gauge below the hatch to reach zero? [11:42:38] yes, with the associated switch in the CM/LM DP setting [11:42:52] and the pressure equalization valve on the hatch itself in open [11:43:03] but right now this takes longer than it should [11:43:07] this will be tweaked [11:43:10] yeah [11:43:18] well i have to go now [11:43:31] ok, have fun with your next MCCs! [11:43:35] i will talk to you later if i have problems with loi [11:43:37] thanks [11:43:38] sure [11:43:48] bye [11:44:01] cya [11:44:12] and once again, praise project apollo nassp [13:43:41] Good morning, just read your post on the forum that sounds like a promising place to start investigating [13:44:37] The primary glycol loop could be doing the same since it is not powered during initialization, and the LCG pump as well just as sources of heat transfer [13:44:38] hey, yeah, energy state dropping to 0 seems bad [13:44:53] yeah [13:44:55] I have been thinking about that pump thing though [13:45:04] Is there any way to treat it like a pipe when off? [13:45:18] yes, I've experimented with that [13:45:51] it's still fluctuating a lot, but the masses in the secondary glycol loop are very nicely spread out [13:46:18] at the time when the energy state went to 0 the masses in the first two tanks were 2 and at the end over 2000 [13:46:34] now it seems like a nice pressure equalization [13:46:59] Energy going to zero is weird [13:47:35] Unless [13:47:48] Some of my heat exchangers are always on [13:48:08] it only happens at 10x [13:48:11] maybe it is dumping energy to "space" and not retaining heat long enough [13:48:16] could be [13:48:31] there are quite a few systems connected to the relevant tanks [13:48:37] HX, boiler, heat load etc. [13:49:10] Yeah [13:49:30] even with some changes to how our pumps work, the accumulation at the end of the loop also needs to be addressed [13:49:39] I'll look at the pressures [13:49:55] something must cause a flow, even if the tanks downstream already have a much higher mass [13:50:26] there wouldn't be any flow to a higher pressure, so it must be temperature or so [13:51:57] It should be accumulating in the accumulator [13:52:18] but of course other areas shouldnt be empty [13:53:01] yeah, it shouldn't accumulate there this much [13:53:32] the tanks with the 0 energy state are kept at a constant temperature before it happens [13:53:37] what is causing that? HX? [13:53:44] boiler [13:54:23] Which tanks specifically [13:54:46] SECGLYCOLLOOP1 [13:54:57] 277 K I think [13:55:51] There are heat loads attached to [13:56:21] which should be off though, no system is running [13:56:25] But I dont think any of those should generate heat until the LM is powered [13:56:56] no heat exchangers are attached to it [13:56:58] nor boilers [13:57:26] Oh I take that back [13:57:41] The ASA HX is on there [13:57:57] And that is providing heat [13:58:17] it's kept at around 277.35K [13:58:40] no, it's slowly going down [13:58:54] so maybe there is nothing directly controlling the temperature of this tank [14:01:21] Nothing that I can see [14:01:42] Just some heat from the ASA is put in [14:02:15] yeah [14:02:23] I'll compare the pressures between all the tanks [14:02:46] maybe what happens is that the first tanks are getting heat [14:02:52] raising its pressure [14:02:54] cause a flow [14:03:05] and the constant heat with the decreasing mass causes bad things [14:04:29] there are 6 connected tanks [14:04:30] Could be [14:04:41] Also the secondary loop has the pump into the accumulator [14:04:44] the first 5 are flucuating a lot, somewhere between 3-5 PSI [14:04:53] I believe the primary pumps from the accumulator if that makes a difference [14:04:56] and the last one looks more stable and is slowly increasing in pressure [14:05:01] pumping large into small vs small into large [14:05:19] accumulator has 10 PSI, nothing goes in anymore [14:05:27] just occasionally something in the tank before it [14:06:09] suddenly everything went crazy, now the last two tanks have the same pressure, 10.6 PSI [14:06:41] oh btw, I moved the systems timestep to clbkPreStep [14:06:53] things seem slightly more stable, but that wasn't the big issue [14:07:42] there are just some inherent instabilities to this glycol loop [14:08:12] when I use 10x things go crazy again and suddenly the pressure in the last two tanks is 34 PSI [14:09:14] I wonder if we have to artificially increase the volumes of the tanks [14:09:30] I did that for the primary loop to help stabilize pressure [14:09:50] or the valves or the pipe max flow [14:10:32] CSM secondary glycol loop uses 0.0003 as the valve size [14:10:37] LM is currently mostly at 0.01 [14:11:54] Hmm [14:12:11] Would smaller valves lend to stability? [14:12:55] probably, yeah [14:13:29] I'm experimenting a bit with it right now [14:14:45] so far it doesn't help much... [14:15:08] but when you limit the flow during one timestep then a longer timestep (10x) wouldn't hurt as much [14:15:10] I think... [14:15:13] Feel free to mess with anything you wish, I won't be able to play with it until tomorrow [14:15:40] yeah, just trying to find something that improves things [14:15:48] I think I enlarged some to get better pressure stability [14:15:50] and we can of course make the pump change [14:15:53] But this was all 1X testing [14:16:22] should that be an optional thing or be done for all pumps? [14:16:46] Realistically there was no restriction for flow through a pump [14:16:57] yeah [14:17:01] So I would think all pumps should use that [14:17:12] It might help issues with the suit fans as well [14:17:38] That sort of stops the suit circuit from properly pressurizing when the CSM pressurizes the LM [14:17:38] yes, there certainly should be some flow at least [14:17:48] there actually is a bypass for the secondary glycol pump [14:17:58] with a valve opening at a certain pressure differential [14:18:23] but that is probably just to stop some overpressurization form breaking the loop [14:18:26] from* [14:19:45] The primary loop has a similar bypass [14:19:55] Yeah thats what it is for [14:20:33] if I make the valves really small (0.00001), then there is a nice equalization [14:20:43] 1982g mass in the accumulator [14:20:51] around 520g in the other tanks [14:20:57] and very similar energy states [14:20:59] Hows the overall pressure [14:21:05] 3-5 PSI [14:21:08] Good [14:21:22] and there is no sudden overpressurization in the accumulator [14:21:24] Now what is the pressure when the pump is enabled [14:21:28] Using those sizes [14:21:36] I'll check, if I can [14:21:55] We also need to make sure that small doesnt inhibit heat transfer when a heat load is fully applied [14:22:04] yep, too small is also no good [14:27:12] how much should the pump raise the pressure? [14:27:50] Sec loop should read 23 PSI nominally [14:28:32] dP of 16 or so PSI [14:29:24] Primary loop normally reads 21 [14:29:35] And heat increase will of course increase that a little [15:07:43] I'll try to pop in later, let me know if you have any luck! [15:11:56] morning [15:12:29] Hey Alex [17:46:11] morning! [18:22:21] Hey Mike [18:24:08] what's up? [18:26:46] Nothing much. Will be preparing for an exam on monday in a bit. [20:38:10] good evening [20:48:54] hey [20:53:25] Ryan and I are deep in the plumbing of the LM and it takes a while to find our way out again. :D [20:53:34] hahaha oh boy [21:18:00] I am thinking about telemetry viewers [21:18:58] I want it to be easy to add new AGC programs or rearrange things, so I think I'm going to make it mostly configuration file driven [21:19:29] yeah, seems tricky to accomodate versions other than Colossus and Luminary [21:19:57] yeah [21:20:36] I'm also gonna steal the NASSP DSKY graphics and make it update a little DSKY correctly, since almost all of the downlists include DSPTAB and channel 11 [21:21:00] does Sunburst include the full DSKY? [21:21:04] yep [21:21:05] always seem like a waste [21:21:08] haha [21:22:00] oh, yesterday I pushed the commit for the LM abort sequence to the IU [21:22:01] yeah I guess the DSKY generally doesn't show too much during the Apollo 5 flight [21:22:12] ah nice [21:22:40] So, you need to use the PAMFD, go to the IU page, give it the name of the vessel (AS-204) and choose the LM Abort sequence as the option [21:23:20] and then, maybe 5-15 seconds later, on the Uplink page press the COI button [21:23:32] I tried it at 7400 m/s [21:24:33] same procedure for the suborbital abort program [21:24:45] awesome, I'll definitely have to try those [21:24:46] just not the COI button then, but the other one, whatever I called it [21:24:52] SAB or so [21:25:24] the IU uplink is enabled from the LVDC software side at TB3 + 10 seconds, so shortly after staging [21:25:54] trying the suborbital abort early also has the advantage that you can actually see it all happening from the outside [21:26:01] COI is in full darkness [21:26:41] I cranked up the ambient light in my orbiter a bit so I could see the FITH, heh [21:27:19] yeah, the suborbital abort also has a FITH [21:49:03] night [14:26:46] hey [14:27:31] so i just finished the first sleep period and i calculated the mcc2 and i get dvc 0001.7 [14:29:12] hey [14:29:17] 1.7 ft/s is great [14:31:01] might even be possible to not do that MCC and just burn MCC-3 next [14:31:13] yeah [14:31:22] 1.7 isnt that much [14:31:54] 1.7 ft/s would be a RCS burn in any case [14:32:03] not SPS [14:32:42] Good morning [14:32:44] so someone posted an apollo 10 scenario http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2854.210 (eleventh post down) and am i supposed to calculate the mcc and loi before the refsmmat uplink? [14:33:14] the scenario does work [14:33:15] its just to practice [14:33:38] hey Ryan [14:34:52] yeah, you have to calculate MCC-4, then LOI-1 then the REFSMMAT [14:35:03] because the REFSMMAT depends on the trajectory after LOI-1 [14:35:18] and that can only be accurately calculated if the RTCC MFD has knowledge of both MCC-4 and LOI-1 [14:35:24] and that would be desired refsmmat right? [14:35:47] yes, desired REFSMMAT uplink and the REFSMMAT type/calculation method should be "LS during TLC" [14:36:10] yes [14:36:25] I'm explaining it a little bit in this post [14:36:25] http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2854.msg26271#msg26271 [14:37:26] another case is if you execute MCC-3, but MCC-4 is small enough to not be necessary [14:37:52] then of course the RTCC MFD doesn't need to know about anything MCC-4 and the method only needs LOI-1 before calculating the REFSMMAT [14:40:59] rcflyinghokie, I've experimented a bit more with the secondary glycol loop, but the behavior is still not great. [14:41:14] Valve sizes not helping much? [14:41:24] I can't simply do the pump change, because then some things in the CSM become unstable [14:41:29] secondary glycol loop actually [14:41:33] but I have an idea why [14:41:43] valve sizes help a bit [14:42:12] the way it works in the CSM might actually be pretty good [14:42:24] fairly small valve sizes, just the pump valve size bigger [14:42:48] which isn't too unrealistic, the diameter of the glycol loop in the Systems Handbook is larger at the pump [14:43:50] in the CSM we also get the phenomenon that in the broken loop (pump off) the mass accumulates in the last few tanks [14:43:50] Yes it is [14:44:06] just not so much, due to smaller valves [14:44:31] Did you try the pump change already? [14:44:35] in terms of pressure the 5 tanks of the sec glycol loop in the CSM was about 5,10,40,40,40 PSI [14:45:09] the only thing that works much better in the CSM is when the pump is running [14:45:13] quite a bit more stable [14:45:40] yes I tried it, and some modifications to at least one valve will be necessary in the CSM, or else the sec glycol loop becomes unstable with the pump off [14:45:45] so similar to the LM issue [14:47:28] in any case time acceleration makes things worse, even in the CSM [14:48:06] Yeah seems to be Achilles heel with this [14:48:18] there has to be a way to improve that [14:48:41] making more numerically stable [14:51:09] It certainly would make things easier in the long run [14:51:29] there even is a noticable difference between 0.1x and1x [14:51:32] 1x [14:51:46] more stable at 0.1x [14:55:17] Hmm [14:56:37] Is more done per unit time? [14:57:03] well yeah, the flow is proportional to the timestep length [14:57:12] Ah [14:57:52] so if the timestep is giant then it would flow quite a bit, without taking into consideration that the next tank has increased in pressure and wouldn't allow that much flow [14:58:22] at least small valves seem to make it stable enough to not cause the 0 energy [14:58:26] What would be a solution for that? [14:58:42] Allowing more to be done per timestep? [14:59:05] it kind of already works that way, but it only would have an effect above 1000x or so [14:59:45] some tweak on the very basic level of the flow and tank calculations might help [15:00:37] the valve size tweaks alone might already prevent the NaN issue, so I'll focus on testing that [15:01:41] the big fix making things more stable probably would increase the CPU load, but it might not be so bad [15:02:19] Well at least on my system I have a good margin of CPU left [15:02:30] Even running time accel [15:02:46] that's good [15:02:57] Virtual AGC probably also becomes a factor at some time acceleration [15:03:16] so, one idea I have right now is an intermediate calculation of tank pressure [15:03:24] that is not done in the flow function [15:03:51] it doesn't have to be super detailed, but if one single tank has a lot of interaction, then recalculating the pressure during flow will help [15:03:54] This is in Hsystems? [15:03:57] yes [15:04:47] and for mcc1 it was dvc 11.6 and the residuals was 4.0 [15:05:33] EMS residual? [15:05:33] the residuals are weird, but the actual Apollo 11 mission didn't do MCC-1 and had about 20 ft/s for MCC-2. [15:05:50] yeah [15:06:09] i can probably just skip mcc2 like you said [15:06:10] Tailoff thrust error I believe [15:06:25] can't be, it's set to 0 [15:06:28] Oh [15:06:29] well [15:06:37] if the burn was under 6 seconds it's different [15:06:41] Ah yeah [15:06:45] and that small of a burn would be [15:06:53] right [15:06:57] are you talking about my mcc [15:06:59] YEs [15:07:00] yep [15:07:06] Sorry didnt mean to barge in haha [15:07:07] it was 4 seconds i believe [15:07:12] no problem [15:07:24] Yeah probably didnt need to be done [15:07:34] yeah, the short burn logic would be used for that. So the CMC will cut off the burn too early [15:07:52] Artemis (Apollo 15-17) actually has the short burn logic in the erasable memory [15:07:57] so there I have set it all to 0 [15:08:19] so on those missions you would never get an issue with tailoff thrust [15:08:43] Other than TLI :P [15:09:00] Unless it accounts for that as well [15:09:06] the LVDC accounts for it [15:09:11] and our S-IVB simulates it [15:09:23] and for the evasive maneuver it was 19.7 and residuals were 0.3 [15:09:37] yeah, 19.7 ft/s might be just over 6 seconds [15:09:45] and then the logic for the longer burns is used in the CMC [15:09:55] and for that the tailoff thrust is set to 0 [15:10:53] and will the co2 filter changes ever be simulated? [15:10:57] so, in the future, for those shorter burns you just have to null the residuals a bit with the RCS after the SPS burn is done [15:11:04] yes, I hope so. [15:11:23] yeah i null them [15:11:28] nulled* [15:11:42] good, that is probably why your MCC-2 is so small [15:12:42] and for the docking i see in the flight plan it talks about connected umbilical cords and docking latches would those be simulated in the future too? [15:12:51] connecting* [15:13:43] maybe, that seems a bit tricky to do with 2D panels [15:13:50] astronauthen96 the CO2 filter changes will be simulated eventually [15:14:31] in v8? [15:14:57] Probably not V8 in the CSM, but we have the foundation to do it in the LM [15:15:17] Just have other bugs to work out before we tackle that [15:16:10] so when i get to going in the lem at 56:20, should i expect bugs? [15:17:48] that should just be some communication checks. Not much of it is simulated. [15:17:58] yeah i think its mostly familiarization [15:18:03] yeah [15:18:08] not too many bugs in that, no [15:20:43] LM pressurization might cause issues though [15:20:58] Though I only got that NaN on time acceleration [15:23:31] I am going to try a LM Press right now without it to make sure [15:24:01] with the smaller valve sizes the sec glycol loop is at least not what is causing the NaNs [15:24:14] probably happens in the primary loop now first [15:24:25] oh, I wanted to ask another thing [15:24:37] I did the math and I got 10 lbs in the sec glycol loop [15:24:41] shouldn't it be 5? [15:25:59] and also, for docking at the lem/csm pressure equalization part the gauge just below the hatch doesnt seem to be going down at all? [15:26:26] is it always at 5? [15:26:31] Yes it should be 5 [15:26:33] or 4 [15:26:51] I increased the masses a bit when I was playing with stability [15:26:58] well, that is no good [15:27:07] Well it was just for pressure [15:27:20] the whole behavior is totally different if the mass in the loop is not right [15:27:22] So we can change the mass back, and change the pump pressure [15:27:29] I forgot I did that :( [15:27:38] Initially it was 25 and 5 lbs [15:27:49] I guess we haven't tweaked that loop too much anyway [15:28:48] If you want I can go ahead and fix the masses [15:28:58] probably makes things worse [15:29:03] in terms of stability [15:29:17] let me find ok valve sizes first [15:29:18] I think the volumes are what helped stability [15:29:24] and then we change the mass [15:29:28] The mass was simply to get the pressure correct [15:29:31] and then we do more tweaks [15:29:35] Ok [15:30:33] not too many variables at once [15:30:44] which was the biggest mistake we did with the LM ECS I think [15:31:12] Yeah very true [15:31:26] Hard to track down problems with so many simultaneous changes [15:32:07] and it is not happening now but in the middle of the night i got woken up by the master alarm and there was a fc3 light on the warning panel [15:33:18] during the sleep period [15:33:46] you have to check the FC3 gauges then [15:33:58] fc3 is a bit high [15:34:09] temperature? [15:34:21] flow? [15:34:44] flow [15:34:47] higher than 1 and two [15:35:30] are you still purging? [15:35:33] it says between 10 and 15 [15:35:40] no [15:35:46] i just did [15:35:49] Fuel Cell Purge switches all centered [15:35:53] yes [15:36:05] it was high before the purges [15:36:36] maybe something with your EPS configuration isn't quite right [15:36:36] and then that master warning came on in the middle of the rest period [15:36:39] FC3 doing all the work [15:36:59] try the DC indicators and check the FCs [15:37:01] FC3 I believe has Main B all to itself [15:37:30] Might have something on MNB that should be on MNA, or you left a heater on [15:37:46] not sure [15:37:59] im gonna do a p52 first then i will check [15:38:09] Check your H2 purge heater and sps line heaters, those are easy to leave on [15:38:09] i am not too familiar with the eps systems [15:38:39] the sps line heaters have been mostly off [15:38:55] As they should be [15:39:37] Suit compressor on AC A? [15:39:45] *AC 1 [15:39:56] AC bus 2 also runs off of main bus b [15:39:58] nope [15:40:31] what is the suit compressor on [15:40:54] suit compresser 2 on ac2 [15:41:05] Thats probably it [15:41:13] You only need 1 of the 2 compressors on [15:41:20] And it should be on AC 1 [15:41:27] its only compresser number 2 [15:41:31] okay [15:41:34] ill try that [15:41:43] That should reduce the FC3 load and prevent those warnings [15:41:53] fc3 flow just went down [15:42:05] Good [15:44:12] Yeah in a normal configuration FC3 powers Main Bus B [15:44:27] And Main B is inverted to provide AC for AC bus 2 [15:44:56] So that fuel cell does a lot of work, but most systems are kept on AC 1 and Main A to even out the other 2 cells [15:45:16] in the redundant component check during earth orbit it says to switch the suit compressors [15:45:22] Yes [15:45:34] So you turn off compressor 1 and turn on comressor 2 [15:45:39] compressor [15:45:51] are you suppose to switch it back after the check [15:46:03] Honestly I don't know haha [15:46:16] it doesnt say to do it [15:46:45] It is a redundancy check so I would ASSUME that you would switch back but you are correct the procedure doesn't specify [15:49:09] and i think indy said the suns temperature is simulated [15:49:20] Yes [15:49:40] so the ptc is really necessary then [15:49:57] yeah cause during time acceleration it gives me bad frame rates about 30x [15:50:48] not really a problem i just have to weight [15:50:54] Yeah PTC is necessary [15:51:05] just don't look at the CSM main panel when doing time acceleration [15:51:15] and i asked indy this have you flown a full apollo 11 mission before with the recent changes to the lem? [15:51:25] Not with the ECS changes [15:51:39] I am actually working on one now though [15:51:47] Playing with LM pressurization as we speak [15:52:19] yeah after the docking with the pressure equalization the gauge below the hatch doesnt seem to move [15:52:29] is it supposed to? [15:52:41] It will when you begin LM pressurization [15:52:55] However, the LM isnt "created" until you eject from the SIVB [15:53:07] yeah i forgot about that [15:53:13] So you have to cheat and wait to do LM PWR and LM PRESS until after ejection [15:53:32] But in 20 minutes my tunnel dP is 2.5 psi [15:53:40] i did the lm power but not the equalization [15:53:51] You will have to redo LM power [15:54:00] After ejection [15:54:17] yeah i did it after ejection [15:54:30] the lm power but no the equalization [15:55:37] Ok [15:55:54] It will work it just takes time [15:56:05] and dont use time accel for it right now [15:56:16] i wont [15:57:47] rcflyinghokie, it won't get better though when the LM is pressurized [15:58:40] I havent tried time accel with everything pressurized [16:03:53] interesting, there already is something in place to make the flow more stable [16:04:26] if the volume taken from a tank during flow greater than 50% of the whole mass in the tank, then the flow gets limitied to that 50% [16:04:37] so you can never completely empty a tank on one timestep [16:04:47] only ever 50% of the current mass [16:05:01] oh wait, I got that wrong [16:05:09] Where is that? [16:05:14] double ratio = vol / Volume; [16:05:20] if (ratio > .5) ratio = .5; [16:05:34] if it is greater than half of the total volume [16:05:38] h_volume::Break [16:05:53] break is the function that removes a volume from a tank [16:10:52] And thats for removing volume [16:11:53] Woo 40 minutes and my dP is at 2psi [16:12:44] how long should it take? [16:16:08] Haha I think 30 minutes total [16:17:20] according to the checklist the tunnel pressure rises fairly quickly [16:17:31] so it should go from 4 PSI to 2.4 PSI Delta P [16:18:05] that will just need the pressurize equalization valve size to be greater than the valve in the LM hatch [16:18:20] so that the tunnel fills faster than it can go into the LM cabin [16:18:50] Yeah [16:23:02] Interesting, the direct O2 goes into the suit circuit return valve [16:23:18] In our configuration [16:23:41] It looks like the suit connectors dont do anything [16:23:55] and the only reason direct O2 can increase cabin pressure is the suit circuit relief [16:24:00] Which is wrong [16:24:29] But we already know that system needs an overhaul later on [16:28:17] yeah [16:41:38] I think the repress package is too small as well I should be able to repress the CM a few times from 4.0 to 5.7 before it empties [16:42:04] But again, to be fixed later [16:45:35] hey [16:48:26] Hey there [16:48:43] hi [16:50:32] so about half an hour ago the command module completely shut down [16:51:01] As in no power to anything? [16:51:06] i have a scenario just before the end of the first rest period and i switch the suit compressors and it doesnt seem to have any problems so i dont know that happened [16:51:11] yeah [16:51:23] i was messing with the lem pressure equalization and then it happened [16:51:23] Can you post the scn? [16:52:09] yeah but its on my computer and im using my laptop right now so i will have to end my current scenario so just hold on and i will get it for you [16:52:17] and can you take a look at the pressure gauges too? [16:52:44] Just quicksave the current one :) [16:52:45] Sure [16:53:09] okay [16:53:48] https://thepasteb.in/p/wjh0Qvl0YlZsv [16:55:03] Its just the raw info from the file, I have to put it in VS and save it as a scn [16:55:24] okay [16:56:02] In the future if you can post the .scn file itself it would help :) [16:56:07] Instead of the code within [16:56:14] i am not sure how to do that [16:56:19] on dropbox? [16:56:59] Yes that works well [16:57:07] And looks like you had the NaN energy glitch [16:57:16] The one we are working to fix [16:57:34] There is no good way to remedy that other than reverting to an earlier time [16:57:41] yeah [16:57:53] it happened at around 25 hours [16:58:10] what do you think caused it? [16:58:31] Thats what indy91 and I have been trying to figure out [16:58:47] Time accelleration seems to be what makes it happen [16:58:50] general ECS simulation instability [16:59:42] does it usually happen at the same time period? [17:00:29] Soon after LM pressurization is what I have found [17:01:18] could it have been switching the suit compressor cause i just did that and so far no shutdown [17:02:24] Well you didnt lose power [17:02:32] At least in the scn I have [17:03:15] how do the pressure gauges look [17:03:54] Well they vanished [17:04:00] Part of the glitch [17:04:09] the gauge below that hatch i can see is pointing down [17:04:40] and when i lost power the gauges all came back [17:04:58] The needle will be at zero when in OFF, LM PRESS, and VENT [17:05:18] The only time the needle will register something is dP, and with the glitch the needle will appear to have vanished [17:05:38] And when you lost power all the needles read zero again [17:05:43] So they appear to come bac [17:05:44] back [17:06:26] Is the scn you sent me the configuration you were in when you lost power? Also, is your DSKY totally off in the lost power situation? [17:06:39] yes [17:06:49] I'll do some 50x tests with the new valve sizes, that should have fixed the sec glycol loop at least [17:06:54] not super stable, but not so bad [17:07:18] I will look at the other loops then [17:07:18] i am not losing power now but when i did the dysky was off [17:07:36] rcflyinghokie, the prim glycol loop valve sizes seem very... random [17:07:52] 0.01, 0.03, 0.1, 0.001 [17:08:13] They actually were adjusted one by one [17:08:39] To provide good flow of heat throughout as well as pressure at the accumulator [17:09:19] well, I am pretty sure that loop has the same issue, so the sizes can't stay as they are [17:09:30] Feel free to adjust as necessary [17:09:59] also, lots of PREG pipes there [17:10:42] We can probably eliminate some [17:11:44] what do they do? limit the flow above 30PSI differenceß [17:11:45] ? [17:11:51] Yeah [17:11:58] But that was also when the pump was set to 30psi [17:12:02] @rcflyinghokie i don't mean to interrupt but i told indy this yesterday and i just wanted to say that nassp is worthy of the highest praise possible [17:12:03] So they can be removed [17:12:40] Well its a work in progress! So hopefully higher praise in the future :P [17:12:56] morning! [17:13:02] There are some pressure regulation pipes in the glycol loop though [17:13:18] hey Mike [17:13:27] rcflyinghokie, those pipes are probably not the issue [17:13:29] I dont know the real limits though [17:13:52] I will prune it a bit regardless when you have some valve sizes [17:14:24] by what method were the valve sizes decided? It seems so trial and error [17:14:57] I'll look at the LCG pump next though [17:15:01] much simpler [17:15:20] I would focus on pressure and heat transfer between two tanks [17:16:04] Basically focusing on how much heat remained in the loops for heating and then the accumulator and indications in the cabin [17:16:09] I rather will focus on having no 0 or NaN energy states, haha [17:16:19] Haha yes please [17:16:32] and then it can be tweaked again for better heat transfer [17:16:37] Sure [17:17:51] so the simplified change for the sec glycol loop is the valve sizes that were 0.01 changed to 0.0002 [17:18:06] the CSM uses 0.0003, but that's slightly less stable [17:18:33] and just the valve responsible for the pump stays at 0.005 [17:19:13] it it holds up for an hour at 50x with pump on and off then it should be ok [17:19:39] if* [17:19:58] Then I can adjust the mass and subsequently the pump pressure to achieve the 23PSI [17:20:07] And we can repeat for the primary loop [17:21:37] the 23 PSI probably will still work [17:22:11] after all the relevant valve stays the same size [17:22:25] if I make the other valves any smaller then it doesn't quite get to 23 though [17:23:43] Well the mass change will change the pressure [17:24:00] oh, that one [17:24:02] yeah [17:24:08] I suppose I will leave the volumes of the tanks alone for stability [17:24:18] decrease the volume by the same amount? :D [17:24:43] I can try, that caused stability problems but maybe with the valve sizes I can get away with it [17:24:54] this is a silly question but if you have the time to answer will eating and drinking water ever be simulated? [17:24:56] smaller volumes caused issues? [17:24:58] Originally I computed the volume for the mass [17:25:07] And used that [17:25:14] Well the pressure wasnt stable [17:25:21] But I didnt touch valve sizes [17:25:22] astronauts are simulated. They consume O2 and produce CO2. That can be expanded. [17:25:38] But it wouldn't be an eating simulator, just urine production etc. [17:25:40] I will initialize it though with the new valve sizes to the proper mass/volume based on mass [17:25:48] yeah [17:25:48] ok [17:25:56] They also produce H2O [17:26:36] oh, right [17:27:10] so far no shutdown and its been over an hour after the suit compressor change [17:27:24] Yeah the suit compressor shouldnt have done anything to kill your power [17:27:39] maybe it was me messing with the lem pressure equalization [17:27:49] Possible but unlikely [17:28:01] who knows what all happen when half the systems have NaN [17:30:39] True [17:31:17] Though in the quicksave that was posted, the NaN thing has happened, but all power consumption looks normal [17:31:34] hmm [17:31:37] you mean mine? [17:32:09] Yes [17:32:20] haha, too many conversations at once :D [17:32:22] when did it happen [17:32:35] Right when i load [17:32:44] But your electrical looks good [17:32:53] did a 1 hour test at 50x, sec glycol loop is about the only thing that doesn't have NaN [17:32:57] so that's promising [17:33:02] at the every beginning? [17:35:10] astronauthen96 Yeah it happens within a few seconds of me loading that scn [17:35:42] indy91 great! [17:36:10] it accumulates in the last tanks in the loop, but the same thing happens in the CSM, so... [17:36:14] as long as it isn't bad [17:36:16] wonder why you guys are getting the shutdown but not me [17:38:19] indy91 we can deal with that for now if its off the accumulation doesnt really matter [17:38:26] yep [17:38:45] just has to be stable enough to not cause bad things at reasonable time acceleration [17:39:17] Oh can you check something for me? The suit fan switch is not off for LM closeout it seems, but the breaker is out, can you verify that when the LM is created, that the suit fan is not running? [17:39:35] More specifically, make sure the pump is indeed off [17:40:05] me? [17:40:22] No sorry haha, indy91 [17:40:27] its okay [17:40:32] I should have highlighted him when I typed that [17:40:36] yeah [17:40:43] will do [17:40:57] Same with all pumps actually, just in case [17:41:05] both glycol pumps and the lcg [17:41:08] I checked some [17:41:19] secondary glycol pump is certainly off [17:41:42] I checked all the wiring of the ones you mention, but I didn't actually look at a debug string [17:41:48] Also regarding the suit fan, having no flow through there when the pump is off might mess with LM pressurization as I mentioned yesterday [17:43:01] Since it is gas flow not liquid, it might need either some sort of bypass or a special pump to allow it to be a pipe when off [17:44:09] right [17:44:41] one loop at a time [17:45:49] Yes [17:46:19] Speaking of, I am at 2 hours LM is at 3.5 PSI, suit pressure in there is zero (the suit fan flow thing) and the glycol is a steady 20F [17:46:50] Which is good for an unpowered LM I believe [17:48:02] I'm sure my fixes will mess that up a bit [17:48:20] Probably not too much [17:48:27] I hope [17:48:32] The only heat going to the glycol is ASA I think [17:49:00] Is that heated during TLC? [17:49:18] Yes it is [17:49:51] Or supposed to be, along with the RR standby heater and landing radar heater [17:50:16] And IMU standby [17:50:38] But only ASA heat would go to the glycol [17:51:57] Oh sband is also heated during TLC I think [17:52:07] LCG loop seems fine [17:52:19] I gues it only gets the whole NaN from somewhere else [17:52:40] Its attached to the suits [17:52:43] but it doesn't happen on its own in the LCG [17:52:46] yeah [17:52:51] heat exchanger is always on [17:53:33] ah, I am already seeing trouble [17:53:34] PRIMGLYCOLPUMPMANIFOLD [17:53:40] 3 grams mass and 0 energy [17:54:50] That will be the first tank after the pump [17:54:57] So everything drains out of it [17:54:59] yeah, so nothing goes in it [17:55:22] valve sizes way too large, I think [17:56:26] Yeah I was adjusting those to get the right pressure [17:56:42] Again, go for shrinking them, we can compensate with the pump [17:57:29] the valve sizes just don't have to be too small [17:57:34] then the pump usually works fine [17:58:53] Side note, all the heater temperatures in the LM look good (LR RR and SBAND) 2 hours into TLC [17:59:25] So either the heaters are working or they are holding the initial temperatures haha [17:59:49] I havent checked if they are powered from the CSM properly or not [17:59:54] hmm, it's weird, I had to do some LM EPS config changes to get the sec glycol pump working [18:00:27] specifically, the X Lunar Bus Tie for the LMP Bus [18:00:53] isn't the S-Band heater on the LMP bus? [18:01:00] Yes [18:01:36] As is the sec glycol pump [18:02:51] yes [18:03:22] so how is the S-Band heater powered during TLC? [18:04:09] Well the breaker is in [18:04:26] but no power on the LMP Bus [18:04:28] So I assume it was tied to the xlunar bus somehow [18:04:48] maybe we have to fix something [18:04:57] writes in on the list [18:04:59] it* [18:05:21] Let me make sure it is indeed supposed to be powered [18:05:47] Do you have a LM closeout checklist handy? [18:06:06] Never mind I do [18:07:34] Breaker is indeed closed [18:08:59] oh, I knew that [18:09:08] just, the LMP bus has no power [18:09:17] not when the LM is created anyway [18:09:22] and not when connected to CSM power [18:09:31] I need to close the X lunar bus tie CB [18:09:38] the question is if that is correct [18:09:46] So why is the breaker closed? [18:12:51] prim glycol loop tanks indeed get awefully empty [18:16:15] I wonder if shrinking the volume of the tanks and adjusting the mass accordingly would reduce that flow [18:16:44] Basically making the total volume produce a little pressure at the accumulator with the pump off [18:17:03] I imagine that was the real case to prevent any air gaps/cavitation [18:19:46] And of course we dont simulate a true accumulator [18:20:45] how do they work? [18:22:25] Basically a tank with a piston attached to a spring to maintain positive pressure [18:22:43] https://en.wikipedia.org/wiki/Hydraulic_accumulator [18:22:50] That is pretty much what it is [18:23:14] we could simulate that, if it helps [18:24:00] Well they are used in both glycol loops as well as the LCG and also in the water separator tank I believe [18:24:06] So they arent uncommon [18:24:17] something strange just happened [18:24:45] made a bunch of adjustments, prim glycol loop doesn't pass the 1 hour at 50x test yet [18:24:54] Ah no not the water sep sorry [18:24:57] loaded the scenario tried to do the p52 and got program alarms and it couldnt load the star then tried the scenario again and now its working [18:25:32] which program alarm? [18:25:42] you can check with V05 N09 [18:25:46] not sure [18:26:09] too late now i have a new scenario running but just checked the p52 and it is working now [18:27:18] maybe you were in an attitude where it couldn't find a star [18:27:40] maybe [18:28:32] did you get the program alarm after pressing PRO and before it showed the first star ID? [18:28:40] yes [18:28:48] and for the star it as 00000 [18:29:49] probably didn't come up with any star then [18:30:04] you just have to change the attitude a bit [18:30:44] when i terminated ptc the pitch and yaw were off a bit from the original P 090 Y 000 [18:31:01] that is quite normal [18:31:27] for ptc if the pitch is 090 then should it be +09000 [18:31:31] it's tricky to get the pitch and yaw rates close to 0 when starting PTC [18:31:42] yes, 90° is +09000 [18:32:14] when the program alarm happened, did it show the number 405? [18:32:27] i think so [18:32:33] yeah, that is the alarm code [18:32:36] "NO PAIR" [18:32:48] so it couldn't find a pair of stars in the view of the sextant [18:33:18] and still no shutdown and by the way what does nan stand for [18:34:01] "Not a number" [18:34:12] Basically undefined [18:34:55] H2OSURGETANK 0.470000 1 1 0 0 0.01000000 0.01000000 0.01000000 0.00100000 [18:34:55] CHM 2 -nan(ind) 0.000000000000 -nan(ind) [18:34:56] [18:35:06] that is the only tank that has NaN as the mass [18:35:11] which is interesting [18:35:31] I believe the water flow also suffers from the time acceleration issues [18:35:57] would 30x affect anything? [18:37:13] Thats the one connected to the water separators [18:37:39] yes, right now even 10x is bad. We try to fix that [18:38:46] Odd that has no mass, its initialized to about half full, and its only output is the evaporators [18:38:52] Ohh [18:39:04] Its flowing to the prim and sec regulators [18:39:09] so its emptying to them [18:39:18] Maybe its completely emptying [18:39:59] which should work fine, but maybe there is a bug with something completely emptying [18:40:19] still, it shouldn't actually become completely empty, right? [18:41:12] I don't think so [18:43:06] Though I dont know if it started with anything in it at launch [18:43:45] Well it took 3 hours but I have the LM up to 4.5 psi [18:46:02] haha [18:46:07] and no NaN? [18:46:47] Nope [18:47:00] No time acceleration either [18:47:36] And other than going slow, the pressurization decal seems to work properly [18:48:08] But the only thing I am worried about is the suit in the LM has zero pressure, turning on the suit fan will fix that quickly I am sure but that could cause problems as well [18:48:17] But again, one loop at a time [18:52:39] yes, I would like to change the pump code accordingly, but first I will have to figure out all the side effects of that [18:54:08] Right [18:58:44] For Apollo 11, which option do I use for MCC1 and 2, option 2? [18:59:41] yes [19:05:09] are you flying that mission now? [19:06:28] and what about for mcc3 and 4? [19:06:59] option 1 [19:07:14] Yeah I am [19:07:21] Mostly to test the LM stuff [19:07:34] how far in are you? [19:07:41] 7 hours [19:08:19] im 2 minues away from 25 hours [19:08:28] h_substance::Condense and h_substance::Boil are weird... [19:08:43] and does it matter what time you calculate the mcc pad? [19:08:47] they subtract dt (time) from mass [19:09:04] astronauthen96, closer to the burn will be slightly more accurate [19:09:15] okay [19:09:16] usually for the MCCs the maneuvers were calculated an hour before [19:09:39] but you can do preliminary calculations, even if only to decide if the burn is necessary or not [19:09:47] that will be in 45 minutes [19:10:03] I doubt that will make even 0.1 ft/s difference [19:10:30] uhh that is weird [19:11:07] if (vapor_mass < dt) [19:11:07] dt = vapor_mass; [19:11:12] yeah, super weird [19:11:22] of course dt will be something like 0.16 [19:11:24] 0.016* [19:11:40] but still, those functions do weird things [19:11:41] Maybe it was an easy way to add or subtract small masses [19:11:46] maybe [19:11:54] boil is even more convoluted [19:13:55] The liquid to vapor math in this is weird all together though [19:14:08] And there is no difference between liquid and gaseous oxygen [19:14:18] Which can cause issues as well [19:14:27] The only difference is the boiling [19:14:36] The thermodynamic properties are the same [19:15:22] and how much dv or how little would determine weather a mcc is necessary or not? [19:16:25] Mission rules [19:21:55] I believe for 11 if the burn was less than 3 seconds on SPS it was scrubbed [19:22:56] indy91 probably knows them by heart [19:24:43] yeah for mcc1 it was an sps burn 4 seconds and the residuals were 4.0 [19:26:03] Then I am betting you wont need an MCC2 [19:26:15] maybe not [19:26:41] ill find out in 12 minutes when i calculate it [19:26:45] Calculate an option 2 for 26:45:00 [19:26:48] You can do it now [19:26:52] okay [19:27:00] Wont change much in 12 minutes [19:27:12] But you ca of course recalculate before you uplink anything [19:27:46] okay [19:27:54] dvc 1.7 [19:28:05] sps burn 0 seconds, rcs thrusting, 13 seconds [19:28:14] Yep scrub it [19:28:21] yeah [19:29:43] if the dvc is low i assume that means my trajectory is okay [19:30:05] Yes [19:30:16] You did the RTCC MFD option 2? [19:30:50] yes option 2 [19:31:11] and i think indy said option 1 for mcc3 and 4 [19:31:15] Yeah [19:31:32] It will use the node you have targeted [19:32:25] just crashed now im back at 24:30 [19:32:33] and i think you said that i could skip the p23's [19:33:05] yeah, those are just for practice anyway [19:33:37] Crashed? [19:33:40] yep [19:33:54] i was in the sextant and it froze for 2 seconds then crashed [19:34:03] ill have to remember to save every hour [19:37:00] Hmm weird [19:37:23] Yeah save often, and those saves can help us debug issues as well [19:38:14] #rcflyinghokie did you get ctd during lem ejection? [19:38:19] No [19:38:33] I think that bug was fixed [19:38:36] Or thought it was [19:38:54] I've done many LM ejections in the past day, for LM ECS testing, no CTD [19:38:58] Me too [19:39:00] i get it only sometimes [19:39:29] like maybe every 1 out of 5 [19:39:29] Took 3 and a half hours but LM cabin is pressurized :) [19:39:40] Oh I did way more than that a few days ago with no CTD [19:42:33] oh, and regarding mission rules [19:42:48] 5-57 Translunar MCC Execution Criteria [19:42:59] A. SPS MCC's should be greater than 3 sec. [19:43:11] B. MCC 2 and 4 are preferred execution points. [19:43:35] C. Considering the above, first midcourse will be delay until MCC 2 if cost is not prohibitive [19:43:48] D. is not so relevant [19:44:05] delayed* [19:45:59] well, i already did mcc1 and for mcc2 its 0 seconds on sps and 13 for rcs so i think im gonna just scrub it [19:47:30] yeah. The actual Apollo 11 mission only did MCC-2 (20 ft/s) and that burn was accurate enough to not need any other MCC [19:47:47] for that the LOI constraints also become relevant [19:47:51] with the sps of course im assuming [19:47:54] yep [19:48:08] that would be a long rcs firing [19:49:02] for sure [19:50:08] ooo, good news -- I've been a bit worried about what my yaAGC refactoring was going to do to its performance [19:50:11] but it's a bit faster [19:50:26] ~12 seconds to execute 100 million cycles, instead of ~13 [19:58:53] awesome [19:59:05] but what about pulse processing? [20:02:14] everything it was simulating before is now there, and in some cases more correct [20:02:37] I'm going to put up a preliminary pull request shortly, and then start in on some of the counters [20:02:56] the pulse processing is happening realistically now, and the cells are all there, just need the logic to request counts added in [20:03:00] I'm going to start with the RHC [20:04:16] it's already doing a bit more than it used to, actually [20:04:29] the voltage alarm and counter alarmas are in [20:04:40] *alarms [20:18:33] oh, I mostly meant for performance [20:19:02] once all devices are connected that have pulses to be processed, then the yaAGC performance would be a bit effected, no? [20:19:26] yeah, definitely [20:19:48] but being faster before adding all of that is a good starting place [20:19:52] right [20:22:01] oh, I was randomly looking for hints for LVDC source code and found some interesting entry on Linkedin [20:22:26] Undergraduate Research Fellow at Marshall [20:22:37] "AS-505 flight program simulations. Translation of flight equations into a high-level [20:22:38] computer language to determine the behavior of a flight." [20:23:28] we have no kind of AS-505 documentation regarding the LVDC that I know of [20:23:53] oooh interesting [20:24:14] you should reach out to him :D [20:24:20] so that might not be related to source code, but surely they have some more documentation interesting to us [20:24:24] yep [20:24:26] https://www.linkedin.com/in/manuel-martinez-4a1083b8 [20:25:40] probably going off of an EDD, I guess [20:26:12] I'd love a Saturn V EDD [20:26:31] haha me too [20:26:42] speaking of linkedin, I found Herb Thaler on it [20:26:54] he's not on the AGC mailing list so I'm going to try to get in touch with him [20:28:23] what did he work on? [20:28:52] he was in charge of AGC hardware design, from the Raytheon side [20:29:09] so there is a chance he will either have stuff useful for me, or know people who have things [20:29:33] by hardware I mean logic, not mechanical [20:30:18] right [20:32:31] I still reeeeaaaaaalllllly want to find Newspeak or Lamesh [20:33:55] I found something interesting [20:33:57] "MSC-07164, Saturn launch vehicle Systems Handbooks SL-1" [20:34:04] at UHCL [20:34:16] did we already know about this one? [20:34:27] hmmmmmm [20:34:31] might have some more EDS stuff [20:35:27] oh wait SL-1 was a Saturn V wasn't it [20:35:42] sure was [20:36:00] is that in the archive search instead of the history search? [20:36:02] I can't find it [20:36:03] "Skylab 2 (also SL-2 and SLM-1[4]) was the first manned mission to Skylab" [20:36:10] yes, archive search [20:36:16] nice, I never look there [20:36:24] you should definitely request that :D [20:36:29] they have a bunch of ASTP checklists that I still want [20:36:31] will do [20:37:25] I just noticed they have a couple of AGC program user's guides that we don't have any examples of [20:37:30] so I'm not sure how good they are [20:38:01] "Saturn launch vehicle Systems Handbook, AS-204 / LM-1 " [20:38:20] "Universal Saturn launch vehicle Systems Handbook AS-508 and Subsequent Vehicles " [20:38:26] holy cow [20:38:40] I need to use the archive index more [20:40:34] Just came back to my sim, dP is almost at zero and the LM is all happy and pressurized still [20:40:47] great [20:40:56] so we just need to stabilize it [20:41:44] Yep and of course increase the pressurization times [20:45:03] But no NaN [20:45:21] "Skylab operational Command Listing", I wonder what that would be [20:46:46] I havent a clue [20:48:45] sometimes i get ctd when i press calculate on the rtcc mfd [20:49:37] did Skylab have a computer (LVDC?...) left on on orbit that they could command from the ground? [20:49:56] Thats what my initial thought was [20:50:20] astronauthen96, yeah, unfortunately the RTCC MFD is not too good at preventing those kind of CTDs [20:50:25] Skylab did have a computer, developed by IBM [20:50:53] ill just try to use it as little as possible [20:51:17] usually you will get a CTD with some wrong inputs [20:51:57] I would wager that the operational commands were to control Skylab when not crewed or even when crewed from the ground [20:52:06] ahhhh hahaha, the ATMDC, awesome [20:54:16] "Apollo 14 - Emergency Power Down Rationale, CSM Contingency checklist, CSM Rescue Book, Orbital EVA Procedures, CSM Malfunction Procedures " [20:54:20] oh wow it was a 4pi computer similar to the GPC on the shuttle [20:54:39] "Apollo 15 - CSM Contingency checklist, CSM Malfunction Procedures, CSM Rescue Book " [20:55:27] Oh those sound good [20:55:45] yeah, we could use a CSM Contingency Checklist [20:55:52] and a rescue book for later missions [20:57:07] Anything on there about rescuing a LM from NaN? [20:57:22] somewhere in the ECS malfunction procedures [20:57:46] lol [20:58:24] "don't dock to a LM infected by NaN, it might be infectious" [21:00:00] ooooh [21:00:07] I understand the quarantine trailers now [21:00:34] NaN was fixed for later missions [21:02:28] Haha [21:03:32] Any more luck with the valves? [21:05:02] trying again right now [21:05:20] I still get NaN with 50x time acceleration for a few minutes [21:06:18] hey @thewonderidiot [21:07:02] i have told rcflyingrookie and indy this already but i just wanted you guys to know that nassp is worthy of the most amount of praise possible [21:07:51] or in the case of thewonderidition, the Virtual AGC. That's what he is mostly working on :D [21:07:55] thewonderidiot [21:07:59] can't even spell it [21:08:01] flyingrookie? how rude! [21:08:05] :P [21:08:12] whoops [21:08:16] I happen to have many hundreds of hours flying :P [21:08:28] yeah sorry [21:08:29] haha [21:08:30] Which in the grand scheme still makes me a rookie ;) [21:08:36] I am just teasing [21:09:10] a Hokie bird is my schools mascot [21:09:12] just don't call me Junior [21:09:21] We named the dog Indiana [21:09:33] hahahahaha [21:10:59] thanks astronauthen96, but these guys really deserve most of the credit. I feel the same way about NASSP, it's pretty incredible :D [21:11:18] are you a developer too [21:11:48] tangentially, I maintain the AGC emulator and I guess occasionally the AGS emulator if it acts up now too [21:12:09] I have yet to write any NASSP code directly, heh [21:12:12] the AGS acted up about once [21:12:19] The AGS fix was pretty huge though [21:12:20] and then never again [21:12:23] yeah it is a much more well behaved computer than the AGC [21:12:36] as far as emulators go heh [21:14:57] and @indy91 i saw your apollo 15 landing video and was wondering if the 15 scenario would fully work because remember i was having problems with the apollo 17 launch [21:15:32] It might have the same issue, I haven't been able to check yet [21:15:59] but otherwise, to my knowledge, you can fly it all the way to a lunar landing [21:16:00] i will try it when i get to the next sleep period with apollo 11 [21:16:44] and i believe there is no flight plan for it in the checklist mfd [21:16:53] Nope [21:17:06] Checklists have stopped at 11 for V8 [21:17:14] so i can get the flight plan on my laptop and use the mfd just for checklists [21:17:18] You can use the default checklist for it though [21:17:36] But you will need the flight plan as you mentioned [21:17:39] yes [21:18:32] There should be enough in there to supplement a 15 mission, however the current LM is not a J mission LM, so it doesnt have extended stay features [21:18:51] yeah [21:18:57] maybe ill do 14 [21:19:06] i dont think that was a j mission [21:19:18] And frankly, we haven't tested out current LM enough to see if it has enough for 11-14 haha [21:19:49] i will probably find out soon [21:20:08] Just remember that 14 didnt use a FR so it may be a little tricky to calculate burns for at first [21:20:23] really? [21:20:40] i thought all of them used it [21:20:54] nope, starting with Apollo 12 they used a hybrid trajectory [21:21:02] which is basically "close enough" to free return [21:22:15] interesting [21:22:33] I wouldn't suggest flying Apollo 14 right now, the calculation methods in the RTCC MFD don't work too well for it [21:23:04] yeah, so, Apollo 13 had to do multiple maneuvers after the explosions, the first one brought them back on a return trajectory [21:23:55] explosion* [21:24:11] well i have a scenario that someone posted for apollo 10 before the mcc before loi so i am practicing on that [21:25:10] do you know that option to use for mcc4 on apollo 10? [21:26:25] option 1 [21:26:27] 1 [21:26:31] what* [21:26:35] Its pretty much identical to 11 [21:26:46] It was a dress rehersal afterall [21:26:55] i think @indy said option 1 or 3 for mcc3 and 4 [21:26:57] Everything but PDI [21:27:18] okay [21:28:01] and i am scared to even touch the rtcc mfd but is the stuff pre loaded for option 1 like it is for 2? [21:29:13] uhh, probably? If the page doesn't show all 0s for option 1, then it is preloaded correctly [21:30:42] I think it is for 11 [21:30:45] yes [21:30:46] Preloaded I mean [21:30:47] it is [21:31:44] and i get no gimbal angles on the pad or sextant star angles [21:31:49] its for an rcs burn [21:32:04] the trim gimbal angles are just for the SPS [21:32:12] only the hybrid trajectory missions actually have numbers preloaded, so Apollo 12 and later [21:32:15] okay [21:32:32] and i scrubbed it anyway i just glanced at the pad and just noticed they were missing [21:32:41] how it works is that an option 2 calculation for MCC-1 and 2 stores some numbers for an option 1 calculation [21:33:00] and those numbers are saved in the MFD [21:33:11] so make sure you have the MFD open when you save a scenario [21:33:16] or else those numbers get lost [21:33:48] Yeah thats no fun, trust me [21:34:15] i cant remember if i had it open last time [21:34:26] but i just loaded the last scenario and the numbers are in there [21:35:31] sounds good then [21:36:42] if i were to get the numbers lost would there be a way to put them back in [21:37:09] i know in the flight plan it has landing site data [21:37:22] you can always manually input them on the page. Alternative, you can use numbers from the mission report [21:37:50] but it also might not hurt to do another option 2 calculation for MCC-3, or maybe even MCC-4 [21:38:03] yeah [21:38:05] you just might get slightly larger Delta Vs than you would with option 1 [21:40:42] and are you on here everyday? [21:41:10] most days [21:41:28] cause for the translunar coast i probably wont need much help [21:41:33] Hey indy91, are the LM ECS temp gauges wired to the ECS DISP breaker? [21:41:53] astronauthen96, coasting is Sir Isaac Newton's job [21:42:10] As in, they should display if only that breaker is in [21:42:34] yes, they are wired to it [21:43:03] I am just verifying that my cabin temp is so low [21:43:17] I am surprised it didnt warm up using the CSM to pressurize it [21:43:52] you sure you have power on the CB? [21:44:00] Yeah my cabin pressure gauge is up [21:44:27] astronauthen96: we're all in different timezones so it can occasionally be hard to line up. if you have a question and somebody isn't here, you can use Guenter to relay it [21:44:32] like this: [21:44:36] .tell indy91 how do I do the thing [21:45:03] Disclaimer: if you actually ask that question results may vary [21:45:43] it is a pretty open ended question, yeah [21:46:22] you do A, then you do B, then you do C and then you plant the flag [21:47:19] sounds easy :D [21:48:07] except you cant plant the flag cause theres no eva's for v8 [21:48:11] or is there [21:48:50] there is 10 year old code that is currently not really usable [21:49:54] the eva's for 15-17 would be interesting [21:50:00] Hmm so why on earth did the heat not come with the CSM cabin air [21:50:01] with the rover [21:50:14] I did see an LRV systems handbook in the archive search ;) [21:50:40] LRV is pretty interesting [21:50:47] actually nevermind, there already is one on the ALSJ [21:51:17] or at least parts of one [21:51:35] rover will be simulated at one point [21:51:39] again I should say [21:52:09] driving in orbiter will be interesting [21:52:48] there are some addons that do it [21:53:08] and FOR ONCE the touchdown point stuff of Orbiter 2016 will help and not hurt us [21:53:18] lol [21:54:17] What is the H2O quantity gauge wired to? [21:54:34] LMWaterQtyMeter.WireTo(&ECS_DISP_CB); [21:54:55] do you have the SCEA powered? [21:55:00] No [21:55:04] might want to try that [21:55:23] not sure how much ECS measurements are going through it right now though [21:55:26] let me check [21:55:31] Temp [21:55:36] h2o quantity [21:55:39] suit press [21:55:59] double LMCabinTempMeter::QueryValue() [21:55:59] { [21:56:00] if(!lem){ return 0; } [21:56:01] return lem->scera1.GetVoltage(21, 2)*20.0 + 20.0; [21:56:01] } [21:56:05] Thats what came on when I powered it up [21:56:25] so im at 27:00:00 and its asking for an earth horizon bias is that necessary and is there a way to find it in the rtcc mfd [21:56:47] So without the SCEA up, I only have cabin pressure and o2 quantity with the DISP breaker [21:56:51] the earth horizon bias is basically the altitude at which you see the horizon in P23 [21:57:13] different astronauts preferred different values for this actually [21:57:21] I think you can skip that item [21:57:33] yeah it says if required [21:57:49] and at 35 hours its asking for a lunar flyby pad [21:57:54] rcflyinghokie, some readings go through the SCEA, others aren't [21:58:08] Ok [21:58:15] Well good news is the LM isnt below 40 haha [21:58:24] oh, flyby is a fun one. That is also not really required, unless you want to return home to Earth right away. [21:58:42] nope [21:58:44] it's also a bit tricky to calculate [21:59:03] but basically, that maneuver is usually at the same time as MCC-4 would be [21:59:20] and it will be a course correction for a lunar flyby [21:59:58] is it like an abort [22:00:00] it can be calculated with the RTCC MFD, under Return To Earth somewhere [22:00:09] yeah, it's an abort maneuver. [22:00:46] and for the return to earth section is that where would would calculate abort pad's? [22:01:13] yep, mostly there [22:01:29] would they work [22:01:44] yeah, I have done a few with success [22:01:56] e.g. when the flight plan says "Update: Block Data" [22:02:02] those are abort PADs [22:02:13] of different type [22:02:22] early in the mission they would be direct return aborts [22:02:41] so not even going to the Moon, but a large Delta V "backwards" and flying home to Earth directly [22:02:59] yes [22:03:23] apollo 13 considered doing that but they didnt know how damaged the service module was [22:03:35] so they did the free return [22:03:48] indeed [22:03:59] those are calculated on the "Return to Earth (Earth-centered)" page [22:04:18] once you reach the SOI of the Moon, the preferred method is a flyby [22:04:27] "Return to Earth (Moon-centered)" page [22:04:27] yeah it would be faster [22:05:33] so those different types of maneuvers can all be calculated in that part of the MFD [22:06:58] the MCC for Apollo 8 already calculates a loooot of them [22:07:17] Apollo 11 got a short form abort PAD I think [22:08:07] P37 PAD. Only has a few numbers and let's you calculate the direct return abort maneuver with the AGC [22:10:11] lol, other things to clean up in yaAGC [22:10:39] the command line help says that only ropes containing all 36 banks are supported, and there is probably no use for any hypothetical ropes that contain less [22:10:51] uhh [22:11:04] Sunburst and earlier? [22:11:09] Or did those just have empty banks [22:11:17] no you're right [22:11:32] this was just written a long time ago when there was only Luminary 131 and Colossus 249 :) [22:11:40] haha, ok [22:12:32] Aurora was the first program we got with less, and if I recall correctly yaAGC had to be modified to accept it because it wasn't the expected size [22:15:00] what about ropes with more memory? :D [22:15:22] we need to get the ACM/ATM simulator working for that! [22:18:25] I might have just found the origin of the NaN [22:18:31] a negative energy state [22:18:41] ooo [22:18:59] in CDRSUITISOLVALVE [22:19:08] at the very least I will add some code that prevents this [22:26:19] I will investigate this further tomorrow, good night [22:26:24] night! [22:28:53] Hmmm back to those isol valves [22:29:00] They seem to cause too much trouble haha [22:32:31] If those are the origin I have a few ideas of how to make them unnecessary as tanks [22:32:43] So maybe we can actually have a stable ECS [22:35:06] On the bright side its been 12 hours with no time acceleration and the LM and CSM ECS are looking very good [22:35:10] astronauts don't *really* need suits :P [22:35:41] that's awesome! [22:36:05] Well see I will keep the suits, and change the need for a "tank" as the valve itself [22:36:16] Assuming Niklas' fix doesnt work [22:36:22] Or even both [22:36:36] Its a tiny tank that acts as the valve [22:40:10] huh [22:40:19] is that because panelsdk doesn't have just valves? [22:41:58] rcflyinghokie, I was curious, will you modify the checklists to have the press. equalization procedure happen after LM ejection? Or is the plan to keep it as the real timeline [22:42:30] Yes I absolutely plan to do that [22:42:46] It will be PR'd when we have the stability thing under control [22:43:07] right makes sense [22:44:42] Other than some valve adjustments to decrease the time it takes, the procedure works properly [22:44:57] Took me 3 hours haha [22:46:09] haha [22:46:27] how did you get it to go through without getting nan's? [22:47:20] Time acceleration instability causes them [22:48:32] ah right [22:48:48] Also we are going to fix pumps so they let substance through when off [22:48:51] Brave of you to wait 3 actual hours :p [22:49:01] Haha well I was off today and let it run [22:49:26] I found more mistakes with how the CSM O2 is plumbed as well [22:49:40] Which is why certain things dont work quite as advertised [22:50:03] But you would never notice unless you were messing with ECS in detail [22:50:52] But in general, using Direct O2 and cabin repress to get the cabin to 5.7, and then pressurizing the LM through the equalization valve, using repress when the cabin got to 4-4.5, works [22:56:10] yeah thats good to hear [22:56:24] anyway im off for the evening, cya [22:57:30] i was having some problems with the lem/csm pressure equalization [23:02:33] What issues were you having? [23:03:22] well, i was supposed to bring cabin pressure to around 4 i think [23:03:33] and i couldnt [23:03:48] You mean while the LM is filling? [23:04:23] right after docking [23:08:10] Oh the LM isnt created yet [23:08:15] So the pressure wont go anywhere [23:08:25] That checklist doesnt work properly until after ejection [23:08:55] I will be making that change to all LM mission checklists once we fix the stability bug [23:08:56] yes [23:09:01] i think you mentioned that [23:09:12] will that affect my mission i have [23:09:24] If you perform that checklist after ejection, it works just takes 3 hours instead of 30 minutes because well we need to adjust a lot in there [23:09:27] No [23:09:44] You can pressurize it now though if you want [23:09:47] remember that scenario i posted [23:09:50] Yes [23:09:57] Oh thats a NaN one isnt it [23:10:04] the gauges were missing [23:10:06] That will mess things up having the NaN values [23:10:09] yes [23:10:37] I could fix it if you like but it will do it again until we fix the bug [23:10:49] okay [23:11:54] I'd say keep flying it to the moon I think indy91 and I are close to a solution [23:12:10] okay [23:12:22] ri just reached 28 hours [23:12:38] will this affect going into the lem at 56 hours [23:17:49] Yeah it will [23:18:29] Just keep on trucking and we can fix your scn when we have a fix [23:18:40] okay [23:20:39] do you think you'll have it by tomorrow or is that too early [23:21:20] indy91 usually is on hours before me (time zone difference) so hopefully we will have something tomorrow [23:21:45] yeah [23:21:51] i am in canada by the way [23:24:14] so when you get the fix you will release it as a build right? [23:26:47] Yeah [23:27:32] would you still have to fix the scenario [23:28:32] Yeah [23:28:40] All those "NaN" states are saved in there [23:29:09] If you aren't planning to time accelerate I can fix your current state [23:29:10] how long would it take to do cause i have a few scenarios [23:29:26] Well I would copy a good ECS state into your scn file [23:29:33] as in my state right now [23:30:05] I think your state right now is bad [23:30:19] If you post your latest save I can take a look [23:30:26] yeah where should i put the scenario file [23:31:12] Can you put it on dropbox and put the link here? [23:31:23] sure [23:31:40] ill have to save the scenario and exit it [23:31:44] one second [23:32:02] Sure [23:40:44] aaaalright [23:40:48] Niklas is going to kill me [23:40:52] https://github.com/virtualagc/virtualagc/pull/1060 [23:41:46] Uh oh [23:42:20] Counters as in CDU? [23:44:15] well... none of the unique counter logic has been implemented yes [23:44:17] hey [23:44:22] but yeah, the CDUs and all 24 others [23:44:23] so could i post it on orbiter forum [23:52:58] Easiest way is to copy the file to dropbox and share the link here [23:57:55] .tell indy91 about those isol valves, we can change them from tanks to pipes if necessary I think, might mean adding your valves to other tanks but it can be done if they are still an issue [00:03:14] okay i have the link [00:04:01] https://www.dropbox.com/s/yxqlo82dyczhiu3/CURRENT.scn?dl=0 [00:05:54] does the link work [00:06:08] yep, it works [00:07:22] I am going to give you a pressurized LM, ok? [00:09:25] Hopefully it will help fix issues [00:09:26] https://www.dropbox.com/s/xyqlkdgt20eetjz/CURRENT.scn?dl=0 [00:11:18] okay [00:11:26] that was quick [00:11:42] Yeah I just copied a good LM ECS state from my Apollo 11 scenario into yours [00:12:32] so i have some scenarios before the lem is created, eventually when the fix build comes would those scenarios have to be edited as well [00:17:12] Before LM ejection there is no bug technically [00:17:20] Because it's the LM ECS that causes the problem [00:17:44] okay [00:17:55] do you have time for more [00:19:44] its just 5 [00:22:15] 4 actually [00:22:33] https://www.dropbox.com/s/lhxie7wxl0fhnvz/1st%20Sleep%20Period.scn?dl=0 [00:22:45] Sure [00:22:55] Just give me 1 and a time so I dont mix any up haha [00:22:55] https://www.dropbox.com/s/qgm5s32fi3ae18a/MCC2%20SCRUBBED.scn?dl=0 [00:23:04] okay [00:23:15] here is two [00:25:34] https://www.dropbox.com/s/ivm4gpuzmnawmlo/1st%20Sleep%20Period.scn?dl=0 [00:27:42] https://www.dropbox.com/s/b96dbs96c42yvjp/MCC2%20SCRUBBED.scn?dl=0 [00:27:46] Ok fire away [00:27:56] https://www.dropbox.com/s/p34166cj3iv7sst/Before%20End%20of%201st%20rest%20period.scn?dl=0 [00:30:15] https://www.dropbox.com/s/l4sohvloqttxwh0/Before%20End%20of%201st%20rest%20period.scn?dl=0 [00:30:42] just one more [00:30:49] https://www.dropbox.com/s/5v8d27cm37taykm/AFTEREVASIVEMNVR.scn?dl=0 [00:33:21] https://www.dropbox.com/s/e07mzsr0zjsm2rq/AFTEREVASIVEMNVR.scn?dl=0 [00:33:27] Those should work [00:33:42] thanks [00:34:42] they work [00:36:57] Great [00:37:51] just wondering if the pressure reads zero does it mean the lem is pressurized [00:38:03] the gauge below the hatch [00:39:04] Put it on lm/cm dP [00:39:08] Should be close to zero [00:39:14] it is on [00:39:23] its close to zero [00:39:27] And yes that means the tunnel is pressurized, and since the LM overhatch valve is open, the LM is pressurized as well [00:40:29] Gotta grab dinner, back in a bit [00:47:25] me too [00:47:36] its almost 5:00 here [10:33:25] hey [11:29:00] hey @thewonderidiot [12:05:03] hey @indy91 [12:05:12] hey [12:05:37] so i am flying that apollo 10 scenario and had problems with mcc4 [12:06:30] the p41 sps thrusting gave me a completely different attitude from the maneuver pad [12:06:56] for the p41 do you know what the trim should be? [12:07:07] or sorry the verb 48 [12:07:21] well first, P41 isn't SPS Thrusting [12:07:26] it's RCS [12:07:26] ah [12:07:29] yes [12:07:50] did you do anything with the REFSMMAT in that scenario? [12:07:58] uplink etc. [12:08:01] yes [12:08:11] it was ls during tlc and desired [12:08:18] followed by a P52 option 1 [12:08:22] yep [12:08:58] one thing that can happen with the RTCC MFD is that it doesn't know about the REFSMMAT currently in the AGC [12:09:07] i set the trims to zero with the verb 48 [12:09:17] the trim angles are irrelevant for P41 [12:09:23] I wouldn't change them for a P41 at all [12:09:31] because they might be useful for the next P40 [12:09:50] on the REFSMMAT page in the RTCC MFD is a downlink button [12:09:53] labeled DWN or so [12:09:59] yeah [12:10:13] that "downlinks" the REFSMMAT currently in the AGC to the MFD [12:10:33] and then the Maneuver PAD can use that to calculated the burn attitude [12:10:37] so i should do that before the uplink [12:11:05] hmm if you always had the RTCC MFD open and didn't reload with it closed or so then there shouldn't be a problem [12:11:25] because in that case the REFSMMAT was calculated by the RTCC MFD and then uplinked [12:11:35] which should make the REFSMMAT in the AGC and MFD identical [12:11:58] on the Maneuver PAD page it shows you the REFSMMAT type currently in the MFD [12:12:19] if that says "Launch", then the MFD reverted back to the REFSMMAT at launch and you need to downlink it from the AGC again [12:12:42] it was someone elses scenario but when i load the rtcc is open on the right side mfd [12:13:13] and then you do the calculations for the MCC-4 and LOI-1 burns and the LS REFSMMAT [12:13:44] followed by the P52 option 1 [12:13:54] and when you then calculate the Maneuver PAD after all that, then the attitude on the Maneuver PAD should be good. [12:13:58] if not something else is wrong [12:14:23] so do i press downlink and then calculate [12:14:46] no, if the REFSMMAT is calculated in the MFD anyway and uplinked after that, then there is no need to uplink [12:14:49] uhh [12:14:51] downlink I mean [12:15:28] uplink + P52 option 1 will make the REFSMMAT in the AGC identical to the one you calculated in the MFD [12:16:49] let's say you already did all the uplink, P52 etc. [12:17:00] and then you close Orbiter without the RTCC MFD open [12:17:23] then the MFD doesn't save data and you need to downlink the REFSMMAT [12:17:27] okay [12:17:39] so when i load the scenario and go to the refsmmat page is says ptc [12:18:23] yes, then the MFD knows about the REFSMMAT in the AGC at that point [12:18:26] a PTC REFSMMAT [12:18:46] but the MCC-4 burn will not use that REFSMMAT of course [12:19:31] so i just uplink the lls refesmmat then [12:20:14] yeah. calculate MCC-4, calculate LOI-1 and then the REFSMMAT [12:20:16] then uplink [12:20:19] then P52 option 1 [12:20:22] yes [12:20:41] once you have calculated the REFSMMAT you can already calculate the Maneuver PAD as well [12:20:57] and i am still not sure why the p41 gave me a different attitude [12:21:11] how much off was it? [12:21:23] if it was totally different then the issue was probably the REFSMMAT [12:21:29] yeah [12:21:31] a few degrees then it's something else [12:21:34] i will try it again [12:24:33] and i guess the tv attitude is irrelevant [12:25:30] yeah [13:05:30] so, i am at the burn attitude verb 50 noun 18 but the needles seem to be off [13:06:35] wait [13:07:55] there are different configs for the needles, as long as the attitude is now the same as on the Maneuver PAD it's all good [13:08:36] they are off by a bit [13:08:57] just checked the verb 16 noun 20 [13:09:19] the attitude is off by a few degrees [13:09:37] that's too much [13:10:18] what's the DV vector? [13:10:26] and did P30 have the same? [13:10:35] 00005 [13:10:51] i keep pressing pro and the attitude seems to be getting closer [13:10:53] wait, the burn is only 0.5 ft/s? [13:10:58] yes [13:11:35] maybe that is the issue, DV vector is too small :D [13:11:41] morning [13:11:43] hey Alex [13:11:54] but [13:11:55] I wouldn't burn a 0.5 ft/s maneuver [13:11:57] you can skip it [13:12:20] i checked the verb 82 PRO and my hp is 03049 [13:12:37] did you update your state vector? [13:12:40] yes [13:12:56] that HP might still be ok [13:12:56] is this MCC-4? [13:12:59] yes [13:13:03] yes [13:13:11] you are far away from the Moon and that is the instantenous HP [13:13:12] for apollo 10 [13:13:20] okay [13:13:21] not the one you will have when actually reacing the Moon [13:13:24] V82 will not give accurate readings that far [13:13:26] Sun and Earth are still pulling at oyu [13:13:31] on you* [13:13:32] the attitude is getting closer [13:14:01] this dap seems to be slow for me [13:14:21] so what it could be is that the DV vector calculated by the MFD is something like: 0.14, 0, 0.46 [13:14:29] just an example [13:14:31] astronauthen96, If you check the real transcripts, Jim Lovell actually complained about that same thing to mission control, he asked why V82 read like 300 NM when it should be 60 :D [13:14:36] but the computer only takes 0.1 ft/s increments [13:14:59] so 0.14, 0, 0.46 would be 0.1, 0, 0.5 in P30 [13:15:25] which might be something I have to fix in the MFD, it should calculate the attitude for these rounded DV values [13:15:53] the attitude is pretty much correct now [13:16:04] but that is an issue that will only happen with the small DV [13:17:08] AlexB_88, I fixed one bug on Hsystems in a not very elegant way and made a bunch of valves much smaller, I think that fixes most if not all of the NaN [13:17:12] in* [13:17:23] could use some testing [13:17:27] nice [13:17:30] the dv's were 00003, 00003, 00002 [13:17:38] just a bunch of coasting from the Pre LM ejection scenario I guess [13:18:15] yeah, ill backtrack my Apollo 11 run back to pre-ejection and carry on from there [13:18:23] the RTCC MFD might have calculated the actual DV vector as 0.34, 0.26, 0.16 [13:18:24] for example [13:18:40] and that not rounded DV vector would have an attitude that's a bit different [13:19:58] but 0.5 ft/s is not something that has to be burned anyway [13:20:04] not MCC-4 at least [13:20:33] yeah [13:20:40] that velocity is about the same as the accuracy of the ground tracking [13:20:42] so did you fix that NaN thing [13:20:46] I hope [13:21:05] unfortunately it will only be fixed in scenarios before LM ejection [13:21:07] well [13:21:17] half of the bug [13:21:38] so it might still happen once you update to the newest release [13:21:48] but the chance is 50% smaller, haha [13:22:34] rcflyinghokie fixed some of my scenarios last night [13:22:50] valve sizes? [13:22:51] he gave me a pressurized lem [13:22:53] oh [13:25:02] it might still happen in that scenario [13:25:26] it did when i did time acceleration [13:25:52] I can do more fixes to it, if you want [13:26:34] thats okay [13:26:45] which fixes [13:27:03] adjusting a few valve sizes [13:27:11] those are saved in the scenario [13:27:46] Good morning, any luck? [13:27:49] yes [13:28:07] I fixed the bug with the negative energy states [13:28:12] Valves? [13:28:23] that was one cause of the NaNs [13:28:43] somehow the energy state of the components of a volume wasn't in sync with the total energy [13:28:44] What else was it? [13:28:59] How did that happen? [13:29:11] that I don't know [13:29:24] so my fix probably doesn't address the actual problem [13:29:28] Haha [13:29:34] I guess we will see [13:29:36] Q should always be the sum of the components Qs [13:30:00] but when that wasn't the case and a part of the volume was removed during flow, Q could become negative [13:30:09] so I added a GetQ() in the Break function [13:30:14] that recalculates the total Q [13:30:35] Ah [13:30:41] with that I had about a 50% chance to survive 1 hour at 50x [13:30:52] the other fixes I did was indeed valve sizes [13:31:23] sometimes when a tank in the primary glycol loop got really empty the energy state suddenly started increasing beyond anything normal [13:31:40] it might be some floating point issue, the mass at that point was something like 2e-20 [13:31:49] Yeah sounds like it [13:31:57] but with really small valves the tanks don't empty that much anymore [13:32:04] which hopefully will prevent this from happening [13:32:28] I cant do it today but I will try to get the proper masses for the glycol loops in this week [13:32:32] oh, that issue with the negative Qs fixed the issue in the suit isol valves [13:32:45] change* [13:32:46] Oh I was going to ask about that, great [13:32:57] On the plus side my sim has been running all day and night with a pressurized LM (I went in and cheated and ran the suit fan for a bit) but without time acceleration it looks good at 25 hours GET [13:33:00] so the NaN didn't originate there anymore [13:33:21] there might still be another source of the NaN issue, but most possible sources should be fixed [13:33:38] glycol loops, LCG loop was never an issue [13:33:39] Would you be interested in looking into the pump code next? [13:33:51] ah, it might still happen in the water supply [13:34:05] although that could have been the same issue with the negative Qs [13:34:38] I already looked into the pump code and I am very interested in it, haha [13:34:45] the pump code isn't the issue [13:34:55] that is an easy change [13:35:15] but it caused some bad things in the CSM, possibly due to a valve size associated with the pump [13:35:21] I'll test that next [13:36:20] Basically you are just making it a pipe when not pumping , correct? [13:36:25] yes [13:36:44] the sec glycol loop in the CSM had all 0.0003 as valve sizes [13:36:50] but 0.1 for the pump :D [13:36:57] so that might be the issue [13:37:14] should be ok to make that a bit smaller without too much trouble [13:40:23] luckily there are only two pumps in the CSM [13:41:02] 0.01 valve size already seems ok [13:42:27] Arent the ATMREGEN technically pumps also? [13:45:03] Switching to my cell, back in a few [13:53:19] ATMREGEN has the same issue with not letting anything through when unpowered, but we only use it in the CSM, so, never touch a running system :D [13:53:42] Right [13:54:15] Just making sure they were indeed pumps [13:54:47] yep, they are [13:54:59] did another 2 hour test at 50x [13:55:02] looks all good [13:55:33] Where will the valve size be controlled on the pumps [13:55:36] of course my valve changes might not allow for proper operation of the glycol loops [13:55:45] I'm sure you will find that out soon enough [13:55:53] Haha yes i will [13:56:01] the IN valve of the pump [13:56:05] is the relevant one [13:56:51] Where is that controlled [13:57:07] In code or config [13:57:15] the valve size? [13:57:25] Yes [13:57:38] same as any other valve, defined in the config, but saved in the scenario as well [13:57:44] because we have some adjustable valves [13:59:03] Oh when you say IN you mean the OUT of the input tank? [13:59:30] Because i dont recall a valve size on the pump in the config [13:59:52] the pump is connected to two valves, just like a pipe [13:59:58] and yes, those valves belong to tanks [14:00:07] Ok got it [14:00:34] For some reason i thought the pump class had a default valve size [14:00:46] to make the CSM glycol loops more stable I am changing the size of two valves, the OUT valves of the connected tanks [14:01:07] nah, it just uses whatever it is connected to [14:01:41] Speaking of sizes and stability, do you forsee any similar issues with increasing valve size for lm press? [14:02:41] probably not, bigger tanks, rarely close to 0 mass [14:03:10] and also not so much going on with heat exchangers, boilers etc. [14:03:19] at least not the tunnel [14:03:59] Yeah i was concerned with the tunnel feeding a near zero mass of the lm cabin and all the devices indirectly connected to it [14:05:04] Right now the valve sizes actually deliver good proportions, the tunnel dP is very close to the actual csm lm dP [14:06:17] Just need to speed it up [14:07:44] so probably the valve size in both CSM and LM hatch a bit larger [14:08:02] that should keep the same dP but allow more flow [14:09:52] Yeah [14:11:30] So that and the glycol loop mass changes are next on my agenda [14:11:56] And moving the lm checklist items to after extraction for now [14:12:26] Ill try to do some of that tonight [14:12:39] I would like to not work on the ECS, haha [14:12:47] so many other things to do [14:13:03] Yeah i should be able to handle the tweaking [14:15:29] Assuming that works properly i can start the fine tuning process [14:16:13] I'll also commit the move of the LM timestep to PreStep now [14:16:22] that could cause some new issues, no idea [14:16:37] best case scenario is that it fixes the north trend of the LM during PDI [14:17:18] ok, updates all pushed [14:17:23] pumps allow flow through them now [14:17:27] when off [14:44:55] I hope I can make a bit of progress in my own development departments now :D [14:45:13] LVDC parameters for Apollo 9 and 10 would be useful [14:55:35] look at this [14:55:36] https://www.ebay.de/itm/NASA-Saturn-SA-513-SA-515-Skylab-1-Flight-Sequence-Program-Manual-July-1972-/232600341780 [14:55:54] I want that for every mission, haha [15:10:09] ill try the LM update this afternoon [15:10:36] you say the lateral error in PDI is fixed? [15:12:55] running the IMU in clbkPostStep might have caused it [15:13:01] at least there is a chance for that [15:13:08] I haven't actually tested it yet though [15:13:36] but the LM systems are now running mostly in PreStep [15:14:08] hmm [15:14:15] all of them probably [15:14:19] that might not be so good [15:14:26] let me check if I have to change a few [15:15:23] be back later [15:58:06] hey [15:58:38] i think that there MIGHT be something wrong with the trim on the maneuver pad [16:00:37] so i get the verb 49, entered the attitudes from the pad, and then for the p40 sps thrusting i get a completely different attitude, it was almost pointed the opposite direction [16:01:35] ok [16:01:58] is this LOI-1 or what? [16:02:03] loi 1 [16:02:14] apollo 10 [16:03:09] what attitude did the PAD have? [16:03:30] cant recall [16:03:35] but i am trying it again [16:03:42] i will have it in a second [16:04:17] and roughtly, what is the LOI-1 DV vector? [16:04:21] roughly* [16:05:34] i will have it soon [16:05:49] and i think the burn time was around 6:16 [16:05:59] sound about right [16:06:19] and the issue is not the trim gimbal angles. Those are the angles of the SPS gimbals to point through the combined CoG of the CSM+LM [16:06:34] the IMU angles, the attitude, is something different entirely [16:07:05] trim angles are set in V48. Attitude with V49 [16:07:07] okay [16:07:46] attitudes from the pad are R 266 P 341 Y 358 [16:08:14] PTRIM 000.65 YTRIM 000.29 [16:08:23] that attitude does not sound right [16:08:27] dvc 2980.8 [16:08:31] Roll, 355°; Pitch, 230°; Yaw, 342° [16:08:41] those are from the historical Apollo 10 LOI-1 Maneuver PAD [16:08:50] and while we will never get the same, it usually is fairly close [16:09:00] but not 110° off [16:09:04] so something is wrong [16:09:06] i calculate the pad at 69:15:00 [16:09:18] that is for the lls refesmmat [16:09:19] LOI-1 w/o MCC option [16:09:24] yes [16:09:47] maybe something went from with the REFSMMAT calculation. I'd like to look at the scenario [16:09:50] wrong* [16:10:10] should loi be fixed lpo [16:10:14] yep [16:10:33] what that means is a completely defined (fixed) orbital plane in lunar orbit [16:10:55] based on landing site, overflight time of the landing site and approach azimuth [16:11:07] the other option does not have the approach azimuth as a constraint [16:12:25] http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2854.210 [16:12:32] 11th post down [16:12:45] oh, it's just that scenario [16:12:51] yes [16:13:00] with MCC-4 scrubbed, so LOI-1 is next, I understand [16:13:31] so let's see what I will get... [16:13:39] okay [16:15:05] oh, I have an idea [16:15:26] so, the "LS during TLC" is only used when two maneuvers have to be taken into account [16:15:30] option* [16:15:37] which would be MCC-4 and LOI-1 [16:15:50] but you don't do a MCC-4, so only LOI-1 has to be taken into account [16:15:56] so another option is used then [16:16:01] Landing Site [16:16:17] but, on the bottom left choose the MCC option instead of direct [16:16:30] and that will display the LOI-1 parameters [16:16:44] I admit, this isn't solved all that well in the MFD [16:17:00] but that's the procedure for taking ONE maneuver into account [16:17:32] and when I calculate that I get much better IMU angles on the Maneuver PAD [16:18:42] so in that scenario I calculated "LOI w/o MCC", then on the REFSMMAT page the options Landing Site, Desired REFSMMAT, MCC [16:19:03] MCC meaning in this case any kind of course correction [16:19:10] could be named something better [16:19:49] ah [16:20:04] and then you can uplink the REFSMMAT and calculate the Maneuver PAD [16:20:11] i will try that [16:20:46] I am getting the attitude: 356°, 231°, 341° then [16:21:03] which is pretty close to the historical attitude [16:21:08] within 1°, haha [16:22:18] i got the same thing [16:22:33] it worked [16:22:50] i will try the loi and see how it works [16:24:26] yeah its off by just one degree [16:24:31] which is great [16:26:00] yeah, the RTCC MFD is a quite powerful tool that I am very proud of. But very user friendly it is not :D [16:26:26] did you develop it? [16:27:18] yeah, the RTCC MFD is all mine [16:27:29] very nice work [16:27:33] I've done a bunch of development for NASSP, but the RTCC MFD is the only one that is 99% mine [16:32:59] apparently the dsky can calculate attitudes for sightings [16:33:00] for the p52 [16:34:13] well i have to go and will be back in an hour so i will talk to you later [16:34:22] and praise the rtcc mfd [17:31:00] morning! [17:40:15] hey Mike [17:40:25] https://www.ebay.de/itm/NASA-Saturn-SA-513-SA-515-Skylab-1-Flight-Sequence-Program-Manual-July-1972-/232600341780 [17:40:38] read the text associated with it [17:40:50] hehe, yeah I've seen that, and have considered buying it [17:41:30] this is the second one that has gone up for sale on ebay, as far as google remembers [17:42:17] I didn't know it was still up for auction, I think the price has gone down a bit [17:42:19] maybe I should just get it [17:43:20] well, I would love to have it, haha [17:44:07] the text sounds like the seller has more of this kind of stuff [17:44:27] yeah, I was just looking through his store [17:46:22] other interesting things, but nothing else worth the price [17:47:08] there is one of these for AS-206 in the Smithsonian Bellcomm collection [17:49:48] alright, you've convinced me [17:49:52] thank you for making me spend money [17:49:53] lol [17:49:58] AS-206 the LM test flight [17:50:00] it should be here this week [17:50:05] you are very welcome [17:50:25] it said it would cost 30€ shipping it to Germany, so... :D [17:50:38] haha, only $7 here [17:50:53] see, that means all in all we are saving money [17:50:57] that's how it works, right? [17:51:03] yeeeaaaah, totally [17:51:22] oh I hadn't even properly looked at the title of it [17:51:28] "SA-515 Skylab Backup" [17:51:36] well, probably would be the same sequence [17:51:43] yeah definitely [17:52:01] there might be more clues as to actual program names in here too [17:52:02] the photos on the page already were quite interesting [17:52:17] I really wonder what the Skylab LVDC version was based on [17:52:26] it has TB4 as the orbital timebase, so [17:52:43] did they use the Saturn IB or Saturn V version? [17:52:48] I really don't know [17:52:48] I haven't even read enough about skylab to know how that worked [17:52:54] did the S-II do the orbit insertion? [17:52:57] yep [17:52:57] or did it insert itself? [17:52:59] weird [17:53:09] it was light enough for that [17:53:29] so, in terms of IGM, it's basically the same as a Saturn IB [17:53:36] just with a S-II instead of a S-IVB [17:53:44] both have a MRS somewhere in there [17:54:07] modifying the Saturn V IGM might have been more work than changing some numbers in the Saturn IB LVDC [17:54:18] haha [17:54:27] yeah I could see that [17:56:24] so in other news, I finished the initial framework stuff for yaAGC and almost finished implementing the RHC counters this morning [17:56:54] what I probably will do is create a development branch and simply copy&paste the new agc_engine files [17:57:00] and fix everything from there [17:57:15] yep, I fully intend for us to have identical agc_engine files after this [17:57:23] this is a very good time to resolve all differences [17:57:33] indeed [17:59:28] SL-1 Flight Evaluation Report confirms, the LVDC was a modified Saturn V version [17:59:36] with a few additional features [17:59:36] hey [17:59:37] very interesting [17:59:42] morning! [18:00:02] welcome back [18:01:57] time for loi in 5 hours [18:02:04] different tower clearance maneuver, some yaw steering during first stage boost, S-II CECO at a specific velocity instead of time and S-II OECO at inertial velocity instead of depletion [18:02:10] less then that with time acceleration of course [18:02:43] oh and a navigation scheme using pre-set accelerations in lieu of y and z accelerometer outputs until approx 10 seconds" [18:02:48] which I find veeeery interesting [18:03:03] most of our IU state vector errors come from liftoff [18:04:25] it talks about 3 IGM phases... [18:04:48] which can only mean that after CECO it used another IGM phase [18:04:57] so instead of S-IVB flight it used S-II on 4 engines [18:05:04] so not a tricky change at all [18:05:32] at least on the IGM side [18:06:30] one change I want to make to our LVDC are configurable programmed events [18:06:35] pre-set accelerations? that's madness [18:06:38] so those events listed in the document you just bought [18:07:13] in two axis. I guess the measured acceleration should be close to 0 anyway and would just include errors by using the accelerometers [18:07:39] better hope those accelerometers don't end up measuring anything meaningful :P [18:07:49] pre set would be mostly the small yaw maneuver [18:13:45] so, if I have the flight sequence program configurable I can have one for every mission [18:14:14] without me having to do special code for some missions [18:14:30] that would be awesome [18:15:28] the flight evaluation report lists most of those events, so I have good data for most missions [18:16:19] the difference I could implement then are e.g. the S-IVB lunar impact maneuvers, J-Mission differences etc. [18:17:16] of course there were coding changes from mission to mission as well, but not significant enough that I can't handle it in code [18:20:09] Skylab would be such a case. That's where your document helps :D [18:20:52] yeah, yeah [18:21:01] and that document also seems to have a complete list of discrete inputs [18:21:06] which I don't have yet for the Saturn V [18:21:09] LVDC [18:21:27] oh really? did the IB list come from the EDD or something? [18:21:38] yeah, the EDD has that [18:21:41] gotcha [18:21:45] we knew all the interrupts [18:21:48] but not the discrete inputs [18:21:58] we really need to find a saturn V EDD [18:22:08] oh yes [18:23:57] relying on a fairly incomplete 1967 document for that is less than ideal [18:24:06] yeah [18:24:28] I really wonder if the Georgia NARA has EDDs or anything like that [18:24:39] that place is such a big unknown, without any public indexes or anything [18:25:06] https://www.archives.gov/files/atlanta/finding-aids/nasa.pdf [18:26:19] can't really tell from that exactly what they have, though [18:26:45] yeah [18:27:09] there's some potentially promising groups there [18:28:00] "Saturn Interface Control Documents, 1971-1972" [18:29:33] the launch vehicle operations office group is probably pretty good too [18:29:43] but we really need somebody to go there at some point to find out [18:38:26] astronauthen96, so are you continuing to fly Apollo 10 instead of 11? [18:38:39] because, Apollo 10 does not have the right software for a lunar landing [18:39:06] oh can 69 just straight up land? [18:39:15] I knew it was buggy, but didn't know it was that bad [18:40:21] hmm [18:40:23] it kind of works [18:40:34] problem is, LR readings don't work [18:40:39] probably a padload issue [18:40:43] because they did test the LR [18:40:58] the abort programs are super buggy [18:41:11] and I remember some issues with P65 or P66 as well [18:41:37] P63 and P64 worked well [18:42:12] @both [18:42:37] i am kind of using apollo 10 as a practice with calculating loi with the rtcc mfd [18:43:53] what does the LR do? does it just get garbage data or something like that? [18:50:33] it was garbage data, yes [18:51:10] you perform a DOI maneuver just like Apollo 11 would and at perilune (50,000 feet) you test the LR [18:51:16] lock on worked [18:51:23] but the data was nonsense [18:51:27] yeah [18:51:46] I bet it's a padload issue [18:52:01] I'll have to look into that at some point [18:52:28] otherwise Luminary 69 should be working quite well [18:52:48] there was this one other interesting thing about it [18:52:50] rcflyinghokie knows [18:52:57] something with the P63 test [18:53:19] you need to repair a flag after the test or else Average G is broken for the following maneuvers [18:53:26] but that is just a procedural thing [18:53:50] the document we have for Apollo 10 is outdated in that regard and had the wrong procedure [18:54:27] Oh yeah i remember that all too well [18:54:32] hehe [18:55:05] interesting that procedures are wrong, Luminary 69 was the only version released for 10 (other than, of course, 69 rev 2) [18:55:28] released in november 1968 [18:55:54] the document is from later than that, but based on an older LGC revision [18:56:09] weird [18:56:13] we could actually track down when the changes were done, not too long before revision 69 [18:57:09] "LM Descent/Phasing Summary Document - Mission F - Preliminary", January 1969 [18:58:18] and that still isn't based on the November 1968 Luminary 69 [18:58:28] weird [18:58:40] seems like they would have had a copy by then [18:59:18] ah [18:59:29] first reference is to a GSOP from March [18:59:56] heh, reference 5 is to the manual for Flight Program 2 [19:01:06] AGS FP2? That's not even a flown one, right? [19:01:27] I don't thiiink so, but I'm not positive [19:03:27] whatever GSOP they were referencing, we don't have [19:03:55] however our Sundance GSOPs are all from after March, so whatever it was, it was definitely old [19:04:37] lol yeah it's definitely an old Sundance GSOP [19:04:49] Luminary wasn't born until April [19:05:16] Sundance was in the 60s at the time [19:13:52] afternoon [19:13:58] hey [19:17:29] hey Alex [19:20:29] so [19:20:54] for the loi the p40 altitude is off on the pitch and yaw [19:21:25] i think the pitch was about 34 something [19:21:59] if i gave you a scenario would you be able to take a look at it [19:22:24] altitude or attitude? [19:22:33] attitude [19:23:13] sure, I can look at the scenario [19:23:38] so what is off is the 50 18 in P40? [19:23:53] yes [19:23:58] the roll was about the same [19:24:56] how much off are pitch and yaw? [19:25:57] pitch was 03400 [19:26:12] cant remember the yaw [19:27:19] shouldn't it be like 230°ß [19:27:20] ß [19:27:23] damn [19:27:24] ? [19:27:38] yeah [19:28:05] and you uplinked the REFSMMAT followed by the P52 option 1? [19:30:30] ohhh [19:30:33] there is one thing [19:31:29] if you are doing multiple uplinks at once (REFSMMAT, state vector, targeting load) [19:31:40] then the REFSMMAT has to be last [19:31:57] that has to do with the computer memory, the uplinked desired REFSMMAT is stored in temporary memory [19:32:02] first i uploaded the state vector, then uploaded the refsmmat and then the p52 option 1 [19:32:30] SV uplink or targeting load for P30 would overwrite the desired REFSMMAT [19:32:42] easy to get wrong, you just have to know that [19:32:54] what is the targeting load? [19:32:55] I certainly didn't for quite a long time [19:33:00] the uplink for P30 [19:33:11] so the maneuver data [19:33:17] in your case the LOI-1 [19:33:18] where would i find that [19:33:35] on the page where you calculate that maneuver is an uplink button [19:33:48] ahh [19:33:51] but manually typing in the numbers in P30 accomplishes the same [19:33:58] just not so convenient [19:34:09] give you give me the order of the things to do [19:34:23] state vector and targeting load first, order doesn't matter [19:34:26] then REFSMMAT [19:34:29] then P52 option 1 [19:34:36] that is what i did [19:34:45] then it could be some other issue [19:35:07] I can look at your scenario [19:35:31] okay [20:13:03] astronauthen96, if you want me to look at your scenario, then you need to upload it somewhere :) [20:14:29] the p52 doesnt seem to be giving me good attitudes [20:15:03] i will try to make it 15 minutes before loi is that fine [20:15:19] that will be good [20:15:25] so it might be some alignment problem [20:15:31] I'll check that first then [20:21:17] it might take half an hour [20:21:27] how long will you be on here for? [20:21:46] maybe an hour [20:40:23] i think i will focus on 11 for now [20:50:38] wow, the new document is already shipped [20:50:40] that was fast [20:52:28] did the owner quiz you like he said in the description? [20:52:38] that whole "I only sell to somebody who knows what this is" thing [20:52:39] nope [20:52:43] lol [23:36:21] hey [23:37:08] can you show me how to do that Guenter thing [23:39:31] never mind its okay [23:45:43] Sorry i was upstairs [23:45:53] Which Guenter thing did you want to know how to do? [23:46:44] Back in a sec need to reboot [23:48:38] the tell indy thing [23:48:42] Oh haha [23:49:09] .tell "username" what you want to tell [23:49:29] tell @indy91 the problem with the apollo 10 scenario was probably a bad alignment i did mcc4 which wasnt really necessary and the p41 rcs thrusting gave me the right attitude [23:49:43] you dont need anything with the username [23:49:48] no @ or # [23:49:56] tell indy91 the problem with the apollo 10 scenario was probably a bad alignment i did mcc4 which wasnt really necessary and the p41 rcs thrusting gave me the right attitude [23:50:00] That should work [23:50:08] Oh you need a . before tell [23:50:12] .tell [23:50:28] .tell indy91 the problem with the apollo 10 scenario was probably a bad alignment i did mcc4 which wasnt really necessary and the p41 rcs thrusting gave me the right attitude [23:50:32] There [23:51:14] at first i thought guenter was a real person [23:54:42] Haha nope just a bot [23:58:00] unless guenter wendt was on here [00:08:15] I wonder where guenter wendt [00:22:09] .tell Thymo you're going to want to manually delete that message for "username", it has invalid nick characters in it so we can't get rid of it the normal way :P [00:27:10] Did I break something else? [00:28:24] :P [00:31:07] .tell Thymo in regards to thewonderidoit's message to you, that was my fault [00:35:02] I have been summoned. [00:35:16] Haha yes [00:35:30] RIP. I'll fix it one sec. [00:35:35] Sorry! [00:35:36] Meeting ended by Thymo, total meeting length 790666 seconds [00:35:37] .endlogging