[17:05:40] NASSP Logging has been started by thymo_ [17:05:48] That was off for some reason :p [18:20:51] hey [18:24:32] morning! [19:06:25] how's you comms link doing? [19:06:48] you mean my work on the HGA? [19:07:00] I mean your ISP :P [19:07:20] same thing [19:07:32] just was bad for a day [19:07:48] cool [19:27:41] UHCL has quite a few Apollo checklists [19:27:50] just not for those missions I currently want [19:28:12] haha [19:28:27] that is unfortunate [19:30:57] "REVISION A TO THE Apollo 10 FINAL FLIGHT PLAN" [19:31:04] this is something I can use [19:31:18] we only have the ""final"" flight plan from April 17th [19:31:25] the revision is from May 5th [19:32:44] with some luck for UHCL it really only is the revision and not a full version [19:34:36] I'm not even sure there would have been a full reissue of the final flight plan for this [19:34:48] probably just page changes to the flight copies and the flight controller copies [19:35:53] do you have any idea what changed? [19:36:50] lots of small things I would guess [19:37:03] here is the one for Apollo 11 [19:37:03] https://de.scribd.com/doc/46181272/Apollo-11-Final-Flight-Plan-Revision-A [19:38:48] ah, nice [19:38:54] yeah hopefully it is just the same as that [20:05:05] hmm, I think I have a thing to request from UHCL as well [20:18:58] which is? [20:20:37] the GSE Familiarization Manual from MIT [20:20:58] it's from 1963 but from what I can tell the AGC GSE was not so different between Block I and Block II [20:27:58] they also have a different type of manual for some AGC programs that we don't have yet that I'm really curious about [20:28:16] that sounds fun [20:28:52] GUIDANCE NAVIGATION AND CONTROL LUNAR MODULE FUNCTIONAL DESCRIPTION AND OPERATION USING FLIGHT PROGRAM LUMINARY ( REV 116 ( REVISION 116 )) [20:29:29] and it's 500-600 pages long, looks like [20:31:07] UHCL also has one for Comanche 67 and Sundisk 1 [20:31:30] if we are playing good cop, bad cop with the size of scanning requests, then this time I am the good cop [20:32:11] hahaha [20:32:17] yeah, you go first :P [20:40:08] done [20:41:03] easiest request since the Apollo 8 LVOT that turned out to be the 3 pages distribution list [20:41:15] not that I knew that when I made the request of course [20:47:23] hahaha [20:51:04] a bunch of these giant SCOT trajectory listings weren't really helpful immediately, the Mission Profile (Volume I) was better for a general overview. But since I made the long list of SCOT requests I have looked in all of them multiple times [20:51:08] so definitely worth it [20:52:02] nice [20:52:10] yeah I think I have only requested one really useless one [20:52:17] so useless I don't even remember if I mentioned it in here lol [20:53:12] must have been really useless then [20:53:55] remember I was thinking the Apollo 8 Guidance and Navigation Information may have been the equivalent of the Apollo 15 Delco manual for 8? [20:54:10] yeah, I think so [20:54:33] https://drive.google.com/open?id=1buPQ1zDO0iqxGeICVwZ5TvS9dp1q17-m [20:54:56] turns out it's mostly phone numbers for hotels and things [20:56:46] who was the audience for this? [20:57:28] some AC Electronics flyer [20:58:04] reporters maybe? I'm not really sure [20:58:16] definitely not us :P [20:58:20] yeah [21:08:22] night [15:20:55] hey @rcflyinghokie [15:21:01] Good morning [15:21:39] i have a question how did you know that your windows 7 ctd's were caused by dx9? [15:23:34] When I debugged after a CTD it was a dxd9 .dll file that always came up [15:43:41] and i also get MSVCR90.DLL which has something to do with a reddist package [15:45:54] you need to reinstall the vc package [15:46:09] which one? [15:46:10] https://www.microsoft.com/en-us/download/details.aspx?id=29 [15:46:23] i did not have that one [15:46:27] just 2017 [15:46:35] That could be your issue [15:46:42] hopefully it is [15:47:22] From what I can see that DLL is from the 2008 one [15:47:29] Then you should install the 2015 one as well [15:47:36] https://www.microsoft.com/en-us/download/details.aspx?id=48145 [15:47:57] i am guessing x86 [15:47:58] Not sure if you need the 08 one actually [15:48:05] Yeah NASSP runs 32 bit [15:48:27] Install those both and then reboot and check windows for updates [17:12:21] hey all [17:12:44] I took a couple days off from NASSP but I'm back again and still trying to figure out the P23 navigation [17:13:09] I put in the star codes specified in the flightplan but it will not maneuver the spacecraft to the correct attitude [17:13:14] it does maneuver the spacecraft [17:13:42] but it's not possible to see the correct star from that attitude even if I roll the spacecraft [17:15:23] P23 is challenging especially in NASSP [17:15:51] Which mission are you trying this? [17:20:38] morning! [17:21:52] Hey Mike [17:22:11] Apollo 11 rcflyinghokie [17:22:29] At what point in the mission? [17:22:53] The first P23? [17:35:01] yeah [17:36:01] So when you start the P23, you are entering: [17:36:20] 00002, 00000, 00110 [17:36:30] yeah [17:36:35] and then PRO [17:36:45] to 50 25 [17:36:47] and then PRO [17:37:10] then I set up the maneuver, SC CONT- CMC, CMC MODE- AUTO, BMAGS to RATE 2 [17:37:16] and then I hit PRO again and it maneuvers [17:37:28] That should maneuver you to have the star and earths horizon in the same frame in the SCT [17:37:46] yeah it didn't do that [17:37:56] Then your SV or REFSMMAT is bad [17:37:59] for star 02 I was able to manually roll the spacecraft to bring the star within the FOV of the SCT [17:38:06] and for star 44 I wasn't able to at all [17:38:12] Have a scn? [17:38:13] yeah I'm sure I screwed up the align somewhere [17:38:19] ? [17:38:51] a saved scenario file so I could take a look [17:47:50] https://drive.google.com/open?id=1_CK7-XIlsE8DddY6xnRtk8HEjQ0PRErc [17:51:52] Btw you still have your direct O2 open [17:52:03] That will waste a lot of O2 over your mission [17:52:44] having astronauts? [17:54:15] I dont know if that would be a "waste" per se [17:54:24] But leaving direct O2 open would [17:54:50] yeah [17:55:37] Oh I have merged Thymo's CWEA changes into my local [17:55:48] And I have begin piecing together the wiring and logic [17:55:52] begun* [17:56:12] great [17:56:22] oh whoops about the direct 02 [17:56:43] So the lights themselves are powered by the LMP LTG breaker [17:57:00] The logic by the CWEA breaker to turn them on or off per conditions [17:57:11] And the master alarm lights and sounds are all on the MA breaker [17:57:52] Looks like the component lights work the same, the logic for them is on the CWEA breaker but power is from the lighting [17:58:22] So I am working now to make them turn on for the lamp test but if the cwea breaker is open, they remain off (unless lamp testing of course) [18:05:53] Hey [18:06:20] Hey Alex [18:07:13] On the road still so might have connection issues [18:07:16] Uncooked, I updated your SV and REFSMMAT and the P23 is maneuvering me to the proper place [18:07:36] any luck with the MA? [18:07:39] Your REFSMMAT was off a few degrees [18:07:44] Very good luck in fact [18:07:58] Slowly wiring it in [18:08:04] awesome! [18:08:19] I had to change more wiring of the CWEA anyways because it depends on a few breakers [18:08:46] Can’t wait to scare all the neighbours with the tone [18:08:52] Oh its awful [18:09:20] Thankfully you can pull the MA breaker and still see the CW lights :) [18:09:51] wrong REFSMMAT? maybe used the wrong option for the uplink? [18:10:29] It was close [18:10:53] which type? [18:11:01] He should still be on launch [18:11:09] I just did an option 3 [18:11:19] alignment was good? [18:11:22] So that means there was a bad alignment to it [18:11:26] ok [18:11:43] The REFSMMAT itself was fine, bad alignment is what i should have said [18:12:17] But I did that and a SV update and the P23 maneuver put me exactly where it ought to [18:12:49] hm [18:12:58] I'll try that then, thanks [18:14:12] Just do a P52 option 3 and get a good alignment [18:14:31] I think the SV was fine, I just did it as a precaution [18:15:08] oh ok [18:15:28] And after the auto maneuver, at the F59, change optics to CMC and hit enter again to bypass calibration, then it will drive the optics to the star [18:16:03] and then get your brain fried by the split line-of-sight [18:16:16] yeah I stopped before superimposing ;) [18:27:11] indy91, I still am getting an intermittent CTD, it is seemingly random but it is the same error every time it does happen, I managed to get a debug screenshot of it today [18:27:30] https://www.dropbox.com/s/2fpvnxjcn5vqhmy/Screenshot%202018-03-18%2012.26.31.png?dl=0 [18:28:14] It looks like the same .dll that caused astronauthen96 to CTD [18:28:54] I couldnt pinpoint it until recently as I couldnt debug on a crash without attaching a process [18:29:39] joystick init code, interesting [18:30:20] Yeah [18:31:13] With all the reloading of a save I have done lately I have noticed that being the random CTD every time it does happen [18:31:22] But only happens every so often [18:43:34] do you have a joystick connected when it happens? [18:44:55] wait a minute [18:45:01] it says line 1070 for the crash [18:45:05] in GetScenarioState [18:45:12] not where the joystick code is [18:45:52] I mean I have my joystick connected yes but it is disabled in the launchpad [18:46:07] while (oapiReadScenario_nextline(scn, line)) { [18:46:12] this is line 1070 in your case [18:49:05] hmm [18:49:17] but that is only called once at scenario start [18:49:24] not during the session [18:52:33] do you remember which line actually caused the CTD? [18:52:55] No idea [18:53:11] I cant willingly reproduce it [18:53:21] It happens every once in a while [18:54:51] well, was it actually in that joystick code or in the function below? [18:55:38] the screenshot shows the joystick code, but in the small window at the lower right it says line 1070 [18:55:44] so that is confusing me a bit [18:56:11] Yeah thats what opened up when i went to the debugger [18:56:21] I just took the screenshot and closed it out haha [18:56:35] I was focused on a CWEA issue and kind of shrugged this off [18:56:51] If I get it again (I probably will at some point) I will get more info [18:57:47] great [18:58:02] one of these annoying unreliable issues, haha [18:58:53] Exactly [18:59:22] So I am trying to figure out which component lights get their logic through the CWEA [18:59:26] I don't think this code has been touched by me ever [18:59:35] it's been like this since we started on Github [18:59:43] at least the joystick init code [19:00:31] Might be a conflict with launchpad settings [19:00:58] Like my cfg file isnt in sync or something [19:01:10] That happened when i copied it directly over to my laptop [19:01:18] Though no ctd, just that debug line showed up [19:02:54] Do all the component lights get their logic from the CWEA? [19:04:16] probably [19:04:33] wait, which lights are we talking about [19:04:33] I am looking at the RR no track light, I don't think that does [19:04:37] oh [19:04:43] The component lights [19:04:44] those lights [19:04:53] Some get logic from the CWEA [19:04:54] do any of them get their logic from the CWEA? :D [19:04:56] which ones? [19:05:07] Well I am basing this on the procedure [19:05:20] AOH vol 2 CWEA checkout [19:05:27] pdf 57 [19:05:54] With the CWEA breaker out, the comp light test switch turns on all the comp lights as expected [19:06:12] And they go back off when the switch is put back on off [19:06:14] however [19:06:42] When the CWEA breaker is closed, the CW lights come back on and looks like the glycol h2osep and suitfan lights are allowed to come back on [19:06:53] So I think those 3 are controlled at least in part by the CWEA [19:09:06] Does that make sense? [19:09:28] Otherwise they wouldnt be off when the CWEA breaker is open, and back on when it is closed [19:11:43] where does it say that the lights are off with the CWEA breaker open? [19:12:45] Step 6 [19:12:49] 7 [19:12:58] Says all lights in step 6 are off [19:13:18] And the next step when the breaker is closed, those 3 are allowed to be back on [19:13:44] actually not glycol comp light [19:13:51] just h2o sep and suit fan comp lights [19:14:26] it says H2O SEP light is on in both step 6 and 7 [19:15:04] It is off in step 7 [19:15:13] "All lts in step 6 - off" [19:15:14] yeah, that was step 8 [19:15:27] Step 8 closes the CWEA breaker [19:15:33] And those are back on [19:15:35] oh, I see [19:15:45] step 7 has the test off and the lights off [19:15:49] Yes [19:15:58] step 8 still has the test off [19:16:05] Yes [19:16:11] But the CWEA breaker is back in [19:16:48] yes [19:18:04] So they come back on because that breaker is close so I am inferring that they get logic from the CWEA [19:18:19] Otherwise they would come back on in step 7 [19:18:39] master alarm CB is also open at that point [19:18:46] Yeah [19:19:01] That is because with the CWEA power off, the MA would be on and unable to be silenced [19:21:55] do you guys know if there is a way to calcuate an sps evasive maneuver pad with the rtcc? [19:22:35] You should be able to just use the actual evasive pad from the mission [19:22:43] okay [19:22:47] Then calculate your MCC's with the RTCC after that [19:23:09] I assume this is the evasive from the SIVB? [19:23:24] yes [19:23:37] Yeah you can use the actual from the transcript if you wish [19:23:44] Or the one printed in the flight plan [19:26:07] yep, they executed it exactly as planned [19:26:27] and do you know what an access violation is i looked it up but i dont understand it [19:27:47] something tried to access a part of the memory that wassn't allow to be accessed by it [19:28:11] rcflyinghokie, Systems Handbook lighting page [19:28:26] I9 [19:28:29] at the very top [19:29:11] hmm [19:29:20] I think i read the wiring wrong [19:31:24] i think that is what is causing it [19:32:41] Yeah thats how I know they got power from the LTG breaker [19:33:37] It looks like the h2o sep and co2 lights are controlled by cwea logic if you look at the caution wiring [19:33:49] but I cannot find anything for the suit fan other than the dP breaker [19:34:16] I'll be back in a few and look some more [19:39:11] indy91, any good rendez-vous progress? [19:39:25] didn't really have time [19:39:45] the SCOT at least mentions which processor in the RTCC was used [19:40:03] two-impulse processor. Which basically is what the Lambert page is doing [19:40:20] so using a specific offset [19:40:28] right [19:40:45] which is what we have been doing for the phasing maneuver anyway [19:41:21] the only tricky thing is the timing of the arrival at the target point [19:41:23] there is a phasing maneuver on 10? [19:41:43] that's what the maneuver after DOI is called [19:42:05] Ah right [19:42:07] the one making your HA very high, haha [19:42:16] yeah [19:42:17] I have figured out the TIG of that one at least [19:42:28] it's similar to a PDI+12(?) abort as later missins had planned it [19:42:42] but Apollo 10 had some tasks scheduled over the landing site, LR test etc. [19:42:47] so the TIG is a bit later [19:42:54] 10 minutes after overflying the landing site [19:43:04] I have been calculating those pads on the recent missions I flown [19:43:12] which is basically PDI + 15° (PDI to landing site) + 10 minutes :D [19:44:10] I just use on offset of the CDH position relative to the CSM for the PDI+12 [19:44:49] On Apollo 12 I did that [19:45:23] ah right, that is a shorter profile [19:45:32] so CDH is the target point [19:45:36] offset target point [19:45:47] Yes target point [19:45:57] CSI nominally 0 [19:46:02] in the case of Apollo 10 it would be the nominal point of the insertion from the landing site [19:46:16] DH and phasing angle [19:46:55] the two-impulse processor and related processors were part of a tool that was used for mission planning as well as real-time operations [19:47:13] so I bet they could input the whole desired rendezvous profile and get the timing for TPI right that way [19:47:39] important is that TPI is at orbital midnight [19:47:49] that's a very important constraint [19:49:06] the time of arrival at the insertion point is what will make that happen [19:49:38] I've found some additional information on the timing, but I am not sure it's a constraint per se [19:50:23] 4.5 (alternatively 5) minutes prior to entering darkness [19:50:37] for the insertion maneuver [19:52:12] I guess a lot of variables to consider [19:52:20] Gotta go later! [20:07:16] and do you know that a memory leak is [20:08:12] basically, unused variables in memory that are not made available again for use [20:08:47] so an application with a bad memory leak would need more and more RAM while running [20:08:58] i have 4g [20:09:29] small memory leaks usually don't matter much and I don't think NASSP has a big issue with it [20:10:20] and what about the access violation that is what it says [20:10:52] tricky to find the exact cause [20:10:56] it says running as administrator might fix it [20:11:04] but i dont think it will [20:11:06] unlikely in this case [20:11:21] a bad pointer can easily cause an access violation [20:11:40] if it points to a random piece of memory that has nothing to with the application [20:13:09] i am looking at the event viewer and i just found D3D9Client.dll [20:13:10] if it is our joystick code, as the debugging rcflyinghokie did might point to, then it also could be some driver issue [20:13:23] I cannot seem to find a good definitive attachment of CWEA and the comp lights [20:13:35] and yes, the DX9 Client could also be the cause [20:13:45] d3d9client is what always caused failure on my windows 7 laptop [20:13:49] yeah [20:13:53] right [20:14:03] No problems on any windows 10 machine [20:14:29] rcflyinghokie, I wonder if the CWEA uses the lights as some sort of alternative master alarm if the MA CB is open? [20:14:31] no idea... [20:15:25] I mean it looks like they are grounded through either the lamp test or the logic source of the lamp itself [20:15:43] yeah [20:15:52] I just cannot figure out that part of the procedure w [20:16:01] where the lights go out and back on with the CWEA breaker in [20:16:24] "CB INST: CWEA - close resets flip-flops, causing annunciator lights to go on" [20:16:47] Right [20:16:57] Those arent the component lights though [20:17:38] Unless the procedure is wrong? [20:18:02] Or the wiring is different for LM11 [20:19:38] The co2 and h2o sep component lights are inclused in the c/w schematics [20:20:32] but not the suit fan light [20:20:45] yeah, possibly a LM-11 change [20:20:57] the suit fan light should be only controlled by the dP sensor [20:21:14] at least from what LM8 says [20:21:34] the co2 light and the h2o sep are tied into cw logic I believe [20:22:05] pdf 114 G3 [20:22:12] systems handbook [20:30:28] Looks like the suit fan is as well based on reading about the ecs caution light in the AOH [20:30:46] But again I cannot find support in the handbook [20:32:22] found the light in the elementary schematics [20:34:36] Page? [20:34:41] 572 [20:35:04] in the document ending with 889, NTRS ID [20:35:24] 20A20-K10 is the relay for the normal logic [20:35:53] I dont think I have those docs [20:36:39] https://web.archive.org/web/20100517193006/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19710070889_1971070889.pdf [20:37:56] Thanks [20:38:06] I don't see a routing of the wiring that would have that light on [20:38:14] except of the relay for the normal operation is closed [20:38:22] or if the test switch is in COMP [20:38:53] Me either [20:39:33] That relay is from the dP switch? [20:40:51] I was just looking at H2O Sep [20:41:01] there it is from the RPM check [20:41:09] but I think I figured out the solution [20:41:22] the procedure in the AOH doesn't exist in a vacuum [20:41:39] in the Activation Checklist, the CWEA checkout is done fairly early on [20:41:45] Right [20:41:47] after it is done, a few lights are still on [20:41:55] including H2O Sep [20:42:04] Yeah [20:42:08] and suit fan [20:42:53] so I am pretty sure the lights listed in step 8 are just the lights that would be on anyway at that time during LM activation [20:42:56] so with their normal logic [20:43:00] not anything from the CWEA [20:43:08] But what about step 7 [20:43:17] All lts off [20:43:33] oh damn [20:43:52] Thats what led me down this rabbit hole [20:45:50] From what I am reading though in the AOH, the comparator that controls the ECS light for CO2 also turns on the component light [20:45:54] Same goes for H2O sep [20:46:38] But I dont see that verbiage for suit fan, just "suit fan comp light also goes on at this time" when the CWEA turns on the ECS light for that failure [20:48:41] do you think it would run better on windows 8.1 or 10 i will get one of them [20:56:15] Its hard to say [20:56:24] Could also be hardware [20:56:47] well i was planning on getting it anyway for a long time [20:57:42] If you are planning on using it on just one machine get an OEM version [20:57:48] much cheaper [21:02:10] indy91 I can see all those relays in the schematics you showed me in the ECS elec schematics maybe that will help [21:02:15] I will take a look after dinner [21:10:41] Also if you feel bold: [21:10:42] https://github.com/dseagrav/NASSP/compare/Orbiter2016...rcflyinghokie:Orbiter2016 [21:10:50] Take a look at the changes so far? [21:10:53] Back in a little [21:11:30] the last thing I can think of is that some ECS sensors don't get power because the CWEA switches something off? [21:11:39] not that I found anything for that yet [21:12:15] Could be [21:12:54] looks all really good [21:12:56] except for [21:12:57] But the AOH seemed to imply that the CO2 light and the H2O lights were controlled by CWEA comparator? [21:13:11] some pointers not being nulled in the CWEA constructor [21:13:26] Ah yeah [21:13:37] I added pointers today and forgot that [21:13:51] I don't think that the CWEA has those comparators [21:14:09] They are elsewhere? [21:14:48] hmm [21:14:55] The flow chart in the CWEA schematics is where I was looking [21:15:01] And those have the bulbs in there [21:15:04] no, the schematics indeed say the comparator is in the CWEA [21:15:09] For H2O and CO2 at least [21:15:23] I couldn't find the same for suit fan [21:15:27] That looks like just the dP switch [21:16:38] H2O Sep comparator and relay for the light are both in the CWEA [21:17:10] Same with co2 pp? [21:20:33] yes [21:21:27] Ok thats how I have it currently set up [21:21:45] I want to get the MA working with the annunciator light before making a PR [21:21:58] I saved that for last because of how annoying it is [21:22:25] Also, I couldn't figure out if the OFF position of the lamp tone test turns off the master alarm [21:23:02] In other words, if it is turned on from the alarm test, does the OFF position reset it or does pushing it [21:23:30] Additionally, will pushing it turn it off when IN alarm test, or will it be set to on again immediately after [21:23:54] Ok NOW it's time to eat [21:25:01] you can't just put off NASSP work for food! [21:25:09] sleep on the other hand is a valid reason [21:25:12] good night! [00:12:48] .tell indy91, well when its corned beef and cabbage, stout beer, and whiskey, I say it warrants an NASSP break :P [12:31:53] hey [12:32:31] hey Alex [12:33:18] I requested the Revision A to the Apollo 10 Final Flight Plan, because I thought we didn't have those changes [12:33:52] I just got the revision document. Turns out we already had the pages from it. It's all the pages that have a "Rev A" at the bottom [12:34:06] ah right [12:34:14] but at least I now know that we really have the final version [13:23:35] damn wifi [13:23:52] will I make it to 90 today? :D [13:25:32] not for now [14:27:12] Good morning [14:30:40] hey [14:31:07] trying your latest changes in your repo, looks awesome [14:31:51] Getting there [14:32:12] I ran into a snag last night trying to figure out how to make the MA trigger when a cw light comes on [14:32:29] having fun pulling the various SCEA cbs and watching what displays are affected [14:32:33] hey [14:33:02] I guess checking how the CM does it would be a 1st step [14:33:12] Yeah I was looking there [14:33:32] It didnt quite click to me witht he way they did the light status [14:37:52] CautionWarningSystem::SetLight [14:38:09] Yeah [14:38:29] I dont quite understand how to use it in the LM code [14:41:33] probably requires a bunch of changes [14:41:38] hi [14:41:47] Yeah [14:42:02] my video card driver was outdated [14:42:50] did updating that help with the CTDs? [14:43:08] not sure yet but frame rates have improved a bit [14:43:21] rcflyinghokie, and there also is the special case of the descent quantity light, which doesn't cause a master alarm [14:44:26] It looks like the csm just has a number of lights lit and a total and if the number of lights lit increases it turns the alarm on or something like that [14:45:21] not quite [14:45:33] if the state of a light changes from off to on, then a MA is generated [14:46:27] something very similar should be possible to be implemented [14:47:09] and also when i open the direct o2 valve a get a master alarm is that normal it doesnt do that in orbiter 2010 [14:47:35] the direct o2 valve had a wrong size in NASSP 7.0 still [14:48:04] it's now much bigger, which together with some missing plumbing in our systems simulation, causes the O2 flow high [14:48:09] o2 flight high alarm [14:48:12] Yep [14:48:16] flow* [14:49:07] rcflyinghokie, do you want me to implement some of the MA triggering logic? I can PR it into your Orbiter2016 branch [14:49:20] That would be great [14:49:41] I am struggling to convert the csm case to use in the lm [14:50:23] yeah, I think I know what to do with that [14:53:40] well i am going to try one of my 11 scenarios now to see if it was the video driver [14:58:09] i will be back in a bit [14:58:56] rcflyinghokie, I am really confused by your if/else logic [14:59:04] where [14:59:35] if (lem->EPSInverterSwitch.GetState() != THREEPOSSWITCH_DOWN) { [15:00:05] that if goes down all the way [15:00:27] Forgot a } [15:00:47] right now it would disable a whole lot of lights [15:01:05] Yeah I fixed that this morning but it hasnt been pushed [15:01:31] would be good if I could work from your latest state [15:02:19] One sec [15:03:01] I forgot I fixed that when i added power draws [15:05:15] Should be up [15:07:13] I'll teach you another VS trick [15:07:30] see the "}" below the large lights off section? [15:07:54] delete it and type it in again [15:08:16] Ok [15:08:19] and VS will automatically format the if-else stuff properly [15:08:50] Interesting [15:09:00] Mine didnt change though [15:09:25] did you copy&paste? [15:09:36] that might not work [15:09:56] do the same with the } just above else [15:11:01] No i deleted it and retyped it [15:11:14] That worked [15:25:03] this will take a while, I'm changing all the direct LightStates changes to the function [15:26:13] No problem [15:26:34] Now why does the button make a click sound when clicked and again when released? [15:29:19] are the CES AC and DC C&W lights now wired? [15:32:03] I haven't messed with them yet [15:32:42] Looks like they should be off though if the ATCA breaker is in or the gyro test switch is centered? [15:32:57] I dont know the actual logic I haven't done those yet] [15:34:58] ah yes, the ACTA breaker turns them off [15:35:05] ATCA* [15:36:09] But in reality there is a bunch of logic for those lights involving the RGA [15:36:54] And the gyro test switch resets the light [15:38:25] SetLight[3][5] = 2; [15:38:33] is the state 2 doing anything interesting? [15:39:32] or why are you using it? [15:39:45] or was it always 2? [15:39:50] It was 2 before I started [15:40:24] ok [15:40:38] That was on the landing radar light right? [15:40:40] ah yes [15:40:47] there is a special hack for it in the display code [15:41:00] 2 makes the light label blank [15:41:05] Ah makes sense [15:42:01] When the MA lights I will go through and add/change more cw logic as well to include all implemented systems [15:42:30] When the MA lights are working* [15:51:35] did you add the Rendezvous Radar Caution? [15:52:55] no, it's been there [15:53:02] just seemed out of order [15:54:10] Yeah it did look like it was just stuck in there [15:54:31] And I am pretty sure the logic is incomplete [15:55:02] Oh wait [15:55:10] // 6DS28 RENDEZVOUS RADAR DATA FAILURE CAUTION [15:55:19] Thats further up is that a duplicate? [15:55:33] Yep [15:55:44] yes [16:03:54] looks like the logic for that one at the bottom is more correct than the other [16:06:18] in thw CWEA light test code [16:06:20] so i got a ctd and as soon as i hit the lem sivb sep i get a message saying dx8 joystick not found [16:06:23] if (IsLTGPowered()) { [16:06:30] that is suuuuper random [16:06:53] what is that doing there? [16:08:38] astronauthen96__, that message is not uncommon, it can happen. Shouldn't cause any issue [16:08:56] The light bulbs need to be powered to work [16:09:14] That lighting breaker is what actually powers the light itself [16:09:25] So when that breaker is out the cw panel is not able to light [16:09:46] I need to verify it might be both of the lighting breakers in redundancy [16:10:57] using the if there within the switch looks super confusing [16:12:55] do you think there might be something wrong with my installation? Faulting application path: C:\Users\MatthewHenry\Desktop\BETA\modules\server\orbiter.exe [16:14:25] does it also say a faulting module or something like that? a dll file? [16:14:53] its both ntdll and d3d9clientdll [16:15:00] hmm, I see [16:15:11] which D3D9 Client version did you install? [16:15:11] exception code 0xc0000005 [16:15:23] the latest one i think [16:15:34] are you using Orbiter Beta or 2016? [16:15:50] beta [16:16:39] latest D3D9 Client version for that is r914 [16:16:43] for Orbiter Beta r71 [16:17:25] that is the one i have [16:19:57] rcflyinghokie, the IsLTGPowered() would be redundant there anyway, the same check is done in the Redraw function [16:21:36] Hm I thought I had an issue with only having it in redraw I could be wrong [16:21:56] I'll check [16:22:03] astronauthen96__, there is a D3D9 Client log file [16:22:19] under Modules\D3D9Client [16:22:25] astronauthen96__ I had the same error on my windows 7 machine [16:22:29] could never figure out the cause [16:25:38] https://usercontent.irccloud-cdn.com/file/VnVosELR/D3D9ClientLog.html [16:26:35] no errors, I think it only saves the data from the last Orbiter session [16:26:59] so if the CTD didn't happen during the last time you had the simulation running, then the relevant errors wouldn't be in the log [16:31:55] Sounds familiar [16:39:40] pulling the CWEA breaker causes a MA? [16:41:28] Yes [16:41:35] And one that cannot be extinguished [16:41:41] Without pulling the MA breaker [16:41:44] seems like it, yes :D [16:41:47] And the CW PWR light stays on [16:41:50] that sound... [16:41:53] Yep [16:42:31] And that is probably why in the AOH procedure the MA breaker is pulled before the CWEA breaker is opened :P [16:43:30] Any power failure to the CWEA causes that to happen [16:43:49] Including of course the breaker itself being pulled [16:44:11] pulling the ANNUN lighting breaker doesn't have the right effect yet [16:44:11] Back in a few [16:44:36] Which effect? [16:44:44] lights going out [16:44:51] even the CW power one [16:44:51] It did before [16:45:17] That breaker killed all cw lights [16:46:04] yeah, I think a change I did with the ifs causes this [16:46:48] Unfortunately the way the LM CWEA was set up here seems way more complicated than the CSM c/w [16:46:51] brb [16:48:14] ah, there is one of these CBs on the CDR side and one on the LMP side [16:49:58] morning! [16:51:41] I scanned that SLCC Programmer's Reference Manual last night [16:51:48] may be some interesting information in it [16:51:49] https://drive.google.com/open?id=1txlIIeI32pqwTXVdDWjNHGqmQhs3Q75_ [16:52:13] also here is the S-II LIEF Training packet that was in the binder with it: https://drive.google.com/open?id=1_IVrf7j5gmZNS1q0yISaZvHosfrJs5GJ [16:54:13] at the very least I know the difference between MDI/MDO's and LDI/LDO's now :P [17:10:59] great, thanks, I'll look through them [17:11:22] I already got the revision to the Apollo 10 flight plan, but we already had those changes [17:11:29] it's 87 replacement pages [17:11:59] and the version of the flight plan we have already has a "Rev A" at the bottom of it [17:12:06] on every replaced page [17:12:39] when comparing the pages directly with the revision it becomes obvious, but I probably should have discovered the "Rev A" on those pages before :D [17:12:47] at least I now know that we have the final, final version [17:22:49] hahaha [17:22:49] nice [17:25:53] for Apollo 11 it's not so obvious [17:26:36] indy91, I know for a fact that the CDR side powers the comp lights, but can you check if it's just the LMP side or both that power the CWEA in redundancy? [17:26:41] I have different versions of the flight plan for 11, and some have the revision A changes and some don't and it doesn't always say revision on the page [17:26:56] both CBs go into the lighting control assembly [17:27:07] and it seems they are totally redundant [17:27:19] so they have the identical function [17:27:21] Yeah, looked like through it though the comp lights only were connected to the CDR breaker [17:27:47] and there was a tie I believe going to the cw lights but I need to look again when I get a second to pull the docs up [17:29:17] I don't think any light in the LM is affected if either one of the two CBs is open [17:30:52] well [17:31:11] not after LM ejection at least [17:34:27] anyway, I can push my first version soon [17:34:55] and I'll probably implement the LCA next [17:34:59] seems to make sense now [17:52:31] LCA is? [17:52:48] Lighting Control Assembly [17:52:53] ah right [17:58:11] I see what you mean about that [17:58:20] they have a tie in the LCA [18:04:29] I'll have a PR up shortly [18:04:38] it seems to do the master alarms correctly [18:04:47] Awesome [18:07:27] ah damn [18:07:39] it tries to PR my newest RTCC and MCC changes [18:08:13] I'll push those to the main repo first, then you can merge those changes, I'll merge them as well, and I'll PR again :D [18:09:22] Haha ok [18:10:03] ok, I pushed it [18:10:24] merged [18:10:31] and you need to push the merge commit as well [18:10:54] just a normal push to your repo [18:10:59] that just contains the merge [18:11:00] Yep all done [18:11:08] thanks, this makes things easier for me [18:11:22] Always better that way [18:12:22] let's see if I thought this out correctly [18:12:52] looks like it [18:13:55] PR is up [18:14:52] PR merged [18:15:01] Now I fetch from my origin? [18:15:10] yep [18:15:15] done [18:15:21] and then merge it [18:15:53] I'm intrigued how it works for you [18:16:01] I didn't mess with any CB logic [18:16:18] just added a SetLight function which calls SetMasterAlarm(true), if appropiate [18:16:19] Ok I think I am all up to date [18:16:33] and I also added the option for a light that does not trigger the alarm [18:16:40] and I added that for the descent prop quantity [18:17:06] now, with this implementation you still get a master alarm every time you reload a scenario [18:17:18] because the light states aren't saved [18:18:05] Not a problem for now [18:18:31] I will leave the power as is until we have some sort of LCA [18:19:25] Oh did you find out why the MA button makes 2 click sounds when pressed [18:19:39] The CSM MA only clicks on a press I believe [18:19:48] pressing the MA seems to give a double click sound, don't know if thats intended [18:21:01] Yeah thats what I was talking about [18:21:20] It wasn't my intention but that was Thymo's code I couldnt figure out what caused the 2 clicks [18:23:02] Also the master alarm light lights up even if the breaker is pulled [18:24:21] Might need an ispowered in the setmasteralarm() [18:24:49] This perhaps? [18:24:50] void LEM_CWEA::SetMasterAlarm(bool alarm) { [18:24:51] if (IsMAPowered()) [18:24:51] MasterAlarm = alarm; [18:24:52] } [18:26:38] Or maybe in rendermasteralarm [18:26:57] No, set should work [18:27:01] that code is messy anyway [18:27:22] there should be a CheckMasterAlarmMouseClick function like in the CSM [18:27:30] there is [18:28:34] then there is some redundant code [18:29:34] it seems to light even when all power is removed [18:30:57] Yeah I just fixed that I am pretty sure, still wondering about the click thing [18:31:50] ah, I have it [18:32:01] ButtonClick() is in the clbkPanelMouseEvent function [18:32:19] a mouse event is when you click but also when you release [18:32:25] so it gets called in either case [18:35:34] I'll do a PR [18:36:32] Ok [18:36:35] out for a few hours, later! [18:36:38] cya [18:36:38] Later [18:36:40] haha [18:36:42] always the same [18:37:32] yep, it's fixed [18:40:44] PR is up [18:41:24] Ah that makes sense [18:46:14] Looks like it works properly [18:46:31] Now to get back into the logic [18:51:07] Which other CW lights do we have systems ready for? [18:52:06] ASC PROP LOW [18:52:16] RCS TCA WARNING [18:52:32] although I already noticed an implementation error in my TCA code [18:52:44] RCS A REGULATOR FAILURE [18:52:47] and RCS B as well [18:53:58] TCA Warning looks scary, but almost all of it is already implemented [18:54:08] CWEA just needs to connect 8 signals for the light [18:56:21] what I did wrong is the TCA flag reset [18:56:30] it's done with the CWEA reset bus [18:58:16] hmm [18:58:18] or did I? :D [18:59:48] before the RCS TCA CBs are closed, you can get red quad flags [18:59:52] activation checklist says [19:00:02] "possible tb-Red, Cycle CWEA If Necessary)" [19:00:15] that's sound like cycling the CWEA breaker would reset the flags [19:01:42] Yeah [19:01:50] They are also shown in the c/w schematics [19:02:28] yes [19:02:33] there they look quite scary [19:02:38] to implement [19:04:13] so i have decided to buy windows 10, not just for nassp but hopefully it will work [19:07:03] I hope it does as well [19:07:19] Seems to be a good OS though [19:09:51] hmm, I don't think I did it totally wrong anymore [19:10:10] is the CWEA reset bus only powered when the CWEA breaker is open? [19:10:46] I believe so [19:11:16] that would give power to the reset of the flags then [19:11:31] how IS the CWEA reset bus powered? [19:11:36] I am looking for it [19:12:07] I see it hanging off of the power supply [19:13:45] But not sure where it gets power [19:14:45] maybe some capacitors that get power when the CWEA breaker is closed and release their power when it is cycled? [19:15:05] I suppose it's possible [19:15:07] that would make sense with the way the breaker is used [19:15:16] Here is another bus for c/w inhibit [19:15:29] Part of the inverter logic [19:16:58] I dont see a reference to the bus anywhere else yet though [19:18:31] So that seems like a logical conclusion [19:18:55] They keep charged from the cwea breaker and when that potential is removed they discharge [19:19:41] Maybe its in the AOH [19:20:19] the CWEA schematic also shows a bunch of flip-flops that we have partially implemented [19:20:28] like WaterWarningDisabled [19:20:31] Yeah [19:20:46] are those actually in the CWEA or in the subsystem they are for? [19:21:38] CWEA [19:22:23] I'll try finding them in the elementary schematics [19:22:41] You can see the flip flop in the CWEA schematics [19:23:05] Also our C/W lights dont quite match those of LM 8 [19:23:21] The radar caution light is one slot above where it is in LM-8 [19:28:59] so those flip flops will also need to be saved in the CWEA class [19:29:43] Yes [19:30:01] There are quite a bit as you said [19:32:43] I can confirm that the flip flops are in the CWEA [19:33:40] so what are you implementing now? ascent prop and RCS regulators are the easy ones [19:34:01] I was just checking to make sure the rest of the lights are where they belong [19:34:07] But yeah I was starting with those two [19:34:19] Looks like the bmp has to be changed to fix the light [19:34:22] uhh [19:34:36] ASCENT PROPELLANT LOW QUANTITY CAUTION is already implemented [19:34:43] I saw that [19:34:55] the prop seemed like a duplicate [19:35:24] there are ASC PRESS and ASC QTY on the panel [19:35:28] ASC QTY is implemented [19:35:38] What is ASC PROP then I wonder [19:35:44] Maybe for a later LM [19:35:45] so "ASC PROP LOW" is wrong, it's ASC press low [19:35:54] it's at the right position [19:36:07] it's just labeled wrong there [19:36:15] not PROP LOW, PRESS LOW [19:37:15] Ah yeah that makes sense [19:37:20] there also is ASC HI REG CAUTION, but earlier LMs didn't have that [19:37:39] LM-8 did [19:37:51] Any idea when it was first added? [19:38:17] LM-6 didn't have it [19:40:19] We can use the hack to cover that for now, same as the landing radar light [19:41:17] we could just not implement it for now [19:41:28] we don't have the label for it anyway, would require a bitmap change [19:41:51] hi reg caution? [19:41:54] yes [19:41:55] its on our cw panel [19:41:57] oh [19:42:00] haha [19:42:02] and has logic [19:42:26] it does? [19:42:43] 6DS21 HIGH HELIUM REGULATOR OUTLET PRESSURE CAUTION [19:42:58] that's the DPS [19:43:18] No DPS is further up [19:43:25] / 6DS3 HI/LO HELIUM REG OUTLET PRESS [19:44:05] oh right, got confused with the 2 arrays [19:44:17] then I looked at the wrong panel in LM-6 [19:44:32] Would be simpler I think with a comment naming the light itself on each of these haha [19:44:41] And not the AOH definition [19:44:46] Or both rather [19:45:09] so the only thing wrong is the PROP in the "ASC PROP LOW", which is actually PRESS [19:45:30] and it needs to be implemented [19:45:36] And the RR light in the wrong spot [19:46:21] APS helium pressure readings are going through the SCEA; but only for telemetry [19:46:23] not for the CWEA [19:46:48] for telemetry and the panel display [19:47:08] So CWEA gets it directly from the sensor? [19:48:02] And are we hjust using the propellant tank pressures or do we have helium tanks simulated [19:48:03] yes [19:48:16] helium tanks are kind of simulated [19:49:26] lem->GetAPSPropellant()->GetAscentHelium1PressPSI() [19:50:30] and the LEMDigitalHeliumPressureMeter class in lemswitches will need the SCERA measurement [19:50:41] I guess you have some experience implementing that by now [19:50:57] Yeah I do haha [19:52:01] DPS helium pressures for the display are not going through the SCERA [19:52:09] just APS [19:53:26] the helium pressure has a constant value right now [19:53:33] so it will never trigger the alarm [19:53:41] just if the signal sensor CB is open maybe [19:55:26] Is that pressure reading function dependent on the sig sensor cb? [19:56:29] yes [19:56:38] returns 0 if that CB has no power [19:56:45] Ok [19:57:01] Any idea what the +5V going into this logic is? [19:57:14] handbook 111 top left corner [19:58:11] no idea [19:58:29] Also the comment doesnt seem to follow the logic here [19:58:36] // Blanket pressure in fuel or oxi lines at the bi-propellant valves of the ascent stage below 120 psia [19:58:50] hmm [19:59:13] Maybe a condition on a later LM? [19:59:18] yeah, possible [20:00:31] Ok I am on this pressure meter function [20:00:49] That needs to use the scea [20:01:03] for all of those pressures? [20:02:22] only the APS ones [20:02:28] DPS ones can stay as they are [20:03:41] Ok [20:10:25] Looks like you already have those two in the scea [20:10:34] Less work for me haha [20:14:43] Hmm it doesnt seem to like the scera in this function [20:15:47] friend class maybe? [20:16:30] yep [20:16:36] it needed a friend [20:20:45] Where are the RCS regulator pressures [20:22:48] already in the SCEA [20:23:02] SC1, SA6 [20:23:06] Ah yeah just found it [20:23:20] those are simulated [20:23:27] at least opening and closing valves does something [20:23:35] including the exploding valves [20:23:43] explosive* [20:24:06] so those lights will turn off at the right point in the LM activation [20:32:05] for the SOV's is 0V open or closed [20:32:40] Looks like 5V is closed? [20:48:05] Ok those are done [20:48:49] hey again [20:49:19] Welcome back [20:49:58] do you know what data execution prevention is becase i disabled it for orbiter and i just made it to 5 hours with no ctd almost all of them were between lem ejection and the evasive maneuver [20:51:43] it has something to do with memory [20:56:06] Usually it protects from programs running from protected areas of system memory [20:56:42] Never thought to disable it for orbiter though [20:58:06] and it can cause the c0000005 error i was having [21:04:33] night! [21:46:02] hey [21:46:12] afternoon! [21:55:02] Hey there [21:55:09] More C/W lights out [21:56:05] I think the ascent pressure light was on throughout the flight wasn't it? Until APS pressurization? [22:04:10] awesome [22:04:14] yes, I think so [22:04:39] Ok [22:05:12] Some lights still need more logic, but after these AGS light fixes all the lights but ASC PRESS should be out if running nominally [22:05:30] I think I still need to implement the real logic of the TCA and CES lights [22:05:45] And of course battery lights will require an ECA with the sensors built in [22:27:47] Ok you should have all lights out but ASC PRESS now [22:27:52] In my repo [22:32:18] i'll test that now [22:35:40] There is an interesting +5V going into that CWEA logic for the ASC PRESS [22:35:53] I am wondering if cycling the CWEA breaker would reset that [22:36:11] But I also recall reading somewhere that the light was on until staging [22:36:15] I dont know haha [22:50:51] Any issues? [22:51:21] I know I found one potential issue with my change to the ammeter/voltmeter is I get a CTD sometimes when first loading and quickly switching to that panel [22:51:41] Its a dxd9 issue but it has a specific cause, the drawing of that meter [22:53:22] But I didnt find any CWEA problems, other than we need a lot of flip flops in there soon [22:54:37] when I pull the MA cb, the tone goes out but the MA light stays on, is that correct behavior? [22:55:40] That should have been fixed [22:55:52] also, if the MA is already on, and you cut the power, the MA light is still on [22:55:58] Also was fixed [22:56:03] cut all power to the S/C* [22:56:04] hmm [22:56:16] I thought I had updated to the latest state [22:56:22] It all works fine in mine [22:56:27] Its not on the main repo yet [22:56:37] Its in my local [22:56:48] yeah I am testing your branch [22:57:11] Orbiter2016? [22:57:18] yep [22:57:25] and I am up to date with it [22:57:52] and I see only the ASC warning light on so I know its up to date [22:57:55] I just tried it I dont have those problems anymore [22:59:14] the tone goes out, but the MA light stays on [22:59:16] I have the light on if you cut power though [22:59:29] I thought you meant if you pull the MA breaker [22:59:40] if I pull the MA breaker too [23:00:08] (if the MA was already on before pulling the breaker) [23:01:41] Hmm good find [23:02:04] The breaker/power prevents it from turning on but doesnt turn it off in the event of a power loss [23:02:16] I think I know how to fix it [23:04:55] Try that [23:08:53] Better? [23:09:29] hmm still on when I cut power/pull MA breaker [23:10:17] wait, I did something and now it cuts the light out [23:10:47] one thing is this is a scenario from a few weeks ago [23:12:27] No the light stayed on hmmm [23:16:13] Lets see what this does... [23:24:33] Ok I think I have it [23:25:13] Try this [23:25:25] Had to put a power check in the timestep [23:34:38] Any issues? [23:37:06] yep works! [23:38:42] Great [23:38:55] First fix wasnt in the timestep so it wouldnt keep checking the power [23:39:04] Enjoy the sound ;) [23:40:12] thanks for getting this to work! was looking forward to it [23:43:14] Had a lot of help [23:43:36] Also a plus, Niklas is going to start an LCA soon [23:43:48] That will tie in to a lot of systems making life easier [23:56:26] I am trying to find a good pic of the flown CW panel of pre LM-8 LM's [23:56:44] The panel in the LM 8 handbook has the RR caution light one cell below where we have it [23:57:05] interesting [00:03:23] night! [00:03:37] NIght [09:48:57] . [10:38:06] hey [10:38:42] i think that data execution prevention think fixed the ctd's [10:39:07] thing [10:44:29] @indy91 do you think i should try apollo 9 before doing a lunar mission, i am not too familiar with the lem [11:00:04] hmm [11:01:02] Apollo 9 is a fairly challenging mission in some way. Apollo 10 might be better. [11:01:30] Apollo 10 also has the MCC implemented until LM undocking [11:01:41] very recently implemented [11:01:55] so you could test it for me as well as flying the mission [11:02:38] and by way the lem pressurization works better now [11:03:07] yeah, that has been steadily improved over the last few weeks [11:03:49] and that lem/csm dap is fairly slow is that normal? [11:06:46] slow as in attitude rate? [11:07:13] at 4:50 it asks for a maneuver and it took about 10 minutes [11:08:02] the normal configuration of the DAP for the CSM alone is 0.5°/s, for the CSM/LM docked it is 0.2°/s [11:08:07] so yeah, it's normal [11:08:10] okay [11:08:31] slow attitude rates are more fuel economical [11:08:36] i think i will try apollo 10 for now [11:09:09] but you have to plan around those slow attitude rates, especially for the later missions the flight plan is very clever and detailed in how it handles larger attitude maneuvers when docked [11:09:41] you can always change the DAP configuration [11:09:46] yeah i did the lem pressurization during the maneuver [11:09:46] in V48, the first line [11:09:55] the last digit [11:10:07] 11102 is the normal CSM config, 2 meaning 0.5°/s [11:10:17] 21101 is the normal CSM/LM configu, 1 meaning 0.2°/s [11:10:25] yeah for the p23 [11:10:37] so if you want higher attitude rates, just change it to 21102 [11:10:42] i think the dap calls for 11102 and it is much faster [11:11:25] the first digit is the vessel configuration, 1 for CSM, 2 for CSM/LM docked. Using 1 when docked to the LM would be a fairly bad idea. [11:12:35] have all the checklists been updated?, maybe the p23 is from apollo 8 hence the 11102 [11:13:21] could be, yes [11:13:36] maybe just copy&pasted [11:14:01] yep [11:14:14] the Apollo 11 checklist wants to use 11102 by default [11:14:20] that has to be updated [11:16:09] 21101 is the DAP config used for P23 with the LM docked [11:17:40] and for the evasive maneuver should the p/y trim be zero? [11:18:47] not for a docked evasive maneuver, no [11:19:30] if you calculate a Maneuver PAD or if the MCC shows you one, then you will know what trim angles to use [11:20:32] someone posted a before cis lunar navigation scenario for apollo 11 and i checked the maneuver pad in the rtcc and it was the evasive maneuver do you know how he calculated that? [11:21:11] probably by manually inputting the TIG and DV on the Maneuver PAD page [11:21:37] the evasive maneuver has a fixed TIG and DV, not necessary to use any other calculation page in the RTCC MFD for this [11:21:45] so you need to manually input the numbers [11:22:04] on the Maneuver PAD page there should be TIG and DV buttons [11:22:11] on the lower left I think [11:22:14] okay [11:22:36] and there just input the same TIG and DV used during the actual flight [11:22:46] Apollo 10 or 11? [11:22:50] 11 [11:23:16] i have the numbers memorized [11:23:19] good [11:23:44] well i am going to continue with apollo 11 until the first rest period to see if i get a ctd and then i will start apollo 10 [11:24:46] sure [11:25:12] i will let you know how your mcc updates are [11:25:47] i will talk to you in a bit [12:13:40] hey [12:13:57] hey Alex [12:14:26] pushed a CWEA saving/loading update, now there shouldn't be a master alarm every time you load a scenario [12:14:42] great [12:16:17] and also a update for the APS propellant before staging [12:16:25] uses default helium pressures now [12:16:37] with that, I think, the left half of the CWEA lights is solved [12:16:43] at least none of them is one for me [12:20:01] yep all out in my test too [12:20:49] doesnt the checklist say that the AC PRESS light should be on until ascent activation? [12:21:04] I don't think so [12:22:01] may have read it wrong [12:22:02] the light is off in the Apollo 12 activation checklist after the activation power up CB procedure [12:22:14] right [12:22:35] it would make sense to that the light would be off [12:23:48] with those CB closings the signal sensor CB is closed [12:24:06] with nominal pressure, that is what should make the light be off [12:25:09] on the Apollo 10 phasing Maneuver PAD is a weird entry, "Phasing Delta". 5 seconds from the transcript. [12:25:14] any idea what that could mean? [12:25:46] minus 5 seconds [12:27:20] looking at the transcript now [12:32:18] nothing on it in the flight plan pad descriptions [12:32:35] yeah, it's certainly written down under remarks [12:32:48] I wonder if it is DOI to Phasing maneuver time [12:32:56] well, the difference to the flight plan for that [12:33:14] because, the might have the event timer counting up from DOI [12:33:17] they* [12:33:26] and their procedures might be relative to that [12:33:34] right [12:38:57] I'm not even sure where those procedures would be in the flown checklists [12:39:16] maybe in the Rendezvous Checklist already? [12:41:43] LM timeline book? [12:41:44] so i got a ctd again, before i tried it 5 times and this time when i use the rtcc it happens [12:45:25] astonauthen96__ have you considered upgrading to win10? [12:45:39] yeah even before nassp [12:45:57] you are on win 7 now, correct? [12:46:03] yes [12:46:18] 10 didn't have a Timeline Book, I think [12:46:39] RTCC MFD caused the CTD? [12:47:23] i think so because i had the evasive maneuver pad memorized so i did tli right through to 6 hours about 5 times with no problems but when i use the rtcc it crashes [12:48:23] I am quite sure that your CTDs are related to the fact your running windows 7, and unfortunately we are all running windows 10 so its hard to fix bugs for older OS's when we don't have any developers testing on it [12:50:25] astronauthen96__, did it crash when you pressed CLC or something like that on the RTCC MFD? [12:51:13] when i switched views and this was before lem ejection this time and the rtcc was open [12:51:54] i press clc then a few seconds later i switched to the left panel and it crashed [12:52:19] ah, so one of these panel change CTDs [12:52:27] yes [12:52:40] when debugging those it usually points to an issue with MFDs [12:52:47] or rather, how they are displayed on the panel [12:53:08] its in the 2d cockpit of course [12:53:58] yeah [12:54:06] so the issue is not just in the LM I guess [12:54:52] I'll look through our MFD displaying code [12:54:57] maybe it's outdated in some way [12:55:13] AlexB_88, UHCL actually has some of John Youngs Apollo 10 documents [12:55:23] not in the normal search options though [12:55:41] not part of the "JSC History Collection" [12:55:49] but "JSC Artifact Collection" instead [12:55:57] https://uhcl-ir.tdl.org/uhcl-ir/bitstream/handle/10657.1/377/2016-0005.pdf?sequence=1 [12:57:21] and i have noticed some things missing in the checklists [12:58:01] best mention them to rcflyinghokie when he joins [12:58:06] he is the keeper of the checklists [12:58:07] yeah [12:58:57] i am hoping apollo 10 will work because obviously i wont need the rtcc [12:59:14] I don't think the RTCC MFD is the problem [12:59:44] maybe some display incompatibility in older Windows versions of MFDs in general [12:59:47] but that is just a theory [13:00:50] but then again apollo 7 and 8 work just fine [13:02:02] yeah [13:04:28] i am looking at the event viewer and i see 0xc0000005 which means an access violation [13:07:24] astronauthen96__, have you had these issues in Orbiter 2016 as well? [13:07:27] or only in the Beta [13:07:32] both [13:07:49] ok [13:08:24] there is only one difference I noticed in how CSM and LM handle MFDs [13:08:51] the CSM does some check I don't understand yet [13:11:11] what do yo mean a check? [13:11:37] oapiGetMFDMode(MFD_LEFT) != MFD_NONE [13:11:55] in Orbiter you can usually define 2 MFD display areas for a vessel [13:12:00] but you can also define custom ones [13:12:05] the CSM supports up to 4 [13:12:22] LM only 2, so maybe that check is just something for those custom ones [13:17:39] one thing I have planned for the 8.0 Beta phase is to work on panel improvements and optimizations [13:18:01] we can switch to Beta once the MCC is fully implemented, I think [13:20:57] yeah [13:21:19] now that the LM systems are almost finished [13:21:37] we'll be in Beta for quite a while still I imagine [13:21:50] but I think a 8.0 release this year is realistic [13:22:02] yeah, I guess getting the most people to use NASSP during beta will be good [13:22:09] to find the most bugs [13:22:28] and also when i debugged in visual studio it said something about head memory or heap corruption or something like that [13:26:37] thats a weird one [13:28:06] I have a CTD to report to Ryan [13:28:25] D3D9: ERROR: UnDeleted Surface(s) Detected [13:28:30] we have lots of those in the log [13:28:39] but I don't see which ones would be undeleted [13:29:48] I noticed that the other day [13:30:18] we don't have them in scenarios with only the CSM [13:31:46] ah, I think I know what is missing for that [13:31:56] ReleaseSurfaces() has to be called in the LEM destructor [13:32:29] seems like a pretty bad error [13:32:46] oh [13:33:03] how long has it been like thatÉ [13:33:17] É=? [13:33:38] forever I would guess [13:33:48] damn french keyboard [13:34:00] I still get 4 undeleted surfaces if I fix that [13:35:21] about my CTD: happens after 1st creating LM (LM ejection) I switch to the LM, then go to the right CB panel and I get the CTD [13:35:40] https://www.dropbox.com/s/oxu1skldokxa2wd/Screenshot%202018-03-20%2009.32.13.png?dl=0 [13:35:41] same [13:35:51] but in the csm [13:36:28] and i get the same 0xc0000005 error [13:36:32] astronauthen96__ I don't think this is related to your CTD, this is specifically something with the LEMDCVoltMeter [13:36:48] That was recently worked on [13:37:35] Did you also get the LEMDCVoltMeter when you ran the VS debug? [13:38:01] no this was a while ago i have no idea how to debug like you guys do [13:38:31] well you have Visual Studio, right? [13:38:48] no i recently reinstalled windows 7 [13:39:29] ah ok [13:40:02] is debugging easy? [13:41:35] well genarally no, but sometimes the CTD has a debug button, when you press it, it will open a VS window and show where in the code the error is [13:41:49] generally* [13:41:50] that is what i did [13:42:22] yep and then you can take a screenshot of it and post it on here [13:43:02] it usually says ntdll but i dont know what part of nassp is causing it [13:43:52] you must have VS installed to see the debug display inside VS [13:44:55] i am doing that now [13:46:01] you mean visual studio community? [13:46:06] yes [13:46:19] which components do i install [13:48:58] select "desktop development with C++" [13:49:28] and also select the checkbox in Windows 8.1 SDK and UCRT SDK [13:49:55] discovered another bad thing [13:50:05] Thats on Windows 10 at least [13:50:05] we were creating two surfaces with the same ID [13:50:14] srf[SRF_BORDER_34x29] = oapiCreateSurface (LOADBMP (IDB_BORDER_34x29)); [13:50:16] is done twice [13:50:49] bad [13:50:53] let's see if that fixes the remaining DX9 client errors [13:51:46] 2 of them [13:51:48] 2 remaining [13:51:59] lol [13:52:14] ah [13:52:16] same was done with [13:52:17] SRF_LEM_COAS1 [13:52:18] and [13:52:19] SRF_LEM_COAS2 [13:53:11] could be your fault, Alex :D [13:53:17] installing [13:53:50] hmm [13:53:56] no, that already was the case in 7.0 [13:54:23] which LM COAS? upper or fwd? [13:54:32] just the loading of the bitmap in general [13:54:40] and also already the case when we moved to Github [13:54:42] ah [13:54:43] so a very old issue [13:55:22] so does that take care of the last 2 errors? [14:04:33] that it does [14:05:37] update pushed [14:05:59] it seems to me that when you quit Orbiter it now is doing that faster [14:07:39] there is a very small, but nonzero chance that this fixes your CTDs, astronauthen96__ [14:08:19] somehow i doubt it [14:08:23] me too :D [14:08:38] but it's a bug that only was in the LM [14:08:41] just like the CTDs [14:08:47] i seem to be the only one getting the ntdll error [14:09:04] i am at 14 percent [14:09:58] i hope i am able to debug it [14:12:17] that would be great [14:12:24] I am sure it is fixable, even on Windows 7 [14:14:03] i wonder if any of the apollo astronauts who are still alive have heard of nassp [14:15:51] I only know that Charlie Duke has tried some simulator that used the Virtual AGC [14:16:29] if they did they would most likely give it some praise like i do [14:16:48] no, not Charlie. Al Worden [14:17:42] he was on apollo 15 right cmp i believe [14:17:47] I think Charlie Duke tried that Apollo 11 VR sim [14:18:49] Fabrizio, one of the guys in the Virtual AGC mailing list, built a partial CSM simulator with Virtual AGC [14:19:00] I helped him troubleshooting some Artemis072 issues [14:19:09] the CMC version that Al Worden would have used [14:19:11] in his garage? [14:19:13] I have a picture [14:19:24] i think i have heard of him [14:21:22] Fabrizio is part of some group [14:21:36] never mind its not him [14:21:46] they had the sim at some expo where Al Worden also was [14:21:49] https://gm1.ggpht.com/DxWObZ1h-kHuEfPVVwmafyWHfXc2WEk5DjQzwN4FDSGUQXH9yYbY0IRgPBcWu5lXq7GtI6hJIBw1uEKTTIVa_Zuv7cIH_RC9JO2u2Zoe14dtYTuEudlqkcE7HBZiaO7ifa0DPcswUvFDJvM9AUHIvuKPF4Ge4_fXxQT1SJz3jiLfg06bwPoeuhcyAk9-_-C3u73BxYbJd2SfVR8d9WntV_cVvv1uKshNwo7Mg1LoJZCuYRwwEhw2puS75usudFW7LIlotH2GHo48TeEjTlX34T3Whlw70muxOolFu-S0XtscC3GxmmFEXN9lwW4JCUaMcfsBHUpddqQgZX2l6POMAEZNAVoY_23bXnybkobDnod6CUrrI1GUHzSiH2lLT305x7IEgEicj3uz4Pu6rzA9jl8YQThqe0mclXKZ8RGN [14:21:50] gJk4-t2MpwxNIrWv3kPs7up6Nz2sRaYURnEcnlxWATpQIvqTVwSpgbE9zqs3geKoXyVM_NY8S_B-3rBWzWjXgzV_HRsBTG2kk3ov-T70FlUrevCJsiPqvDoI4NYJyDndWEAn2t0d9SCsrpdjgaM2rD-3-J8BesfYxN92hmjo_tBF3DfVsBw-snC0QB_vzHvjv9Ix0APRMGvtk1utU_55Rf0ZFjS_erhdl-OXSJ_kPZ_O-70fm_GR59-3FZJu8l36fSYcygq6nNQU2HSu28TEKA=s0-l75-ft-l75-ft [14:21:53] hmm [14:22:04] I guess that link didn't work [14:24:21] there is this guy on facebook who pretty much built a full command module with all switches and windows and i believe he has orbiter running and i thought of nassp when i saw it [14:25:12] here is the picture Fabrizio sent me [14:25:13] https://i.imgur.com/seoslcD.jpg [14:25:26] that's Al Worden using the Virtual AGC [14:29:51] nice stuff [14:30:17] is that little screen with the docking target a picture, or Orbiter? [14:31:43] https://www.dropbox.com/s/pdgxum7pphgerat/26730899_10210143674860696_6893531572069931644_n.jpg?dl=0 [14:32:01] this is in his garage [14:32:36] AlexB_88, not Orbiter, I think he wrote a TD&E simulator or so [14:32:38] nice [14:32:49] just something simple that works with the CMC attitude control [14:33:14] that looks impressive. That is not what Fabrizio built of course, some other person [14:34:22] and he has videos and i think he is running orbiter 2016 out the windows it was in lunar orbit and the textures looked like 2016 [14:34:41] do you have a link? [14:34:47] https://www.facebook.com/henry.rosales.982?ref=br_rs [14:34:54] i dont know if you have facebook [14:35:01] his videos are on his page [14:35:13] indy91, is the PGNS -> AGS downlink something still planned for 8.0? [14:35:25] yeah, I think so [14:36:06] https://www.facebook.com/henry.rosales.982/videos/10210162845739956/ [14:37:12] might be Orbiter 2016 [14:38:45] i am at 95 percent do you think either one of you could help me debug this if you have time? [14:41:12] sure. when you get the CTD, just press "debug" and then it will give you a window that asks if you want to use VS to debug and select that [14:41:29] okay [14:41:37] then take a screenshot of the open VS window and post it here [14:43:38] okay [14:46:05] Good morning [14:47:33] hey [14:47:53] Any other unusual MA issues? [14:49:03] nope looks good [14:49:21] I am getting a CTD in the LM after LM ejection [14:49:35] happens after 1st creating LM (LM ejection) I switch to the LM, then go to the right CB panel and I get the CTD [14:49:48] Yeah thats probably the one I mentioned last night [14:49:54] https://www.dropbox.com/s/oxu1skldokxa2wd/Screenshot%202018-03-20%2009.32.13.png?dl=0 [14:49:58] Its something to do with drawing the ammeter and voltmeter [14:49:59] if it was my system or windows 7 would it show it in the code? [14:50:14] Yeah Alex thats exactly the same one I get [14:50:31] I can reproduce it if I load a new LM, and before clicking anything immediately switch to the right cb panel [14:50:39] yes same here [14:50:47] It's not liking that draw code in the class [14:51:06] astronauthen96__ you would need to debug it but yes you can in windows 7 [14:51:24] i just have to restart my computer first [14:51:36] You know how to use VS and the JIT debugger? [14:51:36] hey Ryan [14:51:39] i will be back [14:51:45] I added CWEA saving/loading [14:51:46] no they are gonna show me [14:52:05] Awesome, did Alex tell you about the CTD caused by the lm ammeter/voltmeter? [14:52:15] yes [14:52:43] I don't think what hes getting is related, but a debug might show [14:52:59] I don't think "FrameSurface" is properly initialized [14:55:45] I am getting the exact CTD [14:56:06] https://www.dropbox.com/s/aj6gl4oo5q3tkkh/Screenshot%202018-03-19%2018.17.32.png?dl=0 [14:56:09] From last night [14:59:49] I think I know how to fix it [15:00:13] Orbited is running now I have to do tli and transportation and docking and i am on my tablet [15:02:47] the DC BUS light comes on only when the DV BUS voltage falls below a certain value, correct? [15:03:16] the cw light or the comp light [15:04:06] cw is a bus lower than 26.5v [15:04:20] the comp light is a ground fault which we do not simulate [15:06:39] the cw light [15:07:39] There is some weird behavior in my Apollo 12 scenario. After I stage the descent stage my BUS voltage is low, just at the t=26.5 threshold [15:08:17] *just at the 26.5 threshold [15:09:47] That could be something to do with power loading which we might not have right [15:09:54] and the DC BUS cw is still out, but every time my RCS fires, there is a load that seems to kick the voltage down 0.5 volts, and beyond the trigger point for the DC BUS cw [15:10:16] Yeah that was what I got usually towards the end of a rendezvous [15:10:28] what seems weird to me is the 0.5 V spike very time the RCS fires [15:10:32] What is your cb configuration for the cross tie breakers [15:10:44] We were thinking the RCS is double dipping power whenever it fires [15:11:01] BUS - OPEN [15:11:08] BAL LOADS - closed [15:11:38] yeah, but the double dipping is user error, not a bad systems simulation. Just don't use hardover mode at the same time as normal control through PGNS or AGS [15:12:07] most of our DC equipment has the same threshold voltage to stop working [15:12:33] so if the voltage has dropped below that because of low battery life, then a lot of systems will be off for one timestep [15:12:46] then the power load is much lower during one timestep and all is normal again [15:12:49] repeat cycle [15:13:24] our battery code does the following [15:13:26] "Simple appoximation for voltage: 90% voltage at 20% capacity" [15:13:32] AlexB_88 is that on both panels? [15:14:12] 11 liftoff cb config is CDR panel both closed, lmp panel both open [15:14:43] I pushed an update that probably will fix the CTD [15:14:48] Actually indy91 the dc bus light is higher than the normal dc thresholds [15:14:58] the defined min voltage is 20 [15:14:59] the Volts and Amps meter CTD [15:15:15] Awesome [15:15:25] the dc bus comes on at >26.5 [15:16:01] ah right, 20.0 would be really low [15:16:36] there also is "Voltage drop because of load" simulated [15:16:45] But I think you dont get that problem with he cross tie breaker closed [15:17:03] Or not until later in rendezvous using hardover [15:17:32] rcflyinghokie, yes [15:17:56] Sorry I'm just kind of excited [15:19:13] Alex try closing them on the CDR panel and not using hardover [15:20:10] yep still happens with that [15:20:40] Right after staging? [15:20:51] yes [15:21:02] Weird [15:21:06] I staged from a pre-PDI scenario [15:21:11] Let me try on one of mine [15:21:18] this is an Apollo 12 from a few weeks ago [15:21:44] maybe the batteries were already drained a bit, because I know we had some EPS issues that drained the batteries a bit before [15:21:48] The ascent batteries should be full [15:22:00] They should only briefly been put online [15:22:05] hmm I guess they are not full [15:22:37] Can you pull the watt seconds number from the scn file? [15:23:07] Full is 31968000 [15:23:13] 5 and 6 ASC_BATTERY_A 30670044.0127 [15:23:14] ASC_BATTERY_B 30520169.1196 [15:23:54] Interesting [15:24:02] They have used something like 400 watt hours [15:24:37] Now that shouldnt be depleted by any means but still interesting [15:30:00] indy91, I think the RR caution light needs different logic from the no track light [15:30:28] From what i was reading I think I was seeing that it comes on if a lock is lost, not just if it doesnt have a lock [15:33:45] yeah [15:34:14] also goes through the SCEA [15:34:23] Yeah [15:34:49] is ED RELAYS light tied in? [15:34:56] and RCS [15:35:43] I think relays are in [15:35:47] RCS TCA is not yet [15:36:01] I have the same low voltage issue with the ascent batteries [15:36:17] is it due to high load? [15:36:26] or battery having been drained [15:36:34] High load [15:36:36] ah [15:36:40] all the heaters are running [15:36:49] https://www.dropbox.com/s/vixhzdia8qdpgao/Untitled123.png?dl=0 [15:36:50] since this scenario has low temps on all those systems [15:37:01] Normally they would all be up to temp [15:37:46] Let me let all the heaters heat things up on the des bats and try again [15:37:48] ah, makes sense [15:37:53] so a old scenario issue mostly [15:38:12] does that tell you anything [15:39:21] not much unfortunately. But it confirms that the CTD is caused in the LM [15:42:26] rcflyinghokie, also, when power is removed from the temp/mon rotary, all needles are at 0, except the four quads, they go to 50 [15:43:00] That was from the scaling [15:43:11] I dont know if thats the actual behavior though [15:43:18] ah ok [15:43:24] 50 is zero on that scale [15:43:45] Might need to make it return another number though [15:44:19] Once the quad heaters are done the ascent voltage is 28V [15:51:02] Hmm doesnt seem to like having the xtie breakers open on the LMP panel [15:51:10] with both ties closed things seem happy [15:52:27] Wonder is something is still consuming too much power [15:53:53] something on the cdr bus [15:54:36] Unless I have all 4 ties closed the cdr bus has low voltage [15:55:00] The quad heaters arent the issue there [15:55:19] I have 30V on the LMP bus and 24 on the CDR [15:55:28] 24.5 or so [15:56:33] how many Amps on the relevant batteries? [15:57:00] indy91, your change fixed the CTD on my end [15:57:07] great [15:57:52] 21-22 on bat 5 [15:58:00] 40 on bat 6 [15:58:31] 40, ouch [15:58:36] how many watt seconds left? [15:58:37] Using liftoff configuration cb's [15:58:46] let me look [15:59:29] Still have juice since they only went online recently [15:59:30] ASC_BATTERY_A 30988040.3275 [15:59:31] ASC_BATTERY_B 30726152.8944 [15:59:57] The heaters are responsible for the early drain [16:00:10] But they arent on when I am getting those amperages [16:01:11] I can confirm the voltage with my calculation [16:01:30] 34V is the default voltage, no load, 100% power [16:01:51] voltage due to only having about 96% juice left is 33.8V [16:02:06] and 40A is making all the difference [16:02:17] that is determined with a internal_resistance factor [16:02:57] and we use the same factor for all LM batteries and the 3 main CSM batteries [16:03:02] so maybe the factor is wrong [16:04:16] Could be [16:04:33] need to research that [16:07:19] 296 AH battery, 50 amps at 28VDC for 5.92 hours [16:07:38] So it should be able to provide that current without voltage dropping that low [16:08:27] In the CWEA code comments it says // Disabled when RR mode switch is not set to AUTO TRACK. [16:08:51] but I find the caution light is on when its not set to AUTO-TRACK [16:09:07] and goes out when I set it to auto-track [16:09:16] seems opposite from what the comment says [16:09:22] comment might be wrong [16:09:29] let me check [16:09:53] oh and do we need a landing radar caution light? [16:10:13] it uses a sort of reverse logic there [16:10:35] Should be disabled when in auto track [16:10:46] and we do have a LR light which will be used on later LM's [16:11:13] it should be disabled when not in auto track [16:11:22] later LM's meaning post-Apollo 11? [16:11:28] LM 10 and later [16:11:36] so 15 and later [16:11:52] it's a little bit weird [16:11:54] there is a flip flo [16:11:56] p [16:12:08] and the auto track switch setting goes to reset of the flip flop [16:12:10] yeah that logic is confusing haha [16:12:18] but also to the AND gate [16:12:36] just a second back to the batteries [16:12:43] sure [16:12:43] let's say the 34V default voltage is accurate [16:12:57] and now I assume 50A leads to 28V for a full battery [16:13:08] that would give the resistance factor 0.12 [16:13:32] what is the current resistance factor [16:13:44] 0.234 [16:13:54] twice what you calculate [16:14:00] with the new calculation you would get 29V at 40A [16:14:09] and 96% power left [16:14:22] so should I change it to 0.12? Probably makes more sense [16:14:27] I think so [16:14:30] it was just copy & pasted from the CSM is my guess [16:14:41] Need to verify the descent batteries use the same factor [16:14:48] but that math works out for the ascent bats [16:15:24] descent batteries [16:15:38] 25 amps at 28vdc for 16 hours [16:15:41] for the DES batteries it says 40A for 28V minimum [16:15:54] yep [16:15:56] yeah, but 25A is the usual load in that case [16:16:16] is 50 amps a usual load for the ascent batteries? [16:16:22] 0.15 for the descent batteries then [16:16:45] I think that means 28V is guaranteed for the load 50A, which is the max you would expect [16:16:53] that makes sense 25 amps *4 and 50amps *2 [16:17:16] ok, agreed on 0.12 and 0.15? [16:17:29] Yes [16:17:56] And then I want to look further at this RR caution logic [16:18:02] sure [16:18:09] we will need a flip flop first [16:18:29] A lot of things will need those haha [16:18:35] But I will start with RR [16:19:03] internal resistance is not saved in scenarios [16:19:14] so changing the config will fix old scenarios [16:19:21] Oh nice [16:19:46] well, time to try apollo 10 then after that windows 10 hopefully no more ctd's [16:20:02] I still wonder about that 34V though [16:20:23] pushed [16:20:42] we have no number for 100% power left and no load, I think [16:21:15] LM Data Book probably would have good numbers [16:21:35] I think the CSM Data Book is fairly detailed about the batteries [16:22:25] when RCS quantity falls to 0, RCS PRESS remains at about 1800 PSI [16:23:14] I used a quadratic fit for that [16:23:18] I have a redlines LM Data book [16:23:24] are there others? [16:23:44] 1816.76 PSI for 0 propellant, needs to be changed for very low RCS quantities I guess [16:24:07] Redlines is Part 2 [16:24:19] I dont have part one then haha [16:24:24] Part I is "Constraints and Performance" [16:24:33] we have that for the CSM, but not the LM [16:24:44] it's one of the documents high on the priority list [16:25:10] Ah [16:25:56] "batteries must read 36.98VDC prior to installation [16:26:00] For the descent batteries [16:26:26] Same for ascent batteries [16:26:32] oh, interesting [16:26:47] "open circuit voltage must remain constant until load is applied" [16:27:00] So that seems like a good open circuit number [16:27:10] Thats from the redline book [16:28:28] haha, with that the old resistance would be fairly good [16:28:42] Maybe thats what t was calculated with [16:28:53] for the CSM batteries we are using 37.2V open circuit voltage [16:29:33] So should we change the resistance and make the batteries open circuit at 36.98? [16:29:37] I wonder if the 34V was used because the load was pretty small [16:29:51] for testing or so [16:31:31] Also the 30 volts comment is incorrect in the config [16:31:51] max voltage under load is 32.5 [16:32:00] is it? AOH also says 30V nominal voltage [16:32:31] nominal vs max [16:32:39] the comment says max [16:33:44] ah, right [16:34:57] So should we revert resistance and change voltage? [16:35:09] hmm, let's do some more research first [16:35:16] @indy91 if you have time can you check how many maneuver pads i would need for apollo 8, i think you said 32 for apollo 7 [16:35:26] it was 32 for Apollo 8 [16:35:33] okay [16:35:33] not as many for Apollo 7 [16:36:14] i think i will stick with 7 and 8 till i get windows 10 [16:36:16] 8 SPS burns, at least 3 RCS maneuvers, one not executed maneuver [16:37:15] I'm counting 14 Maneuver PADs for Apollo 7 [16:37:19] but the form is different [16:37:44] 35.5VDC open circuit critical low voltage after <20AH load has been applied and removed [16:37:52] we have a "Apollo 7 Update Forms.doc" file [16:38:09] That tells me that 34 is still low [16:38:13] yeah [16:39:30] 36.98V sounds still like a minimum in the Data Book [16:39:40] it also sas 37.1 there for nominal operation [16:39:51] Yeah [16:39:55] so I could just use the same voltage as the CSM batteries, 37.2 [16:40:07] 36.98 is a minimum for installation [16:40:13] I dont see why not [16:40:38] with that you would get 27.84V for 40A [16:40:46] 25.5V for 50A [16:40:51] with the old resistance that is [16:41:44] should I use 30V or 28V as the reference for the high load state? [16:42:01] 28 [16:42:44] 0.184 for ascent batteries, 0.23 for descent batteries [16:43:08] that leads to 28V with 100% power left and 40A or 50A respectively [16:43:31] That looks right [16:43:33] so if I read correctly, ASC PRESS caution light is only active before staging, if the ascent pressure is below 2773 [16:43:51] yeah, just as an alert for a leak or so [16:43:57] right [16:44:02] Yeah the logic on that is weird, there are 2 5V leads going into it [16:44:11] and after staging, no matter what the pressure is, the light wont come on [16:45:09] any idea if cabin lights will be implemented ever? [16:45:20] when we have a 3D panel [16:46:06] So that battery config looks right [16:46:09] and co2 filter changes? [16:46:41] They will be implemented at some point, yes [16:46:57] so shouldnt asc press be always on before staging? [16:48:19] pushed again [16:48:25] well i am going to go ahead and "attempt" to rendezvous with the sivb i will be back if i need help [16:48:34] AlexB_88, it's helium pressure [16:49:03] oh I see [16:49:14] and thats always 3020 [16:49:31] yeah, static right now even, I think [16:49:38] The logic needs work still [16:49:44] nominal is 3020 PSI at 70°F [16:49:50] right [16:51:03] morning! [16:51:54] hey Mike [16:51:55] Ok lets look at this ASC PRES logic [16:52:03] hey [16:52:05] thewonderidiot, https://uhcl-ir.tdl.org/uhcl-ir/bitstream/handle/10657.1/377/2016-0005.pdf [16:52:19] "JSC Artifact Collection" [16:52:21] also at UHCL [16:52:31] but it's different from our usual collections [16:52:35] oooo, nice [16:52:46] has a bunch of Apollo 10 checklists and cue cards [16:53:21] I think I'll ask Lauren about it, haha [16:53:32] haha yeah, I was going to say... I guess Lauren would at least know who to talk to [16:53:51] yeah [16:54:06] I have good news too [16:54:33] that guy on reddit with a bunch of AC Electronics manuals finally got back in touch and said he is willing to drive it all to the nearest archive.org location "pretty much any time" [16:54:48] so... potentially Block I AGC+DSKY schematics soon [16:54:51] gotta love reddit [16:55:02] haha yeah [16:55:35] more reason for us to implement the Block I emulator [16:55:42] yep [16:55:47] together with the schematics we could make it all work properly [16:55:55] definitely :D [16:56:09] although it may be a while yet with all of the Block II stuff I have going on [16:56:21] before I can actually get down to implementing a Block I hardware sim [16:56:29] @thewonderidiot so have you flown a mission yet? [16:56:33] nope! [16:56:42] and won't for the forseeable future now [16:56:49] you should see your work in action [16:57:06] if everything goes well I will see it in action in different ways next year :D [16:57:39] indy91, what is "eci no 1 closed" in the ascent press cw logic [16:57:40] but for the most part I am pretty content watching the youtube videos that Niklas and Ryan make :P [16:57:42] and just wondering what exactly did you do again [16:58:02] AGC/AGS guru [16:58:15] rcflyinghokie, basically staging, electronic circuit interrupter [16:58:36] specifically AGC, I am fairly certain I know its hardware operation better than anybody else, other than the people that actually designed it [16:58:37] So it is closed while unstaged [16:58:39] but it's easier for now to just do a check on the current stage [16:58:51] Which is currently done [16:58:53] so I do a lot of work on the AGC emulator [16:58:56] yeah [16:58:59] yeah i am about to use it to rendezvous with the sivb in apollo 7 [16:59:05] Any idea about those 2 5V leads going into the or gate? [16:59:12] no [16:59:22] I think we will have to look at the electrical interface again, deadface code is messy [16:59:24] apparently it there is alot of stuff to do in a short time [16:59:50] oh yes, Apollo 7 rendezvous is very challenging [17:00:02] astronauthen96__ all rendezvous are like that, especially the direct ascent ones on later lunar missions [17:00:15] it comes with practice [17:00:28] Once you internalize what actually is happening, it becomes easier [17:01:52] will printing a tpi pad on paper come in handy or couldi just read it on the screen [17:02:31] I found that they are extremely helpful for all rdv phases [17:03:21] and one minor issue with the apollo 8 pre tei scenario [17:03:35] TPI PAD is mostly for a ground update though, at least on Apollo 7 [17:03:39] when you load it up it shows what appears to be an abort pad [17:03:44] and the ground update is just backup [17:03:51] tei-11 [17:03:56] ah, right [17:04:15] they did get both the final TEI-10 and a TEI-11 PAD at about the same time [17:04:22] i don't know if you have access to the tei pad but maybe someone could put it in the scenario description maybe [17:04:33] so when the scenario was saved the latest Maneuver PAD was the TEI-11 one [17:04:44] yeah, good idea [17:05:36] astronauthen96__, there is one thing you can do [17:05:52] TAB to open the CAPCOM menu [17:05:56] 9 for debug options [17:06:00] 2 for toggle MIT [17:06:01] MT* [17:06:23] then TAB and 9 again but then press 5 "Dec State" [17:06:28] and the TAB, 9, 2 again [17:07:09] then it should show you the TEI-10 PAD [17:08:16] that worked [17:08:21] what does the -10 mean [17:09:19] 10th revolution [17:09:44] yeah it says 89 hours so its pretty much the tei pad [17:09:53] yeah, Apollo 8 spent 10 orbits in lunar orbit [17:10:01] when you have written down the numbers from the PAD you want [17:10:08] Hell of a way to spend christmas [17:10:12] do you just do inc state [17:10:18] yep [17:10:25] that should show you the TEI-11 PAD again [17:10:41] and then the MCC should work properly, as in, will cycle to the next updates at the right time [17:11:00] is that an abort pad or is it for an extra orbit hence the 11 [17:11:35] it is for the case that they can't perform the nominal TEI maneuver [17:11:45] somethings breaks in the CSM prior to ignition [17:11:47] something like that [17:11:53] is there a tei pad for each revolution? [17:11:59] only on Apollo 8 [17:12:04] Frank Borman insisted on it [17:12:12] i probably would have too [17:12:27] for Apollo 10 and later there only was one for every few revs [17:12:45] More and more trust in the SPS [17:12:47] but you always want to have an abort PAD at some point in the future [17:12:59] if you loose communications [17:13:06] hence the TEI-11 PAD [17:13:36] TEI was also not something that could be calculated on board [17:13:42] yeah [17:14:03] During TLC or TEC they could calculate entry solutions and navigate with P23's [17:14:15] i am learning alot from nassp [17:14:18] But TEI was computed on the ground [17:14:22] if you just added 2 hours to the TIG of TEI-11 and burned the same DV you probably would still be able to get home with some larger course corrections [17:14:37] True [17:14:50] I am sure they had some contingency tables to do that [17:15:01] hmm, maybe [17:16:18] Ok i am working on this RR caution logic [17:16:22] I added the flip flop [17:16:31] they had procedures for interrupted TEI burns [17:16:36] Its just hard to follow haha [17:16:38] and are those numbers preloaded into the rtcc like they are for the landing missions? [17:17:08] yeah, the RTCC MFD should have good numbers preloaded for most missions [17:17:55] rcflyinghokie, first, there is an AND gate with 3 inputs [17:18:19] the inputs are: RR No Track signal, the flip flop and Auto Track [17:18:25] switch position [17:18:36] the rest of the logic will just be for the flip flop [17:19:15] set should probably dominate reset [17:19:25] reset with the auto track switch psition [17:19:33] set with another AND gate [17:19:34] Let me get this no track in the scea first then I will see if I can implement this correctly [17:19:44] and you probably annoyed by this but i just have to tell you that nassp is worthy of the most maximum amount of praise possible [17:19:45] ok [17:20:23] astronauthen96__, thanks! [17:20:33] no problem [17:20:45] and my favourite part was on apollo 11 when the earthrise came up [17:21:07] yeah, a lot of missions had really nice earthrises [17:21:28] and just wondering what software you use to record your videos? [17:22:09] OBS studio [17:22:13] its free [17:22:15] same [17:23:37] just so i know is it okay if i give a thanks to you guys at the end of the video [17:23:49] on youtube? [17:23:58] yeah [17:24:05] fine with me haha [17:24:32] yeah you will receive some praise [17:24:47] rcflyinghokie, I'll check the ECA code, maybe we need to adjust the LV voltage code now that we increased the open circuit voltage [17:25:07] it uses 93% of the input voltage [17:25:11] let's see if that is right [17:25:12] @indy91 do you mind if i do that? [17:25:19] you can, sure [17:25:28] Ah yeah [17:25:38] if you want to. I am always contect with just a general thanks to the NASSP team, haha [17:25:58] yeah [17:26:48] each battery has 20 cells [17:26:53] So the low voltage tap is good until about 90% remaining [17:26:54] LV tap is at the 17th cell [17:26:59] 27V [17:27:10] that would be 85% [17:27:14] 17/20 [17:28:03] aha! [17:28:08] someone did the math [17:28:19] we used 34V before [17:28:27] 34*0.93 = 31.62 [17:28:30] and now [17:28:40] 37.2*17/20 = 31.62 [17:28:47] How about that [17:28:52] so indeed it should be changed [17:31:18] So sidestep briefly, is the no track signal generated when the RR is not powered [17:32:20] I don't think so [17:32:31] it's a "No Track" relay in RR electronics [17:32:52] So if there is no DC it wont close the relay [17:32:55] the light uses a contact from the same relay [17:33:10] same as the signal to the SCEA [17:33:35] so the CWEA doesn't receive that input with the RR off [17:33:57] IsRadarDataGood() seems to send the signal regardless of power [17:34:11] yeah [17:34:21] that should probably be changed to IsRadarDataBad() or so [17:35:21] Yeah [17:38:29] hmm, need to check what the radar tape is getting in that case though [17:38:29] Ok those are changed appropriately [17:40:18] I just set it to !lem->RR.IsRadarDataBad() [17:40:53] instead of lem->RR.IsRadarDataGood() [17:41:21] then it will try to show RR data when the RR is off [17:41:38] later guys! [17:41:41] later [17:42:27] The Bad logic is reversed though [17:43:05] lem->RR.IsRadarDataBad() == false instead? [17:43:12] or == 0 [17:46:04] "Bad" has become the active signal instead of "Good" [17:46:25] Yes [17:46:27] so Bad would only be the case if the RR is powered AND has no signal [17:46:44] so the two case where bad is false are: RR no power and RR tracks [17:47:17] I am confused [17:47:52] Dont we want false for that radar tape? [17:47:55] the radar tape should only get data if there actually is data [17:48:16] and IsRadarDataBad() is not a good indicator for that [17:48:22] Oh i see [17:49:12] I just went through and swapped the logic on all the old radardatagood to radar data bad [17:49:22] swapping the 1's and 0's accordingly [17:49:42] yeah, that is only half the story [17:50:28] What else needs to be done then [17:52:36] the tape meter is getting an entirely different signal from the RR [17:53:43] that relay in the RR is only used for the SCEA and the light [17:53:52] and from the SCEA to the CWEA of course [17:54:55] So we need another function for the relay? [17:55:20] at least the SCEA/CWEA and the tape meter can't use the same one [17:55:37] I see [17:56:14] So could the good function be used in the bad function? Does that make sense? [17:56:25] the tape meter is getting separate signals for range and range rate for one thing [17:57:05] internally in the RR maybe [18:01:38] so, the RR has a frequency and range tracker lock relay [18:01:53] that is basically "IsRadarDataGood" [18:02:16] and if energized, that relay is opening a contact to a relay driver for the No Track relay [18:02:53] I think you know that system better than I do [18:02:58] yeah [18:03:04] Would you like to make the relay? [18:03:37] yeah, I that that is the simple solution. I'll add another relay for the No Track case [18:04:02] which will be used for light and SCEA [18:04:09] everything else stays the same [18:04:35] Ok [18:05:02] I already have the scea ready for it I just need to know the function name [18:06:06] GetNoTrackSignal probably [18:10:35] I'll also change the light logic, SCEA and CWEA is your job [18:12:05] Sure [18:12:43] hmm, "RR.IsDCPowered()" [18:13:06] what in the RR needs AC power? [18:14:56] "loss of RR antenna slew & track capability" [18:15:39] the No Track Relay just gets power from the RR DC power supply [18:15:52] so with the RR AC breaker open, you probably would get the light [18:16:28] nah, I'll simulate that later [18:17:05] I want to give the RR a makeover again anyway [18:17:23] and finally properly connect the test modes with the normal logic [18:19:04] I forgot what needed the AC [18:19:12] But the no track light was just DC I believe [18:19:35] yeah, I tracked it down in the Systems Handbook [18:20:44] ok, I'm moving it above the "!IsPowered()" code and add a proper DCPower condition [18:20:48] not so difficult [18:23:26] done [18:23:29] GetNoTrackSignal() is the function [18:27:45] Ok [18:38:01] hey [18:38:07] o/ [18:38:14] Add RR no track relay, does that affect the cw operation? [18:38:30] that's what Ryan is working on now [18:38:36] ah ok [18:38:41] I just did the RR changes [18:38:44] and for the light [18:38:55] the light will now be on if the RR only has DC power [18:39:04] oh does that take care of the RR test issue [18:39:19] probably not [18:39:37] the operation of the no track light was not as per the checklist during the RR test [18:39:54] RR test needs some revisions [18:41:30] if I do that next then the Apollo 10 MCC will never get finished! haha [18:43:23] yeah lol better let you finish the MCC [18:45:54] So basically if it is in auto track and gets a no track signal the light comes on? [18:46:36] if it switches from track to no track, I think [18:46:41] that is what the flip flop should do [18:49:59] I think [18:50:50] the flip flop logic has to come before the CWEA light logic [18:51:22] when you switch from manual to auto [18:51:30] and lock on happens immediately [18:52:48] then the FF gets set [18:54:49] but the no track signal is off [18:54:53] so no CWEA light [18:55:02] when you then loose lock [18:55:16] then the flip flop is still set [18:55:34] so you get a light [18:55:53] you don't even need lock on immediately [18:56:11] So losing lock while the flip flop is set turns the light on [18:56:24] yeah, because the flip flop is one input into the AND gate [18:56:54] I still am having trouble with this, maybe I am not thinking clearly [18:57:54] it's certainly tricky, I'm not 100% yet either [18:59:03] Ok so what all sets the flip flop [18:59:15] I have moving to auto track as resetting it [19:00:49] yeah, it has to be a if/else if condition [19:01:04] because you might get set and reset at the same time [19:01:41] speaking of else if [19:01:45] can you quickly look in LEM_CWEA::SystemTimestep [19:01:48] sure [19:01:57] why is that an else if? [19:02:08] copy paste error [19:02:13] ok [19:02:18] should be just an if [19:02:38] thanks [19:03:25] so if the no track signal is good and the switch is in auto track, the flip flop is set [19:04:02] you mean if the no track signal is off [19:04:05] yes [19:04:24] yeah, that together sets the FF [19:04:31] that should be in the if condition [19:04:37] yes [19:04:40] and the else if for the FF just has the auto track switch setting [19:04:59] To reset [19:05:36] yes [19:06:03] the only logic problem I have is that the loss of tracking would cause the FF to be reset [19:06:30] only moving to auto track would [19:07:39] and the cw logic, flip flop set, no track signal is on, and in auto track? [19:08:00] Wont that reset the flip flop? [19:08:18] all of this is in auto tracking [19:09:27] so moving to auto track wont keep it reset [19:09:46] it will just reset and allow it to be reset unless moved out and into auto track again? [19:10:38] I don't think the case of not being in auto track is very well defined for the FF [19:10:44] it doesn't really matter I think [19:11:10] Here is what i have so far [19:11:11] https://www.dropbox.com/s/24p7a5k9fhgjwce/Screenshot%202018-03-20%2015.10.40.png?dl=0 [19:12:52] AutoTrackEnabled is your FF variable? [19:13:14] int or bool? [19:13:33] the else if is wrong [19:13:58] that's the thing with the FF [19:14:20] both set and reset input are from the auto track position of the switch [19:14:29] so it has to be "== 0" in both cases [19:14:54] autotrackenabled is an int [19:15:02] can probably be a bool [19:15:12] just has to be true and false [19:15:16] nothing else [19:15:27] Ah i just copied the water warning flip flop [19:15:39] which can probably also be a bool [19:15:48] I can change that after this [19:17:03] so == 0 will set those booleans to false [19:17:15] == is a check [19:17:36] thats why I has = [19:17:39] had [19:17:55] Shouldnt those change the FF to 0 [19:18:10] I'm not sure what you are talking about [19:18:18] for the FF [19:18:21] the if condition is correct [19:18:26] You said has to be "== 0" in both cases [19:18:27] else if condition is not correct [19:18:29] yes [19:18:38] RendezvousRadar.GetState() == 0 [19:18:40] you have [19:18:40] != [19:18:50] Oh [19:18:51] I see [19:18:54] has to be "==" for both if and else if [19:18:55] I got it [19:19:05] I was looking at the wrong part [19:19:08] right [19:19:19] and for the lightlogic you just need the same condition again [19:19:29] because auto track is also an input into the last AND gate there [19:19:39] you don't even need the lightlogic variable for this [19:19:55] I added that for lights with multiple ON conditions [19:19:57] like the ECS light [19:19:59] I put it in just in case this got complicated [19:20:07] yeah [19:20:35] if (AutoTrackEnabled == 1 && sceravoltage > 2.5 && AutoTrackSwitch == 0) [19:20:37] basically [19:20:43] to set the light on [19:20:57] but that is not fully correct yet [19:21:15] because that would reset the FF when you loose tracking [19:21:22] so we are still missing something [19:21:25] not sure what yet [19:21:36] Haha complexity [19:21:53] https://www.dropbox.com/s/dzd5wr77o6qn73r/Screenshot%202018-03-20%2015.21.49.png?dl=0 [19:21:56] So far [19:22:04] oh [19:22:05] hmm [19:22:06] theory [19:22:38] the reset only gets an input when you set it to AutoTrack. So not all the time, but only at the moment you set it to auto [19:22:50] Thats what I was thinking earlier [19:22:54] Its a one time thing [19:22:58] Not constant [19:23:07] Then of moved out and back in it does it again [19:23:19] yeah [19:24:39] How to do that in here though [19:25:12] do most FFs behave like this? [19:25:16] thewonderidiot [19:26:07] hi what's up [19:26:25] flip flops [19:26:30] right [19:26:33] what about them? [19:26:40] when you have a constant input into let's say reset [19:26:56] mhm [19:26:57] would it try to reset all the time? [19:27:20] or would it basically need the change from logic 0 to 1 for the input to reset [19:27:40] if it's a regular flip-flop, it would be trying to reset all the time [19:28:02] however, SET inputs can still be noticeable on the output, depending on exactly how things are wired [19:29:07] in our case a switch is in Auto Track all the time, basically [19:29:12] Auto Track causes reset [19:29:25] but we think only switch it away from Auto Track and back to it resets the FF [19:29:45] and there is not signal to set in this case [19:29:48] no* [19:29:50] hmmm [19:30:26] I'm not sure what logic technology that would be, but it's possible [19:30:31] NOR logic does not work that way [19:30:47] I'll check the schematics [19:33:05] Sorry had a work phone call [19:33:56] this behavior of NOR logic, by the way (SET being visible through a persistently-held RESET, and vice-versa) is part of what caused the LR bug in the AGC, by the way :P [19:34:05] https://www.dropbox.com/s/lmodfuiwha3yui7/Screenshot%202018-03-20%2015.33.59.png?dl=0 [19:34:13] The center is the logic in question [19:35:55] the power through the RR mode select switch comes from "+9VDC C And W Enable Bus" [19:36:01] which might be interesting [19:36:13] maybe it works like we thing the CWEA Reset bus works [19:36:17] think* [19:36:29] so only gives a blip of power [19:36:52] I wish we had more info on those little busses [19:36:56] There seems to be a few of them [19:39:03] I need to run for a bit, let me know if you figure anything else out or if you and Mike figure out this logic conundrum [19:39:50] from the description in the AOH I am fairly sure it has to work like this [19:47:00] when in doubt we can always get Grumman schematics from NARA [19:47:10] if you can figure out which drawing this is in [19:48:39] I probably can [19:49:11] the CWEA buses are more interesting for this than the FF [19:49:32] I think the FF is a normal one, just no power comes through the RR Mode switch anymore [19:49:46] so CWEA power supply schematics [20:00:40] I think I found something [20:03:53] not really, just a change from LM-4 to 5 [20:04:03] we implement the version as it worked on LM-5 and later [20:06:53] ANy luck? [20:07:12] not yet [20:15:23] The RR schematics has all this logic in it as well [20:15:33] Cw 2 I mean [20:15:52] Including some relays which could be pertinant [20:16:13] Q5 on handbook pdf 193 [20:17:42] nothing really new there [20:18:34] right now I still think the C&W Enable Bus is the interesting part [20:18:46] Is there anything more explaining that? [20:19:00] haven't found it yet, if there is [20:20:02] hmm [20:20:05] no, this can't be it [20:20:25] then AND gate at the end needs power coming from the RR Mode switch [20:21:14] the flip flop somehow stays set when the RR looses tracking [20:21:15] how [20:23:56] does the AOH description help? [20:24:33] top of AOH 526 [20:25:01] it at least describes how it should behave [20:25:11] light stays on until tracking condition is restored [20:25:15] I am just trying to follow the logic [20:25:32] It feels all over the place even though I am sure it isnt [20:49:24] the AGS cw light also doesn't behave as per the activation checklist [20:49:51] It doesnt have all the logic [20:50:23] rright [20:50:28] *right [20:50:38] last thing I can think of [20:50:48] voltage from the CWEA bus [20:51:06] when you switch to Auto Track, there is a voltage spike [20:51:09] or current, whatever [20:51:09] I can throw the AEA power logic into it Alex [20:51:15] that is enough to reset the FF [20:51:26] Kind of like it overpowers the set? [20:51:41] well, there wouldn't be a set signal at the time [20:52:18] but after switching to Auto Track there is enough power to energize the AND gate inputs [20:52:23] but not the reset input to the FF [20:52:28] So how do we simulate this haha [20:53:48] we remove the reset condition out of the CWEA code [20:53:55] so that only the set condition is there [20:54:00] rcflyinghokie, sounds good [20:54:05] then we add some code in LEM::PanelRotationalSwitchChanged [20:54:18] that function is only called if the switch was just changed [20:54:46] and if the state it was just changed to is Auto Track, it calls a function in the CWEA [20:55:05] there it checks for CWEA power and if it has that power, then it resets the FF [20:56:07] I wonder if that would be helpful when using the other flip flop [20:56:12] waterwarningdisabled [20:56:20] As it is also used in the AGS [20:57:25] looks like there are 3 separate FFs for the WATER QTY light [20:58:06] Yes [20:58:33] So we cannot use the same bool for all of them [20:59:08] yes [20:59:17] I can start divving those up [20:59:27] looks like the ags has some interesting logic as well with the FF [20:59:31] I don't think we will have the same problem with those FFs [20:59:39] I'll look at the AGS [21:00:02] one FF [21:00:06] and complicated logic [21:05:50] Yeah [21:05:59] Mostly ASA comparators [21:06:26] I need to figure out what turns the light on when the switch is set from standby to opr [21:07:41] turning it from off to standby with the ASA on brings up the light [21:07:50] Then closing AEA turns it back off [21:08:10] then with the AGS AC breaker in and it moved to opr, it comes back on until the FF is reset [21:12:24] Dinner time [21:19:58] indy91, I'm wondering if your fix to remove the D3D9 errors that you did earlier might of fixed the panel change CTD in the LM [21:20:39] I'll have to test for that by trying to recreate that CTD. Thing is it was quite rare and hard to re-create [21:31:52] ooh I was able to recreate it on an old repo [21:32:17] by continuously switching between the panels [21:32:44] lets see if I can re-create it consistently [21:37:47] it's quite possible that this fixes a few things [21:38:09] after all it was a pretty bad bug [21:39:38] releasing all the surfaces was bad enough, but only affects closing Orbiter [21:39:43] not releasingÜ [21:39:47] not releasing* [21:40:12] but removing the duplicate surfaces really could do some good things [21:41:42] well I can re-create it very consistently on my old repo, but the debug points to the duplicate COAS (obviously) but I haven't been able to recreate the CTD which pointed to the MFD (in my old repo) which is what I am trying to do [21:42:00] right [21:42:28] the other duplicates were two borders [21:42:33] for the Checklist MFD [21:42:36] I'll check what uses them [21:42:42] its just that before, all the panel switching CTD's I was getting, were pointing to the MFDs [21:43:00] ok [21:43:10] every toggle switch :D [21:43:31] the other border isn't used, as far as I can see [21:44:03] difficult to tell what the side effects of this are [21:44:14] you would register additional surfaces with Orbiter [21:45:07] yeah, I don't really have an idea how this fixes anything except for the Orbiter log errors [21:47:46] emphasis on "no idea", this just isn't any kind of code I have messed with before [21:49:29] Hmm I still dont get how the logic explains the ags light for the activation procedure [21:50:07] I'll look at it tomorrow. Good night! [21:50:18] Night! [21:51:51] I guess we'll have to pull out some major schematics for that one lol [21:54:46] Maybe [21:55:08] the logic seems straight forward, I just need to figure out which condition is triggered by moving from stby to opr [21:55:19] I am currently adding all the flip flops for the CW [22:01:54] hey again @rcflyinghokie just wondering how are your framerates? [22:02:08] Usually very high [22:02:31] i am just worried windows 10 will make them lower [22:03:51] they are high right now with windows 7 [22:05:32] That shouldn't [22:05:37] If the GPU is the same [22:05:50] Unless you have a finite amount of RAM [22:06:04] 4g [22:06:04] I am running 16GB, but with 10 you really ought to have 8 [22:06:35] my dad has extra ram though i think another 4g stick [22:06:50] Any 64 bit OS should have more than 4gb of ram I think [22:07:20] Just need to make sure its the same type as yours and that you have a 4gb stick and not 2x2GB [22:07:34] yeah it says 4gb [22:07:45] just one stick [22:08:31] do you think that might be my issue with the ram [22:10:02] could be [22:10:33] only seems to happen when there is two vessels [22:10:44] what GPU do you have? [22:11:57] NVIDIA GeForce 210 i dont know if thats the gpu [22:15:33] hmm that could be the problem... Orbiter 2016 is very graphic intensive with the new earth and moon meshes [22:15:46] apparently its old too [22:16:10] and maybe with only the CSM, its not enough to put it over the limit... but with the LM on top, yes [22:16:54] maybe the extra ram will help though [22:17:05] https://www.geforce.com/hardware/desktop-gpus/geforce-210/specifications [22:18:41] and as @rcflyinghokie said it could be a hardware issue [22:19:29] Thats why I was thinking my intel graphics on my windows 7 machine was the reason I got the CTD with dxd9 [22:19:33] is it a tower or laptop^ [22:19:51] mine is a tower [22:22:18] at least the extra 4gb ram will be free [22:23:24] more ram and investing in a better GPU would certainly help [22:23:59] depending on how old your PC already is [22:25:55] and this windows 7 is a pirated copy that is why i want to upgrade to a legal windows 10 [22:26:04] actually buy it [22:26:46] and this computer is 8 years old [22:29:00] i do think its hardware because even after reinstalling windows twice the ctd's still happen [22:31:55] What you can try now is adding the 4 gb ram and see how that works [22:32:35] and as for the laptop, it had 3g's of ram with severe lags it was unplayable [22:33:32] and I don't know if adding a new GPU would help in your case, considering your PC is 8 years old [22:33:54] Yeah [22:34:04] Your MB probably cannot support a newer one unfortunatly [22:34:50] i have been thinking of getting a new computer for quite some time that is why i didn't want to get the oem version of windows 10 [22:34:52] or maybe it can [22:34:54] pcie [22:35:19] Much cheaper to build a new one yourself these days [22:43:16] and fun [22:44:25] i was thinking of getting this https://www.amazon.ca/Windows-10-Desktop-Computer-Optiplex/dp/B01E5VRJSU/ref=sr_1_2?ie=UTF8&qid=1521585809&sr=8-2&keywords=windows+10+computer&dpID=413AfaSztbL&preST=_SY300_QL70_&dpSrc=srch but i don't think it comes with a dedicated video card [22:46:48] I would highly recommend not getting a PC with integrated graphics [22:48:04] unless your only using it for non-graphic applications [22:48:08] agreed [22:48:28] You can probably build a new one using your current tower [22:48:33] ive made that mistake before lol [22:48:41] find a MB/processor combo deal [22:48:49] Pick a GPU [22:48:52] Ram [22:49:02] and find a power supply that supports it [22:54:48] yeah i tried it on my dads $200 windows 10 computer and it was a bit slow [23:01:59] do you think a laptop would work? [23:02:30] Desktop would be a lot cheaper to get specs for running this [23:03:03] yeah i just really want to get rid of this old pc as fast as possible [23:03:04] I just bought a pretty powerful laptop that runs it but I also had to replace a 10 year old laptop so I could justify the purchase haha [23:03:17] Your best bet is building one seriously [23:03:21] It is very easy [23:08:36] are your compiters all expensive [23:09:14] because i will be getting a job very soon [23:11:44] I probably put 800-900 into mine total [23:12:05] My initial build was maybe 500-600 [23:12:21] Then you can upgrade parts for a lot less than a whole new system [23:13:28] how do you think this would work https://www.amazon.ca/MSI-GT-710-2GD3-LP/dp/B01DOFD0G8/ref=sr_1_2?ie=UTF8&qid=1521587563&sr=8-2&keywords=graphics&dpID=51CMTwgy7vL&preST=_SX300_QL70_&dpSrc=srch [23:15:02] Hard to say honestly [23:15:41] yeah i can play flight simulator x at the highest settings with no lags or issues [23:17:24] Actually FSX is very CPU intensive not GPU intensive [23:18:09] So the GPU wont change FSX performance as much as you might think [23:24:48] well i hope this ram will help [23:26:37] Doubling your ram should help somewhat [23:26:56] People underestimate how much effect extra ram has on a 64 bit system [23:27:04] maybe the ctd's will stop [23:27:23] Thats hard to say, I am thinking those are hardware related but its worth a shot [23:27:37] You do have the latest dx drivers right? [23:27:40] rcflyinghokie, I see some updates for the RR CWEA, ill try that now [23:27:44] not sure [23:27:53] Eh work in progress AlexB_88 [23:28:12] Niklas and I are still confused with the logic sequence [23:28:20] right [23:28:21] could you give me a link and i'll check [23:28:24] I did add flip flops for everything [23:29:03] astronauthen96__ believe it or not I had to install these on my brand new laptop to et orbiter to work right [23:29:03] https://www.microsoft.com/en-us/download/details.aspx?id=8109 [23:29:24] Install that first [23:29:27] Then check this [23:29:28] https://www.microsoft.com/en-us/download/details.aspx?id=35 [23:30:24] and as for visual studio it said something about heap fragmentation [23:31:48] When/where did it say that [23:32:06] on the bottom right [23:32:15] it was last month i thinki [23:32:42] I have never seen that before [23:32:49] What were you doing when it happened [23:33:04] switched panels [23:33:10] it was the ntdll [23:33:23] Ah the error we cant track down haha [23:34:05] and i have no idea how to install this direct x [23:35:10] download the file [23:35:24] dont include any of the checkboxes [23:35:26] where do i extract the files to? [23:35:46] Make a folder you can easily fine [23:35:48] find [23:36:21] okay [23:36:42] Then after extracting open it up and run DXSETUP [23:37:52] i doubt this will fix it but it is worth a try [23:38:27] Yeah it didnt on my old laptop [23:38:31] But never hurts [23:42:19] my dad might have another video card too [23:42:23] one more free thing [23:43:35] Hey free is always good [23:43:56] Also ebay is a great way to get used parts, just make sure you scrutinize the seller ;) [23:44:13] I got my 500 dollar GPU for 240 brand new from ebay [23:44:25] well i am going to take a break from nassp tonight si will be back tomorrow with apollo 7 [23:44:36] Quicksave often! [23:44:42] it has been giving me headaches [23:44:49] It is complex [23:45:18] It mimics a lunar orbit rendezvous though [23:45:20] https://history.nasa.gov/afj/loressay.html [23:45:26] maybe some Tylenol and a new video card and some extra ram would help [23:45:28] That might help you picture what you are doing [23:46:04] okay [23:46:07] good night [23:49:24] Later [00:20:57] Well I have more AGS logic done now, but still need to figure out the best way to send 12V 28V and freq data to the SCEA [00:21:06] And an AEA fail logic [00:28:30] great [00:34:43] A bunch more to figure out [00:35:26] trying that now [00:35:55] Was that LCA thing Niklas was talking about done^ [00:36:23] lighting control assembly [00:37:43] No it hasnt been started I dont think [00:37:48] We got stuck on logic [00:37:54] the RR is very confusing [00:38:31] yeah [00:39:10] I also noticed that the CWEA seems to work even without power [00:40:37] The lights stay on? [00:40:53] ie. from a fresh LEM without power yet, you close just the CWEA cb and the annunciator lighting cb and the cw panel lights up [00:41:08] and the MA if you close the MA cb too [00:41:12] That sounds right [00:41:18] ah ok [00:41:33] It is getting no scera data so all voltages are zero in the comparator [00:41:42] gets its power from a hot bus or something? [00:42:02] What do you mean [00:42:21] well if the LM is powered down, where would the power come from [00:42:39] Wait you mean if the batteries are off? [00:42:43] yes [00:42:49] Not connected to CSM power? [00:42:56] neither [00:43:06] That shouldnt happen [00:43:14] I was thinking that too [00:43:15] Those CB's have to get power from the busses [00:43:18] Ill check [00:43:20] right [00:43:34] But first, I just got an ntdll.dll CTD [00:43:59] Something to do with the DES O2 tank [00:44:07] if you take a fresh LM that has been ejected from the SIVB then close only those 2 cbs the CWEA lights up without batteries on [00:44:09] ah bummer [00:44:44] I bet its an initialization issue it happened when get scenario state was called [00:48:42] I got a screen shot [00:48:46] Now to look at the LM [00:52:08] I also have a glycol light on [00:53:18] Ah because the fresh LM starts with bats 1 and 4 on [00:53:41] Flip the battery displays on [00:57:27] oh lol [00:57:31] right [00:57:37] Took me a second as well [00:58:18] I am trying to get ASA temp into the scea but it will not return voltage and I cannot figure out why [00:58:22] so thats why a freshly entered LM has like glycol light on [00:58:26] Yes [00:58:35] all comp lights would be off with the dimmer [00:58:44] right [00:58:58] thats what the LCA will do? [00:59:06] Yeah one of the many wonderful things [00:59:31] Which reminds me, when the LCA is done I am going to implement the TLE (tracking light electronics) [00:59:36] Any hope of a strobe? [01:00:26] oh right yeah I can look into that [01:02:48] I wouldnt imagine it would be hard, I see a lot of orbiter vessels with strobes [01:03:05] And we have data on flashes per unit time [01:03:26] Should be a simple on or off [01:03:46] yeah [01:04:01] should be easy [01:04:12] I'll start looking into it tomorrow [01:04:28] Awesome [01:04:30] I had another question about the CWEA [01:04:32] Sure [01:06:04] On the Apollo 12 comm activation checklist, it says transfer to LM power and then the C/W PWR caution light should come on. Wouldnt that require the ANUN/DOCK/CMPNT cb to be in already? [01:06:25] Because at that point that cb is still open [01:06:27] It is at launch [01:06:55] That breaker is never opened [01:07:09] but the initial activation status has it open [01:07:15] Which one, there are 2 [01:07:19] redundant [01:07:29] CDR one should be closed [01:08:16] yep its closed [01:08:26] That should allow the cw pwr light to come on [01:08:34] but looks like the LMP one needs to be closed in the sim for now [01:08:47] maybe a LCA thing? [01:08:56] No thats a logic issue let me see [01:09:16] I changed that recently [01:10:09] Yeah I changed LEM_CWEA::IsLTGPowered() [01:10:15] Added an or for both breakers [01:11:25] Interesting it still just uses the LMP breaker [01:11:38] Good catch [01:11:44] The LCA will fix this but I can fix it for now [01:12:11] Haha [01:12:14] I am stupid [01:12:24] The breakers in the OR condition are the same [01:12:33] haha [01:12:36] oops [01:12:47] easy fix [01:12:53] bool LEM_CWEA::IsLTGPowered() { [01:12:53] if (ltg_pwr->Voltage() > SP_MIN_DCVOLTAGE || lem->CDR_LTG_ANUN_DOCK_COMPNT_CB.Voltage() > SP_MIN_DCVOLTAGE) [01:12:54] return true; [01:14:06] if you are running off of mine it is pushed [01:14:20] Forgive the debug lines if you are though [01:14:52] thanks [01:15:02] yep I have a repo running yours [01:18:10] I appreciate the real time error checking :) [01:19:27] no worries I love to test :) [01:20:32] yep seems to work now [01:23:02] Great [01:24:17] Hmm [01:24:34] It doesnt seem to be properly loading things like the antenna temperatures between saves [01:25:11] Ah there it goes [01:25:15] Bad save on a current state [01:27:23] is RCS and DPS/APS fuel temp on the way too? [01:28:59] I havent dug into any fuel systems yet, I imagine we can just give them a set temperature for now, or set them as a radiator so they can slowly heat or cool from surroundings [01:29:11] Easiest thing is a set temp for the time being to hook up displays and scea info [01:30:25] right [01:31:24] So that wont be hard [01:31:50] I am sure there are still more displays that need scea info as well [01:32:02] A lot to comb through [01:32:21] CWEA, much like doing the temperature displays, is helping find missing ones and putting them in as needed [01:32:37] Most of the CWEA uses the SCEA now [01:39:49] good to hear [01:40:18] so the SCEA is feeling more important every day lol [01:40:48] Yeah it connects everything :) [01:40:58] I need to call it a night though [01:41:02] I am making silly mistakes [01:41:11] me too [01:41:13] And I think I may have botched flip flop logic haha [01:41:17] But I will see tomorrow [01:41:24] Night [01:41:27] cya [11:40:57] hey indy [11:41:02] hey [11:41:25] I saw your post on the Orbiter Forum. So you are getting the CTD even with the latest NASSP updates from yesterday? [11:41:38] have not tried it yet [11:42:13] i think rcflyinghokie got an ntdll error yesterday i was reading the chats [11:52:26] @indy91 but i don t think its related to what i am getting [11:52:39] yeah, probably not [11:53:54] Something to do with the DES O2 tank [11:58:13] @indy91 anyway i am going to see if those updates fixed it and then work on the rendezvous with apollo 7 [11:58:59] sounds good [11:59:14] cya [13:10:58] morning [13:20:16] hey [13:24:28] hi alex [13:25:20] just reading the post of the guy who wants to have part of the checklists automated [13:25:38] I guess it would be possible, just has to do lots of editing [13:25:47] @alexB_88 i think rcflyinghokie had an ntdll error yesterday do you think it might be related to my ctd's [13:25:54] i doubt it [13:26:08] hard to tell [13:26:26] it was in the lem i think [13:26:32] and actually, no because his debug pointed to a specific cause [13:27:04] did he post a screenshot? [13:27:39] hmm I can't remember, but it was something to do with ECS I think [13:27:55] DES O2 tank [13:27:59] yes [13:28:42] astronauthen96__ did you try the extra ram? [13:28:56] not yet my dad is out of town [13:29:00] right [13:29:32] well i have 4g of ram would an extra 4g's really affect anything? [13:30:49] as we said yesterday, 4g is quite low and given Orbiter 2016's high detailed earth/moon textures, it could very well help. But what is most likely the issue is your lack of a proper GPU [13:31:47] yeah maybe it cant handle the lem and csm together [13:32:58] While your CSM only scenarios are ok, the added LM might be what throws it over its tipping point, resources-wise [13:33:37] the LM is getting to be quite a large module as of now [13:34:19] i just don't know what video card to get [13:34:40] combined with the earth+moon in Orbiter 2016, not a good match for an 8 year old PC :D [13:35:28] have you tried testing without the high detailed textures of earth+moon? [13:35:37] no [13:36:26] do you have your settings all maxed out in the Orbiter options? [13:36:50] well [13:36:57] planet night lights are 1.00 [13:37:04] res is 19 [13:37:12] ambient light level 25 [13:37:40] ok try turning down the planet resolution [13:38:03] youu mean the max resolution level? [13:38:11] yes [13:38:24] maybe 10? [13:39:16] I'd go as low as possible just for testing 1st [13:39:19] try 1 [13:39:28] and then try and reproduce your CTD [13:39:29] okay [13:39:54] i will be back in maybe 20 minutes [13:42:41] Just have to do docking and then see if it works [13:43:03] I am on my tablet now [13:43:34] ok [13:43:44] The earth looks dreadful but I still hope it works [13:44:06] Better then nothing [13:44:21] yeah, if it works, then you can bring the res back up in increments until you can reproduce the CTD [13:44:38] and then you know what the max res will be [13:45:02] I won't use the etc for the evasive maneuver as I have everything memorized [13:45:15] Rtcc* [13:46:35] for the evasive maneuver the RTCC MFD is mostly useful for the trim gimbal angles [13:46:45] on the Maneuver PAD [13:47:02] but not really anything else [13:47:49] Yeah I got 00082 00026 [14:03:36] AlexB_88, I've begun the work on a rendezvous planning tool [14:03:46] oh nice [14:03:50] not sure how easy it will be to implement for the MFD [14:04:05] in the MFD? [14:04:15] just available for the MCC as the first step [14:04:36] it will have different rendezvous plans [14:04:47] in the first step the nominal Apollo 10 sequence [14:05:06] Phasing (Fixed TIG) - Insertion - CSI (at apolune) - CDH - TPI (fixed TIG) [14:13:59] so when this eventually gets to the MFD, is it some sort of thing that tells you what the required maneuver is, say PDI+12, with a TIG, target TOA and offsets? [14:14:15] that you then plug into lambert DV [14:14:32] you'll give it a desired rendezvous sequence and the most useful output will be the times of CSI, TPI etc. [14:14:39] lambert page* [14:15:01] Morning gents [14:15:05] hey [14:17:47] I began experimenting with adding in FF's throughout the CWEA last night, I think for most the behavior is right but still a few I am unsure of [14:19:09] hey Ryan [14:19:34] AlexB_88, usually for the various rendezvous aborts you get one ground calculated maneuver and then the CSI and TPI times for the onboard calculations [14:19:47] I would imagine that being the relevant outputs of a rendezvous planning tool [14:20:52] makes sense [14:20:57] rcflyinghokie, I read you had issues with a SCERA returning a voltage? [14:21:05] I figured it out [14:21:13] Though I dont know why what i did worked [14:21:20] that's never good [14:21:27] You might be able to help [14:21:28] what did you do? [14:21:52] I added ASA Temp to it [14:22:04] 1/10 [14:22:18] And the current ones on there were outputs 1 3 and 4 [14:22:27] I made it output 5 at the bottom of that list [14:22:37] No voltage [14:22:45] Changed it to output 2 and it works [14:23:04] that subassembly only has 4 channels [14:23:14] maybe I am using the wrong type of subassembly [14:23:15] Ah [14:23:25] Well you didnt have a 2 in there yet [14:23:31] So maybe the ASA was the missing link [14:23:44] If thats the case everything looks right [14:24:34] Systems Handbook says it should be channel 2 [14:24:37] where did you get 5? [14:27:43] I added it to the bottom and just went sequentially, it was an oversight [14:27:56] I was getting tired and not thinking straight last night haha [14:28:36] so you didn't research where it actually should be added? :D [14:31:20] because, the channels aren't random [14:32:25] rcflyinghokie, looks like the CWEA is behaving like it should now at LM PWR transfer early in the activation checklist. When I transfer to LM power the C/W PWR caution lights up as it should [14:32:47] nice to see things slowly start behaving like it says in the checklist [14:32:51] Good to hear [14:33:51] And indy91, I usually do, again I was just tired and wanted SOMETHING to work before bed [14:34:01] haha, ok [14:34:29] But it solved itself it seems [14:35:12] yeah, you used the right channel then [14:35:21] even if you didn't know that at the time :D [14:36:20] Which reminds me, there are a few other ASA items in the SECA but no scaling [14:37:10] like? [14:37:19] Things like ASA freq and the 12V and 28V [14:38:18] AOH has the scaling [14:40:23] Any idea why they arent in the handbook? [14:40:37] I did find them in the AOH but was hesitant as they are different LM's [14:41:44] where does the Systems Handbook have scalings? [14:42:33] and ASA frequency is not on telemetry [14:42:39] maybe it's missing because of that [14:44:11] TM data range column of the tables [14:45:14] ah right, there [14:45:38] so probably missing because it's not telemetry [14:45:52] but the scaling seems to be 380 to 420Hz [14:46:01] Yeah thats what it looks like here [14:47:04] Does the ASA have its own power inverter? [14:52:49] yep [14:53:07] I guess I'll have to implement that in some way [14:53:36] easiest solution is adding a function to the ASA for the SCERA first, just one that returns 400Hz if the ASA is powered [14:55:15] Right [14:55:34] I added a get temperature function already [14:55:45] The 12V and 28V are interesting though [14:56:00] I guess they would work the same way [14:56:24] Though the temperature warning tells the CW its high by open circuiting the 12V connection [14:56:42] yeah, the ASA power supply has a lot of outputs [14:57:08] PDF page 205 [14:57:14] in the Systems Handbook [14:58:04] Yeah [14:58:26] I think the temperature logic should go in a function that opens the 12VDC going to the CW [14:59:22] But a simple is powered should suffice for tthe 28V and freq [14:59:33] I think I know how to approach that [14:59:54] Now, do we have anything that can generate the AEA test mode fail properly set up? [15:01:19] And before I forget, the ASA IsPowered function includes the AGS switch, even though the ASA power is not controlled by that [15:01:44] AEA test mode is in software [15:01:49] there is an output bit for it [15:01:58] just have to do the wiring for it, I hope [15:03:22] not even that [15:03:33] does it go directly to a CWEA input? [15:03:43] Yeah [15:04:07] ok, in the CWEA timestep [15:04:14] at the beginning are a bunch of AGC channel values [15:04:24] add this [15:04:24] Ok [15:04:25] AGSChannelValue40 agsval40; [15:04:40] and then below, where the code gets all the AGC bits [15:04:41] add [15:04:41] agsval40 = lem->aea.GetOutputChannel(IO_ODISCRETES); [15:05:02] it's inverted logic [15:05:22] Should this indicate fail when the AGS switch is first thrown to OPR? [15:05:23] ~agsval40[AGSTestModeFailure] [15:05:32] not sure [15:05:45] the ~ inverts the bit [15:05:49] That is what causes the MA when the switch is moved to OPR [15:06:05] you will see, I guess, haha [15:06:09] Haha ok [15:06:34] Actually shoot it goes through the SCEA [15:06:52] 1/4 [15:09:16] probably the best to add a function for it that asks the AEA for the output discrete [15:09:27] and let the SCERA access it [15:10:37] Yeah [15:12:57] Do it the same way as it was in the cwea? [15:13:09] almost [15:13:14] I'm working on it [15:13:27] Ah ok [15:14:24] is there a procedure to open the lem hatch from the csm? i would like to just try it [15:14:37] bool LEM_AEA::GetTestModeFailure() [15:14:38] { [15:14:39] Not implemented [15:14:39] if (!IsPowered()) [15:14:40] return false; [15:14:41] AGSChannelValue40 agsval40; [15:14:41] agsval40 = OutputPorts[IO_ODISCRETES]; [15:14:42] return ~agsval40[AGSTestModeFailure]; [15:14:43] } [15:15:12] well i made it to six hours [15:16:22] indy91 thanks, and regarding the ASA IsPowered() question? [15:16:51] astronauthen96__ do you usually have the CTD by 6 hours? [15:16:53] astronauthen96__ great! You are a few hours from MCC1 if you even need to burn it [15:16:55] no [15:17:08] it usually happens before the evasive maneuver [15:17:39] @rcflyinghokie i changed the resolution to 1 [15:18:17] i think ill skip it and burn mcc2 like they did in the real mission [15:20:22] rcflyinghokie, what was the ASA question? [15:22:05] i was actually thinking about flying apollo 10 with indys mcc updates [15:22:18] The ASA IsPowered function has a condition for the AGS power switch [15:22:34] is the AGS (AEA) comp light located beside the glycol pump selector, have anything to do with glycol? [15:22:35] ah, right [15:22:48] I thought the AEA power was switched by that not the ASA [15:23:03] AlexB_88 actually it is a glycol comp light [15:23:39] I believe the AEA sticker is there because if the glycol light comes on then your AGS cooling is compromised especially important warning in an abort situation [15:24:02] Since the temperature tolerances are small [15:24:44] both ASA and AEA are affected by the switch [15:25:24] see the comments at the top of LEM_ASA::TimeStep [15:31:44] Ah [15:31:46] Thats right [15:36:10] thank you @alexB_88 [15:37:02] is anyone flying apollo 10 right now? [15:37:21] yes [15:37:32] 5 minutes flying, 5 days development, 5 minutes flying etc. [15:37:57] only because I'm implementing the rendezvous calculations though :D [15:38:21] well i am going to get a sandwich from subway then i will start apollo 10 and see how your mcc's go [15:43:12] rcflyinghokie, just completed a complete activation of the latest LM state and made a list of the things that are not quite like the checklist (MA/CWEA behavior mostly) [15:43:23] and that list is already quite small [15:43:31] Haha fire away [15:43:39] wont be long [15:44:02] just finishing up something and I'll post it [15:47:32] Oh indy91, I got an ntdll.dll ctd last night, might have some useful info in it [15:47:49] https://www.dropbox.com/s/08pld8mz0k8gqm3/Screenshot%202018-03-20%2020.44.11.png?dl=0 [15:48:08] Could not reproduce it [15:48:18] when did that happen? [15:48:22] during loading a scenario? [15:48:23] Just loading a scn [15:48:26] ok [15:49:26] it might be a loading bug of one of the LM systems [15:51:42] I saw the des o2 down there [15:52:02] I don't think that means anything [15:52:06] "this" is the LM [15:52:42] and DesO2Tank is the first variable defined for it [15:52:47] a pointer [15:53:25] so basically, if you would look in memory how this object of the class LM looks like, the pointer DesO2Tank is at the beginning of the allocated memory for LEM [15:54:56] Ah so not helpful [15:55:26] more helpful would be the content of the line [15:58:33] but it's probably outside the scenario file [15:58:37] hence the access violation [16:05:29] I am confused about the ASA and the switch now [16:05:47] It looks like the 12V 28V and freq only get power from the breaker [16:05:50] Not the switch [16:06:03] Yet it needs to be in standby to start the gyro motors [16:07:34] rcflyinghokie, I have the list (not including the AGS and RR lights you guys are working on) [16:07:45] Sure fire away I will take a look [16:09:54] 1. RCS A/B REG warning lights: At 1st CWEA power up, they should come on according to the checklist. But in the sim right now, they only come on after the activation power-up CB config (with all the RCS cbs push in) and then after that recycling the MAIN SOV's and only after that do the 2 lights come on [16:10:49] however the checklist has those 2 lights come on at C&W checkout, before the power-ip cb config [16:10:58] power-up* [16:13:04] the question is, if that is a CWEA issue or a RCS simulation issue [16:13:08] 2. During initial CWEA power-up, the HEATER caution light should also come on, but doesn't [16:13:31] The logic in the CWEA code is the same as the handbook/AOH so I think it is the latter [16:14:23] "Disabled when main shutoff solenoid valves close." [16:15:02] Ah I dont think I have that part [16:15:12] oh wait, are the MAIN SOV supposed to be open before and through activation? [16:15:32] Oh yes I do [16:16:23] Yes they are [16:16:31] Its in the initial activation switches [16:16:46] ok well for some reason they close by themselves somewhere in early activation [16:17:00] I think they and the RCS quads start closed [16:17:08] yes [16:17:31] Yet the initial activation says they start open [16:18:11] I noticed the SOV's gray at initial LM entry, but somewhere they ended up closed, by the time I powered up CWEA [16:18:29] but I hadn't touched them. I'll investigate further [16:18:50] no, they aren't actually open [16:18:59] lack of a signal causes the TB to show grey [16:19:12] oh [16:20:05] so, maybe the valves are supposed to be open at launch [16:20:09] that can easily be changed [16:20:18] looks like it from the Systems Handbook [16:20:52] the primary interconnect valves are shown open prior to pressurization and the main SOV [16:21:03] I'll fix that [16:21:46] great [16:21:57] that would explain that then [16:22:04] 2. During initial CWEA power-up, the HEATER caution light should also come on, but doesn't [16:26:19] That is odd [16:26:43] The Sband and RR heaters are on during TLC [16:26:48] So they should be up to temp [16:27:06] must be lack of signal sensor power [16:27:50] hmm SIG SENSOR cb? [16:28:04] Those should all be closed before the CW check [16:28:08] yep [16:28:10] no [16:28:28] light is on, Activation Power Up, light is off [16:28:44] that's how it is in the Apollo 12 Activation Checklist [16:29:05] hmm, wait [16:29:08] ACT-21 [16:29:10] step 2 [16:29:29] HTR TEMP MONITOR - Cycle then LDG (Heater Lt - Off) [16:29:54] after setting the quads to auto [16:30:39] the heater temp monitor switch is resetting flip flops [16:30:51] ah [16:30:51] Yep [16:30:59] Those are implemented locally [16:31:21] locally? [16:31:25] those flip flops are probably set at any time previously, when the temperature was out of range [16:31:26] My local repo [16:31:30] ah right [16:32:06] Ok AGS warning has 12V 28V and freq [16:32:15] Now for this AEA test logic [16:32:25] i'm doing the activation right after LM ejection for my test [16:33:17] 3. During the power-up checklist after the power-up cb config, you check the FUEL & OXID VENT tb's. It says they should be gray, but they are bp in-sim [16:34:02] I'll check the power for those flags [16:34:04] might be wrong [16:35:23] DISP/ENG OVRD LOGIC CB [16:37:16] hmm [16:37:29] those TBs fail closed [16:37:39] that means without power they should show BP [16:37:44] right [16:37:59] so to be gray they should have power at that point [16:39:02] they have power [16:39:12] it's just after the CB is closed [16:39:25] but that would mean one of the vent valves is open [16:39:48] there is a set of explosive valves and a set of valves that can be opened and closed whenever you want [16:40:07] the TB shows the state of the non-explosive vent valves [16:40:17] Systems Handbook shows those closed at launch [16:41:43] and you wouldn't touch them before post landing I guess [16:42:11] maybe an error in the checklist [16:42:42] nope, Apollo 14 Activation Checklist says the same [16:46:26] I found a picture that confirms that those TBs show BP without power [16:46:54] Its funny our breaker panel still has AQS instead of AGS :P [16:50:10] I don't have an explanation for the vent TBs [16:50:17] 4. LDG GEAR DEPLOY-FIRE TB not gray before hitting the fire switch [16:50:33] in the checklist that tb is already gray before firing [16:50:58] can't be [16:51:07] where does it say that? [16:51:36] in the Apollo 12 activation checklist ACT-35 [16:51:56] it says, switch to Fire [16:51:59] and the it's gray [16:52:02] then* [16:52:29] hmm [16:52:41] no, that's right [16:52:46] you set it to fire twice [16:52:47] Yeah [16:52:52] once with ED A, and once with ED B [16:52:59] ah ok I see [16:53:08] you 2 it twice [16:53:12] yep [16:53:16] makes sense [16:53:54] morning! [16:54:16] er, if that didn't go through -- morning! [16:54:27] It did haha [16:54:28] 5. DES SUPCRIT PRESS indicates 400 PSI during DPS checkout, but it should be 750-1320 PSI [16:54:31] hey Mike [16:54:38] Lauren already sent me the two documents I requested yesterday [16:54:53] AlexB_88, which page? [16:54:55] hey Mike [16:55:01] ACT-53 [16:55:04] the GSE manual is a bit underwhelming but gave me lots of part numbers for Block I equipment to search for [16:56:46] AlexB_88, so, what I did there was use the SHe pressure at LM ejection [16:56:59] during TLC it warms up and increases in pressure all the time [16:57:06] the simulation of this is still missing [16:57:37] ah ok [16:57:39] so it's at a constant pressure [16:58:00] but the Luminary functional description and operation manual is incredible [16:58:01] something simple should be possible to be implemented [16:58:13] one of the best concentrations of how the system works from the LGC point of view that I've seen [16:58:18] oh great [16:58:33] we definitely need to get the Comanche 67 one too [16:59:41] and I think they have a Sundisk one that might be interesting [16:59:51] anything about padloads? [17:00:03] I don't think I saw anything [17:00:09] one sec, just uploaded them to drive [17:00:14] ok [17:00:19] GSE manual: https://drive.google.com/open?id=1kyciEWBtmnNQq7cnJa5ZJ2sZglIkaWi5 [17:00:34] Luminary manual: https://drive.google.com/open?id=1C4ll6VLKvQGcfAQWtRTaInbaIOByfCIL [17:01:22] it gets amusingly detailed at points -- for example, thanks to this document I now know the actuation force for DSKY keys [17:02:26] haha, wow [17:04:19] lots of procedural stuff, nice [17:05:56] good reference if I ever get confused about some routine and don't want to read the source code [17:06:32] yeah, it's great [17:14:23] So it doesnt look like the test mode fails when I cycle AGS power [17:14:48] Also I am trying to figure out what connection in the CWEA makes the MA come on when the switch is on standby but the AEA breaker is out [17:16:51] My changes so far... [17:16:52] https://github.com/dseagrav/NASSP/compare/Orbiter2016...rcflyinghokie:Orbiter2016 [17:33:10] hmm [17:33:15] not a fan of the GetASA12V() function [17:33:56] is the ASA actually accessing the SCEA? [17:34:17] if not, then there shouldn't be a call to the SCERA voltage there [17:36:17] can you explain again under which circumstances the ASA power supply generates the 12V? [17:42:56] Sorry had to take a call [17:43:38] The ASA is sending data to the SCEA which sends to the CWEA [17:43:45] And for the power generation, it is unclear [17:44:36] Looking at the instrumentation AGS diagram, the ASA breaker powers the voltage signals [17:45:09] But I am not sure what they actually measure in the ASA [17:45:17] And when they are powered [17:45:41] did you look at the power supply schematic in the Systems Handbook? [17:46:12] but in any case, there shouldn't be a call to the SCEA in ASA code [17:47:12] Well the temperature was an interesting thing [17:47:38] The temperature >150+-5 opens the 12V circuit [17:47:58] But that probably is handled internally isnt it [17:48:40] yeah, looks like that is in the ASA [17:48:46] Ok I can change that [17:48:50] just at the 12V output to the SCEA [17:49:12] As far as the power I had no idea if it was just the breaker or both breaker and switch, I think the latter [17:49:47] so "hsink->Temp()" or something like that? [17:50:22] I had a GetASATemp [17:50:33] Does exactly that [17:50:53] yeah, I guess the ASA can use that function internally as well [17:51:19] Now I think those conditions are all correct [17:51:35] I think the MA for the startup of the AGS is solely by the test signal [17:52:06] MA comes on when switched to standby and the ASA breaker is closed, AEA and AGS breakers open [17:52:18] Turns back off while in standby and AEA breaker closed [17:52:34] And back on when put in OPR with all the aforementioned breakers closed [17:52:55] And then a FF is reset [17:54:01] once the FF is reset, can that be reversed? [17:54:24] If one of the conditions comes back on [17:54:56] I have to go though I should be back this evening [17:55:03] Current state: [17:55:04] https://github.com/dseagrav/NASSP/compare/Orbiter2016...rcflyinghokie:Orbiter2016 [17:59:19] hows the rendezvous stuff coming along? [17:59:46] 19 seconds [18:00:22] with the initial guesses for time differences between phasing and insertion, and insertion and CSI the calculated TPI time is 19 seconds off during the very first iteration [18:00:44] so, pretty good [18:00:49] nice [18:09:31] do you have that MAIN SOV fix ready by any chance? [18:22:50] pushed [18:23:57] thanks [18:31:57] so in the Apollo 14 activation checklist, the HEATER caution light is not on at C&W checkout [18:33:26] and we are working with the Apollo 14 Systems Handbook [18:33:42] although, the Apollo Experience Report might help us implement an earlier CWEA version [18:34:31] https://www.hq.nasa.gov/alsj/tnD6845LMInstrumentation.pdf [18:34:55] that document has good info on CWEA logic changes from LM-3 through 5 [18:35:32] oh and would maybe explain why the ASC PRESS is not on either [18:36:14] Apollo 10 DOI Maneuver PAD finally done, haha [18:36:16] took a while :D [18:36:22] lol [18:36:33] CSI time was the tricky one [18:36:46] needed the whole rendezvous planned out [19:12:29] hmm I still have my descent batteries after staging [19:13:50] Ryan forgot to add a check on the stage in the SCEA [19:13:57] lem->Battery1->Voltage() [19:13:59] direct access [19:14:35] Haha I guess I got back in time to see that [19:15:57] oh and my CO2 goes full high after staging aswell [19:16:05] Should that check be in the SCEA or done differently [19:16:17] and also forgot cleanup of the old code for the DC meters [19:18:16] yeah, this needs a bunch more work [19:19:40] EPSMonitorSelectRotary [19:19:49] I just removed those [19:20:05] I thought I did before as well but I guess I didn't [19:20:50] I think you commented it out in some commit [19:21:00] must have reversed that at some point [19:21:36] there also is code in LEM_EDS for the switch [19:21:40] Yeah I commented out and I thought I deleted it after but yeah it reverted [19:22:05] our whole handling of the ascent/descent stage power connection is a bit messy [19:22:23] Shouldnt the batteries themselves be null? [19:22:41] At staging [19:23:21] no, they can't be deleted [19:23:48] This code in the EDS looks the same as the staging code in LM systems [19:24:16] yes, messys [19:24:18] messy [19:24:21] Indeed [19:25:25] we also have to consider the deadface switch [19:27:11] I am not well versed with that [19:28:41] more EPSMonitorSelectRotary in the code for the switch [19:30:03] searching through the whole code for instances where that switch is used might have been good [19:30:43] Doing it now [19:30:58] deleting all of it of course doesn't solve anything [19:32:16] we need new handling for this [19:33:42] hmm [19:33:56] so, when you set that switch to deadface [19:34:11] you might still get a voltage on the meter [19:34:51] deadface seems to just disconnect the ECAs from the bus feeds [19:35:00] batt feed* [19:36:08] It looks like it goes to the DC Bus Volts cb as well though from the deadface relay box [19:36:37] So i think deadfaced would not return a voltage [19:37:11] Ah thats for the bus never mind [19:37:27] Current comes from the tap on the battery [19:37:30] voltage* [19:38:02] Through the ECA I think [19:39:08] yeah [19:39:20] does it only to go the HV tap? [19:39:24] go to* [19:40:42] The comment says HV tap but that seems odd as they read voltages when on the LV taps [19:41:13] Unless it is bus voltage [19:42:05] No they look at the battery voltages when they are in LV [19:45:16] and is that actually LV voltage? [19:45:37] ah [19:45:38] yes [19:46:13] which might be wrong right now as well [19:46:22] LV voltage is created in the ECA code by us [19:47:05] http://moonpans.com/apollo_flown_items/a17-descent-schematic-big2.jpg [19:47:07] Looking in the AOH, the battery voltage is connected to the HV [19:50:59] So it always reads from the HV tap? [19:51:42] can't be [19:52:06] as you said, in the activation checklist they are checking each battery individually for voltage [19:52:15] and if the voltage is too low the HV tap is selected [19:52:22] if not too low that is done later [19:52:25] Yeah I know [19:52:33] I am just looking at the schematic [19:54:33] well, it's not super detailed in the AOH [19:54:37] might be a simplification [19:55:46] True [19:59:29] The VOLTS and AMPS indicators (panel 1 4 ) enable monitoring the terminal voltage and current [19:59:29] draw of each descent battery (high-voltage tap for voltage only) [19:59:32] From the AOH [19:59:52] ah, good find [20:00:06] and I was checking this Apollo 17 schematic [20:00:10] So maybe it was bus voltage <27 [20:00:15] batteries 2 and 3 don't even have a LV tap [20:00:55] and 1 and 4 don't have voltage monitoring even [20:01:07] this might be the J-Mission configuration [20:01:30] Yeah I think you are right [20:01:50] Apollo 15 activation also says to check the bus voltage [20:01:52] But the LM-8 handbook does support the HV tap [20:01:53] not each battery [20:02:06] yes [20:02:22] so, we are using the high voltage for the meter? [20:02:30] Yeah [20:02:35] that makes things easier, haha [20:02:36] and whatever the taps are at for the bus [20:02:54] yeah, that is already simulated correctly [20:03:00] Yep [20:03:13] so we just need to fix the meter displays [20:03:19] and the deadface switch code [20:04:18] Right, for the meters should the stage check be done in the scea? [20:04:50] Or should those batteries return nothing when staged and that data transmitted to the scea [20:08:27] what do you think, would the meters still show battery voltage/current when the deadface switch was used to disconnect the DES batteries? [20:09:05] It looks like the voltage data comes from the ECA [20:09:15] Which is before the deadface relay I believe [20:10:07] So if we are unstaged, even if deadfaced, you should return a voltage I believe [20:10:08] yeah [20:10:14] yeah [20:10:32] Staging should be the defining factor in returning battery voltage/current [20:12:02] the question is just where to put the stage condition [20:12:11] SCEA, LEM function, ECA [20:12:31] Where are those disconnects simulated? [20:13:03] Wherever those connections are severed (I would assume eds) would be a reasonable place to disconnect them [20:14:42] electric circuit interrupters right? [20:14:51] yeah, but we don't have that [20:15:11] there are two deadfaces. with the switch, which is reversable, and with the pyros, which is separating the stages for good [20:15:31] Well staging disconnects the ECA's [20:15:53] Whenever that is done for good, the batteries should be disconnected as well [20:16:12] Otherwise deadface shouldnt have any effect on the meter, just the bus [20:18:16] so i managed to get up to the first sleep period [20:18:36] Which also means that the deadfacing has no effect on the eps monitor rotary in that class [20:18:41] And those can be removed [20:18:49] yes, that anyway [20:18:56] the rotary class can also be changed [20:19:03] doesn't have to have sources attached to it anymore [20:19:15] it's just a dumb switch now, with the logic in the meter code, right? [20:19:22] Yes [20:19:22] ok, solution [20:19:28] LEM::CheckDescentStageSystems [20:19:34] add [20:19:35] Battery1->Disable(); [20:19:38] for the 4 batteries [20:19:43] astronauthen96__, and no CTD? [20:19:50] That would work well [20:20:00] disabling isn't saved [20:20:01] Would you also keep that in the pyro section? [20:20:05] nope [20:20:06] but that function is called every time [20:20:11] you load a scenario [20:20:16] usually this far i would have gotten one [20:20:20] so, it should always keep the battieres disabled [20:21:56] We also need to do that for pyro batteries correct? [20:22:15] I think those are in the descent stage [20:22:21] one of them [20:22:25] but of course i skipped mcc1 and didnt touch the rtcc mfd [20:22:45] astronauthen96__ you probably need MCC 2 ;) [20:22:59] yeah, very likely MCC-2 will be necessary [20:23:06] yeah that is what they did in the real mission [20:23:46] rcflyinghokie, so, the only reason to have any electrical code in the pyro section is because the descent stage is actually disconnected electrically first [20:23:58] and only then the stage is properly separated [20:23:59] thank you AlexB_88 [20:24:10] @AlexB_88 [20:24:34] So the bus disconnects can stay [20:24:39] yeah [20:24:42] it's redundant anyway [20:24:45] Yeah [20:24:50] CheckDescentStageSystems does it as well [20:24:52] just to be safe [20:25:01] I think this is a good solution [20:25:04] And disable pyroA in that? [20:25:13] hmm [20:25:29] are you asking because of the pyro voltage? [20:25:51] ED battery* [20:26:43] that was handled with a powered switch as well [20:26:44] EPSEDVoltSelect [20:26:56] Yeah [20:27:21] It should be handled the same as the descent batteries [20:27:27] disconnected/disabled [20:27:43] Real quick, I can replace PowerStateRotationalSwitch with RotationalSwitch [20:27:47] I would disable the battery the same way [20:27:49] yes [20:27:55] Ok [20:27:58] and if it complains, it needs more code cleanup [20:28:42] Is the battery just pyroA [20:29:06] haha, pyroA is just an intermediate variable [20:29:14] yeah i scrolled up and saw that [20:29:16] Not that simple [20:29:21] EDBatteryA [20:29:33] just disable it the same way as the DES batteries [20:29:52] in the check function [20:30:20] Ok lets see if anything complains [20:35:50] No errors or warnings [20:37:53] then, good job [20:38:22] Deadface switch isnt doing anything... [20:39:35] ASC ECA CONT CBs both need to be in [20:39:43] Ah [20:39:50] duh [20:39:56] although I am not sure that is correct [20:40:08] I don't know either [20:40:32] from the Systems Handbook it looks like either should work [20:40:40] oh wait [20:40:46] that's how it already works [20:40:52] astronauthen96__ N [20:40:52] lem->CDRAscECAContCB.Voltage() < 24 && lem->LMPAscECAContCB.Voltage() < 24 [20:41:04] that is the condition to do nothing [20:41:14] astronauthen96__ no problem! [20:41:20] so either will work right now [20:42:19] Great [20:42:22] That looks right [20:42:38] I still have voltage when deadfaced [20:42:40] Which is good [20:42:44] Lets see what staging does [20:43:20] Hm I have battery voltage [20:44:08] hmm [20:44:21] disable might just stop the battery timestep [20:44:25] checking [20:45:16] I think you are right [20:45:40] when an e_object is disabled it should always return 0 [20:46:08] Even for voltage? [20:47:05] hmm, not for overloaded voltage functions probably [20:47:19] but Battery doesn't overload Voltage, only Current [20:47:29] ah, no [20:47:34] it overloads them [20:47:49] I think we can do a small change to the battery code then [20:49:15] I'll quickly do that and push it [20:51:17] Ok [20:52:15] I cannot duplicate Alex's CO2 issue though [20:52:50] done [20:56:14] Building [21:01:12] I broke the ed volt switch somewhere [21:02:39] Ah found it [21:03:45] Lets see what this does [21:06:06] oh man I think it's happening -- just got CC'd on an email from the guy with the AC Electronics manuals to my contact at his local archive.org branch ^_^ [21:07:24] Block I here we come [21:07:34] \o/ [21:07:54] Very nice [21:08:02] indy91 everything works from what I can tell [21:08:10] great [21:08:19] We lose volts on bat 1-4 and ed A [21:08:23] when staged [21:08:36] yes [21:08:41] Now I need to get back to this AGS logic :( [21:08:59] AGS isn't so bad [21:09:02] RR is worse :D [21:09:05] True [21:09:13] Why do you think I chose to finish the AGS first :P [21:09:31] yes [21:09:40] Ok so I need to figure out why the MA comes on at certain parts of powerup [21:09:58] AEA power is off and AGS AC is off when it is switched to standby [21:10:03] triggers a MA [21:10:16] oh great now we have to make a block 1 CSM :D [21:10:27] light turns off when AEA breaker is put in [21:10:37] AlexB_88, get to work on the panel [21:10:53] Hey hey I need that strobe light first! [21:11:13] and the CSM still needs separate optics switches [21:11:30] i've been falling behind [21:11:36] And I need light up engine start/stop pb's [21:11:47] We could go on for a long time I am sure [21:12:34] and the temp monitor colour bands [21:13:08] That should be easy for me to do [21:13:25] indy91, any thoughts about my AGS caution? [21:13:44] more thoughts when I have done the research [21:13:52] Fair enough [21:14:18] I am guessing that the AEA breaker allows one or more of those ASA voltage signals to come through [21:14:42] And then the MA when the switch is moved to OPR I am guessing is an initial condition of the AEA test fail being set [21:15:11] I don't think it's the AEA test fail signal [21:15:22] that sets a flip flop [21:15:28] all the other inputs don't [21:15:41] and when pushing in the CB makes the light go out, then it can't be the FF [21:17:33] AOH Volume II has the answer [21:17:48] "AGS CWEA inhibit is removed and ASA voltage is low due to absence of AEA clock" [21:20:07] Thats when moved to standby [21:20:28] yes [21:20:34] Is that in the AGS section or CWEA [21:20:41] Actually, give me the page haha [21:20:45] AGS activation [21:20:48] page 315 [21:20:50] Thanks [21:20:57] AGS Power Up procedure rather [21:21:04] I didnt think to look at that [21:21:27] I remembered that the AOH Volume II is often checklist plus additional comments [21:21:34] Indeed [21:21:47] Ok, so which ASA voltage is low without the AEA breaker [21:23:36] Systems Handbook page 208 [21:23:48] ASA clock signal from the AEA goes into the ASA [21:23:59] to the 64 kHz puls generator [21:24:06] from there to a 8 kHz pulse generator [21:24:21] and then signals 20 and 26 go into the ASA power supply schematic [21:24:41] so I guess the answer is [21:24:43] all of them [21:24:56] Fair enough [21:25:13] I can make those need AEA DC power to generate [21:25:15] at least the 29V AC [21:25:21] 400 Hz [21:25:35] 29VAC 8 Hz isn't on the CWEA [21:25:44] No [21:25:45] and the DC to DC converter might be ok in general [21:25:56] so the 400 Hz is the suspect [21:26:53] Hmm but does the AC power there come from the AEA DC power source or the AGS AC power source [21:27:20] I would guess the DC because the AEA breaker clears the CW light [21:33:20] which AC power? [21:33:41] AGS AC breaker is only for FDAI I think [21:33:49] Ok that makes sense [21:37:33] DOI and Phasing PADs are done. Although I still don't know what "Phasing Delta" means [21:37:58] and for the PDI Abort PAD I have to simulate yet another rendezvous profile [21:37:59] hahaha [21:38:01] great [21:38:02] ... [21:39:08] Oh, to add on to that complicated list, is it possible to use those computations to generate the SV's for later missions like LM SV insertion+10m for the CSM? [21:40:20] that one isn't calculated [21:40:24] I don't think [21:40:28] it's downlinked from the LM [21:40:33] and directly uplinked again to the CSM [21:40:49] so, I might add a SV downlink option [21:40:52] for the MFD [21:40:57] and the RTCC in general [21:40:58] Even when the LM is on the surface? [21:41:04] oh [21:41:08] Thats what i mean [21:41:10] did they uplink that? [21:41:12] Yes [21:41:15] short profile? [21:41:26] Not sure [21:42:07] In the FP [21:42:22] "Uplink CMC nominal LM SV Insertion +18m" [21:42:28] Before liftoff [21:42:44] which mission? [21:42:44] Right after the V45 [21:42:45] 11 [21:42:48] uhh [21:43:15] I know you are doing 10, but thats why was wondering could those calculations be used for that [21:43:43] that seems more like a byproduct of the lunar liftoff time calculation [21:44:12] just checked Apollo 14, and there they definitely uplinked the state vector of just inserted LM to the CSM [21:44:16] but I don't know about earlier [21:44:20] so that is what I remembered [21:44:39] ah [21:44:42] same for Apollo 11 [21:44:56] but also earlier the nominal one [21:45:27] just so that the CMC has a state vector already, I guess [21:45:28] Yeah [21:45:42] Something to use as a reference for the rendezvous [21:45:54] yeah, that would come from the liftoff calculation [21:45:59] it also simulates the rendezvous [21:46:10] So that could be used for it [21:46:17] yes [21:46:23] I'll add that when I get to 11 [21:46:32] Sounds good [21:46:36] I'm trying to not skip any MCC update [21:46:51] and that is one of them [21:46:55] Its an unusual thing so I figured I would mention it [21:47:08] Rather something we cant do right now [21:48:46] yeah, difficult to calculate from scratch [21:48:52] Ok so when the AGS switch is put to operate, the warning light latches on due to core priming operation which interferes with program inhibit of hardware alarm [21:49:22] In other words the test mode fail is 1 when first switched to operate? [21:50:13] yes, that sounds like it [21:50:18] also because of "latches on" [21:50:19] the FF [21:50:42] does that work yet? [21:52:30] if not, then this might be something for the Virtual AGS [21:53:31] ducks [21:54:36] No its always reading zero [21:54:40] rcflyinghokie, I don't understand your logic with the FF [21:54:52] what sets it to 0 and what to 1? [21:55:26] and where [21:55:34] I have changed it locally, it is set to 0 when the test mode fails and 1 when the quantity rotary is on reset [21:55:52] so 0 = set and 1 = reset? [21:55:55] why like that? [21:56:26] Just copied over from water warning [21:56:54] No particular reason but 1 should be set [21:56:58] yes [21:57:10] let's not make it more confusing than it is anyway [21:57:58] and how did the water warning get this logic? [21:58:22] It was alreadyt here [21:58:37] That FF was there before I even started the CWEA [21:58:44] yeah [21:58:49] it even is like that in 7.0 [21:58:53] weird [21:59:57] Seems to work right though [21:59:59] ah, the variable name is "disabled" [22:00:21] but the state of the FF as in the Systems Handbook is set = enabled, reset = disabled [22:00:33] so it's just a variable name thing [22:00:42] Well now set is 1 and reset is 0 [22:00:52] To make more sense with naming [22:01:13] ah, you changed the name of it [22:01:21] then the logic should also be changed, right [22:01:50] Yep it has been [22:02:29] I'm still not sure where the AGS FF is ever set to 0 [22:02:31] or 1 [22:02:45] changed into one state with the QtyMonRotary [22:02:51] but the other state? [22:02:54] is that code somewhere else? [22:06:11] I have it currently that if the AEA test mode fail signal is sent that the FF gets set, unless it should be set whenever the rotary is not in reset? [22:07:34] where is that code? [22:07:53] I'll push it its all local [22:08:06] is in in CWEA code? That is what I meant [22:08:13] Yes [22:08:31] ok [22:08:54] and I guess you monitored the output discrete from the AEA directly, I saw the debug string [22:09:02] so definitely no spurious test fail signal [22:09:16] which might be all that happens there when the AEA is turned on [22:09:27] but enough to set the FF [22:10:12] According to the AOH, the warning light latches on due to core priming operation which interferes with program inhibit of hardware alarm [22:10:13] the actual AEA initial state is as the AOH says [22:10:30] only sends out an engine off signal [22:10:52] not test fail [22:11:11] so the test fail must be on for a very short time during that core priming thing [22:11:21] Just enough to trigger the CWEA [22:11:25] yeah [22:11:40] I guess that isn't simulated by the Virtual AGS [22:12:28] Here is the current comparison [22:12:29] https://github.com/dseagrav/NASSP/compare/Orbiter2016...rcflyinghokie:Orbiter2016 [22:14:07] I still don't like the logic, haha [22:14:15] I dont either because somethings wrong [22:14:23] let's say the FF is set [22:14:28] AGS light is lit [22:14:30] and then you switch the AGS to Off [22:15:06] hmm [22:15:08] no [22:15:24] Well this logic is assuming the test fail sets the FF [22:16:53] AGSWarnFF != 0 [22:16:57] then [22:16:59] AGSWarnFF =1; [22:17:10] of it is 0, then this can never happen [22:17:12] if* [22:17:45] it might be better if you take this logic gate by gate [22:19:04] or else it gets [22:19:05] messy [22:19:53] Ok [22:20:01] also separate FF logic from light logic [22:20:18] interwining them only creates issues [22:20:27] intertwining* [22:21:15] so FF logic first, then the light logic [22:21:32] and then you can use the FF as a logical element for the light [22:23:04] you'll figure it out [22:23:08] good night! [22:25:55] weird stuff that AGS light eh [22:29:46] Yeah [22:29:55] Back to a logic gate problem [22:30:54] I could not duplicate your CO2 issue btw [22:32:10] may have been procedural error on my part [22:32:50] I have never seen it go off scale high haha [22:32:58] Only in the initial testing [22:33:25] Unless it was a time accel glitch which the ecs and glycol still get [22:33:32] They fluctuate a lot [22:33:43] well I said of scale but really meant up near the top but not all the way [22:34:12] Still I never had it happen [22:34:20] Was it slow or abrupt [22:34:39] I'd say abrupt [22:34:54] it was after staging [22:34:58] Very odd indeed [22:35:07] I tried a bunch of staging today never had it happen [22:50:22] with your latest repo the AGS light seems to be on all the time...I guess it is still in progress [22:51:13] AGS is just feeling lonely and wants some attention [22:52:19] haha [23:11:52] Yeah I know why [23:12:02] Took me WAY too long to find that [23:12:06] Wrong scera [23:21:05] I think I have the correct behavior [23:21:47] I just cannot test the MA turning on when moved from stby to opr because I do not have a transient AEA test fail [23:22:33] right [23:22:49] because its not simulated in VAGS you guys were saying? [23:23:30] Right [23:23:48] But I think I have the other failures and the flip flop correct [23:24:46] Also your DES bats should be disconnected now at staging as well as the ED Bat A [23:27:51] Lets see if it works [23:35:11] Now what i dont know is if the FF is set whenever not in reset [23:35:17] Or if it is set by the conditions [23:52:07] Also need to figure out if the FF's are set or reset by default [23:53:28] But the current state should work for now [23:54:13] Let me know if you find any other issues [23:56:26] works good in the latest update [23:58:12] I just hope the FF treatment is correct [23:58:39] Dinner time [00:56:06] yep AGS behavior is exactly as per power-up checklist now :) [01:05:58] btw I am getting the MA turn on when moving from stby to opr like the checklist says [01:06:55] and then C/W RESET clears it [01:34:48] night [12:03:14] hey indy [12:03:41] so i forgot to save did the tli and docking about 5 times with no problems then i used the rtcc and then got a ctd [12:03:42] hey [12:04:12] ok, I want this confirmed. When did you get a CTD exactly? [12:04:19] When you pressed a button? [12:04:22] yeah [12:04:23] on the MFD [12:04:26] which one [12:04:28] yes the rtcc [12:04:35] CLC? [12:04:36] very strange [12:04:39] yeah [12:04:43] or any button i think [12:05:14] if it was only the calculation (CLC) button, then it could also be a RTCC MFD bug or a user error [12:05:24] but it sounds more like a general MFD issue [12:05:29] i dont have the apollo 8 flight plan with me but do you know the get for when mcc7 is supposed to take place because i want to try to make a calculation with the rtcc to see if i get a ctd [12:06:07] is this only happening with the RTCC MFD? Have you gotten a CTD with any other MFD? [12:06:13] nope [12:06:16] hmm [12:06:26] i mainly use the project apollo mfd for killing rotation [12:06:30] right [12:07:08] i know rc and alex are flying missions but i don't know if their using the rtcc [12:07:12] Apollo 8 MCC-7 is at 2 hours before reentry [12:07:22] nominal time is 144:45 [12:07:24] roughly [12:07:28] okay [12:07:44] I am sure RC and Alex are using the RTCC MFD a lot [12:08:20] but they don't get ctd's when using it though [12:08:21] is the RTCC MFD bug the ntdll one or however it is called? [12:08:26] issue* [12:08:35] did you debug that one yet? [12:08:39] the ntdll happens after using it [12:08:51] all of my errors are ntdll [12:08:55] ok [12:09:03] access violation it seems [12:14:59] got it [12:15:17] a ctd in apollo 8 [12:15:26] with the rtcc same error ntdll [12:15:42] c0000005 access violation [12:18:49] what were your exact steps [12:19:02] i kept pressing calc and switching panels [12:19:08] ok [12:19:25] and that only causes a CTD with the RTCC MFD open? [12:19:55] well, if there is a calculation i don't know if simply having it open causes it [12:20:58] but all your inputs for the calculation were valid, right? [12:21:15] for MCC-7 it shouldn't take long at all to do the calculation [12:22:10] i just inputted the tig [12:22:22] what about a splashdown longitude? [12:22:33] nothing [12:22:49] well, that is no good [12:23:02] it would try to land at 0° longitude then probably [12:23:17] or did you choose the mid pacific option? [12:23:19] but it even does it with the evasive maneuver pad [12:23:46] where you manually input TIG and DV, right? [12:23:50] yes [12:24:35] the Maneuver PAD calculation should be instantly. In that case you can't do the panel switching while it calculates, right? [12:24:49] it just happens when you press CLC? [12:24:59] after a calculation is done [12:25:02] ok [12:25:17] are you trying it now [12:25:18] so evasive maneuver PAD calculation and then panel switching? [12:25:37] yes [12:25:39] not directly, I am looking for any general RTCC MFD issues [12:25:52] i press calc more than once [12:26:05] ok [12:26:07] why? :D [12:26:11] not sure [12:26:32] maybe it's not a system issue [12:27:02] at least i hope not [12:28:28] pressing CLC once starts the calculation, usually as a thread [12:28:41] which basically means, even if the calculation runs into issues, there can't be a CTD [12:28:51] pressing CLC once again stops the thread [12:28:57] again, for most calculations, not all [12:29:13] so maybe it's a threading issue [12:29:51] last night i got a ctd with apollo 10 right after the first three mcc updates sorry i forgot to tell you that [12:30:25] so a CTD without using the RTCC MFD? [12:30:33] yeah [12:30:35] when did it happen? Was it after the TLI PAD? [12:30:39] yes [12:30:45] same error ntdll [12:32:07] hmm [12:32:09] very weird [12:33:37] but i seem to be the only one who is getting it [12:34:18] oh, I found something interesting [12:34:43] in the threading thing? [12:35:02] yeah, I actually think that is done by ntdll [12:35:58] hey alex [12:36:09] i think were getting somewhere on my ctd's [12:36:18] and the source code file that contains CreateThread is different in Windows 7 and later [12:36:31] so maybe it's a Windows API incompatibility [12:36:45] do you think it can be fixed potentially? [12:37:13] hey [12:37:17] hey Alex [12:37:28] yes, maybe, have to do a bit of research [12:37:56] so CTD's so far, astronauthen96__? [12:38:01] astronauthen96__, do you have a 32bit or 64bit system? [12:38:06] 64 [12:38:11] ok [12:38:15] yes alex [12:38:22] it seems to be a threading issue [12:39:38] well, potentially [12:41:46] can you check something for me? [12:41:55] open visual studio installer [12:42:17] yes [12:42:30] okay [12:42:39] me? [12:42:53] yes [12:42:59] its open [12:43:04] mine wants to update itself right now [12:43:12] ok, done [12:43:17] almost... [12:44:08] I have the German version, go to more(?) and change in the drop down menu [12:44:28] the drop down menu also should have the options repair etc. [12:44:31] you mean repair? [12:44:32] yes [12:44:42] yeah, don't click repair [12:44:46] okay [12:44:58] what are your options there? [12:45:06] repair and uninstall [12:45:18] uhh [12:45:19] for visual studio community [12:45:21] yeah [12:45:34] I have repair, uninstall and a 3rd one [12:45:41] I wanted you to check that 3rd one [12:45:59] what is the third one? [12:46:49] well, "change install" or something like that [12:47:08] I want you to look at the individual components installed with Visual Studio [12:47:09] there is a modify option next to the launch button [12:47:11] have you seen that menu? [12:47:14] ah, yes [12:47:15] modify [12:47:40] i have desktop development with c++ [12:47:40] and then, invidual components or so? [12:47:45] yes [12:47:53] now you should have a long list [12:47:59] yep [12:48:14] almost at the bottom [12:48:20] do you have Windows 8.1 SDK installed? [12:48:30] yes rc told me to get that [12:48:36] hmm, ok [12:49:03] haha, I don't even have that installed [12:49:10] but multiple Windows 10 SDK versions [12:49:36] yeah, that was my idea [12:49:46] that you maybe didn't have the 8.1 SDK [12:49:50] so it's not that [12:50:15] although, have you actually built NASSP with Visual Studio yet? [12:50:29] what does that mean? [12:50:43] do you use the Github builds of NASSP? [12:50:51] i download them manually [12:50:56] ok [12:51:17] all the developers are using Visual Studio to build the NASSP dlls from the source code [12:51:40] what I wonder is, if the auto builds for Github are somehow incompatible with Windows 7 [12:52:02] hmm, maybe [12:53:07] btw indy91, I think we got the AGS warning light behavior solved last night [12:53:20] by auto builds do you mean the ones from the meadville space centre? [12:53:44] BuildBot posts the links on the forum, yes [12:53:57] those files are hosted on Github though [12:54:07] https://github.com/dseagrav/NASSP/releases [12:54:19] AlexB_88, very nice [12:54:28] and what is the source code used for? [12:55:09] so that you can build the NASSP modules yourself and don't rely on the releases [12:56:24] so do you think it might work on windows 8.1 [12:58:25] oh please dont install windows 8.1 :D [12:58:51] i wont i was just checking the prices i think im gonna get windows 10 for sure [12:59:11] haha just joking of course, I have had such misery with that version [13:00:39] we are using the Windows 8.1 SDK for NASSP, that's all. Works with Windows 10 no problem. [13:00:56] although, we could change that to Windows 10, probably [13:00:59] okay [13:01:05] i might even buy it today [13:02:32] I'm not saying you should get Windows 10 just for NASSP, but it's quite likely that you won't get the same issues with it [13:02:52] no i was planning on getting it even before i started using nassp [13:02:57] right [13:03:39] The AGS self-test fail function seems to light up the AGS warning light correctly when going from stby to opr, and then resetting it with the C/W RESET [13:04:03] are you using windows 10 pro or does it matter [13:04:12] also, you can force a self test fail with 412+3 and that will also light up the warning light [13:05:01] I have Windows 10 Pro, no idea about version differences [13:05:23] AlexB_88, wait, so the output bit is actually already set when switching on the AGS? [13:05:34] without a Virtual AGS change? [13:06:05] I got lucky with my Windows versions, because Microsoft allowed upgrades. [13:06:14] looks like it yes [13:06:17] As a student I was able to get every Windows version for free, but just once [13:06:31] do you think it would also affect the performance? it run very smoothly on windows 7 [13:06:34] so I got Win 7 on my old laptop and ran it until the laptop died [13:06:52] then I got a new laptop and got Windows 8, since upgrades through 8.1 to 10 [13:06:58] but seems like it only does it when 1st switching on the AGS for the 1st time (the momentary self-test fail) [13:07:07] and I also got 8.1 for free because it's a separate version from 8.0 :D [13:07:30] all upgraded to Win 10 by now [13:07:37] in the period when that was possible for free [13:07:53] and then after that it wont do the self test fail thing if you then afterwards, re-switch off the AGS and back on [13:07:56] ah, so only the very first switching on [13:08:01] looks like it [13:08:02] right [13:08:05] so would the frame rates be about the same? [13:08:20] guess you and Ryan tested with a powered up AGS that you just switched off [13:08:21] but of course you can force it with 412+3 and that light it up anytime [13:08:22] so all good [13:08:28] guess i might find out today [13:08:30] astronauthen96__, I don't know [13:08:31] yes [13:08:53] if your PC is good enough to run Windows 10 then there shouldn't be much of a difference for Orbiter and NASSP [13:09:31] I have been testing lots with a pre LM-ejection scenario and then quickly powering up and than doing the AGS power-up (1st) which is where I noticed that [13:09:39] okay [13:11:05] This is just the behavior I notice right now though I haven't check in the manuals if that is correct (only doing it at 1st power-up) or just a side-effect in our sim [13:11:54] no, I think it's quite likely the correct behavior [13:12:07] yeah, what I think too [13:12:12] I'll check the lunar surface checklists [13:14:08] hmm [13:14:20] for the Apollo 12 power up on the surface [13:14:28] I think the switch stays in standby [13:14:32] and then [13:14:34] CB closed [13:14:39] AGS STATUS - OPERATE [13:14:46] (AGS Warn Lt-On) [13:14:59] hmm [13:15:11] loosing power might not be properly simulated [13:15:17] for the AEA memory [13:15:31] ah [13:15:45] it just stops doing cylces [13:15:50] right [13:15:56] but I bet there are some side effects to removing power [13:16:11] which, probably should be partially simulated by NASSP, partially by the Virtual AGS [13:18:42] on another note, on my latest scenarios with a fully powered up LM, if I reload a quicksave, the ECS casution is on and H20 SEP comp light on [13:19:09] and then 2 minutes later they go out, so looks like the sate of the H2O sep seems to not be saved [13:21:18] ah, very possible [13:21:27] I think Ryan added some logic to it [13:21:38] which just might need save and load functions [13:21:45] I had the same thing with those lights [13:23:24] yeah, the water separator doesn't even have save/load functions [13:23:26] I'll add that [13:23:50] thanks [13:24:48] oh and according to the activation checklist, when you push in the LGC/DSKY breaker, the MA should come on. Could that be some kind of self-test logic as the AGS does at power-up? [13:25:26] maybe the LGC light logic needs work [13:26:08] I'll dig for some info on that [13:28:32] I've worked on the Apollo 10 PDI abort a bit, it's fairly easy [13:28:46] horizontal phasing maneuver at nominal PDI time [13:28:55] half a rev later, horizontal height maneuver [13:29:09] half a rev later, coelliptic maneuver (CDH) [13:29:24] all leading to a TPI that is about 1 rev earlier than with the nominal profile [13:29:37] I can reuse a lot of Skylab rendezvous calculations for this [13:31:04] great stuff [13:31:13] I wonder if the PDI+12 maneuvers for later missions also work like this [13:32:12] is all that the timeline they actually flew, or another separate abort? [13:32:13] nope [13:32:36] nope to the "No PDI+12" maneuver being the same [13:32:54] right [13:32:56] Apollo 10 got a Maneuver PAD for the PDI abort, but that is not the profile that was flown [13:33:35] the actual profile is with insertion maneuver placed so that the general profile is like from a lunar liftoff [13:33:49] and if you did that Abort, then would you get a maneuver pad for the "horizontal height maneuver"? [13:34:04] https://history.nasa.gov/afj/ap10fj/pdf/19700026734_mission-f-csm-rendezvous-procedures-19690429.pdf [13:34:12] or could you do that one onboard? [13:34:29] the CSM rendezvous procedures document has all the abort cases for LM and CSM active [13:34:33] let me check [13:35:00] the height maneuver can be calculated with P32 [13:35:33] just the phasing maneuver (PDI abort) not [13:35:51] right [13:36:23] and I'll add support for a ground calculated height maneuver PAD eventually [13:36:38] but you basically have multiple abort options, which requires some additions to the CAPCOM menu [13:36:57] for now I'll just support the nominal rendezvous profile, but with every PAD the crew got [13:37:05] and the PDI Abort is one they got, but not flew [13:37:25] makes sense [13:38:07] so if you fly the abort, you just have to turn off MCC [13:38:40] yeah, basically [13:38:50] CSI and TPI times are on the Maneuver PAD for the PDI abort [13:39:08] so you got everything you need for an onboard calculated rendezvous [13:39:29] nice [13:40:00] and then after rendez-vous, fly home "RTCC MFD style" [13:40:40] I guess [13:40:55] when the MCC supports it, it will return to the nominal timeline [13:41:02] right [13:41:04] so just go the MCC state after rendezvous [13:41:07] go to* [13:43:28] hmm maybe you push the abort button in MCC menu, then it simply waits until it detects docking then sequences to post rendez-vous timeline [13:44:31] just an thought of course [13:49:41] so after a year of thinking i finally bought windows 10 [13:50:22] hello rc [13:51:56] hey Ryan [13:52:01] @rcflyinghokie my ctd's are most likely being cause by the rtcc mfd [13:52:13] Hey good morning [13:54:09] rcflyinghokie, I don't know if you saw my message yesterday but the AGS self test fail thing seems to be working with the AGS light [13:55:18] Hmm [13:55:24] Really [13:55:46] yep, but only at AGS 1st power up [13:56:19] I have been testing with a LM ejection scenario so it worked for me as I was powering up AGS for the 1st time [13:56:43] you can also test it by forcing a self-test fail with a 412+3 [13:57:26] I guess I was testing on a situation where I shut it down and fired it back up [13:57:33] yeah [13:57:37] Even better then [13:57:53] Means something in the logic flow is finally correct :P [13:58:55] Although we think that something is still not right as according to procedures, it should do the self-test fail thing at every power-up, not just 1st, but that it is an issue of the vAGS [13:59:25] Niklas thinks its that the AGS is not properly powered down when we pull the breaker [13:59:43] so that it doesn't actually power-down [14:00:07] and hence doesn't give the warning when going back to opr [14:00:23] more like, the AEA memory isn't put into a powerless state [14:00:29] although I am not quite sure how that works [14:00:56] and it's not the RTCC MFD causing the issues, it's the threading of RTCC calculations that I think is the issue [14:01:03] both MCC and RTCC MFD use that [14:01:26] and astronauthen96__ got a CTD in the Apollo 10 MCC scenario after getting the TLI PAD [14:01:31] no RTCC MFD in that case [14:01:36] but calculation threads [14:03:31] and even in apollo 8 [14:04:46] rcflyinghokie, is the RR caution light logic still broken? [14:04:59] Yeah I haven't gone back to it yet [14:05:17] indy91, should all the flip flops be initialized as set or reset? [14:12:33] @indy91 best thing i can do now is to save then calculate a pad then copy it then reload until windows 10 comes tonight or tomorrow [14:18:31] rcflyinghokie, reset [14:18:46] Ok good [14:18:47] actually i am about to download it never mind [14:20:51] should it be 32 bit or 64 [14:21:47] You want 64 [14:22:00] yeah it comes with both [14:23:11] so i am a bit confused can i just install this or do i have to burn it to a disc https://www.staples.ca/en/Microsoft-Windows-10-Home-32-64-bit-English-Download/product_1832606_1-CA_1_20001 [14:23:55] you can install it directly, because you have Windows 7 [14:24:01] okay [14:24:10] That gives you the option to do a clean install or save your files [14:24:23] Personally, I think it is messy to "upgrade" if that makes sense [14:24:30] yeah [14:24:32] Leaves too many old files handing around [14:24:34] better do a clean install [14:24:36] hanging* [14:24:45] Just make sure you backup everything [14:24:54] so i have some pre tli and pre launch scenarios for apollo 11 that are from about a month ago will those need to be updated? [14:25:07] another way is using the windows 10 media creation tool: https://www.microsoft.com/en-ca/software-download/windows10 [14:25:08] Also when you get to the choose a disk to install screen, delete all old partitions on the drive [14:25:29] Alex can you use the media creation tool for 10 if you do not have 10 installed? [14:25:53] I just did that to put my windows on my laptops new ssd but I had windows 10 previously on there [14:26:35] i dont have very much important stuff so i don't think i will need to back anything up [14:26:46] hmm I think you can, you just need to give it a valid actiavtion number I think [14:27:30] I use the media creation tool to create a USB key with it, then do a clean install by booting the PC from the USB key [14:28:03] Yea thats what I did [14:28:08] and the advantage of the media creation tool is you get all the latest updates [14:28:09] Works very well [14:28:42] i am a bit confused i have an 8g flashdrive would that work [14:28:46] And since my laptop was new, I made an HP recovery media disc for it and just reformatted the hard drive completely [14:28:51] 8g might not be big enough [14:29:03] It will tell you when you start it though [14:29:24] https://www.microsoft.com/en-us/software-download/windows10 [14:29:34] click the download tool link [14:30:28] requirements are "A blank USB flash drive with at least 8GB of space" [14:31:55] fun fact, a double layer DVD is just too small for Windows 10 since the fall update [14:32:16] I didn't have the right USB stick, so I had to find an older Windows 10 version to install on the DVD [14:32:53] I cannot remember how much space it wanted for mine, but I used a 16GB stick anyways [14:35:21] rcflyinghokie, another ECS thing, My glycol pump 1 cb is closed and I have glycol selector to pump 1 but the light isn't going out [14:35:35] despite normal glycol temp/press [14:37:00] The comp light? [14:37:30] yes [14:37:46] That uses some pressure switch code [14:39:16] Give me one second [14:40:47] It might take a little [14:42:22] It is using the pressure difference on either side of the pump [14:48:36] AlexB_88, I'll push the water separator saving/loading shortly [14:48:41] thanks [14:48:47] don't have much time to test it, but you can do that I hope [14:49:14] rcflyinghokie, so the comp light should go out after a little while with the pump on? [14:49:21] indy91, sure [14:50:51] so i am going to order it in a few minutes [14:51:03] i am not getting just for nassp but i am still a bit nervous [14:51:23] My light usually goes off after a few seconds [14:51:51] me too, but it seems to go back on after, with the needle in the center of the green band [14:52:16] Needle only hits the center of the band due to timestep issues when switching panels [14:52:21] Also turns the light on [14:52:29] Did you switch panels a lot? [14:53:12] me? [14:53:47] Alex [14:54:13] astronauthen96__ we are discussing about the glycol light behavior in the LM. Good luck with your Windows 10 purchase [14:54:30] rcflyinghokie, hmm I did switch panels a bit [14:54:38] Yeah thats probably why [14:54:46] thank you [14:54:54] If the pressure increased a lot then the system will take a while to settle back down [14:54:59] but pump 2 behavior is fine though [14:56:16] i will talk to you guys later [14:56:20] The light doesnt look at pump 2 failure I don't think [14:56:50] goodbyer [14:57:33] actually id does, if I pull the pump 2 cb, the light comes on [14:57:47] Thats from the dP switch I bet [14:58:23] ah yes [14:59:12] suit fan dP? [14:59:24] No glycol pump dP switch [14:59:31] oh lol right [14:59:32] Not a panel switch [14:59:40] A sensor switch internally [15:01:28] hmm now I have my selector to pump 1 and I pulled the pump 1 cb, but the comp light is out [15:01:52] shouldnt that sense a failure of pump 1 and turn on the comp light? [15:02:10] Is auto transfer in? [15:02:32] I pulled it for the test [15:03:17] its like if the logic is reversed because the light is out when the pump 1 cb is out [15:03:26] the auto transfer latch might still be set [15:03:29] possible at least [15:03:46] Also you may have some weird pressures in your tanks still [15:03:57] If your pressure was that high after panel switching [15:05:27] indy91, for the water and oxygen flip flops, should I make 3 for each? Or just use one that acts as all three? [15:05:35] ok I am making a simple test, I only closed the pump 1 cb, left the other 2 cb's out. Now Ill select pump 1 and wait without time accel or panel switching [15:06:04] Put your suit temp to full hot, it will help the pressure equalize faster [15:06:10] ok [15:06:29] rcflyinghokie, probably all 3 [15:06:31] Ok [15:07:53] rcflyinghokie, the pump 1 pressure is not high btw, its below the green band [15:08:16] Ok then the light should come on [15:08:22] right [15:08:26] its on now [15:08:45] Now close pump 1 cb [15:09:01] its been closed for a few minutes now [15:09:07] with the pump selected to 1 [15:09:24] Light still on? [15:09:34] yes [15:09:40] Can i get a scn? [15:09:48] sure [15:10:18] https://www.dropbox.com/s/oz42jqp2s2u342h/Apollo%2012%20-%20Before%20LM%20ejection%200010%200002.scn?dl=0 [15:12:29] The pump doesnt seem to be turning on [15:12:47] yeah thats what I found weird [15:14:24] Auto transfer I think was still latched [15:14:28] I cycled that breaker [15:14:43] And it came up [15:14:57] Working normally now [15:15:18] hmm not on my end [15:15:54] Close all three breakers [15:16:16] Move the switch to pump 2 [15:16:54] That will unlatch the relay I believe [15:17:08] Then back up to pump one and pull auto transfer [15:17:29] ok yeah I see [15:21:42] complaints to Grumman, not me [15:21:48] Indeed [15:21:56] Everything is working as advertised [15:22:07] Thats also why the glycol pump procedure is the way it is [15:23:10] hmm its just that the pump selected back to one after doing that, the light seems to come back on in some cases [15:25:09] cya in a few hours [15:27:35] With auto transfer open? [15:31:48] ah with it open, pump 1 stays on [15:35:45] Yeah [15:35:46] but the glycol pump check in the activation check still doesnt agree with what happens in-sim for some reason [15:35:53] Which part? [15:36:06] ACT-27 [15:36:18] I mean which part of the procedure [15:36:41] ECS GLYCOL PUMP 1 - OPEN (M.A, ECS caution lt - On Momentarily [15:36:54] the MA and the ECS caution dont do anything [15:37:21] Is your ECS light on already when you start? [15:38:34] no [15:39:14] I think it is supposed to auto-xfer and that turns the ECS light on momentarily [15:39:28] Oh right [15:39:38] Yeah it happens too fast I think for the light to pop on [15:39:45] but pulling the breaker, I hear nothing, and by the time im back on the main panel to check, all lights are out [15:39:51] right [15:40:12] Realistically there is a lag between the pressure switch and the auto transfer relay latching [15:40:15] maybe putting a delay in the code? [15:40:32] Would have to ask Niklas about that [15:40:39] He wrote that section [15:41:12] I would imagine it would be simple though [15:42:26] Actually that is weird [15:42:38] later in that check it says select pump 2, then you get comp light on and off [15:42:45] Well that one is simple [15:43:00] You would have to cycle through the not working pump 1 to get to 2 in the real LM [15:43:01] but the light doesnt do that in-sim [15:43:09] so maybe a delay there too [15:43:20] No a delay wouldnt fix that [15:43:30] Only making the rotary switches work properly would [15:43:50] In other words you cant go directly from SEC to Pump 2 on the real switch if that makes sense [15:44:01] Where as we can in the sim [15:44:41] One thing I don't get though is that first part [15:44:57] Nothing about pulling that breaker for pump 1 should trigger the MA [15:45:24] The only two things that turn on the MA from the glycol light are low quantity and high temperature [15:48:09] does pump 2 action the MA? [15:48:50] No' [15:49:03] Only low level or temp in the primary loop [15:49:15] Oh wait [15:49:17] Sorry [15:49:21] Thats all the glycol light [15:49:28] The ECS light has other indications [15:49:39] If either pumps detect a failure [15:49:56] And that might be where a delay is needed [15:50:48] hmm doesnt seem to work with pump 1, I pull the cb with pump 1 running, the compl light comes on, but no ECS light [15:51:39] the same, but with pump 2, does work though [15:55:32] Let me try [16:00:27] Waiting for the water sep... [16:02:15] Ok pulling pump 1 cb the auto transfer happens faster than the light can detect a failure [16:02:35] right [16:03:11] Ah i see [16:03:20] The light doesnt come on until you reclose the breaker [16:03:37] So thats an issue in Niklas's code [16:03:42] ah yes [16:04:03] The comp light should be off but that ECS light should come on when it is pulled I think [16:07:05] yes I think that your description makes sense [16:07:21] bad Niklas :p [16:08:08] Yeah there are conditions in here involving the breakers [16:08:37] it wouldnt be in this line by any chance? [16:08:38] if (lem->scera2.GetSwitch(12, 2)->IsClosed()) { lightlogic = true; } //Coolant pump 1 failure [16:09:18] Yeah [16:09:39] In order fot that to close in the code the breaker has to be in which doesnt make sense [16:09:43] for that* [16:10:19] I think this might need some work to work properly [16:10:58] in the code, the that switch closes if (GlycolAutoTransferRelay && glycolRotary->GetState() == 1 && glycolPump1CB->IsPowered()) [16:11:17] I am not sure if that is correct [16:13:36] No it looks like it does need that cb in to close the switch [16:13:46] I am not certain right now haha [16:13:53] Niklas knows that code better than I [16:14:09] yeah [16:15:22] btw I'd like to merge to your latest repo, but could you any chance merge in Niklas's water sep save code? [16:15:38] I'd like to test all that [16:17:42] Yeah I just need to check the last bit of FF code [16:18:07] Should be up to date now though [16:18:43] thanks [16:18:50] I mean now [16:18:54] Sorry haha found an error [16:23:02] about the selector skipping the pump 1 position when going from sec to pump 2, one way to fix that is to change the switch type from rotary to 3-way [16:23:24] 3-position* [16:23:41] Yeah we talked about that [16:23:59] That would not work though [16:24:09] You can still click a 3 way from position 0 to 2 [16:24:14] Without going through 1 [16:24:20] Take the inverter switch [16:24:39] The reason you close both INV cbs before switching it from off to 2 is you have to go through 1 [16:25:15] hmm I cant go to 2 on the inverter without going through 1 [16:26:49] Oh really? [16:27:03] Maybe I was wrong then [16:27:23] You are correct! [16:27:49] I think the better option for realism though would be to change the rotary switch behavior in general [16:28:03] Thats why, for example, the cw test has an off on either side [16:28:11] So you can take it from one side to the other [16:28:18] Without going back through [16:28:34] yeah [16:30:09] I mean I am cool with that [16:30:19] I just don't know how to do it safely off hand [16:31:09] ok in the latest state, if I go to C/W reset, I get a perpetual MA that I cant stop [16:31:19] Lets see.. [16:33:04] That means a FF is not being reset [16:33:13] Probably a logic error [16:36:36] I think I might know the cause let me see [16:37:08] it doesnt do it on my older scenarios [16:38:02] Doesnt do it in any of mine [16:38:48] oh its the AGS light [16:40:00] go to stby on AGS, then pull the AEA breaker [16:40:22] then you get a MA you that wont go out, even when putting everything back [16:41:48] Interesting [16:42:52] That is weird though pushing the MA should reset the alarm and leave the light [16:43:35] yeah [16:44:51] actually in old scenarios it only does it if AEA cb is out, push it back in and the MA can be extinguished [16:44:53] Why is it perpetual [16:45:24] Even if the breaker is out, the MA should be able to be extinguished [16:45:27] but if you create a fresh LM, as soon as you power up c&w, you have the perpetual MA and there is no way to turn it off [16:45:32] right [16:49:27] hi again [16:50:39] In that condition the LGC light is causing the perpetual MA [16:50:49] So this is something in the MA code [16:51:26] welcome back [16:51:41] just downloading windows 10 i am at 70 percent [17:01:35] Something in the way the code writes the MA trigger [17:01:50] Keeps setting the light instead of doing it once [17:02:17] It looks like the AGS and LGC lights both do it somehow [17:02:30] it was working fine this morning though [17:03:21] Lets see what I broke then [17:03:29] and this morning I was up to "AGS FF change" [17:03:42] with that commit, it was still working fine [17:03:57] it could be Niklas's stuff too maybe [17:06:59] Separating the FF's may have done something bad [17:13:00] its not niklas's H2O sep saving, I tried the main repo with it and its normal [17:13:51] so that narrows it down to "Add separate FF's in O2 and H2O caution logic" [17:14:19] Yeah its something to do with the FF's [17:14:29] Ill investigate in a few I need to run out [17:15:05] ok [17:19:14] morning! [17:21:03] hey [17:21:33] what's up? [17:22:22] flip-flop craziness [17:23:32] lol [17:24:04] so something like http://klabs.org/history/ech/agc_schematics/logic/a01-1.jpg [17:24:05] :P [17:26:34] wow [17:26:41] is that block-1 related? [17:36:17] no, that's one half of the scaler module in the Block II AGC, haha [17:36:31] although I think the Block I AGC had a very similar module (here's hoping we find out soon) [17:42:04] nice [18:17:12] okay, I've requested the other two Functional Description and Operation documents [18:17:17] I can't get over how good the Luminary 116 one is [18:22:15] @rcflyinghokie so i am running windows 10 now and i forgot which reddist packages to get [18:26:05] select desktop developpment with c++ and the windows 8.1 SDK [18:26:19] so all checkboxes up to the windows 8.1 one [18:26:37] i meant just to run nassp [18:27:39] I think you should not need to install any other except the direct X update for the D3D9 client [18:28:29] https://www.microsoft.com/en-ca/download/details.aspx?id=35 [18:39:11] Back [18:42:38] welcome back [18:49:50] I am currently adjusting the no-track light bmp as it shifts a few pixels between on and off [18:55:01] I used that as a reference so it might be the same for other comp lights [19:05:27] I'll make a PR to your repo soon, with the comp light fixes, if you dont mind [19:06:00] I also adjusted slightly the positions of all the comp lights so they display perfectly now [19:06:19] ie. no shifting between on and off sates [19:31:25] Great that sounds good [19:31:43] I think I have the issue narrowed down to the O2 and H2O flip flops [19:31:49] Just a little more testing in a few [19:33:12] great [19:33:21] the CES DC/AC just randomly came on [19:41:00] PR sent [20:05:09] hi again i have a problem [20:05:24] hey [20:05:30] on the bottom left of the screen it says please enable project apollo mfd on the launch pad but it is enabled [20:06:11] can you see PAMFD in the MFD menu? [20:06:16] no [20:06:21] not the rtcc either [20:07:55] Looks like these FF's are causing more issues [20:08:35] bummer [20:09:06] rcflyinghokie, what redist does hes need again 2015? [20:09:24] yeah x86 [20:09:31] https://www.microsoft.com/en-us/download/details.aspx?id=48145 [20:09:41] try that, astronauthen96__ [20:10:04] [20:10:05] vc_redist.x86.exe [20:10:40] i only had the 2017 installed [20:11:37] 64 or 86 [20:14:28] 86 [20:14:43] well i just installed the 64 and it didnt work [20:14:48] i will try the 86 [20:15:22] You need x86 since NASSP runs in 32 bit mode [20:17:03] worked thanks [20:17:12] and my frame rates are smooth [20:24:08] great [20:24:55] ctd's are gone [20:25:22] been pressing calc for the last 2 minutes [20:25:44] even greater [20:26:16] so is landing the lem hard in apollo 11 i don't know weather to start 11 or 10 [20:26:53] have you flown 8 yet? [20:26:58] not a full one [20:27:01] but [20:27:23] do you have a scenario for 11 between lo1 and loi 2 because that is where i left off last time [20:28:38] I do but its from a few months ago and is already quite outdated with all the development work that has been going on in the LM [20:29:51] Yeah I wouldnt trust old ones for flying an actual mission, only for testing [20:31:04] any luck with the FF's? [20:31:31] Not yet [20:31:44] I cannot figure out what is setting off the MA [20:31:49] It isnt the FF's actually [20:31:54] They all are zero [20:31:58] that is fine [20:31:59] Which means reset [20:32:16] has anyone tried out indys mcc's yet? [20:32:24] annoying eh, those little f*'s :D [20:32:49] oh it isn't the FFs [20:32:57] how you guys tried apollo 10? [20:33:45] I wonder if its similar to what prevents you from reseting the MA when the MA cb is in, but CWEA cb out, with the C/W PWR light on [20:34:19] not yet, astronauthen96__ [20:34:39] Possibly [20:34:44] guess i'll be the first to test indys mcc's now that my stupid annoying and irritating ctd's are gone [20:34:52] I dont understand why I have an AGS light [20:34:56] The switch is off [20:35:00] goodbye for now you guys [20:35:08] cya [20:35:33] one more thing can you show me how to do that tell indy thing [20:36:24] .tell [20:37:00] .tell indy91 please praise windows 10, i am going to fly apollo 10 now to test your mcc updates now that my stupid annoying and irritating ctd's are gone [20:37:20] So windows 10 did it? Even with the LM? [20:37:45] it was the threading i believe [20:38:17] he said it was related to ntdll and that something about an api issue with windows 7 but i don't know what that means [20:39:00] on windows 7 after the first three mcc updates i got a ctd and then on apollo 8 i got a ctd from the rtcc mfd [20:54:49] I have no idea why this is happening [20:54:55] It actually is not the flip flops [20:55:40] Something keeps the light on even if pressed with the AGS code [20:59:09] Its something with the "lightlogic" mixed with the FF [21:00:57] But its like it turns it on each timestep instead of once [21:03:36] I havent a clue [21:09:02] hmm weird [21:10:37] Ok so it is just one line that is causing it to stay on in the AGS code [21:11:06] which one? [21:11:12] And its the line that triggers the alarm when the AGS is switched to standby without AEA power [21:11:21] if (lem->scera1.GetVoltage(16, 2) > ((415.0 - 380.0) / 8.0) || lem->scera1.GetVoltage(16, 2) < ((385.0 - 380.0) / 8.0)) { lightlogic = true; } // ASA Freq [21:11:40] Something about that is keeping the light on [21:12:00] ASA Freq [21:12:07] whats that? [21:12:31] Simulated ASA frequency] [21:12:47] It goes to zero if the AEA breaker is out [21:12:51] Which is what causes the alarm [21:13:06] But I cannot see why it wont let the MA reset [21:14:00] I skimmed through the chatlog [21:14:07] saw a "bad Niklas" somewhere in there [21:14:30] haha that would be me [21:14:34] glycol auto transfer? [21:15:18] ah yes, well the glycol pump 1 CWEA behavior is incorrect [21:15:30] ok [21:16:17] on ACT-27 of the Apollo 12 activation checklist, at the glycol pump check part you open the glycol pump 1 cb [21:16:55] and you should get: Master Alarm, ECS Caution lt - On Momentarily [21:17:12] and then after close the pump 1 cb again [21:17:35] the issue is the MA and caution light only come on when you close that cb, not open it [21:17:57] is that an auto transfer happening there? [21:18:19] I think it is happening [21:19:50] based on the actual glycol psi gauge (pump 1 cb is pulled out, but psi stays normal) [21:20:30] just that the CWEA ECS caution and associated MA should be also happening, based on the checklist [21:20:57] hi indy [21:22:10] @indy91 so i am going to start apollo 10 right now and i won't be on here maybe not till monday but i will let you know how your mcc's go [21:22:31] I wish you many CTD-less hours of NASSP [21:22:37] thank you [21:23:07] just pressed calc about 20 times and constantly switching panels and everything seems good [21:23:11] AlexB_88, ok, all three glycol CBs are closed before that procedure [21:23:18] yes [21:23:42] open glycol pump 1 CB [21:23:46] pressure will drop [21:23:48] goodbye indy [21:23:52] cya [21:24:00] below the switching point [21:24:12] then it will auto transfer to pump 2 and the pressure will rise [21:24:49] so, it probably only is below the threshold pressure for one timestep [21:24:59] because our pumps don't need time to start up [21:25:20] yeah [21:25:44] but whats weird is the ECS caution and MA do come on but only after, pushing the pump 1 cb back in [21:26:13] yeah, that's weird [21:26:41] I think that the cb requirement in that code is not quite right but I didnt look into it as I still cant find my issue in the cwea [21:29:14] For some reason now when the AGS light comes on, the MA is not able to reset [21:32:32] the MA is probably triggered again every time [21:32:52] it comes on when the state of a light goes from off to on [21:33:22] hmm, I have to wait for a bit in my scenario, so that the ECS light goes off [21:33:36] then I can try the glycol test again [21:33:51] but what does come on momentarily is the component light for it [21:35:32] switching the selector to sec and back to pump 1 seems to clear the ECS light [21:36:03] For the AGS light it should either be off or on [21:37:16] haha, glycol pressure doesn't even drop enough with both glycol CBs open [21:37:37] The dP should drop enough [21:37:45] no ECS light [21:37:50] hmm [21:37:53] but the component light [21:38:13] ah wait [21:38:19] I don't use your current state [21:38:38] any plans for a PR soon? :D [21:38:44] I'll use your branch [21:38:46] If I can figure out this AGS light [21:39:00] right [21:39:06] The FF's all work properly [21:39:11] I still need RR caution [21:39:23] And I need to know why this AGS light will not let me reset the MA [21:41:10] one light at a time, first I'll test the ECS light with your branch [21:41:25] Sure [21:43:43] I don't see the separate logic for pumps 1 and 2 in the CWEA schematic [21:44:01] it says "selected coolant pump fail" [21:44:08] shouldn't the rest of the logic be in the SCEA? [21:46:22] oh, they go to different lights [21:47:19] no, dumb me [21:47:25] suit fan != glycol [21:52:10] lem->GlycolRotary.GetState() == 2 && lem->scera2.GetVoltage(13, 3) > 2.5 [21:52:19] I don't think that is right [21:52:29] the condition on the switch is [21:53:23] it should be just the SCERA input [21:53:41] the input to the SCERA has the condition that the switch is in pump 1 or 2 [21:53:44] but not only 2 [21:53:51] Oh it does? [21:54:08] lem->ecs.GetGlycolPump2Failure() [21:54:20] and that returns true if [21:54:20] lem->GlycolRotary.GetState() != 0 && lem->PrimGlycolPumpController.GetPressureSwitch() [21:54:51] the function name is almost misleading, but I think the measurement is called like that [21:55:02] So that means pump 2 failure can be true if pump 1 is selected [21:55:11] Which is not the case for the ECS light [21:55:43] what does the light use? [21:55:56] The light says selected pump fail [21:56:13] the solid state switch of SC2, SA12, channel 2 [21:56:55] That is pump 1 failure [21:57:10] ah, two conditions [21:57:10] either [21:57:11] There is also one for pump 2 [21:57:15] that solid state switch [21:57:18] or just the DP switch [21:57:45] that is all implemented correctly for the component light [21:58:26] For the ECS light the condition is selected pump fail, thats why I have a condition for each pump unless that selection is handled elsewherE? [21:58:28] yeah, so, I think the additional condition on having the glycol switch in pump 2 is wrong [21:58:54] Ok [21:59:16] it should be just SC2/SA13/3 [21:59:38] the name of that is misleading [21:59:54] I think it works under the assumption that you are always in auto transfer [22:00:04] so you would only ever get a pump 2 failure, if pump 1 already has failed [22:00:09] Ah ok [22:00:16] because pump 2 wouldn't be used otherwise [22:00:20] So just one condition? [22:01:28] yeah, just that one SCEA measurement [22:01:37] so no extra line for pump 1 [22:01:49] and remove the condition on the switch [22:02:08] Interesting [22:02:10] and just change the comment to selected pump fail [22:02:39] SA12, channel 2 is certainly not used for the CWEA [22:02:46] not that I can see from the ECS instrumentation page [22:02:52] Ok [22:03:18] output voltage of 12/2 goes to telemetry, solid state switch to light [22:03:24] Gotcha [22:03:37] indy91, your H2O sep save/load works well [22:03:43] great [22:03:53] just RPM saved [22:03:59] I don't think it needs anything else [22:04:03] right [22:05:05] let's see if this behaves correctly now [22:06:18] yep [22:06:28] MA on, ECS light was on for a split second [22:06:37] Nice [22:06:52] hmm [22:06:58] now I close the CB [22:07:06] why would the glycol light be on now? [22:07:13] ah [22:07:16] component light [22:07:17] yep as the checklist ays [22:07:20] says [22:07:28] because the auto transfer relay is still set [22:07:53] great [22:08:36] component light on when you switch through pump 1 [22:08:52] which you don't really have to do in NASSP, but in reality [22:09:10] yeah [22:09:14] Right we were discussing changing the switch to make that happen [22:09:16] looks good [22:09:38] probably a general thing for rotary switches [22:09:45] Yeah exactly [22:09:53] Change the class to make it have to cycle through [22:10:06] would make sense to have all rotaries like that [22:10:15] if its possible of course [22:10:17] Could be annoying for things like the s band P and Y switches though haha [22:11:14] But no more time consuming than the ATT SET switches [22:11:33] maybe implementing to use the mouse wheel for it? [22:11:44] some simulators use that for rotational switches [22:12:20] hmm I would definitely not want it only to be the mouse wheel [22:13:22] mousewheel or click on the left side or right side of the switch [22:13:25] ok, AGS light? [22:13:58] that's quite the beast of logic [22:14:32] Yeah I thought I had everything right, but the ASA Freq condition (set by the AEA breaker being out) will not allow the MA to be reset [22:17:01] if (lightlogic || AGSWarnFF == 1) [22:17:02] { [22:17:03] SetLight(2, 1, 1); [22:17:14] that's doing it [22:17:38] How? [22:18:17] I also tried an else if there and had the same result [22:18:17] ah wait, I misread, maybe [22:18:41] so your lightlogic ends at the AND gate [22:18:48] and the FF is an additional condition, ok [22:22:05] Even if I just leave lightlogic in that if statement it does it [22:22:18] ok another thing related to this: If you power up a fresh LM, once you close the CWEA and MA cbs the MA cant be extinguished [22:22:33] and all SCEA cbs are closed [22:22:34] probably also the AGS one? [22:22:49] I could extinguish mine [22:22:57] Unless the AGS light was on [22:23:17] in my before LM ejection scenario [22:23:22] I popped in a new LM and used the activation powerup breaker config [22:23:31] bats to high taps and inverter on [22:23:35] MA cleared [22:25:39] so, the only way a light could do this if the light on condition cycles on and off [22:25:59] Right [22:26:09] but without ASA voltages, that condition should be permanent [22:26:18] Exactly [22:26:41] Now I wonder if I messed something up in the timestep itself when I added the other FF's [22:26:48] Add separate FF's in O2 and H2O caution logic [22:26:51] Happened after this [22:26:57] https://github.com/rcflyinghokie/NASSP/commit/774acea2b378c66cb336e41e03fd039f6c59b9e1 [22:28:36] hmm [22:28:42] wouldn't all lights do that then? [22:31:12] Yeah probably [22:32:02] I believe it was working before that commit [22:32:09] I dont know what I did to break it haha [22:34:02] something definitely is resetting the light [22:34:10] Yeah [22:34:23] I added some test variables, the light state is never, ever on just before it is set on or off [22:34:43] aha! [22:34:50] you did a bad copy paste I think [22:35:07] search in the CWEA file for [22:35:07] SetLight(2, 1 [22:35:31] the same light is set by [22:35:32] CES AC VOLTAGE FAILURE [22:35:37] CES DC VOLTAGE FAILURE [22:36:04] so the wrong light is set those [22:36:08] by those* [22:36:36] and funny enough I was noticing the CES lights come on and off randomly haha [22:36:36] it should be "0,1" and "1,1", I think [22:38:03] I actually fixed a bunch of those issues as well [22:38:14] I found some left over from changing to setlight :P [22:38:32] oh, I did some typos there? [22:38:34] no surprise really [22:38:57] It is so easy with those lights [22:39:54] so that should hopefully take care of the AGS light [22:42:11] If thats all it was I have been headaching most of the day about it haha [22:43:16] I even added {} in places just in case under if's haha [22:43:34] looks like it works [22:43:56] Wow [22:44:05] All that for an incorrect light :P [22:44:09] Thank you! [22:44:18] Makes me feel better that the FF's work [22:44:40] thanks for the help with the 2 issues, Niklas [22:44:49] "Good Niklas" [22:44:50] So with that working, I now need to figure out this RR caution logic [22:45:06] Haha the "bad" has been replaced [22:45:08] thanks to carrying boxes half the day I had a fresh mind, haha [22:45:20] Yeah doing something else can help [22:46:01] rcflyinghokie, now about those CES AC/DC they have new FF's I see [22:46:11] although I doubt that will help with the RR light [22:46:12] how are those set and reset? [22:46:15] that's just confusing [22:46:23] Yeah it is [22:47:19] Yeah the CES FF's are reset using the gyro test switch [22:47:37] move it up or down [22:47:46] aha! [22:47:49] thanks [22:48:19] this CWEA is almost by the book now guys [22:48:36] You should go look at the RR caution logic [22:48:43] Its "fun" [22:48:53] Thats what I need to figure out next [22:48:56] lol I heard [22:49:00] at least RCS TCA shouldn't be so bad [22:49:09] and what about the S-band one? [22:49:43] I dont think we have enough implemented for it yet, do we? [22:50:22] probably not, but the FF and some parts of the logic should be possible [22:50:26] I need a condition for it receiving signal [22:50:30] Yeah I can get the FF in there [22:51:01] you need the SCEA as a condition [22:51:10] Yep [22:51:13] and that channel will just be 0 without logic [22:51:35] so basically, you can implement the CWEA part of it [22:51:37] all of it [22:52:07] Yeah [22:52:25] That will be simple *skims over RR caution happily* [22:58:35] I mean, we can do the solution with the reset not in CWEA code but in the rotary switch code in lempanel [22:58:44] that should give the right behavior [23:02:36] the RR is way too good probably, it would never loose track on its own. Only if the LM gets out of range [23:03:25] Haha [23:06:00] but [23:06:14] pulling the RR AC breaker should always give the alarm, I think [23:06:32] without that breaker the RR still sends out the No Track signal [23:06:43] which it then would in Auto Track [23:08:10] I can implement the RR light, if you don't want to deal with it, haha [23:08:21] I think you understand it better than I [23:09:31] sure, I'll handle it [23:09:33] but not today [23:09:36] good night! [23:18:42] I need to grab dinner and a drink [23:20:49] lol you deserve a drink or 2 [23:34:10] the FF no longer activates the AGS warning though [23:34:34] so the self-test fail thing no longer turns the AGS light on [23:35:03] I think caused by the change from if (lightlogic || AGSWarnFF == 1) [23:35:10] to justif (lightlogic) [23:35:43] but I think that was correct before [23:49:44] wait that change stayed? [23:49:49] I thought I reverted it [23:50:14] I guess not [23:51:09] hehe [23:51:35] I never pushed the revert [23:51:41] anyways im off to bed! Good work! [23:51:58] I need to verify from Niklas but I think I can convert signal strength into a condition for the sbd cwea logic [23:52:08] Night! and thanks for the testing! [23:52:25] night [09:49:41] hey indy [09:49:58] i am about to dock with apollo 10 [09:50:11] hey [09:50:34] your roll for sep is off by about 2 degrees [09:51:02] yeah, I have noticed that before [09:51:20] what did the TLI PAD have for the attitude? [09:51:35] 358 [09:51:54] and it's actually 0°? [09:51:59] yeah [09:52:05] interesting [09:52:16] the actual Apollo 10 TLI PAD was also 358° [09:52:27] so, I wonder if this is an issue with the attitude calculation of the LVDC [09:52:48] rather than an issue with the TLI PAD calculation [09:54:13] i am pitching up now i will see if it affects the docking [09:55:04] nah, 2° are nothing [09:55:48] the CSM and LM are always docked at one exact roll angle in NASSP, but in reality you could docked with some roll error [09:55:53] I think 2° was about the average [10:04:53] just docked with no problems [10:05:12] great [10:05:30] i could tell by the docking mfd that the roll was really close to hitting red [10:07:35] so i guess the threading was a windows 7 issue? [10:10:03] well, I am sure we are doing something wrong with that. But it probably was some incompatibility of the way we used threads and Windows 7, yes [10:10:08] probably fixable in some way [10:10:20] but I have no idea how [10:10:27] only had one ctd because of windows update [10:10:38] i guess you cant minimize orbiter then switch back to it [10:10:51] you can, but you have to use the right setting for it [10:11:10] on the video tab [10:11:19] Full Screen Mode [10:11:30] I always have "Full Screen Window" chosen there [10:11:48] you probably have "true fullscreen (not alt+tab)" there [10:11:52] no* [10:11:54] yeah i do [10:12:10] with "full screen window" alt+tab will work [10:12:13] i might change that after the evasive maneuver [10:12:25] sure [10:13:01] will there be any major changes to the lem coming up? [10:14:50] not too major anymore I think [10:15:10] none that would break old scenarios [10:15:45] well i wont be entering the lem until day three i think [10:17:35] so is anyone actually flying apollo 10 and not just for testing? [10:18:50] right now? probably not [10:19:01] I am flying it to implement the MCC of course [10:19:14] just to know in advanced is there a mcc1 [10:19:20] very likely, yes [10:19:38] so, I've based the decisions to do MCCs based on the mission rules [10:19:39] my residuals for the tli were 54.5 is that normal [10:20:23] the separation attitude roll being off was probably not a TLI PAD issue, but that definitely is. The TLI PAD calculation doesn't simulate the TLI maneuver super well yet [10:20:37] so that will need improvement [10:20:51] so, your TLI burn was likely very accurate [10:20:56] just the TLI PAD DV value not [10:21:03] is there no evasive maneuver pad [10:21:08] there will be [10:21:13] okay [10:21:32] 55 minutes after TLI or so [10:22:22] should be coming at about 3:30 [10:22:36] i am at 3:34 and no pad yet [10:22:51] just got it [10:23:20] its about 10 minutes later than in the flight plan [10:23:48] I think it's at around that time in the flight plan, no? [10:23:53] shortly after 3:30 [10:24:06] i meant the get for ignition [10:24:15] oh [10:24:18] in nassp its 4 38 flight plan is 4 28 [10:24:37] which flight plan are you using? [10:25:11] final flight plan april 17 the first page has a yellow background [10:25:13] I think that was actually a change done in the last revision of a flight plan, so you might have a slightly outdated one [10:25:29] page 3-8 [10:25:37] does it say "REV A" somewhere at the bottom? [10:26:10] where did you get that flight plan? [10:26:38] https://history.nasa.gov/afj/ap10fj/fplan/a10-final-flight-plan-19690417.pdf [10:26:56] this one has the updates of revision A from May 5th 1969 [10:27:09] and the evasive maneuver is at 4:39 in there [10:27:44] you think final flight plan means final? Dead wrong, hahaha [10:28:03] i was looking at the csm burn schedule [10:28:10] in your it says 4 28 as well [10:28:11] oh, interesting [10:29:26] so, I have the revision document for revision A and it only contains changed pages of the detailed timeline [10:29:32] not of the sections before that [10:29:49] i guess the 4 28 was just a prediction i guess [10:29:59] no, that was an actual flight plan change [10:30:15] there just wasn't an official replacement page for the CSM burn schedule I guess? [10:30:30] does not look like it [10:30:48] I wouldn't be surprised if that 4:28 time was changed by hand in the flown copies and the flight controller copies, haha [10:31:21] i wonder if they have star charts available from the lunar landing missions [10:31:22] so I guess the lesson is, trust the detailed timeline more than section 1 [10:31:46] yes, I've seen those [10:32:13] i probably wouldn't know how to use them but it would be neat to see [10:33:01] yeah, I wouldn't know how to use them either [10:33:16] https://www.ibiblio.org/apollo/Documents/A8-Updates-1004.pdf [10:33:25] PDF pages 14-16 has some of those charts [10:33:53] do you have any physical copies of any of the flight plans? [10:33:59] I don't [10:34:08] i have 2 apollo 11's from amazon [10:34:24] the reformated version [10:34:44] yeah, I've used the reformatted version a lot, just only as PDFs [10:34:45] well [10:34:51] and I printed the PADs from it [10:34:58] because they look quite nice [10:35:11] I only have a collection of different flight plan copies as PDFs [10:35:24] one thing i noticed, for the first set of p23's on the second one it says star 40 ENH r3 00120 [10:35:34] The Honeysuckle Creek Tracking Station website has the scan of their copy posted for example [10:35:51] shouldnt it be 110 [10:36:15] it says that in the flight plan or the Checklist MFD? [10:36:22] in the actual flight plan [10:37:04] hmm, I don't see it in the detailed timeline. Is that on page 3-9? [10:37:10] in my book it does [10:37:21] Apollo 10, right? [10:37:38] apollo 11 [10:37:43] oooh [10:37:43] ok [10:37:45] let me check [10:37:55] the reformatted version does have some typos etc. [10:39:36] yeah, I think that is a typo in the reformatted version. Or was fixed in a revision, I can also check that [10:39:43] because it's actually the far horizon optio [10:39:44] option [10:39:57] "2. STAR 40 EFH (R3=00120)" [10:40:02] F instead of N [10:40:32] and that was not changed in a revision to the actual flight plan [10:40:38] so it must be a typo of the reformatted version [10:42:13] and i am not seeing the lem weight in the maneuver pad [10:42:38] but in the checklist mfd it asks for verb 21 which is just to change the csm weight [10:43:21] the weight of the LM hasn't changed since liftoff, so you can leave the LM weight as it is [10:43:42] yeah whenever i did a calculation in the rtcc it didnt change much [10:43:57] I think the LOI-1 Maneuver PAD is the first PAD to have an updated LM weight [10:47:23] just did lem ejection and i keep getting this no joysticks found error is there any way to make it go away [10:49:10] do you have all the joystick options disabled in the Orbiter launchpad? [10:49:14] yes [10:49:22] including in the NASSP config menu= [10:49:23] ? [10:49:29] i think so [10:49:41] do you have a joystick connected? [10:49:49] no i am using the keyboard [10:50:03] in the Project Apollo Configuration under Controls [10:50:25] RHC and THC should both be unchecked there [10:52:22] they are [10:52:27] so what also might happen is that NASSP accidentally detects some other connected device [10:52:40] and then when it figures out that it isn't a joystick, it gives that error [10:53:06] maybe a printer connected or something? But in any case, that probably needs some work on our side [10:55:41] my printer was off for the last few days and i just turn it on to print some pads [10:56:14] i'll just turn it off then [11:33:15] i have got some p23's coming up and i just want to practice them but i forgot at which point to cancel it [11:50:00] you mean when to cancel them to not actually update the state vector? [11:52:53] yes [11:54:54] when you have N06 V49 [11:55:04] there you do V37E 00E to end the P23 [11:55:08] V37E 23E to start another one [11:55:15] or PRO to incorporate your mark [11:55:41] okay [11:56:45] uhh [11:56:50] V06 N49 of course [12:58:27] i am at 6:30 with no ctd's or any issues [12:59:49] great [13:00:07] still got crap results with the p23's [13:01:42] you are not alone with that [13:01:58] it's difficult and the Earth has the wrong shape in Orbiter [13:02:38] I don't think anybody has reliably been able to navigate with P23 with precision [13:03:03] sometimes you think you are getting good results and then suddenly the position and velocity errors are rising again [13:03:25] i am guessing the mcc1 pad will come before 7:00 [13:04:16] no, MCC-1 update will be at about 10:00, as per the flight plan [13:04:53] at 7:00 it sayd if mcc1 can be made with ptc refsmat click pro otherwise click fail [13:05:35] ah, I haven't implemented that logic yet. So you will get the PTC REFSMMAT uplinked in any case at that time [13:05:58] so you should press PRO [13:06:52] okay and i am on orbiter forum and is there a way to change the title of a post i made i want to change the ntdll post to solved [13:06:54] but there will just be that uplink there [13:07:06] not the MCC-1 update, that will be later [13:07:09] uhh, no idea [13:07:20] never mind just clicked on go advanced [13:32:40] im at 7:08 with no refsmat should i just press pro or wait? [13:33:39] I think it should be uplinked right at that time where you are [13:33:56] just got it [13:36:20] which one is easier torque or coarse? [13:39:26] easier in what way? [13:40:22] coarse alignment is very quick, but can cause a little bit of an IMU drift, if your attitude rate is not 0 [13:40:43] and torquing is slow, but causes no additional IMU errors [13:41:32] I think they usually used the torque option for the PTC REFSMMAT [13:54:55] i think im gonna take a break now i didn't sleep at all tonight because of nassp [13:56:27] and also i messed up on the p52, i chose tourque and it was changing numbers and i went to program zero now when i punch in the p52 i get a prog and pngs light [13:57:20] torque can take a minute or more until it is finished changing the IMU alignment [13:58:07] with torque it will show V16 N20 [13:58:28] until it is done [13:58:44] and what about the pngs error [13:59:09] that's caused by the program alark I think [13:59:12] alarm* [13:59:43] i punch in 37 52 and i get the alarm and a flashing verb 37 [14:03:16] you must have broken something then [14:03:22] probably some user error in the P52 [14:03:25] get some sleep! [14:03:30] i will [14:03:46] i will try again in an hour or two [14:04:10] goodbye for now [14:05:17] cya [14:28:39] hey Ryan [14:30:26] Hey good morning [14:31:53] I'm finally past the CSM sep maneuver on Apollo 10 [14:32:11] all three PADs the LM is getting before that are looking good [14:32:36] the only thing that isn't considered yet is the trajectory change due to the 2.5 ft/s separation maneuver [14:33:07] because for the phasing maneuver you basically have to use: LM post-DOI state vector and CSM post-sep state vector [14:33:51] but the sep maneuver is done radially, no orbital period change. So I am sure the calculate CSI and TPI times are accurate enough [14:34:23] Yeah they should be close [14:35:26] I'll see. There is a planned phasing maneuver update post-DOI [14:36:04] and if that DV vector is very different from the earlier PAD, then I'll have to consider the sep maneuver in the trajectory calculations [14:36:41] As you said since it was radial it should have only a small effect on phasing [14:37:26] yep [14:37:40] I think I have s band cw logic finished [14:37:44] Just testing the FF now [14:37:46] great [14:38:02] I routed your signal strength through the scea [14:38:13] ok [14:38:22] how do you handle the unit of it? [14:38:32] I think it's just an arbitrary scale from 0 to 100 [14:38:36] It is [14:38:40] scaled to 0-5v [14:38:54] Which is used on the display which is also 0-5 [14:39:10] The same signal from what i can see goes to both that and the cw [14:39:10] ok [14:39:19] your last commit was [14:39:22] "Comment out sband SCEA until scaling figured out for negative numbers (dB)" [14:39:30] Yeah that was before bed [14:39:41] Research today revealed that is not needed [14:40:25] The signal strength is preconditioned to a 0-5V scale [14:40:35] Before going to any display/cw [14:40:54] So I took your "0-100" and just scaled it in the scea [14:41:14] makes sense [14:41:20] back in a few [14:41:26] good morning ryan [14:41:49] just having some with some ctd'less nassp [14:41:54] fun* [14:43:00] Great! [14:43:30] indys mcc's are working fine [14:44:40] @rcflyinghokie i was thinking of going into the lem to get familiar with where the panel numbers and i know you were getting ctd's in there should i expect some too? [14:45:14] I don't think so [14:55:58] have you done a lem activation lately? i was thinking of doing that for some familiarization [14:58:39] Yeah i do them often for testing [15:01:19] If you are practicing, use the apollo 12 activation checklist [15:04:38] okay [15:06:07] rcflyinghokie, there is a LR test scheduled in the Apollo 10 flight plan, at 99:20. I don't think the checklist has that [15:06:14] unless it is in the DOI sub-checklist [15:06:24] Let me take a look [15:06:31] It probably is [15:06:59] yeah, because the test is basically during DOI [15:07:07] I'll get there soon, so, I'll tell you [15:07:56] Hmm nope I might have missed it [15:10:04] also interesting for the later test [15:10:32] which hasn't really been working in Luminary069 [15:10:53] if L099 is bad with LR flags, L069 is probably even worse [15:11:03] I think they found more issues with it on 10 didnt they? That were fixed for 11? [15:11:43] luckily we have all the Luminary memos for that [15:12:12] I might have to go through this 10 phasing procedure [15:12:37] I dont remember why I didn't follow the phasing summary [15:12:58] because it's very outdated [15:13:36] Ah yeah thats why I skipped some parts [15:14:00] In the beginning at least [15:15:23] after the phasing maneuver we have the rendezvous procedures document [15:15:26] which is up to date [15:15:37] so I guess at that point the procedures become very detailed and accurate [15:15:54] Yeah that part I followed pretty close [15:16:04] I am just seeing parts of the phasing summary i skipped [15:17:48] I will make some edits [15:26:56] In the flight plan it says LDG RDR TEST, and then below it LR TEST, V78 [15:27:03] yeah [15:27:08] Thats the spur test [15:27:13] yes [15:27:15] Ok [15:27:21] So I just missed the self test [15:29:30] Which was not in the phasing summary [15:29:39] Probably how I missed it [15:42:55] ah, these hardcoded tailoff thrust numbers are annoying [15:43:06] have to implement thrust tailoff for DPS and APS soon [15:43:55] That will make the insertion procedure that much more important to follow [15:44:24] The manual engine stop when the DSKY reads 50fps remaining [15:45:16] So I am going through the rest of the cwea, I think the ISS is implemented wrong at least for LM 8 [15:45:42] Unless all of those data values send an ISS warning to the scea [15:45:51] Apollo 10 insertion procedure? [15:45:52] In which case they need to be rerouted [15:45:58] Did they manually cut off the engine? [15:46:10] Insertion from the surface [15:46:22] oh [15:46:29] The insertion in 10 was a regular burn [15:46:52] But the tailoff will make following that procedure from a surface liftoff more important is what I mean [15:47:31] isn't it just engine arm to off at 50 fps? [15:48:36] with simulated tailoff thrust there just won't be as much residual trimming [15:49:35] Ah you are right it is engine arm off [15:50:12] I knew it was something off there [15:54:38] yeah, and with the weird APS engine logic, that doesn't turn off the engine [15:54:46] because the engine start button is still pressed [15:55:23] having both engine start on and also auto ignition, it kind of works like the DPS command override [15:55:37] and that is turned off in anticipation for insertion [15:57:57] there is a LR test in this checklist [15:58:00] but after DOI [15:58:21] guess that moved to before DOI from the early procedure document to the flown flight plan [16:02:17] Ah [16:04:21] I moved it to before [16:04:40] Oh, I am transferring the lgc and ISS failures to the scea [16:05:02] guess they belong there [16:05:08] I see that the ISS light had a number of conditions to turn on in the code [16:05:21] However I see only one in the handbook, the ISSWarning [16:08:29] I would assume based on the comments // On when ISS power supply fails, PIPA fails while main engine thrusting, gimbal servo fails, CDU fails that the ISS warning comes on when any of those happen? [16:09:50] isn't that all controlled by the LGC? [16:10:40] Thats what i thought, I am trying to figure out why the cwea had all those channels as part of the ISS code [16:11:02] When from what I can see, it only uses ISSWarning [16:13:00] I would think that the proper failures of the IMU would send that warning, and all the other warnings are unnecessary in the cwea/scea [16:13:52] I bet this is something that should be simulated by the LGC electronics [16:13:59] and that it only is one output [16:14:08] which goes to the SCEA and then to the CWEA [16:14:16] Thats how I changed it [16:14:35] I just hope the LGC simulates it properly haha [16:18:08] Hmm I pulled the IMU breakers and I got the LGC prog light and temp light but no ISS warning [16:20:16] morning! [16:20:33] Hey good morning [16:20:48] what's up? [16:20:58] rerouting lgc failures through the scea [16:21:17] Hm maybe I cannot do it like I thought [16:21:22] SA3.SetOutput(11, val163[Ch163DSKYWarn]); [16:29:19] Oh duh, guid switch was in AGS :P [16:34:14] Seems to work right [16:35:38] :D [16:38:25] Question is if the ISS Warning is sent by the LGC at the proper conditions [16:38:59] it should be, I think that one is entirely under software control [16:39:58] but if I'm wrong about that, then it isn't :P [16:40:44] I am hoping, the cwea code before had the light use a bunch of channels instead of just that one [16:41:03] nope, it's just channel 11 bit 1 going directly out to the main connector [16:41:06] no funny business with it [16:41:10] totally software controlled [16:41:40] Seems to work properly at least when pulling the IMU breaker [16:49:01] indy91, should I use the lem->DPS.pitchGimbalActuator.GimbalFail() or the K21 for the gimbal fail indication sent to the scea? [16:49:15] K21 uses the function and a few other conditions [16:50:19] I would assume use K21 [16:53:02] And if so, adding bool GetPitchTrimFail() { return K21; } to the scs header [16:55:12] Or rather, bool GetK21() { return K21; } [17:05:46] And there is one more cwea component switched to scea [17:07:42] \o/ [17:13:17] Now to go back to the des reg light [18:03:40] woo! [18:03:54] we now have two more of the Functional Description and Operation documents! [18:05:04] Which systems? [18:07:32] both for the CSM [18:07:41] Block II CSM [18:07:52] one very very early one written for Sundisk revision 1 [18:07:58] (I think it was 282 that flew or something) [18:08:02] and one for Comanche 67 [18:08:33] Very nice [18:08:40] yeah, 282 flew [18:08:54] uploading now [18:09:52] I'm curious to see what Sundisk 1 looked like from a high level lol [18:10:18] oh! nevermind [18:10:34] this is revision 1 of this document, they titled it a bit differently from the other two [18:10:40] this is written for Sundisk 282 [18:11:41] Sundisk 282: https://drive.google.com/open?id=1HO0akn188Ii6sQuYDoM5_1D50x5a3j1b [18:13:39] Comanche 67: https://drive.google.com/open?id=1YNQmDtm622bzc4UWbUjBzvyUCsQaDNlj [18:20:18] welcome back, you just missed my links [18:20:25] Sundisk 282: https://drive.google.com/open?id=1HO0akn188Ii6sQuYDoM5_1D50x5a3j1b [18:20:30] Comanche 67: https://drive.google.com/open?id=1YNQmDtm622bzc4UWbUjBzvyUCsQaDNlj [18:20:42] more Functional Description and Operation documents [18:22:06] oooh, Sundisk [18:22:23] yeah, I was wrong about it being for Sundisk 1 -- the wording in the title is a bit different [18:22:37] so like "Luminary 1" [18:22:45] aka Luminary 069? [18:22:53] oh maybe [18:23:10] I was thinking the Revision I was probably just meaning the first revision of this document [18:23:18] possible [18:23:28] rcflyinghokie, what was that about relay K21? [18:23:38] I figured that part out [18:23:49] Now I am on the des reg logic [18:24:31] to which SCERA/Subassembly/Channel did that relay go? [18:24:52] K21 was 2/3/9 [18:24:58] K22 2/3/10 [18:26:01] yeah, I think you did it correctly. Relay closes contact, contact is used for the SCEA channel [18:26:36] I already added some DECA stuff to the SCEA [18:26:42] I think it were the throttle commands [18:26:52] In doing the gimbal test, I also see that the des reg light comes on when the engine is armed [18:27:10] So i came back back to that logic [18:27:25] I think the engine arm sets the FF [18:27:40] And that coupled with being unstaged and low pressure (not pressurized yet) turns the light on [18:27:48] And cycling the CWEA breaker resets the FF [18:27:52] Does that sound right? [18:30:56] uhh, maybe [18:31:15] Well I know the pressure low/unstaged condition is met [18:31:36] So I need to know what sets the FF, there are 2 things on that [18:31:42] DPS ARM and Time delay [18:33:24] I think DPS arm is also from the SCERA [18:33:56] SC1/SA3/CH9 [18:36:13] indy91, do you know why they skipped Colossus 2B? [18:36:27] I hadn't realized Comanche 55 was Colossus 2A and Comanche 67 was Colossus 2C [18:36:54] yeah it is I am just trying to figure out what sets that [18:37:15] page 124 [18:38:01] DECA PWR CB has voltage AND unstaged AND (DECA relays K1 OR K23) [18:39:23] Is there any condition tha already uses those in the DECA code? [18:39:37] the relays? [18:39:39] Would using DEArm work for example [18:40:09] well, the SCEA wants those relays, so why not use it? [18:40:32] it might make sense to move the conditions into a function in the DECA [18:40:49] Thats what I wanted to do [18:41:01] I was just checking to make sure there wasnt already one that uses what I want [18:41:50] hmm [18:41:52] in the DPS [18:42:00] if (lem->SCS_DECA_PWR_CB.IsPowered() && (lem->deca.GetK1() || lem->deca.GetK23())) [18:42:01] { [18:42:02] engArm = true; [18:42:02] } [18:42:29] the question is where the SCEA gets its logic from [18:44:08] Looks like from the DECA [18:44:15] that certainly [18:44:31] I see the two relays there [18:44:32] seems like both DPS and SC1 get the same output from the DECA [18:45:17] so, it would probably make sense of the DPS calls a function in the DECA with that logic [18:45:29] and SC1 calls the same function [18:45:43] that way the logic isn't there twice [18:46:51] thewonderidiot, so we always got those designations wrong? [18:47:26] I never realized it, Ron pointed it out when I sent him these docs [18:47:34] but I can't find anything containing the string "Colossus 2B" [18:49:07] I looked in the Artemis GSOP [18:49:12] 2A = 55 [18:49:18] 2C = 67 [18:49:20] yep [18:49:28] 2D = 72 [18:49:30] and 2B was maybe some revision in between? [18:50:19] the revision index has a bunch of weird "reincorporated" entries [18:50:34] for 2C [18:51:05] hmmm [18:51:07] strange [18:52:21] those are changes that were already done in earlier versions [18:53:53] maybe they had a version ready for a September launch [18:54:02] a reflight of the G mission in the case Apollo 11 didn't land [18:54:10] but with 2 more months time [18:54:15] they added a bunch of new features [18:54:46] hmmmmmm [18:54:47] maybe [18:54:53] too bad we don't have Colossus memos from this time [19:01:50] Colossus 2C did Level 4 testin from July 7th to 17th [19:02:30] which might have been just in time to support a September launch [19:05:34] hi again [19:06:47] hey [19:08:16] no, I can't find anything about Colossus 2B [19:09:42] rcflyinghokie, Phasing DV before DOI: +169.4 +0.0 -99.0 [19:10:03] and after DOI and CSM separation maneuvers: +168.8 -0.1 -99.1 [19:10:07] what do you think [19:11:09] 0.6 ft/s off isn't too much [19:11:13] Wow [19:11:46] the pre-DOI numbers are with a simulated DOI and the sep maneuver not taken into account [19:11:53] Yeah that sep maneuver is almost negligible in effect for that [19:12:02] As expected of course [19:12:26] yeah [19:12:39] also, what is the right throttle profile for DOI? [19:12:50] I'm pretty sure it cut off when I had it at 40%, haha [19:13:26] I thought it was 10, then 40 through to cutoff [19:13:32] probably [19:13:44] it has a burn time quite close to 26 seconds [19:13:54] Yeah 10% for 15s [19:13:58] then 40 until completion [19:14:05] yep, that's what I did [19:14:06] Pretty sure 11 is the same [19:14:57] could be annyoing if it throttles up and cuts off immediately [19:15:13] might get larger residuals that way, because timing the cutoff gets difficult [19:15:54] ah wait, that burn time in the flight plan includes the ullage [19:16:04] from DPS ignition to cutoff it was 22 seconds [19:16:12] sounds right [19:16:39] 70 something FPS? [19:16:52] yeah, 72 it was on my Apollo 10 DOI [19:17:00] Very nice [19:18:15] For this logic, any idea what "time delay 6 s" and "contact from propulsion" are? [19:18:24] I'll look [19:18:31] hmm, I have a slightly incompatible throttle program for the LM [19:18:44] it only stays at 10% for 5 seconds, not 15 [19:18:51] might have to make that an input [19:24:47] For burn time calculation? [19:25:09] yes [19:25:21] both for the Maneuver PAD and the finite burntime compensation [19:25:35] they use the same function to simulate a DPS burn [19:26:06] I bet apollo 9's docked dps really is wrong using that haha [19:26:26] With all the position changes at the wnd [19:26:28] yeah [19:34:47] I'm tracking down the signal in the schematics [19:34:55] I think it comes from the ED [19:36:02] I don't know where that 6 second delay is coming from though [19:38:34] I'm fairly certain it comes from the DPS helium pressurization delay timer [19:38:38] but that one is 1.3 seconds [19:39:38] although this almost looks like a separate delay timer, just for the CWEA [19:40:26] I see the GSE above the reset line, but it looks like cycling the CWEA breaker resets it based on the procedures [19:46:32] there must be some additional 6 second delay timer that I don't really know where it is [19:47:22] hmm, looks like the ED [19:49:37] but power from the CWEA enable bus and the signal is only going to the CWEA [19:50:03] oh wow, I didn't realize that this is basically our first actual documentation for Sundisk [19:51:23] Also regarding the reg light during the gimbal test: [19:52:09] Light remains on until : (1) Normal pressures are established [19:52:10] by DPS pressurization , (2) CB INST : CWEA is cycled [19:52:10] which resets logic if ENG THR CONT : ENG ARM sw - OFF , or [19:52:11] (3) staging occurs [19:52:24] thewonderidiot, we have full Apollo 7 rendezvous procedures, which already tell a lot [19:53:44] ok, so I probably found the delay timers [19:54:18] in the elementary schematics logic, ED system A is called "2A1", system B is "2A2" [19:54:28] and any relay is then called e.g. 2A2-K1 [19:54:39] now, the relays in the delay timers are [19:54:41] 2A3-K1 [19:54:46] 2A4-K1 [19:54:54] and they are without description [19:55:14] but those are a redundant set of timers, probably 6 seconds [19:55:42] so they kind of belong to the ED, but aren't part of one of the ED relay boxes [19:57:42] there also is some helpful stuff in the Apollo Experience Report for LM Instrumentation [19:57:51] PDF page 35 [19:58:08] it says it's a 7.3 second delay timer [19:58:44] which probably means, the 1.3 seconds delay of SHe pressurization during the first burn [19:58:54] Ah [19:59:13] and then the additional 6 seconds of the separate delay timers just for the CWEA light [20:00:18] I'm not really sure how that all works though [20:01:09] Yeah it is a bit confusing [20:03:20] That GSE going to the FF is weird as well [20:03:42] Cycling the CWEA breaker must reset it [20:03:55] I wonder if cycling it resets all FF's [20:03:55] yeah [20:06:07] ok, I think I have it [20:06:19] that relay that is energized after 1.3 seconds [20:06:35] there indeed is a contact going out to the other delay timer [20:06:40] the 6 second one [20:07:33] So does all this belong to the ED system? [20:08:36] basically, but I am pretty sure that those 6 second delay timers are not in the ED relay boxes [20:10:14] looks like each relay in the ED relay box is going to one delay timer though [20:10:47] and the logic is, if any of those two 6 second delay timers has its contact closed, then the signal is going to the CWEA [20:11:18] so maybe it would make sense to give those two to the LEM_EDS class [20:11:32] and not LEM_EDRelayBox [20:11:55] those delay timers appear on the ED schematics, not CWEA, so they belong there, somewhere [20:12:19] we are basically going beyond the detail in the Systems Handbook with this :D [20:12:29] Haha clearly [20:16:24] That GSE reset still bugs me though [20:18:45] It cannot be the only way to reset the FF, otherwise the light would stay on [20:18:51] until pressure was correct or staged [20:24:06] I'll track that down as well [20:24:39] do you want to add the delay timers or should I do that? [20:24:43] I have the logic ready for those [20:24:48] Oh the delay [20:25:06] I really dont quite understand how to make them [20:25:26] I have the CWEA logic ready for the missing variables though [20:26:34] hmm, in this case the schematics just say "closure via GSE" [20:27:03] Yeah [20:27:08] AOH says [20:27:28] nothing actually [20:27:32] only about setting the FF [20:27:47] Exactly [20:28:09] But unless I am missing something, if that FF is set, and the reg pressure is low, the light will stay on until staging [20:28:25] Which does not follow the procedures [20:28:56] In other words, unless cycling the CWEA breaker resets that FF, the light will remain on until DPS pressurization [20:35:23] and the FF can get set by arming the DPS [20:35:57] Like in the case of the gimbal drive test [20:38:20] on the DPS propellant page it says [20:38:27] "1st DPS Arm signal" [20:38:46] so that might confirm the behavior, that the FF is never reset [20:40:52] is maybe the DPS plumping under pressure at launch? [20:40:59] Maybe the pressure is good [20:43:20] AOH Volume 2 Malfunction procedure says [20:44:00] "Light is enabled when unstaged and after ENG ARM - DES for first time, or ABORT pb has been pushed (engine-arm signal-enabling logic delayed until 6 seconds after engine-on command is issued):" [20:45:35] So what turns the light off after CWEA reset? [20:45:46] no idea [20:45:54] Yeah I am confused haha [20:46:37] maybe it's different LMs again [20:46:46] Well the cycling is also in AOH vol 2 [20:46:49] LM 11 [20:47:14] where? [20:47:25] pg 276 [20:48:14] Says cycling "resets logic if eng arm switch is off" [20:48:54] ah, the relay contact of the delay timer gets its power from the "CWEA enable bus" [20:48:59] so one of those again [20:50:42] is resetting the logic the same as resetting the FF? [20:56:48] I don't think so [20:57:17] I just cannot understand how the light goes back off if that remains set [20:57:29] yeah... [21:00:17] Also when I changed the gimbal drive test cw logic I no longer get a gimbal light when it hits the stops using K21 and K22 [21:00:56] what was the logic before? [21:01:08] I don't think the malfunction circuits are even simulated [21:01:24] they should probably set those relays when the gimbal is in a stop? [21:04:45] hey [21:05:43] hey Alex [21:06:21] oh man [21:06:38] rcflyinghokie, I'll add the same conditions that were in the CWEA to the DECA [21:06:39] okay if everything works out, current ETA of Block I schematics scanning is ~3 weeks [21:06:52] awesome [21:07:11] Sorry indy91 I just saw these messages, yes they should be set when in a stop [21:07:34] I hadn't added that because the logic was in the CWEA I guess [21:07:39] Right [21:10:11] do you want me to PR that again? [21:10:23] hmm [21:10:27] don't even have to [21:10:33] just changes in DECA code [21:12:11] indy91, I was reading this old post of yours: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=491.msg26165#msg26165 [21:12:21] that MA works now :D [21:14:42] haha, great [21:15:04] indy91 are you changing the DECA code? [21:15:31] I think what actually causes the gimbal fail alarm is not the position being in the gimbal stop, but that the gimbals is commanded to move, but doesn't [21:16:09] Because it is in the stop [21:16:27] yeah [21:17:08] So is that code right? [21:17:15] I already have the logic in the DECA actually [21:17:15] Because I no longer get an alarm [21:17:30] powered && (K1 || K23) && lem->DPS.pitchGimbalActuator.GimbalFail() [21:17:43] but, that GimbalFail() function never returns true [21:18:09] so, I probably will added the gimbal failure in the gimbal actuactor code, not DECA [21:19:06] that should make the light work properly [21:19:18] Ah ok sounds good [21:19:24] The rest of it is wired up and ready [21:19:28] yep [21:19:48] I almost have all the CWEA wired correctly [21:19:55] one side-effect of yesterdays glycol pump CWEA/SCEA fix is that now we get a master alarm during time accel, or panel changes. I know this is expected behavior as the glycol pressure is not too stable during time accel/panel changes [21:20:27] updates pushed [21:20:34] Actually that happened before I believe Alex [21:20:45] But yeah its the stabiity issue with those [21:20:56] Same with the cabin pressure [21:21:04] and suit circuit pressure [21:21:13] lem->eds.GetHeliumPressDelayContactClosed() [21:21:28] that is the function you want to call for the 6 second delay input to the CWEA [21:21:32] Is that direct to the CWEA? [21:21:42] yeah [21:22:03] you would still need the CWEA enable bus logic for the power through the relay contact [21:22:09] but how that bus works... [21:22:12] no idea [21:22:22] basically as soon as you time accel, the pump 1 goes to the pressure switch, then the auto xfer happens. (and momentary ECS and MA) [21:22:26] it's something to do with cycling the breaker at least [21:22:50] before the fix, the ECS light did not come on of course with the auto x-fer [21:24:29] yeah [21:24:45] Ryan, you always choose projects that seem not so bad at first and turn out super complex :D [21:26:05] I know, right? [21:27:37] lol [21:30:43] CW logic, how hard can that be? [21:31:11] can't be worse than the ECS [21:31:16] No [21:31:29] That was/is painful but at least I have an understanding over it [21:31:29] let me know if the gimbal failure light works right now [21:31:37] Sure I am building to test now [21:31:56] hmm, shouldn't the CMC restart light illuminate the LGC warning? [21:32:13] LGC restart light* [21:33:00] I dont know, should it? [21:33:07] CMC and LGC? [21:33:25] On when any LGC power supply signals a failure, scaler fails, LGC restarts, counter fails, or LGC raises failure signal. [21:33:33] in the CWEA description [21:33:34] Channel 163 [21:33:41] Same as it was before [21:33:52] so when you 1st push in the LGC breaker, there is the restart light [21:34:04] but no MA [21:34:18] Then that channel isnt outputting when that happens [21:34:23] Thats an LGC issue [21:34:35] reason im asking is in the A12 activation check there is a note that says you push in the LGC breaker and should get an MA [21:34:38] ah ok [21:34:53] Right [21:35:21] All the CWEA sees is the SCEA and the SCEA sees that channel from the LGC [21:35:33] I know it comes on if you pull the LGC breaker [21:35:43] yes [21:35:48] So its sending something haha [21:36:02] But as far as why the signal is not sent when it is started I do not know [21:36:33] so like you say must be something on the LGC side, or the checklist is not right [21:37:41] gimbal alarm works [21:38:08] nice [21:38:18] indy91, was curious what is DockingInitiationProcessor? [21:38:34] Gotta run to the store, back in a bit [21:39:11] another one of those actual RTCC processors [21:39:30] for now it can only do the Apollo 10 PDI Abort procedure [21:39:43] although with that it should already be fairly flexible [21:40:09] horizontal phasing maneuver, half a rev later, horizontal height maneuver, half a rev later coelliptic maneuver [21:40:19] setting up TPI at the right time [21:40:50] and the height maneuver is basically CSI and the coelliptic maneuver is CDH, both can be calculated onboard [21:41:35] right [21:42:20] it calculates the Apollo 10 PDI abort sequence just as planned [21:42:35] looking quite flexible as you say looking forward t trying that [21:42:50] yeah, I'll give the RTCC MFD a page for it [21:43:03] great [21:45:24] ah damn, P63 didn't iterate [21:46:12] did anyone have that issue on Apollo 10? [21:46:19] hmm [21:46:27] TLAND probably needs an update [21:46:35] I'm like 15 minutes behind schedule [21:47:26] i've had that before lol [21:47:28] I wonder when that would been done on the actual mission [21:47:40] they were about 12 minutes behind as well [21:47:57] DOI target load I guess [21:48:36] maybe MCC can check the difference between planned and predicted TLAND? [21:49:06] yes [21:49:09] and then have it updated if more then a certain value (ie 10 mins) [21:49:25] might have been updated in any case [21:49:31] it's one of the outputs of the DOI calculation [21:49:39] right [21:50:17] I'm looking in the Mission Report Supplement for the GNC Systems [21:50:31] I don't think it has that, but it has something I've been looking for [21:50:55] a graph of the pulse ration modulator characteristics of the ATCA! [21:51:10] the LM-1 Systems Handbook has one as well, but the behavior was changed [21:51:15] for later LMs [21:51:29] so I used the LM-1 one with some modifications [21:51:46] this basically determines if and how often per second the LM RCS is firing under ATCA control [21:52:00] so I will be able to make that behavior a bit better [21:52:06] or at least more realistic [21:52:22] ratio* [21:53:09] nice [21:53:30] I was really excited when I found that in the LM-1 Systems Handbook and really annoyed when the LM-8 didn't have the updated version of it [21:53:57] haha I bet [21:54:08] I have a question [21:54:17] so in the A12 activation checklist, the CWEA cb is reset a few times. Why is that? [21:54:27] or at least one [21:54:32] once* [21:54:42] for the FF? [21:54:50] it does something with some special CWEA buses [21:54:59] we haven't really figured out how it works [21:55:06] but it does reset some things [21:56:47] ok [21:57:27] also shouldn't pushing in the ACTA cb close the CES AC/DC lights? The activation check seems to indicate that [21:57:55] right now you can only reset those with the gyro test switches [21:58:13] not saying the behavior is wrong though, just an observation [21:58:40] ATCA* [21:58:47] I don't the those lights are fully simulated yet [21:58:51] think* [22:00:21] hmm [22:00:27] should be mostly complete though [22:00:31] well pulling the ATCA cb definitely turn those lights on [22:01:52] the activation check has the CWEA reset thing just before it shows the CWEA state (with the CES lights out) so maybe its something related to that [22:02:21] ACT-24 [22:07:20] ohh wait in the Apollo 14 checklist, they are still on at that same part [22:07:47] oh lol nope never mind I cant read tonight [22:12:25] night! [22:35:37] hello @AlexB_88 [22:35:56] hey [22:36:11] just having fun with some ctd-less nassp [22:39:11] happy to hear that [22:39:38] are you testing with apollo 10? [22:42:36] not yet I am not flying any mission right now [22:45:30] AlexB_88, what was that about the CES lights? [22:46:36] oh just that they should be off on page ACT-24 of the A12 activation checklist [22:47:03] but the gyro test switches havent been touched by that point [22:47:11] so in the sim, they are still on [22:47:12] guess i am the only one who is actually flying a mission in nassp [22:47:24] Yeah I need a bunch of RGA data for those [22:47:40] ah right [22:47:42] I have the original condition still on those, ATCA cb power [22:48:02] But realistically I need RGA SPIN MTR logic [22:48:19] Not sure to what end those are simulated [22:49:51] But it appears if the ATCA is not powered, the SCEA doesnt get that data and the light would be on [22:51:08] there is a FF for those, right? [22:51:34] Yeah [22:52:12] so the when the ATCA cb goes in, the FF needs to be reset afterwards in any event I guess for the light to go out [22:52:33] The only thing that resets the FF is the gyro test switch [22:53:08] But that is interesting [22:53:13] right [22:53:21] Because we were discussing the DES REG FF as well, we canot find a way for it to reset [22:53:27] But that also has a cycling of the CWEA [22:53:36] Which made me think maybe that resets them all [22:53:53] so in all cases even with more logic for the RGA SPIN MTR thing, it would still need a FF reset [22:54:00] Yeah [22:54:02] for that light to go out [22:54:11] I do think that the CWEA breaker resets all FF's in the CWEA [22:54:14] Based on procedures [22:54:22] I was thinking the same as you on that [22:54:26] But I cant pinpoint evidence in the AOH or handbooks [22:54:39] It would explain these and the DES REG light we are stumped on [22:55:02] So I have been looking, hopefully I find a smoking gun haha [22:55:09] right [22:55:22] because now there is a FF for the DES REG, too? [22:56:29] Yep [22:56:35] And we cant figure out how it resets [22:56:42] Oh..here is something [22:56:44] The power supply assembly not [22:56:45] only provides operating voltages for the CWEA; it has automatic reset and failure-detection c ircuits . [22:56:45] The automatic reset circuits operate when power is turned on; they reset the master flip-flop and all [22:56:46] resettable CWEA logic circuits . [22:57:13] reset master FF's and all resettable CWEA logic circuits, does that mean the FF's in the individual circuits? [22:58:00] Technically it makes sense [22:58:04] yeah [22:58:12] If the problem condition still exists it would just set the FF again [22:58:24] If not it would issue a reset [22:58:31] Until a condition set it again [22:59:27] I am going to try it and see if it behaves correctly [23:02:46] Its funny my laptop builds these so much faster [23:02:57] I have a beefy i5 in my desktop [23:03:09] But I have a brand new i7 in my laptop [23:04:26] Oh if you feel like testing, could you test my sband cwea light [23:04:40] In CWEA ENABLE, if you have a signal it should be out [23:04:51] I havent tested it yet with a signal on the meter [23:05:38] There is a FF though so you have to put it on reset, get an sband signal, and then on CWEA enable [23:05:55] light should stay off until you lose signal or it gets weak (below 1V or so) [23:06:55] nice [23:17:44] So this resetting the FF's is making everything behave [23:18:38] Looks like the helium pressure in the regulators is a constant 245 so it cannot set off the des reg MA [23:19:16] makes sense [23:19:36] But in the real LM the DPS was not pressurized at that point and the low pressure logic would be true [23:19:44] So I am testing it with low pressure [23:19:48] With the FF reset [23:20:10] Would you be able to test that sband? [23:23:17] sure [23:23:29] "reset master FF's and all resettable CWEA logic circuits" [23:23:45] Yeah [23:23:51] I assume that means FF's [23:23:54] so basically that means just resets all FF's in our code at least [23:24:09] It seems to work with the CES and DES REG problems [23:24:18] Follows the procedure exactly now [23:24:27] is there anything else that could be "resettable CWEA logic circuits" [23:24:40] Not that I can think of [23:24:48] There are 3 master FF's [23:24:57] And every other FF is in a logic circuit [23:25:08] That has to be it [23:25:20] It was a guess earlier today but I am more and more convinced [23:27:40] so basically all the FF's [23:27:46] Yeah [23:28:05] And that seems to mirror the responses in multiple procedures involving a cycling of the CWEA breaker [23:32:03] Sweet sband works [23:34:08] how do you get the gimbal light to come on? [23:35:27] like just for testing it [23:39:51] we should also ask Niklas to simulate the lower RCS pressures when RCS quantity nears 0, so that the RCS caution light can illuminate [23:42:43] Just do a gimbal drive test in V48 [23:42:53] Should come on [23:43:12] ah right [23:44:25] The des reg light should also come on [23:44:30] Actually, no [23:44:35] pressure is normal [23:44:44] So only when we have the pressure simulated properly there [23:45:32] it comes on if you do it before DPS pressurization I think [23:46:16] should ASC PRESS not have a FF? [23:47:25] It is supposed to but doesnt because the pointers Niklas made for those manifolds have a set pressure of 245 [23:48:40] It doesnt [23:49:19] There are two lines of just "+5V" going into the OR gate we havent traced yet though [23:49:45] But it should be if the pressure is too high or two low and it is unstaged the light goes on [23:49:56] right [23:50:16] I am still confused as to why the A12 activation check has that light on at 1st [23:51:04] but Niklas I think noted that the A14 activation does not have that light on at C&W powerup [23:51:22] and that our version is of course based on LM-8 [23:51:33] Hm [23:51:56] Well i would assume it should be on as the pressure is probably low at first right? [23:52:51] well helium is at 3020 already [23:53:23] and that light is based on helium [23:53:29] Ascent [23:53:30] ? [23:53:45] ascent he [23:54:01] So thats why the light is off [23:54:27] The APS diagram shows low fuel and oxidizer pressures also setting off the light [23:54:34] But it isnt in the CW diagram [23:54:48] hmm [23:55:30] CW only shoes the helium high and low and the %V reference [23:56:01] Yet the APS shows 4 sensors, He1 He2 Fuel and Ox pressures [23:56:19] Unless its something feeding that 5V reference [23:57:15] Ah no [23:57:23] fuel and ox pressures are cut and capped [23:59:17] so that light is only he [23:59:44] Yes [00:00:05] This 5VDC reference bothers me though [00:03:00] anyways Im off to bed, cya! [00:03:48] Night! [12:53:37] hey indy [12:54:01] hey [12:54:28] i had a bit to drink last night so i accidentally cleared my quick save folder [12:54:54] but i have an apollo 10 folder an i just have to do lem ejection again [12:55:04] good job :P [12:55:09] yeah [12:55:24] I've never even noticed that button before someone mentioned it here [12:55:38] now I worry I'll press it some time [12:55:56] if your doing a mission just make a seperate folder for it [12:56:08] it only deletes the quicksave folder [12:56:19] yeah, that's how I am usually archiving scenarios of a mission [12:56:34] I rarely think of doing that before I am done with the mission though [12:56:43] and just for fun i decided to do tli and docking over again and in the docking mfd the roll was hitting red a few times [12:57:27] we have special docking code [12:57:39] so I don't think it would be a problem if you are in the red [12:58:00] it was just barely hitting it but it was mostly white [12:59:37] and i guess this is up to ryan but there should be a reminder to switch the suit compressors back after the redundant component check in the checklist mfd [13:03:47] and as for apollo 11 are you gonna skip mcc1 for mcc2 like they did in the real mission? [13:05:30] I'm going to implement some logic deciding if MCC-1 is necessary [13:05:42] and more often than not it won't be necessary [13:05:59] the Apollo 11 mission rules are a bit more specific about this than for Apollo 10 [13:06:34] Apollo 10 also skipped MCC-1, but it was more due to intuition of the flight controllers than any hard reasoning [13:08:46] and is there any way i can add my own sounds, i want to add the flight directors loop for the apollo 11 launch starting at -5:10 [13:17:22] @indy91 i see a sequential editor in the sound folder but i have no idea what to do [13:17:44] hmm [13:18:28] no, that can't currently be done in NASSP [13:18:32] okay [13:20:20] guess i will have to play it through headphones [13:34:34] on apollo 11 if remember correctly they skipped mcc1 to increase the dv to around 20 feet per second according to the mission report [13:37:48] yeah, that allowed for a longer SPS burn [13:38:01] which they wanted to do, to gain confidence that the SPS was working properly [13:56:00] Good morning [13:56:07] hey [13:56:27] I found something interesting in the LM-1 Systems Handbook [13:57:10] in some regards it's more detailed than the LM-8 one. Those LM-8 schematics were flown in the LM, so they had to be useful for the astronauts and not engineers. [13:57:56] anyway, there are some interesting relays that have to do with automatic resetting the CWEA [13:58:22] I am pretty sure that the CWEA breaker cycle does reset all of them [13:58:33] kind of [13:58:37] the comment for it says [13:59:05] good morning ryan [13:59:08] "Relays KA, KB, KC and KD are energized for 0.55 seconds upon initial application of power to CWEA" [13:59:14] just having fun with some ctd-less nassp as usual [13:59:52] astronauthen96__ good to here, also glad windows 10 helped [14:00:15] and the signals through relay contacts are going to the CWEA channel detector logic [14:00:17] yeah and i didn't get it just for nassp it just gave me a reason to get it sooner [14:00:23] and the MA flip-flops [14:00:54] so, if indeed all the CWEA flip flops are reset by cycling the CWEA breaker, then that is how it works [14:01:17] upon closing the breaker again those relays are energized for 0.55 seconds, resetting the CWEA [14:02:14] Yeah I saw that in the master FF & relay driver schematic [14:02:35] the reset signal? [14:02:52] Caused by no power to the CWEA I believe [14:03:25] or as I just explained [14:03:26] :P [14:03:30] Yeah [14:03:35] Makes total sense [14:04:02] we just didn't know if the resetting was happening when you open the CB or when you close it again [14:04:06] And having the FF's reset mirrors the behavior of 2 checklist procedures [14:04:19] It explains the CES lights Alex was talking about yesterday [14:04:33] nd of course DES REG [14:04:41] yeah [14:04:59] I would think when it is closed again when power is applied briefly energizing the relays [14:05:06] the automatic reset signal to the channel detector logic probably works by applying power to the inputs in the CWEA internal logic [14:05:36] so it resets the FFs at the input to the CWEA somewhere [14:07:40] Also i was looking at the ASC PRESS light again, I traced the 5V inputs to the SCEA and it is just a 5VDC reference [14:10:41] simple enough [14:11:05] I don't even want to mention it, but does this also explain the behavior of the RR light? Probably not I guess [14:11:57] Unfortunately not [14:12:15] That FF is reset whenever the switch is in auto track [14:12:29] And I do not recall cycling CWEA much in RR operation [14:15:50] I have been trying to break that down more though [14:18:50] I am wondering if something is wrong with the schematic [14:19:13] as auto track position is needed to both set and reset the FF [14:21:06] the LM instrumentation experience report confirms it [14:21:12] But I think the FF is holding at reset until a no track signal is sent while in auto track [14:21:14] that's how it worked from LM-5 on [14:21:21] Ok maybe this does make sense [14:22:18] *fingers crossed* I might understand this [14:23:09] in other news, I have burned the phasing maneuver [14:23:25] now I'm implementing the calculations for the normal and the backup insertion maneuvers [14:23:32] one thing I noticed though [14:23:38] I don't think Apollo 10 tested P63 [14:24:11] I think they scrubbed it because of LR issues? [14:24:21] I know I have it in my procedures still though [14:24:32] yeah, but the flight plan makes no mention of it [14:24:39] and the mission report has a list of all programs tried [14:24:42] P63 is not one of them [14:24:48] hmm [14:24:59] might have been the CSM list though [14:25:03] no, can't be [14:25:04] "near lunar surface activity"? [14:25:13] the CMC definitely did use P63 :D [14:25:25] near lunar surface activity is mostly the LR testing [14:25:34] section 4 of the flight plan has some details [14:25:57] No P63 mentioned [14:26:18] no [14:27:30] I can remove that and the resetting of MUNFLAG [14:29:41] leave it in for now [14:29:52] I still want to request that LMP Checklist that UHCL has [14:30:05] if we get it, it might have more info [14:30:26] Ok [14:41:27] morning! [14:41:59] I think I have the RR caution logic working [14:49:54] Just testing losing track when in Auto track now [14:51:15] Mostly right [14:51:39] It just wants to reset the FF when moved out of auto track [14:54:54] How does this look? [14:55:06] https://www.dropbox.com/s/j5y1udsmfd4ds61/Screenshot%202018-03-24%2010.54.57.png?dl=0 [15:01:49] that's exactly how I would have implemented it [15:01:52] hey Mike [15:05:25] The only thing I am seeing is the FF is getting reset when the switch is moved out of auto track [15:05:32] Which is not right [15:12:46] ah [15:12:54] if (RRCautFF = 1) [15:12:57] has to be == [15:13:35] Oh thanks [15:13:44] I have made that boo boo a few times [15:16:03] someone once tried to implement a backdoor into the Linux kernel that way [15:16:24] yeah [15:16:38] I said implement, I meant "sneak" [15:17:08] I've seen some coding standards at some high-reliability software places dictate that you must write such comparisons as "(1 == RRCautFF)" [15:17:23] because the compiler will raise an error on 1 = RRCautFF [15:18:34] Really [15:18:34] oh, great [15:18:40] That means a lot of changes [15:18:46] Or a lot of () [15:18:58] seems like a good practice [15:19:27] haha, not suggesting that you change all such comparisons in NASSP [15:19:54] and yeah, I do it less than I probably should [15:20:11] And I can't say that the RTCC MFD is high-reliability software [15:20:28] yeah lol [15:20:59] I think I either picked that one up from JSF++ or the LADEE flight software team [15:21:03] the real RTCC might have been, but it required about as much training to use as a CSM or LM [15:21:33] so taking the RTCC as a good example for anything is probably not a good idea [15:21:45] lol [15:23:52] do we have any RGA systems implemented that can be used for CES caution? [15:24:58] sure [15:25:17] at the top of lmscs.cpp [15:26:21] that's where our RGA is at least [15:26:29] I will need things like SPIN MTR and PICKOFF EXCIT [15:27:56] both CES DC and AC? [15:27:58] And for the DC section, different power checks [15:28:04] No those first ones are for AC [15:28:30] DC needs +/-15, +4.3, and +/-6 VDC CES checks [15:28:31] seems like that is mostly checking a bunch of voltages coming out of the ATCA power supply [15:28:38] Right [15:28:47] Which is why the breaker defines the logic for now [15:28:59] I just didnt know if the other stuff was implemented in any way yet [15:29:17] not for DC [15:29:23] I just checked that [15:29:34] all just different voltages, all generated via the ATCA breaker [15:30:38] Ok [15:30:48] So the breaker should suffice for now [15:31:04] What about the AC section [15:31:29] that is the same breaker but also needs a signal from instrumentation [15:31:40] 3V 1600 PPS FROM INSTRUMENTATION [15:31:43] let me track that down [15:33:35] from the general timing equipment [15:33:58] is the AGC clock used in the PCM, thewonderidiot? [15:34:35] I believe so [15:43:57] then the condition is kind of the LGC breaker [15:44:07] but very indirectly [15:45:54] hmmm [15:46:46] so according to LDW 370-54001, the AGC sends 800pps, 3.2kpps, and 25.6kpps to the PSA, and 3.2kpps to the SCA [15:47:48] "1024 kHz from LGC" [15:48:22] and in the frequency divider of the PCM that becomes, among other things, the 1.6 kHz for the ATCA [15:49:35] ah, that clock, yeah [15:50:59] there it is [15:51:16] it's shown right next to the downlink signals in LDW 370-54001 [15:51:26] goes to the instrumentation drawings which I don't have [15:52:28] guessing sheet 10.00 of that is the PCM [16:06:06] I probably will leave the CES as is for now then [16:06:18] I am going to route the ED warning through SCEA now [16:12:15] So I need the SCEA to read stage sequence relays K1-K6 [16:14:09] that has a bit of logic to it [16:14:27] but it's already implemented as the GetStageRelayMonitor() function [16:15:25] I needed the logic already for the light [16:15:58] So that can be read by the SCEA instead [16:16:50] yep [16:16:56] and then the light reads the SCEA [16:18:57] Looks like the same data is in channel 12 and 14 [16:19:19] with 12 going to the comp lights and 14 the cw [16:21:23] Now to look at preamps [16:21:31] 12 is dual channel, one of them a solid state switch [16:21:58] 12 voltage to telemetry, 12 SSS to the component light, 14 voltage to CWEA [16:22:05] and that is all system B [16:22:45] system A would be the same, just with an addition stage condition [16:25:12] So for 12 and 14 I have this [16:25:13] //ED Relay A K1-K6 (GY0201X) [16:25:14] SA12.SetOutput(11, lem->eds.RelayBoxA.GetStageRelayMonitor()); [16:25:14] //ED Relay B K1-K6 (GY0202X) [16:25:15] SA12.SetOutput(12, lem->eds.RelayBoxB.GetStageRelayMonitor()); [16:30:56] sure [16:31:14] add a stage condition to system A [16:31:28] lem->stage < 2 && lem->eds.RelayBoxA.GetStageRelayMonitor() [16:31:49] In the SCEA? [16:33:02] yeah, then the function can stay the same for both systems [16:33:33] otherwise GetStageRelayMonitor() would have to be changed for just one ED system, which is bad [16:36:08] No problem [16:37:35] Now I am looking at preamps [16:38:13] rcs jet preamp power supplies [16:39:03] Are those simulated? [16:39:42] is that for the CWEA or just SCEA? [16:40:28] Looking now to see where it comes from [16:41:09] Looks like they go into the SCEA [16:41:14] 2/19 [16:41:22] *2/15 [16:42:08] are you looking at the SCEA or the RCS schematic? [16:43:54] That was the SCEA list, I am on the RCS schematic now [16:44:46] I'm not finding what you are looking at [16:45:17] Handbook p141 [16:45:36] Has the two voltages in question in the list [16:45:44] GH1488 and 1489 [16:45:58] I am just trying to find them elsewhere [16:46:42] N/A [16:46:53] not anywhere else in the Systems Handbook [16:47:16] it just says prime and backup -4.7VDC there [16:47:36] how do you know it is preamps? [16:47:49] From the preamps cwea logic [16:47:55] Thats what it is looking at [16:48:08] Those two sensors [16:48:21] Which are in the SCEA [16:49:04] And there is a range in the AOH for them 3.5-4.33 vdc [16:50:12] ok, you probably want ATCA variables [16:50:13] hasPrimPower [16:50:16] hasAbortPower [16:55:33] although [16:55:41] those also have a guidance mode condition [16:56:06] Those variables? [16:59:20] ah, now I see [16:59:26] it's just the ATCA PSA again [16:59:51] ATCA PGNS breaker for the primary -4.7 VDC [17:00:03] and the ATCA breaker for the backup -4.7 VDC [17:00:14] So those can just go in SCEA [17:00:45] well, you need to fake the right voltage again I guess [17:01:27] you could give the ATCA two functions for those [17:01:38] and they return -4.7 if the breaker is closed [17:01:42] and if not, they return 0 [17:02:02] access those functions in the SCEA and the through to the CWEA [17:02:22] hey [17:03:30] Sure [17:04:12] Hey Alex [17:05:37] hey [17:07:26] So would the conditions on PrimPower and AbortPower be right? [17:07:39] And just make those return dummy voltages? [17:08:35] nono, don't use PrimPower and AbortPower [17:08:40] that was wrong [17:09:18] well, kind of. The voltage in question basically leads to those variables being true [17:09:33] because that is the preamps power condition [17:09:50] add two functions to the ATCA return either -4.7 or 0 VDC [17:09:55] returning* [17:10:24] and they return -4.7V if the right CB has power [17:12:03] Ok [17:12:19] Oh that reminds me, can the SCEA scale negative numbers? [17:12:29] I believe I had trouble with that before [17:14:37] I think it should be able to do that, yes [17:14:48] you still have to use the lower number as the first input [17:15:06] scale_data(x, -5.0, -4.0) [17:15:18] hmm [17:15:21] let me check [17:15:25] might not work [17:17:48] should work [17:18:08] maybe you had the low and high number exchanged? [17:19:07] I was doing it for the dB thing before i realized that was wrong [17:19:23] I will see what it does with this [17:20:22] something got probably confused with the logarithmic scale of dB [17:22:01] Ah that makes sense [17:22:06] Well this seems to work [17:22:17] No errors at least [17:29:07] What sends the abort command? [17:29:31] GY0050X in SC1 Ch2 [17:30:36] probably a S&C control assembly [17:34:28] CES instrumentation page [17:34:55] lem->SCS_ENG_CONT_CB.IsPowered() && lem->AbortSwitch.GetState() == 0 [17:35:03] just this in the SCEA I think [17:35:37] SC1/SA2/CH9 [17:35:45] Wouldnt that light the light just before liftoff? [17:36:01] When abort stage is pressed before ignition? [17:36:06] isn't the abort signal inhibiting the light? [17:36:32] also, this is abort [17:36:35] not abort stage button [17:37:04] hmm so when 1st switching LM POWER to CSM after LM ejection, the 2 LM PWR cbs pop out [17:37:24] I was sure that bug was fixed [17:37:28] unless I go LM PWR - RESET 1st [17:39:12] also, when, isn't the C/W PWR and comp lights supposed to extinguish during LM PWR - CSM? [17:40:53] I need to look into the cw power light [17:41:01] But the comp lights would be on the dimmer [17:41:11] right [17:41:12] So they would all be out [17:41:57] whats LM power SYS test again, 4D? [17:43:09] yeah [17:44:37] its showing the same indication (4v) whether LM PWR is off or CSM, weird [17:46:35] stop finding these new bugs [17:46:42] pleaaase [17:46:43] :D [17:48:57] ah right I keep forgetting you're trying to finish Apollo 10 :D [17:53:46] Ok PRE AMPS logic is done [17:55:33] That leaves RCS TCA to be done, BATTERY to be done, and ASC QTY to be checked and see if it needs routing through the SCEA [17:55:34] nice [17:55:55] is RR now done too? [17:55:59] Yes [17:56:05] I believe the behavior is correct [17:56:15] I was overcomplicating it I think [17:56:16] I guess I cant test it [17:56:24] I drew it out in steps on paper [17:56:29] And it seemed to make sense [17:57:01] I also still have the FF's reset by the CWEA breaker for now [17:57:10] I'm not looking forward to the PR, it's probably going to be giant [17:57:16] It is [17:57:28] But you have viewed it in steps along the way [17:57:34] I guess, haha [17:58:38] the FF's reset by the breaker, I guess thats a good solution for now? [17:58:45] Yeah [17:59:01] So far: [17:59:02] https://github.com/dseagrav/NASSP/compare/Orbiter2016...rcflyinghokie:Orbiter2016 [18:00:48] Find as many problems as you can Alex haha [18:00:54] I will be back in a little while [18:25:25] be back later [18:37:15] the insertion maneuver performed by the CSM is a bit tricky to calculate it seems. The RTCC even had a special processor for it. [18:37:29] it's also about the least concentric rendezvous you can have [18:37:39] with the LM "stuck" in a 9x196 orbit [18:40:46] should be fun to try with onboard targeting though [19:53:35] yeah that sounds like fun, haha [20:02:50] gives the TPI search routine a workout [20:24:52] Are these calculations going to make 11's easier since they have more or less been exercised? [20:25:03] In other words easier when you get to 11 MCC [20:33:55] I think so, yes [20:34:14] there are a bunch of procedure differences but all in all, I'll be able to reuse a lot from Apollo 10 [20:34:40] After insertion the calculations are similar of not the same are they not? [20:35:55] yeah. Just calculating the ground solution to the onboard ones for CSI, CDH and TPI [20:39:29] It will be interesting to have that 4th to compare to [20:39:59] I calculated PGNS AGS and CSM solutions during a rdv test and they were all very close I was quite pleasantly surprised [20:40:38] yeah, especially the AGS [20:40:59] I'm sure the ground solution will be nice and close as well [20:42:54] I had fun doing an AGS only rendezvous [20:43:02] First time I had PGNS backup [20:43:16] haven't done that yet [20:43:40] But the second time I didnt even use the LGC other than P20 for tracking, manual RR updates is awful [20:43:50] yeah, I can imagine [20:44:12] guess that's why the RR update to the AGS was implemented in FP8 [20:44:18] Yeah [20:44:32] In other news, only 2 CWEA lights need to be implemented now [20:44:42] Everything else is wired up [20:45:00] I just need BATTERY, which we don't have implemented data for yet, and the RCS TCA [20:45:12] RCS TCA should be easy [20:45:18] Yeah I am about to pull that up [20:45:33] that just needs some changes for resetting the flip flops [20:46:02] That's a lot of logic haha [20:46:20] I believe much of it was done for the tb's though right? [20:46:22] all already implemented [20:46:29] Wonderful [20:47:05] Are the FF's in with the TCA stuff? [20:47:37] yeah [20:48:37] Where are they [20:49:28] lm_rcs [20:49:38] I'm looking for what needs to be changed [20:49:48] it has to do with the CWEA reset bus [20:50:20] CWEA is only looking a the set FF's? [20:52:31] yeah [20:53:15] basically has to check tca->IsSet() [20:53:53] now, I think the behavior with these FFs again confirms that the CWEA can reset them itself [20:54:13] because cycling the CWEA breaker apparently clears the thruster pair flags [20:54:14] So cycling that will reset all TCA FF's as well [20:54:19] I think so, yes [20:55:15] Do you have that in the lm_rcs.cpp? [20:55:56] no, I have the normal way of resetting it in there [20:56:03] which is, closing the valves [20:56:20] so you can close the valve and open it again and that clears the red flag [20:56:30] lem->tca1A.GetTCAFailureFlipFlop()->Reset(); [20:56:52] you probably need to call all 8 TCAs like this for your CWEA cycling code [20:57:07] Ok [20:57:28] and for the light logic [20:57:50] the slightly variant [20:57:52] lem->tca1A.GetTCAFailure(); [20:58:16] so you need you make an if with tca1A || tca1B etc. [20:58:30] slightly shorter* [21:01:23] It will work either way, but is 1 if statement with all 8 "or" better than multiple if's? [21:02:16] make it 1 if statement [21:02:39] less code all in all [21:03:13] Sure [21:04:17] Any connections needed to SCEA here? [21:04:36] a loooot of them. but all already implemented [21:04:40] Perfect [21:04:44] Then that should be done [21:05:38] thrust chamber pressure for all 16 RCS thrusters, jet driver voltage for all 16 and reset signals with valve closure for all 8 TCAs [21:05:48] so 40 SCEA readings are used for this [21:05:52] Yeah i saw those in the scea haha [21:06:01] Nice that the CWEA uses just the FF's [21:06:11] yeah [21:06:35] I just am going to connect 2 more AGS things to the SCEA and I think this is PR-able [21:06:49] Oh [21:06:59] Before I forget, the LM master alarm can be heard still in external view [21:07:07] the CSM doesnt have this behavior [21:07:14] probably a sound setting [21:09:15] ah [21:09:20] here a line of code from the CSM [21:09:21] soundlib.LoadSound(SMasterAlarm, MASTERALARM_SOUND, INTERNAL_ONLY); [21:09:59] just add that to the same line in the cwea? [21:10:11] Seems to not complain [21:10:45] Lets see if it works [21:10:47] ah yeah, it's in the CWEA constructor [21:10:56] so you just added the INTERNAL_ONLY? [21:11:02] that should work, yes [21:12:18] hmm [21:12:40] one thing that I don't like right now is that the code will keep the FFs reset when the CWEA breaker is open [21:13:17] Ah that is true [21:13:45] so probably some code would be good that resets them on the first timestep after the CWEA has power [21:13:58] That also brings back the question are they reset when power is off then on, or when power is off [21:14:20] during the 0.55 seconds after the breaker was closed [21:14:27] I do not know how to do that [21:15:15] you will need to add a bool for that [21:15:53] we are using that kind of logic in e.g. the IMU [21:16:12] there we have TurnOn and TurnOff functions [21:16:43] and those only get called once when loosing power while being on, or being powered while off [21:17:24] Ah i see [21:17:24] I can PR that logic if you want [21:17:45] or you can try to figure it out, your choice [21:17:58] So that would be outside of the timestep, it would reset all the flip flops whenever power is applied from not applied [21:18:26] at the beginning of the timestep [21:18:53] Yeah I want to see how you do it haha [21:19:08] ok [21:19:11] I THINK I know but not completely clear [21:19:54] I am trying to hunt down what exactly sends the AGS standby and warmup signals [21:20:12] AGS switch positions? [21:20:24] I mean I hope it is just that position [21:20:31] But that seemed too simple haha [21:20:50] STBY and WARMUP are two separate signals in the SCEA [21:20:52] page 133 [21:21:27] Ah [21:21:29] it is that simple [21:21:39] for once [21:21:45] Ironically I was on 133 of the AOH when you said that [21:21:59] So I was confused for a moment [21:22:08] "Instrumentation AGS" seems like the natural choice to look for this [21:23:54] do you have a CWEA version in your repo right now that I can work with? [21:25:20] One moment [21:25:51] All set [21:26:12] And if you want to take a look I cannot add any more the the CWEA right now without battery data from an ECA [21:31:43] A few things like some pressure sensors of course have static pressure readings right now but the code is ready for when they have actual numbers [21:32:21] sounds all very good [21:34:22] if (IsLTGPowered()) { [21:34:23] if (IsCWEAPowered()) { [21:34:26] this logic [21:34:47] basically stops the CWEA from operating with the lighting unpowered [21:34:50] which is not right [21:35:28] and there is a check on IsLTGPowered() in the code for lighting all the CWEAs lights anyway [21:35:50] So the top part can be removed [21:36:25] yeah, I'll do that [21:36:32] Go for it [21:36:51] As long as it doesn't stop the CWEA light from turning on still when the CWEA is not powered [21:37:16] I know the MA lights are dimmable, I don't remember if that light was dimmable [21:37:36] Rather the other CWEA lights are dimmable, not sure about MA [21:38:31] yeah, I'll check if that still works properly [21:39:25] Nope not dimmable [21:40:14] But wait, the component lights dont look like they are connected to the dimmer r either [21:42:36] Might be magic within the LCA [21:45:49] does opening the CWEA breaker really always cause a persistent MA? [21:46:56] I'm seeing an auto reset signal going to the MA flip-flops in the schematics, but you will know better [21:47:27] also, that panel changing MA right now is rather annoying... [21:48:50] rcflyinghokie, you did a bad again [21:49:04] What did I do [21:49:08] TCA light is used twice [21:49:14] search for [21:49:14] SetLight(0, 5 [21:49:27] inverter failure [21:49:49] I think the TCA one is wrong? [21:50:16] I fixed it [21:50:21] that will also be in the PR [21:50:25] TCA light is 0,2 [21:50:28] That must have carried over [21:50:36] maybe another bad copy&paste [21:50:45] https://github.com/rcflyinghokie/NASSP/commit/54ce288a4c540c595f19279f2dce734c41402a48#diff-37de294e476be3e43fb1ee6461036b55L228 [21:50:48] Yeah easy to mix up with those [21:51:34] Copy paste [21:51:55] works correct now [21:52:24] And opening the CWEa breaker with the MA breaker in is a non resettable MA [21:53:07] You get the perpetual MA light/tone and the CW PWR light [21:53:14] Unless you pull the MA breaker [21:53:26] so when you cylce the CWEA breaker for some reason, you always get a MA and you need to push the MA button [21:53:37] Yes [21:54:00] I believe the same is true in the CM [21:54:47] From AOH [21:55:18] "The master alarm pushbutton/lights are not resettable when the C/W power caution light goes on [21:55:44] And the MA can only be reset by pressing it [21:55:59] So if it is set by the CWEA power failure, you cannot turn the alarm off unless you press the MA [21:56:09] PR done [21:56:11] Assuming CWEA is powered up again [21:56:24] I see [21:56:50] Haha I did know how to do the TurnOn [21:56:58] Thats what I was thinking more or less [21:57:07] But thank you for doing that [21:57:27] I think I've reused that IMU on/off logic somewhere before, so I had the experience [21:57:35] Makes perfect sense [21:57:49] the CWEA behavior should be really good now [21:58:12] you can set CWEA relays and FFs even with the lighting off now [21:58:22] Good [21:58:27] Now we just need an LCA [21:58:35] yeah [21:58:40] Eventually [21:58:50] Well in that case I think this is ready to be merged [21:59:00] when Charlie Brown and Snoopy are docked [21:59:15] then I'll work on the LCA [21:59:20] Great [21:59:37] I think i will head back to those LM PRESS and TUNNEL VENT valves [22:00:03] we have to do something about those panel switching MAs though [22:00:34] what are they cause by again? [22:00:38] caused* [22:00:40] I think its the glycol [22:01:06] yeah [22:01:07] Likely the dP being wrong for a moment [22:01:55] your LM ECS has become very good, just that one flaw that it doesn't deal well with sudden longer timesteps... [22:02:59] Yeah without cheating I am not sure how to approach the problem [22:03:29] we'll think of something [22:03:41] I'll take a good look at the PR in the morning and will merge it then [22:03:44] good night! [22:03:49] Sounds good, night! [22:03:54] good work today [22:06:12] hey ryan [22:06:20] there is a small minor error in the apollo 10 checklist [22:08:31] @rcflyinghokie for tli at DET 58:20 it calls for N62 and some other things but it occurs at 57L20 [22:08:56] Let me have a look [22:11:23] Might be a timing thing [22:12:44] Yeah these might have been Apollo 8 numbers I will recalculate and see [22:13:38] and for the docking, after the "manual maneuvers" it calls for V49 to maneuver to the inputted docking angles and it takes a really long time for the yellow marker to appear [22:13:49] so i just press pro in the mfd [22:15:01] What yellow marker? [22:15:12] And you are right about the times, thanks for catching that [22:15:37] the flashing yellow think the the checklist mfd [22:16:56] Anytime it is yellow in the mfd it means you have to hit pro or fail to keep going through it it is not automatic [22:17:36] Oh I know what you mean [22:17:42] there is a "hidden delay" there [22:17:55] Not quite sure why [22:18:00] I can remove it [22:19:41] and the hidden delay was on 11 as well [22:19:57] Yeah [22:20:01] Probably a copy paste thing [22:21:22] Yeah it came from apollo 9's checklist [22:21:35] I needed the delay to terminate a P47 which was used for that TD&E [22:30:59] It will be added with the next merge [22:39:21] hey [22:39:25] Hey [22:39:31] CWEA has been PR'd [22:39:45] Everything is connected other than the BATTERY light [22:40:14] beautiful [22:40:19] Also astronauthen96__ found some of my bad math in the TLI checklist timing :P [22:40:25] So that is with the PR [22:40:31] okay [22:40:52] hooray for CWEA! [22:40:54] what's next? [22:41:05] hello mike [22:41:10] yo [22:41:21] Probably playing with the LM tunnel some more [22:41:24] just having fun with some ctd-less nassp [22:41:38] I also plan on implementing a TLE [22:41:53] Should complement an LCA nicely [22:41:58] Though I think they are separate [22:42:15] I do not know either of those acronyms lol [22:42:25] have you guys found out a way to create the lem before lem ejection? [22:42:25] Tracking Light Electronics [22:42:32] Lighting Control Assembly [22:42:43] aha, nice [22:42:56] rcflyinghokie, any way to test the RR light? [22:42:58] astronauthen96__ not yet, but there are potential options for later down the road [22:43:17] I tried losing track on purpose but cant seem to get the RR light on [22:43:28] Sure, get a lock on the command module in LGC, then switch to auto track [22:43:32] then lose the lock [22:43:46] hmm I tried that [22:44:07] I did too and it worked for me [22:44:22] lose the lock by maneuvering the LM? [22:44:24] yes [22:50:17] You need a good signal before switching to auto track to set the FF [22:50:32] Then if track is lost it turns the alarm on [22:52:46] Hm [22:52:56] It worked before, why isnt it now... [22:53:09] hmm I have the meter locked on with signal strength 4 and manually losing lock, no alarm [22:53:17] Mine did earlier [22:54:29] Wonder if it is this else if [22:55:15] I will figure this out [22:55:23] It was working before [22:55:44] But I think I know why it worked even though it was wrong [22:56:23] looking through the code in the CWEA, this line popped out: [22:56:24] else if (lem->RendezvousRadarRotary.GetState() == 0) { RRCautFF = 0; } [22:56:49] Yeah [22:56:54] thats the else if I referred to [23:00:04] Its holding the FF at reset [23:01:52] hmm I commented out the else if and it worked [23:02:18] Right but then you cannot reset the FF [23:02:40] right [23:04:07] The reset should only happen when it is first set to auto track [23:04:15] And not held in reset [23:04:33] So how do we tell it to look for it moved out and back into autotrack [23:05:56] I wonder if I need another bool in there to do that [23:06:04] Unless a while could work [23:06:22] Something to say if the switch is not in auto track then moved to auto track, reset [23:07:16] yeah [23:08:05] I will try a while [23:08:54] I know why it worked before though, it was my using = instead of == [23:09:07] it set the flip flop and coincidentally did it at the right time [23:13:49] Hmm I cannot load orbiter with that while loop [23:14:24] So i guess it won't work [23:15:30] Unless I can cheat with an else [23:16:31] But then it will reset even if not in auto track [23:16:59] wait [23:17:13] if (lem->scera2.GetVoltage(2, 1) > 2.5 && lem->RendezvousRadarRotary.GetState() == 0) { RRCautFF = 1; } [23:18:11] the >, is actually a < in that line, in the code right now, is that correct [23:19:14] Yeah its a < [23:19:22] Which means good signal [23:19:29] right [23:20:14] so if there is a good signal. combined with the RR rotary to auto-track, then the FF is 1 [23:20:25] Yes [23:22:51] should that FF not be initialized up at the top of CWEA.cpp? [23:22:59] oh it is [23:28:09] I might have an idea [23:28:11] Let me try it [23:32:41] Nope [23:33:43] I thought the else if would work in this case [23:34:22] what about [23:34:23] if (lem->RendezvousRadarRotary.GetState() == 0 ){ [23:34:24] if (lem->scera2.GetVoltage(2, 1) < 2.5) { RRCautFF = 1; } [23:34:24] else { RRCautFF = 0; } [23:34:24] } [23:35:24] That would reset the FF if the signal was bad [23:35:47] I dont think thats actually how it worked but it SHOULD yield the desired behavior [23:36:40] I dont have anything that says it has to be cycled to reset [23:36:44] So it could be right [23:37:22] Actually looking at the logic that might be correct [23:37:25] My brain is tired [23:37:50] I tried my thing, but it did not work :( [23:40:07] I will give it a go [23:40:15] I am watching the FF [23:42:44] No the FF resets as soon as track is lost [23:42:58] The alarm needs the FF set, bad signal, and in auto track [23:44:10] So I do think it needs to be moved out of auto track and back in to reset [23:45:50] The reset condition allows it to be in auto track with a bad signal without an alarm [23:46:05] If it gets a good signal while in auto track, the FF is set [23:46:39] And that set is held until, well, that is the question now [23:46:57] I really think cycling it is the trick [23:47:53] So back to the question, how in C++ do i tell it to look for it not in AUTO TRACK and then back in AUTO TRACK [23:48:05] Because I think that is the answer [23:49:21] if (lem->RendezvousRadarRotary.GetState() != 0) { [23:49:21] if (lem->RendezvousRadarRotary.GetState() == 0) { RRCautFF = 0; } [23:49:22] } [23:49:27] instead of the else if [23:49:32] Thats exactly what I just put in [23:49:42] line for line [23:49:46] haha [23:49:49] Great minds? [23:50:07] I just hope that doesnt cause a conflict [23:53:04] Here goes nothing [23:53:52] well it gave the RR warning [23:54:06] dont know if the FF is set or reset properly though [23:55:37] The only problem is if I flip from auto to say lgc and back I get a very brief light [23:56:07] If the LGC has a no track condition [23:56:18] or from slew and back [23:57:00] the FF properly sets itself again [23:57:21] But I cannot see if it is resetting [23:57:44] Nope [23:57:47] not resetting [23:59:43] .tell indy91, so the RR caution logic is flawed, I'd hold off on a PR, the else if cause it to perpetually RESET, so we are trying to figure out a way to tell it to reset if moved out of and back into auto track [00:01:40] I mean we could cheat and make it reset when moved out of auto track [00:01:56] But that isnt the right behavior [00:02:05] It would work right in the sim [00:05:19] I am adding a intermediate boolean [00:05:56] It keeps track of the switch being changed [00:07:08] bool AutoTrackChanged = 0; [00:07:08] if (lem->RendezvousRadarRotary.GetState() != 0) { AutoTrackChanged = 1; } [00:07:09] if (lem->RendezvousRadarRotary.GetState() == 0 && AutoTrackChanged) { RRCautFF = 0; AutoTrackChanged = 0; } [00:12:37] let me know how it works out [00:12:46] anyway im off to bed, night! [00:14:26] Night