[22:06:40] NASSP Logging has been started by thymo [22:10:08] okay I think I might be done with the tricky ones [22:10:17] the CDU drive counters are nice and simple lol [22:16:05] yeah and all 5 are identical [22:33:34] hmm, I should get a second DE0-Nano [22:33:47] it would be fun to have two AGCs communicate to each other via OUTLINK and INLINK [22:35:39] would like any hardware AGC/FPGA. :p [22:37:54] you're in college right? you could try to get an academic price for one [22:37:58] https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=593&PartNo=7 [22:38:05] $61 USD with academic pricing [22:38:44] Nice thing is as long as you have your student email address, you can get student pricing for most things [22:38:49] er, if that is the same one [22:38:57] I use my @vt.edu and my student ID all the time :P [22:39:01] hehehe [22:39:12] my email got disabled within a few days of dropping out [22:39:41] I got the github education pack using my @student.saxion.nl email. [22:39:46] I get to keep mine for life [22:39:50] lucky [22:39:51] Unlimited private repos and more. [22:40:19] https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=941#section [22:40:34] I'm not sure why the Development and Education board is cheaper [22:40:37] I don't know what it is [22:41:14] oh no that is the right one [22:41:20] http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=593 [22:41:25] ^^^ that is the board I use [22:41:53] I'm not even sure if I would have been able to keep mine if I had actually graduated [22:42:01] I think my university just takes them away if you're not an active student [22:42:54] I actually was inactive for a little and I still had it [22:43:16] nice [22:43:35] Hmm [22:43:39] starts debating. [22:44:16] Looks nice. I should first put some use to the massive amount of components I ordered though. :P [23:58:33] In terms of real lift time, what is dt in NASSP? [23:58:36] life* [23:58:48] double oxygen = 0.00949 * number * dt; //grams of O2 [23:58:56] For example in oxygen consumption [00:05:21] dt is the time between the last and current timestep. [00:05:39] I think in seconds. [00:09:23] Ok [00:09:35] So is it safe to assume that is 1 second [00:09:46] so 0.00949 grams per person per second [00:10:10] Sounds about right. [00:10:30] Don't know what a mole of oxygen weighs. [00:11:03] 16.00u per molecule if I remember correctly? [00:32:50] Almost 32 grams/mol O2 [00:33:36] 31.9988 grams to be more precise. [00:54:42] Yep [00:55:14] A number I have burned into my brain [01:07:32] thewonderidiot: Are these still valid even? http://www.ibiblio.org/apollo/developer.html#Fictitious_IO_Channels [01:08:06] hmm [01:08:07] no idea [01:10:09] Also, any idea if the ropes came with a list of the major modes? Can't seem to find them. [01:10:20] Or were those just in the GSOPs? [01:10:56] GSOPs and other documentation [01:11:30] the table for them is in FRESH START AND RESTART [01:11:36] but I don't think it says much about them there [01:14:51] Thymo: http://www.ibiblio.org/apollo/Documents/j2-80-E-2448-REV1_text.pdf [01:15:02] http://www.ibiblio.org/apollo/Documents/j2-80-E-2448-REV4_text.pdf [01:15:26] Hmmm so in the LM 10 AOH I have this line: [01:15:27] A small amow1t of oxygen is tapped from the suit circuit upstream of the PGA inlets and fed [01:15:28] to the carbon dioxide partial pressure sensor, which provides a voltage to the PART PRESS C02 indicator [01:15:46] But in the LM 8 systems handbook, the schematic looks like the line goes to 2 places [01:15:56] https://www.dropbox.com/s/mvcpgswnfkh3nmd/Screenshot%202018-01-06%2020.15.01.png?dl=0 [01:16:22] I am wondering if I should just tap it upstream of the PGA's instead of taking the average like I have it from the schematic [01:16:38] thewonderidiot: Are you talking about a commented table or FCADRMM1? [01:17:16] FCADRMM1 [01:17:46] hmm [01:17:50] I found that. Having some trouble understanding how it works though. [01:18:01] I think I would tend to trust the systems handbook... probably [01:18:29] do the elementary functional schematics cover this stuff at all? [01:18:33] and if so is it at all readable? [01:19:10] The AOH has had some errors in the past. Go with the systems handbook. [01:19:37] Thats what i did, the sensor is closer to the upstream, right now I am just taking an average of the two which still seems high [01:19:39] systems handbooks have had errors too :D [01:20:46] rcflyinghokie: Those two line coming out of the PP sensor go to the indicator and the SCE. [01:21:30] I mean the actual pipe [01:21:38] That the sensor is on, running left to right [01:22:17] Connects just before the heat exchanger and just after the suit circuit relief [01:23:03] Won't it cause leakage since it's after the suit isolation? [01:24:08] No its still within the closed loop [01:24:30] So what would you get an average of? [01:25:06] The way I have it set up, that section is the "suitcircuit" tank after the relief valve and the other is the "heatexchangerheating" tank [01:25:25] So it is taking an average of the CO2PP in both tanks [01:25:55] rcflyinghokie: https://web.archive.org/web/20060104172247/http://ntrs.nasa.gov:80/archive/nasa/casi.ntrs.nasa.gov/19710070891_1971070891.pdf [01:25:57] pdf page 193 [01:26:36] that might be the most trustworthy thing [01:26:52] it is hard to read.... buuuut there is a hard copy of it at the smithsonian ;) [01:28:10] Does it have a schematic containing the CO2 sensor? [01:28:30] not sure, I just found the section [01:28:53] Yep [01:29:05] Same as the systems handbook, a pipe attaching those two parts [01:29:32] p219 [01:31:06] I will let my LM run overnight and see what the CO2 looks like [01:54:58] Hopefully Neil and Buzz are alive in the morning :P Goodnight! [01:56:34] thewonderidiot: Any idea about the =MINUS pseudo-op? [02:01:30] Okay. I think I'm slowly understanding the mechanism used to define programs. [02:01:46] Don't know why they made it so complicated. [02:02:44] PREMM1 contains a binary code that contains the major mode number, ebank and the downlist to be used. They spend some time decoding that and eventually save it in MINDEX. [02:03:13] That is later used to INDEX on FCADRMM1 which had the FCADRs to the program entry points. [02:04:16] .ask indy91 Do you know anything about the P80s programs on Artemis072? [11:25:07] . [11:32:32] Thymo, that might just be the internal designation for the MINKEY programs. So P33 in MINKEY would be P83 etc. [12:13:51] Hey [12:14:47] hey Thymo [12:15:13] from an user standpoint there are no programs P8X in Artemis [12:15:20] and in the code it all looks like MINKEY to me [12:16:05] I hadn't heard about them, but MINKEY makes sense. [12:16:43] I sort of figured out how the major modes are called. [12:17:02] Just need to figure out if I will break anything if I start to remove entries. [12:18:44] I'm adding Mike's TEMP light change now [12:42:50] hi [12:43:36] hey [12:44:20] i might have asked this yesterday i cant remember but for the p23s when it says to superimpose on the star what excactly does that mean [12:45:41] you enable the split line-of-sight with V and then you have to align the star over the horizon [12:46:13] do you maneuver the space craft to do that or do you do it with the optics [12:46:35] well, both [12:46:54] the split LOS will alternate between your sextant view and the sextant view if it had shaft and trunnion angles 0° [12:47:04] yeah thats what i was doing just wanted to be sure [12:47:24] so the best method is the maneuver the CSM in such a way that the sextant points to the horizon closest to the star [12:47:30] to* [12:48:16] P23 calculates the right attitude for that, but I like to adjust the roll angle after that auto maneuver [12:48:35] i see [12:50:01] just wondering if you have flown the full apollo 11 mission? [12:52:14] not entirely, no. I have flown it all the way through the lunar landing and rendezvous with the CSM. [12:52:38] when your on the lunar surface is there stuff to do in the csm at the same time? [12:52:52] not terribly much [12:53:07] Apollo 15 and later had a lot of science equipment in the CSM [12:53:20] so for those missions there was a lot to do for the CMP [12:53:30] what would you say is the most difficult part for 11? [12:54:25] hmm, good question [12:54:42] I've done many lunar landings by now, so I've become quite experienced with it [12:55:04] so that isn't so difficult for me anymore. But in the grand scheme of things it's probably the most difficult flight phase [12:55:29] P23 are difficult and annoying for my eyes, so I usually skip them [12:55:34] yeah [12:55:46] a bunch of off-nominal procedures are pretty difficult [12:55:54] manual reentry for example [12:56:03] do you use the checklist mfd or is everything memorized [12:56:52] I use the Checklist MFD sometimes, more often I am using the flown checklists. Feels more real to me [12:57:14] I have many things memorized, but following checklists of course helps missing some step [12:57:27] and is it possible to visit other landing sites such as tycho crater [12:57:30] helps to prevent missing some step [12:58:16] it is possible to reach Tycho crater, but don't expect to have enough propellant to get the astronauts back to Earth :D [12:58:34] but you can change the landing site in the RTCC MFD [12:58:56] the landing site coordinates are used for many calculations [12:59:01] and will apollo 13 ever be simulated [12:59:35] some work was done on that a few weeks ago. Our Apollo 13 scenario should be in good shape. [12:59:41] We have two Apollo 13 launch scenarios [12:59:53] one for a nominal mission and one where the explosion happens [13:00:30] and it will happen at the right time and drain all your O2 for the fuel cells [13:01:05] you have to ask rcflyinghokie when he joins, he did this work on Apollo 13 [13:01:53] Scenarios\Project Apollo - NASSP\WIP Scenarios [13:02:02] that's where the scenarios for the later missions are [13:02:23] "Apollo 13 - Launch and Landing" is a nominal Apollo 13 mission [13:02:38] "Apollo 13 - Launch" is the one where you will get the failures [13:02:39] and as for the sps evasive maneuver for 11 it only says to activate delta thrust a and not b would this be correct [13:02:57] I think so, yes [13:03:05] they open redundant set of valves [13:03:11] yeah i tried both and it gave me too much delta v [13:03:17] hmm [13:03:28] I don't think those are related [13:03:53] using A and B shouldn't have any influence on the DV [13:03:58] yeah [13:04:05] so something else must have gone wrong [13:04:14] yeah it happened the second time [13:04:23] first one was perfect [13:04:37] weird [13:05:13] in the real spacecraft there is a small difference between using one or two banks [13:05:31] if you don't have both sets of valves open your thrust would be slightly lower [13:05:37] i might have asked this before but in the rtcc mfd which option should i use for the first mid course correction [13:06:24] TLMCC Option 2 [13:06:51] and you probably only have to give it a TIG as an additional input [13:07:12] all the other parameters needed for the calculation are preloaded in the MFD for the specific mission [13:07:24] yeah 11:45 i believe [13:08:21] yeah [13:08:24] seems about right [13:08:35] as in the flight plan [13:13:47] what does the RTCC MFD give you for MCC-1? [13:17:32] Thymo, ok, help me with this co-author commit thing [13:18:17] git commit --author "Mike Stewart " -m "Did stuff" [13:18:41] does that give full authorship to Mike? [13:18:47] No, wait [13:19:17] git commit --author="Mike Stewart " -m "Did stuff" [13:19:28] You need an = apparently. [13:19:45] indy91: It will list it as "thewonderidiot commited with indy91" [13:19:51] ah, good [13:19:54] Instead of "indy91 committed" [13:20:12] these DSKY changes are of course mine, but it's not like I did the majority of this work [13:21:21] It will show it as a contribution of Mike, only that it was committed via you. [13:21:30] sure [13:22:12] https://github.com/dseagrav/NASSP/commits/Orbiter2016 [13:31:20] Looks good. :) [13:33:04] Hey Ryan [13:33:35] Morning [13:34:03] Looks like the CO2 held overnight at about 3 mmhg, I think that is reasonable [13:39:25] hey [13:41:59] good morning [13:46:10] I'm doing a bit of reorganization that potentially will make it possible to launch a LM on a Saturn IB [13:46:25] I really would like to get that working for the 50th anniversary of Apollo 5 [13:46:59] Ohh that would be cool [13:48:21] as the first step I've made the Saturn stage systems classes independent from the Saturn class [13:48:57] so the S-IB when it gets initialized gets a pyro for the S-IB/S-IVB stage separation [13:49:04] instead of doing the separation itself [13:49:45] so now I can already created a new class called LEMSaturn, which is derived from the LEM class but also has an IU, S-IB and S-IVB systems [13:49:53] create* [13:51:17] I guess the next step is make the functions in sat1bmesh available for both the normal Saturn IB and the special LEM class [13:52:01] Very nice [13:57:15] I am going to try to push through more LM heat [13:58:00] While the glycol stays at a good temperature (hardly using the sublimator) the cabin and suit get too cold right now because of the lack of heat in the glycol loop [14:08:00] yeah [14:08:14] hopefully most systems other than the IMU and ASA are easy to implement [14:08:22] Wouldn't it be more appropriate to make each stage its own craft? (relatively stupid, at that: "I have X engines, Y amount of fuel and Z of oxidizer. I can/cannot gimbal, and I am/am not asserting level sense, and do/do not have a LEM) to report to the IU and/or CSM. Tell me when to fire my engines.") That'd allow assembly in the VAB again and keep the number of IUs per mission at 1. And going [14:08:22] forward, it allows for being more in line with orbiter 2016's feature set. (starting/lifting off with docked individual craft.) It *also* allows for the easier creation of AAP type missions like the manned Venus flyby plan in the future. [14:10:39] indy91 would you be able to help me with the rest of the ASA code? I started it in that PR but it is not complete [14:11:41] Cannibal^, yes that would be the better solution, but that approach causes a large number of new issues. For a while I thought we should have stages docked together on the launchpad, but at least for now that is not really feasible. [14:11:55] rcflyinghokie, sure [14:12:47] Thanks [14:14:26] Ah. [14:14:27] So I need logic to control the heaters, and a way to give heat to both the primary and secondary loops [14:16:26] I'll write some logic [14:17:31] So basically if the ASA breaker is in, the fast heater is on until 116F, then the fast heater turns off and the fine heater heats to 120 and then holds it there [14:18:18] the fast heater should be possible to control with just the config, right? [14:18:29] I have the temperatures in the config, all I need is a way to make sure only the fast heater runs below 116F and only the fine heater above 116 [14:18:35] Yes [14:18:37] yeah, that should be easy [14:20:51] uhh [14:20:59] seems like ASA and AEA are not even drawing power yet [14:21:34] haha wonderful [14:21:49] AEA will need a heat load as well, just not a heater [14:22:14] right [14:26:32] ok, how much heat should the ASA generate? [14:28:28] Assuming I am reading the heat load correctly, 95.1W [14:29:03] But I dont know if it generates less in standby [14:29:13] I cannto find an ASA difference in standby and operation [14:29:16] *cannot [14:29:23] Both have heaters and gyro motors running [14:30:05] And looks like the ASA draws 41.1W of power, which also doesnt seem to be right with the 95.1, unless the 95.1 is the fine heaters plus the gyro motors [14:31:41] great [14:31:56] I wished we had much better sources on this... [14:33:16] Me too [14:34:00] I am going to say make the heat load from the motors 41.1 [14:34:24] And I will make the fine heater 54W [14:36:02] I already know that this isn't going to work [14:36:21] hmm [14:36:31] so how do we use the heat exchangers? [14:37:00] Haha so much confidence [14:37:24] the radiator will only radiate 0-2 watts [14:37:34] as we have it right now at least [14:37:44] We dont need it to radiate much at all [14:37:49] adding 41.1 watts to that will make the temperature raise a lot [14:37:54] The ASA is actively cooled by design [14:37:57] ok [14:38:26] I have a heat exchanger on the primary and secondary loop set to 120F [14:38:38] You shouldnt have to worry about them in the code [14:38:43] The config should take care if it [14:38:48] hmm [14:39:00] If they are above 120 they will cool it [14:39:05] so I guess it will do the same thing as the IMU blower [14:39:07] Below 120 it wont do anything [14:39:10] cylce at 120°F [14:39:15] Yes [14:39:35] it says the temperature is kept at 120°F +/- 0.2° [14:39:54] Yeah [14:40:30] yeah, this will simply cycle at 120°F [14:40:46] not really realistic, but what can we do [14:41:16] Yeah its the best course currently [14:41:31] I put the range on the fine heater and heat exchanger [14:41:39] 119.8-120.2 [14:43:12] I will see what this does in a debug string [14:44:21] I have a few config changes you will need [14:44:36] LEM-ASA-FineHeater 1 DC_DUMMY 54.0 54.0 TEMP 321.92778 322.15 HYDRAULIC:LEM-ASA-HSink [14:44:50] PRIMASAGLYCOLHX 1 2.0 PRIMGLYCOLLOOP1 LEM-ASA-HSink 321.92778 322.15 #120F +- 0.2F [14:44:51] SECASAGLYCOLHX 1 2.0 SECGLYCOLLOOP1 LEM-ASA-HSink 321.92778 322.15 #120F +- 0.2F [14:46:53] ok [14:56:42] that fine heater number can't be right [14:56:55] it's trying to heat it up to 120.2°F [14:56:59] but the heat exchanger is fighting it [14:58:14] fine heater should probably try to keep it at 119.8° [14:58:31] I just have the range on both [14:58:40] How about heat exchanger at 120.2 [14:58:46] Fine heater to 120 [15:01:15] why not the fine heater to 119.8°F? [15:03:47] I guess it doesnt hurt, but if the gyro motors (heat load) is not on wouldnt it just stay at 119.8 instead of 120? [15:04:11] right [15:04:35] as long as there is a temperature range it will work [15:04:43] and not make the heat exchangers fight with the heater [15:05:01] Yeah [15:05:18] So the heat exchangers should be at 120.2 [15:05:26] and the fine heater 120 I think that should work properly [15:06:03] sure [15:06:17] yeah, if the ASA is off, the temperature slowly declines [15:06:31] and the heater kicks in again at 119.8° and heats it up to 120° [15:06:57] Perfect [15:08:16] one issues remains [15:08:27] the secondary heat exchanger doesn't do anything [15:08:53] when the temperature increases above 120.2°F the primary HX does its job [15:09:06] and that instantly drops the temperature below 120.2° again [15:09:28] then the HX is off for one timestep [15:09:37] temperature increase and the cycle repeats [15:11:28] what we could do is decrease the size of the HXs, so that the temperature can only be kept under control when both HX take heat [15:12:02] Well the secondary loop is not running [15:13:16] We might have to cheat and turn that secondary HX off while the secondary loop is off [15:14:04] as I said, the secondary HX isn't doing any work anyway [15:14:16] Also, the secondary heat exchanger, if the glycol is above the temperature of the heat sink, it wont transfer Q [15:14:59] but it's not doing anything anyway [15:15:16] Ok now the question is, if the primary loop is turned off, and the secondary loop is running, will it start running [15:15:16] because the primary HX is doing its timestep first, it removes all Q above 120.2° [15:15:33] yes, then the secondary one will take all the heat [15:15:49] ah wait [15:15:52] you mean the loops [15:16:08] then it depends on the temperature of the loop [15:16:14] Yes [15:16:24] Specifically that particular tank in the loop [15:16:28] if the temp of the primary loop is above 120.2°F, then the secondary loop will take the heat [15:16:31] right [15:16:52] With the timestep allowing the primary first, I think that would be correct [15:18:07] And it is just that section of the primary loop since it is not pumping [15:18:17] So it would heat up faster than the accumulator [15:18:35] And transfer heat to the secondary [15:18:41] I think that is the right behavior [15:19:18] well even without the loop being pumped it still transfers heat between tanks [15:19:24] and long as the valves aren't closed [15:19:33] as* [15:20:17] so eventually the whole loop will heat up [15:20:30] or all connected tanks rather [15:20:47] is 120°F a bad temperature for the loop? [15:21:05] I dont think so [15:21:12] also, when it approaches 120°, the primary loop will start taking less and less heat [15:21:16] which is also desied behavior [15:21:31] so I guess we can leave it like this [15:21:45] the heater behavior is good [15:21:49] HX as expected [15:22:32] I think as long as the loop pressure isnt high, the higher temperature is irrelevant, if anything you just don't want it to freeze [15:23:07] ok, then I think I am ready to commit this [15:23:24] Great [15:23:44] the HX length could probably be 1.0 instead of 2.0 [15:23:53] it had to be increased for the IMU blower [15:23:55] Sure [15:24:05] because it couldn't deal with 78 watts or whatever it was [15:24:14] but now we have 2 HX for half the watts [15:24:19] I'll test that [15:24:32] Yeah make sure its working even when only one is running [15:24:47] one what? [15:25:29] ah, you mean that one HX can take all of the heat on its own [15:25:54] Yes [15:26:07] Because once the other loop heats up, it wont take any more [15:26:14] right [15:29:27] Now here is a question, do we want to use this radiator/heat exchanger method for all of the heat sinks in glycol? It would be a little more work, but give you a place to measure temperature for telemetry and use the heat exchangers to control the cold rails that have twice as much heat exchanger length in the primary loop as the secondary [15:29:28] interesting [15:29:48] it doesn't cycle on every timestep [15:30:11] prim HX is at -41.1 watts for 10 timesteps or so and then once back to 0 [15:30:51] we should use this way for every system whose temperature is measured for telemetry [15:30:57] I think that is the right approach [15:31:09] I agree [15:31:45] For now I will start implementing the config changes (after we finish the ASA) to support it [15:31:57] every once in a while the secondary HX also gets heat [15:32:01] I think I'll use 1.5 and not 1.0 [15:33:42] And then there are the systems I dont think are independently modeled like the CDU LCA DSE RGA etc [15:34:10] Oh for the ASA HX make sure the same length is used in both HX [15:34:13] RGA is a separate system [15:34:19] yep, 1.5 for both [15:34:22] Great [15:34:33] how much power should the ASA draw? [15:34:38] also the 41.1? [15:34:41] For things like the TLE, we will use a 3:1 ratio prim to sec [15:34:56] Yeah [15:35:04] Thats the electrical load [15:35:10] Thats where i derived the heat load [15:38:40] update pushed [15:40:54] Awesome [15:43:37] Now which components cooled by glycol have a TM reading [15:44:13] Off to the big list [15:44:34] let's look at the RGA next [15:45:42] I don't think that even has a heater [15:45:55] I also don't see any temperature reading [15:46:03] so that can be a simple heat load going into glycol then [15:48:11] The only issue I have with that now is the divvying of the loops [15:48:51] RGA for example has 1 pass of primary coolant and 3 of secondary [15:49:43] Actually, this shouldnt matter [15:49:53] Same amount of heat will be generated no matter what [15:50:52] So the loop will take the same heat value [15:51:06] So simple heat going to glycol it is [15:53:27] Quick question, what is the RTG? [15:54:44] There is a temp value that is measured I think it is in the CWEA somwehere [15:58:29] uhh, Radioisotope thermoelectric generator? [15:58:38] Apollo 12-17 had one for the ALSEP [15:58:58] Ah yeah [15:59:14] Duh i should have known that acronym [15:59:16] but I would be surprised if there was a measurement for it [15:59:19] There is [15:59:27] and it's connected to the CWEA? [15:59:29] GL8275T [15:59:34] No its just next to it [15:59:38] In the list [15:59:44] I see [15:59:58] So yeah it is measured haha [16:00:34] So the only other systems I can see on here that have temp measurements are the LR and RR antenna and the PIPA [16:01:15] And none of those are in the glycol loop as far as I can tell [16:01:43] Of course I could also not be reading the right list :P [16:02:04] RR has a standby heater at least [16:02:58] in what list did you find the RTG? [16:03:07] AOH or Systems Handbook? [16:03:16] handbook [16:03:51] ah and it says N/A for a reference in the handbook [16:04:01] so I won't be able to find it there anywhere [16:04:02] Right [16:04:24] I am surprised things like the inverter or ECA arent measured for TM [16:04:30] it goes through the SCERA though [16:06:13] AC Bus Voltage is on telemetry [16:06:22] Temperatures [16:06:27] ah [16:06:53] I could have sworn the batteries had some sort of temperature measurement [16:07:18] oh, there is, indirectly [16:07:23] battery malfunction [16:07:28] T > 145°F [16:08:46] Ok I thought so [16:08:57] but only the malfunction signal is on telemetry [16:09:00] Ah [16:09:08] so probably some sensor attached to the batteries [16:09:19] unfortunately we don't have the detailed DC Power schematic [16:10:02] I have the schematic of those sensors [16:10:20] you do? [16:10:28] Not sure how detailed it is, but it is in the Apollo 13 mission report [16:10:32] oh, great [16:10:53] pdf pg 140 [16:11:09] Just shows the switches in the ECA that turn on the light [16:11:33] and the bimetallic temperature switch [16:11:52] which goes directly through the battery [16:11:59] malfunction logic is in the ECA then [16:12:00] Yep [16:12:22] And this also means the batteries might need some way to have a temperature [16:14:41] But I got off track, RGA was next, and that should just be a simple heat load applied to both loops [16:15:16] Now to look for power/heat [16:16:05] dc_source->DrawPower(8.7); //TBD: Actual value [16:16:10] that's what I implemented [16:16:12] Haha, helpful [16:16:17] Ok [16:16:36] I would think it would be a higher draw based on it's size [16:16:43] the heat sink size I mean [16:18:18] what is the size of it? [16:18:33] I am just looking at the relative size in the schematic [16:18:40] ah [16:18:45] It gets power from the ATCA breakers it looks like [16:18:55] yep [16:19:49] I let it draw power from the ATCA breaker [16:20:04] as opposed to ATCA (AGS) or ATCA (PGNS) [16:20:30] It uses AC and DC [16:21:31] Assuming I am reading this right [16:21:43] So it might need both? [16:22:36] I think the ATCA has an internal inverter [16:23:33] Ah that would explain it then [16:24:19] yeah, 800 Hz from the ATCA power supply [16:24:37] that power supply would technically need a signal from instrumentation [16:24:45] So the ATCA and ATCA pgns both go to the power supply [16:24:53] And from there to the RGA [16:25:25] the RGA gets signals 33 and 36 [16:25:33] those are both only powered by the ATCA breaker [16:25:41] Ah ok [16:26:12] only one route goes from the ATCA PGNS breaker to the ATCA power supply and out of it [16:27:29] and that one only goes to the PREAMPS CAUTION light [16:27:55] so it's all the ATCA breaker powering the RGA [16:28:03] and the ATCA (AGS) one for the test signals [16:28:55] The ATCA breaker has a heat load of 42W, draws 55W on PGNS and 65W on AGS [16:29:09] So I guess a portion of that is the RGA [16:33:29] Haha nice [16:35:15] yeah, 8.7 as the heat load should be ok [16:35:30] I really don't know where I got that number from though [16:37:50] TLE should be simple next [16:38:31] what's that? [16:38:31] Question is does it generate heat if the breaker is closed but the switch is off [16:38:36] Tracking light [16:38:43] we don't simulate one [16:38:59] we probably should add a system for it first before adding the heat load [16:39:07] Ah true [16:39:13] Its pretty simple [16:40:34] Just a breaker and switch and light [16:41:22] And electronics package with capacitor banks that create the voltage for the strobe but that can simply be the heat load [16:45:05] I dont think there is anything else special [16:48:07] The lighting control assembly controls the majority of the lights that will be some work but thankfully the tracking light is its own thing [17:29:19] After the RGA stuff, adding heat for the AEA might be a good next place as that helps complete the heat loads in the lm_ags.cpp [17:30:16] ok [17:32:13] And looks like a little heat comes from the AGS AC breaker, not sure where to put that [18:00:17] Looks like it should go in the AEA heat as well [18:07:02] yeah, might be the best [18:09:47] Are you doing the RGA? [18:10:27] I can do that, sure [18:10:48] Actually I was working on this "LM on Saturn" project :D [18:11:28] Oh haha, by all means continue I was just curious [18:11:50] I just didnt want to start working on something you were working on [18:12:19] I am adding AEA heat or attempting to right now [18:16:26] ok [18:17:10] would be great if you could do most of the other heat loads. I'll answer any coding question [18:19:19] Absolutely! [18:19:26] Might take longer [18:19:33] But I would be happy to do it [18:20:55] the process is mostly: change the init of a function to include a heat load, add a GenerateHeat in the SystemTimestep of the system [18:21:09] and give the heat load to the system via the init function in lemsystems [18:21:20] init of a system* [18:22:37] morning! [18:23:32] hey Mike [18:23:50] TEMP light works as advertized [18:23:58] excellent [18:24:39] and I am working on getting a Saturn launchable LM working for the 50th anniversary of Apollo 5 [18:24:55] I might still abandoned that project due to sudden difficulties, but so far it looks good [18:25:10] yessssssss [18:25:13] I am excited :D [18:25:28] the approach is different than I thought about it in the past. It is basically the LM class with everything added that you need for a Saturn IB [18:26:01] simulating the systems of each class in a specific class, as we are doing now, of course helps [18:26:08] of each stage* [18:26:11] hm, interesting [18:27:09] so I have a class derived from LEM and added to it: IU, SIBSystems and SIVBSystems [18:27:24] that already takes care of everything non-Orbiter related [18:28:02] but now I still have to do meshes etc. [18:28:31] right yeah [18:28:41] once in orbit only the normal LM code will be relevant [18:28:42] legless LM and whanot :D [18:29:13] yeah, we already were able to launch a legless LM, just not one that actually runs LM systems and panel [18:29:30] so I am mostly copying over code from our Saturn IB and do a few modifications [18:30:09] oh gotcha [18:31:06] For the AEA, the IsPowered has a Powerswitch->IsUP [18:31:11] Does this mean AGS in OPR [18:31:21] And not standby or off [18:31:42] yep [18:31:53] AEA will only be powered with that switch in the up position [18:32:38] ah, you still have to add the SystemTimestep [18:32:44] I added it in the class definition [18:32:53] in the header [18:32:55] I did [18:32:57] ah, good [18:33:16] SystemTimestep will look at IsPower() [18:33:19] Powered* [18:33:24] and then draw power or not [18:33:25] void LEM_AEA::SystemTimestep(double simdt) [18:33:26] { [18:33:26] if (IsPowered()) [18:33:27] { [18:33:28] lem->SCS_AEA_CB.DrawPower(41.1); [18:33:28] lem->AGS_AC_CB.DrawPower(3.45); [18:33:29] aeaHeat->GenerateHeat(44.55); [18:33:30] secaeaHeat->GenerateHeat(44.55); [18:33:32] } [18:33:34] } [18:34:10] I will PR what I have done if you dont mind checking it [18:34:22] no, that isn't safe [18:34:44] IsPowered() does not check if the AGS_AC_CB is closed [18:34:48] Oh [18:34:50] or did you add that? [18:34:53] Nope [18:35:09] I actually meant to ask that when I was discussing ispowered() [18:35:43] So IsPowered needs to see if both breakers are closed [18:36:25] Right now it only looks at the switch and DC voltage [18:36:58] hmm, the AC CB is only used in a very limitied way [18:37:01] limited* [18:37:06] The AEA doesnt even seem to use the AGS cb [18:37:10] in the code I mean [18:37:15] that I have already implemented [18:37:20] GetTotalAttitude() [18:37:24] GetAttitudeError() [18:37:43] Ah ok [18:37:48] so I think the only job of that CB is conditioning the AGS attitude error and total attitude for the FDAI [18:38:26] Ok so where should it's power draw come from? [18:39:44] add a IsACPowered function [18:39:59] which should work like [18:40:07] (lem->AGS_AC_CB.Voltage() < SP_MIN_ACVOLTAGE) return false; [18:40:10] return true; [18:40:21] those two lines [18:40:27] and then in the SystemTimestep [18:41:01] IsPowered() is checked for the DC [18:41:07] which you did slightly wrong [18:41:20] lem->SCS_AEA_CB [18:41:24] that's only one CB [18:41:36] Ah yeah there are two [18:41:40] the AEA has a power merger for this [18:41:42] DCPower [18:41:44] just use that one [18:41:49] DCPower.DrawPower(X) [18:43:23] Ok [18:44:31] Now where should my AC power draw go? [18:45:50] also in SystemTimestep [18:45:57] but not in the if (IsPowered()) [18:46:09] but in its own if (IsACPowered()) [18:46:22] should probably also draw power when the AEA is off [18:46:41] Hmm class LEM has no member DCPower [18:47:21] not lem->DCPower [18:47:23] DCPower [18:47:28] the AEA owns it [18:47:30] Oh duh [18:48:13] Can i generate heat from two places into the same heatload? [18:48:22] Would they be additive [18:50:59] If I did this for example: [18:51:00] yep [18:51:01] if (IsPowered()) [18:51:01] { [18:51:02] DCPower.DrawPower(41.1); [18:51:02] aeaHeat->GenerateHeat(41.1); [18:51:02] secaeaHeat->GenerateHeat(41.1); [18:51:03] } [18:51:05] if (IsACPowered()) [18:51:09] { [18:51:10] lem->AGS_AC_CB.DrawPower(3.45); [18:51:13] aeaHeat->GenerateHeat(3.45); [18:51:14] secaeaHeat->GenerateHeat(3.45); [18:51:16] } [18:51:19] Would it add the heat [18:51:20] yep, that works [18:51:22] Great [18:51:29] all the GenerateHeat function does is: [18:51:30] heat_load += watts; [18:51:38] so it add to the load [18:51:40] adds* [18:51:48] Thats exactly what I want [18:51:56] it gets processed and reset to 0 when it actually does the power drawing [18:52:05] yeah, makes things easier [18:52:11] DrawPower works the same way [18:52:34] So i could have two places drawing power of different values and it would add [18:54:13] yeah, that's a fairly common case [18:54:38] that multiple systems draw power from the same CB [18:56:24] PR is up, tell me what I messed up :) [18:56:38] Never mind, found something [18:58:02] Fix coming to the PR [19:00:05] the SystemTimestep function still needs to be added in lemsystems [19:00:33] I thought I did that [19:01:05] LEM::SystemsInternalTimestep [19:01:15] just add it to the list [19:01:43] the function needs to be called [19:01:53] I also forgot that at first with the ASA [19:02:24] Oh do i also need: aea.SystemTimestep(tFactor); [19:02:32] yep, that's what you need [19:02:42] Ok [19:02:47] just add it to the asa there [19:02:54] Added [19:03:54] looks good otherwise [19:04:01] I kept wanting to type asa all over the place [19:04:38] So that is the general formula for adding a heat load to a system that is already implemented [19:04:59] yeah, even more complicated than usual, due to the missing SystemTimestep [19:05:09] and the different DC/AC handling [19:07:56] How did you want to handle the RGA [19:08:54] ah, that is at the top of lmscs.cpp [19:09:02] LEM_RGA::SystemTimestep [19:09:24] just add a {} around the DrawPower and add the heat load to it [19:19:54] I am just going to call it 42W for now based on the ATCA breaker [19:20:28] for the RGA? [19:20:38] that seems way too much [19:20:43] Yeah agreed [19:20:54] 8.7 for now then? [19:20:59] yeah, that's better [19:21:01] Ok [19:21:28] with the systems and heaters we have been adding I doubt you can make it through a mission right now with the LM [19:21:33] it was critical before already [19:21:47] we will have to see [19:22:14] Power consumption? [19:23:14] yeah [19:23:40] wasn't it really close before? [19:24:04] even with the CSM powering the LM during TLC [19:26:03] I never had problems with the des batteries on 11 or 12 [19:26:14] Only the ascent [19:26:51] But it could be configuration as well, if I had the cross ties on I was fine, just the CDR bus seems to take way more juice than the LMP bus I think [19:28:16] yeah, because the AEA and ASA (and other systems) weren't drawing power yet [19:28:28] should be more balanced now [19:28:36] so the ascent batteries were an issue, ok [19:29:35] Yeah I never had an issue with descent batteries [19:31:39] Added the RGA, but forgot a new PR [19:33:13] yeah, I was waiting on BuildBot to be finished [19:33:38] you added a few commits after each other, so at one point it had 3 builds scheduled :D [19:34:04] Oh haha [19:34:11] I keep forgetting it adds those to buildbot [19:34:12] and another one... [19:34:18] at this rate I can never merge it :D [19:34:35] Haha I forgot to save my cfg changes when I pushed my changes so it didnt update it [19:34:44] I am done now I promise [19:34:55] looks all good though [19:35:29] RGAHeat->GenerateHeat(8.7); [19:35:33] SecRGAHeat->GenerateHeat(8.7); [19:35:41] shouldn't that be half of 8.7 each? [19:35:46] No [19:35:48] considering the total drawn power is 8.7 [19:36:02] Well I see what you are saying actually because it doesnt have a hx [19:36:26] yes, it always generates the heat for both loops [19:36:27] It should give its entire load to whatever loop is taking away heat [19:36:49] that's not really possible [19:36:52] I know [19:37:05] and also doesn't sound realistic [19:37:06] and halving the heat reduces the true heat that would be given to a loop [19:37:35] But I think you are right that is the way to do it right now [19:38:00] unless you want to add heat exchangers en masse [19:38:13] I honestly considered that [19:38:22] Let's go with halving right now [19:38:25] See what it does [19:38:36] We are using maximum loads afterall anyways [19:39:05] I have merged the current PR [19:39:10] even if it was still building [19:39:15] best do a new one with the fixes [19:39:22] No problem [19:39:32] I need to halve the AEA as well [19:39:38] ah, right [19:41:57] What other systems are implemented to a point to take heat? [19:44:58] Windows decided it had my "permission" to reboot [19:46:07] Also I mulled it over briefly, from a code standpoint making the heatsinks and heat exchangers might be simpler than adding primary and secondary heats to the systems [19:46:24] Half as much to add to the project [19:47:30] Just might take more debugging and testing [19:48:05] But anyways, I will think about it longer, don't know if it went through but what other systems are implemented to a point to take heat? [19:54:25] I have to check which systems are even connected to the glycol loops [19:55:06] Want a list? [19:55:52] I have it open [19:55:57] Ok [19:56:00] SCERAs can be done [19:56:08] ATCA probably [19:56:08] ATCA [19:56:20] PCM [19:56:32] S_Band [19:56:53] Any idea what SBP and SBX are? [19:57:10] S band what and what [19:57:12] S-Band subsystems [19:59:43] not sure [19:59:54] XMTR? [20:01:12] That was a guess of mine as well [20:01:24] Maybe the power amp and transmitter [20:01:40] Would produce the most heat in the system I think [20:03:12] PR'd the halving of the heat [20:03:24] I will play with other systems in a little [20:07:48] I will also see if i can get the other heaters working [20:08:21] The aoh has good description of the lr heater but not the rr heater operation [20:10:16] Lr heater has a thermostatic switch and the heater is turned off when it is operating because operational minimum heat is enough to keep it in the right temp range. [22:37:14] Can I separate changes into multiple pull requests? [22:39:13] if you have them on separate branches, yes [22:39:23] Ah nope [22:39:33] if one depends on the other, sometimes I make a branch off of my branch, and then make the second pull request target the first branch [22:39:38] All in my local Orbiter2016 branch [22:40:00] I am implementing heat loads by systems and wanted to separate them into multiple requests so they are easier to check before merging if that makes sense [22:41:00] yeah [22:41:30] I have only done one new system though [22:42:18] They don't really depend on one another [22:55:53] Oh well on the bright side the AEA ASA AGS RGA ATCA GASTA and IMU all have heat [22:56:06] Still a bunch more to go [22:58:10] hahaha awesome [22:58:11] that is a lot :D [23:01:00] Working on S Band now [23:01:27] A vacuum tube during warmup would use as much power as in operation to heat itself up wouldnt it? [23:02:36] Actually, the s band transceivers werent tubes were they? [23:03:13] I could be wrong but I wouldnt think they had vacuum tubes [23:03:16] In the LM [23:05:47] I know someone that works with tubes a lot. Let me ask him. [23:07:10] The project code keeps saying "tubes" for s band warmup and cooldown but that doesn't seem right to me [23:07:16] I would think those are too fragile [23:10:27] He's saying that the heating element works like a light bulb. The hotter it is the more resistive it is. [23:10:49] So if it's cold it will draw a lot of current and will draw less when it gets hotter. [23:11:38] And there did exist tubes that were designed for military/aerospace use. [23:11:51] https://c1.staticflickr.com/6/5174/5422992965_91752c1976_b.jpg [23:13:28] http://g3ynh.info/valves/var/7586/nuvistor004.jpg [23:13:30] See left [23:17:22] So question is, did the LM S band use tubes [23:17:42] And that was my understanding of tubes as well [23:17:54] Higher loads until operating temperature [23:18:58] https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19720023255.pdf [23:19:14] "For example, weight and power requirements made an amplitron-tube design more attractive than the traveling-wave-tube design used in the CSM. The amplitrontube power amplifier weighed 16.8 pounds and required 72 watts; the CSM power amplifier weighed 32 pounds and required 90 or 167 watts, depending on mode selection." [23:19:54] Yep the amplitron was used in the LM [23:20:00] I didn't know it was a tube [23:20:20] So the drawing of 1/3 of the power during warmup as it is written is wrong [23:21:01] The S-band power amplifier was a package that incorporated a QKS 997A amplitron tube, a solid-state dc-to-dc converter, and associated RF circuitry (such as circulators and RF filters). An RF output of 20 watts was expected, with a total dc input of 52 watts, [23:26:47] Ok code question for you guys [23:26:55] if(lem->SBandXCvrSelSwitch.GetState() == THREEPOSSWITCH_UP){ [23:26:55] if (tc_mode_1 == 0) { [23:26:56] tc_mode_1 = 2; // Start warming up [23:26:56] SBXHeat->GenerateHeat(17.65); [23:26:57] SBXSECHeat->GenerateHeat(17.65); [23:26:58] } [23:26:59] }else{ [23:27:01] if(tc_mode_1 > 1){ tc_mode_1 = 1; } // Start cooling off [23:27:03] } [23:27:18] Right now how I have that is it starts generating heat to the glycol as soon as it is enabled [23:27:59] tc_mode_1 = 3 is operating, I want it to generate heat there instead, would an else if be the right way to go? [23:28:56] if(lem->SBandXCvrSelSwitch.GetState() == THREEPOSSWITCH_UP){ [23:28:57] if (tc_mode_1 == 0) { [23:28:57] tc_mode_1 = 2; // Start warming up [23:28:58] } [23:28:58] else if (tc_mode_1 == 3) { [23:28:59] SBXHeat->GenerateHeat(17.65); [23:29:01] SBXSECHeat->GenerateHeat(17.65); [23:29:03] } [23:29:05] }else{ [23:29:07] if(tc_mode_1 > 1){ tc_mode_1 = 1; } // Start cooling off [23:29:09] } [23:36:52] Would that start heating when the mode hits case 3? [23:37:09] And stop heating otherwise [23:38:17] should work [23:38:41] Great [23:39:01] Nik has been super patient helping me learn how to do this stuff I am glad some is sticking [23:39:07] haha [23:40:39] I am making common mistakes and not stupid ones :P [23:41:21] Ok S Band has heat (I hope) [23:41:24] Now VHF [00:15:31] I would think only the VHF transmitters would be in the heat sink [00:16:19] Because the receivers have such a low heat load [00:44:34] Ok VHF is done pending review [01:00:11] LGC and its systems are going to be a challenge [01:00:44] I need heat loads from the LGC CDU PSA and PTA [01:10:16] Is the AGC getting an electrical overhaul of some sort? [01:14:46] .tell indy91 I PR'd my heat loads but am now getting a CTD I cannot debug [02:00:30] rcflyinghokie: a bit, to make sure the voltage alarms operate correctly [02:00:42] that won't be for a little bit since I need to do this counter stuff first [02:21:24] Ah ok, is it going to give anything else it's own system powered through the LGC? [12:42:42] hi [12:44:51] Hey [12:46:32] how is the lem coming along [12:50:06] Ryan and Nik are still working on it. Good progress is being made with the heat load of the systems. [12:52:56] just wondering if anyone has a scenario file for apollo 11 right before mcc1? [13:08:33] Nik might have one. He's not here at the moment though. [13:55:14] hey [14:05:53] indy91 do you have a scenario file for apollo 11 right before mcc1? [14:06:48] I don't, unfortunately [14:06:53] okay [14:07:05] I can look for a really old one, but it would be horribly outdated [14:07:15] no thats okay [14:07:26] are you having trouble with your scenario? [14:07:32] nope [14:08:12] just wondering what is the max time acceleration that can be done? [14:10:49] 10x-50x in Earth and lunar orbit, 50x-100x during the coast periods between Earth and Moon [14:11:06] I tend to stay lower, 10x in orbit, 50x during translunar coast [14:11:30] at 100x you can get into trouble with the Virtual AGC [14:11:53] it still needs to do the same amount of computer cycles per simulated second [14:12:13] and a small dip in your frame rate can apparently already break the AGC [14:12:19] and for the docking when it comes to the pitch up 180 degrees are you supposed to set the cmc mode to free [14:12:43] there are a few techniques, the checklists for different missions aren't very consistent on this [14:12:58] it comes down to preference [14:13:10] yeah i just put it in free and then back to auto after the 180 [14:13:51] yeah, that works [14:13:54] let's see... [14:14:02] the closest checklist to Apollo 11 for this is from Apollo 12 [14:14:05] https://history.nasa.gov/afj/ap12fj/pdf/a12_l_o_c.pdf [14:14:38] that one does the 180° maneuver with the SCS [14:15:08] and once roughly in the docking attitude, back to CMC control an V49 [14:15:10] and* [14:15:30] PDF page 49 in the checklist I posted [14:15:43] 49 and 50 [14:18:25] and i think im supposed to do the switch to lem csm power after the lem ejection is that right? [14:23:55] yep [14:24:11] the LM systems aren't simulated until LM ejection [15:25:24] Good morning [15:29:43] Hey [15:32:56] Meeting ended by Thymo, total meeting length 149175 seconds [15:32:57] .endlogging