[15:35:45] NASSP Logging has been started by n7275 [15:35:47] hey guys [17:13:46] hey [17:14:54] yeah, definitely promising [17:58:49] morning! [18:08:39] hey [18:15:40] what's up [18:15:41] ? [18:16:39] got Apollo 11 once more into lunar orbit [18:16:50] those documents from UHCL sound nice [18:17:37] nice [18:17:49] yeah, one of them should hopefully mention it haha [18:18:12] and if it's not mentioned in June 5 I feel like that will pretty definitively say they didn't know about it yet [18:18:53] good to get our SCB meeting collection more complete [18:22:27] classic Tindall line "I really blew it at the June 5 Apollo Spacecraft Software Configuration [18:22:28] Control Board meeting." [18:25:09] I'd say there is a bigger chance that the FRR talks about it [18:25:13] but we will see [18:25:39] actually, did I switch back to 99R1... [18:25:43] yes [18:27:48] good that I have both (or really all) rope modules "onboard" :D [18:40:53] hehehehe [18:41:08] I feel like flying with Luminary 99 would almost be more fun [18:41:22] just a very rare chance that sometime you have a bit of of excitement in your landing :D [18:41:29] well [18:41:35] only with an abort [18:41:49] true [18:42:18] oh speaking of I wanted to ask [18:42:32] what were the flight rules for using ABORT STAGE over ABORT? [18:46:59] fairly simple I think, if the DPS is suspected to be the problem use abort stage [18:47:17] "An abort situation in which the DPS and PGNCS are both operational [18:47:20] implies that some other subsystem is at fault. For this case the recom [18:47:22] mended procedure is to push the ABORT button." [18:47:39] can't hurt to safe as much DV as you can [18:47:49] and if the DPS runs out, you go to abort stage anyway [18:47:50] ^ [18:47:56] good afternonn :) [18:47:58] okay, makes sense :D [18:48:00] afternoon [18:48:02] hey Ryan [18:48:13] Lol LM talk must have summoned me [18:48:14] that's what the mission techniques say anyway [18:48:22] maybe mission rules has more [18:49:36] that's good enough for me haha [18:50:56] mission rules has some cases for abort and abort stage use [18:51:23] but most just say "abort" under the powered descent category [18:51:51] IF POSSIBLE THE DPS WILL NOT BE BURNED TO PROPELLANT DEPLETION. WHERE EVER POSSIBLE THE ABORT [18:51:51] STAGE SEQUENCE WILL BE INITIATED AT LOW LEVEL PLUS 20 SECONDS [18:51:52] D [18:51:53] U [18:51:53] R [18:51:54] I [18:51:55] and some say abort, and then abort stage 20 seconds after low level [18:51:56] ~ [18:51:56] G [18:51:57] AN ABORT FRUM POWERED [18:51:59] DESCENT. HOWEvER. AT CREW OPTION ABORT STAGE SEWUENCE MAY BE INITIATED AT [18:52:03] ~ [18:52:05] O [18:52:07] W [18:52:09] L [18:52:11] E [18:52:13] v [18:52:15] E [18:52:17] ~ [18:52:19] IF A [18:52:21] S [18:52:22] Niklas broke IRC [18:52:23] A [18:52:25] F [18:52:27] ~ [18:52:29] ABORT STAGE CAPABILITy EXISTS, [18:52:33] ouch [18:52:35] sorry [18:53:01] lol no worries [18:53:07] "If possible the DPS will not be burned to propellant depletion, where ever possible the abort stage sequence will be initiated at low level plus 20 seconds during an abort from powered descent, however, at crew option abort stage sequence may be initiated at low level if a safe abort stage capability exists." [18:54:33] I'm sure you want a healthy altitude or positive altitude rate before doing abort stage [18:54:38] there is a bit of a startup delay [18:54:43] absolutely [18:55:08] positive rate for sure, APS can only arrest the fall so fast [20:14:24] flying all of Apollo 11 takes a long time, but I can start thinking about what I want to do next... [20:15:21] a bunch of RTCC things need fixing I guess [20:23:33] but that has probably always been true in the last few years... [20:41:54] hehehe [20:46:05] seems like one of those neverending projects where you can always get better, but never finish [20:46:30] pretty much [21:11:23] how long does it usually take you to get a response from UHCL nowadays? [21:11:30] I don't think I've actually requested anything since Lauren left [21:13:06] got a reply about 5 hours later [21:13:19] but they seem to be busy and with minimal staffing [21:15:35] hmm okay [21:19:15] I guess Ron didn't get his requests yet either [21:19:26] probably yeah [21:19:30] since he hasn't posted anything [21:23:24] yeah [22:02:59] night! [22:47:20] > This email to acknowledge receiving your request. We will try to make these available to you by the end of this week. [22:47:24] oh nice [23:30:51] that's awesome [23:36:10] I am really excited to see what these two things have to say [23:36:18] deep down I'm expecting neither to mention it [23:36:29] because of my track record with this darn anomaly so far [23:36:33] but if either does it will be great :D [16:37:27] hey [16:40:28] hi [16:47:25] what's up? [17:04:15] Still working. Doing some Ansible stuff. [17:04:33] Need to automate creating a bindmount on Linux. [17:06:10] You? [17:07:53] I thought I had pressed the abort button in the LM by accident, for the second time in a row [17:08:05] but it seems a problem with the auto checklist haha [17:08:34] Better disable the abort monitor :P [17:10:07] hmm some code seem to think the button is springloaded [17:10:10] seems* [17:10:39] so when it doesn't even have to change the state of the button, it's pressing it [17:19:02] I didn't notice until a while later [17:19:12] abort button pressed also arms the DPS [17:19:27] with the DPS armed, the DPS can be gimballed [17:19:48] and when in AGS attitude hold mode it tries to attitude hold with the DPS, if it is armed :D [17:20:12] on Apollo 10 it drove the gimbals into the stop and I got a master alarm [17:44:05] hi guys [17:47:17] hey [17:52:37] noticed some odd behaviour with pcm, when switching to hbr [17:54:53] if you reload the simulation with the system in hbr mode, it seems to work [17:55:15] the issue is when you switch mid sinulation [17:55:19] CSM? [17:55:24] *simulation [17:55:26] yes [17:56:01] some things either aren't getting updated, or theres an issue with the sync [17:57:33] if it's not a know issue, or easy fix, I may just put it on my list for future projects [18:01:43] oh you mean in the telemetry client? [18:02:40] well that's were I'm noticing it. so of course it could be an issue with the client, but I dont think so [18:02:50] yep, it's a known issue [18:02:56] which I haven't been able to figure out [18:03:07] always thought it was on the telemetry client side [18:03:08] hmmm [18:03:20] but maybe it's in the PCM, hadn't thought of that [18:03:43] the only thing that fixes it, is shutting down orbiter and re launching current state [18:03:53] fixes it 100% of the time [18:03:59] interesting [18:07:37] I guess first you have to figure out on which side the problem is [18:08:00] actually, what I saw was that some stuff was shown correctly in high bitrate in the telemetry client, but others not [18:08:17] quite random [18:18:20] yeah [18:41:06] morning! [18:41:30] hey mike [18:48:06] yeah, indy91, only the hbr-only things get messed up, and yes, randomly [18:59:21] hey Mike [18:59:31] I had a random restart [18:59:39] channel 77 says TC trap [19:00:26] Luminary 99R1, before most of the LGC activation stuff [19:00:32] maybe I pressed mark or so [19:13:58] oh interesting [19:14:07] I feel like this has happened before... [19:14:08] what's your RSBBQ? [19:14:16] but this time I didn't reset it immediate :D [19:14:19] and saved [19:14:24] what address is that again? [19:14:55] 1432 and 1433 [19:14:59] (in E3) [19:15:19] EMEM1432 2102 [19:15:20] EMEM1433 400 [19:16:25] O_o [19:18:09] so... your bank register is not valid at all, and your program counter was.... either in the last alarm code register or the "used" flag for VAC1 [19:18:56] I can believe that something awful happened there :P [19:19:18] haha [19:19:25] I have no idea how that would even happen [19:20:06] hope it didn't overwrite anything important [19:31:28] LM minimum impulse firing with a full LM gives really small attitude rate changes [19:31:34] have to get used to that :D [19:31:59] hehehe [19:33:50] in pitch and roll it actually fires the RCS for 40ms instead of 14ms for the CSM/LM docked case [19:34:01] there 15ms would really be too small [19:34:42] 14* [19:35:04] ah wait wrong again [19:35:05] 60ms [19:35:08] for docked [19:37:07] I like it for P52 [19:37:17] nice and small bursts. I guess it's just a bit smaller than before, but still [19:37:41] +00001 for a LM P52 is pretty good [19:44:19] nice [19:45:49] smoother ride, I take it? [19:51:52] btw indy91 I got a response yesterday afternoon from UHCL saying that they'll try to get me those scans by the end of the week [19:55:43] thewonderidiot, great [19:56:31] n7275, yeah, with minimum impulse you can barely even see the rate needles move, which is not that great actually. I would like a finer rate display in the LM than it had :D [19:56:53] and normal att hold with the full LM has also less thruster firing [19:57:39] not as much of an improvement as the ascent stage of course [19:57:46] but still noticable [20:06:55] awesome [20:07:28] oh, played around with pcm a bit (remotely, using telemetryclient) [20:07:55] if you close and open it, or connect and disconnect nothing changes sync wise [20:08:11] but if you toggle between hbr and lbr it does [20:09:01] right [20:09:15] could still be both PCM or telemetry client being at fault [20:09:59] hmm yeah [20:10:33] will have to try with my logger [21:32:50] hmm good chance it's just telemetryclient [21:55:45] if it's the client it probably lacks something to re-sync when the bitrate is switched [21:57:20] night! [22:40:07] ugh, nope, stuff is definitely ending up in the wrong frame [14:37:48] hey Ryan [14:38:39] morning [14:39:15] I am working on HGA angles actually in the checklists, do you remember offhand how many switch positions the PY HGA steering knobs have now? [14:45:00] off the top o my head, twice as many as before [14:46:11] just trying to correlate the position to angle right now [15:03:08] also trying to figure out when on 9 they activated the HGA [15:04:56] hmmm maybe one little part of it only [15:05:52] "The service-module high-gain antenna was acquired and tracked successfully [15:05:53] for S-band communications during the Carnarvon and Hawaii station [15:05:54] coverage during revolution 122." [15:06:14] trying to see when it was activated though [15:31:54] not sure. [15:40:49] eventually I need to add ground station s-band sources, not just the center of the earth [15:59:33] yeah for LEO missions that would be great [15:59:53] That and VHF [16:03:00] lol I need ggalfi to push the VESIM fixes so I can use my stick :P [18:01:16] good afternoon :) [18:08:56] hey [18:10:02] hey, so I have been digging into 9 and seem to be unable to find good info on when they used the HGA other than a test in rev 122 and various mentions in the transcript [18:13:39] hmm, possible that they had it powered down most of the time [18:14:05] thats what I am thinking [18:14:22] just unclear on if when it was actually up [18:20:35] I checked the debriefing and the mission report supplement for comm systems [18:20:48] a bunch of details of the test, but not anything about other mission phases [18:25:41] "The CSM high-gain antenna will not be tested during this mission [18:25:42] because of its excellent performance during the Apollo 8 mission." [18:26:10] you sure there MSC prelaunch memo? :D [18:26:22] I guess they added it during flight [18:26:30] it's not even in the flight plan I believe [18:27:52] yeah I saw the test stuff for rev 122 but thats it [18:28:15] I think there were a few mentions of it in the transcript as well I need to look for those [18:28:50] morning! [18:35:43] would be be interesting to see how it tracked a surface station in LEO [18:44:08] hey Mike and Matt [18:44:55] did one of my worse landings on Apollo 11. Anybody got a problem with a 10° yaw angle for the landed LM? :D [18:45:05] for the new default scenarios [18:53:05] oh my [18:53:23] I've done worse [18:53:33] you didn't tip it over [18:55:44] would be an awkward new mission scenario with the LM upside down [18:59:56] "What AOT detent should be use?" "Forward... down" [19:05:26] hehehe [19:09:51] RCS behaved well with the new system [19:10:00] although one thing I still need to investigate [19:10:31] hardover mode [19:11:48] which uses the secondary coils of the RCS [19:12:00] and it doesn't go through the same system as all other RCS fire [19:12:28] in NASSP and in the real thing [19:13:05] actually, on the CSM side, one NAA CSM simulator simulated different thruster on/off delays for direct RCS [19:13:17] difference in the involved electronics I guess [19:13:23] quite significant difference actually [19:13:56] automatic jets: 17 msec on delay, 12 msec off [19:14:05] direct jets: 45 msec on, 41 msec off [19:15:24] to keep things simple, and small pulses are not exactly relevant for hardover and direct modes, I'll probably not simulate those short pulses correctly for hardover [19:16:30] only need to make sure they don't interfere [19:23:14] ugh I need that joystick support [19:23:22] I need my deflection lol [19:24:12] I can get by without joystick if I switch hardover mode off and in V48 set the max rate to 4°/s (instead of 20) [19:24:49] all manual attitude maneuvers are just 4°/s then [19:25:48] ah thats a slick workaround [19:26:02] however I can never put my ACA out of detent after touchdown :P [19:26:44] right [19:26:53] then you just have to fly the later missions [19:27:02] which just do PRO instead of ACA out of detent [19:27:04] yeah I need to [19:27:36] does sundance need ACA out of detent already? [19:28:03] upon landing? [19:28:14] yeah [19:28:16] hmm [19:28:20] or does the PRO take care of everything? [19:28:33] not sure [19:28:48] the ACA out of detent resets the attitude reference for att hold [19:28:59] which makes it stop firing the RCS [19:29:59] where is that, Servicer? [19:30:22] oh the PRO is what shuts down the engine in Sundance, right? [19:30:26] so that's not useful then [19:30:43] yeah [19:30:46] because that's precisely the issue, just before landing you have an attitude which it wants to hold [19:30:51] right [19:30:55] so that's probably the same [19:30:59] but then you touch the surface and it will settle at a different attitude [19:31:00] yeah [19:31:18] unless it cuts off the DAP or so [19:31:23] or widens the deadband [19:32:04] LANDJUNK? [19:33:18] hey that sounds like a LM slur [19:33:32] :P [19:34:09] our private name for LM-2 [19:34:31] Hmmm...I'll allow it [19:34:57] I bet for LTA-8A you wouldn't allow it :D [19:35:43] I'd have to try a landing again, but LANDJUNK doesn't seem to do anything with the DAP [19:39:15] found a bug with the TCAs [19:39:47] if I pull the breakers for the TCA, so the normal RCS coils, and then fire hardover mode it thinks I have thrusters failed on [19:40:18] hmm [19:40:21] or is it no bug [19:46:56] hmmm [19:47:43] they shouldnt be if deenergized? [19:49:22] what logic makes them indicate "failed on" [19:51:41] I think in theory if two opposing thrusters are commanded to be fired [19:51:49] I'll check if I got that right [19:57:17] the firing command is independent of the coil power isnt it? [19:57:37] in other words it can still have a firing command even with the breakers out? [20:12:13] ok I think I got it all wrong lol [20:12:27] I was still in a mode where the CMC was in control [20:12:40] and it tried to fire the RCS in response to my hardover commands [20:12:45] so cmc and you were commanding at the same time? [20:12:48] ahh [20:12:58] so it was thruster failed off [20:13:00] not on [20:13:02] and that's still a bug [20:13:09] as there shouldn't be a thruster demand [20:13:16] yeah that makes sense [20:13:19] for engine failed off it compares actual thrust chamber pressure [20:13:42] pressure to a commanded fire? [20:13:44] with the state of the primary coils [20:14:02] so yeah it couldnt be failed on in that state with the breakers out [20:14:11] yep, those relays can't be powered [20:14:40] SA2.SetOutput(6, lem->atca.jet_request[LMRCS_B1D] == 1); [20:14:49] that jet request works without power, which is wrong [20:15:18] the only place where TCA breakers are currently used is in the function that actually fires the RCS in primary mode [20:15:33] LEM::SetRCSJetLevelPrimary(int jet, double level) [20:15:38] if(RCS_A_QUAD1_TCA_CB.Voltage() > 24){ RCS_A_QUAD1_TCA_CB.DrawPower(46); }else{ level = 0; } [20:15:44] SetThrusterLevel(th_rcs[jet], level); [20:16:07] so they were never dependent on the breakers in the code [20:17:08] not the thruster demand, which the TCA thruster failed off code checking [20:17:37] only is used for the code where it actually fires the thruster right now [20:18:04] good find [20:18:14] and the are two source of the thruster demand, PGNS and AGS [20:18:18] so how do I fix that... [20:19:07] in the schematics those two requests are basically the primary (PGNS) and abort (AGS) preamps [20:19:36] so do they dont receive power from the TCA breakers in that case? [20:19:40] and then the next step is the jet drivers, which need TCA power [20:19:43] ah [20:20:05] thats the jet driver code up there with the power draw correct? [20:20:32] or is that just firing [20:20:36] just firing [20:20:39] SetRCSJetLevelPrimary is what fires [20:20:51] so there needs to be a requirement in between for TCA power as well [20:20:54] hmm [20:20:57] yep [20:21:17] is there any class or code for a jet driver? [20:21:19] some ATCA code is processing the thruster demands and calls SetRCSJetLevelPrimary [20:21:26] no [20:21:46] that might be the solution I suppose [20:22:00] or at the very least a power requirement there [20:22:22] right now there is just one set of jet_request which both PGNS and AGS use [20:22:26] I could make that separate [20:22:43] add an additional array for the jet drivers [20:22:49] and add the power requirement to that [20:23:04] so [20:23:24] if (TCA power && (prim_preamps || abort_preamps)) [20:23:28] basically [20:23:56] i mean it follows the logic from what you described (I dont have the schem in front of me) [20:24:23] yeah, I think I need to untangle a little bit of ATCA code as well, but it shouldn't be too bad [20:24:40] and the failed off is triggered by comparing the command checked where? [20:24:53] the driver? [20:25:09] yeah everything goes through the SCEA [20:25:16] jet driver output is on the SCEA as on or off [20:25:34] and the SCEA also has RCS thrust chamber pressure as a voltage [20:25:49] the TCA gets both signals from the SCEA [20:25:54] failed off is when [20:26:09] jet driver output is on, chamber pressure too low [20:26:27] for a certain time or multiple pulses [20:26:59] and that jet driver output can definitely not be on without the TCA breaker [20:29:05] ah ok so we need a jet driver in there like you posted previously, and that would tie into the SCEA as well [20:29:24] just need to give it the correct signal of course [20:29:26] yep, that is what the SCEA would get as the thruster demand [20:29:39] I am tracking haha [20:29:51] good, that means I am not talking too much nonsense [20:30:15] there is just an annoying piece of code for the balanced couples that I need to move first [20:33:36] ok, that just disables 4 of the abort preamps [20:33:45] so disables 4 thrusters in AGS mode [20:34:29] the switch or the logic? [20:34:49] bal cpl disables the 4 in PGNS and AGS correct? [20:35:01] unless this is just for an abort [20:35:33] only AGS [20:35:49] the switch doesn't affect the PGNS [20:36:04] it only let's power through to four of the abort preamps if the switch is up [20:36:49] I just need to move the code a bit up and reset 4 of the new ags thruster demands if the switch is down [20:37:28] really? [20:37:40] So what about a PGNS P12? [20:37:57] Oh never mind [20:38:03] Duh [20:38:06] trust in the DAP :D [20:38:08] Yes [20:38:11] Haha [20:38:33] although I am not sure it has a special ascent mode [20:41:02] so its been a bit, but BAL CPL is on before liftoff then back off after pitchover [20:41:23] yeah, thinking about it that switch is just to conserve RCS propellant in AGS mode [20:41:33] all thrusters on for pitchover etc [20:41:38] but then you can switch it off [20:41:42] For a launch yeah [20:42:02] Its also to prevent any thrusters firing opposite the APS on the initial vertical ascent is it now? [20:42:04] even with my update the RCS is overpowered for the ascent stage [20:42:05] not*? [20:42:34] I thought so, but you have it the thrusters on for that time [20:42:38] not off [20:43:36] OFF is what inhibits the jets [20:43:53] I mixed them up in my head [20:44:25] makes sense you have them on after pitchover then off during the ascent to conserve fuel but I would also think to not have any thrust countering the APS [20:44:47] yeah, that's definitely the correct four thrusters to switch off for that [20:44:54]