[15:33:02] NASSP Logging has been started by thymo [15:33:26] hey [15:33:33] rcflyinghokie, you can debug your problem [15:34:17] start Orbiter, but only the launchpad [15:34:22] I figured it was something simple, I was writing that last bit for the sband and vhf last night under the influence of cold meds and didnt feel like debugging haha [15:34:46] Ok launchpad up [15:34:46] then in VS you go to Debug and Attach to Process or so [15:35:07] Done [15:35:19] there you search for the Orbiter exe and press OK [15:35:27] Debugger doesn't play very nice with attaching at the launchpad. It might work, it might not. [15:35:27] then you start Orbiter proper [15:35:42] worked pretty good for me [15:35:54] I've had Orbiter crash simply because the debugger was attached at the launchpad. [15:35:56] at least better than not having a working real time debugger at all [15:36:12] Uhh its not crashing [15:36:14] Have you both fixed your debuggers then? [15:36:21] No thats a workaround [15:36:27] ? [15:36:29] Weird I got like 3 in a row last night [15:36:32] I'm not following [15:36:55] what didn't work for us anymore was starting the debugger after the crash [15:37:04] Oh. [15:37:22] indy91 I have loaded 6 times now different scn' [15:37:25] no ctd [15:37:26] after a crash you could press the Debug button and then select the VS solution you have open for debugging [15:37:50] that doesn't work for Ryan and me anymore. Well, it works sporadicly for me [15:37:54] ever 20 times or so :D [15:37:57] every* [15:38:08] rcflyinghokie, so you fixed your CTD? [15:38:25] Ah no there it is [15:38:32] You did add the optional Just-In-Time debugger when configuring VS right? [15:38:40] You need that for it to work. [15:38:46] Yes [15:38:49] oh yes [15:38:54] we did many things to get it back [15:39:18] it just stopped working with the Fall update [15:40:14] Ok CTD are back [15:40:21] and where did it crash? [15:40:27] Nothign comes up [15:40:37] are you sure you had the debugger up? [15:40:50] Its only my "ECS testing" scn [15:40:57] Others work [15:40:59] ok [15:41:09] And yeah I did what you said [15:41:17] I got a window with a close or debug option [15:41:27] Clicked debug [15:41:33] no, that's not right [15:41:43] you shouldn't have to do that [15:41:44] Another close or debug window comes up and I click debug and it terminates the process [15:41:54] Let''s try again [15:42:06] with the debugger up, all you have to do is go to VS to look where it crashed [15:42:46] Ok I have an oragne bar at the bottom and a window with autos and one call stacks, correct? [15:42:47] no need to press debug, because you are already doing that. And that window shouldn't even come up with the debugger already running [15:42:50] *orange [15:42:52] that sounds right [15:42:57] debugger is running then [15:42:59] Now I run the program [15:43:09] now you start the scenario you mean [15:43:19] Yes [15:43:20] Orbiter exe should already be running [15:43:23] And no ctd [15:43:28] haha [15:43:29] great [15:43:47] I will keep trying till I get one [15:44:08] Could try either of these: [15:44:09] https://social.msdn.microsoft.com/Forums/vstudio/en-US/752d4256-ae20-41e7-8c62-60f5bd2a4b69/just-in-time-debugging-not-working-anymore?forum=vsdebug [15:44:09] https://stackoverflow.com/questions/32988364/vs-just-in-time-debugging-wont-work [15:44:23] Ok got it [15:44:29] Now I have the close or debug window [15:44:37] that's weird [15:44:49] it should automatically switch to VS when the CTD happens [15:44:56] Nope [15:45:01] and that window shouldn't appear until you have already ended debugging [15:45:06] I tab over to VS and the window has not changed [15:45:15] you have the NASSP solution open, right? [15:45:22] Yes [15:45:29] weird [15:45:58] 'orbiter.exe' (Script): Loaded 'Script Code (Windows Internet Explorer)'. [15:45:59] The program '[7988] orbiter.exe' has exited with code -1073741819 (0xc0000005) 'Access violation'. [15:46:07] Thats all I get [15:47:05] in any case, I have a bunch of other issues with your PR [15:47:42] Ok [15:47:43] apparently the LM_VHF class draws powers for the ERAs [15:47:53] lem->INST_SIG_CONDR_1_CB.DrawPower [15:48:03] lem->INST_SIG_CONDR_2_CB.DrawPower(10.36); [15:48:10] that was already there before [15:48:24] but those are a separate class now and draws power there [15:48:33] right now it would draw power twice for them then [15:48:34] Ok so remove that [15:48:39] yeah [15:48:58] SIGSENSOR as well? [15:49:06] I don't know if it should draw power from INST_SIG_SENSOR_CB there either, but I'll investigate that later [15:49:07] I added that because the comment said it was missing [15:49:10] so that can stay for now [15:49:22] then in S-Band [15:49:47] there are a few if- if else [15:49:51] if (tc_mode_1 == 0) [15:49:55] else if (tc_mode_1 == 3) [15:49:57] Yeah [15:50:04] I asked Mike about those last night [15:50:07] but then you added [15:50:08] if (tc_mode_2 == 0) [15:50:13] else if (tc_mode_1 == 3) [15:50:16] also mode 1 [15:50:28] you did the same with pa_mode [15:50:29] if (pa_mode_1 == 0) [15:50:33] else if (tc_mode_1 == 3) [15:50:38] if (pa_mode_2 == 0) [15:50:42] else if (tc_mode_1 == 3) [15:50:45] always tc_mode [15:50:53] so that probably needs to be fixed [15:51:27] Mode 1 is the primary sband [15:51:31] and mode 2 is secondary [15:52:06] but shouldn't it be "else if (pa_mode_1 == 3)" and so on? [15:52:28] you always have the "else if (tc_mode_1) == 3)" [15:52:32] always tc_mode_1 [15:52:41] Ohh [15:52:55] bad copy&paste I guess [15:53:46] Where is the () around only tc_mode_1 and so on [15:53:57] Oh I see [15:54:09] Yep copy paste error [15:54:53] Got it [15:55:12] I misunderstood what you meant at first [15:55:19] But that is fixed [15:56:15] oh, and lastly in the ATCA [15:57:06] you used the "lem->scca2.GetK12()" stuff for the PGNS/AGS logic [15:57:34] Copy paste error [15:57:39] That was supposed to be removed [15:57:45] I didn't say there was an error [15:57:46] :D [15:57:51] I just need to check if K12 and K13 are the right relays to use there [15:58:12] Oh [15:58:18] Haha ok [15:58:28] I stole it from the powered logic [15:58:57] But didnt know if it was necessary [16:00:52] Tried the debig again, it just closed the debugger without any prompts from me [16:01:01] debug [16:02:24] the guidance control switch switches a bunch of relays, all with different purposes [16:02:43] so there could be one or two relays that are used for exactly this reason, switching ATCA power [16:05:52] ah I see where you got it from [16:06:22] the power logic for the redundant RCS preamps [16:08:32] that's good enough for now [16:09:37] Ok [16:11:06] I'll merge the PR then [16:13:08] Maybe you will have better luck finding that CTD [16:14:05] it still only happens in the one scenario, right? [16:14:59] I think [16:15:03] I will try some others [16:15:07] Because it works sometimes too [16:15:09] found another small issue [16:15:16] in LM_SBAND::LM_SBAND [16:15:35] you are setting the 4 heat loads to 0 twice [16:16:02] Oh oops [16:23:03] Still no luck on this debug [16:23:32] But seems to be just that one scn [16:28:01] in other new, I have a LEM running on a Saturn IB at LC-37 [16:28:03] news* [16:28:22] Great! [16:28:28] still needs a lot of work, but I think I can get Apollo 5 working properly [16:29:01] That would be interesting to fly [16:29:10] to watch rather :D [16:29:30] but you can play mission control [16:29:52] including letting the LM complete the ascent to orbit [16:30:06] that's one of the programs in Sunburst we couldn't test yet [16:30:25] basically like an automatic Mode IV abort with the LM [16:30:32] Oh cool [16:30:37] using the same calculations as P12 in Luminary [16:30:49] which is also used for an ascent simulation later in the flight [16:31:09] so even with a failing S-IVB the mission wasn't lost [16:31:55] that would be really fun to watch, LM orbital insertion :D [16:32:28] Now was there a FITH contingency for that contingency? [16:32:29] you have to uplink something to the LGC for that, I'll probably have to add something to the PAMFD to support that [16:32:35] hmmm [16:32:55] I don't think in software, no [16:33:08] however, there are a few contingency cases in the LM programer [16:33:15] some of which were used during the actual flight [16:33:34] but there is one mode that executes a whole bunch of stuff in one minute [16:33:44] I think that is for the case that the LM can't make orbit at all [16:33:56] in that case they are doing a very quick test of everything [16:34:36] including a FITH test [16:34:41] but not to achieve orbit [16:34:45] Not much time to do all of that [16:34:54] I'm not entirely sure [16:35:03] we will be able to test all of that [16:35:26] I removed a few components from my ECS scn and havent had a CTD yet [16:35:46] interesting [16:36:03] "Minimum Requirement Sequence", that could be it [16:36:03] I pulled out the boilers and the lunar battery [16:36:11] Sounds like it [16:36:57] Never mind there is one [16:38:03] https://www.ibiblio.org/apollo/Documents/HSI-209589.pdf [16:38:12] PDF page 137 [16:39:31] PR merged anyway [16:39:46] Can you see if you can replicate the CTD [16:40:13] Those timelines are super short btw [16:40:49] I'm in my LEMSaturn branch, but I can test it soon [16:40:55] Ok no rush [16:41:13] yeah, I think that is the timeline for the case that the LEM is in the upper atmosphere, without a way to get to orbit [16:41:31] so better do the tests quickly, or else you have already reentered the atmosphere fully [16:42:38] For the debugging, I have this in my output when I start is that right? [16:42:38] 'orbiter.exe' (Script): Loaded 'Script Code (Windows Internet Explorer)'. [16:45:54] which output? [16:46:40] In the debugger the output tab in the bottom right [16:46:44] When first attach [16:46:46] When I [16:47:06] it says a bunch of things for me there [16:47:16] which modules the Orbiter exe opened etc. [16:47:54] it also says "orbiter.exe (Win32)" for there [16:48:55] for me* [16:51:50] Yeah I dont get any of that [16:54:54] Back in a sec [17:13:04] can you give me the problematic scenario? Or is it the same one we have been using [17:13:10] the old one, with CSM+LM docked [17:13:32] Should be pretty much the same [17:13:54] I think I made a change or two though [17:14:07] I did today at least to try to fix it [17:14:19] https://www.dropbox.com/s/2z6qctbawg5vtuo/LM%20ECS%20Testing.scn?dl=0 [17:15:26] thanks [17:15:43] I'll test it now, good time to make a commit for the LEMSaturn stuff [17:15:50] saving, loading and timestep works [17:16:22] the Saturn IB is not sitting directly on the pad right now, a bit higher up. And it almost falls over because of terrain issues [17:16:35] next I'll wire together the IU with the LM [17:19:26] but that should basically be identical to the CSM [17:19:41] after all Sunburst gets the same input bits from the IU as a CMC [17:20:04] Haha back to the old IB issues? [17:20:10] kind of [17:20:16] I am at pad 37 [17:20:23] where Alex hasn't fixed the terrain [17:20:27] Oh thats right [17:20:44] technically I am where LC-37 was in Orbiter 2006 [17:20:52] have to move the stack and pad a bit [17:21:48] when I release this, there will be 2 Apollo 5 scenarios. One the usual development scenario, with the LM unpowered. Not at T-4 hours probably, that would be a bit excessive [17:21:58] and one scenario just before launch with the LM ready to go [17:22:32] ok, debugger on, let's load this scenario [17:22:48] got a CTD [17:22:51] and it can debug [17:22:56] Excel checklist issue [17:23:44] LM Default Checklist [17:23:57] I added the ECS commands to that [17:24:25] it crashed at initialization [17:26:14] Wonder if it was because of the position it was at [17:26:18] could be [17:26:26] if I delete the checklist state I get no CTD [17:26:32] Yeah that makes sense then [17:26:51] The other scn i tried loaded other checklists besides the default [17:27:04] Still not happy I cannot debug even using that method [17:27:34] oh interesting [17:27:50] VS is not registered as the debugger for script anymore [17:27:56] maybe try unchecking that? [17:28:05] under Options, Debugging, Just-in-Time [17:28:49] but yeah, if it is a checklist issue, then it's a fairly common CTD we had when checklist files were updated [17:28:51] no big thing [17:31:23] Yeah that did it [17:31:40] And I tried unchecking it I still have 'orbiter.exe' (Script): Loaded 'Script Code (Windows Internet Explorer)'. [17:31:44] As the only thing that comes up [17:34:11] Maybe the VS debugger is learning from its own bugs to become better. It's a feature! [17:34:35] Hah [17:35:20] So I wanted to ask you, PCM heat, where should it go? [17:36:15] together with [17:36:17] lem->INST_PCMTEA_CB.DrawPower(11); [17:36:22] in LM_VHF [17:36:49] Ah simple [17:43:20] And SCE? [17:45:20] which part of it? [17:45:26] you mean the SCEA I guess [17:45:32] Yeah SCERA [17:47:04] oh, the two SCERAs are a subsystem of the SCEA [17:47:22] electronic replacable assemblies (ERA) or so [17:47:49] for each kind of voltage there is a different type of replacable unit [17:48:02] the SCEA has two SCERAs, and each SCERA has 22 of those units [17:48:20] in any case, it should go into the SystemTimestep of the SCERAs, in lm_scea [17:48:23] Ok [17:48:32] I will use the heat from sig cond 1 and 2 then [17:48:52] there are separate classes for SCERA 1 and 2 [17:49:02] so you can put them to the draw power in each [17:49:08] Great [17:49:31] I still am worried that we don't/won't have enough heat in the glycol with this halving thing [17:49:46] But once all systems are in place giving heat we can test and see [17:50:19] Also I wonder if it is prudent to give some heat to the cabin from some systems that arent cooled by glycol yet give off heat [17:50:33] that can be done [17:50:39] same procedure as with the other heat loads [17:50:41] Yeah it should be easy [17:50:46] they just have to be connected to the cabin tank [17:51:00] I will wait until all the glycol systems are attached first [17:52:15] morning! [17:52:28] PR is up for PCM heat [17:52:40] I need to run some errands and I will see if I can get SCE heat going [17:52:53] What other systems are implemented that can take heat [17:54:33] not sure [17:54:36] hey Mike [17:54:44] what's up? [17:54:53] I'm making progress with the LEM on Saturn project [17:55:09] connecting the LM to the IU right now [17:55:44] I can already load Orbiter without a crash and am seeing a Saturn IB, but with a LM cockpit [17:55:58] that's awesome! :D [17:58:58] can't wait to see Sunburst fly a whole mission [17:59:46] well, 90% of a mission already worked before [18:00:13] I'm especially excited for the abort to orbit stuff in Sunburst [18:00:27] yeah that will be awesome [18:02:26] especially a mission phase 3 abort, what with it using both DPS and APS (with a FITH, I think) to claw its way into orbit [18:03:32] it's all manual though, right? the LM won't automatically respond to problems? [18:03:40] MP3 says this: [18:03:41] # CALLING SEQUENCE [18:03:42] # SUBORBITAL ABORT IS STARTED AT THE DISCRETION OF THE GROUND IN THE EVENT OF AN ABORT DURING THE EARLIER PART [18:03:42] # OF BOOST. KEY CODE 23 IS SENT VIA UPLINK. [18:06:35] yeah, probably has to be initiated from MCC [18:06:56] so it would do a FITH for that abort [18:07:16] I wasn't sure when I talked to Ryan about it earlier [18:08:53] can Sunburst command staging? [18:09:00] uhh [18:09:06] I mean, S-IVB/LM staging [18:09:32] normally that might be commanded by the LVDC, on a schedule [18:09:39] but I am sure there is a backup for an abort [18:11:07] hmmm [18:11:17] good question [18:12:00] "MP3 THEN STARTS +X TRANSLATION AND COMMANDS SIVB/LEM SEPARATION." [18:12:26] so maybe the programer can command it? [18:12:27] LMP switch 90 [18:12:36] awesome [18:12:39] TC 2LMP+DT [18:12:40] DEC 90 # LEM/S4B SEPARATE - COMMAND ** [18:12:41] DEC 4 # ED BATTERY ACTIVATION - ON * [18:12:41] DEC 10 # WAIT 100 MILLISECONDS [18:14:18] damn, those sections are missing from the LM-1 Systems Handbook [18:15:07] but shouldn't be too difficult to add that capability [18:15:27] booo [18:15:39] now, is Sunburst also commanding this during a nominal mission? [18:16:19] mission phase 7 is nominal right? [18:16:51] # SIVB/LEM SEPARATION IS STARTED 39 MIN. 56 SEC. AFTER SIVB SHUTDOWN IS DETECTED. AT 00/11/04, ONE [18:16:52] # MINUTE AFTER BOOST SHUTDOWN IS DETECTED, MISSION TIMER NO. 1 IS SET TO 38M 56S AND MISSION PHASE REGISTER NO. 1 [18:16:52] # TO MP 7. MISSION PHASE 7 STARTS AT 00/50/00. THIS PROGRAM COMMANDS A SEQUENCE OF EVENTS INCLUDING RCS COLD [18:16:53] # FIRE PURGE, RCS PRESSURIZATION, S BAND SYSTEM ACTIVATION, +X TRANSLATION INITIATION OF LEM/SIVB SEPARATION [18:16:53] # SEQUENCE, AND AGS ACTIVATION. IMMEDIATELY AFTER PHYSICAL SEPARATION .... [18:16:57] yeah [18:18:46] great, I was always confused where the command for the separation originated [18:18:58] so another job for Sunburst [18:45:12] first launch test [18:45:54] well, it was more of a flight readiness firing [18:47:06] hahahaha [18:47:30] I lifted off on the first actual test, but now with the IU actually running it didn't lift off [18:52:43] but I know why, I didn't properly connect some things [18:53:41] next test [18:53:50] looks promising, it's doing the prelaunch venting [18:55:11] :D [18:55:31] it's pitching [18:55:42] so LVDC and rest of the IU are running correctly [18:55:48] awesome!! [19:01:37] bad things still happen at staging, but that was expected [19:01:56] and I still need to solve a bunch of issues on the ground that I don't know all that much about [19:02:02] meshes and touchdown points etc. [19:02:12] where's Alex when you need him [19:03:00] yeah, I also need him to flatten the terrain at LC-37 [19:03:07] it's 2° off at launch right now [19:03:15] that won't be a very accurate insertion :D [19:07:16] next attempt, staging might be fixed [19:10:03] got another flight readiness firing [19:10:13] the stage itself didn't even fire [19:10:22] just the particle effect of the launchpad [19:10:37] heh [19:10:54] but I've had this issue before, that it decided to cutoff [19:11:03] can't remember what caused that [19:16:47] some weird things still, but looked like a good staging [19:23:10] ran out of fuel before making orbit [19:23:20] I guess I have to tweak the empty and propellant masses a bit [19:26:29] you could have used MP3 or MP4 :P [19:28:24] not yet [19:28:36] S-IVB/LM staging won't work properly yet [19:28:49] and I still have a completely powered down LM [19:44:48] I'll try a launch from the LC-34 coordinates, it should be flat there [19:45:18] if that still runs out of fuel, then I am going to change some things [19:49:57] oh btw, totally unrelated but I don't think I mentioned this [19:50:22] I was going over the table of GAP error messages in the Symbolic Listing Information document, and comparing it to YUL source a few days ago [19:50:51] I'm pretty sure GAP was very close to being just a straight port of YUL, because almost all of the error messages are the same [19:52:27] who made GAP again? [19:52:56] not sure, I only really know them as "the GAP team" [19:53:03] Hugh may have given some names in his book, I don't remember [19:53:51] maybe I am confusing things, GAP is not the one Raytheon or so made? [19:54:52] no, it was an MIT port of YUL to the IBM 360 [19:55:11] ah, of course [19:55:12] wasn't there an external company that also made an assembler? [19:55:16] Hugh did the original ones for the IBM 650 and the Honeywell 800/1800 [19:55:38] Raytheon must have made one, since SuperJob doesn't build correctly with YUL [19:55:41] but we don't know much about it [19:55:46] ah, that was it [19:55:56] when we discovered SuperJob [19:57:06] so back to GAP, guess what works doesn't need to be changed. Including error messages [19:59:49] haha, got a fun CTD. The ATCA tried to do something. Probably just turn a RCS jet off or so [20:00:01] but that thruster isn't defined yet [20:00:12] so I guess I have to make that code a bit more safer [20:00:19] shouldn't even try to do this without power [20:00:27] not even turning a jet off [20:23:21] hey [20:25:16] hey Alex [20:28:23] see a lot of new additions in the past days to the LM, just trying it now [20:28:53] mostly LM ECS heat loads [20:29:53] but for that we also connected the IMU and ASA heat sinks (simulated as radiators) to heaters and heat exchangers [20:30:03] I guess CWEA is next on the list? [20:30:14] Thymo is still working on it [20:30:24] I am working on a small side project [20:30:34] small as in, a few 1000 lines of code [20:30:43] very small indeed [20:30:51] SECA? [20:30:59] I'm trying to get LEM launching on a Saturn working [20:31:12] in a few days we have the 50th anniversary of Apollo 5 [20:31:17] ah nice [20:31:18] I hope I am done by then [20:31:22] SCEA* [20:31:42] oh yeah, the SCEA still can use a few lines of code [20:31:47] mostly adding more measurements [20:32:51] maybe from the knowledge gained from that we can get the LM creation order changes [20:33:02] changed during TD&E [20:33:22] unlikely [20:33:32] what I am doing is build a Saturn IB around the LM class [20:33:41] ah, I see [20:33:41] not a very elegant solution [20:33:53] but the only way right now [20:33:57] right [20:34:50] I just discovered a bad bug that will cost me a while, but essentially I can already launch this to orbit [20:35:24] the separate classes for the Saturn stages made that possible fairly easily [20:49:58] luckily got the bug fixed. Our LEM is now officially protected against CTDs caused by non-defined thruster :D [20:52:01] uhh, not quite yet [20:52:08] lol [20:52:45] I switched to the LM panel and got another CTD [20:52:57] because the thrust indicator directly access the DPS thruster [20:53:12] which is of course not defined :D [20:53:40] yeah, I switched to the panel about 5 seconds after proclaiming that the LM is protected against that... [20:54:24] seems better now [20:55:26] goal for today, actually getting int orbit [20:59:30] oh man I keep forgetting to request that AS-503 systems handbook [21:03:32] there, requested [21:03:43] hopefully it is as good as LM and CSM systems handbooks [21:04:27] that would be awesome [21:04:34] you know what else is awesome? [21:04:47] AS-204 being in orbit [21:05:11] oh hell yeah that is awesome [21:05:28] judicious use of try/catch blocks and breakpoints. :D [21:05:47] that came pretty quickly after making it your goal for the day lol [21:05:48] also not bad, indeed [21:05:59] well, I fixed a single bug and then just tried again [21:06:11] but that one bug caused most issues [21:06:19] basically parts of the LM alone were still loaded [21:06:30] propellant, some vessel properties [21:06:48] the LM mesh was visible through the nosecap [21:06:51] not anymore [21:06:57] heh [21:07:53] nosecap separation is next, but I already implemented that a while back for the normal Saturn, so should be easy [21:08:08] and then LM separation [21:08:29] Any of you use pgp keys at all? [21:08:31] when that is all working I'll power up the LM on the ground [21:08:56] googles pgp keys. [21:09:06] no, I don't [21:09:43] Ah. I just created my key today. Need (verified) people to sign it. :) [21:10:16] nope [21:10:35] AlexB_88, I need your help for this LM project [21:10:41] flattening the terrain at LC-37 [21:11:16] I still have to move the launchpad around a bit, it's not properly aligned with the textures [21:11:23] then I'll give you the coordinates I need flat [21:13:43] good night! [22:06:48] oh man [22:06:54] Saturn V systems handbook does indeed look pretty great [22:12:23] https://drive.google.com/open?id=1a7MtC4Viq4AJk7pgyqW93XfDpDBJNiXu [22:12:53] .tell indy91 Saturn V Systems Handbook: https://drive.google.com/open?id=1a7MtC4Viq4AJk7pgyqW93XfDpDBJNiXu [22:15:19] That looks like it could contain many missing links [22:15:25] yep :D [22:34:22] interesting [22:34:32] this gives us addresses of some things in the LVDC [22:34:41] tables with "Module, Sector, Address" [22:36:39] oh wow page 206 has a very nice block diagram of the LVDC processor [22:38:24] yeah I think Niklas is going to like this [22:38:34] Sounds very nice [23:09:20] Ok I am going to try in vain to reinstall my VS [23:09:35] oh boy [23:09:36] This debug thing is really getting aggravating [23:09:48] I need to do a full uninstall though to be sure [23:10:31] what version of VS are you on? [23:10:46] 2017 15.5.2 [23:11:13] I have been having more errors than the debug the last few days though, freezing on intellisense and parsing [23:11:22] bleh [23:11:23] And when i try attaching a program to debug it doesnt do anything [23:11:40] might be getting time for an OS wipe and reinstall [23:11:44] Yeah [23:11:58] Honestly am considering it [23:14:18] Its been a little while [23:14:49] Just turns into an all day affair of hurry up and wait [23:15:06] yeah [23:15:14] I've been on the edge of doing that recently too [23:19:06] Hmm what other installs should I remove, redist packsges and sdks [23:20:38] seems like that stuff shouldn't matter.... but maybe? [23:20:49] Yeah I would think it doesnt [23:22:40] there are a lot of them [23:25:12] Reboot time back in a sec [23:55:42] Ok I probably have asked this before, but which packages/extras do i need [23:56:18] for VS? I am not the person to ask, haha [23:56:29] Well you are a big help :P [23:56:34] Where is Thymo when you need him [23:56:37] always :P [23:57:37] nobody has talked about packages/extras while I've been on this computer either [23:58:01] I suppose universal and desktop development plus the debugger and git extension [23:58:12] But do I need both universal and desktop haha [23:58:12] that sounds pretty reasonable [23:58:30] right because desktops exist outside the universe [23:58:35] I mean I have plenty of room but it is my main SSD so space is always a premium [23:59:51] and the 2015 toolset [00:00:07] 20 GB yay [00:00:31] Oh well [00:00:37] Here it goes for probably no change haha [00:00:49] wooooo [00:05:31] I deleted numerous leftover folders and registry entries [00:10:17] Wow that install was fast [00:19:13] any luck? [00:19:38] I am rebuilding now and will force a CTD and see [00:19:51] But no stuck parsing or intellisense freezes [00:32:31] No change [00:32:32] Oh well [00:34:40] :( [02:09:07] On the bright side, the heat loads by the systems appears to be working [02:09:18] My glycol starts warming up [13:25:29] Good morning [13:27:24] hey [13:28:40] oh my god... [13:28:49] that document is so good [13:28:52] it's unbelievable [13:30:04] I know I was looking through it last night :) [13:30:28] A lot of missing links I am sure [13:30:40] no EDS stuff unfortunately [13:30:50] "to be provided later" [13:31:15] Hopefully literally in our case [13:31:22] haha [13:31:49] So i played with the LM a little last night, the glycol loops respond positively to the heat loads [13:31:51] But this will already help a lot, after this Apollo 5 work I'll look what I can implement from it [13:31:55] Afternoon! [13:31:56] good to hear [13:31:59] hey Thymo [13:32:03] Good morning [13:32:34] College started again today. Had a nice break. [13:32:35] in Apollo 5 news, I implemented everything and fixed bugs until SLA panel deployment. Right now I am moving the LV to LC-37B [13:32:53] and then I can power up the LM [13:32:55] The evaporator isnt even working that hard yet so it can still take more. After an hour or two the glycol was about 55 degrees at the heating heat exchanger which is a good lower end for suit loop heating [13:33:06] great [13:33:15] Get the terrain worked out? [13:33:21] and I am sure with the still missing heat loads it gets even better [13:33:24] Exactly [13:33:38] uhh, I haven't checked yet if at these coordinates there is a terrain issue [13:33:55] Guess you will find out [13:34:06] perfectly straight [13:34:15] LC-37B is really close to LC-34 [13:34:28] so I wonder if this is in the same terrain tile as LC-34, which Alex already made flat [13:35:03] Could be [13:35:10] so that shouldn't be an issue [13:35:17] One less thing to worry about [13:35:34] LC-37 doesn't have any animations yet, but that is really low priority. AS-204 sits on the right pad and it doesn't look too bad [13:35:49] Oh for the rest of the heating we need: LGC, CDU, PSA, TLE, LCA, DSE, PTA, CWEA, RRE, INV, and ECA, plus batteries [13:36:02] that's quite a bit [13:36:06] we might be able to implement it for the ECA [13:36:08] Yeah its more than I thought haha [13:36:09] and the RR CDUs [13:36:24] there are several ECA systems though, right? [13:36:39] Yeah I am not sure what exactly gets rejected to glycol from those [13:37:23] I need to look at the ECA's again and see what parts will generate the most heat [13:40:30] my least favourite thing about Apollo 5 is the launch time. It was at around sunset and every interesting mission phase happens over the US, but in complete darkness [13:41:13] the launch itself looks amazing [13:41:16] great lighting [13:42:06] but nose cap deployment, SLA panel deployment and LM jettison all happen in the darkness. For debugging reasons I moved the launch temporarily up by about 10 hours. [13:42:51] To watch it [13:43:04] yeah [13:44:41] and because Apollo 5 will be mostly a playback mission, with the LGC and LM programer doing all of the work, I'll probably provide an alternative scenario [13:44:57] which will be a few hours earlier, so you can watch all the fun stuff [13:45:13] the DOI, PDI, lunar ascent, FITH simulations [13:45:49] Good idea [13:46:24] it might be interesting for us here to just watch the DSKY automatically switch programs [13:46:41] Yeah I would be watching that intently [13:47:00] Back in a sec [14:10:58] So there are 4 ECAs total, 1 handles des 1&2, 2 handles 3&4, 3 on bat 5 and 4 on bat 6 [14:13:33] Lots of stuff going on inside of them [14:18:07] Relays and logic etc [14:28:02] indy91: Looks like you can use git-svn to clone subversion repos. No separate svn client needed. [14:28:31] ah, good to know, thanks [14:39:50] rcflyinghokie, how many separate "boxes" is the ECA in the real LM, also 4? [14:43:30] Yeah 4 eca boxes [14:44:26] I would guess they are all next to one another on the cold plate [14:44:59] Scratch that. Apparently git-svn is broken on Windows apart from some very specific versions. [14:46:59] 1 and 2 are different from 3 and 4 as well [14:55:04] LM-1 is powered up [14:55:16] I need to add a few new things to the LM programer as well [14:55:42] the programer, commanded by Sunburst, opens the Main SOV valves and a bunch of other things that weren't implemented the last time I played with Apollo 5 [15:06:10] ah great, the Auto Throttle switch in the LM uses the same LGC input channel bit as the liftoff signal from the IU [15:06:45] the connection to the switch was probably capped in LM-1 [15:06:59] Sunburst is always in auto throttle anyway [15:08:21] Did lm1 fly with ecs? [15:08:43] yes [15:08:56] I was going through the circuit breaker and switch list at liftoff [15:09:05] nothing related to suits was powered or used [15:09:06] How did it handle ascent? [15:09:08] but glycol loops [15:09:21] In regards to cabin pressure [15:09:26] good question [15:09:42] the valves in the hatches were in auto [15:10:00] so maybe they launch at sea level atmosphere and let the auto setting do its job [15:10:04] launched* [15:10:16] That would be my guess as well [15:14:51] ok, I am in program 02 [15:14:59] aaaand it switched to P11 again [15:16:21] Its weird thinking about the lgc running those [15:16:48] yeah [15:19:43] Remind me, auto is a one way valve correct? [15:19:54] Cabin to ambient [15:21:11] So it would relieve a cabin pressure differential but not flow into the cabin if say the cabin was vented in a pressure environment [15:22:11] yeah, it only vents when the cabin pressure is higher than outside [15:24:45] Yeah so auto sounds right [15:26:07] well it is in auto. The LM-1 Systems Handbook says so [15:26:13] both hatches in auto [15:27:40] hi [15:28:11] i know i ask about the mcc1 yesterday but does anyone have a scenario file for apollo 11 prior to loi 1? [15:30:21] I dont have one handy, unfortunately [15:30:29] thats okay [15:34:57] do you have any during the trans lunar coast? [15:35:24] Well i do have some but they were made before a lot of the latest changes [15:35:39] I dont know if they would break [15:35:48] okay [15:35:50] Let me check my dropbox as i am not at home [15:35:59] I have them at home though [15:36:37] yeah, same problem here, I only have old scenarios [15:36:49] that is fine [15:39:31] and another problem is that in orbiter 2016 the sivb doesnt seem to maneuver at all to the seperation attitude [15:40:00] hmm, that is bad [15:40:06] i created the scenario using orbiter 2010 and the scenario is old [15:40:15] that will be the problem I think [15:40:26] but i have one right after docking and everything works fine [15:41:02] I bet the fairly recent changes to the S-IVB will have broken the maneuver to sep attitude in old scenarios [15:42:04] so if i started from the launch scenario (-4 hours) in orbiter 2016 im guessing everything should work? [15:42:37] yeah, those launch scenarios are always kept up to date [15:43:05] but i wouldnt need to do that cause of the scenario after docking works i just prefer the earth textures in 2016 its more realistic [15:43:23] Making some progress. Manged to remove P23, entering it now give a OPR ERR. All that is left is removing the associated code. [15:44:19] one step closer to creating Skylark, haha [15:44:50] IRC-Source_94060, if everything is right after docking, then the S-IVB changes aren't a factor anymore, yeah [15:44:57] We have quite a bit of the PCRs and the programmed guidance equations. We should be able to come close. [15:45:08] I will need to learn how to use the Interpreter at some point though. [15:45:48] And I came up with a basic idea to get to Saturn without the AGC breaking. [15:46:44] 1. TSI, 2. Disable state vector integration before exiting Earth SOI, 3. Enable state vector integration when in Saturn SOI. [15:47:10] IRC-Source_94060 nothing from the TLC on 11 in my Dropbox [15:47:13] Sorry [15:47:16] Surely we can change the parameters for the moon to Saturn. [15:48:41] that will need a scaling change as well [15:49:33] and state vector integration above low orbit has to be changed [15:49:57] between Earth and Moon it uses the gravity of Sun, Earth and Moon for the calculations [15:50:04] in low orbit it only uses Earth or Moon [15:51:15] I'm sure you can help me out a little bit. You're more knowledgeable about that stuff. :) [15:51:31] It's a problem for the future though. [15:51:51] yeah [15:52:24] so the auto throttle input bit is not what causes it to go to P11 [15:52:33] I'll have to debug this with Mike [15:52:51] it's in P02 and switches to P11 on its own after a few seconds [15:53:06] I can take a look [15:53:11] yeah [15:53:20] P02: https://www.ibiblio.org/apollo/listings/Sunburst120/OPTIMUM_PRELAUNCH_ALIGNMENT_CALIBRATION.agc.html [15:53:35] P11: https://www.ibiblio.org/apollo/listings/Sunburst120/MISSION_PHASE_2_GUIDANCE_REFERENCE_RELEASE_PLUS_BOOST_MONITOR.agc.html [15:53:56] I can't remember anymore, but there might be an acceleration monitor [15:54:03] that also can start P11 [15:55:15] "GYROCOMPASS-GRR RECEIVED OR G LEVEL EXCEEDS GLIFTOFF-START UP MP 2" [15:56:20] hmm [15:56:27] maybe the padload I am using is outdated [15:56:40] for once I didn't put in the effort to keep a reference padload [15:56:49] because I experimented with different scenarios [15:58:25] GLIFTOFF is at E3,1764 [15:58:48] yeah, the scenario has the same value as the Excel worksheet [15:58:59] I'll check if I changed the value in any other scenario [16:03:58] You can always check bit 2 of flagword1 if GRR has occured [16:27:01] yeah, the difference to my previous tests is that I had Sunburst connected to a powered up CSM [16:27:22] so there could still be some input bits that are done twice, by IU and something in the LM [16:28:46] EMEM1764 37777 [16:28:47] EMEM1765 37777 [16:29:09] so I disabled the GLIFTOFF check [16:29:16] that's from my T-20m scenario [16:29:19] still with a CSM [16:29:31] not sure why I did that, but I guess it was for a good reason [16:29:40] 37777 is negative max? [16:29:53] No, POS MAX rather. [16:30:00] That disables the check all together. [16:30:08] yep [16:30:14] and that's what I did last year [16:31:25] Are those two 1764,1765 in E3? [16:32:24] yes [16:45:28] GRR input bit was set as well [16:45:36] because that's the same bit as the Mode Select switch [16:47:05] hey [16:47:15] hey Alex [16:47:16] https://i.imgur.com/NCqfgiv.jpg [16:47:20] textures are a bit dated [16:47:25] but otherwise it looks fine now [16:47:34] oh and Alex, the terrain at LC-37 is super flat [16:47:55] Hey Alex [16:54:03] first test launch with a powered up LM! [16:54:11] indy91, great stuff [16:55:23] aaaand got a CTD [17:00:01] the glycol temperature is also pretty high and I got a IMU TEMP light shortly before liftoff [17:00:10] maybe because I am sitting in the sun the whole time? [17:02:04] maybe I didn't properly active the ECS, also very possible [17:05:53] Hmm well a sublimator wont work in atmosphere [17:06:03] So you have no cooling [17:06:32] Only radiative cooling is possible until you are in a vacuum [17:08:21] I'm not sure that is all simulated [17:08:36] it could be a configuration issue [17:08:52] I only had the primary evaporator no. 1 open [17:09:28] secondary glycol pump was activated at launch, so I probably should open all the things, at least for the descent stage [17:13:04] So the evap can work in atmosphere? [17:13:30] And yeah sec loop means the breaker, water tank to sec, and sec evap open [17:13:40] the LM isn't connected to any atmosphere [17:14:02] we probably should rework the VENT class to simulate the outside conditions [17:14:06] What about the evap code [17:14:07] but I don't think that is currently done [17:14:54] ah, I didn't know that [17:15:01] parent->Vessel->GetAtmPressure() > 30000.0 [17:15:06] you know this code better than me [17:15:15] so I guess I kind of need GSE... [17:16:50] I think I have a coordinate system problem with my Apollo 5 launch [17:16:50] Yeah i never considered the atmosphere part for the lm [17:19:46] when it comes to connected tanks though, then the outside atmosphere probably doesn't matter [17:19:58] so if you open the hatch valves it probably dumps everything to vaccum [17:20:59] So the cabin would dump in atmosphere [17:21:09] Because it doesnt consider it [17:22:35] yeah, I think so [17:22:50] haven't properly tried it though [17:22:58] http://nassp.sourceforge.net/w/images/1/1e/CSM_systems_diagram.gif [17:23:10] EARTH is a special tank in that case [17:24:42] Yeah i remember seeing that in the csm systems [17:25:01] Guess it needs to go in the lm as well for this case [17:26:06] I'd rather implement a special tank class for "outside", whatever that may be [17:26:19] less hacky [17:26:39] That sounds good [17:32:32] But in regards to the operating lm for launch, what kept it cool i wonder. Just radiating heat? [17:32:46] temperature is coming down in the higher atmosphere [17:32:51] GSE probably [17:34:28] Ah yeah [17:34:42] glycol temperature back in green band [17:34:49] just 3 minutes after liftoff [17:35:07] and the TEMP light probably will follow shortly [17:35:55] Yeah theres a gse port on the glycol loops [17:36:02] Which makes sense [17:36:24] you can add some minimal support for it, if you didn't already [17:36:32] and then I would add the rest to LC-37 code or so [17:36:39] I havent yet [17:36:54] But the sec loop has a gse inlet and outlet [17:37:04] So probably cooled via gse [17:37:27] Prim has the same ports inlet and outlet [17:38:42] TEMP light is out [17:38:57] so all nominal again [17:39:19] Glad the cooling can handle the high temps [17:40:35] good insertion [17:40:40] LGC switched to P13 as expected [17:41:02] now a lot of coasting [17:41:10] Looking at the schematic the gse bypasses the pump in the lm more evidence that it was cooled on the ground [17:41:15] Great! [17:42:09] but this coordinate system issue will be really bad. Essentially, the Saturn/CSM use different orientations of the coordinate axes. [17:42:19] And a flag in our IMU code deals with that for the IMU [17:42:47] but when the LM is separated, it will be rotated by 90° from what it actually should be [17:43:10] Makes sense of course [17:43:35] to get a good ascent to orbit I already had to do a hack [17:43:48] IMU orientation like a CSM, but PIPA rate like a LM [17:44:06] but I also can't really rotate all the meshes of the Saturn stage [17:44:13] then I would get the same issue, just with the LV IMU [17:44:55] I'll have to think about this for a while I guess :D [17:45:03] but first, LM/SLA separation test [17:45:05] Yeah [17:45:47] Did the sla panels jettison for apollo 5 or was it a total fairing [17:46:32] 45° angle, no jettison [17:46:34] I think [17:46:40] that's what I am doing right now at least [17:47:02] morning! [17:47:17] oh good, our LV IMU code is derived from the AGC IMU. So I would be able to give it the same LM Flag, if I wanted to rotate the whole coordinate system of this [17:47:19] hey Mike [17:47:24] what's up? [17:47:27] just launched Sunburst [17:47:38] turned on this time? :D [17:47:41] yep [17:47:43] awesome [17:47:44] with a powered up LM [17:47:48] Yeah the sla panels werent jettisoned till 8 [17:47:57] ran into some of the same issues as last year [17:48:07] because I was starting with an old-ish padload [17:48:14] haha [17:48:23] I just didnt know if the aero shroud/fairing jettisoned in a different way [17:49:28] the nose cone was of course jettisoned [17:49:40] shortly after orbital insertion [17:50:04] but the SLA is like on Apollo 7 [17:50:11] just, you know, working properly [17:50:25] Haha right [17:53:15] indy91: how's that new systems handbook? [17:53:34] too good [17:53:53] so I didn't look at it in detail, or else this Apollo 5 work will not get done [17:54:06] but it's amazing [17:54:24] :D [17:54:29] excellent [17:55:54] I was surprised at the detail in some parts... like the graphs of current drawn from each individual battery throughout the mission, with all of the events marked, heh [17:57:39] yeah, and it has the complete list of switch selector events [17:57:47] and so many schematics that will be useful [17:57:51] especially the S-IVB [17:58:13] sweet [17:58:46] and the good news (for you, bad news for me) is that there are several of these at NARA [17:58:53] I don't remember exactly which missions [17:59:53] hmm [18:01:33] I don't need many other missions [18:01:36] AS-508 and subsequent, AS-504, a preliminary Saturn IB, AS-505 and subsequent, SL-1, SL-2,3,6,4 [18:01:38] but this AS-503 is missing sections [18:01:45] like the EDS [18:01:54] yeah [18:03:06] let's see what happens at LM/SLA separation right now [18:03:12] I hope funny things [18:03:16] haha [18:03:37] commanded by Sunburst of course [18:03:46] and I still have a lot of other things to add to the programer [18:05:16] S-IVB deployed the SLA panels, which it of course shouldn't do [18:05:24] but as I expected, the LM is in the wrong orientation [18:06:38] and it looks like there a ASTP docking module in the S-IVB [18:06:45] https://i.imgur.com/az6jtNX.jpg [18:06:59] but it worked, in principle [18:07:12] heh [18:07:12] a powered up LM launched and jettisoned [18:07:24] and sunburst commanded the separation? [18:07:27] yep [18:07:32] that is friggin awesome [18:07:33] :D [18:07:34] I added that to the programer [18:08:26] yeah, very promising. I think Apollo 5 will be possible to fly soon [18:08:46] \o/ [18:13:14] the AS-503 Systems Handbook is for Mission D [18:13:26] it has description for those timebases [18:13:43] did they switch the IU or LVDC between AS-503 and AS-504 at some point? [18:14:17] or maybe the software of AS-503 actually supported such a mission [18:14:18] hmm [18:15:19] that is a good question [18:21:18] from one of the NARA indexes [18:21:50] "This mission was also referred to as Mission C and C' [Mission C Prime] Apollo 7, CSM 101, AS-503 and some documents were formerly Mission D." [18:22:14] that is a note for the AS-205 mission documentation group [18:22:23] Mission C was Apollo 7 [18:22:26] C prime Apollo 8 [18:22:56] Mission D is Apollo 9 [18:24:09] https://www.hq.nasa.gov/pao/History/SP-4009/v4p2n.htm [18:24:11] on August 19: [18:24:22] Assignment of Saturn V 503, CSM 103, and LM-3 to Mission D was canceled. [18:24:22] Saturn V 503 would be prepared to carry CSM 103 and LTA (LM test article)-B on a manned CSM-only mission to be designated the C prime mission. [18:24:38] so yeah, AS-503 was originally supposed to be used for Mission D [18:26:17] those sections in the Systems Handbook might be outdated then [18:26:33] but still, Apollo 8 and 9 potentially flew the same LVDC software [18:26:53] possibly yeah [18:27:21] although based on that program development document that arrived yesterday I would be surprised if any missions were identical [18:27:34] true [18:27:57] there are at least missions where from all I know they could have been identical [18:28:00] minus bug fixes maybe [18:28:09] 10-11, 12-14, 15-17 [18:28:15] those maybe were identical [18:28:28] but does your new document say about this? [18:28:50] I'll scan/take pictures of it [18:29:02] but there was a lot of required iteration getting to the final flight program [18:29:40] a "Level I" program was released at the same time as the EDD, which was pretty much the previous mission's program [18:30:04] that went through reviews and got inputs on data for the particular stages, and that was fed into a Level II program [18:30:17] and then more things had to happen for that to become the final flight program [18:33:55] there is an IBM document that I am very curious about now [18:34:04] number 67-F11-0012 [18:34:16] entitled, simply, "Saturn V Vehicle Flight Program", for AS-503 [18:34:49] but of course there are no google results for any combinations of that [18:35:13] sounds like it could be something [18:35:20] is that at NARA? Or is the number all you have [18:35:32] it was one of the references in the appendix for the document I got [18:35:46] so the number and title are all I have [18:43:38] Hey Mike o/ [18:44:01] Managed to deregister a MM in Artemis. It triggers a OPR ERR now. [18:44:25] Also, there's a message hanging around in the backlog. [18:45:23] I also added a --noresume option to yaAGC in my fork. That causes the loading of erasable memory to be skipped even if a core file exists. [18:45:41] Would there be any interest in PRing that back to upstream? [18:48:33] why not just remove the core file? [18:51:48] It also prevents a core file to be created. I kept finding myself running yaAGC while I still had a core file I didn't know about. It can also be useful if you want to test something with fresh memory without deleting/renaming the core file. [18:52:10] for your backlog comment, I'm sure code cleanup would be appreciated, but you'll have to ask Ron what his opinion on formatting is [18:52:38] okay, go ahead and pull request it if you think it's useful [18:56:19] Cool. I'll ask Ron. [18:57:22] I have had occasional problems with that, as well, if I'm switching between significantly different programs like Aurora and Luminary [18:57:58] I figure I need to be getting used to it, though, since once I have a physical AGC resetting all the cores isn't as easy as deleting a file :P [18:58:25] Haha. Definitely not. [18:59:58] I think I'm going to need a monitor working before I can properly run any code [19:00:16] because upon construction, every word has a 50% chance of having a parity error and causing a restart [19:01:01] so something needs to inhibit alarms and walk through and at least correct parity [19:03:18] What causes the 50% change of parity errors? [19:04:42] well, every core I wire in is going to have a pre-existing polarity and there's a 50/50 chance for a 1 or a 0 on each [19:04:58] and a 50% chance that any given word will have an odd number of ones, I figure [19:05:19] roughly at least [19:08:32] Oh right. So you'll only have to run through it the initial time after construction? Well, I suppose also when you are resetting it again. [19:10:29] hm? [19:11:07] oh, you mean, if I try to do the equivalent of deleting the core file [19:11:14] Yeah [20:51:50] https://www.nasaspaceflight.com/2018/01/spacex-static-fire-falcon-heavy-1/ [20:51:54] FH static fire possibly tomorrow :D [21:02:10] great [21:02:20] we will probably not get to see it live I guess [21:03:06] hmm, why not? [21:03:20] er [21:03:25] yeah I guess they don't normally stream those [21:03:28] nevermind, brain fart [21:04:39] NASA would stream it [21:05:07] private companies, not so much [21:12:53] hmm, this coordinate system issue is pretty tricky to solve [21:17:15] oh, seems like that was also an issue with jettisoned SLA panels [21:17:20] so maybe I can learn from that code... [21:58:38] night [22:00:00] macieksoft just posted this https://www.youtube.com/watch?v=5lpKMvlFVtQ [22:13:02] Hey Alex, havent crossed paths with you in a bit [22:21:12] hey Ryan [22:21:21] Just trying out the latest state [22:27:28] Yeah I have thrown a bunch of heat loads into the LM [22:27:43] Still a lot to adjust as far as valve sizes [22:27:59] But it does heat up, and the IMU and ASA have the heaters running [22:28:41] I want all the systems generating heat before I start adjusting valves for flows and such for pressurization in order for the thermo to be correct [22:33:04] The LGC is going to be the biggest pain for heat loads because so many systems in the cold rails are powered through the LGC [22:33:18] powered through the LGC? [22:33:39] Things like the CDU and PSA and PTA I think [22:34:07] reeeally [22:34:08] interesting [22:34:20] I knew the DSKY EL was powered through the AGC but didn't know about the others [22:34:22] what even is the PTA? [22:34:55] Pulse torque assembly [22:35:38] oh right [22:39:15] I need to learn how the PSA plays into the LGC [22:39:27] Because it gets power from both IMU breakers and the LGC breaker [22:40:30] The CDU gets power from the PSA [22:40:55] And so does the PTA [22:42:06] And PSA gets at least some power from the LGC [22:42:33] If you have some free time and want to decypher it that would be a big help :) [22:44:37] The LM AOH has some good info on it [22:45:05] But the real trick is to implement those systems first, get the power distribution right, and then add heat loads [22:45:31] Oh AlexB_88 I meant to ask you, do you know how to add a light to the exterior of the LM? [22:45:43] I want to implement the tracking light electronics [22:52:16] rcflyinghokie: ND-1021042 and ND-1021043 have sections dedicated to the PSA which I have not read [22:52:20] there are probably lots of answers there [22:52:51] I think I would want the ajacent systems implemented too before doing power and heat [22:54:36] I know Nik wanted to add real CDU's [22:55:09] yeah, that will happen along with my AGC counter overhaul I think [22:55:29] Ok I can wait for those [22:55:42] I think I am going to do tracking light next, seems easy [22:55:47] rcflyinghokie, I can definitely give it a try [22:55:55] Awesome [22:56:06] Its pretty simple on the LM side [22:56:24] Just wiring it to the breaker and switch, and adding heat to the glycol [22:56:34] Just need the switch to actually activate a strobe on the LM [22:57:07] Niklas and I were also discussing building a lighting control assembly [22:57:39] And getting more LM lights working of course [22:57:54] The LCA controls all lights but utility lights and the tracking light [22:58:08] The utility lights need their own panel similar to the ordeal panel [23:01:00] When Thymo is completed with the CWEA I will add heat to it as well [23:01:43] Then we need to figure out batteries, make ECA logic, and inverter heat all based on current flow [23:17:15] I'll try to get it done soon. Progress has been slowed than I'd like. [23:17:20] I'm off to bed. Goodnight. [23:17:23] No rush [23:17:26] Bight! [23:17:27] Night [23:18:48] .tell indy91 before I forget to ask you tomorrow, but is there a debug line we can use to display the total amount of heat given to the glycol loop? Or at least how much heat is being generated in total? [23:20:43] Hmm I wonder what is included in the RRE [23:28:54] Shaft and trunnion cosine and sine resolvers, servo amps, xpdr mode range tracker, freq trackers, and all the outputs for the test monitor [23:31:21] I need to see what all is implemented for the RR [23:31:57] hmm [23:32:07] I wish C had more tools for playing with bits [01:50:38] A long shot...but would anybody have a good resource for the approximate internal volume of a PGA? [02:19:25] doesn't know what a PGA is [02:21:08] Pressurized Garmnet Assembly....the suit [02:21:12] Garment* [03:46:01] .tell rcflyinghokie Volume of a PGA? Depends on the size of the occupant. Generally, 2 ft^2 of "air" volume while occupied. Estimating based off of the ACES suit made by Hamilton Standard/ILC and you won't go too wrong. (https://history.nasa.gov/spacesuits.pdf) Comparison pics look "close enough" and it makes sense to keep the free volume and presure as low as possible to keep the joints from [03:46:02] being too difficult to bend. [03:58:45] .tell rcflyinghokie page 8, btw. [11:22:01] hi [12:10:29] . [12:59:35] Morning [13:00:40] hey [13:02:12] I am glad I sent you a message with Guenter, because I cannot remember what i asked :P [13:02:40] total amount of heat given to the glycol loop [13:02:54] no, there isn't an easy way to have a debug string for this [13:02:59] Ah yes [13:03:09] although, a hacky one maybe [13:03:32] What about through hsysparse? [13:03:54] but what do you want to ask it there? [13:04:19] How much heat is being loaded to a certain heat load [13:04:25] Then I can just add them in a debug line [13:04:25] that can be done [13:04:31] but there are a lot of heat loads [13:04:35] Yeah I know [13:04:45] yeah, asking that load is no problem [13:04:47] I figure this is the most minimally invasive way [13:04:55] I can add that [13:05:23] That would be helpful [13:07:35] I'll name it HEAT [13:08:10] Logical [13:08:23] the location of that debug string will be critical though [13:08:38] because the load gets reset to 0 every timestep [13:09:14] ah [13:09:17] just at the usual spot [13:09:32] where all the ECS debug lines are [13:09:34] lemsystems? [13:09:38] yes [13:09:41] Great [13:09:53] These are double values? [13:09:55] that is AFTER all the systems timesteps, but BEFORE the Panelsdk timestep gets called again [13:10:03] yes [13:10:41] update pushed [13:10:44] Thanks [13:12:12] That will help me once more systems are in place [13:13:53] I've made some more progress with LM-1 [13:14:04] but now I am confused how it was mated in the SLA [13:14:21] our LM-1 mesh might be wrong [13:15:37] I mean it looks the same as any other LM [13:16:08] The bottom of the DPS engine bell is about flush with the bottom of the SLA [13:16:22] Maybe a little below [13:16:23] https://www.nasa.gov/sites/default/files/thumbnails/image/lm-1_being_hoisted_onto_saturn_1b.jpg [13:16:26] yeah, but how is it rotated? [13:16:54] in which direction relative to the S-IVB is the forward hatch/windows pointing? [13:17:10] might just be our wrong mesh that is confusing me [13:17:15] it is rotated by 45° [13:17:16] Oh i see what you mean [13:17:37] I'll load our usual LM in SLA mesh once [13:17:48] just to reduce the confusion, maybe :D [13:18:07] https://upload.wikimedia.org/wikipedia/commons/7/78/Lm1_ground.jpg [13:18:16] Looks like the hatch is lined up with a hinge [13:24:24] in the usual orientation we use, the LM would point the forward hatch "up", while the S-IVB is still doing orb rate [13:25:47] so maybe it's just our LM-1 mesh that is wrong [13:26:00] Could be [13:28:05] our LM-1 mesh is outdated anyway. And it looks quite different, so at staging we would suddenly have the newer ascent stage [13:28:26] so I'll probably ask Alex to make a mesh out of our usual LM, but without legs [13:30:43] and then I need to do some hacky things with the IMU, so that it has the right orientation [13:30:46] maybe [13:31:08] most other issues are solved, the LM already separates itself and continues flying as normal [13:32:11] the list of Saturn issues becomes quite short. And after that all I have to do is padload tweaking [13:36:59] Very cool [13:39:47] hmm, it's actually pointing the right part of the LM at the sun during the DPS cold soak period... [13:39:55] I just let this play out for once [13:40:10] if it orients itself correctly for the first DPS burn then maybe I don't have to fix anything [13:41:31] Might as well try haha [13:41:41] hmm [13:41:45] ECS just went crazy [13:41:48] Oh made a minor PR for my little list of ECS tweaks [13:41:56] How so [13:42:08] I don't see any needles anymore [13:42:22] Uhh [13:42:25] Weird? [13:43:11] Brb [13:43:22] ECS is all NaN [13:48:17] Back [13:49:28] all the needles went offscale and the tanks have NaN substances [13:49:41] reloaded the scenario, now watching again what happens [13:50:04] glycol and atmosphere are looking all goo [13:50:05] good [13:50:10] all in the green band [13:50:18] Glitch then? [13:50:56] maybe just the general instability of the glycol at 10x [13:51:10] Very well could be [13:51:19] That will ve worked on soon [13:51:20] Be [13:51:29] I don't think the glycol loops can survive TLC right now [13:51:40] I'll watch it for a while [13:52:09] The debug lines for heat work well [13:52:38] great [13:58:40] Do you think the moving things to post step will help [14:01:29] to pre step [14:02:06] yes, it might a little bit. Having the timesteps in the wrong function is making our accelerometers fairly unstable. [14:02:06] Yes [14:02:25] so, maybe it has that effect as well on the systems SDK [14:02:59] Now that there is some heat i am going to start making more ecs adjustments [14:03:15] I had no luck pressurizing the lm from the cm though [14:03:26] takes too long I guess [14:03:29] Yeah [14:03:48] The direct o2 change doesn't help much because of the way its plumbed [14:04:11] yeah [14:04:47] ah, so I just had a small freeze, as can happen when Orbiter loads new planet textures [14:04:56] that make the ECS pressure go to almost 0 [14:05:00] made* [14:05:03] it recovered this time [14:05:08] but maybe it doesn't always [14:05:12] Interesting [14:05:32] the timestep became too long for the glycol loop I would guess [14:06:24] it doesn't like that, hence the issues with time acceleration [14:08:22] I forgot how exciting 3 hours of coasting is... [14:08:42] Wooo [14:08:50] those 3 hours were the most useful period for PGNS testing during the actual mission [14:08:58] because the DAP was doing attitude holding [14:09:24] What about ags? [14:09:35] no AEA and no ASA on LM-1 [14:09:52] Ah [14:09:59] so the ATCA did most of the work after the issue with the first DPS burn [14:10:07] and not the DAP or LGC anymore [14:12:15] I keep forgetting to make that docked dps video [14:12:26] Ecs sidetracked me [14:13:41] see, this is why I don't even want to look at the Saturn Systems Handbook right now [14:13:56] because I am sure I will find 50 things I would want to change immediately [14:22:42] Haha i bet [14:24:00] I guess i can do the video with apollo 9, i really wanted it for 13 pc+2 [14:33:54] about your PR [14:34:22] I don't like having 100 debug pointers being set in every timestep [14:34:52] that's why I commented them all out since we merged the ECS into the Orbiter2016 branch [14:35:57] so, it's fine adding more lines, but I would prefer them to be commented again in PRs [14:38:27] Oh i totally forgot to comment them back out! [14:39:02] I will fix that when im back on my computer [14:39:21] great [14:42:27] Since the RR is implemented, would it be ok just to add the heat load for the RRE to add heat whenever the RR is on? [14:43:00] sure, just add a comment that it needs to be improved [14:43:13] time for this DPS burn. Let's see if the IMU has a good alignment [14:45:39] seems fairly good [14:47:50] off in yaw maybe [14:49:32] and I kind of got the same issue as the real mission [14:49:41] DPS propellant wasn't pressurized [15:01:12] Haha [15:01:24] Didnt the real one swallow helium? [15:02:04] And i will do that for the RRE and i can make sure the implemented heaters work [15:02:12] For the LR as well [15:02:18] Do they draw power? [15:05:12] helium pressure didn't rise quickly enough, because the system only fired the pyros for the helium valves at ignition + 1.3 seconds [15:05:38] but I wonder, there are 3 sets of explosive valves for the DPS. I have to research which ones were opened on the ground already. [15:06:14] this DPS burn was exactly in the right direction, but I can't remember if it also had such a weird yaw angle when I tried this last year [15:11:14] Oh Alex said he would look into lighting so maybe we can implement the TLE soon [15:12:24] great [15:12:32] let's see what this DPS-2 is doing [15:12:53] I didn't even properly remember what that burn did [15:13:20] but it's the long DPS burn, followed by a throttle command test, followed bit FITH, followed by a short APS burn [15:13:29] that's the most fun burn for sure [15:24:10] A lot going on haha [15:27:13] Hey [15:27:26] Hey Thymo [15:28:36] What's up? [15:29:44] Thinking about what systems can take heat next [15:30:01] Nice. [15:31:12] I'm working on a webshop I need to build for a college project. Fun project ...If the HTML/CSS want to cooperate. [15:31:43] hey Thymo [15:31:51] DPS-2/FITH/APS-1 worked perfectly [15:32:06] Sweet [15:32:26] that was just meant for the general chat, not directly at you, haha [15:32:44] but this is with my current state of a Saturn launched LM [15:33:15] so already working quite well [15:36:12] Sweet nonetheless [15:36:29] yeah [15:36:39] I'm eager to test the contingency orbit insertion next [15:37:01] That will be cool [15:58:20] Debug pointers are commented out [16:24:12] merged [16:40:17] I still am having a hard time finding temperature ranges for the RR [16:40:53] The power/heat table shows the STBY heater range between -40 and 0 F and the opr heater from -10 to 20 F [16:41:36] And the CWEA limit is -54 to 148 F [16:42:04] So I guess as long as it is between -10 and 148 it is ok to use? [16:43:24] Interesting that the stby heater is 10 heat watts but draws 81 power watts whereas the opr heater is 50 heat watts yet draws 29 W [16:54:42] Hmm there are multiple heaters in the RR assembly [16:55:35] Gyro heaters, X96 multiplier heater, shaft wrap heater, driver/RF heaters and shaft motor heater [16:56:05] that's a lot of heaters [16:56:08] Yeah [16:56:19] The X96 is the most sensitive it looks like [16:57:13] it's heater activation points are "survival: -40 to 0 F and preoperational 18 to 44 F" [16:58:37] I think for now I will use the limits on the cb chart [16:59:12] Since we only have one radiator for the RR antenna [17:02:35] Now I need to find a normal operating range [17:04:14] Ah I know why there is less used for the OPR heaters [17:04:33] There are more standby heaters than operation heaters [17:27:00] ha, Apollo 5 had a countdown hold, because the glycol temperature didn't become cold enough [17:27:29] GSE issue [17:37:07] Haha just saw the glycol message [17:43:20] the issues on the real mission and the ones I am getting are getting kind of similar... [17:43:44] oh about the explosive DPS valves. These were all wired together to the Engine Start + 1.3 seconds signal on LM-1 [17:44:00] hence the issue with the slow propellant pressure buildup [17:45:46] on the later LMs you manually open the propellant isolation valves and the ambient helium valve before the burn [17:49:51] hmm [17:50:03] I don't think there even was a ambient helium bottle on LM-1 [17:50:12] that one gets only used for the initial pressure anyway [17:50:19] Looks like there is just a wireto for the rr heater breakers, no power draw from what I can see [17:50:20] so maybe that was added exactly because of this issue [17:50:31] Could be [17:53:29] morning! [17:54:22] Good morning [17:54:47] indy91 should I add an ispowered for the rr heater breakers? [17:55:03] There currently is one for the dc and ac for the RR itself [17:55:13] But not the heaters from what I see [17:58:11] sure [17:58:17] IsHeatPowered or so [17:58:20] hey Mike [18:02:33] the AGC is confusing me again [18:03:09] all of the documentation suggests that counter increments are higher priority than restarts but that is very much not what I am seeing [18:10:58] weird [18:12:01] thewonderidiot, Apollo 5 update. LM is separated in the right attitude now. Still has legs. I thought that the IMU must still be messed up in some way, but I already flew a sucessful DPS-1 and DPS-2/FITH/APS-1 already with it [18:12:12] same resulting orbital parameters as I had last year [18:12:58] nice!! [18:13:31] :D [18:14:22] so what's next? [18:17:14] I'd like to try a contigency orbit insertion [18:17:37] and I still have to fine tune the padload a bit, I think [18:17:53] and still a short list of Saturn issues [18:18:35] so, how does one send an unused DSKY key code? [18:18:41] because that is how you start the abort [18:18:58] same as you would send any other keycode, through uplink [18:19:05] code 23 for an suborbital abort, where it does a few DPS and APS tests, just so that the mission isn't completely lost [18:19:10] and 24 should get the LM into orbit [18:19:44] but what is the code 23 or 24? [18:19:47] as an example [18:20:02] this is the code for ENTR [18:20:03] case 'E': // 11-110-000 01-111-100 [18:20:03] cmdbuf[1] = 0360; [18:20:04] cmdbuf[2] = 0174; [18:20:04] break; [18:20:33] where cmdbuf is a byte array? [18:21:14] and you generate an uprupt after you do that right? [18:21:17] that's from our function to encode a DSKY input [18:21:25] send_agc_key(char key) [18:21:49] and then follows a list with all DSKY keys and their codes [18:22:31] if it is like a key, then all I have to add is that sequence above for codes 23 and 24 [18:22:49] sure, but I need those two questions answered first :) [18:23:03] unsigned char cmdbuf[4]; [18:23:15] 4 bytes? interesting [18:23:31] I'll have to search through this code, I never really looked at it [18:23:35] so I don't know what bytes 0 and 3 do [18:23:38] to find any place for an uprupt [18:23:59] I just copy&pasted this from the PAMFD to the RTCC MFD 3 years ago or so :D [18:24:09] but when you're uplinking DSKY keys, the format is KK/K (the second K is inverted) [18:24:16] if (vesseltype > 1){ [18:24:17] cmdbuf[0] = 031; // VA,SA for LEM [18:24:17] } [18:24:18] else{ [18:24:18] cmdbuf[0] = 043; // VA,SA for CM [18:24:19] } [18:24:30] so the top 5 bits are the keycode, next 5 bits are it inverted, and then the last 5 bits are the keycode again [18:25:06] so byte 0 is for CSM vs. LM [18:25:32] I'm not sure we use byte 4 in any way [18:26:22] 3* [18:27:25] so the keycode for ENTER is 34 [18:28:01] yep [18:28:45] so the uplink keycode for it would be [18:29:01] 11100 00011 11100 [18:29:18] Is the wire to needed anymore in the init? [18:29:19] HTR_RR_OPR_CB [18:29:21] and there is typically a leading 1 on that to appease the AGC hardware [18:29:27] Not that [18:29:27] if(lem != NULL){ [18:29:28] stbyantheater->WireTo(&lem->HTR_RR_STBY_CB); [18:29:29] } [18:29:43] and I think that matches what you have there [18:30:59] rcflyinghokie1, you only have to wire it to the CB once [18:31:16] either in the Init function or in the system (RR) itself [18:31:26] ah, a leading 1, ok [18:31:58] .py oct((1 << 15) | (0o23 << 10) | (0o14 << 5) | (0o23)) [18:32:35] so that would be the word you want to send [18:32:39] 11-001-101 10-010-011 [18:33:22] 0315 and 0223? [18:33:26] that#s what I got... [18:33:30] that's* [18:33:46] 023 in binary is 10011 [18:34:08] yep, those are the numbers I get as well [18:34:53] .py oct((1 << 15) | (0o24 << 10) | ((~0o24 & 0o37) << 5) | (0o24)) [18:35:34] indy91, ok so I can remove those lines I typed if it is already wired in the systemsinit? [18:35:40] 0321 and 0164 for code 24 [18:35:51] .py print oct(0150564 >> 0xFF), oct(0150564 >> 8) [18:35:58] whoops [18:36:02] rcflyinghokie1, yeah, I think the systems init is the better place for that [18:36:08] .py print oct(0150564 & 0xFF), oct(0150564 >> 8) [18:36:18] yeah [18:36:25] Thats what i thought [18:36:31] It was done in both places [18:36:45] So I will remove the other one [18:36:49] yep [18:37:26] next I have to figure out how to send ground commands for the nose cap and SLA separation [18:37:31] the timing is pretty tight [18:38:01] ah, ground has to send those? [18:38:21] in the case of an suborbital abort or COI yes [18:38:43] the nominal times for it are 45 seconds and 100 seconds after orbital insertion, respectively [18:38:48] that is not quick enough [18:39:06] gotcha [18:39:09] I have a timeline from the RTACF handbook for Apollo 5 [18:39:47] although, I don't know at which point in there the command to the LGC is sent [18:41:31] for the COI, the LM/S-IVB separation is commanded 40 seconds after S-IVB shutdown [18:41:45] and that is coming from the LGC [18:57:29] http://www.ibiblio.org/apollo/Documents/Verification%20Results%20Summary%20for%20LM-1%20Mission.pdf [18:57:35] do those timelines have anything helpful? [18:59:12] yes [19:05:17] Teaching the PAMFD to sent such a simple sequence is surprisingly complicated [19:06:13] hehehe [19:06:35] it needs the whole infrastructure of a new uplink type [19:06:43] and then just sends a single code [19:09:15] indy91 I think we talked about this before, but arent all the circuit breakers wired to their busses in lempanel? [19:09:25] Making all those wireto in the init redundant [19:09:40] yep [19:10:12] all WireTo of circuit breakers at least [19:10:42] So I dont even need that [19:10:52] HTR_RR_STBY_CB.MaxAmps = 7.5; [19:10:53] HTR_RR_STBY_CB.WireTo(&CDRs28VBus); [19:10:54] HTR_RR_OPR_CB.MaxAmps = 7.5; [19:10:54] HTR_RR_OPR_CB.WireTo(&CDRs28VBus); [19:10:58] That is in Lemsystems [19:11:13] And the breakers are also wired up in lempanel [19:11:20] those should be redundant [19:11:26] Oh ok [19:11:30] just check if the MaxAmps is the same [19:11:32] then you can remove them [19:11:49] The amps is actually incorrect in lempanel [19:12:00] But yeah this is in lempanel [19:12:01] HTR_RR_STBY_CB.Init(67, 0, 29, 29, srf[SRF_CIRCUITBRAKER], srf[SRF_BORDER_29x29], Panel11CB3SwitchRow, &CDRs28VBus, 5.0); [19:12:01] HTR_RR_OPR_CB.Init(131, 0, 29, 29, srf[SRF_CIRCUITBRAKER], srf[SRF_BORDER_29x29], Panel11CB3SwitchRow, &CDRs28VBus, 7.5); [19:12:30] then they need the right value [19:13:21] but I wouldn't mass delete the WireTo [19:13:33] could accidentally break something [19:14:13] I wont [19:14:25] Thats why i was suggesting before one system at a time [19:14:33] But I will leave those for now [19:20:26] so which MaxAmps is correct then? [19:28:57] thewonderidiot, Sunburst will start the orbit program P13 after the early S-IVB shutdown [19:29:14] indy91, the 7.5 is the correct one [19:29:14] is there any restriction for how long you can still call a suborbital or COI abort? [19:29:33] you mean, in the code? [19:29:41] yeah [19:29:57] it will switch to P00 after a while in P13 [19:29:59] Also, if I have the power in the systems config, I dont need to tell it to draw power in the timestep (for the heater) [19:30:03] so maybe it still has to be in P13? [19:30:34] rcflyinghokie2, you need to tell it to draw power on every timestep [19:30:47] doesn't matter where, but in the SystemTimestep of each system would be the best [19:31:10] But the heater has an electrical draw in the config [19:31:10] so then the question is when exactly it will accept keycodes 23 and 23 [19:31:19] *24 [19:31:31] Wouldnt the wire to simply draw that power from the proper bus? [19:31:50] This is for a heater (boiler) not a heat load [19:33:37] oh [19:33:44] yeah, it draws power in the boiler code [19:34:23] so that is taken care of [19:35:02] damn IU is too realistic. Command uplinks are disabled by default. [19:35:22] but probably not on AS-204 [19:35:31] now whose fault is that I wonder :D [19:36:02] yeah, me implementing the Digital Command System [19:36:33] so let's see [19:36:49] it uses flagword 2 bit 10 to make sure it doesn't process multiple uplinked abort keycodes [19:37:07] it also checks flagword 2 bit 9 to see if aborts are enabled [19:37:16] if (IsHeaterPowered()) [19:37:17] { [19:37:17] antheater->SetPumpAuto(); [19:37:18] } [19:37:18] if (IsSTBYHeaterPowered()) [19:37:19] { [19:37:19] stbyantheater->SetPumpAuto(); [19:37:21] } [19:37:21] and then it just goes [19:37:23] Is that all I need for those [19:37:31] Sorry to jump in the middle [19:38:14] rcflyinghokie2, where is that code? [19:38:27] RR timestep? [19:39:18] that doesn't look right [19:39:26] bit 9 is enabled in "POSTLET" [19:39:27] what does IsHeaterPowered() all do [19:39:34] POSTLET is P12 [19:39:42] RR SystemTimestep [19:39:43] it switches automatically after a set time from P11 [19:40:02] And bool LEM_RR::IsHeaterPowered() [19:40:03] { [19:40:03] if (lem->HTR_RR_OPR_CB.Voltage() < SP_MIN_DCVOLTAGE) { return false; } [19:40:04] return true; [19:40:04] } [19:40:18] I don't think you need any of that code at all [19:40:25] the boiler code checks if it has power [19:40:32] Oh really [19:40:39] well it has to draw power from it [19:40:41] it doesn't disable the command monitor until MP6 [19:40:51] if (SRC->Voltage() < SP_MIN_DCVOLTAGE) { //or unload if no power. [19:40:52] pumping = 0; [19:40:52] return; [19:40:53] } [19:41:09] which is P13 [19:41:19] thewonderidiot, MP6 is the coasting. [19:41:45] the abort test has it switchting to P13 before initiating the abort [19:41:49] hmm [19:41:52] MP6A specifically [19:41:56] rcflyinghokie2, is there any additional logic to the heaters running? [19:42:01] No [19:42:11] well, then it should also be in auto mode I guess [19:42:15] it's the first thing MP6A does, and MP6A is waitlisted to run 1 minute after the switch to P13 [19:42:16] Just powered or unpowered with the temperature switches in the config [19:42:27] you don't even need to do that in the init function [19:42:33] just set it to 1 in the config [19:42:48] so, from the start of POSTLET to 1 minute into P13 is when both are accepted [19:42:57] ah, so 1 minute [19:43:07] Ok then how do I wire the boiler to the breaker to make it on or off [19:43:21] 1 minute after P13 is started, which happens when the LGC notices that the acceleration from the S-IVB is missing [19:43:34] rcflyinghokie2, just one WireTo in the init [19:44:44] possibly sooner, if the LGC takes a restart, but let's not plan for that :P [19:45:16] yeah, so the nominal timeline wouldn't work, SLA panel set at 100 seconds after cutoff [19:45:22] sep* [19:45:55] rcflyinghokie2, you might not even have to give a pointer to the heaters to the RR [19:46:06] if there is no additional logic to it that is [19:46:30] it was necessary for the ASA heaters for example to make the fine heater not work until the fast heater is done [19:47:24] So without a pointer how does it know which heater? [19:47:55] what does the RR code have to do with the heaters? [19:48:18] don't you juse connect the heater to a RR radiator in the config? [19:48:20] just* [19:48:24] Well thats where the heater was originally [19:48:31] So I am just adding the other heater [19:48:44] And there was a pointer for it [19:49:09] ah, I see, it did the WireTo, SetPump etc. [19:49:54] from all we know now, with Enable and SetPumpAuto unnecessary, the RR class doesn't need to do anything with the heaters [19:50:15] you don't have to delete that part [19:50:29] but the WireTo should be in the Init function [19:50:32] Yeah I reverted that and just added the other heater [19:50:40] and the SetPumpAuto is done in the config also [19:50:44] Enable is unnecessary [19:51:11] so the RR probably doesn't need to do anything with the heaters [19:55:36] Yeah I removed all but the Init wiring [19:56:33] I see what you mean [19:56:42] So I just added a systemtimestep with the heatloads [19:56:50] And put both heaters in the init [19:57:59] yep, that sounds good [20:06:44] Last thing for the RR, what is the best way to return the antenna temperature [20:07:04] double LEM_RR::GetAntennaTempF(){ [20:07:05] return(0); [20:07:06] } [20:07:08] Is currently there [20:07:32] Make a pointer for the radiator temp? [20:08:47] yeah, pointer in the RR class [20:08:52] and then the same setup as in the ECS [20:09:05] Ok [20:09:25] is this for the display on the main panel? [20:11:14] uplink worked! [20:11:18] it switched to program 72 [20:11:29] now I just have to figure out the timeline better [20:11:47] then I can try a suborbital abort or COI [20:16:10] wooooo! [20:16:11] :D [20:17:01] I'll make the nosecone jettison and SLA panel deployment switch selector events [20:17:17] the Apollo 5 Mission Report indicates that those were controlled through the IU anyway [20:17:53] then I can easily control those events through the PAMFD [20:18:43] but I already heard switches clicking after it selected P72 [20:18:52] I guess it started to do RCS pressurization etc. [20:19:16] and indy91, I dont know what the display calls up, the gettemperature function was already in the RR code just with return(0) [20:19:25] ok [20:20:08] ah [20:20:11] CWEA does call it [20:20:48] Hmm the panelsdk isnt working [20:21:34] in general? [20:21:39] Undefined in this case [20:21:48] what exactly is undefined? [20:21:53] double LEM_RR::GetAntennaTempF(){ [20:21:53] if (!RRAntennaTemp) { [20:21:54] RRAntennaTemp = (double*)Panelsdk.GetPointerByString("HYDRAULIC:LEM-RR-Antenna:TEMP"); [20:21:54] } [20:21:55] return KelvinToFahrenheit(*RRAntennaTemp); [20:21:55] } [20:22:03] "Panelsdk" [20:22:10] try a lem-> before it [20:23:18] lem->Panelsdk [20:23:19] Yep that did it [20:23:22] great [20:23:31] the LM owns the Panelsdk [20:23:48] some systems use it so much, you give it direct access to it [20:23:52] but the RR doesn't have that [20:29:37] https://github.com/rcflyinghokie/NASSP/commit/7d35f89a59761318be6d797109e199edc3c019ff [20:30:07] https://github.com/rcflyinghokie/NASSP/commit/2204e7e0bea47243c92e81bafa918f682c84aea8 [20:30:12] How do those look [20:32:20] HTR_RR_OPR_CB.MaxAmps = 7.5; [20:32:21] + HTR_RR_OPR_CB.WireTo(&CDRs28VBus); [20:32:28] that stuff can be removed now, right? [20:32:31] those 4 lines [20:32:59] for the two heater CBs [20:34:48] rest looks good [20:34:57] I have a funny bug right now [20:35:04] the SLA panel animation is messed up [20:35:14] is rotates two SLA panels and the LM mesh [20:35:22] it* [20:35:54] Yeah thats what i said I was leaving until we decided to remove it [20:36:02] When does it rotate [20:36:04] sep? [20:36:39] when it does the nominal SLA panel deployment animation [20:37:00] so instead of rotating the 4 SLA panels to 45° it rotates two of them and the LM [20:37:10] LM mesh only at that point [20:38:40] Haha bet that looks weird [20:40:38] yeah, quite [20:41:03] I am going to clean up the LR heater and S band heater as well [20:41:10] great [20:41:16] don't forget about the isolation [20:41:37] Ah I didn't touch the isolation for the RR [20:42:05] But since the heatload isnt going into the case it shouldnt be much of a factor like the ASA and IMU [20:42:16] Remember those had heaters and heatloads to radiate [20:42:23] right [20:42:48] the RR isolation probably should have such a small factor as the IMU case anyway [20:42:56] So I will leave them alone for now, debug them and adjust accordingly but since it shouldnt have much heat to reject it probably doesnt need much play [20:43:10] hey [20:43:12] PR is up for the RR heat stuff [20:44:07] yeah, but be prepared that the sun and lack of sun will be the biggest factor by magnitudes for the heat going in and out of the RR antenna temperature [20:44:28] so I would at least turn down the isolation to 0.0001 or so [20:44:43] or else the sun will be about 1000x stronger than the heater [20:44:49] hey Alex [20:45:31] Ah ok will do [20:45:36] I need your help with LM-1, Alex [20:45:42] I will push that with the LR heater [20:45:44] we have an old mesh, but that is rotated all wrong [20:45:49] rcflyinghokie1, sure [20:46:06] so maybe the better solution is to make the LM legs a separate mesh [20:46:13] and have it enabled by default, but not for LM-1 [20:46:49] so, I did a quick P71 test. Got a program alarm, but I think that was caused by the DPS not starting. I have to fire the pyros on the ground already. [20:47:49] sure I can look into that [20:49:28] maybe it is fairy simple [20:49:40] just separate the landing gear in a mesh editing program [20:49:54] yeah should be very easy [20:49:55] and save it separately? I have no idea, but it might be as easy as that. [20:50:05] essentially what I did for the hatches [20:50:13] ah, right [20:52:45] now I have everything in place for the full suborbital abort program of Sunburst I think [20:53:03] I still don't know if the IMU is messed up or not [20:53:13] but I think the COI will tell if that is the case [20:54:27] how far along are you in the mission? [20:55:10] I managed to get LM separation working [20:55:19] and I had a good DPS-1 and DPS-2/FITH/APS-1 test [20:55:41] but I still am not quite sure if the IMU is surviving the coordinate system change at LM creation [20:55:49] or rather, when the LM mesh is separated [20:56:02] I still have a few doubts [20:56:08] but so far everything looks good [20:56:18] so I am testing the abort programs of Sunburst right now [20:58:22] and I think the suborbital abort program just worked perfectly [20:58:51] nice [20:59:22] hmmm [20:59:34] and then it started tumbling wildly with the APS firing [21:00:17] maybe I should first check what that program is even supposed to do [21:00:45] Hmm something weird with the RR wiring [21:00:57] // Rdz Radar [21:00:58] RDZ_RDR_AC_CB.MaxAmps = 5.0; [21:00:58] RDZ_RDR_AC_CB.WireTo(&CDRs28VBus); [21:00:59] PGNS_RNDZ_RDR_CB.MaxAmps = 15.0; // Primary DC power [21:00:59] PGNS_RNDZ_RDR_CB.WireTo(&CDRs28VBus); [21:01:00] RDZ_RDR_AC_CB.MaxAmps = 2.0; // Primary AC power [21:01:00] RDZ_RDR_AC_CB.WireTo(&ACBusA); [21:01:20] 2 wirings for the AC cb? [21:01:27] with different max amps [21:01:50] that seems wrong [21:02:00] and an AC breaker wired to the DC bus [21:02:16] I think those first two lines are just nonsense [21:03:10] That AC breaker is wired twice. Must be. [21:06:02] the second WireTo wins [21:06:10] Niklas, UHCL has LUNAR MODULE SYSTEMS HANDBOOK LM-10 AND SUBSEQUENT VEHICLES. REV A, PCN-3, APOLLO 17 * ( 39 PAGES )  [21:06:15] er [21:06:20] nevermind, ignore me [21:08:17] there is a lot of potentially useful stuff specifically about LM-1 at UHCL though [21:08:22] LM-1 ( LUNAR MODULE 1 ) MASS PROPERTIES and stuff like that [21:08:42] good to know [21:08:50] LM-1 ( LUNAR MODULE 1 ) SUBORBITAL ABORT SEQUENCE // APOLLO //  [21:10:05] found the sequence of events already, but good to know where I could find even more details [21:10:19] I had an RCS failure after staging [21:10:22] not sure why [21:10:26] but Sunburst performed right [21:10:54] short DPS burn to get away, FITH, short APS burn, coasting, another APS burn [21:11:03] Sorry I lost connection when you were talking about the wiring [21:11:29] only a little bit [21:11:40] those first two lines are probably completely wrong [21:11:54] wiring AC breaker to an DC bus? Makes no sense [21:13:35] Exactly [21:13:36] And that breaker is already attached to the AC bus in lempanel [21:13:58] oooo, MP3 worked? :D [21:15:07] thewonderidiot, yes, mostly. [21:15:11] And those other lines, like the heaters, are redundant I believe [21:15:15] and what didn't work wasn't Sunburst's fault [21:19:28] :D [21:19:36] that's awesome [21:49:20] indy91, https://www.dropbox.com/s/1hb47vhp4e30mz5/Screenshot%202018-01-10%2016.48.39.png?dl=0 [21:49:49] great [21:50:30] oh wait I think it had par of the landing gear structure though [21:50:35] part* [21:51:02] like here: http://space.skyrocket.de/img_sat/lem-1__1.jpg [21:51:25] yeah [21:51:56] Does the RR draw any power the way it's wired [21:57:31] I don't think so [22:02:11] Ok I can add that as well [22:03:02] Whats the best way to go about the DC and AC draws [22:05:04] the function IsPowered already considers both DC and AC, right? [22:06:57] Yeah [22:07:16] Would it draw power though AC breaker was in and DC was not? [22:07:17] so just draw power if that function is true [22:07:22] I don't know [22:07:31] I will do the simple case for now then [22:07:36] yeah [22:08:38] I haven't fixed the animation issue, but I'll do one COI test and then call it a night [22:08:45] let's see if the LM can get me into orbit! [22:10:01] Good luck! [22:10:40] got a program alarm [22:10:41] 1412 [22:11:55] and I got RCS failures again that I don't understand [22:12:53] oh well, have to try that again tomorrow [22:12:55] good night! [22:12:56] 1412: "Descent ignition algorithm not converging" [22:13:03] thanks [22:13:06] Haha [22:13:07] Night [22:13:11] Night. [22:13:14] that's Sunburst, right? [22:13:33] the alarm [22:13:37] type [22:13:53] so maybe I stopped the S-IVB too early [22:13:58] or it's on a bad trajectory or so [22:14:09] night [22:15:05] 1201 [22:21:00] hmm, no, that is not Sunburst [22:21:03] # 01412 CDU DOES NOT AGREE WITH COMMAND TO 5 DEGREES ALARMS (WHICH CALLS ALARM) WILL [22:21:03] # CONTAIN ALARMS +3. Q OF THE [22:21:04] # ORIGINATING ROUTINE WILL BE STORED [22:21:04] # AT QPLACE [22:22:57] .tell indy91 1412 is generated by KALCMANU if the magnitude of error exceeds 5 degrees on any axis after a maneuver [22:23:03] You're right. On sunburst, if that were KALCMANU, it'd be a magnitude error warning denoting that you're 5+ degrees out of whack upon completion. (Per KALCMANU_STEERING: "IF THE MAGNITUDE OF THE ERROR EXCEEDS 5 DEGREES ON ANY AXIS DISPLAY AN ALARM INDICATING THAT SPACECRAFT MAY NOT HAVE ACHIEVED THE DESIRED ATTITUDE" [22:23:07] .tell indy91 so could possibly be related to your IMU concerns [22:24:36] ...not sure if I can do anything to help debug this one [22:27:02] C++ question for you guys [22:27:39] I want the rendezvous radar to draw dc power only if the AC breaker is not in, and dc and ac power if both are in [22:27:42] .tell indy91 actually that might just be due to the RCS failures [22:28:00] Do I use two if statements or do I need an else if [22:28:06] if (IsPowered()) [22:28:07] { [22:28:08] dc_source->DrawPower(150); [22:28:08] ac_source->DrawPower(13.8); [22:28:09] RREHeat->GenerateHeat(65.4); [22:28:10] RRESECHeat->GenerateHeat(65.4); [22:28:10] } [22:28:11] if (IsDCPowered()) [22:28:13] { [22:28:15] dc_source->DrawPower(150); [22:28:17] RREHeat->GenerateHeat(65.4); [22:28:19] RRESECHeat->GenerateHeat(65.4); [22:28:21] } [22:29:24] if IsPowered and IsDCPowered to what I think they do, then you don't technically need an else -- but I would put one in [22:30:26] normally I would try to structure the logic to avoid any duplicated lines, though [22:31:57] What would be an example in this case [22:32:42] And ispowered means both ac and dc power, isdcpowered means just the dc breaker [22:34:37] then there isn't really a clean way to do it with just those too functions [22:35:22] Hmm what about: [22:35:43] Ah never mind [22:36:07] I would normally try to do something like this: [22:36:08] if (HasDCPower()) [22:36:09] { [22:36:10] dc_source->DrawPower(150); [22:36:10] RREHeat->GenerateHeat(65.4); [22:36:11] RRESECHeat->GenerateHeat(65.4); [22:36:11] if (HasACPower()) [22:36:12] { [22:36:12] ac_source->DrawPower(13.8); [22:36:13] } [22:36:14] } [22:36:22] but I don't know if you have the API support for that [22:36:34] I mean I can add a function for ac power [22:37:11] actually wait, that doesn't work [22:38:06] no nevermind it does [22:38:15] mis-reread what you were going for [22:38:36] haha [22:38:57] So if both cases are true both will draw? [22:39:57] it will draw DC whenever available, and draw AC only if both are [22:43:10] So: [22:43:10] if (IsDCPowered()) [22:43:11] { [22:43:12] dc_source->DrawPower(150); [22:43:12] RREHeat->GenerateHeat(58.5); [22:43:13] RRESECHeat->GenerateHeat(58.5); [22:43:14] } [22:43:15] if (IsACPowered()) [22:43:17] { [22:43:19] ac_source->DrawPower(13.8); [22:43:21] RREHeat->GenerateHeat(6.9); [22:43:23] RRESECHeat->GenerateHeat(6.9); [22:43:25] } [22:44:56] I want both conditions to happen independent of one another [22:45:04] oh, then that works [22:45:08] So if the ac breaker is in but dc isnt, it still draws AC [22:45:16] If both are in, it draws from both [22:45:17] although [22:45:42] do the numbers passed to GenerateHeat() get added to each other, or would a second call overwrite the first? [22:46:04] Or this: (Hang on.) [22:46:38] Yes they do [22:46:44] they are additive [22:47:20] okay, then that should be what you want [22:51:03] Great [22:51:19] I didnt realize how many systems in the lm are not drawing power [22:51:41] Like the RR and LR in this case [22:52:59] haha [22:53:04] radars are pretty hungry :D [22:53:16] You use and else if if it needs to be one or the other. In this case, if there is no DC check if there's AC instead. With two statements it will be. Is there DC? /and/ Is there AC? [22:54:46] More info: https://www.tutorialspoint.com/cplusplus/cpp_if_else_statement.htm [22:55:45] Off to bed. Super tired. Night! [22:58:28] night! [23:14:31] if (HasDCPower() || HasACPower)) { [23:14:32] if (HasDCPower()) { [23:14:33] dc_source->DrawPower(150); [23:14:33] RRESECHeat->GenerateHeat(65.4); [23:14:34] } [23:14:34] if (HasACPower()){ [23:14:35] ac_source->DrawPower(13.8); [23:14:36] RRESECHeat->GenerateHeat(6.9); [23:14:36] } [23:14:37] } [23:14:55] And of course it killed the tabs. [23:16:17] Try that again.. [23:17:41] if (HasDCPower() || HasACPower)) { [23:17:42] if (HasDCPower()) { [23:17:43] dc_source->DrawPower(150); [23:17:43] RRESECHeat->GenerateHeat(65.4); [23:17:44] } [23:17:55] if (HasACPower()){ [23:17:56] ac_source->DrawPower(13.8); [23:17:56] RRESECHeat->GenerateHeat(6.9); [23:17:57] } [23:17:58] } [23:18:07] the outer check is just redundant, though, isn't it? [23:24:09] For optimization, I believe. (And if you decide later to split out the radar electronics heat from the radar proper's heat) [23:27:03] it seems to me like it would either be slower (by checking IsXPowered twice), or the compiler would optimize it out [23:30:23] fair enough, though it also makes it more legible. [23:35:28] So is what I have a good way to do it for what I want? [23:36:40] what you have is fine, rcflyinghokie [23:37:06] Ok [23:37:35] Cannibal^ is right though, I will be adding radar heat separate from RRE heat later, but only after RRE has a better and more defined implementation [23:38:11] This is just to get things started [23:47:31] Ok now the sband heater [12:29:46] . [13:54:10] Good morning [13:54:31] hey [13:55:28] I actually have a few questions about my PR (instead of you questioning me before a merge, weird I know) [13:55:50] haha [13:56:11] I already merged it though [13:56:14] I know [13:56:28] They arent issues or mistakes (that I know of) [13:57:15] But I was wondering for example in the get antenna temp function, why return KelvinToFahrenheit(antenna->GetTemp); would not work [13:58:16] That what I tried first because it was a simpler way to get temperature (so I thought) but it did not build correctly [14:00:00] GetTemp is a function [14:00:06] GetTemp() might work [14:00:25] and might be the better way, if the RR (or LR?) already has a pointer to the antenna radiator anyway [14:01:33] Which it does [14:01:46] Thats why I wanted to do that instead of make another duplicate pointer [14:03:18] So somethign like: [14:03:19] return KelvinToFahrenheit(antenna->GetTemp()); [14:03:29] yeah [14:04:03] Also when i got home last night, I was finally messing with some of the heat loads of these, but they don't seem to be adding to my total heat like the other systems I did are [14:04:52] is the SystemTimestep called? [14:05:09] doesn't look like it [14:05:13] Ah [14:06:28] Yeah that would do it haha [14:08:52] I knew I forgot something :P [14:10:36] easy to forget [14:10:55] I have fixed my animation and RCS issues with Apollo 5 [14:11:00] Oh great [14:11:02] the RCS issue was actually a long time ATCA bug [14:11:07] What about the alarm before you left? [14:11:13] but it can't happen in the normal LM [14:11:28] I am still getting that alarm when I try a COI [14:11:37] but it could be due to my trajectory [14:11:50] the suborbital abort program now executed flawlessly [14:12:08] short DPS burn, FITH, short APS burn, coasting, longer APS burn [14:12:18] goes back to P00 after it is over and I had no alarms or so [14:13:15] but COI doesn't work too good yet [14:13:27] Ah [14:13:34] the altitude overshoot I am getting is a few miles too high [14:13:46] Does it put you in orbit at least? [14:14:08] not really [14:14:13] well, kind of [14:14:20] it's doing some wild maneuvering [14:14:26] insertion is at 165 km [14:14:36] normal altitude overshoot is 185 km apoapsis [14:14:40] I am getting 195 km [14:15:11] so in the minutes leading up to insertion, the Saturn always has a negative altitude rate [14:15:19] to achieve the desired insertion altitude [14:15:36] and I think this negative altitude rate is too high [14:15:52] it takes a minute or so after the abort for the DPS to fire at 100% [14:16:00] so in this time the LM looses a lot of altitude [14:16:05] maybe too much to be compensated [14:16:37] Does it wait the 26 seconds or so before 100%? [14:16:40] I will try a later S-IVB cutoff and also maybe a padload change to a lower alttitude [14:16:44] yep, it does [14:16:54] I am surprised in an abort situation that it would [14:16:56] and before that it takes 30 seconds or so to have the whole separation sequence [14:17:10] first an RCS burn to get away from the S-IVB [14:17:16] then it orients itself for the DPS burn [14:17:18] I would expect the gimbal andles to be set for that before launch [14:17:20] that is when I get the alarm [14:17:24] angles [14:17:31] which angles? [14:17:37] PR with the fixes is up [14:17:50] Well the 26 seconds is so the DAP can find the CoG [14:17:55] And gimbal accordingly [14:17:58] Right? [14:18:15] yeah, but somehow that is never done in the LM [14:18:27] it is done this way in the CSM of course [14:18:45] you normally set the gimbal angles for an abort case, before liftoff [14:19:03] Right which is why I am surprised that it still waits the 26 seconds before throttle up [14:19:19] Especially in an abort that can be time critical [14:19:20] guess it only has one ignition routine :D [14:19:22] Ah [14:19:37] we have documentation about Sunburst simulations [14:19:49] and there it does indeed take 1 full minute from commanded abort to DPS 100% [14:20:00] Yikes [14:20:20] I guess they really really hoped that didnt happen :P [14:21:56] and the program alarm might be caused by it calculating the attitude for the insertion burn and it notices that it won't be able to achieve the desired altitude in time [14:22:18] because of the higher negative altitude rate [14:22:32] I've already implemented the actual AS-204 pitch polynomial, but that didn't help any [14:22:42] so it must be masses and thrust parameters [14:23:22] Yeah those are important as we have found [14:23:33] of course the issue could still be something else [14:23:39] but for now that is my theory [14:24:00] it should use basically the same algorithm as P12 in Luminary [14:24:12] Oh one more question about my other PR, the way I implemented the draw power for DC and AC, was that the right way to do it if I want none or either or both to be able to draw? [14:24:19] In the RR [14:25:14] I think so, yes [14:25:25] you implemented separate DC and AC IsPowered functions, right? [14:25:28] Yes [14:25:44] I only get the heat from the DC though in the sim [14:28:58] Almost as if it isnt checking the IsACPowered condition [14:29:06] Or its always heated [14:31:02] you did the function wrong [14:31:07] you return true in both cases [14:31:22] if (ac_source->Voltage() > 100) { [14:31:23] return true; [14:31:23] } [14:31:24] return true; [14:31:27] Ah hah [14:31:34] it should default to false [14:31:35] Damn that copy paste [14:31:37] Yeah [14:35:45] Thanks [14:37:08] It all works now [14:39:31] I still need to debug the radiators in the sun and shade but all the draws and heat loads to the glycol work [14:39:43] And no CTD :) [14:41:40] that's always good [14:46:53] I think that is all of the currently implemented systems that give heat to glycol [14:47:18] how is the cabin temperature now? [14:47:38] I had it about 75 last night after an hour or so [14:47:50] Suit temp was in the 60's [14:48:10] That was full hot on the LCG and suit temp [14:48:13] With crew [14:48:21] So it can easily take more heat [14:48:37] I was doing my initial tests with 3000W [14:48:48] We only have about 300 right now total in the primary loop [14:49:04] Actually 4000 W including batteries in my tests [14:49:14] But its not freezing anymore [14:49:56] I am thinking the next systems to look at are the ECA's and inverter [14:49:58] Brb [14:57:25] one more thing [14:57:43] did you remove the newly added pointer from the LR class? [14:57:57] the one that is not needed [15:01:18] It heats the LR from operation not the heaters [15:02:11] what? [15:02:35] Is LRAntennaTemp still needed is what I mean [15:02:49] Did i not remove both [15:03:06] maybe I am just not seeing it in the PR [15:04:14] https://github.com/rcflyinghokie/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_lm/LEM.h#L200 [15:04:47] RR also still has it [15:05:08] Ah yes [15:05:20] Ill fix that in a little when i get back to my computer [15:05:44] Eventually ill remember all these small things [15:06:14] Ok. I'll wait with the merge until then [15:11:45] Thanks [15:20:02] Had to run to the hardware store, honey do project refinishing a basement [15:52:11] Pointers removed [15:57:27] How thorough are the ECAs coded? [15:58:03] I did see they had the 4 with the right batteries attached [16:08:51] Ah dont merge the PR, forgot the initialization of the pointers i removed ill fix it shortly [16:22:15] Hey [16:27:21] Hey there [16:36:03] hey Thymo [16:41:32] increased the S-IVB propellant mass a bit, I was using the nominally used number [16:41:40] maybe that helps with the trajectory [16:41:46] I'll also initiate COI even later [16:43:10] Do you have a source for Apollo 5 propellant loads? [16:43:38] LVOT has the numbers [16:44:26] Is that what you used initially? [16:44:53] still using it. It just lists residuals and reserve as a separate mass [16:45:03] and I didn't add that at first [16:45:08] https://web.archive.org/web/20100520095417/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19680007674_1968007674.pdf [16:46:15] PR merged [16:47:04] there also is a fairly large attitude discontinuity between IGM stages 1 and 2 [16:47:12] so at MRS it pitches down about 10° [16:52:08] That seems high [16:53:03] yeah [16:53:39] so, I wonder if the issue is actually a different one. What is does after LM separation is a ullage burn to get away from the S-IVB [16:53:50] but it doesn't try to do attitude holding or so during that time [16:54:05] it basically looses control and resumes it after the RCS burn is over [16:54:34] so maybe that is the cause of the 1412 alarm. It's an KALCMANU alarm after all. [16:54:49] Yeah that could be [16:54:59] Weird that it doesnt att hold during an ullage though [16:55:14] indeed [16:55:31] could be due to the IMU issue that is still potentially there [16:55:46] I really have to check the IMU attitude next attempt [16:55:54] I always forget to see if it changes during the LM sep [16:56:22] Not something you usually think about being used to a CSM on top [16:56:23] but at least during the suborbital abort it doesn't have these problems [16:56:54] yeah, and watching the LM stage from the outside is more fun [16:56:57] or watching the DSKY [16:56:58] Haha indeed [16:57:18] You need like an external MFD with the DSKY [16:57:38] if the DSKY was a MFD that would be possible [16:58:49] and writing an MFD that accesses the DSKY should be fairly easy as well [16:59:28] Might be good for this case [16:59:39] And perhaps for videos in the future [16:59:49] I just have to force myself to look at the FDAI, haha [16:59:57] and not get distracted by all the other things happening [17:00:12] including the LM programer setting a bunch of switches [17:00:46] That was one of the challenges when I became an instrument rated pilot. You train with not having any view outside, but when you get in actual IMC, and pop in and out of clouds, its all do distracting you have a hard time keeping your eyes in the cockpit [17:01:08] IMU attitude stays the same! That surprises me [17:01:46] Well thats a good sign [17:01:47] you just have to get one of those fancy augmented reality helmets for the F-35 [17:01:57] Haha yeah those are crazy looking [17:02:02] and crazy expensive [17:03:09] So is everything having to do with that aircraft [17:03:57] haha, right [17:04:09] Hmm looks like ECA's 1 and 2 are in the descent stage [17:04:27] yep [17:04:40] So I wonder if those cool by radiation only [17:04:58] The ECA cold plates are in the ascent stage [17:05:09] So maybe just the ascent ones are cooled by glycol [17:05:19] hmm, tricky question [17:06:10] I noticed I still had the LM AOH Volume II open. When I couldn't figure out the RCS issue I went through the malfunction checklist, if that maybe gives me a clue :D [17:06:33] I ended up at "K13 (S&C #2) FAILED CLOSED" But that wasn't it :D [17:06:58] that's a relay that we indeed simulate, but it's in the right state [17:07:59] Oh that reminds me, when I was playing with the PDI scenario to initialze the ECS, I tried firing the RCS and got red flags everywhere, I learned quick that I had to fix old LM scenarios [17:08:19] yeah [17:08:23] just open all the valves [17:08:34] and fire the RCS helium pyro [17:08:44] Yep [17:09:21] I am getting the 4 red flags for the +X thrusters before LM sep [17:09:30] because it starts firing those before the LM separation [17:09:40] and at that point the thrusters and propellant isn't defined yet [17:09:55] but I was also getting all the other flags when the RCS didn't work [17:10:07] helped me figure out where the problem was [17:10:22] so it works like intended I guess [17:10:55] you get the red flag when 6 consecutive firing commands from the PGNS to the RCS didn't lead to the RCS actually firing [17:12:32] no, PGNS and AGS [17:13:01] but setting the switch to off, then showing barberpole, sets an RCS failure input bit in the PGNS only [17:13:15] that is fun to play around with [17:13:33] how many thruster failures the LGC can take and still being able to maneuver [17:17:01] reading the COI code, the DAP enabling flag is called "GODAPGO" [17:17:30] that's what I've been telling the DAP each time I tried the COI [17:18:27] Haha godapgo [17:18:31] So many creative names [17:18:42] yeah [17:19:03] I'll be back in a few [17:36:41] morning! [17:37:20] hey [17:38:01] what's up? [17:38:08] fixed the animation and RCS issue. So MP3 is working flawless now [17:38:14] sweeeeeeet [17:38:23] COI is still giving me the 1412 alarm each time [17:38:38] that's weird [17:38:42] I discovered some interesting behavior with that [17:38:48] just doing another test [17:40:08] it's firing the 4 aft RCS thrusters to get away from the S-IVB [17:40:16] but it's not doing attitude holding [17:40:32] so because of the small asymmetry, the LM is rotating [17:40:56] I first thought it is trying to get to another attitude [17:41:21] but I think it's not controlling attitude at all [17:41:25] huh [17:41:49] and then I get the alarm [17:41:51] and it recovers [17:43:04] I think the alarm happens only at the end of an attempted maneuver [17:43:10] although, now that I think about it, there is a small chance that this stil has to do with the RCS issue. [17:44:26] but it might also be something like the bitrate switch issue again [17:44:41] or a wrong input bit [17:44:57] the IU and LM systems could still interfer in some way [17:45:21] what exactly is MP4 trying to do after LM separation? [17:47:16] 4-jet +x translation [17:47:20] yes [17:47:23] that is what it is doing [17:47:33] seems like it fires for a bit before sep [17:47:44] a second or so [17:47:53] yep, the thrusters and propellants are not defined at that time, so I am getting RCS failure flags [17:48:20] it calls SETMINDB (minimum deadband) and HOLDRATE just before the separation [17:48:24] pretty sure it's doing the same thing in MP3, but there it also does attitude holding [17:48:33] HOLDRATE is interesting [17:49:19] oh wow it is very interesting [17:49:55] http://www.ibiblio.org/apollo/listings/Sunburst120/DAP_INTERFACE_SUBROUTINES.agc.html#484F4C4452415445 [17:50:09] it seems to have been intentionally broken [17:50:45] MP4 is the only thing that calls it [17:50:49] yeah [17:51:05] so, I should have said, it still fires the DPS after the alarm and does some wild maneuvering [17:51:23] theoretically it could do everything right, the trajectory is a bit off [17:51:28] maybe too much for it to recover [17:51:48] I'll modify RINJECT on the next attempt, so that it actually can achieve it [17:53:14] it also recovers attitude control later [17:53:20] I think [17:53:20] I'm going to make a Sunburst binary with CS DAPBOOLS there [17:53:32] just out of curiosity [17:53:33] just not in that period with the 4-jet +x [17:53:35] yeah [17:54:33] intentionally turning off the DAP is one of the things they simulated [17:54:39] it can be done with an extended verbI think [17:55:31] so maybe the COI just tests something like that? [17:55:38] I don't see anything like that [17:55:49] it looks like it tries to use it [17:56:12] well, or some DAP test at least. After all HOLDRATE is intentionally broken [17:56:19] just why is the question [17:56:58] https://drive.google.com/open?id=1ibmoVCiOsLIjMm0yTU-kI3qxKYFz96w1 [17:57:07] it's not broken in Sunburst 37 [17:57:21] interesting [17:57:35] and it's not marked as a change between 116 and 120 [18:09:38] COI worked! [18:09:55] with an insertion altitude 20km lower [18:10:03] and normal Sunburst120 [18:10:31] oh awesome! [18:10:36] but for the first time it didn't do crazy attitude adjustments [18:10:42] so it was just the trajectory [18:10:45] and it cut off [18:10:47] yeah [18:10:53] that's good :D [18:10:56] something is still too light in my Saturn IB [18:11:03] so it overshoots the insertion altitude [18:11:17] that is normal, but the LVOT has an overshoot to 185km, with insertion at 165km [18:11:23] I got up to 195km [18:11:46] and that leads to a high negative altitude rate at the time when the LM can do COI [18:12:03] the LM still needs a minute from S-IVB cutoff to DPS 100% [18:12:11] so in that time it looses too much altitude [18:12:54] I have to look if it is supposed to have a positive altitude rate at COI cutoff, because it did [18:15:08] it seems to load 0 for RDOTD [18:15:19] but it also says "FIXED LATER" [18:16:41] in any case, I don't think there is an IMU issue [18:16:42] hehehe [18:17:00] so is all of Sunburst working now then? minus whatever isn't implemented in the LMP? [18:17:20] I have implemented most of the relevant things in the LMP [18:17:36] and I did test the second APS burn last year [18:17:40] it worked then [18:17:55] so far with this Saturn launched LM I tested through APS-1 [18:18:11] and it, like last year, ended with a apoapsis that is a bit too high [18:18:22] APS-2 had a bit of trouble with that then [18:20:32] the padload parameters are fairly inconsistent between SCOT and the Sunburst 116 padload from March 1967 we have [18:20:46] so that will need some tweaking [18:20:56] and tweaking is all I really have to do from now on [18:20:59] hmm [18:21:02] Saturn, LVDC and LGC parameters [18:25:48] all of this is making Apollo 5 into one of my favorite missions, heh [18:25:57] Sunburst has been a lot of fun to get working [18:26:07] yeah [18:27:23] Now that I got it mostly working earlier than I thought, I might do a video for the 50th anniversary [18:27:33] :D [18:27:42] there are still some manual inputs that need to be done right now [18:27:53] like the GRR backup signal [18:28:02] so still some things to work out [18:29:11] I really like the idea of a DSKY MFD too [18:29:21] so you can see what the LGC is doing while watching it all go down [18:30:00] the coding should be easy. Just has to access the DSKY [18:30:37] making it pretty would be the challening part for me [18:33:59] hmm [18:34:19] I think the insertion issue could be due to a Saturn IB LVDC problem [19:26:27] hey [19:26:58] hey Alex [19:29:51] hey [19:31:37] AlexB_88, iirc you said something about inaccurate Saturn IB insertions a while ago [19:31:49] or at least inaccurate according to the lvlog [19:32:46] I am getting the same with Apollo 5 [19:32:55] it is accurate through T+60 seconds or so [19:32:59] and then becomes pretty bad [19:47:10] yeah it was pretty bad before with Apollo 7 in my testes [19:47:16] tests* [19:47:48] in my testes...lol [19:48:03] greek plural I guess [19:48:24] the actual insertion numbers are good though [19:48:35] so maybe it's just something with the SVCompare function [19:48:47] yes yes exactly what I was going for :p [19:49:02] the SVCompare function uses the nominal GRR time [19:49:14] but the actual time can vary a bit now [19:49:26] when I had adjusted the pad height in the LVDC presettings, that helped [19:49:27] that was changed a while ago. But also in the Saturn V [19:50:56] actually, that's not right [19:51:08] only liftoff time (T1 start) can vary more now [19:51:20] so shouldn't have an influence on the SVCompare function [19:52:01] on my Apollo 5 tests the S-IVB was still accurately tracking the local horizon at LM sep, 1 hour after liftoff [19:52:06] so it can't be actually that bad [20:06:31] did you figure out he RCS failure? [20:06:46] yep [20:06:51] it was an ATCA bug [20:07:00] jet on/off timing [20:07:30] it used the current sim time (since Orbiter loaded) for some things, but the current mission time (since T-0) for others [20:07:50] in our normal LM this caused the thrust ramping up to never happen [20:07:59] because sim time is always smaller than the mission timer [20:08:10] because the LM never gets loaded or used before T-0 [20:08:32] but in this T-60s scenario it basically delayed all thrust on commands by these 60 seconds [20:08:49] so pretty bad bug and we were lucky that it only had a big influence on Apollo 5 [20:11:40] I guess that is a nice thing about getting Apollo 5 working is that we can detect bugs like these that might have otherwise been overlooked [20:13:50] yeah, I am especially was finding instances where not having valid thrusters or propellant for the LM caused CTDs [20:13:56] -am [20:14:07] those are all fixed now [20:28:06] how about that legless LM mesh? [20:28:47] I guess the partially attached leg structure is difficult to get right [20:36:00] sure, I think I can mange the partial leg structure [20:36:05] manage* [20:37:59] your deadline is the 50th anniversary of Apollo 5 :D [20:38:55] does it matter what model I base it on? It would be more realistic if I use the legs extended model, and take the legs off that [20:39:46] hmm [20:40:09] then this would be a model we only use for LM-1 [20:40:12] which is ok [20:47:06] and I am asking this because there is a difference between the leg retracted and extended meshes: [20:47:07] https://www.dropbox.com/s/stz2td52bs47wc7/Screenshot%202018-01-11%2015.40.36.png?dl=0 [20:47:40] so LM-1 was missing its legs, but it had them extended [20:48:39] yes, but I think the upper part is always supposed to look like that, even before leg extension [20:48:56] is that wrong in our mesh? [20:48:59] Its just that our leg retracted mesh was very poorly made [20:49:29] well I base that on real shots of a LM with its legs retracted in the later missions [20:50:16] https://spaceflightblunders.files.wordpress.com/2017/09/lm-4-s69-17807-orig.jpg?w=1632 [20:50:52] better meshes are always good [20:56:41] doing so many launches I am really liking the performance of the S-IB systems [20:56:48] would be fun to put in on a test stand [20:57:03] there really isn't much needed for a test firing [21:16:56] turned down the thrust of the S-IB a bit, now staging happens at the right attitude [21:17:08] so maybe this leads to a more nominal trajectory [21:17:20] and the LM can do a COI to the nominal insertion radius [21:19:02] peak altitude even a bit low [21:24:22] yep, I'll try that COI now. At the same S-IVB cutoff velocity as one of the Sunburst test runs. [21:31:25] thewonderidiot, ah, and I haven't done a run with your "fixed" Sunburst version. Should try that, too. [21:51:08] the binary results in the sam behavior and still a 1412 [21:51:19] same* [21:51:21] good night [02:15:10] Anyone up for a quick C++ question? :) [02:26:38] shoot [02:27:58] Ok I am dabbling with adding temperature readings to the temperature gauge in the LM, but when I place my functions or even the switch in there it says member is inaccessible [02:28:40] is it private/protected? how are you trying to access it? [02:34:10] That I was looking for but dont quite know where to look [02:34:39] lem->TempMonitorRotary [02:34:42] For example [02:36:14] It is used in other places with no problem [02:36:47] are those other places in lem? [02:36:56] if it's a private in lem then things not in lem wouldn't be able to see it [02:38:30] if not, the other places could also be friends of lem, I don't know how much NASSP uses friends [02:38:40] friends are allowed to touch each other's privates [02:40:00] Haha [02:40:02] Well put [02:40:12] hehehe, it's an old C++ adage :P [02:40:20] I am in lemswitches.cpp right now [02:40:42] But I guess these are looking in LEM.h [02:41:13] Another switch (that I am pretty much copying) has this: [02:41:19] { [02:41:20] if (!lem) { return 0; } [02:41:20] switch (lem->TempPressMonRotary) { [02:41:21] case 0: //HELIUM [02:41:21] return lem->scera1.GetVoltage(6, 2)*350.0 / 5.0; [02:41:22] case 1: //PRPLNT [02:41:22] return lem->scera1.GetVoltage(6, 4)*350.0 / 5.0; [02:41:24] case 2: //FUEL MANF [02:41:26] return lem->RCSB.GetRCSFuelManifoldPressPSI(); [02:41:28] case 3: //OXID MANF [02:41:30] return lem->RCSB.GetRCSOxidManifoldPressPSI(); [02:41:32] default: [02:41:34] return 0; [02:41:36] } [02:41:38] } [02:41:40] Why would say temppressmonrotary work and mine not [02:42:50] In other words, where should I look to see why that works and lem->TempMonitorRotary doesnt [02:43:27] try the private/public sections in the class definition? [02:43:34] I'm still at work so I don't have NASSP code handy, sorry [02:43:52] Ok [02:44:38] in lemswitches.h? [02:44:53] class TempMonitorInd : public MeterSwitch { [02:44:53] public: [02:44:54] TempMonitorInd(); [02:44:54] void Init(SURFHANDLE surf, SwitchRow &row, LEM *s); [02:44:55] double QueryValue(); [02:44:55] this would be in whatever "lem" is [02:44:56] void DoDrawSwitch(double v, SURFHANDLE drawSurface); [02:44:56] protected: [02:44:58] LEM *lem; [02:45:00] SURFHANDLE NeedleSurface; [02:45:02] }; [02:45:04] LEM [02:45:04] Oh thats what came up for the definition [02:45:28] there isn't anything you could set on TempMonitorInd that would make it inaccessible to users of "lem" [02:45:35] that's a property of "lem" itself [02:48:48] So why isnt it working [02:52:47] I guess I do not know why that case isnt working yet another is? [03:10:26] Ah I think I found the reason [03:10:35] No friend class [03:11:33] That did it thanks! [03:28:27] I totally forgot about those, and should have looked there when you were telling me about friends and their privates ;) [03:44:52] Night! [12:15:38] Hey [12:17:30] hey [12:18:00] Ryan added too many standby heaters, haha. You can't power the LM from the CSM currently it seems [12:18:08] circuit breakers are plopping open [12:18:35] Haha [12:19:06] I get conflicting numbers about that though [12:19:18] the circuit breaker says it has 953 amps [12:19:22] max is 7.5 [12:19:37] but the X-Lunar bus tie controller says something about 114 watts [12:19:42] which sounds much more reasonable [12:19:51] The heaters are drawing 953 amps? [12:20:01] That can't be right [12:22:22] yeah, something is weird [12:23:19] Shouldn't the low voltage battery taps handle that until T+30? [12:23:53] 30 hours? [12:23:57] hours, not seconds [12:24:29] uhh, maybe? I thought you started powering the LM from the CSM shortly after docking [12:25:06] 35100 Watts, 28.8 Volts, 1220 Ampere [12:25:09] something is broken [12:25:41] it's a random number almost [12:29:05] I doubt anything aboard the two spacecraft is able to supply 35kW of power. [12:29:22] and now I got 6500 amps [12:29:36] It must be something with the CSM/LM interface [12:29:47] I don't think the LM on its own has these problems [12:36:18] when the CBs have plopped open and I try to closed them again then they have a much more reasonable load [12:36:49] too much for one CB still [12:42:47] hmm, now it works [12:42:49] really weird [12:43:06] but still, it plopped open the CBs because of some random ampere value [12:43:10] but then I could close them [12:43:17] and it draws 2 Ampere [13:53:13] ...LM10's AOH (vol 1) suggests that 200 watts is what the LV taps are used at. (2.5.3.2) (6.94 amps at 28.8v if my math is right) and the CSM umbillical is rated for 108w nominal, 296w peak (2.5.6) for a maximum of 3.75a nominal/10.277a peak. So ISTR that the heater numbers are faulty. [14:01:38] I was getting a little over 2A at 28.8V [14:01:43] when everything worked normal [14:03:39] but I don't know the LM EPS well enough. Is the power going from the CSM through the LV taps? [14:04:44] and of course before CSM power is connected the LM batteries have to handle the heaters (in the real LM). That is batteries 1 and 4 LV taps [14:05:43] Power goes from the CSM umbillical directly to the CDR bus, if I'm reading the scematic properly.. [14:05:54] yeah, I think that is right [14:06:41] in any case, this initial wattage I was getting has to be a bug [14:06:59] after everything has settled down and is connected properly the numbers are very reasonable [15:04:05] Good morning [15:05:03] hey [15:06:32] I started debugging the radiators for the antennae last night, the heaters work as advertised, but the temperature just keeps increasing [15:07:00] nothing is cooling it sufficiently then [15:07:09] Also I added the temperature returns to the temp monitor gauge in the LM and fixed a mis matched pointer in the RR which I will PR shortly [15:07:21] So what is the best approach to increase cooling [15:07:46] something with the radiator [15:07:55] radiator isolation I think [15:08:03] not to be confused with the thermal isolation [15:08:32] So what are all of the parameters in the config again [15:09:45] LEM-ASA-HSink <0.013 3.0 0.03> 255.372 [15:09:45] 0.03 0.04 9389.36206 [15:09:46] [15:09:51] first line is position and initial temperature [15:09:52] I know the position one for sure [15:09:55] Ok [15:10:16] then volume [15:10:25] which gets used in the calculation of the size parameter [15:10:36] but I think we are overwriting the size parameter in code, right? [15:11:29] I have an Area in the code [15:11:34] And isolation [15:11:35] yes, area [15:12:27] area and isolation are both thermal parameters [15:12:42] And those are the first two numbers on the second line? [15:12:53] no [15:13:02] isolation is set to 1.0, always [15:13:11] which then usually gets changed in code [15:13:21] Which it was for these [15:13:52] the first parameter of the second line has many names [15:14:05] volume, size [15:14:16] and the area is 1/4*volume [15:14:25] the last parameter is mass [15:14:31] also used in the thermal calculation [15:14:39] the middle one is the radiator isolation [15:15:08] and that's probably the one you want to increase [15:15:21] And that is different from the isol in the code [15:16:02] yes [15:16:04] it's weird [15:16:13] Yeah thats what keeps confusing me [15:16:22] radiators are thermal objects [15:16:33] so they do the normal thermal calculation. Increase heat in sunlight [15:16:37] and loose heat in shadow [15:16:49] but radiators also have an additional term for radiating heat [15:16:59] that is what is calculated in the radiator timestep [15:17:26] Ok I will play with that number then and see what I get [15:17:37] the CSM fuel cell radiators have the value 6.8 [15:17:41] maybe start with that? [15:17:48] Yeah i was starting with 10 [15:18:06] not too high, or else the heaters have to work a lot [15:18:12] Right [15:18:14] another thing [15:18:22] we weren't careful with adding SystemTimesteps [15:18:28] some systems now draw power twice [15:18:34] OH [15:18:34] because it was done in the Timestep code before [15:18:38] Uh oh* [15:18:48] Which ones? [15:19:02] https://github.com/dseagrav/NASSP/blob/Orbiter2016/Orbitersdk/samples/ProjectApollo/src_lm/lemsystems.cpp#L3024 [15:20:12] So should that be removed? [15:20:49] probably [15:20:49] Since the AC and DC are taken care of elsewhere [15:21:21] LR has this as well [15:21:27] multiple draw powers in the code [15:21:43] there probably should be something like a "moving" flag [15:22:01] and then draw more power if the RR or LR is moving [15:22:07] that is what is done in LR code basically [15:22:41] Yeah the s band has it as well [15:26:49] do you want to fix the DrawPower or should I do that? [15:27:32] I am working on it [15:27:58] I just need to know the best way to set the moving flag like what is done with the s band [15:28:55] There is a pitchrate and yawrate in the steerableantenna class [15:31:32] I suppose I can use shaftrate and trunrate [15:32:48] if (abs(PitchSlew - pitch) > 0.01*RAD) [15:32:48] { [15:32:49] pitchrate = (PitchSlew - pitch)*2.0; [15:32:49] if (abs(pitchrate) > 5.0*RAD) [15:32:50] { [15:32:50] pitchrate = 5.0*RAD*pitchrate / abs(pitchrate); [15:32:51] } [15:32:52] moving = true; [15:32:54] } [15:32:56] From sband [15:33:10] Could I use shaftrate and trunrate in this type of structure for the RR? [15:35:10] I would use shaftVel and trunVel [15:35:21] ok [15:35:31] might not even need an additional flag [15:35:43] just use shaft and trun Vel in the SystemTimestep function [15:38:27] Ok [15:38:46] Hmm how much to draw [15:41:36] It will be additive though so i can use just the additional power draw for those moving [15:43:42] if (abs(shaftVel) > 5.0*RAD) [15:43:43] { [15:43:43] dc_source->DrawPower(33); [15:43:44] } [15:43:44] if (abs(trunnionVel) > 5.0*RAD) [15:43:45] { [15:43:46] dc_source->DrawPower(33); [15:43:47] } [15:44:11] Probably need something other than 5*RAD [15:44:19] oh yeah [15:44:30] whenever it is moving [15:44:37] LR only has one speed [15:44:49] So >0 [15:44:50] so there the power draw would be constant during movement [15:44:54] for the RR probably not [15:45:09] maybe a bit higher than 0 [15:45:16] What units are on there [15:45:37] so that it doesn't draw too much power if it is actually fine tracking the CSM for example [15:45:40] the velocities? [15:45:49] rad/sec [15:46:36] Well 5*RAD was used for the S band I think to allow tracking [15:47:09] that would be 5°/s [15:48:47] Too fast for RR slew? [15:49:25] I don't think you are reading the S-Band antenna code right [15:49:34] the moving flag is set at 0.01°/s or higher [15:49:56] Ah [15:50:00] Yeah I see that [15:50:15] so you could add something like that for the RR as well [15:50:35] if (abs(shaftVel) > 0.01*RAD) [15:50:35] { [15:50:36] dc_source->DrawPower(33); [15:50:37] } [15:50:37] if (abs(trunnionVel) > 0.01*RAD) [15:50:38] { [15:50:38] dc_source->DrawPower(33); [15:50:40] } [15:50:44] sure [15:50:51] if 33W is the correct number [15:50:53] for each [15:50:58] so 66W when it's really moving [15:51:12] Hm maybe 16.5 then [15:51:26] I got the number from looking at the max load and heat load on the RR DC breaker [15:51:37] And subtracting the two [15:52:03] ok [15:52:06] sure, that works [15:53:41] Just something reasonable for now [15:53:55] That doesnt exceed the max on the breaker [15:54:31] While I have this up, how do you scale a gauge? [16:13:16] do you mean for the antenna temperatures? [16:13:33] I think those measurements go through the SCEA [16:13:38] so it should be scaled there [16:14:29] Ah ok [16:14:45] sband has a different scale on the temperature indicator [16:14:58] yeah [16:15:03] that might be all the SCEA [16:15:18] I added some placeholders for now to remove the need for a debug line [16:15:24] although it's not as simple as scaling the gauge from 0 to 5V, I have noticed that with some RCS measurements [16:15:53] for those it was something like 0.475V (0 on the gauge) to 4.8V (100% on the gauge) [16:15:57] something like that [16:17:07] Weird [16:17:44] maybe you need a certain threshold voltage for the needle to move [16:18:06] Yeah true it culd depend on the physical display [16:18:08] could [16:18:59] Ok PR's the changes [16:19:02] PR'd [16:20:26] S-band antenna temp is scaled from -200°F to 200°F by the SCEA [16:21:15] so that is the only range it would be able to show on the gauge [16:22:08] Oh no its the quads that need rescaled [16:22:13] ah [16:23:07] I misread that last night then [16:23:22] -60° to 260° [16:23:34] Yeah [16:23:53] And the LM display for the antennae is -100 to 200 [16:24:07] so 0V would be -60° for RCS and -200° for S-Band [16:24:19] Which would be off scale low [16:24:19] 5V would be 260° for RCS and 200° for S-Band [16:25:01] I think the RR and LR SCEA measure -200 to 200 but the display doesnt have that range [16:27:22] RR is also -200° to 200° [16:27:28] and it says for the display [16:27:36] 1.25 to 5.0 vdc (-100° to +200°F) [16:27:48] exact same for the LR [16:28:34] Ah that makes sense then [16:28:40] Otherwise it would drive the needle down [16:29:57] oh, you let the DrawPower in the LR Timestep like it is [16:30:04] just removed the one in SystemTimestep [16:33:29] Yeah because it takes care of the moving case [16:33:36] Is that ok? [16:35:29] sure [16:35:46] I just thought you had moved it [16:37:39] Should it be moved to the systemstimestep? [16:38:52] I didnt want to mess with anything important there [16:41:58] Wow I have that rad set to 1000 and am still getting temperatures [16:42:06] increasing temperatures* [16:42:27] All but the LR [16:43:08] Mass seems to have a greater effect than changing that middle number [16:44:38] what's the isolation at? [16:44:50] the thermic isolation [16:45:01] The value set in the code? [16:45:05] and how much heat is going into it? [16:45:06] yes [16:45:09] 0.0001 [16:45:32] are you in the sun or not? [16:45:42] The SPS bell is facing the sun [16:46:02] But when i changed the mass of the LR to the right value it cools and heats [16:46:18] I nearly doubled the value that was there [16:46:39] And changing that other number (the 0.04 originally) is having no noticeable effect [16:46:54] then the radiation part is not having an effect [16:46:59] Nope [16:47:22] you probably should debug this with all wattages in a debug string [16:47:33] I did then when I tried to figure out what was going on in general [16:47:37] that* [16:47:39] Yeah good idea [16:47:48] I had done some temporary changes for that [16:47:49] Right now I just have heaters on or off and temperature [16:47:56] I'll make them permanent [16:48:03] Ok let me know what I need [16:55:40] this is actually already supported it commented code [16:56:10] h_Radiator::refresh in Hsystems.cpp [16:56:26] and H_system::Create_h_Radiator in Hsysparse.cpp [16:57:51] So just uncomment and change the name? [16:58:45] yeah [16:58:54] Ok I will try that [16:59:01] it's a bit tricky to add easier debug support for the thermal calculation [16:59:08] radiator is easy and I'll do that [17:00:42] Ok [17:01:02] LR seems to be the one I am closes to equilibrium with I will start there [17:01:06] closest [17:02:58] Hmm not really doing anything it seems [17:03:00] in any case, I bet it's still the sun heating it up [17:03:08] rcflyinghokie, what exactly did you change? [17:03:17] I uncommented those sections [17:03:21] both? [17:03:33] Yes [17:03:35] you can only have one debug string at a time [17:04:20] Just the one in Hsystems then [17:04:33] yeah, that first [17:04:48] what is the radiator name? [17:05:16] LR is LEM-LR-Antenna [17:07:06] that should give you the debug string then [17:08:54] Radiator 0.227 and temp slowly increasing [17:09:23] 0.280 when i activate the LR itself [17:09:37] that should be watts [17:09:41] that's really low [17:09:43] Yeah [17:09:58] with your isolation factor the sun heat will be in the 1000s [17:10:04] try that with the other debug string then [17:10:34] and there also remove the empty line after the "else", just to be sure [17:11:22] Change that isolation factor too? [17:11:45] first a test what number it has right now, I think [17:11:55] Ok [17:13:06] Earth Sun Albedo all zero [17:13:12] Space -28.9 [17:13:19] Ges -28.9 [17:13:29] Temp slowly climbing [17:16:34] that's less than I thought [17:16:43] probably because you made the mass smaller or so [17:21:17] hmm [17:21:29] although, your numbers suggest that you are in darkness [17:22:02] might be much higher in the sun [17:22:16] oh, and that was probably Tschachim who wrote that code [17:22:30] "Ges" is short for gesamt, German for "total" [17:23:09] I actually made the mass larger [17:23:29] And My SPS bell is in the sun [17:23:37] So the LM is sort of in the sun? [17:52:19] morning! [18:49:15] hey Mike [18:50:12] hey [18:50:14] what's up? [18:50:55] oh, I've been doing a lot of AS-204 launches [18:51:18] I can't really get the normal COI to work, the trajectory just doesn't let it work [18:51:36] our LVDC is at fault, some presettings for it at least [18:51:50] it waits until the last minute to cancel out the negative altitude rate [18:52:03] don't we have the flown LVOT? [18:52:10] we have [18:52:31] hmm [18:52:36] so some implementation problem somewhere? [18:52:37] I have to change a few things for it, especially the timing of the mixture ration change [18:52:46] ratio* [18:52:48] ah right [18:53:01] and also, we can't use all parameters directly [18:53:07] different LVDC version [18:53:31] but yeah, there could also be some implementation issue still [18:54:15] I'll have to do it a bit more systematically, go through the relevant presettings one by one, how they are used in the code etc. [18:55:06] all that said, it's not super off anymore [18:55:30] that's good [18:55:45] actually, whatever I changed made it worse [18:55:54] so it's very close to the Apollo 7 configuration again [18:56:31] http://klabs.org/history/history_docs/jsc_t/as203_launch_results.pdf [18:56:42] the time window where COI is possible might also be fairly slim [18:56:44] maybe this is helpful? that's probably closer to the AS-204 flight program [18:56:55] yeah, for sure [18:57:12] they tested an S-IVB cutoff at 7400 m/s [18:57:20] about 15 seconds before normal cutoff [18:57:53] that is the flight evaluation report, right? [18:58:03] we have that for AS-204 as well [18:58:30] uh, I guess so [18:59:15] ooooh [18:59:16] nice [18:59:18] https://archive.org/stream/nasa_techdoc_19900067467/19900067467#page/n133 [18:59:33] bottom of the right page, listing differences between Apollo 5 and 7 LVDC programs [18:59:42] that is nice indeed [19:12:02] changed one other variable, that might help [19:12:24] I am also not using the Apollo 5 specific thrust and specific input values [19:12:50] the engines itself didn't vary so much, but the mixture ratio did [19:39:02] the test run that MIT did for COI had S-IVB shutdown at 585 seconds, at 88.5NM. MP4 ignition at 664 seconds, at 85.5NM [19:39:12] so a fairly small altitude loss [19:39:31] in my case ignition happens as low as 75NM [19:39:46] I don't think this trajectory is possible even according to the LVOT [19:40:20] the trajectory that MIT used I mean [19:42:06] oh, I found something about the 1412 alarm! [19:42:35] https://www.ibiblio.org/apollo/Documents/Verification%20Results%20Summary%20for%20LM-1%20Mission.pdf [19:42:44] PDF page 89 [20:12:50] afternoon [20:13:46] hey [20:38:02] looks like the early LM's (LM-1) did not have the RCS deflectors [20:38:59] Apollo 9: http://sen.com/thumbs/1024x576/img/apollo-9-full-package-60341447444434.jpg [20:40:34] and all the real photos of LM-1 dont have them, (although all the photos are of it being built) but I can fairly assume the final product did not have them either [21:24:02] oh nice, so the 1412 was a known thing with MP4 [12:39:03] . [16:34:21] morning [16:34:29] hey [16:35:34] I think the uplink activity light is buggy in Sunburst [16:35:52] I've uplinked the GRR signal at T-5 seconds and the light stays on [16:36:08] I got the LM-1 mesh ready [16:36:11] awesome [16:36:28] just add it to the Orbiter2016 branch as a PR [16:36:42] sure [16:37:29] My Apollo 5 branch is also pretty much ready to be merged. A lot of details still to work out, but all the major things are working. [16:37:51] great [16:38:16] and I've added MCC support to it, just for the uplink at T-5 seconds for now [16:38:38] and with that I also added the first part of MCC uplink support for the LGC. That will of course be needed for Apollo 9 and later as well [16:45:32] I guess the old LM-1 mesh can be deleted then? [16:45:39] Or did you directly replace it with the new one [16:47:26] PR sent [16:47:37] I put the old mesh in obsolete meshes folder [16:48:29] ok [16:49:00] also, on top of removing the legs, I removed the RCS deflectors as the early LM's didnt have them [16:51:51] ok [16:53:08] Are you going to make a whole new section for LM-1 in lemmeshes.cpp? [16:53:51] no, after LM separation LM-1 is just like any other LM [16:54:03] it has a few flags in the scenario though [16:54:15] no AEA, no legs, but a LM programer [16:54:57] the No Legs flag will decide which mesh is displayed [16:55:00] Is it basically a sit back and watch the show type mission I guess :D [16:55:01] and that is of course in lemmeshes [16:55:09] pretty much, yes [16:55:24] I will supply two scenarios. One at T-1 hour, LM still powered down [16:55:34] and one at T-60s where everything is ready [16:55:53] and now that the MCC does the GRR uplink at T-5 seconds the whole thing should be automatic [16:56:12] whats the uplink? [16:56:15] V65E [16:56:29] kind of like the V75E you could do as a backup liftoff signal in the CMC [16:56:44] but it's done at GRR, which is at T-5 seconds for AS-204 [16:56:45] ah I see [16:57:14] that has to be uplinked, or else it doesn't start P11 [16:57:27] there also is a liftoff monitor that senses acceleration [16:57:39] but it doesn't work too well [16:57:50] it causes P11 to start occasionally [16:58:10] oh, I think I have an idea what is wrong with Saturn IB launches [16:58:25] it might be caused by a touchdown point change you did in November [16:58:32] Did you manage to get the launch pad (LC-34?) visuals to be properly aligned and all? [16:59:45] yeah, it's decent. LC-37B. Without animations and the textures are veeeery outdated, but otherwise it looks fine [16:59:55] ok, Saturn IB [17:00:01] this it what it saves in the scenario [17:00:01] POS -80.5650771 28.5314449 [17:00:02] HEADING 270.00 [17:00:03] ALT 39.904 [17:00:03] AROT 151.141 -8.280 94.541 [17:00:15] that was an intermediate scenario, T-40 minutes or so [17:00:21] the AROT is the problem [17:00:37] that only gets saved, if the Saturn IB never properly settles down [17:00:58] and that is an inertial attitude [17:01:03] so the S1B is not settling properly? [17:01:09] not 100% sure [17:01:16] when you then load the scenario it tries to use that attitude [17:01:26] maybe the x_target is too small [17:01:29] it doesn't fall over or so, it recovers to 90° pitch [17:01:39] but what does not stay the same is the azimuth [17:01:54] instead of 270° it suddenly then had 271.6° [17:02:09] Let me check what the change I did was [17:02:27] that explains why the IU state vector is quite off, but the insertion orbit is good [17:02:34] because only the azimuth is rotated wrong [17:03:18] https://github.com/dseagrav/NASSP/commit/93c1211af7b72b8d044060f0a620f312aa96557b#diff-b2bc71fa4cb69ff58479796e9d430c5aL220 [17:04:16] I put it too 0.05, which is very low to make the think not bob up/down at ignition, but this low is also not making it settle right I guess [17:04:27] I can try making it 0.1 [17:05:10] it also occasionally falls over [17:05:17] 0.5 is the original very stable value that Fred18 suggested, but it makes the weird up/down movement of the stack at liftoff [17:05:38] yeah 0.1 or 0.2 should take care of that [17:05:42] it falls over, when the computer is loading all the Earth textures for the first time [17:05:49] right [17:06:00] it can also happen when you switch panels, haha [17:06:12] DO you have this issue with the Saturn V? [17:06:35] I don't think so, but I've mostly done Apollo 5 stuff in the last time [17:07:16] Yeah I think Ive fined tuned the SV to a very good balance right now, but the S1B still needs tuning [17:07:34] as you said, 0.1 or 0.2 will probably be quite good [17:07:43] yeah [17:08:05] I've had to repeat the code for the AS-204, so I'll use whatever you are changing it too [17:08:10] to* [17:08:20] and I'll tell you if the issue still happens [17:08:34] another thing in my testing that I fine helps stability is reducing the distance between the TD points (making the stance smaller) [17:09:56] maybe you can try 0.1 to start and see if it still happens? [17:13:01] will do [17:14:26] Bringing the ro down a bit (distance between the TD points) from 30 down to 20 or so might be a good idea... The s1B is using the same number as the SV which is not correct really as the S1B has a smaller diameter [17:36:45] seems like the issue also occurs with the Saturn V, in principle [17:36:49] just not as strong [17:37:02] 270.01° in the scenario [17:37:08] but even that is not really desirable [17:37:23] I can add a fine alignment function for the LV IMU [17:37:32] to align it to whatever attitude it has at liftoff [17:37:43] just before GRR rather [17:37:57] that is basically done anyway, with alignment targets etc. [17:38:09] so it's just realistic to have that [17:39:30] yeah that would make sense to have that [17:40:46] in reality it certainly wasn't done shortly before liftoff, but a while before [17:43:53] I'm not sure changing the x_target factor helps much [17:44:39] it's fairly random [17:44:58] we are unsettling the vessel with the AddForce, which we have to do [17:45:21] and it seems as long as it calculates physics for the vessel it will save an AROT in the scenario [17:49:57] if you put it at -0.5 does it help? [17:58:22] not really sure, it's fairly random [17:58:34] and I got a fairly good startup with -0.05 now [18:18:01] does LM-1 separate the ascent stage during the mission? [18:25:28] yes [18:25:40] there is a long burn of the DPS, simulating the power descent [18:25:49] including throttle down [18:26:16] using the same or similar guidance equations as a powered descent [18:26:32] and when it's at about 20% throttle it then does a random throttle program [18:26:40] 10%, 20%, 50%, 100%, but not in this order [18:26:55] at the end of that it does the fire-in-the-hole test [18:27:03] abort staging at 100% DPS throttle [18:27:15] well, it cuts it off at that point of course [18:27:25] and then follows a short APS burn [18:27:43] and a while later there is a long APS burn, simulating the powered ascent [18:28:22] Because when it stages, the legs will suddenly re-appear on the descent stage I think [18:28:34] oh [18:28:40] that is probably correct [18:28:49] so we need another mesh [18:29:23] and the newly created descent stage needs to have that as a parameter given to it [18:29:28] yeah, for the descent stage project, Sat5LMDSC [18:29:34] yes [18:32:56] I wouldn't worry about the touchdown points of that though [18:33:06] a legless LM is never going to be near the Moon [18:38:22] oh, I don't think you know me well :D [18:43:07] hmm, so, I changed an IMU setting after creating my T-60s launch scenario for Apollo 5. So I am doing one test run from the T-1 hour scenario to see if it still works properly. [18:43:18] and then I can think about merging the branch [18:50:59] morning! [18:53:52] hey [18:54:02] I have a fun Sunburst question [18:54:24] I believe the uplink activity light handling might be a bit buggy in it [18:55:05] I uplinked a "V65E" for the required signal at T-5 seconds [18:55:13] that was and had to be done on the real mission as well [18:55:33] but then the uplink activity light stayed on [18:55:33] hmm [18:55:39] pressing RSET fixes it [18:56:19] in theory it could also be something with my MCC uplink method that I just implemented for the LGC [18:57:57] but it's identical to the CMC one, so... [18:58:05] I'll blame Sunburst first :D [18:59:20] any chance SMARTJOB could be running? [18:59:22] http://www.ibiblio.org/apollo/listings/Sunburst120/P-AXIS_REACTION_CONTROL_SYSTEM_AUTOPILOT.agc.html [18:59:47] "SMARTJOB IS A DUMMYJOB-LIKE FUNCTION DESIGNED TO ABSORB IDLE TIME. IT CAUSES THE COMPUTER-ACTIVITY LAMP TO REMAIN ON, AND PREVENTS THE EXISTENCE OF A JOB SLEEPING IN TH ELOWEST NUMBERED CORE SET." [18:59:48] GETSMART, lol [18:59:55] hehehe [19:00:01] uplink activity [19:00:05] not computer activity [19:00:09] oh oh oh [19:00:19] sorry, just woke up [19:00:23] haha [19:00:33] the uplink was successful and completed in any case [19:00:52] I could simply uplink "V65E RSET" .D [19:00:54] :D [19:01:34] and I believe uplinking a single key, like I did for the aborts, is too quick for the light to ever come on [19:03:13] do further uplinks work if you don't send the RSET? [19:03:41] # UPACT IS TURNED OFF BY VBRELDSP, ALSO BY ERROR LIGHT RESET. [19:04:09] have to try that [19:09:36] it looks like KEY REL should fix it too [19:09:49] but I'm having a hard time finding where how it is turned off automatically [19:10:01] where or how [19:23:36] yeah [19:23:55] I have no idea how you could have any uplink that doesn't just leave the uplink activity light on [19:24:10] in Sunburst at least [19:24:15] right [19:24:24] ok, good to know [19:24:45] I'll implement some uplinks (state vector update etc.) that will be done by the PAMFD or RTCC MFD [19:24:51] that's a slightly different uplink method [19:25:18] in our PCM code, for some reasons it is handled differently, I don't really know [19:25:35] if that also has the light stay on, then we know for sure it's a Sunburst thing [19:26:08] I'm looking at how it works in Luminary to just make sure [19:27:15] # 'UPLINK ACTIVITY LIGHT' IS TURNED OFF BY ..... [19:27:15] # 1. VBRELDSP [19:27:16] # 2. ERROR RESET [19:27:17] # 3. UPDATE PROGRAM (P27) ENTERED BY V70,V71,V72, AND V73. [19:27:23] that's what Luminary says, and my looking through the code agrees [19:28:05] (VBRELDSP is only called by pressing KEY REL) [19:28:53] so it seems like the light should remain on in Luminary too if you uplink anything other than an update program thing [19:29:04] ah, ok [19:29:47] it's only the light though, right? Not some flag as well? [19:30:01] right [19:30:01] the light itself would be irrelevant for Apollo 5, due to the lack of astronaut [19:37:48] you know, I vaguely remember reading something about AGC uplink once that said that every uplink was concluded by a KEY REL or RSET [19:37:52] but I can't find it now [19:53:02] I only know that it is followed by a V33E [19:53:35] but I think that is just what P27 wants as the confirmation to end the uplink process [19:57:51] ah right, in this new scenario the DCS is disabled by default again... [20:02:21] DCS? [20:03:06] Digital Command System [20:03:14] IU uplink [20:04:03] the Saturn IB usually enables it at orbit insertion, Saturn V after TLI [20:04:11] there also is a switch in the CSM for it [20:04:32] but that of course doesn't connect to anything with LM-1 [20:04:58] I guess on AS-204 the DCS was enabled the whole time [20:05:04] ahhh [20:05:06] on all unmanned missions probably [20:05:09] right [20:05:52] same reason as having a switch for the AGC uplink I guess [20:06:11] so that no accidental or maliciously wrong uplink can be done [20:06:38] speaking of turning uplink on, the LGC ICD has an interesting note on powering up the LM DCA/DUA [20:07:04] http://www.klabs.org/history/lm-icd/10_uplink_sh-86.pdf [20:07:08] paragraph at the bottom [20:07:15] of the first page [20:08:25] or more specifically turning it off [20:10:33] yeah, pretty sure a bunch of missions got the "uplink too fast" on an uplink [20:10:52] mission control should have read the ICD :P [20:11:12] who has time for that [20:11:54] a well managed near-disaster this Apollo program [20:13:45] hehehe [20:21:30] uplinking the signal for the suborbital abort works with the uplink activity light on [20:21:34] and it actually turns it off [20:22:30] and there is the new and legless LM-1 mesh in action [20:32:52] well, even more action if I had remembered to open the RCS quad isolation valves before launch [20:39:11] hahaha [20:39:21] awesome :D [17:57:40] 08,03â–„10,13â–„08,05â–„12,02â–„05,06â–„12,07â–„02,06â–„06,05â–„08,10â–„06,03â–„02,07â–„03,08â–„08,11â–„06,02â–„11,03â–„03 PLEASE GO TO #FREENODE AND REMIND TRELANE HOW MUCH OF TOOL HE IS LOOK HERE ===> https://zerobin.net/?cd8099d655af8901#kauJm+pk86X/k9GeT0XVvFAqdGNsC/ofdo0pm+SR99c= mfrma: mcarberry Cannibal^ Guenter 12,05â–„04,12â–„06,03â–„09,11â–„06,08â–„02,05â–„05,05â–„03,02â–„04,03â–„10,10â–„07,08â– [17:57:45] 10,08▄04,10▄12,12▄07,03▄09,09▄02,04▄07,08▄11,10▄06,04▄11,11▄08,05▄05,02▄13,02▄13,12▄07,07▄05 PLEASE GO TO #FREENODE AND REMIND TRELANE HOW MUCH OF TOOL HE IS LOOK HERE ===> https://zerobin.net/?cd8099d655af8901#kauJm+pk86X/k9GeT0XVvFAqdGNsC/ofdo0pm+SR99c= lfblpq: mcarberry Guenter Thymo 09,09▄03,09▄04,05▄07,04▄12,02▄05,07▄09,03▄08,08▄06,03▄10,12▄ [17:57:49] 07,11â–„11,12â–„07,12â–„12,04â–„13,05â–„12,03â–„05,03â–„02,05â–„09,13â–„07,09â–„10,03â–„12,13â–„08,07â–„11,09â–„13,05â–„10,03â–„09 PLEASE GO TO #FREENODE AND REMIND TRELANE HOW MUCH OF TOOL HE IS LOOK HERE ===> https://zerobin.net/?cd8099d655af8901#kauJm+pk86X/k9GeT0XVvFAqdGNsC/ofdo0pm+SR99c= hpozfxqqky: orbifan Thymo Cannibal^ 10,09â–„03,10â–„07,13â–„06,09â–„03,06â–„03,08â–„10,05â–„02,07â–„12,04â–„06,13â [17:57:54] 03,02▄10,12▄07,12▄05,08▄06,02▄04,11▄11,11▄05,03▄07,13▄11,05▄02,09▄08,10▄08,03▄13,04▄02,05▄07 PLEASE GO TO #FREENODE AND REMIND TRELANE HOW MUCH OF TOOL HE IS LOOK HERE ===> https://zerobin.net/?cd8099d655af8901#kauJm+pk86X/k9GeT0XVvFAqdGNsC/ofdo0pm+SR99c= buubsrz: indy91 Cannibal^ orbifan 09,10▄03,02▄02,12▄07,08▄07,07▄09,06▄06,09▄08,05▄04,05▄10,08▄10,04▄ [17:57:59] 13,11▄04,07▄04,05▄04,13▄07,02▄06,12▄12,02▄02,11▄13,06▄05,11▄06,02▄04,13▄06,10▄07,10▄06,04▄06,08▄13,04▄06,13▄06 PLEASE GO TO #FREENODE AND REMIND TRELANE HOW MUCH OF TOOL HE IS LOOK HERE ===> https://zerobin.net/?cd8099d655af8901#kauJm+pk86X/k9GeT0XVvFAqdGNsC/ofdo0pm+SR99c= xrvycdrzoi: thewonderidiot indy91 Guenter 03,11▄12,08▄07,05▄03,10▄07,13▄05,09▄12,08▄ [17:58:04] 13,12▄08,05▄10,08▄04,02▄02,04▄07,12▄07,12▄06,05▄10,12▄08,02▄11 PLEASE GO TO #FREENODE AND REMIND TRELANE HOW MUCH OF TOOL HE IS LOOK HERE ===> https://zerobin.net/?cd8099d655af8901#kauJm+pk86X/k9GeT0XVvFAqdGNsC/ofdo0pm+SR99c= gslktlgwbu: thewonderidiot indy91 Guenter 10,07▄13,06▄08,04▄06,05▄04,12▄10,09▄03,03▄13,07▄02,08▄02,04▄06,09▄09,09▄02,12▄03,02▄02,12▄ [17:58:09] 09,10▄10,04▄07,02▄13,12▄09,13▄05,02▄07,10▄13,13▄04,12▄09,10▄02,11▄09,07▄08,08▄10,05▄05 PLEASE GO TO #FREENODE AND REMIND TRELANE HOW MUCH OF TOOL HE IS LOOK HERE ===> https://zerobin.net/?cd8099d655af8901#kauJm+pk86X/k9GeT0XVvFAqdGNsC/ofdo0pm+SR99c= rrphzbuoey: thewonderidiot Thymo Cannibal^ 13,11▄06,11▄05,13▄08,04▄05,13▄09,05▄12,11▄11,10▄06,11▄07,02▄09,10▄ [17:58:31] How...Annoying [17:58:42] I can't even properly read it [17:58:45] it's all... colors [19:44:06] Well. There is our first spam bot... [19:56:26] so many modes [20:03:01] morning! [20:04:17] hey Mike [20:04:57] what's up? [20:05:01] made some Apollo 5 progress [20:05:20] last year we basically got the APS-2 burn to work, but not very well [20:05:41] the SCOT has some targeting parameters for the padload, but they are in the wrong coordinate system [20:06:01] luckily the SCOT also has the rotation matrix for this, which I didn't realize last year [20:06:13] so now the burn works pretty well [20:06:17] +ntcps, and if you're feeling particularly fascist, +intcpsmk and make everone who isn't +v have to ask Guenter to do their talking, stripping out links and color codes. [20:06:37] oh sweet [20:06:51] haha, I think we can do that if the spam bots become a real problem [20:07:18] runs out of fuel before completing the burn, which is normal, and it has the expected program alarms [20:07:25] :D [20:07:34] so that's the whole mission, then :D [20:07:39] kind of [20:08:13] the target orbit is 170x470 and it was 175x420 for me. 10 seconds more of the APS burn and it would have been spot on [20:08:30] after the APS-2 burn come a few RCS tests [20:08:53] and we talked about this last year as well, there must have been a way to maneuver the LM to a specific inertial attitude [20:09:27] the RTACF manual for Apollo 5 has a calculation for this specific purpose. And the display for it simply has the inertial IMU angles at ignition for it. [20:10:36] it's not one of the uplink extended verbs in this list: https://www.ibiblio.org/apollo/listings/Sunburst120/UPDATE_PROGRAM_PART_1_OF_2.agc.html [20:11:21] hmmm [20:12:18] http://www.ibiblio.org/apollo/Documents/LM-1%20Trip%20Report%20at%20MSC.pdf [20:12:21] second full paragraph on page 3 [20:12:51] oooooh [20:12:52] awesome [20:13:19] "was supposed to be a post-mission test" [20:13:29] that's what the SCOT also says [20:13:42] the Apollo 5 mission is basically over after the APS-2 burn [20:14:01] but they scheduled 5 RCS burns, just in case they were still able to do anything useful with LM-1 [20:14:39] I'd like to include this as MCC uplinks [20:14:58] hehehe [20:15:10] sounds great [20:15:13] it's so hacky, I love it [20:15:24] the translation itself was commanded through the programer I think [20:15:54] there is a +X translation command, which actually stands in for the TTCA and sets the LGC input bits for a +X translation [20:16:23] yep [20:16:45] and programer commands can be sent easily with one of the extended verbs [20:19:13] so how does one start KALCMAN3 with V30? [20:19:23] and where do I have to uplink the attitude to [20:20:00] the specified erasables :P [20:20:04] one sec, let me look [20:21:47] okay, so if gimbal angles are precomputed, they are stored in CPHI, CTHETA, CPSI [20:22:03] those are the inertial IMU angles? [20:22:21] for example, the DPS cold soak attitude calculation should result in angles for this [20:22:38] yeah, that looks right [20:22:51] so I uplink those angles, then reset the ATTCADR [20:22:55] and then something with V30 [20:23:07] yep, let me work out the V30 [20:24:04] hmm, what priority should we use [20:24:48] heh, MP16 starts it with "PRIOKM", that sounds good [20:25:05] MP16 isn't usable though, is it? [20:25:25] not for the RCS tests at least [20:25:26] doesn't stop us from stealing the KALCMAN3 job priority number from it [20:25:30] of course [20:29:34] okay, try this [20:31:20] V25N26E 20001E 2067E 70063E V30E [20:33:01] thanks [20:33:14] that is all for the V30, right? [20:34:00] I'll try that manually now [20:34:01] yeah, that just sets up job priority, FINDVAC-type, and address of KALCMAN3 for V30 [20:34:52] ATTCADR is already 0 [20:35:03] I think I will have to reset that after each burn or so [20:35:10] yep [20:35:48] which addresses are CPHI etc? [20:35:50] I can't really tell [20:36:00] 1603 to 1605 maybe? [20:36:15] no, 1631 to 1633 [20:36:42] in E3, yeah [20:38:40] ah damn, I used the wrong addresses [20:38:43] it did the maneuver though [20:39:17] sweet! [20:39:25] now ATTCADR is -1 [20:41:27] second maneuver, now properly to 0/0/0 please [20:41:38] yep, worked [20:41:49] \o/ [20:42:01] and now I test the translation command [20:42:24] thank you, Jay Sampson [20:43:00] yeah, that document is pretty good [20:43:15] uhh, now [20:43:17] V67E [20:43:30] 200E for the translation command [20:43:38] but P27 still wants something [20:43:54] maybe just a V33? [20:45:08] probably doesn't work yet, I have to override the normal TTCA code [20:57:40] yep, it works [20:58:06] I can now command attitude maneuvers and translation maneuvers [20:58:15] that's all I need I guess [20:59:33] at least for RCS maneuvers 1-4 [20:59:47] the last one used 4 jets for the translation maneuver to RCS depletion [20:59:50] excellent! [21:00:02] but that is probably just a DAPBOOLS change [21:00:27] :D [21:00:36] oh, APS-2 is also an excellent test for my RCS propellant supply [21:00:41] supply logic* [21:00:59] because it switches to APS interconnect (RCS using APS propellant) during the burn [21:01:06] also opens and closes crossfeed [21:01:11] a lot going on [21:01:59] that's all hardcoded in Sunburst of course, no MCC uplink necessary [21:03:00] hehehe [21:03:02] I love Sunburst [21:03:44] me, too, for some of same and some other reasons [21:03:59] it has all the guidance equations for a lunar landing that Luminary has, just all automatic [21:04:21] it even has more than Luminary. DOI calculation for example, that was deleted in Luminary [21:05:48] hah, wow, I didn't know that [21:06:44] I mean, it's not a very complicated calculation. It targets 0 altitude rate and a specific perilune altitude [21:06:49] so setting up the right conditions for PDI [21:07:29] but still needs too much memory for Luminary I guess [21:07:46] it's in the early GSOPs and the RTCC MFD uses similar calculations for DOI [21:09:19] it works as advertized in Sunburst [21:10:12] any idea how the IMU angles are scaled? [21:10:23] degrees/360 is commonly used in the AGC [21:11:33] you mean for KALCMAN3? [21:11:44] yes [21:11:55] how are CPHI etc. scaled [21:13:32] hmm [21:13:39] scaled by 2*pi [21:13:46] yep [21:13:51] that is right [21:14:04] radian/(2*PI) = degrees/360 [21:14:19] so I know what to do [21:47:04] taught the MCC how to uplink this stuff [21:47:08] so RCS tests are go! [21:47:26] woooo! [21:47:35] nice work :D [21:48:13] and now general programer commands for the burn itself [21:48:22] I also need to use the programer for the RCS configuration [21:48:35] the first RCS burn is supposed to deplete RCS system B [21:48:52] so I guess I'll use crossfeed and close RCS A [22:22:15] hey [22:22:30] hey Alex [22:28:32] hey [22:30:45] AlexB_88, Sunburst is solved, I am just adding the planned RCS tests late in the mission to the MCC. But that is mostly for fun. I'll merge my development branch soon, so that everyone can try the mission. [22:31:01] :D [22:31:07] is actually going to fly a whole mission for once [22:31:13] or watch it fly itself as the case may be [22:31:35] yeah, from the T-60s scenario on that I will provide you shouldn't have to do anything [22:31:48] great stuff. Ill try to update the descent stage mesh tomorrow [22:32:26] you don't even see it on Apollo 5, you do a short APS burn right after staging and gone it is .D [22:32:27] :D [22:44:16] night [05:04:19] "The Guidance Officer loaded the predetermined desired CDU angles into the specificed erasable memory locations and requested the attitude maneuver program (KALCMAN3) via a VERB 30 UPLINK commands. .... KALCMANU was designed to be used only under LGC control." [05:05:17] it turns out that the way to do this is via sending V25N26E 20001E 2067E 70063E V30E [05:05:26] and that was the final mystery, so it all works now :D [05:05:40] er [05:05:42] that was meant for my friend [05:05:46] ignore me [15:43:34] morning [15:54:31] hey [15:54:44] can you help me test something? [16:19:14] sure [16:21:19] LM ascent stage, attitude hold [16:21:31] and then +X translation [16:21:37] with the TTCA [16:22:06] my two questions are: howe well does it hold the attitude and do you get any red flag for a thruster failure [16:36:57] holds good attitude and no flags [16:37:05] in AGS mode [16:38:09] and in PGNS? [16:38:34] yep its good in PGNS too [16:38:47] interesting [16:39:03] I fixed a bug in the ATCA in my branch and I think it's causing new issues [16:39:26] mostly for very short duration firings of the RCS [16:39:43] I'll revert that change again, just to see what it does in Sunburst [16:43:09] yep, that fix caused my new issues [16:43:47] so, essentially we simulate the behavior of the RCS as it really works. A small delay until it starts firing, then it ramps up, full power, ramp down, off [16:44:08] the bug caused it to fire immediately upon request [16:44:15] at full power [16:44:45] but without that it sometimes commands it on and off very quickly and it never has a chance to develop thrust, at least not at 60fps [16:45:21] the shortest duration for a command that will do something is 14ms, 60fps is 16.666ms per timestep [16:45:48] so I will have to come up with a way to fix this bug without causing these new issues [16:45:50] hmm... [16:53:28] at least it's not a Sunburst DAP configuration issue or something with the thrust failure detection [17:13:18] that is the last issue I want to fix before I merge my development branch [17:20:32] looking forward to fly the legless LM [17:20:56] ah, it got confused if the thruster was commanded on, then off, and then on again before it could complete the ramp up/down [17:21:05] the simple fix seems to work [17:21:32] you mean, let the legless LM fly itself :D [17:22:32] yep and me watching while drinking a beer [17:23:13] sounds great [17:27:03] hmm, I want to combine two uplinks for the programer, but it seems it does the two sequences too quickly after each other. [17:27:22] I wonder if I can trick it by sending a bunch of key release signals in between [17:30:17] haha, it worked. 5x key release didn't work, but 10x did :D [18:41:59] morning! [18:42:09] hey Mike [18:42:27] what's up? [18:42:38] discovered a fun new thing that Sunburst does [18:42:43] ooo [18:43:08] if it detects an thruster failure input bit, then it commands that thruster pair off via the programer [18:43:48] those input bits are only set by the thruster pair switches on the panel [18:44:26] that spooked me quite good. I was playing around with the RCS configuration and when I was switching one thruster pair off manually then 1 second later it automatically did the same thing again. [18:44:57] because Sunburst was also setting the switch to off [18:45:07] I thought our panel code was broken or so [18:47:15] https://www.ibiblio.org/apollo/listings/Sunburst120/RCS_FAILURE_MONITOR.agc.html [18:47:31] I have to look in the LM-1 Systems Handbook what can actually cause those input bits to be set on LM-1 [18:50:02] interesting [18:50:17] lol [18:52:14] and I just fully figured out the LM-1 alignment. So now I can calculate the IMU angles for a specific RCS burn I want it to do [18:53:22] I had a MATLAB script from last year which helps [18:55:34] excellent [18:56:29] it has a really weird alignment, so that it doesn't go into gimbal lock during any of the maneuvers. Luckily the Sunburst code is full of comments [18:56:49] yeah they did a really good job with comments in Sunburst [19:11:46] I'm finally rearchitecting virtualagc for counters [19:12:11] hopefully will have everything that currently works working again today [19:12:49] sounds scary [19:14:55] I'm going to test standby before I give it to you, I promise [19:18:22] it should be much cleaner, overall [19:30:17] ok, MCC for Apollo 5 should be done. Now I have to test it. [19:30:35] And then I'll create the T-60s scenario [19:30:49] and then I can release the Apollo 5 update [19:31:05] :D:D [19:31:09] woohooo! [19:32:06] there are 5 RCS tests, the last one is to depletion and it even has an uplinked LM mass that is wrong on purpose, to test how the DAP handles it [19:32:34] and then at T+13 hours the mission is properly done [19:32:37] all propellant used [19:32:52] well, minus about 5% in the descent stage [19:34:53] can't have total depletion with a FITH :D [19:35:05] APS-2 ends at T+6:30, so most of the exciting stuff in over by then [19:35:55] is* [19:42:39] Is the LM just left in orbit? [19:43:49] yeah, final orbit is 303x470 NM according to the SCOT [19:44:33] probably takes as long as LM-3 to decay I guess [19:44:48] LM-3 ascent stage reentered in 1981 [19:49:33] RCS #2 complete [19:50:53] attitude hold works pretty well, even with just the system A thrusters [19:51:06] they had a good DAP by the time they had to release Sunburst [19:56:17] "even has an uplinked LM mass that is wrong on purpose, to test how the DAP handles it" [19:56:25] I guess they decided to pull this forward in the real mission, too :P [19:56:58] not in purpose, if I read the memo correctly [19:57:00] on* [19:57:22] yeah, I was being sarcastic, heh [19:58:08] I didn't update the mass so far, although it will be quite off, due to RCS B being at 0% and RCS A at 60% [19:58:18] seems to still handle it quite well [20:00:43] I wonder if it would be possible to have a description appear in the MCC text area as each event happens on what its doing now [20:03:36] yeah, I already have that [20:03:48] at least for all the MCC uplinks [20:04:17] but it should be possible to also add that for the Sunburst controlled part [20:05:32] mice [20:05:36] nice* [20:06:44] RCS #3 and #4 done and tested [20:06:55] just one more coasting phase and a burn to depletion [20:07:32] Got to go but Ill be back later to try its pushed by today [20:07:47] if its pushed by today* [20:07:54] it might be, not sure [20:08:20] later! [20:19:47] and LM-1 is out of RCS [21:04:52] haha, it's also running out of power at that point [21:07:38] heh [21:07:41] coincidence? [21:09:28] well, they certainly did an EPS analysis for Apollo 5 and wouldn't have scheduled any important events at a time where the batteries have run out of power [21:10:08] during the last RCS burn the voltage from the batteries is low enough to cause a bit of trouble, mostly because it is still trying to fire the RCS [21:16:38] the RCS needs quite a bit of power, but only when it's actually firing [21:17:01] after it runs out of RCS it doesn't command any bursts, but continuous firing, to achieve the desired attitude [21:17:11] and I think that is what is pushing it over the edge [21:28:38] my development branch has been merged [21:29:25] I hope I have added all new files [21:29:38] sweet! [21:29:42] I will definitely check it out tonight [21:31:44] I chose the lazy way and used my latest T-60s scenario as the default one [21:31:51] it has the TEMP light on [21:32:00] because GSE is still missing at LC-37B :D [21:32:17] hehehe [21:33:56] all temperature will be normal before insertion even [21:34:02] temperatures* [21:34:48] ah, I did indeed forget to git add some files [21:39:23] I guess now I am allowed to take a detailed look at the Saturn Systems Handbook [21:55:09] it built correct, so, good night! [05:41:39] .tell indy91 Colossus memos have arrived from the Smithsonian! they cover revisions 197 through 221, plus a few non-version memos involving lunar stuff [05:42:13] .tell indy91 Margaret writes a mean memo, she goes into waaay more detail in changes between versions than the Luminary memos do [05:42:25] .tell indy91 I'll scan them in tomorrow night [13:18:46] . [13:19:01] :D [15:10:29] Hey [15:12:38] hey [15:12:46] What's up? [15:13:22] the Apollo 5 update is released! [15:33:33] Awesome! [15:34:05] I've been mostly busy at college today building a webshop. [15:34:22] I'll be sure to try Apollo 5 when I can find the time. [15:35:58] yeah, it's a fun few maneuvers to watch [16:27:59] hey [16:29:51] hey Alex and Alex [16:31:43] tried Apollo 5 last night, good work! [16:32:39] thanks! [16:32:55] I forgot to fire the DPS propellant valve pyros in the T-60s scenario [16:32:58] that is now fixed [16:33:26] without that fix you would get the same result as the actual mission during the first DPS burn [17:34:51] morning! [17:38:00] hey [17:38:08] what's up? [17:38:49] just a bit of experimenting with docking ports [17:39:49] fun [17:39:58] I launched Apollo 5 last night [17:40:09] it makes perfect sense but I wasn't expecting the DSKY to be so uninteresting during launch, heh [17:40:36] yeah, there is not much going on there [17:40:38] looking at the downlists, Sunburst is probably the best reason to resurrect the telemetry client, there's a lot of good stuff in there like mission timer values [17:40:41] the most interestin part is the program [17:41:08] also, I did a fix earlier today, your scenario would suffer the same fate as the real Apollo 5 mission [17:41:18] hahahaha [17:41:19] awesome [17:41:23] two DPS propellant pyros aren't fired [17:41:45] I think I killed my scenario anyways [17:42:07] I was time acclerating at 10x and after a while it switched to POO, which I figured probably wasn't supposed to happen [17:42:08] how so [17:42:26] it will be in P00 during coasting [17:42:31] ah [17:42:33] then nevermind :) [17:42:36] P11 during S-IB flight, P12 during S-IVB flight [17:42:43] P13 once it notices S-IVB shutdown [17:42:47] P00 after a few minutes [17:42:59] and then it will stay in P00 until shortly before LM sep [17:43:16] gotcha [17:43:19] what I noticed is that Sunburst often displays a 34 in the verb [17:43:34] is that so ground could quickly uplink an ENTER to stop the current program? [17:44:12] that could be [17:44:14] I'll check the code [17:44:28] also in the downlist is the last 8 commands sent to the LMP, that's pretty cool [17:45:08] I might look into getting that working after the counter overhaul [17:45:26] great [17:45:42] hmm, I really should have created a new T-60s scenario [17:45:46] which is going really well, by the way, the scaler logic is sooo much cleaner now [17:45:49] just noticed a missing padload change [17:48:06] just one address though it seems [17:48:42] and that is not something you can easily fix in orbit, because of the way the mission timers work [17:49:38] I changed the timing of MP13 initiation on orbit, had to manually edit the timer in the erasable [17:49:46] luckily it's saved in seconds there [17:52:55] so have you taken your detailed look at the new systems handbook yet? :D [17:53:09] a little bit [17:53:50] there are a few things I should be able to implement quickly [17:55:23] cool [17:55:32] and it's a great resource overall [17:55:35] :D [17:55:47] and at some point we'll get later ones with the missing sections from NARA [17:55:48] especially for the S-IVB and for J-2 engine electronics [17:55:53] awesome [17:58:17] also like I mentioned, Margaret's memos are crazy [17:59:07] for every revision, multiple pages of point by point, everything that changed, followed by a section of all known issues with the last revision, followed by a section discussing planned future changes, followed by a section saying how many cards went into the revision and the fixed word count change [18:00:12] it's too bad it cuts off at 221 and doesn't make it all the way to 237 [18:01:29] yeah [18:01:51] I still want to find out how to blame for the operator error light in V49 in C237 [18:01:55] who* [18:08:23] haha [18:08:39] seems like a Saturn IB schematic has accidentally found its way into the Saturn Systems Handbook [18:08:55] whoops [18:08:56] for what? [18:09:16] S-IVB J-2 Engine Electronic System [18:09:41] I first noticed that it has a difference in the function of two switch selector channels [18:10:04] but it shows a "S-IB/S-IVB Separation Plane" [18:10:07] it also* [18:11:03] heh [18:28:02] brb [19:10:48] indy91: I think I'm going to include the VFAIL alarm for you with these changes [19:11:14] so you set the input voltage to the AGC however often you like and the voltage fail alarm responds correctly [19:11:21] ok [19:11:27] that should be simple on our side [19:12:44] I will still have to manually copy over your changes to our Virtual AGC, not looking forward to such a big update [19:13:14] yeah, what all was different? I'm wondering if I can knock out the rest of the differences with this update [19:13:52] hmm, maybe [19:13:59] I'll look through them [19:14:02] I remember DOWNRUPT was a big one and I think the logic for that was going to be changing [19:14:11] or will be, rather [19:28:22] will this update require significant changes on the NASSP just to work? [19:28:31] in* [19:28:57] yep [19:29:07] well, maybe, not necessarily [19:29:17] but probably [19:29:34] the answer to that probably changes on a counter by counter basis [19:29:36] so... yeah [19:30:14] does that include IMU pulses? [19:30:24] because, we don't even have working CDUs for that [19:30:32] and no OCDUs [19:30:53] IMU pulses will be supported but for those I imagine your current method will continue to work [19:31:01] the CDUs have the least associated logic [19:31:13] for PIPAs, it depends on whether or not we want to simulate the precounter [19:31:54] I mean, our PIPAs already do something on a pulse by pulse basis [19:31:59] might not be so bad for those [19:32:13] does every pulse cause a counter value change? [19:32:39] or do you not pass through precounted pulses? [19:33:28] uhh, no idea [19:33:40] yeah [19:33:52] there's going to be a lot of work to be done to integrate this, heh [19:34:49] I am also worried that this will make it more difficult to ever implement the Virtual AGC in another simulator [19:36:03] I can probably provide an interface to it that looks something like how it used to work, if that is a big concern [19:36:09] or people can use older versions [19:36:18] right [19:36:55] I think as long as it very clear to any developer what has to be done to interface with the Virtual AGC it is all good [19:37:05] yeah [19:37:31] plus, this way makes the AGC behave more as documented, which is always helpful for that [19:44:32] true [19:45:16] I don't think a backwards compatible interface is necessary, it's not like many people are using it anyway [19:47:49] there are just two things I am always worried about. 1. It becomes prohibitively difficult to implement the Virtual AGC in a new simulation and 2. Virtual AGC changing for the needs of NASSP instead of the other way around. [19:48:56] I haven't seen your change, so I can't tell yet if I should even be worried, haha [19:49:00] changes* [05:49:40] .tell indy91 I scanned in the Colossus memos: https://drive.google.com/open?id=13hjx9aSDoA7J5XOxA_csJ6Ihb-apsvcT [14:53:41] . [16:16:53] Good morning [16:18:14] hey [16:19:05] I see I missed a lot of Apollo 5 stuff as I fought fever and flu [16:19:32] ouch, I hope you feel better now [16:19:54] On the mend for sure, thank you [16:20:07] Finally have some cognitive ability back [16:20:21] but yes, my Apollo 5 work is basically complete. You can start the scenario and the full mission runs automatically [16:20:28] Very nice [16:20:37] I will play with it I am curious [16:20:54] I do also want to get back to that radiator issue I left suddenly and incomplete [16:21:00] http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2957.0 [16:21:14] there is a link with an Apollo 5 timeline [16:21:56] Thank ya [16:22:30] Haha your MSS arms dont touch the vehicle [16:22:40] and they are not animated at all [16:22:47] LC-37 is just a static mesh [16:23:20] That is so weird launching in a LM [16:24:24] yeah [16:24:42] you will also notice that the window directs are all wrong [16:24:46] directions* [16:24:55] not really much I can about that [16:25:17] the separate LM has a different coordinate system orientation than the CSM or the Saturns, so I had to go with the Saturn one [16:25:51] Ah yeah [16:27:14] And of course being able to see out during launch [16:27:26] right [16:27:44] but, I am actually experimenting with something that would solve this [16:28:21] I managed to have separate S-IB and S-IVB vessels docked to each other on the launchpad, without Orbiter exploding [16:28:54] So the docked vessels as stages theory? [16:28:58] yeah [16:29:05] I've studied the code of the default Space Shuttle in Orbiter a bit. It might be possible after all. [16:29:06] That is very promising [16:29:23] it would solve so many problems, without creating many new ones [16:29:49] if we had separate vessels for ascent and descent stage of the LM we would also not have to implement a shifting CoG [16:30:06] because the CoG of the docked vessels would be almost exactly right [16:30:33] but for now I am just experimenting with S-IB and S-IVB [16:30:51] I might try to get AS-203 working, the only mission that didn't launch any CSM or LM [16:32:20] It would also solve the LM creation problem of course [16:32:30] Being able to power and pressurize right away [16:32:37] yep [16:32:48] the only new issue this creates is aerodynamics [16:32:56] but that should be possible to solve [16:33:37] the stage would check if it is docked to something and then determine its aerodynamic parameters [16:33:41] When (or more appropriately where) does orbiter stop simulating atmospheric drag? [16:33:52] 2000km or so [16:34:39] but it's mostly relevant for the stack after liftoff [16:34:45] Right [16:34:59] I meant for parasitic drag in orbit, I am glad it is realistic [16:35:19] it is fairly realistic, but our stages don't all have realistic parameters for it [16:35:45] e.g. the Apollo 7 S-IVB should drop in altitude a bit during the coasting period before docking [16:35:52] uhh [16:35:55] rendezvous I mean [16:36:24] Right [16:36:36] either one vessel would determine the aerodyamics of the whole stack [16:37:24] or some drag is calculated in each stage [16:39:29] the original idea for separate stages also included a launchpad with a giant mass and the S-I docked to it until liftoff [16:39:51] which hopefully would prevent the Saturn to move or even fall over [16:42:20] but right now a S-IB with a S-IVB on top of it already works pretty well [16:42:34] Good start [16:45:54] I will need to develop a new system for sending commands from the IU to the docked S-IB stage [16:47:20] Which will also be needed to say command a sep from the CSM I imagine [16:54:48] yeah [16:56:19] but at least there won't be any logic necessary to determine which stage can receive commands or not [16:56:33] it will be as simple as: is still something docked there or not [16:56:49] so commands from the IU to the S-IC will have to go through the S-II as well then [17:02:02] I'll probably not bother to make separate S-IVB and IU vessels [17:02:04] or even SLA [17:02:27] but CM/SM and ascent/descent stage should be separate, if possible [17:02:28] Yeah those 3 can just be 1 [17:03:00] Right to improve CoM [17:05:27] and to not have to create separate vessels [17:05:33] at CM/SM sep [17:07:49] I'm not sure about the LET [17:08:12] having another docking port in front of the CM could mess with the normal docking [17:08:26] Could it just be docked via the same port? [17:08:40] I mean the LET more or less hangs onto the probe [17:09:15] right [17:09:40] the default Shuttle actually deletes it docking port for the tank after tank separation [17:09:49] so we could just do that as well [17:13:25] Ah true [17:26:33] morning! [17:27:58] Hey Mike [17:28:01] and others [17:28:46] o/ [17:29:00] hey [17:32:05] making progress on the yaAGC refactoring [17:32:18] working through the various cases to make sure the right amount of MCTs happen [17:32:31] I think I discovered that BZF and BZMF drop an MCT if the branch isn't taken [17:48:27] how wasteful [17:49:22] yeah [17:49:29] get anything useful from the colossus memos? [17:50:17] not really, unfortunately. But I have just quickly looked through a few of the later ones. [17:50:49] interesting that EMDOT was originally in erasable memory and was then moved to fixed memory [17:50:55] close to C237 actually [17:51:12] and then between C237 and C249 it was in erasable memory again [17:51:47] maybe someone realized that the SPS could have a different mass flow rate from mission to mission after all [17:53:05] but I have to look through all the memos, maybe something is in there that will help with padloads [17:57:09] all of these memos seem to have the same format [17:57:24] very structured [17:58:30] "Revision 219 was BAD with 3 cusses" [17:59:30] it would be really great to have even more of these memos [18:03:01] yeah definitely [18:03:17] there's a couple random ones in the Neil Armstrong collection, but other than that [18:03:33] I wonder if there's any chance that Margaret has the rest of them [18:07:02] or MIT [18:07:07] well, Draper Lab [18:09:48] heh, yeah [23:14:13] thewonderidiot: What parts of yaAGC are you refactoring? Just agc_engine? [23:15:37] what else is there to refactor? heh [23:18:22] I'm working on all the other files trying to make them readable. I can imagine massive merge conflicts if we both work on the same files. [23:18:59] Doing anything with agc_engine_init? I did that one already. [23:19:08] I will have to, yeah [23:19:42] what all are you doing to them? [23:21:05] Fixing indentation. Adding braces to if statements where they make sense and putting function declarations on 1 line instead of 3. [23:21:24] All formatting. No changes to the code itself. [23:21:36] okay, sounds good [23:21:58] I can just do the same to my stuff [23:22:59] More often than not I would find lines that used a combination of both tabs and spaces. [23:23:19] https://github.com/Thymo-/virtualagc/tree/yaAGC-cleanup [23:24:27] I haven't talked with Ron about it yet but I'm putting everything in that branch for now. [23:25:47] I used set listchars=tab:>- and set list in vim so it would show me tab characters. Made the reformatting much easier. [23:33:41] hmm [23:33:58] so, I have an old email from Ron, from September 2016 [23:34:11] I would like to run 'indent' on all the C/C++ source as well.  However, I've been reluctant to do so, or even to do so on any individual file, because of the potential difficulties it could cause in detecting differences between code in the repo and cloned repos.  I fancy that the same difficulty might occur with the AGC code.  For example, the code in virtualagc vs the code in cgarry.  Even for me personally running 'indent' might cause a probl [23:34:11] Of course, I may be exaggerating the difficulties involved, and perhaps the merging tools handle this case very easily.  Anybody know for sure?  With 'diff', for example, there are settings that can be used to ignore whitespace differences. [23:34:12] At the very least, we'd have to publish our code-formatting standard in advance. [23:34:23] I really think you ought to talk to him about it [23:43:27] I will. I'll send him an email when I'm around again friday. [23:44:06] Is he talking about merge conflicts between the formatted files and previous forks? [23:44:13] .in 36h Send email to Ron. [23:45:06] I guess? [23:45:22] or just general diffing [23:48:58] I know that diff shows differences between tabs and spaces. I don't see how it would cause any more issues than any other big PR. [23:51:52] I'm off to bed. Night! [23:51:55] night! [12:40:57] . [14:41:56] Hey [14:44:45] hey Thymo [14:45:19] Quite a storm today [14:45:32] yep [14:46:05] Public transport has shut down and debris is flying around. 2 people lost their lives. [14:47:36] mostly the same here as well. It's gotten much better in the last hour though, I think the worst is over [14:48:02] Yep [15:34:16] morning [15:36:23] hey Alex [15:49:18] I'm testing docked S-IB and S-IVB stages on the launchpad [15:49:45] just to see if it is possible to launch a stack of docked vessels [15:51:08] the touchdown points I figured out for the S-IB seem to work at least [15:56:12] I had trouble getting the physics to kick-in when I tried that (the addforce hack didnt work) [15:57:40] yeah, if I run into the same issue and can't find a fix then I will abandon this again. I'm just testing a bit in a development branch [16:11:13] Good morning [16:13:34] hey [16:14:03] Is the forum site down? [16:14:39] ibiblio issue I would guess [16:15:02] Yeah thats what I thought [16:18:03] I am going to revive one of my old Apollo 9 saves and record a docked DPS :P [16:18:59] I am thinking about recording it without the beta as well just to illustrate the problem that was there before [16:23:56] fun [16:24:10] I should probably start working on an Apollo 5 video. [16:24:34] I'll be away the whole weekend, so not much time if I want to have it done on Monday [16:26:07] Oh were you able to look into the radiator problem at all by chance? I know I kind of left that unfinished [16:28:25] I can't even remember what the problem was [16:32:17] Haha that was me yesterday [16:32:36] It was heating up too much [16:32:44] Didnt seem to be radiating off enough heat [16:58:03] well, except increasing the relevant factors of the radiator I also have no idea [16:59:04] indy91, any luck getting the LV SV's any better on the S1B/SV? [16:59:19] I think you had talked of adding a fine align before GRR [16:59:24] right [16:59:29] haven't done anything for that yet [17:04:31] Seems that only increasing mass is doing anything noticible [17:06:18] how are radiators used in the CSM? [17:08:13] are we using it in a completely different way? [17:08:34] I dont think so [17:08:46] The SMRCS quads for example are used like I am using them in the LM [17:09:10] All of those radiators in the CSM have the same parameters 0.03 0.04 and 10000 [17:09:27] Even the ECS radiators [17:10:19] makes them predictable :D [17:12:04] Well thats what i started with as well [17:12:26] I just dont understand why they just constantly heat seemingly out of control [17:12:56] sun or an attached heat load [17:13:13] that's the only two heats going into it [17:16:28] Right [17:17:52] unless there is a heater that is running as well [17:20:04] In this case I am looking at the RR LR and SBD [17:20:24] The RR and SBD dont have heat loads just heaters [17:20:38] So right now I am watching them all heat up with their heaters [17:20:49] Heaters switch off and the temps climb and the same rate it looks like [17:22:09] then it has to be the thermal isolation [17:22:44] The landing radar is the only one that behaves [17:23:18] And the only difference is increased mass [17:25:04] morning! [17:26:31] Hmm the SBD and RR just hit about 220 degrees and started falling [17:27:39] hey Mike [17:27:44] rcflyinghokie, did it become dark? [17:27:49] Nope [17:28:03] LM is in more sun actually [17:28:09] might also be an attitude thing [17:28:27] Yeah [17:30:05] Its the attitude [17:30:48] Any good advice as to how to properly change the position of the antenna? [17:31:14] no idea, never tried that [17:35:22] Its an offset from "GC" in cm [17:35:31] I assume that is a typo [17:35:33] CG [17:35:42] yeah [17:38:37] it seems the length of that vector also proportionally increases the heat [17:38:43] Interesting, I change the position to 0 0 0 and the heaters cannot keep up [17:38:50] It cools too fast [17:38:56] hmm [17:39:19] 0,0,0 would disable some of the calculations [17:39:34] I am going to make them all the same as the LR to experiment [17:40:20] LR heats the others do not with heaters [17:40:26] yeah, only 1 out of the 4 Q calculations will have anything with 0,00 [17:40:27] 0,0,0 [17:40:40] and that is the normal radiation heat [17:40:54] which has the same equation as the one in the radiator code [17:41:05] so again, it's probably the isolation factor [17:41:14] The one set in the code? [17:41:18] yes [17:41:25] the one that is called "isolation" [17:41:26] Make it smaller then [17:41:32] yes [17:41:36] what is it now? [17:41:40] 0.0001 [17:41:48] yeah, add a few 0s [17:42:37] Lets see what this does [17:43:04] Also I cannot seem to find the mass of the s band antenna [17:50:06] But the increased isolation seems to be helping [17:56:03] I think it is stable [18:22:10] One other thing I need to do is have the LR heater disabled when the LR is powered [18:34:41] Can I add antheater->SetPumpOff; to the system timestep? [18:51:43] the LEM system timestep or the LR one? [18:52:34] SystemsTimestep in the LR [18:52:47] void LEM_LR::SystemTimestep(double simdt) [18:52:48] { [18:52:48] if (IsPowered()) [18:52:49] { [18:52:50] lrheat->GenerateHeat(118); [18:52:50] antheater->SetPumpOff; [18:52:51] no, that should only have power and heats [18:52:52] } [18:52:53] } [18:53:13] Ok where should this go [18:53:20] also, what would switch it on again in your case? [18:53:26] LR timestep [18:55:07] I guess an else setpumpauto [18:55:07] is the heater actually switched off by some control logic, when the LR is powered? [18:55:10] Yes [18:55:24] yeah, that is system functionality, belongs in the timestep [18:55:34] Because the LR power is more than enough to keep it at operating temperature [18:55:39] right [18:55:51] yeah, some if-else somewhere up in that function [18:56:23] Ok [18:58:22] if (IsPowered()) [18:58:23] { [18:58:23] antheater->SetPumpOff(); [18:58:24] } [18:58:24] else [18:58:25] { [18:58:26] antheater->SetPumpAuto(); [18:58:27] } [18:59:13] sure [19:10:46] I am going to implement the config for quad heaters as well [19:16:43] You know the RCS code better than I though [19:17:04] I have boilers and radiators in the config ready for the RCS [19:19:04] ok [19:22:24] PR is up with the changes [19:25:35] I added 4 radiators for the quads and 2 boilers per quad to represent 1 and 2 [19:26:03] looks good [19:26:42] So sys A/B-1 is directly wired to the breakers and has an internal temperature switch to control the heaters [19:27:01] sys A/B-2 is wired to the breakers and switched via the panel switches [19:27:19] MAN is constant heater power, off is, well, off, and auto is the temperature switch [19:27:47] But I didnt want to touch the RCS code since you have been making so much good progress there [19:31:16] is there even special code necessary for this? [19:31:29] Or can it just go into the ThreePosSwitchToggled function [19:31:54] the four A/B-1 would just be in auto at all times [19:32:07] and A/B-2 is just on, off and auto [19:33:13] Yes that should be fine [19:33:21] The temperature control should be handled by the config [19:33:34] yeah [19:33:59] There is a redundant temperature switch set 7 degrees higher as well but I dont see a point of modeling that [19:34:00] with this simple solution the config needs to be in the same initial state as the switches [19:34:04] which is probably off [19:34:13] Sure [19:35:24] Actually do I want them set to zero in the config? I remember that we couldnt do that for say the secondary glycol pump and lcg pump [19:35:47] Because they were simply wired to breakers [19:35:50] yep [19:36:00] same goes for the A/B-1 heaters [19:36:03] so those should be on [19:36:14] And the switched ones off [19:36:21] initial switch position of the A/B-2 ones is indeed off [19:36:58] and the "pump state" only gets changed and checked whenever you change the switch position [19:37:13] Assuming the switch has power from the breaker [19:37:45] so if the config and initial switch position isn't identical, then they wouldn't have the same state at the beginning [19:38:19] yes, the boilers are also wired to the CBs [19:38:41] have to be, I mean [19:40:33] the switch itself is not wired [19:40:44] although we have switches that work like that [19:40:54] but those actually switch between different power sources [19:41:54] Ok I have the sys a/b 2 initialized to zero [19:42:31] However there is nothing controlling the isolation and such of these radiators yet like the other antennas we have done [19:42:37] I am curious how the CSM does it [19:47:36] hmm [19:50:06] there seems to be nothing that sets the isolation in code [19:50:15] so it would be the 1.0 by default [19:51:24] I'll investigate that tomorrow [19:52:18] Ok [19:54:24] Yeah seems a bit enigmatic how it is utilized [19:59:11] a huge wattage should be going into and out of the system with the isolation being 1.0 [19:59:30] size is the same as we are using in the LM usually [20:03:45] debugging is working as normal for me btw [20:03:54] not really sure what changed [20:03:59] I got a VS update yesterday [20:04:02] but it's working fine now every time [20:04:15] Well I hope the same holds for me haha [21:10:58] Finally have a Docked DPS video [21:12:23] :D [21:15:11] https://youtu.be/S7qu-GqQDJw [21:15:42] It says its still processing so quality is reduced [21:22:11] Not nearly as exciting as a lunar liftoff [21:22:30] Ironic the excitement is in the stability and lack of moving [21:23:26] hahaha [21:23:35] "look! nothing happened!!" [21:25:01] Haha which is way different than before [21:25:15] yeah [21:25:49] it's really funny, the confluence of everything that masked that before in the CSM [21:26:31] with the correct PMI's, the DAP rate previously configured for Colossus didn't work [21:26:51] but the faster rate, which we have since learned is what was actually loaded, caused program alarms back then, because of a bug in virtualagc [21:27:16] so it seemed like the previously configured rate must have been correct since it controlled well and had no alarms [21:27:50] we would have found out so much sooner if we had a colossus padload available [21:29:12] Yeah it was an interesting process [21:34:39] I think I might add a small split screen using the regular orbiter showing what used to happen [21:36:52] haha that's a good idea [21:50:26] If I can figure out how to make them play in the same frame [22:02:10] I will look into that later [22:04:01] yeah, I don't know much about video editing [22:06:20] I almost want to switch gears and look at the LM pressurization from the CM side and figure out why it, well, sucks haha [22:08:14] heh [23:36:56] I am having that same glitch Niklas had where the ECS data goes to NaN [23:38:12] oh nooo [23:41:42] Lets see if its an initialization issue [23:48:20] Nope still happens [00:00:42] No idea why [00:00:49] sets most of the CSM ECS to NaN [00:01:14] SUITCIRCUITRETURNVALVE 1000.000000 1 1 0 0 0.30000001 0.10000000 0.00100000 4.00000000 [00:01:15] CHM 0 -nan(ind) -nan(ind) -nan(ind) [00:01:16] CHM 1 -nan(ind) -nan(ind) -nan(ind) [00:01:17] CHM 2 -nan(ind) -nan(ind) -nan(ind) [00:01:17] CHM 3 -nan(ind) -nan(ind) -nan(ind) [00:01:18] CHM 4 -nan(ind) -nan(ind) -nan(ind) [00:01:19] CHM 5 -nan(ind) -nan(ind) -nan(ind) [00:01:21] [00:01:25] In the "current state" quicksave [00:04:11] that looks pretty angry [00:05:17] Yeah its in most of the ECS of the CSM like that [00:05:38] So its some sort of bug or glitch caused by the connection in ECS of the vehicles I believe [00:13:25] I know Niklas was having this issue when this was first implemented, maybe he has some insight [00:21:54] I remember him saying the reason was because of using old scenarios [01:00:42] This is a fresh Apollo 11 launch [01:01:23] Happens when pressurizing the LM under 10x time accel [01:01:38] But sometimes it takes 30 minutes sometimes it happens within a minute or two [01:03:17] But in other news, the LR RR and SBand antenna heaters all function [01:03:24] As does the temperature display for them [01:16:57] ah weird then [01:17:09] awesome stuff for the heaters! [01:17:11] Yeah I dont know haha [01:17:25] They may need some tweaking after they are tested during TLC [01:17:38] But they seem to raidiate heat when off and heat up when on etc [01:18:08] great [01:18:15] off to bed, cya! [01:26:53] Me too [16:10:00] o/ [17:22:37] morning! [21:16:01] quiet day today [21:16:05] how's it going Guenter? [21:16:14] Guenter! [19:41:28] Hey Mike [19:41:36] morning! [19:41:53] Spent the afternoon cleaning computers. [19:42:07] fun [19:42:31] Currently running tests on one of them because it had issues. Memtest came out fine, now doing a HD test. [19:43:04] I could make a jacket out of the dust that came out of them. [19:44:08] hehe [19:44:13] yeah I need to clean mine [19:45:04] Oh great [19:45:14] So I was having these fan issues [19:45:22] They made a lot of noise. [19:45:50] I wanted to play around with them for a bit so I unplugged the power to my storage so it wouldn't load the OS. [19:45:56] Guess what I forgot to plug back in. [19:46:25] hahaha [19:46:28] ouch [19:46:42] at least it's quiet now [19:47:39] They go quiet after a while. Bearings are going bad. [19:47:43] I should replace them. [19:49:43] There. Plugged back in. [19:51:50] Except maybe not. Forgot to plug in a usb cable. [19:59:11] All working again. :) [20:04:59] sweet [20:05:09] I'm getting pretty close to having yaAGC running again [20:05:31] Nice [20:06:15] and then we'll see if it comes close to passing the Borealis tests lol [20:12:16] hmm, we also aren't generating interrupts on T1-T6 from ADS [20:13:55] oh nevermind, that needs a WOVR control pulse [20:15:47] man, the forums have been down for a few days now [20:26:52] Yeah/ Annoying [20:26:59] s///. [20:27:04] s///./ [20:35:45] heh, yeah they put in a gate specifically to stop ADS from generating WOVR [20:57:27] Meeting ended by Thymo, total meeting length 1056265 seconds [20:57:27] .endlogging