[01:14:23] NASSP Logging has been started by thewonderidiot [01:14:27] Guenter! [01:22:37] rcflyinghokie, nice! [01:23:34] I have one last issue to solve. everything is stable but my hydrogen is, in the words of Cole Porter, too darn hot... [15:48:58] good morning [15:54:03] Hey [16:06:49] Haha indy91 I was just drafting a long reply but you posted before I did :P I am happy the forums let you know when a new message has been posted! [16:07:37] and good morning all [16:08:28] hey [16:09:00] Hey hey [16:11:19] Houston, where is the ice cream I asked for? :D [16:11:33] I wanted to have it on the last day of mission [16:11:38] Hey AlexB_88 [16:11:43] good morning [16:11:54] Enjoying your VC on the realtime simulation! [16:12:19] nice! [16:13:18] still a few small bugs to fix in the VC, I will have to get around to it when I have time [16:13:20] except some gauges are weirdly calibrated :D [16:14:02] yep that was one of them [16:14:10] I found one bug with the FDAI rate needle [16:14:19] but otherwise I didn't touch the VC [16:14:25] ah yes I saw [16:14:43] probably a copy/paste error I did [16:15:13] Quick question: What does "Cabin cold soak" really mean? [16:15:31] To prepare the cabin "termally" for the heat of reentry? [16:15:45] I noticed the AGC star marker file was updated? [16:16:11] yeah I small 0.01° change, because I saw something in the Orbiter code that was bad [16:16:14] a* [16:16:33] ah [16:17:01] a coordinate transformation that Orbiter does with a very outdated hardcoded value [16:17:11] in fact I should probably create an issue on Github for that [16:17:28] and I am also looking into changing the stars themselves [16:17:35] would that help things like P23? [16:17:42] move them back to where they were in about 1970 [16:18:23] well all alignments really. I'd say a 0.01° change is significant, but not so significant that it really changes something from bad to good [16:18:28] I dont think it would help P23 too much, isnt the earth shape and horizon the biggest issue? [16:18:43] yes, because marks on landmarks works mostly fine [16:19:05] right [16:20:02] AlexB_88, I wanted to do some VC fixes, but I didn't really understand some things and wanted to ask you first [16:20:12] sure [16:20:13] a lot of the meters have custom SetRotationRange values [16:20:16] but only slightly [16:20:36] I thought those meters are identical, and their range should already be set somewhere else [16:20:58] a lot of them are not showing the same things as on the 2D panel [16:21:06] they are a bit off [16:21:34] the round meters correct? [16:21:39] yeah [16:21:46] I am seeing like [16:21:48] 38.4° [16:21:50] 38.6° [16:21:52] 39.5° [16:21:55] that sort of stuff [16:23:31] hmm [16:24:03] I feel like that should also be the same number for all meters of this same type [16:24:04] which meters are those exactly? [16:24:34] cryo pressures and temperatures especially [16:24:54] TurryBoeing will know best, he has written down a lot of data flying Apollo 7 [16:27:27] and if it somehow needs custom values for each meter then something isn't right in the code common to 2D and 3D panels [16:30:33] the round meters on panel 2 are all set to a rotation range of 110 [16:31:03] the ones you listed above seem to be the curved meter (vertical) [16:31:42] oh, sorry [16:31:46] yes I meaned curved meters [16:31:51] meant* [16:32:09] ah ok [16:33:29] each individual meter has the top marking and bottom marking at different "heights" [16:33:47] so I scaled them each individually [16:34:21] but maybe a better way is to scale them all to the same size (of the gauge itself) and then handle it all in code? [16:45:57] hmm [16:48:25] I don't understand right now what the null position of the animations are [16:48:41] you set a rotation range, but what angle is the animation state 0 [16:53:54] oh probably the default state of the needle mesh? [16:54:29] all the needles in the mesh are at the bottom of meter [16:54:35] thats the 0 position [16:56:08] the absolute bottom of the meter or the beginning of the scale? [16:56:18] does the scale start in the same place for all those meters? [16:56:28] hmm [16:56:34] the beginning of the scale [16:56:54] and each has a slightly different beginning sometimes [16:57:07] I am starting to think I should have put them all at the very bottom [16:57:08] that might the misalignment then [16:57:27] yeah thats why you have slight variances [16:57:50] the system for the 2D panel isn't very good either [16:57:59] but the real meter, would the needles be at the very bottom when un-powered? [16:58:18] not sure [16:59:35] if we need to move the needle mesh it self it shouldn't be too difficult [16:59:55] like so they all have the same 0 point at the very bottom [17:00:02] and then the rest done in code [17:00:19] Good question about the needle positions, I see a lot of SC in museums and they are in different spots (probably because of the curve and SC position) [17:00:40] maybe they would just stop moving [17:00:48] in zero G though what would drive them to the bottom, my guess is they would just stay in place [17:13:15] so they are d'Arsonval meters [17:14:14] https://instrumentationandcontrollers.blogspot.com/2012/06/darsonval-movement-electrical-analog.html [17:16:55] so I guess they would go to zero? [17:18:06] or wherever the springs were "zeroed" [17:29:47] ah I got the classic [17:29:49] "s not currently available for distribution. We have requested a review from the issuing NASA Center for the documentation needed to distribute this document, although we cannot provide a time frame for when, or if, the document will be made publicly available. We will let you know when we receive an update on the status of this document." [17:32:08] bummer [17:32:31] just have to to be patient for a few months :D [17:34:04] rcflyinghokie, interesting link [17:42:03] morning! [17:50:33] oooo we could simulate gauge response to vibration if we wanted to :) [18:03:52] hey Mike [18:10:41] what's up? [18:18:01] hey Mike [18:18:50] someone on the forums asked about displaying mission time on the screen, I guess a bit like AMSO [18:19:02] I think this should be possible to do [18:36:23] Like as a window? [19:00:29] V16 N65, open telemetry client, there you have your external mission time :D [19:00:41] hehehe [19:01:42] I approve of this method [19:03:26] it downlinks the AGC time without V16 N65 [19:03:31] but the client shows it in octal format [19:07:32] I read the thread, but I'm not really understanding it [19:07:40] display the mission time outside or inside Orbiter? [19:07:49] AMSO has it on the screen somewhere [19:07:55] in Orbiter [19:08:21] with the MCC and RTCC MFD both using the same instance of the RTCC class, there could be an in-simulation way to show actual GROUND elapsed time [19:08:54] basically like the MOCR mission time would probably be driven by the RTCC liftoff time [19:10:28] RTCC class has a timestep function that does basically nothing right now. I could add a flag in the RTCC class, which can be set in the RTCC MFD, and then the RTCC timestep would display mission time on the screen [19:29:56] AlexB_88 "uncalibrated" gauges are Cryo H2 & O2 pressure [19:30:19] They don´t show the same on 2D vs 3D, being the correct reading on the 2D panels [19:30:29] (i think :O ) [19:38:58] ah yes, I will have to revise that [19:41:37] Do you think about implementing lighting in the VC? [19:41:42] That would be AWESOME [19:41:59] I mean, the flood lights, integral lights, etc [19:42:12] But can wait for that :) [19:54:50] so I am trying to conceptualize a way to implement the water accumulators in the CM [19:55:05] They use a wick instead of flow through [19:56:34] basically I am using a similar method to the LM separators, but I am making H2O removal based on the pistons pumping, which in this case will be the pressure delivered to them (100 psi would yield max removal etc) [19:56:53] but I am trying to figure out a way to make it "pull" water out of a tank without flow [20:01:56] I suppose I could just use the tank I am pulling water from and "remove" water from there [20:10:29] I agree lights would be very neat :D [20:12:14] not quite there yet in my 3D skills but maybe one day :) [20:41:29] rcflyinghokie, would flow be that inaccurate though. it's just capillary pressure right? [20:42:10] well the current separators rely on flow through a tank for removal [20:42:27] So I am just giving it a source to remove water from based on the accumulators functioning [20:47:00] I wish I knew their size so I could determine bleed pressure based on work done [21:07:14] quick reality check: valve sizes are actually l/Pa/sec right? [21:08:14] I believe so, yes [21:12:55] in that case I'm trying to pump about 325 l/sec through a loop of 1l tanks. that might be the source of my instability.... [21:13:55] yeah sounds like my LM woes [21:14:03] I spent a LONG time adjusting valve sizes [21:14:15] I fear the case will be the same with the CM now [21:18:14] I was very happy with how stable the H2 and O2 pressures were. even at 50x on the 2d panel with a bunch of getpointerbystring running, they only oscillate in the 5Pa range [21:18:25] so it might not be that bad [21:18:27] thats good for 50x [21:19:22] the gasses no longer want to condense/boil every other timestep now. that was a huge problem before [21:39:17] I think I have a rough accumulator class done [21:39:36] Lots of pointers across other things before testing but I consider that a win for today lol [22:10:19] night! [23:32:48] goal is to make it "run" when there is o2 pressure supplied via the water accumulator remote or manual valves [23:33:17] then I will need to write something to allow the "auto" mode to cycle accumulators [00:54:57] I just spent a good 30 minutes trying to find the bug that was preventing the eps radiators from going into bypass mode [00:55:15] ...turns our the breakers were open [01:06:19] I'm also fairly certain that I'm limited to exactly one major epiphany per day. [01:28:41] Well, one major epiphany per day is a nice rate [01:28:53] I usually get one every 2 weeks... [03:44:02] Preparing entry [03:44:11] Geting nervous [03:44:19] Everithing will be okay! [06:12:30] Uploaded file: https://uploads.kiwiirc.com/files/1610ce58abd2d7358c0827750a7a2863/imagen.png [14:19:02] hey Ryan [14:25:25] I have a dumb typo in my branch that I seem to be incapable of finding.... [14:29:04] haha uh oh [14:29:17] ctrl F not helping? [14:29:54] nope [14:30:15] fc2 loop is inexplicably colder [14:35:40] hmmm [14:35:49] which branch I can check it out and look [14:44:16] FuelCellSystemsUpdate2 [14:46:35] I'm sure it's an obvious error that I just cant see. [14:49:13] I'll take a look [14:50:34] where are you thinking it lies? [14:52:12] also, we will probably have to manually merge things later since we both are heavily changing the cfg file [14:58:07] where is it colder [14:58:46] the condenser glycol for fc2 [15:00:05] ok I'll take a look after this meeting [15:14:52] which tank is that measuring [15:24:36] or radiator [15:27:47] ah found it [15:27:54] not the error though [15:28:48] FUELCELL2CONDENSER [15:29:08] oh wait [15:29:44] I have a valve in the fc1 loop that is smaller than it should be [15:30:51] and radiator 2 is 10x more massive than the others [15:31:15] haha [15:33:29] the NASSP initiation ritual should be solving a valve size problem [15:34:48] seriously [15:35:00] and yeah I see that mass difference [15:36:00] easy fix [15:36:22] did it solve the temp issue? [15:39:45] I wont have a chance to test until tonight. at the office right now [15:40:19] but it seems plausible that it would. [15:45:37] the current config is still a bit hacky because its measuring the temp of the glycol, not the water [15:55:17] I am annoyed, I still can't really figure out how I want to calculate one general purpose maneuver type [15:55:37] "Maneuver to shift line-of-apsides to a specified longitude". Only inputs are that longitude and a threshold time. [15:55:45] There are multiple ways this could be interpreted [15:56:15] maneuver point: that longitude. Maneuver type: cancel out vertical velocity [15:56:24] that would do it for example [15:56:29] or [15:56:59] maneuver point: threshold time. maneuver type: whatever line-of-apsides rotation is necessary to put the perigee (or apogee?) at that longitude [15:57:23] or some optimal maneuver point that needs the smallest line-of-apsides rotation to accomplish the same thing [16:09:02] is there a convenient for "longitude of line-of-apsides" referring to periapsis vs apoapsis? [16:10:07] longitude-of-periapsis is a term I'm familiar with. the other, I'm not sure I've seen much of [16:13:46] I would guess it's the periapsis they want to place somewhere [16:25:15] that would make the most sense [16:29:00] threshold time is just a single value? [16:31:14] yeah, just the earliest time for the maneuver usually [16:31:37] in some cases, when the maneuver is at a fixed time, then that is the TIG [16:33:33] what would this be useful for? rendezvous stuff? [16:35:32] maybe to fly close to a ground station [16:35:44] or setting up a desirable perigee for reentry [16:36:57] yeah I was thinking of argument-of-periapsis, which you can change without changing inclination relative to ground targets [16:38:16] hmm yeah that is annoyingly ambiguous [16:38:29] and it's an RTACF only calculation type [16:38:46] the RTACF had a bunch more maneuvers it could calculate than the RTCC [16:39:08] this specific one isn't getting used by the MCC, but I can't target half the Apollo 7 and 9 maneuvers without the RTACF version [16:39:37] and I am pretty sure the current version of this maneuver type is wrong [16:39:49] it always happens at apogee because its maneuver code is SAA [16:39:56] last letter usually stands for the maneuver point [16:40:30] but in this case that might just be because other letters are already taken :D [16:41:12] there is SAO, o for optimum basically. line-of-apsides shift without changing apogee and perigee heights. [16:41:18] That has a special calculation for the TIG [16:45:53] and of course a document that could potentially help is yet again on the restricted NTRS [16:49:46] and staring at me from NARA, too [17:12:00] Hey guys, from S.S. Essex [17:18:47] hey [17:18:56] USS Essex [17:19:40] yes the title matters :) [17:23:48] * U.S.S [17:34:48] Thank you :) [17:35:21] My father served on her sister ship, so the proper designation of a US commissioned vessel is important to me [17:35:35] did you all see VS2022 launched? [17:35:49] https://visualstudio.microsoft.com/launch/?ocid=vstndb63 [17:36:50] rcflyinghokie Thanks for the correction. Didnt knew it was like that. Sorry for that [17:39:18] hey Turry [17:39:28] ah we successfully skipped a Visual Studio generation [17:39:29] Not a problem! Just hits close to home :P Its like not using the proper title for someones achievements/position [17:39:44] there was a USS Essex that got captured and then became HMS Essex [17:40:19] Haha yes the original namesake, I believe [17:42:01] Hmm to download VS2022 or stay on 2019 :P [17:45:00] I downloaded 2019 a while ago and never used it :D [17:45:06] On work I use 2013 :) [17:45:07] might as well delete it again and skip [17:45:09] n7275, shouldnt there be a vapor mass in the cryo O2 tanks? [17:45:20] I have been using 2019 since it came out [17:45:41] I have all versions installed from 2010 to 2019 right now... [17:45:51] I needed at least 2010 and 2017 [17:46:04] without 2010 the CSM telemetry client couldn't have been rescued [17:46:54] cant you just use the compatibility package for that [17:47:44] maybe something like that would have worked. I remember that nothing I could do worked in versions 2013 and later [17:47:46] oh there isnt one for 2010 [17:47:52] that might be why then :D [17:48:02] I see 2015 but nothing before that [17:48:15] just getting it compiled in its original state was a problem [17:48:22] it wasn't even written for 2010 [17:48:34] I use MSVC v141 to compile NASSP in VS2019 [17:48:41] its the 2017 compatability [17:55:25] morning! [17:58:20] Hello sir [18:32:51] rcflyinghokie, how early in the mission are you ou seeing no vapor? [18:37:15] looking at my Apollo 17 saves, my very first save has zero vapor pressure [18:37:26] In both O2 and H2 tanks [18:38:00] how about near the end of the mission? [18:38:43] Near the end, the H2 tanks have vapor pressure but O2 is still 0 [18:39:00] strange. [18:39:57] here are 2 for you to compare [18:40:05] https://www.dropbox.com/s/beil9kb0sivvtve/Apollo%2017%20-%20Launch%20with%20Delay%200001.scn?dl=0 [18:40:11] oh. probably above the the critical point [18:40:13] https://www.dropbox.com/s/5hxczijsyg9mus7/Apollo%2017%20-%20Entry.scn?dl=0 [18:42:12] I definitely get gaseous O2 and H2 in my fuel cell branch [18:42:44] just gotta warm it up and lower the pressure a bit [18:43:58] i need to compare against the cryo tank phase diagrams again. they're less inaccurate than they used to be [18:59:08] thewonderidiot, is there any chance you could get me the resistance across the terminals of the startup heater on a fuel cell? [19:00:27] oh yeah we definitely have that [19:00:39] standby though, doing some work stuff [19:09:18] awesome. no hurry. [19:10:33] oh n7275 did you make substance property changes at all? I know the masses were computed using those [19:11:02] TLDR do we need to adjust the substance initial masses to have the correct quantity [19:13:43] the only things I changed were vapor pressure and enthalpy of vaporization. [19:14:59] I dont think we need to change initial masses [19:20:49] ok [19:21:50] Also, which state are those values using for example specific heat [19:22:07] O2 and H2 values are very different for liquid and gas [19:22:19] thats why that line is commented out, one is liquid one is gas I believe [19:35:41] I didn't touch specific heat. so whatever it was using before, it's still using. [19:37:09] but yes, huge difference between liquid and gas specific heat. much more so than it varies with temperature [19:37:50] fixing that is no small project though [19:40:30] actually maybe not we'd just need to change the energy in every substance in the config [19:41:07] I might be able to work up a simple model [19:52:07] Yeah thats what I am trying to wrap my head around [19:52:24] We need something to change that value based on state [19:54:25] we compute temperature as an average of the specific heats in the tank, where that average is weighted by the mass of the substance [19:56:44] we just need to distinguish between liquid and vapor mass in that calculation [19:57:21] so we would also need to create a new variable for that line [19:57:45] the specific heat of the substance is the average of the liquid and vapor heats weighted by vapor fraction [19:58:04] yes SPECIFICC_L and _G [19:58:32] I'll let you add that to your branch [19:59:35] the commented out one I believe is liquid [19:59:51] The other is gaseous, but its been a while since I have touched them you might want to verify [20:17:26] I am going to see how VS2022 works with NASSP :P [20:17:52] after the slow download :P [20:19:29] Microsoft is a small company, can't afford fast servers [20:19:51] Haha well this is my current internet connection being slow [21:05:12] So looks like the Windows 10 sdk used in the project isnt available in VS2022 [21:10:07] 10.0.17763.0 [21:11:32] huh interesting, I reloaded it and its compiling it seems [21:11:48] maybe I dont need that aftera;; [21:11:49] all [21:13:47] hmm panelsdk.lib wont build [21:18:00] yeah it wont build on 2022 I guess [21:18:22] Would updating the solution mess anything up? [21:19:15] probably [21:19:29] we should commit to a switch and then everyone switches to 2022 [21:19:33] I think that is the best way [21:19:42] but not quite yet [21:20:05] fair enough [21:20:14] I can still build on 2019 for now haha [21:28:32] yeah. probably best if we all finish the large projects we're working on first [21:29:37] oh no [21:29:41] see ya in 2023 :D [21:31:05] yeah CSM ECS will probably be early next year :P [21:32:36] I still have a plan for the DragUpdate branch [21:32:43] it's not dead... not totally :D [21:32:57] haha soon *TM [21:35:46] All the O2 pipes are in the cfg, now begins the daunting task of going through the systems in the code one by one [21:36:23] the drag update is too good not to merge [21:37:32] I think I have an idea how to take the drag into account in the RTCC [21:38:17] the problem is really that the trajectory integrator always needs a mass and a vehicle area for that [21:38:31] and it needs to work for MCC, RTCC MFD with and without MPT [21:38:45] RTCC MFD with MPT is the easiest, as that just works like the real thing [21:38:59] including vehicle changes like CSM sep [21:39:42] but yeah I can't merge the drag update until everything in the RTCC is able to take drag into account [21:39:47] that is what it is holding up [21:43:23] ah makes sense [21:44:14] because it's going to be quite a bit more drag on average than before [21:50:08] I definitely love the CSM aerodynamics though [21:50:57] including the aerodynamic moments [21:51:10] spins the CSM up nicely in a low altitude :D [21:55:04] I cant wait to fly a full mission with it [21:55:47] I bet! [22:06:14] at least the GPM project is coming to the end [22:06:21] should just be a few more days [22:06:54] you won't really see a difference about it though haha [22:07:14] just an entirely different implementation, mostly exactly like the real RTCC, and a lot of corrections [22:07:47] and if I can't figure out the last 1-2 remaining calculation types, I'll just use the same method as before, even if I know that isn't quite right [22:14:01] night! [22:24:10] Time to start pointers [23:05:45] dont make 'em too pointy [23:56:24] got rid of a bunch of unnecessary (I hope) hacky stuff and replaced them with simple valve controls [23:56:41] Slow moving, of course, I am just up to the main regulators lol [23:59:57] It needed to be done sooner or later. [00:06:03] also I think its unnecessary to save all the masses and such of these tanks in the class when they are saved elsewhere in the scn [00:06:11] sscanf(line + 10, "%i %i %i %i %lf %lf %lf %i %lf %lf %lf", &i, &j, &k, [00:06:12] &o2SMSupplyO2.subst_type, &o2SMSupplyO2.mass , &o2SMSupplyO2.vapor_mass, &o2SMSupplyO2.Q, [00:06:12] &o2MainRegulatorO2.subst_type, &o2MainRegulatorO2.mass , &o2MainRegulatorO2.vapor_mass, &o2MainRegulatorO2.Q); [00:06:23] all that is saved in the class seems very redundant [00:06:34] this is just the "02supply" class [00:10:16] wait, so is it saved twice in the scn? [00:11:24] that what it seems [00:11:56] hang on, what file is this class in? [00:12:35] yep! [00:12:40] ecs [00:12:50] ecs.cpp [00:12:56] O2SmSupply class [00:14:06] ?? [00:14:08] a bunch of stuff saved that probably doesnt need to be [00:14:16] why does this exist... [00:14:24] CABINPRESSUREREGULATOR 0 5.000000 [00:14:25] O2DEMANDREGULATOR 0 0 [00:14:26] CABINPRESSURERELIEFVALVE1 0.001000 41368.468953 [00:14:27] CABINPRESSURERELIEFVALVE2 0.000000 41368.468953 [00:14:27] O2SMSUPPLY 0 0 0 0 0.0000 0.0000 0.0000 0 0.0000 0.0000 0.0000 [00:14:37] All of those are probably unnecessary and redundant [00:14:56] I will prune them as I go [00:20:07] I dont think any of those values are necessary to save [00:20:22] as they already are in HYDRAULIC [00:23:34] More lines in the config translated to 53 additions and 120 deletions in that class alone lol [00:23:46] I didnt think this would remove code but I'll take it [00:26:07] at a stopping point for tonight, feel free to see the damage lol [00:28:03] I'm glad you're removing stuff with all the things I'm adding [00:28:54] haha [00:29:09] well the CSM ECS is not terribly complex thankfully [00:29:30] Its a brilliant concoction of valves and regulation [00:29:47] The ARM at least [00:29:54] I am starting to understand it pretty well [00:30:01] looks like most of the stuff in ecs.cpp looks like it was added in 2007 [00:30:05] The cooling system and water systems though are complex [00:30:11] yep before my time [00:31:36] mine too. I was firmly a NASSP 6.4.3 user at that point...and I had no buisness doing any kind of programming [00:33:24] yep! [00:34:18] I was flying it for a bit then jumped on the old meadville space center forums [00:34:37] Thats where I met Nik and Thymo technically before I got brave enough to jump on the IRC [00:37:13] I forgot about it a while between 2013-2019ish and then I saw a "NASSP 8.0 alpha" video on youtube from Nik. and I was like "oh wow someone still uses NASSP 7.---- wait, 8.0? gotta check this out" [00:37:21] Haha [00:37:40] I remember when Mike figured out the issue in our AGS when I was digging into the LM and trying to learn it all [00:37:56] I made some videos that still are up in the VAGC site's AGS section lol [00:38:21] before that, our AGS was too unreliable to use [00:38:33] thewonderidiot can probably explain more the issue [00:40:12] I've seen those. good stuff [00:42:02] And then that snowballed into me pretending I could code and I gave the LM an ECS with a lot of handholding from Nik lol [00:44:09] I am hoping I can get a better grasp on stability though when I get a little firther [00:44:11] further* [00:44:43] But the way it currently sits, looks good on displays etc but is very very wrong function wise [00:48:20] I have a branch where I where I was adding an "advanced" feature where you could increase the number of system steps per timestep. [00:48:38] sounds dangerous and promising at the same time [00:50:15] very dangerous. but it could be useful if you needed inproved accuracy (for telemetry logging, etc) and could live with lower time acceleration [00:52:57] oooo, good news. I can now simulate a fuel cell startup with the startup heaters [00:53:23] oh on another (similar) topic, I have plumbed in a placeholder for the bladder pressure that comes from the o2 [00:56:33] so I'd love to figure out some way for that to work out [00:57:53] the regulator portion is very simple [00:58:04] some of this stuff may need extra types of systems to be added [00:58:13] yeah very likely [00:58:20] I have implemented a water accumulator [00:58:45] Can finally get rid of the silly combined class that removed co2 and water magically lol [00:59:05] I based it on the LM water separator, so it will require O2 pressure to run [01:00:07] I also will implement the proper cycling as well, the accumulators cycle every 10 minutes automatically [01:00:19] so one turns on for 10 minutes, then the other etc [01:00:32] prevents overheating and excess wear [01:01:30] and the valves can bypass the remotes (which are controlled on the MDC) and run them manualy simply by directing the O2 to the piston [01:02:55] its a pretty simple design which is nice [01:03:07] The only complicated part will be the O2 demand regulators, which have pressure schedules [01:04:16] would be cool to simulate wear on pumps and valves [01:05:20] could be interesting but probably not as necessary...I would want freezing of things first [01:07:06] basically, I am thinking of things that didnt work on apollo 13, and how we could make those not work under the same circumstances [01:08:32] And, as all things tend to do here, that reminds me, I still want to see how we can fix power to make that all function properly [01:08:42] like currentl flow based on potential [01:08:45] current [01:08:56] which of course was used to charge the CM batteries from the LM batteries [01:10:46] I am going to add battery outgassing as well to the battery class, connecting the system test meter to get a pressure from that tank etc as part of this ECS update [01:10:58] I figure since its a tank and valve, its appropriate :P [01:14:21] electrical is definitely something to look at next [01:15:13] will probably require a fundimental change from drawpower(watts) to drawpower(ohms) [01:15:35] and yes I like the idea of battery outgassing [01:16:17] eventually I want anything that has a gauge or telemetry word to be simulated [01:18:21] exactly [01:18:25] the LM is almost there [01:18:44] After this CSM ECS rework there will be a lot more [01:19:05] I am off though its thirsty Thursday :P catch ya later! [01:19:15] Feel free to peek my CSMECS branch if you are curious [12:47:39] Hey guys [14:38:48] good morning [14:39:36] Hey [14:39:39] hello hello [14:40:03] Figured out my attitude issue yesterday after SM/CM sep. [14:40:22] after thinking about it [14:40:27] Correct me if I am wrong: [14:40:32] head colds can really effect your attitude in space [14:41:12] :P [14:41:17] If I kept the PAD attitude after SEP, the earth would appear on the scribe line at 400000 ft right? [14:41:27] Because I was on a inertial attitude [14:41:50] So if I were to keep it, the horizon would appear around that attitude [14:42:52] yeah, at the right time the horizon will appear [14:43:00] And on other side... for the switch covers [14:43:18] Yeah if you tracked the horizon you should end up at entry attitude before EI [14:43:30] (Also I didn´t know that I was below 40000 ft :D) [14:43:41] Conversely if you held entry attitude, the horizon should be there at that time [14:43:49] Could we use the center mouse button to uncover covers? [14:44:18] while not a bad idea in theory, not everyone has a center mouse button [14:44:22] on my mouse the mouse wheel click is very inconsistent since a few months haha [14:44:37] If the mouse cursor is around the switch cover [14:44:51] And you click with the center... [14:45:01] the switch would uncover [14:45:02] also it likely would invite unwanted FOV changes [14:45:12] again not everyone has one [14:45:16] Yeah [14:45:26] Or maybe a click and drag? [14:45:46] But I think that there is some limitation by the orbiter core [14:47:28] not sure about that one to be honest as far as mechanics and limitations [14:48:03] Yeah. [14:48:26] oh indy91, I began reworking the O2SMSupply class last night, there is a lot of stuff saved in that class that basically is redundant as its also present in HYDRAULIC (ie masses, Q etc) [14:48:53] Ironically, I have actually removed more lines of code there than I have added so far with the additions in the config file [14:49:57] yeah I guess we have a few classes that do things in a special way [14:50:03] instead of letting the systems SDK do it [14:50:25] I removed a lot of "special" stuff that should simply be valves and pressure/flow regulation [14:51:00] so hopefully things work like they did in the LM using that technique [14:54:28] so unstable? :D [14:57:48] Shhh I wasnt going to say that [15:14:50] Well guys [15:15:16] Gonna watch a movie and then i will go out and drink with some friends in your honor [15:20:45] ok all 51 out of 53 GPM maneuvers that are unproblematic tested in lunar orbit [15:24:14] and the other 2? [15:24:31] are problematic :D [15:24:34] haha [15:25:14] one of them I was talking about yesterday [15:25:28] the other one is used for Apollo 9 SPS-7 to place perigee for deorbit [15:31:05] but I'll use the old technique for that, if I can't figure out a better one [15:31:10] will at least be working reliably [17:29:56] not that I have tested anything, but on to the cabin pressure regulators :P [18:13:33] rcflyinghokie1, if you already saw the posts by thermocalc, I've started to write an answer for his 2nd part. [18:27:33] I have not yet actually [18:27:49] just to prevent us from writing it twice :D [18:27:57] Haha yes good call [18:28:08] I will take a look at the first after a reboot and work meeting [18:44:22] morning! [18:46:50] hey mike [18:49:20] rcflyinghokie1 I've created a draft pull request on my fork for merging your changes into my branch. right now it looks like the only conflicts will be in saturnsystems.cfg. git just not understanding that things that are additions aren't changes, they're additions. should be easy to fix when the time comes. [18:49:57] whoops [18:50:03] rcflyinghokie I've created a draft pull request on my fork for merging your changes into my branch. right now it looks like the only conflicts will be in saturnsystems.cfg. git just not understanding that things that are additions aren't changes, they're additions. should be easy to fix when the time comes. [18:52:11] hey guys [18:52:20] rcflyinghokie, I already started answering the other questions,too [19:28:46] haha ok then I am just getting back [19:29:08] n7275 ok we will keep an eye out, I have a long way to go for sure [19:42:43] indy91 regarding the pericynthion -40m, I thought that was the trigger for that CSM update (LOS & AOS with and without LOI-1) [19:44:43] question # 7 [20:02:06] hmm [20:02:22] it is now actually before LOI TIG [20:02:43] can't even remember implementing that way, but it's relative to the LOI TIG as calculated by the MCC processor [20:02:53] doesn't even get updated during the LOI-1 calculation itself... [20:06:43] Ah ok, I thought we had it as PC before for the event that LOI was scrubbed or the mission was on an abort [20:06:53] Either way its still about PC-40m [20:08:31] yeah I'm nor entirely sure I agree with my past self haha [20:09:14] it's more user friendly though, you will know the TIG of LOI-1 and then everything is scheduled relative to that [20:09:51] I just changed "PC" to Pericynthion haha [20:10:00] Maybe that will help? [20:12:30] changing it to TIG would be correct [20:18:53] not sure about PC+2 [20:19:03] if that is truly at PC+2 or at LOI-1 + 2 [20:19:29] I have to get back to listening to MOCR audio... [20:20:57] This is PC -40m not PC+2 [20:23:01] But I have made it TIG -40m instead [20:23:20] yeah I was referring to what you said earlier [20:23:29] about events relative to PC for aborts etc. [20:23:35] Ah yeah [20:23:41] I think thats why I used PC to begin with [20:24:01] right [20:24:02] But that call assumes go for LOI so I think TIG is appropriate [20:24:23] the MCC at least uses LOI TIG right now [20:25:31] yeah I dug in and saw that, I changed to TIG to avoid confusion [20:39:48] sounds good [20:39:57] I'll let you know when I change my mind back to PC again :D [20:40:33] Haha if the trigger gets changed to PC in the MCC we'll talk ;) [21:53:10] night! [17:45:21] hey [17:58:24] Hey Nik! [18:06:27] I have more about the ALCSBT topic haha [18:06:38] a few weeks ago Ryan couldn't load a scenario [18:06:59] his LM ascent stage got somehow thrown on an extreme trajectory [18:07:14] and the equivalent to ALCSBT I have been using failed due to that and returned inf [18:08:06] instead of evaluating a series that function uses sine and cosine and so on [18:08:16] but ALCSBT has some extra code to handle extreme cases [18:08:48] so I think in a modern implementation the best solution is to use sine, cosine instead of that lengthy series [18:08:54] and that weird equivalence in Fortran [18:09:12] but I can still use that other bit of code that makes this extreme case not return infinity [18:21:56] any thing you need me to test? [18:23:23] nah, just wanted to share this haha [18:27:17] so I will do that update soon that should make the integrator work even in the extreme case of a LM being thrown to Jupiter [18:31:28] Ryan has gotten very good at that. Some extreme case, maneuver on the MPT, which means a bunch of processing at scenario loading [18:31:34] and then the scenario fails to load :D [19:15:33] speeking of breaking things. I have an improvement to our substance specific heat calculation. [19:18:12] a small or a big change? [19:23:52] small from a code standpoint. [19:29:15] but it breaks every temperature. [19:35:17] so I'm currently working on a script to fix the internal energy values in the config file and scenarios [19:37:13] so it will do: calculate tank temperature using old method --> calculate energy using new method that results in previous temperature --> save new energy value [19:38:30] hmm ok [19:38:45] does it change the temperature a lot? [19:38:59] Or does it settle down like in the current mission scenarios [19:39:13] What is changing that is causing temperature to break? [19:46:21] oh and about the mission scenarios, I am confused about something. Ryan edited all of them a while ago. Was that not for your substances update? [19:59:06] his edit was not related to my update. [19:59:35] I think that was when he switched the water coolant in the csm ecs to glycol [19:59:46] ah of course [19:59:51] and yes this would change temperature a lot [20:00:20] we use the liquid values for all our specific heats [20:00:44] this would distinguish between liquid and vapor [20:00:46] ah the liquid/gaseous thing you were talking about [20:00:57] that makes sense [20:04:44] ryan and I both need it for our projects, or else certain volumes of gas will require several times more energy/mass to heat at the correct rate [20:11:44] so all your gases are going to get fried [20:11:48] or too cold? [20:13:16] it effectively doubles the temperature for the same energy [20:13:47] very warm [20:16:56] but it sounds like a very important change [20:16:59] so we should do it [20:27:11] ok, I think I am actually done with this general purpose maneuver update [20:27:20] I'll take a bit more time for testing [20:27:29] but all the places where the MCC uses it work fine [20:27:36] that's the important part [20:39:16] that's good news. [20:47:01] the MCC always gets in the way haha [20:47:22] it means there has to be a very high standard with little chance of a calculation failing [20:47:54] and in some cases it would even fail in reality, then the flight controller gets an error message, he adjusts an input and then it works [20:47:59] but the MCC can't really do that either [20:59:28] yeah, that makes it challenging. we just need to create an RTCC training course. :) [21:00:00] MCC really is a great feature though [21:04:04] I should work on more examples for stuff in the RTCC MFD that have essentially reached their final form [21:04:46] in terms of inputs and output displays [21:04:54] there are lots of parts that will change [21:05:09] but TLMCC, LOI and some other stuff won't ever change much anymore [21:05:35] those two at least have detailed sections in the RTCC MFD manual already [21:08:23] and I could probably add MCC support for more missions already [21:08:39] but I am always thinking about certain changes to the RTCC [21:08:49] and maintaining the MCC for all the Apollo missions is... a lot [21:15:43] do you think we'll add support for the other missions at some point? people do seem to be able to figure out the RTCC stuff, if the forum is any indication. [21:17:22] I always envisioned it as NASSP 9 adding MCC support for Apollo 12-14 and NASSP 10 for 15-17 [21:22:02] now that you mention it, I think the old roadmap (sourceforge wiki) said something like that [21:25:56] that would be the logical order [21:26:05] NASSP 7 had Apollo 7 and 8 [21:26:22] then add full LM support [21:26:25] then H-missions [21:26:27] then J-missions [21:54:37] night! [16:21:40] hey [16:21:43] morning [16:22:11] I really want a scn file from thermocalc, the fact that he has an LGC TEMP light is bothering me [16:22:28] I havent seen that outside of testing and mismatched scns [16:23:28] that coupled with the o2 flow highs tells me his scn predates the current NASSP version [16:23:48] yeah, I'd like a look at it too [16:32:21] man, I am just not geting the results I want with my script.... [16:33:26] oh no [16:36:43] the script definitely does what I want it to...probably [16:47:26] ah ha. may have found it [16:47:45] new_internal_energy = ((mass-vapor_mass)*SPECIFICC_LIQ[substance]+mass*SPECIFICC_GAS[substance])*old_temp [16:48:06] should be [16:48:07] new_internal_energy = ((mass-vapor_mass)*SPECIFICC_LIQ[substance]+vapor_mass*SPECIFICC_GAS[substance])*old_temp [16:51:07] ah vapor mass [17:03:45] better, but cabin temps are too high, and CSM cryo systems are not behaving how they should [17:04:52] also keep in mind the "cheaty" CSM ECS as it heats the cabin and suits using boilers [17:11:33] both the CSM and LEM stabilized on new proper temps after a while, but that's what I was hoping to avoid. [17:38:42] hey [17:44:23] hey [18:03:11] LGC temp was the IMU heater cbs both off [18:03:27] O2 flow was time acceleration with the tunnel open [18:03:31] thankfully no underlying issues [18:06:28] interesting [18:06:45] accidentally opened those CBs during TLC? [18:08:40] not sure [18:09:02] I can't imagine it being a checklist error [18:09:10] but it should have been checked on both the entry cb chart and activation pwr up chart [18:09:25] I ran those to be sure, and it is correct both in text and in function if auto is used [18:10:27] I am just glad nothing broke internally haha...when I saw both O2 flow high and a temp light I started scrambling to what I might have broken :P [18:11:36] yeah I know the feeling [18:12:53] usually related to the MCC :D [18:13:54] temp light extinguishes right away when I put the breaker in [18:14:41] where is the IMU temp in the TM client? [18:14:45] is it the same as the PIPA? [18:15:17] I think the pages are done by telemetry ID [18:15:56] hmm [18:16:00] it would be on the GNC page [18:16:16] right I see PIPA temp there [18:17:17] its not changing [18:17:33] that might be fixed right now [18:17:56] no actually [18:18:01] double IMU::GetPIPATempF() [18:18:02] { [18:18:03] if (IMUCase) return KelvinToFahrenheit(IMUCase->GetTemp()); [18:18:04] [18:18:05] return 130.0; [18:18:05] } [18:18:06] No it went up when I put it in OPR [18:18:40] but it wasnt changing between opening and closing the STBY breaker at least on there [18:19:09] I think that might be the only temperature that is getting measured there [18:19:13] so PIPA temp = IMU temp [18:19:20] that is also what is used for the DSKY light [18:19:22] the IMUCase [18:20:17] ah ok [18:20:25] I guess its just not updating in the client [18:20:42] high bitrate? [18:21:27] I don't know all of this IMU thermal code, I think you added a bunch of it [18:22:00] oh you know what [18:22:05] the temp sensor [18:22:21] does it even get power without the OPR breaker [18:23:00] I think it doesn't actually [18:23:12] Hmm interesting [18:23:29] I will look [18:24:31] but I'm not seeing that being implemented [18:24:55] it looks directly at the radiator temperature [18:25:04] no CB needed to measure that right now [18:31:21] trying it in the same scenario now [18:31:29] OPR CB made the temp ris [18:31:31] rise* [18:31:43] but then I opened it again [18:31:54] and SBY breaker only, temperature seems to drop again [18:35:43] Yeah I have both open and the temp drops slowly [18:36:37] the two temps in the config [18:36:42] for the standby heater [18:36:46] are 126° and 130°F [18:36:59] does it have to drop to 126° and then it heats it up to 130°? [18:37:45] so if it doesn't drop to 126 then the standby heater wouldn't be on [18:37:55] but if the IMU is on it puts heat into the IMU case [18:38:03] right [18:38:11] where are those numbers from [18:38:16] LM-IMU-Heater 1 DC_DUMMY 109.0 109.0 TEMP 325.372 327.594 HYDRAULIC:LM-IMU-Case [18:38:20] the two temps [18:39:50] 126-130F [18:39:53] yeah [18:39:58] should be good enough [18:40:04] DSKY light goes on at 126° [18:40:55] huh [18:41:00] the temp is above that [18:41:02] but the light is on [18:41:08] is the logic for the light maybe wrong somehow [18:41:26] yeah thats what I am seeing [18:41:31] where is the logic for the light [18:42:09] IMU timestep [18:43:11] I am trying to figure out if it will light without the STBY breaker in [18:43:26] yeah [18:43:29] I implemented this [18:43:32] but I have no idea [18:43:36] maybe it's intentional [18:43:52] it looks like that hi and low limit gets power from the STBY breaker [18:44:52] temp alarm thermostat module assembly [18:44:58] gets power from the standby breaker [18:45:05] and the input bit is called "temp in limits" [18:46:44] so what happens if it doesnt have power [18:46:48] will the light be on or off lol [18:52:15] yeah that's confusing haha [18:52:44] "serves as on-off switch for temperature alarm thermostat" [18:53:03] so if STBY is pulled the thermostat wont set the bits [18:53:07] this is all MIT stuff, so we should have schematics [18:53:36] followup question, if the bit was set and then power was pulled, would it remain [18:53:58] morning! [18:54:04] ask Mike :D [18:54:48] yeah what's the question? [18:54:52] haha yes I like that [18:54:57] we are confused by the IMU temp input bit [18:55:08] LM specifically in this case [18:55:18] IMU standby heater circuit breaker is powering the thermostat for that [18:55:42] and the input bit is called "temp in limits" [18:55:55] so we wonder what happens if the breaker is pulled [18:56:09] would the light be always on [18:56:11] or always off [18:56:31] hmmm [18:56:55] everything here is happening in the PGNS [18:57:01] so we should be able to find out [18:57:28] yeah this is actually mostly an AGC hardware question [18:58:28] the fact that that is an input bit is mostly irrelevant, because that light has a direct hardware path to follow the input bit, even if the computer is standby [18:59:02] right which allows the TEMP light when the computer is powered down [18:59:03] so really it's, which direction does that discrete input float when the breaker is pulled (presumably towards zero) and what does the hardware do to the light with that input [18:59:07] yeah [18:59:13] oh the AOH has a pretty detailed page [18:59:46] LM-10 AOH Volume 1 [18:59:49] page 2.1-50 [19:00:30] although that still doesn't rule out that the input signal gets inversed haha [19:00:34] lol I am currently on 2.1-51 when you said that [19:00:39] great minds [19:01:20] although it does say on page 51 how it could be [19:01:58] so a discrete is provided during normal operation [19:02:01] yes [19:02:13] but if the temperature alarm module has no power [19:02:19] no signal I would think [19:02:21] would that still remain if the power is pulled [19:02:24] right [19:02:31] so without that signal the light goes on? [19:03:12] that's how I implemented it. Maybe it is correct. [19:03:17] AGC input wire is DE125, though circuit 12D in module A27 [19:03:18] I checked the malfunction checklist though [19:03:27] I would expect that to check the breaker [19:03:30] but it doesn't [19:03:40] if the TEMP light is on [19:04:43] do you ever open that breaker? [19:04:48] for any reason [19:04:56] D type input circuit is a voltage divider, that divides incoming discrete voltage by 11 before putting it into the digital logic [19:06:46] that gets inverted by a standby-powered gate in module A18 to form TEMPIN/ [19:08:06] oh god it's like the SCS control logic [19:08:10] and that goes into module A13, which combines it with the ouput bit that lets software turn the light on [19:08:13] inversion of inversions of inversions [19:08:38] yeah that weird input and output bit logic is in our code [19:08:46] we talked about it when that got implemented [19:08:50] if TEMPIN/ is high, then TMPCAU (the output) is high [19:09:04] I think 13 is the only mission to open the STBY breaker [19:09:15] TMPOUT (the output channel bit) can also turn the light on by going high [19:10:33] soooo [19:10:57] yeah if the input bit is 0 volts, then the TEMP light goes on, regardless of what software thinks (or if it's even running) [19:11:10] and presumably if a breaker is pulled, the input bit will go to 0 volts [19:11:41] yeah [19:11:52] so we might have it right then [19:12:08] would still like something to explicitely say "if you pull this breaker, that light will be oN" [19:13:00] I wonder if my LTA-8 procedures document would mention that [19:13:14] I'll have to look through it [19:15:56] but I think what you said almost confirms it [19:16:02] we should maybe check the chat logs [19:16:06] we surely talked about it [19:16:18] I'm sure I implemented it this way for a reason [19:17:18] my commit is from January 6th 2018 [19:19:02] found it in the log [19:19:07] when we talked about it [19:23:09] past Mike posted this [19:23:09] https://archive.org/details/acelectroniclmma00acel/page/n137/mode/2up?view=theater [19:26:19] but I'm not finding the definitive answer in our log either [19:31:01] hmm [19:43:40] I guess it's likely that we got it right [19:48:33] yeah I think that is the best assumption [20:17:31] good enough for me [20:32:30] todays topic, chasing a bug that isn't a bug [20:32:34] because I did that in the RTCC; too [20:33:04] optimum maneuver to change a 120x150 orbit into a 90x230 orbit [20:33:28] the optimum point apparently is when the true anomaly isn't changed during a maneuver [20:33:58] and it somhow didn't go into my head that a maneuver that has a DVZ component of 350 ft/s might not change the true anomaly [21:38:53] night! [01:39:44] haha, so I just tested an unedited scenerio...and it turns out my energy changes were unnecesary [01:49:57] I do not understand.... [14:49:50] hey [14:50:29] hey [14:51:24] I found the issue with my script. I was using the wrong value for "old" specific heat. [14:51:54] I only spent like 3 hours troubleshooting that... [15:03:15] Haha I hate that [15:03:26] So what exactly does this do/change [15:07:42] the script changes the internal energy of every substance so that the temperature stays the same with the new specific heats [15:08:09] it processes a whole directory of scenarios at once [15:09:10] Oh its not a specific heat change for phase changes? [15:13:13] heat of vaporization was changed in the last update. this one adjust values for liquids and adds seperate values for gases [16:12:39] so, rather the looking like this https://www.researchgate.net/profile/Daniel-Banuti/publication/279381888/figure/fig11/AS:614282492391471@1523467767924/Oxygen-density-and-specific-heat-capacity-for-sub-5-MPa-and-supercritical-7-and-10.png [16:14:41] the energy that goes into a substance when it crosses its boiling point happens at a single discontinuity, but energy is still conserved [16:15:26] and from an accuracy standpoint, it's much less bad than it used to be :) [17:29:23] morning! [17:35:09] good morning [17:38:13] what's up? [17:39:02] oh just confusing myself with my own code again, haha. you? [17:39:28] I think I've mostly recovered from my own bout of self-confusion from this weekend :D [17:39:46] making good progress on the rope cycle visualizer website, and should have it online tonight or tomorrow I think [17:40:10] oh awesome! [17:40:16] I already can display everything I want with it, just not in a way that is tied to a UI yet [19:16:51] good evening [19:19:58] hey [19:21:05] did you want to work on the standby mode fix? [19:22:43] Yes, got some documentation to finish here and then I'll take a look. [19:23:33] ah good, I wasn't sure who of us was going to tackle that [19:26:05] Yeah, sorry about that. I started my graduation internship last week, still getting adjusted to it. Squeezing in time for fun stuff is a bit challenging at the moment. All goes well I walk away with a diploma late April. :) [19:26:56] awesome [19:27:45] well all my projects these days have the threshold of "is there any chance it will break the MCC?". That makes them take a damn long time... [19:31:45] I can't push some buggy code and let users find the issues. Who am I, a modern video game developer? :D [19:36:07] haha [19:55:06] hey guys [20:14:06] hey Matt [20:30:10] the specific heat update should be ready some time this week [20:31:57] just need to fix a dumb mistake in my scenario update script and do some testing with my fuel cell branch [20:32:44] sounds good