[00:38:54] NASSP Logging has been started by thymo [00:39:32] hm, when did that happen [00:39:48] oh just now [00:39:50] nevermind [00:39:58] Had to troubleshoot some network issue that required a router reboot. [00:41:00] @Thymo are you a developer too? [00:41:57] I suppose so. I don't think I'm officially listed as one anywhere though. :P [00:45:03] jalexb88 yeah the csm is really not realistic at all with ECS, but as Nik pointed out it is stable haha [00:45:14] and astronauthen96 I haven't a clue [00:45:30] Uh oh missed a lot of good logging earlier [00:46:39] no you didn't, the logging stopped when Guenter briefly left the room [00:47:15] Last log entry is from 01:06 local [00:47:16] .t [00:48:33] But the repress works a lot better now and can repress the cabin from 4-5.7 as is needed for Lm press [00:48:50] Literally just changed it to a real world volume and temperature [00:48:53] And it worked [00:49:28] nice [00:50:05] does that mean direct O2 valve to open, pressurizes to 5.7 within 2 minutes now? [00:50:28] Its better but not perfect [00:50:41] The plumbing in NASSP is not nearly the same as the actual CSM [00:51:07] I guess as you say, they did that for stability [00:51:08] I increased the flow so it does get it up 60x faster though [00:51:21] They used LBM values in a LBH conversion [00:52:18] But the CSM will need a major overhaul, and I think once Niklas and I have solved the stability issues (which we think are resultant from heat exchanger code and thermal code in general) we can retweak the LM to work right and in V 9 we can overhaul the CSM ECS [00:52:40] Other than a tweak here and there the CSM ECS will probably stay as is throughout V8 [00:53:11] Is swatch, dseagrav here? nope... Brunch of lazy bums! :D [00:54:46] I may make a few more LM ecs changes but until we find the underlying stability issue its probably going to remain as is, though I do intend to increase CO2 scrubbing in the LM for now [00:57:29] It would be nice to include the LM in the "crew death simulation" Is that something we can do now? [00:58:03] I guess once we can keep the CO2 levels in the green band [01:08:40] Yes it is [01:08:53] Just throw the same parameters in for the LM [01:09:15] It might show a separate dead/alive for each spacecraft though [01:09:27] Which I suppose if your LM crew dies you can take the CSM back [01:10:22] Ive tried killing the LM crew but it doesn't seem to be simulated yet, it always says crew status OK [01:12:24] Yeah theres no triggers in the LM yet for that [01:12:58] As soon as the CO2 is worked back out I think we can do it [01:13:19] I have had good luck with the cabin/suit temp press and depress [01:13:38] the only problem I have is because of the valve sizes mostly, the suit pressure stays a bit high with suit fans on [01:14:05] Closing the suit circuit relief during depress helps [01:14:15] and along with it the full set of criteria: [01:14:17] - Pressure in suit lower than 2.8 psi for 10 minutes [01:14:18] - Pressure in suit higher than 22 psi for 1 hour [01:14:19] - Suit temperature above about 45°C or below about 0°C for 12 hours [01:14:19] - Suit CO2 above 10 mmHg for 30 minutes [01:14:20] - Acceleration exceeds 12 g for 10 seconds (I don't know how long you had >12g, so I'm not sure if you found a bug? What was your max. g?) [01:14:21] - Touchdown speed exceeds 15 m/s (= about 50 ft/s) [01:14:40] thats from a forum post [01:17:17] Yeah that sounds right [01:17:32] I could just duplicate the detection criteria from the CSM [01:18:00] The suit high pressure seems weird haha [01:18:29] Also the temperature criteria seem a little limited [01:18:38] Apollo 13 was close to that [01:18:47] 1 or 2 C for the return [01:18:58] ouch [01:22:35] more like 2 or 3 but still [01:26:11] I guess that frozen sausage scene in the movie was an exaggeration [01:27:20] Oh no the CM was below freezing [01:27:30] The LM was above freezing [01:28:11] So the lockers in the CM with food were basically in a freezer [01:29:25] ah I see [01:30:38] Remember all 3 men were mostly in the LM [01:31:01] So the body heat and the heat from the limited systems stayed in the LM [01:43:05] yeah makes sense [01:44:56] So just so I am ready, what kind of checklist issues have you found? [02:13:06] some switches, particularly the LM comm panel switches don't sequence in the checklist. (the wrong position makes it sequence to the next item) [02:15:20] Before LOI there is a 1st pass through P40 for the SPS gimbal check. The whole P40 check is run, with a V37E 00E before the burn. What is missing is the post burn items (gimbals off, bus tie switches off) [02:15:39] Keep the list going, are you flying to splash? [02:16:57] DOI burn attitude is 180 off in roll, I think there is missing a 180 roll before DOI [02:19:30] In the rendez-vous checklists, there should be more times stated, say at minus 8 minutes press PRO for the final pass for say TPI [02:20:03] right now it says PRO for the final pass, but I was still at like 15 minutes before the burn [02:27:45] and MCC1, MCC2 (RDVZ) the PRO should be hit at +12 minutes in P35 [02:29:04] so there could be a manual (yellow) check saying wait until 12 minutes into P35, then continue to "PRO" [02:30:51] Sorry, the item I said before, about the final pass PRO during P34, I meant to say should be at minus 12 minutes [02:32:13] This is great feedback [02:32:18] Thanks for doing this [02:32:59] Some things I believe like your pro for final pass are per the actual checklist but I will double check everything [02:36:47] no problem! [02:36:49] yeah, just that in the actual checklist it says to do it at 12 minutes before the maneuver, so what I meant was just to put in something that says to do it at -12m [02:38:27] anyways, im off for the night, cya! [13:41:29] hey [13:42:14] so will rcflyinghokies change be released today? [13:43:39] hey [13:43:40] no idea [13:44:03] is it important [13:44:19] no idea [13:44:26] do you mean the latest pull request? [13:44:29] I just merged that [13:44:30] yes [13:44:34] oh [13:44:35] okay [13:44:41] I thought you mean some other changes [13:44:58] he gave me a fix for my scenarios [13:44:59] but the PR is merged now, so you can use it [13:45:13] would it only apply to pre lem ejection scenarios [13:45:58] it also has some CSM changes, so technically the full changes only apply to the T-4h scenarios [13:46:28] But I wouldn't start over your mission every time there is an update like that, haha [13:46:31] yeah i accidently cleared all my saves so i can just do the 4 hours scenarios anyway [13:46:35] oh [13:46:38] in that case [13:46:43] i pressed clear quicksaves by accident [13:47:39] but on the bright side i havent got a single ctd so far [13:47:51] that's good [13:48:08] at this point we are solving more bugs than we create new ones [13:48:20] thats great [13:49:03] when i click on the build it says page not found [13:49:10] it is still building [13:49:15] okay [13:49:18] I only merged the PR just now [13:49:21] takes a few minutes [13:49:37] usually 10 or 11 minutes [13:49:46] https://ci.appveyor.com/project/dseagrav/nassp/build/8.0-Alpha-Orbiter2016-1049 [13:49:56] here you can see it building live [13:50:18] nice [13:50:43] so i am good for the 4 hour scenario then? [13:51:52] the T-4 hour scenarios are what we always keep up to date [13:51:59] good [13:52:29] in those scenarios the CSM ECS is created from scratch, in all later scenarios lots of parameters saved [13:52:41] including those that rcflyinghokie is currently tweaking quite regularly [14:01:47] got the build [15:12:35] Good morning [15:13:12] The repress valve seems to be working properly now, able to repress the cabin from 4-5.7 without being on fill and without dropping the CM temp [15:13:13] hey [15:13:43] I also tested it on a cabin repress from 0 psi and adjusted so it still goes from 0-3 psi in about a minute [15:26:11] The only catch is old scns hae to be edited to take advantage of the new valve and tank sizes [15:26:13] have [15:28:35] hey [15:29:07] Morning [15:29:15] @rcflyinghokie i accidently pressed clear quicksaves so i am starting a new mission anyway [15:29:26] Ah I have done that before [15:30:13] If you want to fly an entire mission I recommend after a major mission event (TLI for example) you quick save and then rename the file and save it somewhere other than the quicksave folder [15:30:34] okay [15:30:51] will there be anmore major ecs changes in the next week? [15:30:57] anymore* [15:34:05] No idea to be honest [15:34:32] Possibly increasing the LM CO2 removal rate [15:45:21] infy91, I have an Apollo 12 pre-TLI scenario, where the TLI pad freezes up orbiter when the pad is calculated [15:45:48] indy91* [15:48:35] AlexB_88, I'd like to look at that scenario [15:48:50] sure [15:50:16] maybe something I changed wasn't so good for the LVDC without presettingds [15:50:18] presettings* [15:52:49] hmm for some reason I just retried it and it works [15:53:32] that's even worse [15:54:06] wait I think I know why [15:54:30] I forgot to uplink the RTCC TLI solution to the IU, before calculating the pad [15:55:03] so the LVDC only had some default parameters [15:55:10] yeah [15:55:17] actually, there is a flag in the LVDC that indicates that an uplink happened [15:55:25] a TLI target update [15:55:28] I guess the TLI pad doesn't like that lol [15:55:53] if that flag is not set (before the uplink) then the RTCC MFD currently assumes that the LVDC has good presettings [15:56:02] because no uplink would be necessary in that case [15:56:29] I think I can make that a bit safer [15:57:47] there does seem to be a few nan's in the LVDC section of that scenario, it is an old scenario though [15:58:10] https://www.dropbox.com/s/wiodh7yybcfrpdd/Apollo%2012%20-%20before%20TLI%20%28no%20fuel%29.scn?dl=0 [15:59:20] the TLI targeting parameters are NaN, interesting [15:59:26] those that you would uplink [15:59:51] in scenarios without presettings it should use some default numbers [16:00:02] the LVDC interpolates between values from tables [16:00:11] I wonder if that operation is unsafe in some way [16:00:19] so that the interpolation results in nan [16:02:56] hmm so now I calculated a good TLI pad in that scenario, but the SEP yaw angle is 002, should be 330 I think [16:03:29] and in the presettings there does seem to be the right values in there [16:03:56] LVDC_XLunarAttitude 3.141589512000 2.094395207000 -0.523598775600 [16:04:18] ah, I think those angles are not used in that case, that should be fixed [16:04:30] they are only used when no uplink was done. That's a bug [16:04:40] it used 180°, 120°, 0° by default [16:04:44] uses* [16:04:51] ah I see [16:05:32] hmm [16:05:50] actually, in the case of an uplinked solution the MFD doesn't use any values from the LVDC [16:06:07] but instead the internally generated TIG and DV [16:17:18] Checking the LGC pump, can you cross check my math, I need a fan cap for 4 lb water a minute with a valve size of 0.001 [16:17:34] 1 lb of water is 0.45L [16:18:05] 1.8 L/min [16:18:15] 0.03 L/s [16:18:24] times 1000 [16:18:38] divided by 0.001 being the pump inlet valve [16:19:36] I got 30000.0 [16:23:29] If thats right I have the LCG accumulator almost perfectly on pressure [16:24:51] looks right [16:25:01] 30239.467 to be precise [16:26:54] Used more sig figs on the lb to L conversion? [16:27:31] yes [16:29:07] Thanks [16:31:19] Now the only problem left to solve is the high pressure in the suit circuit [16:31:39] larger valve [16:31:52] I was avoiding that solution [16:32:01] yeah [16:32:04] But since its not attached to a HX [16:32:08] It might be safe [16:32:18] just that one valve [16:32:25] In or out [16:32:28] Out [16:34:27] yes, I think so [16:37:15] Ok lets see what happens [16:37:23] Right now that is the only issue with a LM depress [16:37:32] I have secured all other inflows of mass into the cabin [16:38:07] And after that I will see what flows I have through CO2 and the water separators [16:40:23] testing Apollo 9 currently, the two IU uplinks already work [16:40:37] now a test if the LVDC presettings I came up with are any goodf [16:40:39] good [16:41:35] if yes, then I have a reliable way to calculate TLI parameters derived from TB6 start and TLI state vectors [16:41:53] which I could apply to all the other missions, because we have all the Postflight Trajectory documents [16:43:55] TB6 start within a minute of the planned time! [16:45:04] the TLI orbital elements are calculated when the IGM starts, so I won't know if this is any good until ignition [16:49:02] but a lot already has to be right for TB6 to start at the right time [16:54:27] everything was great, except that the S-IVB never cut off the engine [16:56:09] and it happened right over Cape Kennedy: https://i.imgur.com/AOBgVIO.png [16:56:21] well [16:56:27] over Southern Florida [16:56:33] but longitude wise [17:01:44] looks great, will be nice to see some actual preseetings for all the missions [17:01:57] yeah [17:02:18] this burn only has 57.44 seconds of IGM phase 2 [17:02:22] initial guess 308 seconds [17:02:29] might be the issue with the cutoff :D [17:02:49] obviously only on-time launches will be supported for the manually calculated presettings I take it [17:02:53] it was the default initial guess [17:03:10] yeah, only on-time, 1st TLI opportunity [17:03:16] good enough [17:03:31] the flight evaluation report usually has the preflight TLI state vector [17:03:50] and the postflight trajectory the actual TB6 state vector [17:04:05] so I don't even have a full set of planned state vectors to work with, unfortunately [17:04:25] The other advantage of this is actually being able to have the correct ORDEAL behavior during TLI [17:04:46] probably, yes [17:05:12] ignition was only 10 seconds earlier than the flight plan, so I have high hopes for the accuracy of this method [17:05:33] like since the curving nature of the 10-param TLI following the 300 ORDEAL vs. the fixed attitude 7-param that did not follow it [17:06:35] the fixed attitude mostly comes from the TLI TIG that comes with the 7 parameter update [17:07:06] the RTCC MFD calculates the TLI burn as a fixed attitude and the resulting parameters reflect that [17:07:19] ah I see [17:07:37] so, you would be able to change the TIG and get the pitching during TLI [17:07:50] which would be more optimal [17:07:52] DV wise [17:08:03] right [17:08:26] 10 parameter update calculates the TIG from a bunch of presettings, which are indirectly based on S-IVB mass etc. [17:09:01] so that already will cause a different behavior [17:09:17] presettings vs. 10 parameter update/uplink is almost identical [17:09:50] with the presettings the LVDC just has to convert some angles into the target vector, 10 param update provides that target vector directly [17:10:52] I still can't really add a 10 parameter update to the RTCC MFD [17:11:05] just making some decent guesses for the presettings [17:24:19] morning! [17:24:45] Hey Mike [17:24:52] what's up? [17:25:24] just in earth orbit [17:25:38] indy91, yeah I guess that will be presettinngs that will be pre-loaded into the scenario, like Apollo 8 originally was? [17:27:00] yeah, about the same. I had a preliminary LVOT to work with for Apollo 8 actually. [17:27:07] had a few hard numbers for TLI [17:27:10] hey Mike [17:27:19] testing my Apollo 9 LVDC presettings [17:28:42] makes sense [17:28:52] gotta run have fun guys [17:30:09] nice [17:30:22] @thewonderidiot praise the agc [17:30:23] I have all of the output counters completed, I think, and all of them use the new PulseOutput() function [17:30:39] I'm toying with the idea of a PulseInput() too for the CDUs, PIPAs, and uplink [17:31:02] oh, uplink, too? [17:31:03] very slowly trying to wrap my brain around the physics of the PIPAs and what the input waveforms look like under acceleration [17:31:38] yeah, unlike downlink, uplink uses unprogrammed instructions, so it affects timing [17:31:51] so in an ideal world we would simulate that through pulses [17:31:51] the scope of this yaAGC update seems like something that would be good for a NASSP 8.1, haha [17:32:07] that is 100% fair lol [17:32:18] we can do it piecemeal though [17:32:37] I'm just striving for perfection :) [17:33:01] at this point there are only a few small things I can point to on the schematics that yaAGC isn't simulating [17:33:15] it has almost reached the point of a 100% accurate and complete simulation [17:33:39] are you talking about the agc? [17:33:43] yep [17:34:25] well i can tell you one thing and that it is 100 percent worthy of praise , nice work [17:35:10] haha thanks [17:35:39] actually there is one little thing that will keep us from full cycle-accuracy [17:36:08] at least without putting some effort into trying to come up with a simple solution to it [17:37:22] the F05A timing pulse that is responsible for timing the generation of count requests for a lot of the output counters is split into two halves using the SB1 and SB2 strobe pulses... so while F05A is high, F5ASB1 will be high for the first half and F5ASB2 will be high for the second [17:37:51] and occasionally the split between F5ASB1 and F5ASB2 can align with the split between two instructions [17:38:22] I simulate all of the F05A activities at once so it is possible for an unprogrammed increment to occur one instruction off for the affected counters [17:38:30] but should not be that big of a deal [17:38:34] how terrible [17:38:43] lol [17:38:46] one instruction off, totally unacceptable [17:41:11] I should stop changing this variable in the scenario and instead first implement that the variable is actually LOADED from the scenario [17:41:44] haha [17:41:53] sounds like a good idea :P [17:44:44] oh jeez well the AGC is stable at least [17:45:09] apparently I accidentally left it running the Borealis self-tests [17:45:27] sometime yesterday after I finished messing with it? [17:45:47] anyways, it's since completed 1113 self-tests without finding issues, heh [17:46:01] that's a lot of self tests [17:46:22] prooobably overkill [17:47:59] i know i keep praising nassp but i really do mean it, it must have taken you guys alot of work [17:51:21] yes, but fun work [17:52:48] @do you plan on flying any missions soon? [17:52:54] @thewonderidio [17:52:59] @thewonderidiot [17:58:07] mmmmmmaybe [17:58:32] I want to finish this emulator overhaul and then get back to working on hardware [17:58:57] I mostly blame Niklas for me not making much progress on the AGC hardware design last year :P [17:59:26] well, I guess not mostly, because I got myself into it by talking to Don [17:59:29] anyways [17:59:36] I want to start getting in boards and testing them this year [18:10:29] Way too much mass goes into the system from the pressure regulator that even though it cuts off at 3.8, the suit circuit increases to above relief pressure [18:29:11] Ok I have decided I want to remove the isolation valves as tanks [18:29:25] They seem to cause more trouble than their worth [18:30:45] So I would need to add valves to the HXH that go to both suits and the suit circuit [18:31:16] And I think I can do it without adding extras [18:31:50] sounds good [18:32:06] Sorry for the constant ECS PR's [18:32:51] haha, no worries [18:41:03] Hm to make it right I think I need to add 1 valve [18:41:52] Typically if a suit is in disconnect, the isol valve bypasses the suit and flows to the suit circuit [18:42:08] I could do that individually with the tanks [18:42:43] So I think I need 2 out valves from the heat exchanger to each suit and 2 going to the suit circuit [18:43:08] I could just use one and only close it if both suits are in disconnect as well [18:43:38] I will try that first actually, maybe it will yield good results [18:50:47] Might make things complicated in the switch code though [18:52:58] @indy91 tli ignition was right on time 2:44:16 [18:53:40] Apollo 11? [18:53:46] yes [18:54:31] and cutoff at 5:34 [18:55:45] I would hope it is on time, after all we use the exact same targeting parameters as the actual Apollo 11 mission [19:03:44] I added 1 valve and am attempting to put it in the isolation valve code [19:04:38] Can I make the pointer to the valve itself? [19:05:04] h_Valve * scinvlv = (h_Valve*)Panelsdk.GetPointerByString("HYDRAULIC:LMPSUITDISCONNECTVALVE"); [19:05:14] Or should I pointer the pipe and close it that way [19:05:39] you can point directly to the valve, no problem [19:06:39] Ok [19:09:38] Lets see what happens... [19:26:32] docked [19:36:25] Its a lot better now I think [20:08:26] Just have a perpetual pressure increase I am betting is from the sun [20:11:50] so some isolation might have to be increased [20:12:38] Yeah [20:16:52] so with my Apollo 9 TLI I still have one issue. One out of the 6 calculated targeting parameters is 15° off [20:17:05] about the same amount that the S-IVB travels from TB6 start to injection [20:17:33] so maybe it is something with that, after all I calculate the target vector from the injection state vector [20:17:56] the orbital plane calculated by the LVDC is right, inclination etc. [20:19:33] that's more than I ever managed to do before [20:21:27] nice :D [20:37:59] I increased all the isolation by a magnitude and it still climbs, releases through the relief valve, and climbs again [20:38:30] I have pressure increase energy increase but temperature decrease which doesnt make sense [20:53:08] weird [20:55:58] thewonderidiot, btw, NTRS actually has one of the countdown documents I was looking for [20:56:00] Skylab Rescue [20:56:09] oh awesome! [20:56:11] but it does not have what I hoped for [20:56:15] oh boo [20:56:22] list of Terminal Countdown Sequencer events [21:16:56] Ah its with the crew in there [21:17:02] Influx of water and co2 [21:17:09] And heat [21:17:23] I am watching the mass increase [21:17:35] If it stabilizes we should be good [21:18:05] But if it keeps increasing the water seps and co2 arent keeping up [21:20:19] Ok indy91 can you walk me through how the water seps and co2 scrubbers work in the code [21:21:40] h_WaterSeparator::refresh [21:22:17] first it checks for the pressure difference, like a pipe [21:22:31] then it calculates the volume for the flow in that timestep [21:22:33] "fanned" [21:22:49] then it creates a new volume, "h2o_volume" [21:23:01] h2o_volume.composition[SUBSTANCE_H2O].mass = fanned.composition[SUBSTANCE_H2O].mass; [21:23:16] copies over all the H2O from the flow volume to the H2O volume [21:23:32] SetTemp(300.0) sets a certain temperature for it [21:23:58] GetQ() is needed, because it recalculates the complete Q of the volume [21:24:40] then it lets the water flow into the waste tank [21:24:57] and sets all the water in the "fanned" volume to 0 [21:25:10] and let's "fanned" flow into the output tank [21:25:21] Makes sense [21:26:16] CO2 scrubber is similar, but has an upper limit [21:26:30] for the removal rate [21:27:58] 0.0356 is the hardcoded limit [21:28:10] g/s or so [21:28:33] Yeah I dont think I even reach that [21:28:43] I am going to see what my rates are in my current iteration [21:28:46] if there is less CO2 in the flow, then it removes all of the CO2 [21:29:05] yeah, you can watch the removal rate in a debug string [21:30:18] Yeah [21:30:27] I am making one for the H2O removal rate now [21:30:42] I am pretty much just copying the code from the co2 removal rate [21:32:12] an upper limit for the removal rate? [21:32:28] so you don't want it to remove all the water [21:33:01] another difference is that the CO2 just gets removed of course [21:33:06] not directed into another tank [21:33:42] No, adding code so I can see the H2O removal rate like the CO2 [21:33:56] ah [21:34:12] I think I did it right [21:35:39] No errors is always a first good sign [21:42:07] Ok my flow in depressed egress configuration is CO2: 0.065 and slowly rising and H2O: 0.072 and slowly rising [21:42:14] This is with no crew [21:43:16] Settled to 0.07 CO2 and 0.073 in the WS [21:43:52] where is the CO2 coming from? [21:44:34] These are flows [21:44:40] Not removal rates [21:46:02] Added the crew, removal rates increasing [21:47:36] Haha cabin temp is increasing with nearly zero pressure [21:47:41] Damn sun [21:48:24] Ok witht he crew flows settled to 0.055 each or so [21:48:37] Removal rates still increasing slowly [21:48:44] CO2 is 0.0028 [21:48:51] H2O is 0.005 [21:49:25] ppCO2 is up to 4 after 11 minutes [21:52:16] I am 10% of that CO2 removal maximum [21:52:56] Maybe 15% [21:53:41]