[13:48:31] NASSP Logging has been started by n7275 [13:48:33] morning! [13:49:51] good morning [14:22:27] how's it going with Apollo 9? [14:22:59] About to polish up the TPI procedures and fly it [14:57:29] trying to figure out the TPI transfer time to use in the AGS [15:04:14] looks like approx 35 minutes should work [15:29:00] sweet it found a matching solution [16:16:01] nice [16:17:31] TPI burned well now for midcourses [16:25:07] in practice, where would that 35 minute time come from, RTCC? [16:33:29] yeah [16:33:47] basically its the time from burning TPI to rendezvous [16:33:56] based on the flight plan its 30-35 minutes [16:34:16] ahh, okay [17:11:48] Spider and Gumdrop are hanging out :) [17:12:05] lots of small changes here and there but the procedure went very well with a few edits [17:12:23] the switching to the CM was a challenge but I made it an "optional" comment [17:12:35] P76 and marking kept that LM right in the sextant [17:19:41] great [17:21:39] I think we had this topic before [17:21:43] not sure what we concluded [17:22:24] the first thing I find, the circuit breaker diagram in the AOH, says the breakers are needed for switching the ascent batteries off [17:23:28] yeah we had this before for sure [17:23:39] and the switching off was what we used [17:23:56] however you also need it for the deadface flag apparently [17:26:25] yeah the deadface switch gets power from the ascent ECA control CBs [17:27:19] I am just trying to figure out procedurally when the asc eca cont breakers would be turned on [17:27:32] I would think when the ascent batteries are put online but its unclear [17:28:53] yeah [17:29:13] I think we also need to revisit the battery voltages. Having seen it on telemetry the voltages are too high when under load [17:29:55] is ASC ECA CONT not used in the rendezvous activation checklist? [17:30:15] not after the check I guess [17:31:55] yeah they are open on the final cb activation [17:38:15] n7275, I see your PR [17:41:11] yeah agreed on the battery [17:41:24] theres a lot of bal loads opening and closing around burns as well [17:41:48] and I still ran into DC BUS MA's with one open towards the end [17:42:13] loads in general need looked at [17:48:11] hey [17:48:45] https://i.imgur.com/ReTFpXH.png [17:48:47] hey Alex [17:54:08] hmm Telemetry? [17:54:11] yep [17:54:22] I am creating one for the LM [17:54:29] awesome [17:54:41] everything but LGC and AEA is essentially done, although a bit buggy still [17:59:39] hey Alex have you flown an LM ascent stage lately? :D [18:05:11] oh, rcflyinghokie, how did you like the CDH burn with the APS [18:05:22] it was short [18:05:36] haha true [18:06:09] one nice thing with the center of gravity is that it is better aligned with the RCS [18:06:28] so you aren't causing a large attitude rate anymore with translation [18:09:38] still gives me a good excursion when I thrust [18:10:12] ah, I guess that is only really true with a near empty ascent stage [18:10:27] bot the heavy one the CG is below the RCS thrusters [18:10:29] for* [18:14:53] yeah I have a heavy one still haha [18:17:38] those final translations during braking rocked the boat a bit [18:21:25] yeah but we had that before. Except before the CG was too high up [18:24:36] ok LM active docking time [18:24:48] orientations seem like they worked nicely [18:25:33] indy91, not yet but Ill give it a try! [18:28:30] rcflyinghokie, I saw you mentioning the LM cabin temps recently, any more progress with that? [18:35:16] I have just been flying through to gauge the state [18:35:20] I have ideas [18:36:27] fun fact LM-3 actually had 2 cabin fans and a HX and a cabin temp controller [18:40:40] but I think the first line of defense is going to be letting the cabin get rid of more heat to space [19:07:13] Visual Studio is getting really slow with so many things to display :D [19:13:13] hahaha I bet! [19:13:24] which CPU are you running? [19:17:28] uhh, roughly 7 year old, overclockable i5 [19:18:35] but I think the CPU is usually my bottleneck [19:18:44] also for NASSP [19:27:52] I just popped in a Ryzen 5900x [19:28:03] certainly makes things snappier haha [19:35:27] that can probably even handle our CSM main panel [19:39:42] @indy91, regarding my PR, I'm fairly confident I haven't broken anything with the new code, but it's probably worth someone else running that code a bit and making sure nothing weird happens with temperature [20:00:16] yeah I'm a bit scared of that radiator change [20:00:26] I'll fly half a mission with your branch I think [20:07:46] afternoon! [20:15:07] hey Mike [20:17:41] look at this: https://i.imgur.com/ReTFpXH.png [20:19:09] ooo, nice! [20:21:33] something is weird with the DSKY still [20:21:47] see that XX in R1. It uses XX if the character code isn't recognized [20:22:00] I just copy&pasted the code from the CSM telemetry client [20:49:00] @indy91, awesome, let me know how it goes. [21:08:29] that TM looks awesome [22:06:26] I am updating all the APS burn to depletion procedures [22:06:55] do I still have to be MCC with the P42 and such? [22:22:57] yeah [22:23:30] I'll implement that being automated eventually, but it isn't right now [22:23:35] night! [01:07:11] .tell indy91 so looks like the crew left ENG ARM - OFF before they closed out the LM...is this a mistake or did MCC have the ability to work around it? [13:18:16] good morning [13:20:00] hey [13:20:16] ascent engine arming assembly [13:22:12] starting to look at your PR, I have some suggestions for the radiator timestep [13:22:28] we have a bunch of them, so it wouldn't hurt to make it a bit more efficient [13:23:28] AirHeatTransferCoefficient should probably be defined in the radiator constructor and not every time in the refresh function [13:23:38] and then for the density calculations, how about something like this [13:23:48] if (density = parent->Vessel->GetAtmDensity()) [13:24:00] because we will be in space most of the time [13:24:25] so that saves the density in density [13:24:34] and also is a check if it contains something other than 0 [13:24:42] so if that is true, do the density calculations [13:24:52] otherwise set Qc to 0 [13:25:08] and also the density term for Qr [13:25:42] that's a good idea [13:27:34] I guess with that the function looks, in vacuum, basically the same as before except for the check on density, right? [13:28:22] I still want to give it a bunch of testing, but understanding how that function actually works I'm not so wary anymore [13:28:49] because even the current version only affects the behavior in the atmosphere, which is a much more contained issue [13:32:06] yes [13:34:20] hmm, I've only tested this on the NRLMSISE atmosphere model. I should probably test it on the others too. although it's probably the hottest at high altitude, I'd imagine [13:35:55] density is absurdly low up there though, so unlikely to matter [13:38:21] hmm right [13:38:27] I have never changed atmosphere models [13:38:44] I'm sure it will be fine [13:38:57] density might be nonzero, but tiny [13:39:02] back in a bit [14:02:50] back [14:44:12] did any of the recent RTCC changes effect Apollo 7? [14:48:16] only in a good way I hope [14:48:27] I fixed a possible CTD caused by the MCC for Apollo 7 [14:48:39] 18 days ago [14:52:01] I'm re-flying it. at least up to the rendezvous [14:52:51] iirc the mission sceneriaos are a bit outdated [14:52:55] yep [15:12:49] made up to LOX dump last night. I but I can do a big chunk of it this weekend [15:14:47] flying 7 for test the fuel cell stuff? [15:14:51] testing* [15:18:59] partially. mostly just because I wanted to [15:21:05] need a refresher. if we end up not merging my branch, than I wont commit these new scenarios [15:21:56] oh I'm sure we will merge it, just a question how much needs to be changed still [15:22:50] I'll look in detail at the other stuff as well [15:23:07] the radiator refresh changes are just for efficiency of course [15:25:20] when I fly a mission what should I look at specifically? [15:25:27] FC temps and voltages? [15:30:32] yeah, that and periodically checking the saved values for the radiator temps in the scenario file [15:30:40] hey [15:30:53] wasn't able to break those [15:30:58] Alex! [15:31:09] https://drive.google.com/file/d/1mrj1cjby13tlRGKCHfl2ihiBeUW4jSdk/view?usp=drivesdk [15:32:12] hey Alex [15:32:28] poorly drawn graph, but those are what the databook says the steady state temperatures are [15:33:00] ...in kelvens...why Matt... [15:33:14] I'll re plot it later [15:33:40] how do I read that graph [15:34:02] with a specific voltage and current I should get the specified temperature? [15:34:31] or do I go current->temperature->volts? [15:37:20] in prelaunch I definitely get fairly low temps, although in the limit [15:39:02] temperature(current, voltage) is how it would look as a function [15:39:34] right [15:40:11] I think I need to add the GSE heaters to take the burden off the inline heaters while on the pad [15:41:13] I think GSE also forces the radiator bypass on [15:42:13] with those, in my other branch I was able to run a quasi-startup test [15:42:51] eventually we can put GSE in the mobile launcher, but not quite yet [15:44:08] what powers the inline heaters? [15:46:47] the inline heaters are powered directly off of the FC terminals [15:47:14] ah makes sense [15:47:26] had difficulty finding them in the Systems Handbook, but I had just found them [15:48:56] the GSE heaters have no internal electrical connections to the CSM [15:50:12] they are in the new CSM schematics that were added to virtualagc a month or so ago [15:50:50] dont think they're in any of the systems handbooks though [15:51:07] ah interesting [15:51:18] that tends to be the case, also for the Saturn Systems Handbook [15:51:39] that is missing a very important relay in the EDS [15:51:44] all engines running [15:51:48] you can't launch without that [15:51:58] but it's only relevant before liftoff and not in flight [15:52:05] so it's not in the Systems Handbook [15:52:29] and no onboard function, just for the electrical support equipment on the ground [15:53:48] yeah, just a plug on the outside :) [16:04:51] about the FC radiators [16:04:58] there is 8 radiators? [16:05:01] But for all FCs? [16:05:52] FUELCELLRADIATOR1 375.589438 6.800000 [16:05:59] FUELCELLRADIATOR8 365.535782 6.800000 [16:06:05] that's the temperature range [16:06:08] T-30 seconds [16:06:13] goes down from 1 to 8 [16:07:27] yeah that's a bit warm [16:08:20] 10 W/m²K probably isnt enough [16:09:20] I bet it's closer to 25ish with all the convection and wind going on around the vehicle [16:10:53] those temps are on the system test meter right? [16:11:01] and yes. 8 radiators. 3 seperate coolant loops [16:11:19] hmmm [16:12:24] I think it's just "inlet" and "outlet" [16:12:37] which I haven't touched in this branch yet [16:13:06] test meter has FC 1/2/3 RAD OUT TEMP [16:16:26] which comes from the cooling temperature for us [16:16:39] which takes the average of the radiators as the temperature? [16:17:10] okay. yeah. haven't modified that in this branch yet. [16:24:35] still want to do cooling with a coolant loop, at some point [16:28:52] I've been giving that aspect of it a lot of thought recently [16:29:30] I should say: I've been giving the hydraulic aspect of systems SDK a lot of thought recently [16:29:49] is that its own glyocl loop or is it connected to the main loop? [16:34:11] post insertion [16:34:12] FUELCELLRADIATOR1 321.363692 6.800000 [16:34:17] FUELCELLRADIATOR8 307.889585 6.800000 [16:36:57] it's a separate loop [16:37:22] that's more plausible [16:38:46] 3 sepeater loops, one for each fuel cell. common radiators though [16:40:04] if you disconnect one cell, it will receive some non-zero heating from the other coolant loops via conduction through the radiators [16:42:02] right [16:44:17] so, what we actually have with the hSystems is a veeerry rudimentary 1d CFD solver, just with a flow defined by Hagen-Poiseuille equation and with an euler solver [16:46:42] so analyzing it in that way, looking at convergence/Courant number could potentially provide us with answers on the direct cause of some of our instability issues [16:48:46] I think it's just small tanks and large valves, euler breaks down when you are moving large parts of the contents of a tank per timestep [16:49:04] because there is more flow than you would actually get [16:49:20] it's an inherent problem of simulating the system this way [16:50:24] oh absolutely [16:51:37] I'm just saying, there's probably a way to know, a preori, what our absolute maximum allowable timestep is. [16:52:07] right [16:52:12] but what can we do about it? [16:52:37] we can make it run more sub-steps per timestep [16:53:04] but that would just make performance even worse [16:57:40] possibly nothing, but it would draw a clear distinction on what new systems can, and cannot be implemented directly without the need for extensive testing [16:58:04] hmm, right [17:03:55] going to give the DSKY buttons some animations today [17:07:21] nice [17:08:04] alex, what are your eventual plans for optics in the VCs? [17:10:53] good question, for now I am thinking of just use the already present 2D panel for the actual optics windows (SCT,SXT,AOT) [17:11:13] with maybe a click spot from the VC to switch to them [17:11:53] maybe eventually I can figure out how to make an actual VC version of the optics views but I am not sure about how to do that yet [17:18:42] probably the best solution for now. [17:19:02] yeah I think so [17:19:26] I cant think of anything that wouldn't be horrifyingly hacky or performance murdering [17:19:42] haha [17:20:13] such is the way when you're stuck with a graphics API from 2002... [17:20:15] in any event, the optics views are not really needed to be in 3D to be honest [17:20:42] right [19:05:04] alright DSKY key animations are done [19:13:59] morning! [19:18:50] sweet! [19:21:34] good afternoon [19:22:21] yo [19:22:50] such a busy Friday haha [19:26:43] hey Ryan [19:30:45] hello hello [19:38:59] so how on earth was the APS armed for the APS burn to depletion [19:39:26] looks like they exited the LM (based on the procedures) with ENG ARM - OFF [19:39:53] did LM-3's DFI or whatever have enough capability to do something like that? [19:41:34] Thats what i was wondering [19:42:28] DFI and R&D instrumentation was all left powered up [19:43:02] or wait, the AEAA was a thing right? Ascent Engine Arming Assembly? [19:43:10] or was that a thing in all LMs [19:43:54] all LMs as far as I know [19:44:18] An abbreviated version of the mission programmer is used for the LM-3 mission. The LM-3 mission programmer consists of only two assemblies: the digital command assembly (DCA) and the ascent engine arming assembly (AEAA). It provides a means of arming the ascent engine when the LM is unmanned. The ascent engine will be armed via uplink (real-time) commands from MSFN. [19:44:49] LM-3 operations handbook, pdf page 214 goes into details [19:48:12] ahhh [19:48:35] I have the sys handbook not the ops [19:48:57] so it is the programmer like LM-1 [19:49:31] http://www.ibiblio.org/apollo/Documents/LM-3_Apollo_Operations_Handbook_Vol_I.pdf [19:49:33] yup [19:49:43] ah hah thanks! [19:50:00] sure thing :D [19:50:38] I got both the LM-3 AOH and Systems Handbook in the same auction... mostly because I wanted any copy of each, and for whatever reason the LM-3 ones went for way less than the others [19:51:00] and I gotta say, I'm quite happy with how particularly useful they have turned out to be, with LM-3 uniqueness and Sundance, haha [19:52:06] Yeah, I just hope we can model LM-3 [19:52:11] with all its differences [19:52:53] and regarding that SV issue we saw last night, I can confirm the RTCC in the LM will not give a GET automatically in other scns [19:53:00] *RTCC MFD [19:53:23] by design, or due to a bug? [19:55:45] I mean, the time auto populates to current time in the CSM when you bring it up [19:56:00] hey [19:56:24] Apollo 9 and 10 had AEAAs [19:56:34] on 9 they could only arm the APS remotely with it [19:56:41] on 10 they could also switch from PGNS to AGS control [19:56:47] I haven't implemented it yet [19:57:11] but I know how commands are sent to it thanks to the LM-3 Systems Handbook [19:57:49] what is the RTCC issue exactly? [19:58:53] so when you bring up the uplinks page and a SV update, the GET remains all balls in the LM, but it loads the current time in the CSM [19:59:05] interesting [19:59:36] when you open the SV page it does this [19:59:37] G->SVDesiredGET = OrbMech::GETfromMJD(oapiGetSimMJD(), GC->rtcc->CalcGETBase()); [20:00:04] wonder why its not doing it in the LM [20:00:51] Apollo 7 and 9 MCC are still a bit in a halfway state regarding RTCC initialization [20:01:07] I wonder if it is something with that [20:01:43] but yeah, the page needs always an input GET [20:01:47] happened on 11 [20:01:51] that has changed at some point, 1-2 years ago [20:01:55] hmm ok [20:02:06] current scenarios? [20:02:15] it was tried in the 11 liftoff scn [20:02:23] ok [20:02:33] I have the same results in 9 [20:02:36] before lunar liftoff? [20:02:41] yes [20:02:42] or Earth launch [20:02:43] ok [20:03:39] I can't confirm that [20:04:01] I open before lunar liftoff, open RTCC MFD, go to SV uplink page [20:04:06] and I have the current GET there [20:04:46] yeah same here [20:05:00] I was walking someone through rendezvous last night thats where I noticed it [20:05:07] maybe he didnt have a current version [20:05:14] who? [20:05:29] A gentlemen in the spaceflight discord [20:05:35] ah [20:05:46] mike and I were watching his rendezvous and noticed it there [20:05:56] then I pulled up my 9 mission saw the same [20:06:08] ok, I should be able to replicate it in your scenario though [20:06:13] yes [20:06:25] and there it might be a RTCC initialization thing [20:06:37] the MCC doesn't do it yet for Apollo 9 [20:06:50] so in theory the RTCC MFD should be doing it when you open then MFD for the first time [20:06:58] but that could be buggy [20:07:13] and also, all the RTCC parameters are stored in the MCC vessel [20:07:17] I just exited and reloaded now I have a time [20:07:22] 5 minutes ago I did not [20:07:38] so if the RTCC MFD for some reason can't communicate with the MCC, big trouble [20:07:40] that might be the case [20:08:07] oh interesting [20:08:21] it's for permanent RTCC MFD saving [20:08:25] so if I load that page first in the LM, then go to the CSM, the time is 0 in the CSM [20:08:43] ooh [20:08:51] I think I know why [20:08:53] but if I go back and back into the SV page its there [20:09:11] SVDesiredGET is a vessel wide parameter [20:09:21] so gets used by all RTCC MFDs open in that specific vessel [20:09:26] but not other ones [20:09:45] and I guess the MFD opens on that page by default in the CSM if you had it open in the LM [20:09:54] never really understood how :D [20:10:02] but you never press the button to go to that page [20:10:05] in the CSM [20:10:25] it only calculates the time if you press the button to go the page [20:10:34] ahh ok [20:11:12] so going back and to that page again gives it a GET [20:11:51] yep [20:11:57] I can make that a global variable [20:12:02] if that is better [20:12:21] in any case, that time gets used for the SV calculation [20:12:24] and if it's all zero [20:12:32] AGC won't be too happy I guess [20:13:27] what that the whole issue? [20:13:29] was* [20:14:19] indy91, you mentioned I think there was an updated procedure if initializing the MPT? [20:14:34] yes. For the state vector [20:14:39] the "TUP" button is gone it seems [20:14:44] opens a new page, the vector panel summary [20:14:45] right [20:14:52] the RTCC MFD manual has a section on it [20:15:00] ah ok [20:16:04] yeah didnt realize we could get a time by backing out and going forward [20:16:09] but the quick process now is to use the DC button [20:16:12] thought it was locked on 0 [20:16:17] that is the new "ground tracking" solution [20:16:22] left side CSM, right side LM [20:16:45] rcflyinghokie, you can also input a GET or is that broken? [20:17:50] I think I changed it because the real RTCC input for this also always requires an input GET [20:18:06] in other places you could leave the input out and it would use the current GMT [20:18:18] but not for the state vector [20:18:26] yeah input works fine [20:19:21] and I kept that method for calculating a GET around when you open the page [20:19:47] is the MPT on/off state now saved in the MCC? [20:20:20] rcflyinghokie, if I make that a global variable then it would also update the GET in the CSM if it gets changed in the LM [20:20:28] is that any better? [20:20:57] AlexB_88, no that's still saved in the MFD [20:21:01] but only that flag [20:21:16] I guess you have to re-enable it if you had a scenario with the MFD closed [20:21:46] oh and the MPT is a bit broken right now when it comes to lunar surface handling [20:21:47] yeah that might be more trouble [20:22:58] I need to look into this logic Orbiter uses for storing the MFD state [20:23:20] must be that the RecallStatus function gets used globally [20:23:33] I have it save and restore the current screen there [20:24:05] I think if I remove that then it wouldn't even open the same page again if you close and open the same MFD in the same vessel though [20:25:02] so probably more of an Orbiter issue than RTCC MFD actually, but I want to look into that a bit [20:27:38] right [20:28:09] I think a side-project I am going to start soon is an MCC "virtual cockpit" [20:28:43] awesome [20:28:46] basically with a bunch of MFD's to look like consoles [20:29:39] it wont be anything too fancy for now [20:29:40] RTCC MFD manual lies, AGS state vectors can be read from the AEA memory to the vector panel summary [20:30:04] but it requires that the AGS REFSMMAT is set correctly, for which there is no nice way yet [20:30:19] only MED G00. At least there is a button for that on the REFSMMAT page to move REFSMMATs around [20:30:41] and there is no nice way to update the LVDC GRR time either [20:30:54] needed for LVDC state vectors to be accurate in the RTCC MFD [20:31:18] if you launch at the normal time it should be close though [20:32:38] but you can do the TLI go/no go checks now [20:32:48] with vector panel summary + vector comparison display [20:33:34] check how much downrange error the LVDC state vector has at a specific time [20:34:19] and vector comparison display can even be used for calculation the Noun 69 for lunar landings [20:34:39] but I haven't figured out yet which sign to use :D [20:36:14] awesome [20:37:39] when I make the MCC consoles, I wonder if I can make the RTCC MFD always be open by default on them [20:38:10] a bit like how SSU has all the MFDs on at scenario start [20:39:11] yeah, I think I did something like that with the LCC [20:39:44] hmm, or was that just that the very basic LCC MFD could only be used by the LCC... [20:40:17] Would your MCC be run from the MCCVessel? [20:40:23] Or be a separate MOCR vessel [20:41:52] can you somehow make custom MFDs that don't have 1:1 aspect ratio [20:42:00] how is SSU handling that [20:42:01] I was thinking just give a VC to MCCVessel [20:42:14] yeah I guess that makes sense [20:42:48] which would mean we should be able to switch to the MCCVessel with the F3 menu [20:42:54] but we cant right now [20:43:09]