[21:24:49] Meeting started by thymo [21:25:13] without speaking permission? what kind of oppression is this? :P [21:25:32] Meeting chairs are: alexb_88, rcflyinghokie, thewonderidiot, indy91 [21:26:02] I need a Gene Kranz "discipline in the room" button [21:26:03] I'm not sure yet exactly. Maybe it doesn't log stuff unless you're 'seated'. [21:26:43] I want to write a wrapper/modify around meetbot to better suite it to our needs. [21:27:13] yeah, having to .action everything seems really tedious, it would be much better if it logged directly and passively [21:27:23] It does [21:27:24] https://vanbeersweb.nl/irclogs/%23nassp/2017-12-26-21:24_AGC-talk-and-misc-.log [21:27:38] The actions are just for the summary page. https://vanbeersweb.nl/irclogs/%23nassp/2017-12-26-13:22_Untitled-meeting.html [21:27:38] oh cool [21:27:58] nevermind then :D [21:29:10] I want to add in some kind of mute function. Then we can leave it running (maybe auto restart once a day) and mute it if we want to discuss something outside the logs. [21:29:14] indy91: lock the doors, nobody comes in or leaves the room until we've either landed or aborted :P [21:29:29] or crashed [21:29:31] yeah that would be great [21:29:33] no, more like, "keep the shouting to a minimum" [21:29:51] seems like a good guideline for meetings as well [21:36:01] ...Aaand when the logging starts the discussion dies :P [21:36:13] clearly too much pressure [21:36:26] I have stage fright :P [21:36:46] Haha I was thinking the same thing [21:37:05] of course, thats how it always is. Its like when the pilot turns on the seatbelt sign and then the turbulence stops :D [21:37:31] We just want to keep you in your seats ;) [21:37:48] so about the ECS [21:38:18] when you have done the initialization changes and give the OK, I'll do the fun merging process [21:38:37] Sounds good [21:38:45] VS is still acting up unfortunatly [21:39:09] and then Thymo and I will work on SCEA/CWEA, but generally we should be able to start testing [21:39:16] Yeah about that [21:39:19] I'd suggest we use the Apollo 11 launch scenario [21:39:28] and start testing from a pre LM ejection scenario [21:39:40] How detailed should I make it. Every single opamp that's in there like you did with the ED? [21:39:56] every flip flop [21:40:13] but otherwise it's mostly some logic? [21:40:57] A lot of comparators yeah [21:41:19] Been thinking about modelling the power supply with the different internal voltages to some extent. [21:41:30] I'm seeing a lot of flip flops, those need to be simulated and their state be saved [21:41:49] I don't think we ever properly simulated different voltages [21:42:03] so for now that seems a bit excessive [21:42:57] we already had a lot of CWEA code, it doesn't have be completely rewritten [21:43:25] make it use the SCEA, add anything that can be set and resetr [21:43:27] reset [21:43:44] If we're gonna model every bit of logic a lot of it will have to change/ [21:43:55] Is telemetry in the LM up yet? [21:43:59] yes [21:44:36] what do you need it for? CWEA telemetry readings? [21:45:14] the CWEA doesn't use telemetry directly, as in, encoded by the PCM [21:45:15] Downlinking master alarm and c/w power fail readings. [21:45:21] ah, right [21:45:36] I have a VS question for you guys, I just repaired mine on my laptop and now I have so much red in there, numerous identifiers are undefined [21:45:49] It says it successfully builds though [21:46:14] I've had that as well [21:46:16] Might be Intellisense not having scanned the solution completely. [21:46:21] when I set it up on my netbook [21:46:25] it got a bit better over time [21:46:31] There's is a option to rescan it somewhere in the toolbar. [21:46:34] I still occasionally get a lot of red [21:46:45] I have 991 errors [21:46:56] Otherwise peeking definitions of random stuff might fix it. [21:46:59] things like DWORD and HINSTANCE [21:47:03] yep, same [21:47:13] Ok [21:47:14] I think that is Windows SDK related [21:47:15] but I am not sure [21:47:22] Well as long as it builds on here I am ok [21:47:24] Thymo, it's well documented in lm_telecom.cpp where you have to put new readings [21:47:35] e.g. "// Bit 4 = Master Alarm On" [21:49:22] but that again seems to be handled through the SCEA discrete inputs buffer [21:50:33] so the PCM/telemetry code should access the SCEA for the master alarm [21:50:37] and not directly the SCEA [21:51:26] so just focus on writint CWEA code [21:51:31] not SCEA or even PCM [21:53:13] I'm looking at schematic 9.4 in the LM Systems Handbook [21:53:19] PDF page 110 [21:53:41] CWEA has 3 latching relays, one closes a switch for the SCEA [21:53:52] all I need is a Get function to access that relay state [21:53:54] I'm looking at it too [21:54:35] that get function will be used in the SCEA code and from there on to the PCM [21:54:45] so "your job" is only up to that get function [21:55:01] and everything inside the CWEA [21:56:23] hmm, so about CWEA voltages [21:57:04] the logic for it still needs to be there, similar to the CSM. If the CWEA is unpowered (breaker pulled) then the CWEA isn't dead [21:57:15] in the procedures you often pull the breaker [21:57:27] I guess that resets the latching relays? [21:57:42] ah, "CWEA Reset Bus" [21:58:22] Looks like the master alarm relays are also triple redundant. [22:01:06] and C/W power fail is another reading for the SCEA [22:01:10] Completely unrelated but look at drawing 9.1 all the way on the left [22:01:28] Looks like there's some GSE inhibit for the telemetry. Quite interesting. [22:01:50] yeah, I've noticed that when I worked on the SCEA [22:01:56] quite interesting indeed [22:02:07] It's not an inhibit. [22:02:43] They can enable telemetry on the pad by tying it to the DC BUS VOLT breaker. [22:03:22] probably only can get telemetry on the pad that way [22:03:33] but they don't want it enabled at all times [22:03:41] just for prelaunch checks, close to launch maybe [22:04:45] I'd give implementing that a very low priority [22:04:50] we can't even run the LM on the pad [22:06:04] There's a lot of GSE stuff that can be put in storage for later. [22:06:22] Someday I want to be able to do fuel cell activation :D [22:06:26] yep [22:06:52] The GSE interface for the AGC would be cool too. [22:07:05] launchpad technician simulator [22:07:27] Simulate the plugs-out simulation [22:07:34] right [22:07:41] what fun stuff can GSE do with the AGC? [22:07:56] how did they change the padload in the case of a scrub? [22:08:02] is there a GSE uplink? [22:08:06] I think things like examine memory, change certain things [22:08:12] Uplink too I believe [22:08:21] thewonderidiot: knows all about it. [22:08:53] LGC padload wasn't changed I believe, at least not for a next day launch attempt [22:08:59] Thymo: I have a gif [22:09:01] CMC had to be changed every day [22:09:05] one sec [22:09:56] Thymo: I wrote a JTAG implementation of the AGC monitor, which is what they plugged into the test connector -- this shows me typing into a script attached to the monitor, running signals into the FPGA [22:09:57] http://i.imgur.com/hswwvfE.gif [22:10:34] through the test connector you can read/write any channels, read/write any erasable memory, jump to any location and let it run, pause it between instructions or between MCTs, stimulate power supply failures, and a few other things [22:11:40] Nice [22:11:45] Did you put that on git? [22:12:09] would they have the test connector connected on launch day still? [22:12:25] no, the CH77 restart monitor would be plugged in for flight, so the crew can query it [22:12:43] ah, that uses the same port or so [22:12:52] some things, like power supply failure simulation pins, also go out to the main spacecraft connector, so that stuff can still be tested [22:13:26] launch day uplinks to the CMC would be another source for padloads [22:13:41] that's just through the regular uplink interface though [22:14:07] yeah, that just came into my min [22:14:08] mind [22:14:16] Thymo: https://github.com/virtualagc/agc_simulation/blob/master/de0_nano/jtag_monitor.v [22:14:34] that's the actual monitor implementation, with descriptions of every test connector pin [22:14:49] https://github.com/virtualagc/agc_simulation/blob/master/de0_nano/scripts/jtag_monitor_server.tcl [22:14:58] and that's the script that talks to it over JTAG [22:15:07] Is it able to talk with yaAGC too? [22:15:12] hahaha very no [22:15:22] Still using yaDSKY? [22:15:25] you need a hardware AGC for this stuff [22:15:32] wants one [22:15:43] yeah, via https://github.com/virtualagc/agc_simulation/blob/master/scripts/dsky_server.py [22:16:13] that's a script that reads FPGA pins and wiggles other pins, and exposes stuff on ports for yaDSKY [22:16:26] I wrote that to hold me over until I get a physical DSKY going [22:16:43] For the upper hatch, is the threeposswitch position for open/dump UP or DOWN [22:16:44] you can make your own hardware thing with a DE0-Nano and a beaglebone ;) [22:19:12] rcflyinghokie, state = 0 is DUMP [22:19:17] state 1 AUTO [22:19:20] state 2 is CLOSE [22:19:26] I have a raspberry pi. Will that suffice. :P [22:19:33] Half of the GPIO is broken [22:20:36] probably not :P [22:21:09] https://www.youtube.com/watch?v=yvAVeP8KLGo [22:21:32] that should give you a feel for how many pins you need -- for yaDSKY the wires going to the dev board also have to go to the beaglebone [22:21:38] June 2016 [22:21:41] and that's all DSKY stuff [22:21:48] yeeeaaaah [22:21:51] I know, I know [22:21:58] I've been working on this stuff for way too long lol [22:22:07] seem like it, haha [22:22:21] some guys named Don and Niklas showed up and threw all sorts of wrenches in my plans [22:22:30] indy91 there arent any states in the defaults for that switch [22:22:45] I like clicky relay sounds [22:22:51] UpperHatchReliefValve.Register(PSH, "UpperReliefValve", THREEPOSSWITCH_CENTER); [22:23:08] THREEPOSSWITCH_CENTER is defined as 1 [22:23:25] that is the default state of the switch [22:23:31] which is wrong [22:23:36] isn't it in dump? [22:24:00] on the launchpad [22:24:50] then it would have to be THREEPOSSWITCH_DOWN. Down equals 0 equals DUMP [22:27:04] but it doesn't make much sense to use those identifier for those special switches [22:27:28] it's not an actual up position of a normal three position switch [22:27:49] Well that is how it is written right now [22:27:55] I haven't touched it yet [22:28:16] just replace THREEPOSSWITCH_CENTER with 0 [22:28:23] Ok [22:28:24] instead of replacing it with THREEPOSSWITCH_DOWN [22:28:31] which would also be 0 [22:28:34] There are a few switches that do that [22:29:04] if anything that should have its own #defines to be useful [22:29:20] like e.g. DUMPVALVESWITCH_DUMP, AUTO and CLOSE or so [22:29:26] but 0 works as well :D [22:29:36] Ok cool [22:30:04] I can do the same for the CO2 [22:30:09] CO2CanisterSelectSwitch.Register(PSH, "CO2CanisterSelectSwitch", TOGGLESWITCH_UP); [22:30:17] And the hatch handles too I suppose [22:30:41] are those default states also wrong? [22:30:48] No [22:31:04] I wouldn't both changing anything else, unless you know the default state is wrong [22:31:06] bother* [22:31:11] Ok easy enough [22:31:15] too much work [22:32:04] well, good to be back. cya all tomorrow, good night [22:32:20] Night! [22:36:21] And now my vs has a bunch of question marks when I view all references and it has been stuck on "previewing the file" with a little green bar for about 5 minutes [22:38:57] https://www.dropbox.com/s/iu8i1uhngfvbr8u/Screenshot%202017-12-26%2017.36.32.png?dl=0 [22:43:20] lol [22:43:27] And I finally had to terminate the process [22:43:38] it's going downhill :P [22:43:48] Frustrating laptop [22:46:40] Odd that this started after I repaired VS [22:47:04] I cant view references or peek definitions without that preview just hanging [22:52:04] hello [22:54:03] hi [22:55:11] Hey [22:56:08] does anyone know when the next build will be released? [22:57:26] NASSP 8 beta builds are released with every commit made. We might release v8 to stable in a couple of months at most. Whenever we finish the major systems in the LEM. [22:58:02] We're definitely making a lot of progress. We're almost finished with the implementation of the LM ECS. [22:58:32] did anyone find a bug where it crashes to desktop with the lem injection checklist in apollo 11? [22:58:48] rcflyinghokie? [22:58:59] You mean LM ejection? [22:59:03] yes [22:59:19] I believe Alex mentioned something about that and it was fixed I think [22:59:59] okay [23:00:04] But I thought that was in the ECS branch and not the main repo [23:00:08] Do you get ti regularly? [23:00:10] it* [23:00:14] I assume you're still using NASSP 7 on Orbiter 2010? [23:00:25] no this is in v8 on orbiter 2016 [23:00:37] Using the 2016 latest beta [23:00:41] yes [23:00:49] what do you mean by the latest beta? [23:01:03] There is a new beta version of Orbiter 2016 we are using [23:01:30] Has some physics fixes that are necessary for NASSP 8 [23:01:39] maybe that is the problem [23:01:46] do you have a link to it? [23:01:50] NASSP will work on either Orbiter release or beta. I still run the release version without issues. [23:02:01] Partly because I'm too lazy to upgrade. :p [23:02:19] yeah it happens during the lem ejection checklist its if i switch views or press a button [23:03:13] indy91 said that there was some work done recently in that area maybe its a new bug [23:03:28] Alex was having that issue as well [23:04:03] There was some view bug fixed a couple of days ago but I think that only affects the VC. https://github.com/dseagrav/NASSP/commit/e60fa56f59296f0b4702f182793794b74c90bb68 [23:05:08] No that was for any view [23:05:09] I am pretty sure [23:05:18] and does anyone know where i can find that 2016 beta [23:05:53] Yeah one sec I will link you [23:07:01] http://orbit.medphys.ucl.ac.uk/betainstall.html [23:07:10] And here is the new DX client you need [23:07:17] https://www.orbiter-forum.com/showthread.php?p=565651#post565651 [23:07:48] Ugh. Does Martin really still use SVN? [23:09:11] better than CVS or no version control [23:10:00] Yes [23:10:02] and im just trying to figure out how to calculate the sps evasive maneuver on apollo 11 [23:10:28] Do you have the flight plan? [23:10:41] i think so [23:11:00] would it be in there [23:11:42] No, the checklist MFD has the flight plan for the most part but we encourage using the actual flight plan as a follow along reference [23:12:34] okay [23:12:51] Flying a mission we have not set up the MCC support is a challenge unless you know how to use the RTCC MFD to calculate the maneuvers [23:13:16] I do not think we have a tutorial on that yet, unfortunatly [23:13:54] i believe that some of the numbers are in the flight plan is that correct? such as the landing site data [23:14:02] Yeah [23:14:07] https://history.nasa.gov/alsj/a11/a11fltpln_final_reformat.pdf [23:14:12] Theres the flight plan [23:14:20] https://history.nasa.gov/alsj/a11/A11_MissionReport.pdf [23:14:31] And in the mission report you can find a summary of the burns made [23:17:42] Hope that helps a little! [23:18:25] yes thank you [23:28:03] But the RTCC MFD is your best friend and worst enemy for getting to the moon [23:28:10] Because you need that for all of the targeting [23:28:41] Thats how you calculate your burns that will aim you into the proper trajectory for lunar orbit insertion [23:29:05] And you also use it for DOI, PDI, ascent, and of course TEI and reentry [23:30:36] Soon enough we will have a mission control to help you make those calculations along the way (as we already do for Apollo 7 and 8) [23:45:24] and is the sep attitude in the tli pad in the rtcc mfd accurate? [23:47:50] if not then ill just have to use V16E N20E and the calculate it i guess [23:55:38] I'm off to bed. Goodnight! [23:57:11] Night! [00:25:11] hi [15:23:20] Good morning [15:27:06] hey Ryan [15:27:57] I think I have most of the initialization done, just cannot check to be sure [15:29:20] I am working on moving the ecs switches into the checklists, but if you have a few to check my latest state of the ECS repo to see if it looks right that would be a big help [15:30:21] will do [15:36:48] hey [15:37:43] Mornign Alex [15:37:56] For this line: [15:37:57] UpperHatchReliefValve.Register(PSH, "UpperReliefValve", 0); [15:38:16] Would the switch be upperhatchreliefvalve or upperreliefvalve [15:38:47] UpperReliefValve [15:39:56] hey Alex [15:40:20] Great the I did it right [15:48:58] ho [15:49:02] hi [15:49:53] recently i was having problems with crashing to desktop during the lem ejection checklist and i switched to the latest 2016 beta and it doesnt seem to be crashing maybe that was the problem [15:49:53] hello [15:50:46] could be. I'd say NASSP is currently quite buggy, but things will improve from now on [15:50:55] okay [15:51:55] but if it happens again then I'll check if I did something wrong with a few recent changes to LM ejection related stuff [15:53:08] oh wait, you said you switched to the latest Orbiter beta and that fixed it? [15:53:13] yes [15:53:30] hmm, that is interesting [15:53:49] are you using the NASSP builds from Github? [15:53:54] or are you building from source [15:54:00] yes i am on the latest one 926 [15:54:20] good, good [15:55:16] also, welcome to the NASSP chat. If you have any other issues, feel free to ask for help here. [15:55:24] i think you mentioned in another thread that the latest beta had a fix for proper docked operations of the csm and lem [15:56:01] indeed, Orbiter calculated the moments of inertia of docked vessels in the wrong way [15:56:13] so the AGC software couldn't always deal with that [15:56:27] and i am just trying to figure how to calculate the sps evasive maneuver after lem ejection [15:56:38] Apollo 11? [15:56:41] yes [16:00:58] not sure if that only applies to Apollo 10, but it could be a simple constant DV applied at a specified attitude [16:01:02] specific* [16:01:28] yeah the dv is in the flight plan [16:02:19] and the attitude is 75° below local horizon [16:02:29] the 19.7 ft/s were executed exactly like that [16:03:25] what do you mean by local horizon? [16:04:00] 75° pitched down relative to the local horizontal. So almost pointing exactly at the Earth, just 15° away from it [16:04:16] yes kind of like apollo 8? [16:04:24] yeah [16:04:28] okay [16:04:30] you can pretty much use the planned TIG and DV for the burn [16:04:32] in P30 [16:04:49] the DV vector for P30 would be: +5.1, +0.0, +19.0 [16:04:54] and TIG as per flight plan [16:05:04] and i believe the weight is located in the maneuver pad in the rtcc [16:05:49] yeah, on the Maneuver PAD page you can input the TIG and DV and then calculate a Maneuver PAD for burn [16:05:54] that will include the weight [16:05:58] yes [16:06:17] and would the tli pad have an accurate sep attitude [16:07:00] the calculation of that attitude has had a bug for a long time unfortunately [16:07:28] so I wouldn't 100% trust it [16:07:30] yeah so i just do the back with the V16 N20 [16:07:35] back up [16:07:39] yep, that works [16:08:35] and it is my understanding that nassp 8 only supports the latest 2016 beta is that correct [16:09:47] it should be backwards compatible still, so using Orbiter 2016 would be fine [16:10:05] except for the docked burns which were the reason use the beta from now on [16:10:21] docked SPS burns should be fine in either Orbiter 2016 or the Orbiter Beta [16:11:12] Docked burns controlled from the LM are the big issue, but they were only done on Apollo 9 (planned) and Apollo 13 (not so much planned) [16:12:02] and i think someone mentioned that the landing sites were pre loaded in the rtc mfd so if i do a mcc what numbers would i need and could i do them with the exact tig in the flight plan [16:12:53] yeah, you can use the exact TIG from the flight plan [16:13:33] so for the MCCs there are a few options available [16:13:43] what you want for MCC-1 is option 2 [16:14:19] yeah [16:14:20] "TLMCC Option 2: FR BAP, Fixed LPO, LS" [16:14:45] and what numbers would i need to know and would they be in the historical documents? [16:15:06] yeah are in the historical documents, but most of them should already be in the RTCC MFD [16:15:13] so it's mostly the TIG you need to input [16:15:22] okay [16:15:41] so mcc1 could be at 11:45 [16:15:42] option 2 gives you: free return (FR), best adaptive path (BAP, meaning DV optimized), fixed lunar parking orbit (LPO) and a landing site (LS) flyover [16:16:31] according to the mission rules, MCC-1 is planned for TLI cutoff plus 9 hours [16:16:47] that should be about 11:45, yes [16:16:57] yes [16:17:21] and is it the same for loi [16:24:51] LOI TIG can be quite variable [16:24:58] the timing is pretty critical [16:25:24] for the MCCs that is not the case, plus minus a few minutes doesn't make much difference [16:25:37] So going through the checklists there may be an issue with astronauts using the PLSS and the way the ECS setup is, if you have an astronaut in the suit and then follow the instructions to disconnect from the LM you effectively cut him off from LM consumables [16:25:43] the LOI calculation page of the RTCC MFD will give you the right LOI TIG [16:26:23] Now of course he is on the PLSS, but the PAMFD ECS status check might see that astronaut's suit as empty and "kill" him [16:27:22] Simple solution is to just to set "0" in that suit and "1" in the other suit I think but it might be a bridge to cross if we ever implement PLSS's [16:28:43] rcflyinghokie, I wouldn't worry too much about the PLSS yet [16:29:04] disconnecting from the LM simply means he uses neither LM nor CSM consumables [16:29:11] that is the most important part for now [16:29:52] and what do you mean with the ECS status check? [16:30:22] oh, I think I understand [16:30:36] the current setup requires crew to be moved from the suit to the cabin before you can remove it [16:31:25] so just before EVA you would have the crew for a short time in the empty cabin, which is rather unhelathy [16:31:29] unhealthy* [16:31:34] Yeah [16:31:49] maybe we need a simple EVA simulation then [16:31:55] another button to start EVA [16:32:12] will there be evas in v8 or is it not until v9? [16:32:16] I could implement a PLSS tank with a simple ATMREGEN like the CM has [16:33:23] Or maybe even more simple, an eva button that just takes the astronauts out of the LM consumables but doesnt kill them similar to setting crew to zero [16:33:47] yeah, I think in V8 that is all we need. A button to start EVA and something to end it [16:34:08] PLSS simlation together with Apollo 12-14 support is for V9 [16:34:34] we still have a bunch of very old code for EVA [16:34:42] I'll check if there is a simple way to use it [16:36:16] there are some old EVA related flags and events in the LM code, I wanted to either remove or use that anyway [16:39:22] we have two EVA Visual Studio projects even [16:39:42] one for the lunar surface and one in space, like done on Apollo 9, 15-17 [16:42:24] Well I can keep the checklists as they are if we can add that eva situation to prevent the astronaut from "dying" [16:43:24] I think we should work our way through the mission with the merged ECS and fix bugs and add features like a bit of EVA support along the way [16:44:07] Sure [16:44:12] so you can't really have a final ECS checklists version right now anyqay [16:44:14] anyway [16:44:26] Nope just adding the switches to my placeholders [16:44:34] right [16:47:03] any chance I can do the ECS merging today? [16:47:13] or do you want to work checklists until they are done [16:47:17] work on* [16:48:49] No feel free [16:48:59] The checklists are a simple addition later [16:49:14] Were you able to check the initial states? [16:49:26] I will check very soon [16:49:42] are you adding the checklist stuff in the LM ECS branch? [16:50:07] I am currently, yes but once you merge I can just start changing it in the main [16:50:27] I have only dealt with Apollo 9 [16:50:39] I am about halfway through it's LM checklist [16:50:58] hmm, that's not quite as simple [16:51:24] you already did some commit(s) for checklists in the LMECS branch [16:51:27] Yes [16:51:32] so it is different from the Orbiter2016 branch [16:51:47] Right and those would replace the ones in the 2016 branch [16:52:11] you are just causing issues for yourself when you switch to using the Orbiter2016 branch [16:52:25] because you have local changes [16:52:39] What I will do is save the excel files locally somewhere else [16:52:43] It would be better to stop working on the checklists, commit it all [16:52:55] and have no local changes then [16:53:02] and then start working on it again when it's merged [16:53:03] Ok I can do that I can stop at any time [16:53:39]