[13:59:43] NASSP Logging has been started by n7275 [13:59:45] morning! [14:05:25] hey [14:05:55] morning [14:09:52] hey Ryan [14:19:11] I am really getting excited about making this THC work [14:19:24] all the components minus the T handle should be here tomorrow [14:19:58] and I am considering adding the arm switch and LM throttle to it now since I got a big project box lol [14:22:41] and with VESIM it should even be possible to make it work in NASSP [14:23:48] exactly [14:24:01] it would just be a USB Game Controller via an arduino controller [14:27:29] Once I get the geometry of the fwd/aft part down, the rest will be easy [14:27:39] I even think I have a solution for the CCW/CW switch [14:33:46] hmm, so one issue with making the LM CG position mission specific is the data I have [14:34:05] inconsistent data? [14:34:08] it's a quadratic function of mass [14:34:20] I have data for 10776.6 lbs, lunar liftoff [14:34:27] 5928.6 lbs, insertion [14:34:41] but then only slightly different values for CSI and docking [14:34:47] and most of that will be RCS usage [14:35:07] doesn't make a very nice or accurate quadatic function for e.g. mid ascent [14:35:28] because the data points for insertion and later are so close together in mass [14:38:37] hmm thats tough [14:39:09] would the position of the tanks in the cfg file be any use if they were in the correct locations? [14:41:28] in the mission file? Were they mission specific? Different for Apollo 15+? [14:41:47] so for the ascent stage I am calculating it purely as a function of total mass right now [14:42:10] for the descent stage I have it set up so it's only along one axis, but as a function of the DPS propellant mass [14:42:20] with the right propellant tank location [14:42:41] the Data Book has good locations for every tank [14:42:46] even water tanks [14:42:57] the cfg file isnt mission specific, but I suppose we could make them mission specific [14:43:10] that might help later with changing small things between LMs [14:43:12] oh you meant the systems config file [14:43:16] yeah [14:43:17] not the mission file [14:43:21] yes [14:43:28] hmm [14:43:40] that's too detailed for now [14:43:48] It would add more files but it might be useful instead of commenting out things [14:43:50] and it doesn't have DPS, APS and RCS tank locations or anything [14:44:05] no but it could [14:44:10] just a thought for the future [14:44:11] well eventually sure [14:44:31] yeah when it gets really detailed then it probably makes sense to use those locations to calculate mass [14:44:53] I think for now the most I would consider is DPS, APS, RCS tank locations. And astronauts [14:45:12] it should change the CG when the astronauts aren't in the LM [14:45:23] for LM-1 and APS to depletion burns for example [14:45:32] or even docked burns prior to undocking [14:46:14] Absolutely [14:50:57] makes it more difficult to get the same result for the CG location though [14:51:10] have to consider all those masses, astronauts, RCS usage etc. [14:52:29] ideally we have one calculation that can take all those points and masses into account [14:52:47] yeah, that would be one of my endless MATLAB scripts [14:53:46] right now that takes a table from the Operational Data Book and converts it into the coefficients for the NASSP code and a bunch of graphs [14:54:05] but I can play around with taking into account all those individual masses [14:54:24] and then the "rest LM" CG would be calculated [14:55:59] googles "Neil Armstrong weight". [14:59:46] either they used preliminary or simplified calculations or they balanced the LM right, but for LM-10 and 11 the y-axis CG location stays constant throughout the ascent [15:00:06] so they get a smaller roll moment and it doesn't grow much [15:01:54] let me know if you want me to try adding those CG points and propellant tanks to the cfg, at least as a starting point [15:03:54] don't think that will be necessary. I'll just use the CG locations the MIT hybrid simulator and the Operational Data Book used. [15:05:17] using the systems config for that will come much later [15:05:18] ok [17:20:51] ok let's see what LM-10 does with the right center of gravity [17:21:25] about the only thing I didn't like about that update, transients at liftoff for some LMs with a padload for the pitch moment that was a bit off [17:34:01] hmm should I play out the planned EVA or the abridged one? [17:34:10] I am thinking for this, the abridged would be just fine [17:35:17] is that a separate part of the EVA checklist or so? [17:36:13] well the eva checklist has the whole planned procedure of course [17:36:36] but the actual one was a 45 minute, with no EVT [17:36:41] hmm right [17:36:51] well generally we try to simulate the planned missions [17:36:55] yeah [17:36:58] but of course there is not much to do during EVA [17:37:11] exactly my dilemma [17:37:21] we actually have a separate class for on-orbit EVA I believe [17:37:26] have to take a look at that some time [17:37:41] ok well in the mean time I will just write out the whole thing [17:37:53] easier to cut it short than add all the stuff later [17:38:21] I'd be fine to use the shorter version for EVA as we don't properly simulate that yet [17:39:11] do what seems right [17:39:28] hmm, so on this Apollo 15 ascent [17:39:45] you get the opposite affect than liftoff at cutoff [17:39:55] the CG has moved to the point where the APS points through it [17:39:57] and then beyond it [17:40:10] so at cutoff there is an expected pitch acceleration of 4.5°/s^2 [17:40:12] so quite a bit [17:40:29] and guess what my residuals were from the ascent. +00001, +00001, +00001 [17:40:35] Luminary 1E is doing something right... [17:40:41] oh wow [17:40:48] the attitude rates were quite large at the end [17:40:54] and it still did that [17:41:38] but there is no wonder that the LM DAP looks so different than the CSM if it needs to deal with these offset CGs [17:41:53] absolutely [17:44:00] and it was even worse than on the real mission with the CG. I guess this ascent stage is a bit lighter than the real one was on ascent [17:44:08] missing some moon rocks among other things [17:52:25] Yeah I would think so [18:25:26] morning! [18:32:26] hey Mike [18:40:04] what's up? [18:41:12] I'm impressed by the DAP in Luminary 1E [18:42:39] achieving a very accurate insertion from powered ascent despite everything being quite dynamic near cutoff [18:43:10] for Apollo 11 the pitch moment of the APS was larger at liftoff and near zero at cutoff [18:43:35] for Apollo 15 however the angular acceleration is getting large again near cutoff [18:44:53] I'm less impressed by the spike in pitch rate at liftoff, for some reason I don't have that with Apollo 11 [18:46:54] nice [18:47:01] and that spike isn't expected for 15? [18:47:07] I'm not sure [18:47:39] maybe it's letting the stage do its thing without firing the RCS for a moment [18:47:46] to better measure the angular acceleration? [18:47:49] not sure [18:48:01] could also be something with the padload in this older scenario [18:54:17] but it's not too big of a deal [18:54:24] one spike going up to 5°/s [18:54:36] fairly quickly recovers [19:27:22] https://www.youtube.com/watch?v=cfMXBn1ibQc [19:27:41] alternative title: R29 struggling really hard [19:27:59] that's the RR powered flight designate routine [19:30:08] R29 got deleted for 14 and later, right? [19:30:34] yep [19:30:38] was never tried [19:30:45] it used to work great in NASSP [19:30:52] now with these new dynamics... it has problems [19:30:57] hehehehe [19:31:02] man that is a lot of wobble [19:31:11] could be our RR loosing lock too easily [19:33:39] I've looked at every document with attitude and attitude rate data there is [19:33:44] this is very close to how it was [19:35:36] that's super interesting :D [19:36:01] very different from the smoothness of descent, haha [19:36:19] the thrusters for pitch aren't firing at the same time [19:36:29] so whenever it wants you to pitch down it also causes roll [19:36:43] that causes the wobble [19:38:41] If the RR tracking gains need work, I can work on those [19:39:02] sure [19:39:08] David Scott calls it the "PGNS fuel saving program" in the Apollo 15 technical debriefing [19:39:22] under AGS control it will try to keep in attitude and attitude rate deadbands [19:39:26] so it fires all the time [19:39:29] short bursts [19:43:46] https://i.imgur.com/c9ny1gg.png [19:43:50] Apollo 12 pitchover [19:43:56] lower half shows the pitchrate [19:44:07] a lot of up and down haha [19:44:22] I'd be very interested to see how the AGC responds to thruster failure indications now that you have these dynamics modeled [19:45:04] well thruster failure for the LGC is if I switch off a thruster pair manually [19:45:07] I can do that :D [19:45:35] most of the time it only fires 1 or 2 thrusters in an axis [19:45:52] so any one thruster pair failing shouldn't cause any problems [19:46:21] for the AGS you might need to quickly switch balanced couples back on [19:47:04] but there are probably some quite interesting cases with multiple thruster pairs failing [19:47:20] DAP won't have fun with those, although it should still be able to deal with some bad ones [20:06:29] actually, more interesting would be an undetected jet failure [20:06:46] so the test case is: Pull the TCA breaker for one of the downward firing jets in the back [20:06:49] see how it behaves [20:07:01] then switch the thruster pair off so that the LGC knows about it [20:07:06] and see how much better it behaves [20:07:10] I'll try that [20:07:33] :D [20:14:49] I'll try early in the ascent where the pitch moment is the worst [20:17:13] so I switched off the right, downward firing thruster [20:17:30] when it tries to use that there is a fairly large attitude excursion [20:18:09] it recovers, but when it relies on that jet working it's not so pretty for a moment [20:18:30] when the LGC knows about it it just uses the forward, left upward firing jet [20:18:43] together with the left, rear downward firing one [20:19:18] awesome! [20:22:25] there is a ROUGHLAW mode that is kicking in when the attitude or attitude rate error becomes large [20:26:04] probably helps with those excursions [21:56:59] hmmm so I had a d3d9 crash and now whenever I load I get a checklistmfd error causing ctd [21:57:08] i cannot figure out whats causing it [21:58:42] whoa, a bunch of cells are corrupt [21:58:53] "1+A128:K129 [21:58:54] " is in random cells [22:01:14] yep that was it....weird [22:06:56] yeah the Checklist MFD can do that [22:07:31] when you open an old scenario where the current checklist was longer than it is now then it will try to access a cell that doesn't exist and it crashes every time as well [22:10:23] night! [15:05:23] good afternoon [15:10:19] good morning [15:10:39] 9's rendezvous checklists have all been added and updated and flown [15:11:17] I also reduced the cabin fan heat by half as an experiment, I want to revisit those CB heat loads as I am curious if all that heat should be dumped into the cabin or elsewhere [15:13:31] I also had a question I cannot seem to figure out....regarding the cabin repress in the LM...I am wondering if getting a MA is normal when switching the valve from manual to auto when both pressure regs are in cabin and the repress cb is in. Its like it trips the CABIN light for a split second or something but I dont know if thats correct in that case [15:15:27] going from close to auto doesnt trip it, but manual to auto does [15:15:46] hmm [15:16:33] it seems like it still senses it open for a second [15:16:40] even though in auto it should be closed [15:16:47] (cabin is pressurized) [15:17:15] https://www.dropbox.com/s/vor4aulqceipxe3/Apollo%209%20MCC%20-%20EVA%20Day%20Repress%20MA.scn?dl=0 [15:17:20] if you want a quick test [15:18:39] so the condition for the cabin light is [15:18:47] cabin repress not in manual [15:18:54] repress valve electrically open [15:19:05] could be that there is some delay [15:19:09] for one timestep maybe? [15:19:19] where it senses the switch in Auto [15:19:22] and repress valve still open [15:19:24] or something [15:20:19] thats exactly what I am thinking [15:21:02] if (lem->scera2.GetVoltage(3, 8) > 2.5 && lem->CabinRepressValveSwitch.GetState() != 0) [15:21:18] SCEA might be delayed by one timestep [15:21:32] hmm, but I think that logic should actually use the SCEA for the switch as well [15:22:01] You mean delivering the 1 or zero through the gate? [15:22:04] yeah [15:22:12] the Systems Handbook has that coming from SC1 [15:22:15] yep [15:22:21] if both are from the SCEA there should be no delay [15:23:00] don't think we have that in the SCEA though [15:23:07] have to check which signal that is exactly [15:25:22] Systems Handbook doesn't have it under ECS instrumentation [15:25:31] but maybe that is because it's not used for telemetry [15:26:35] yeah I cant find it either [15:28:07] so we have to dig really deep [15:28:26] LM elementary functional diagrams it is [15:28:59] yeah it shows SCERA #1 [15:29:13] 20A18 [15:29:34] but which channel is that... [15:30:31] is that in one of the handbooks? [15:31:07] AOH even gives a telemetry ID for this, maybe that wasn't the case on all LMs [15:32:30] oh, haha, 20A18 is actually the designation for SCERA 1 and not that specific measurement [15:32:43] ahh [15:32:45] those kind of names are used in the PCM as well [15:33:56] so we have of course the repress electronics which is just the relay [15:34:11] the elementary functional diagrams even show the connector and pin numbers. Might be possible to derive it through that, I hope I don't have to... [15:35:24] the AOH doesn't have it [15:35:32] don't I have any complete SCEA list somewhere... [15:36:02] would it be reading one of the relays? [15:38:11] no, the functional diagrams show that it doesn't use a relay [15:38:16] hmm [15:38:23] it uses the relay for the other signal [15:38:30] the repress electrically open [15:38:39] that uses the relay shown in the Systems Handbook [15:38:53] there has to be a switch then in the repress valve switch to give a signal [15:40:02] I just cant see any connection to SC1 [15:41:29] the Systems Handbook and elementary diagrams both show the connected to SC1 without giving any more information where on SC1 the measurement is [15:42:38] I guess I'll check for that connector the, oh boy [15:42:44] then* [15:42:59] looks like LM-3 didnt have that logic btw [15:43:10] it only used the repress electronics [15:43:27] yeah I checked LM-3, it's confusing [15:43:32] it also says it's disabled in manual [15:43:45] ah there is a connector list [15:44:43] https://www.dropbox.com/s/zrrrvut9ca7kzsv/Screenshot%202021-03-05%20104424.jpg?dl=0 [15:44:52] looks like the switch itself goes to SC1 [15:45:09] yeah [15:45:17] close auto give a 0 and manual gives a 1 [15:45:28] here, I link you the document [15:45:38] https://web.archive.org/web/20100517193006/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19710070889_1971070889.pdf [15:45:46] PDF page 373 [15:46:24] taking its time loading lol [15:47:54] hmm [15:47:58] which one? [15:48:19] top one on the right is the cabin light [15:48:25] and it gets two inputs [15:48:36] one coming from a signal in SCERA2, then other one in 1 [15:48:50] to the left it has ECS Relay Box with relay 7K6 [15:49:00] that's the relay for the valve being electrically open [15:49:09] and just above that [15:49:13] p373? [15:49:22] PDF page 373 [15:49:33] yeah [15:49:45] it's quite confusing to read at first [15:49:49] oh ok I am tracking [15:50:42] well I am more confused now [15:50:47] not seeing the physical switch [15:50:49] it says "GF3572X" there [15:50:52] yeah [15:51:00] thats the electrically open signal [15:51:04] yeah... [15:51:21] but that has to be wrong [15:51:32] yeah because thats not the switch position [15:51:34] Systems Handbook has that coming from relay 7K6 [15:52:10] so what is 7H3 [15:53:37] 7H3? [15:54:11] I only see 7A3, I think that is the number for the ECS relay box [15:54:13] thats what the box around the valve is labeled [15:54:18] in the sys handbook [15:54:34] oh [15:54:39] I think that is the switch number [15:54:43] ah [15:54:51] so thats what SC1 is reading [15:55:51] well I think that GF3572X is placed wrong in the diagrams [15:55:58] and that is actually the position indicator [15:56:16] ah, it says GF3572X for the relay as well [15:56:34] yeah [15:56:35] so the connector idea didn't work out [15:56:40] and if you look at the CW logic [15:56:54] GF3572X and the switch position are both there [15:57:00] the first thing I found on the same connector was on a SCERA subassembly that is already full [15:57:02] so that tells me they are independent [15:58:13] ok, different approach [15:58:18] this is a discrete signal [15:58:25] how many spares are there even for that in SCERA1 [15:58:47] hmm, a bunch [15:58:52] yeah [15:59:16] but there are only like 4 places where it could be [16:03:54] the Systems Handbook does have a list for the SCEA [16:04:02] but it either says open or electrically shorted [16:07:48] electrically shorted? so...uh...closed? lol [16:10:17] both SCERAs have a subassembly 1 that is for "GSE Checkout" [16:10:32] with no measurements in there if the Systems Handbook is to be believed [16:11:20] damn I didnt realize this would be such an enigma [16:22:37] AOH says again that it's measurement GF3081 [16:22:50] and it also says it's a SCEA subassembly of the type 504-3 [16:22:57] which SC1 doesn't even have... [16:41:37] oh [16:41:39] I found it [16:41:45] but the spot is taken [16:41:49] and it's on SC2 :D [16:42:13] but it could have been moved [16:42:31] LM-6 has it at the same place as the electrically open signal from the valve [16:42:36] well, same subassembly [16:42:41] one position earlier [16:42:44] but still a discrete input? [16:42:50] yes [16:42:52] but we have [16:42:53] EPS battery caution (GL4047X) [16:42:55] there [16:43:20] hmm [16:43:32] we might just need a placeholder? [16:44:30] I lost it [16:44:40] now I am seeing the battery caution there :D [16:44:43] where was it... [16:47:30] ah wrong AOH [16:47:31] so [16:47:43] LM-3 seems to have had it in that spot [16:47:52] SC2, SA3, channel 7 [16:47:58] channel 8 being the electrically on signal [16:48:53] Yet it wasnt used in the CW logic [16:49:59] I'm not so sure, it looked like that in the schematic [16:50:09] but in another place it still says that manual disables the light [16:51:14] yeah the CW logic gate had the wire cut [17:00:16] so SA12 of SC1 is a double output type of device [17:00:23] I don't think they would put it on there [17:00:37] I think what I will do is add the measurement in one of the other spare places [17:00:49] with a note that it isn't actually the confirmed position [17:03:53] the spare in SC1, SA2, channel 10 fits the best I think [17:06:50] yeah I think thats a fair compromise [17:06:59] then we can test and see if the timestep issue is fixed [17:10:02] checking your scenario before building [17:10:46] with my humble beginnings of a LM telemetry client I am now able to display battery 5 voltage from low bitrate [17:11:05] oh fancy [17:11:24] what do I have to do in your scenario? [17:11:28] it's in auto [17:11:41] manual then back to auto [17:11:53] immediately or when it's pressurized? [17:11:58] ah [17:12:01] already is pressurized [17:12:02] should already be pressurized [17:12:20] yeah got the alarm [17:12:22] I found it because I was doing the repress of the CM with the LM [17:12:53] ah right I remember that [17:13:28] LM being happy that it is for once not the passive part in repress [17:13:52] well for docked repress at least [17:14:07] indeed haha [17:14:28] speaking of SCEA delays [17:14:36] I think I should move the RCS TCA timesteps [17:14:42] it uses the SCEA a lot [17:14:55] so the best place is probably after the SCEA update, but before CWEA [17:14:58] right in the middle there [17:16:07] normally the SCEA needs to be very late, to read the state of all systems [17:16:28] guess what [17:16:34] still a master alarm [17:18:09] EmergencyCabinRepressRelay is updated in LEMCabinRepressValve::SystemTimestep [17:18:13] when is that called... [17:18:39] hmm [17:18:47] the Systems SDK valves have a short delay [17:18:58] and when the valve is moving it's not updating the relay state [17:19:32] so that probably adds a delay [17:19:46] hmm [17:20:38] repress switch is already in auto [17:20:44] when the relay is still powered [17:21:27] I could add logic to have the relay off when the valve is in the process of moving [17:21:57] I think its supposed to be off when moving? [17:22:09] but not certain [17:22:13] it doesn't update the relay [17:22:22] / Valve in motion [17:22:22] if (cabinRepressValve->in->pz) return; [17:22:31] so whatever state it was in before that still is the case [17:22:39] the function does do [17:22:40] if (cabinRepressValve->in->pz) return; [17:22:45] uhh [17:22:49] EmergencyCabinRepressRelay = false; [17:23:01] it does that by default [17:23:08] I'll try moving that above the return [17:23:50] hahaha [17:23:54] still triggers the MA [17:24:40] so is it the relay opening and closing really quick causing it? [17:25:58] I was thinking it was a delay on the relay being unpowered when you switch from manual to auto [17:33:16] hmm [17:34:10] 000002.757: 0 0 [17:34:11] 000002.774: 1 1 [17:34:12] 000002.790: 0 1 [17:34:17] that's three timesteps [17:34:28] first number is if the relay is on [17:34:41] second if the switch is NOT in manual [17:35:13] and I think the SCEA isn't actually adding a delay there [17:35:57] the code that determines if the relay is in doesn't use the SCEA [17:36:01] checks the switch directly [17:36:04] as it should [17:36:42] is on* [17:38:54] morning! [17:39:08] hey [17:39:15]