[09:49:10] NASSP Logging has been started by thymo [09:49:12] Morning! [10:29:37] Hey Matt [11:01:10] hello [11:47:11] my grand plans of getting anything done last night were disrupted by not having internet or power [12:43:15] That sucks [17:01:26] morning! [17:02:23] Hey Mike [17:03:50] what's up? [17:04:40] C programming mostly today. Gonna have another crack at VHDL in a bit. [17:10:03] nice! [17:12:11] Yeah, apart from Quartus being crap. [17:14:15] Quartus is pretty alright as far as FPGA IDEs go [17:23:54] Maybe it's just me not being used to the FPGA worls but I don't find it very intuitive to use. [17:52:16] the FPGA world is very different [17:52:40] and counterintuitive is better than constantly crashing and sometimes corrupting your project, which is what some other tools are like ;) [11:26:45] Hello all! Quick question, is this post the most recent installation guide, and is the process that this post is updated if changes are made to the procedures? [11:26:47] https://www.orbiter-forum.com/threads/nassp-8-installation-guide.36801/ [12:09:06] .tell petriw yes, that is the correct guide, and we keep it updated. [12:09:22] hey Ryan. [13:05:04] Good morning! [13:57:10] how's it going [15:01:51] slammed with work stuff haha [15:42:43] morning! [16:06:26] rcflyinghokie, yeah me too. [16:06:33] hey mike [16:34:45] afternoon :) [08:57:38] . [10:53:23] hello [10:53:59] hey [11:51:08] good morning [12:03:34] hey Ryan [12:06:02] how's it going? [12:11:29] was a bit sick over the last few days, but I'm good now [12:11:54] https://github.com/indy91/NASSP/tree/LMEPSUpdate [12:11:58] I pushed my branch [12:21:36] which is essentially ready to be merged, I think I wanted to do a bit more testing on it [12:25:34] glad you are feeling better! [12:26:02] ok so what all does this have added? [12:28:10] complete overhaul of the ECAs and the control of the CM/LM power connection [12:33:13] so basically the prerequired changes for the LM to CM power [12:44:55] Excellent [12:45:20] so getting them to share a common bus would be next (assuming batteries arent touched yet) [13:07:03] also I wonder what is the best method for the ECAs to generate heat [13:20:47] hmm [13:21:09] I guess that belongs best in the LEM_DescentECAch and LEM_AscentECAch classes [13:21:43] but they probably shouldn't generate the same amount of heat as their power load [13:21:51] as the power is really only passing through [13:22:02] maybe a small percentage of the power load [13:23:19] we have diagrams for the temperature rise in case of coolant failure for the ECAs [13:26:22] the heat load (at least the cb) is only 10W for the DES and 20W for the ASC [13:37:48] all the temp rises are very linear, but of course that is a function of the coolant stabilizing it as it warms [13:48:23] this was an interesting diagram in the AFJ https://history.nasa.gov/afj/ap13fj/pics/lm-pwr-ctrl-sys.png [13:50:33] oh yeah, that's pretty nice [13:50:59] and the procedure for getting the batteries on the line after CM MNB failure [13:51:00] 057:38:24 Haise: Okay. In the CSM, on panel 5, we want CB LM Power 1 and 2, Open. Then the LM Power switch to reset, release. In the LM, panels 11 and 16, X Lunar Bus Tie breakers closed. On panel 16, the Ascent ECA Control closed; the Descent ECA Control closed. On panel 14, Bat 5 Normal feed On, followed by BATS 1, 2, 3, and 4 Low Voltage taps On. Then Bat 5 Normal feed Off. Then Ascent ECA Control breaker Open. [13:51:48] so the RJB got power via the xlunar bus tie from batt 5 to enable the taps in the des bats? [13:52:25] In order to get power to the Descent Stage's battery control system, Fred is told to select Normal SE Feed on Bat 5. Putting this switch to the On position connects one of the two Ascent Stage batteries into the power distribution system. Thanks to the previously closed XLunar Bus Tie, this feeds power also to the Descent Stage control electronics, which are normally tapped to the Commander's Bus and should at this point [13:52:26] get their power via the LM umbilicals, from the CSM's Main Bus B. In the case of 13, this power is not available and they need to supply the power from the LM's own batteries. [13:55:02] hmm [13:55:26] are the LM main buses not powered in the initial configuration of that? [13:56:02] if all you want to do is enable the descent batteries, that's done with power from the descent ECA control CBs [13:56:15] I think there was no power to enable the battery taps via the des eca controller [13:56:49] looks like bat 5 was energized to power the eca controller via the xlunar bus tie? [13:57:11] this is at the start of powering up the LM? [13:57:45] yeah looks that way [13:57:57] so CSM LM power was enabled before the accident [13:58:01] so CM MNB dead, LM cold and dark basically [13:58:11] but the CM lost MNB while that was ON [13:58:16] yeah [13:58:29] (man 13 is a great case study for trying to learn this) [13:58:41] and the control signal from the CM only comes via one of the LM power CBs [13:58:49] something I added with my update [13:59:25] oh doesn't matter [13:59:30] both LM power CBs are on MNB [13:59:46] nice redundancy... [14:00:15] haha yeah [14:02:25] bat 5 norm feed just powers a bus in the LM [14:02:36] so descent ECA control has power [14:02:41] and you can switch on the descent batteries [14:02:59] not sure how xlunar bus tie comes into that [14:03:08] but then I don't 100% understand those anyway :D [14:21:07] From what I am gathering the - busses are completely separate unless the xlunar ties are in [14:21:28] therefore the CDR/LMP busses cannot share unless the ties are closed thus completing the circuit [14:23:23] "Ties d-c bus translunar loads to LM single point ground" [14:23:46] cross tie? [14:24:54] xlunar bus tie breaker description [14:26:18] yes, but " CDR/LMP busses cannot share unless the ties are closed" that is cross tie [14:28:08] I know the BAL LOADS breakers are closed [14:28:41] that would facilitate sharing [14:31:34] I'm definitely missing a university level electrical engineering lecture or two to properly undestand the xlunar bus tie [14:33:04] It just seems like a floating ground to me [14:38:35] the CDR and LMP 28V busses each have their own independent -BUS [14:39:06] with the x-lunar ties out, they do not share a ground, and therefore cannot share a load [15:02:37] https://history.nasa.gov/afj/ap13fj/09day3-lifeboat.html this page does have some info as well [15:40:06] I think we need more wiring diagrams [15:47:23] LDW 390-54000, LDW 390-60000 [15:47:47] those will be the Grumman level 3 drawings for the EPS [15:48:06] for earlier and J-mission LMs, respectively [15:48:33] NARA will have them, but I don't think they're scanning stuff for the public at the moment :/ [15:49:21] but there's no harm in asking if you think that might have answers [15:50:04] do you have pdfs of those? [15:50:17] or are they unscanned still [15:54:37] no, they are unscanned [15:55:10] damn ok [15:55:18] yeah they still have the COVID notice up [15:58:07] I guess it wont hurt! [16:01:40] elementary functional schematics have a DC wiring overview [16:02:31] trying to find that one as well [16:08:22] page 370 [16:08:25] in NTRS 891 [16:08:32] that's the Apollo 14 version [16:08:33] oh [16:08:38] and it says it applies to LM-9 [16:08:44] so that answers my question about that [16:09:25] haha [17:23:54] sending NARA an email is funny [17:24:16] their inbox will look like the spam folder of my old yahoo account that I haven't looked at in years [17:30:07] hahaha [17:34:26] well we will see what happens [19:25:48] Hey [19:25:59] Glad you're feeling better Nik. Not COVID was it? :) [19:28:43] unless Covid managed to mutate into bacteria, no, haha [19:29:42] Good haha [19:31:00] in my family I'm probably the person at most risk now. The only non vaccinated people are my two half brothers, 7 and 5 years old, who could get it at school or Kindergarten and then give it to me. [19:31:06] from COVID I mean [19:31:41] without them showing symptoms [19:31:47] You got both shots already? [19:31:56] non vaccinated except me I mean [19:32:09] so I am at most risk, the oldest not vaccinated yet haha [19:32:49] Oh ,yeah I follow you. [19:33:48] I'm getting the second one next friday. :D [19:33:55] oh you are quick [19:35:00] Yeah, I'm listed as an at risk group due to have cases of bronchitis during my childhood. [19:35:50] I've got meds for it now but if I get a very severe cold it tends to develop into that. Hasn't happened for the last 10 years though luckily. [19:35:57] makes sense [19:40:37] whats funny is I havent even had so much as a cold since 2019 [19:43:25] I mean I haven't been sick since 2019 either. Apart from things like a cold that aren't more than a nuisance. Nothing that actually kept me in bed. [19:43:55] yeah I haven't properly been sick since... yesterday. But before that it was a good run :D [19:44:42] TBH diseases haven't really had the chance to spread since last year either. [19:45:05] yeah, COVID is the apex predator and doesn't like competition [19:46:47] maybe people will stay 10% as careful as they are right now [19:47:19] that would already help with spreading all the other diseases in the years to come [19:49:05] In either case I think people will keep COVID in the back of their minds after this is all over. Hope people are motivated to just stay home when they're not feeling well. [20:01:30] rcflyinghokie, the LM to CM power uses both LM power CBs in the CSM, right? [20:19:37] they are redundant lines [20:20:01] yeah [20:20:30] I guess it doesn't really matter, just the flow direction is different [20:21:34] I really see no easy way for LM to CM power to work... [20:21:44] I was hoping for a negative power load solution [20:21:57] but even that needs some rewiring [20:31:39] to support all cross tie and other combinations the LM wiring is quite complex [20:31:56] BTC_XLunar is the source of CSM power [20:32:22] BTC_XLunar -> BTB_CDR_A -> BTB_CDR_E -> CDRs28VBus [20:32:30] is what is wired together in the LM alone [20:42:56] both were put into operation as they could carry 7.5A each (for a total of 15A) [20:43:30] yeah absolutely [20:43:58] it is a bit complex to work out code wise especially [20:45:04] I really want to better understand the xlunar bus though [20:45:32] thats what offers the -for the CSM power connection [20:45:54] power from CSM being grounded (back to) the CSM? [20:46:22] yeah from what I can see [20:46:55] its the floating ground [20:47:28] XLunar bus' only function is to act as a ground between the two spacecraft [20:47:35] IIRC the tunnel is bonded to the XLunar bus [20:47:45] yeah exactly [20:48:04] so what would happen if that connection is missing with CM power on [20:48:20] should we kill the crews in that condition? :D [20:48:27] which connection specifically? [20:48:37] no xlunar bus [20:48:58] If the XLunar bus is not connected the best thing to happen is no flow of current [20:49:05] yeah [20:49:07] yeah it has no ground return [20:50:05] we aren't really simulating ground return for anything, so adding any condition using those CBs (or the redundant wiring with the relays) would be a bit artificial [20:50:10] right [20:50:11] I guess it would be possible to accidentally have an alternate ground return not rated for the current and that would melt and catch fire but that's so unlikely I wouldn;t bother simulating it. [20:50:18] Don't know how you would either. [20:50:25] I am just trying to get the current flows down first [20:50:33] and what conditions would do what [20:51:55] indy91 in the CSM/LM Primary Power Transfer Logic schematic, I see the DC going from the CSM 28V bus through the CSM breaker and switch to K3 and K4 [20:52:03] Are K3 and K4 in multiple places? [20:52:38] I see K3 and K4 between the - and xlunar busses, but also panel 11 where the DC power flows [20:52:53] yeah, the relays themselves are in panel 11 [20:53:00] they switch like three things [20:53:34] have to be energized for the power to the CDR bus to be connected [20:54:07] they have to be deenergized for the descent ECAs to be switched off [20:54:29] that's something I implemented recently [20:54:32] basically the order is [20:54:37] some descent power is on [20:54:41] ok that would explain why they appear closed where the DC power comes in and open between the xlunar bus and LM - busses [20:54:44] you switch LM power to CSM in the CSM [20:54:54] that sends the signal to switch off the descent ECAs [20:55:03] when all are off, the panel 11 relays can be energized [20:55:06] it specifically sends HV/LV off command, correct? [20:55:13] and that cuts off the connection to switch off the HV/LV taps [20:55:34] so that signal, switching HV/LV off, isn't on permanently [20:55:42] right which we discovered previously [20:56:12] the steady state condition is then the relays being on. While CSM delivers power [20:56:46] and power is required to keep them on, correct? [20:56:55] no power they switch off? [20:57:22] yeah [20:57:49] and the third signal it switches is the redundant wiring to the xlunar bus tie CBs [20:57:57] parallel to the CBs [20:58:27] so in 13's case, losing CSM MNB, those relays became deenegized, but no command was sent for LV taps on? [20:58:34] deenergized* [20:58:43] yes [20:59:35] LV taps on requires LM power to reset [20:59:47] and power from the CM, through the LM power breakers [21:00:04] ok so the switch was put in reset even though no power was coming from the CSM [21:00:34] then xlunar ties were closed, allowing the LM CDR/LMP 28V busses to share [21:01:03] and allowing bat 5 to power the LM [21:01:27] then bat 5 provided the power to enable LV taps in the des batteries? [21:01:36] yes [21:01:42] via LM internal circuits [21:01:46] DC bus has power [21:01:54] and then descent ECA control CBs [21:02:14] I'm not really sure what the LM power reset did for 13 [21:02:23] probably just to not have it on [21:02:43] yeah, definitely want it to Off at least [21:03:00] the reset was probably just the nominal step [21:03:06] since its spring loaded and all [21:03:15] so the eca cont breakers were closed before bat 5 was brought on the line [21:04:01] not sure that mattered really [21:04:12] you need descent ECA cont to switch on the descent ECAs [21:04:24] and ascent ECA control only for switching battery 5 off again [21:04:28] I think [21:05:47] I added a condition that the ascent battery needs to have 5V at least to switch the norm or alternate feed on [21:05:55] it does use battery power [21:06:11] unlike the descent stage [21:06:31] ah ok [21:07:31] so battery 5 powering both busses (that now share a common ground via the xlunar bus) provides power to the des eca [21:07:46] that allowed the switches to generate the LV commands? [21:09:51] descent ECA cont CBs are redundant for this [21:10:01] so only one DC bus having power would be enough [21:10:35] the ascent ECA cont CBs are actually 100% identical in their function [21:10:46] in the systems handbook their wiring comes together just after the CBs [21:10:51] not quite the same for descent, but close [21:11:19] something for the relay junction box [21:13:02] yeah required for full automatic switch from descent to ascent power using the abort stage button [21:13:53] in effect having one descent ECA cont CB open doesn't break aynthing [21:15:41] that makes sense [21:16:03] and for this quick power hack they only used panel 16 eca cont breakers anyways [21:35:09] night! [11:07:24] I think I have a little better grasp on the translunar bus after digesting it a bit last night [11:08:16] hey [11:08:36] I'm looking through the schematics to better understand input/output of the relay junction box [11:08:52] making a list of the connectors and its pins [11:09:10] so what have you learned? [11:11:21] So I have solidified that the xlunar bus acts as the floating ground for CM power and is isolated from the LM negative busses via K3 and K4...K3 and K4 when reset, tie the two negative bus bars together but probably dont handle the load a powered LM would provide thus the xlunar bus tie breakers [11:12:04] thats pretty much the sole purpose of the xlunar bus...floating ground for CM power and negative bus tie for the CDR/LMP 28V busses [11:15:47] so with CM power [11:16:02] negative buses and translunar buses are disconnected [11:16:13] translunar buses can handle load of heaters etc. [11:17:33] and then LM on its own power, powered up. Connection between those buses is done with the redundant wiring [11:17:37] K3/K4 not energized [11:17:44] and xlunar bus tie CBs closed [11:19:49] I find it slightly confusing that the xlunar buses are only used without the CM [11:20:10] uhh [11:20:13] the CBs I mean [11:20:35] xlunar buses are THE negative bus for the LM, with return to the CM, when under CM power I guess [11:21:52] yeah the xlunar bus needs to be isolated from the LM ground [11:21:59] hence floating ground [11:22:09] thats the purpose of that circuitry [11:22:32] all the equipment is connected to the negative buses though [11:22:52] I think those heaters are connected to the xlunar bus [11:23:00] ooh [11:23:02] there are items explicitly listed as xlunar bus [11:23:22] look at the cb load list, and there is an xlunar bus column [11:23:36] Systems Handbook? [11:24:21] ah I see it [11:25:15] S-Band heater, ASA, IMU opr, flood light, annun/dock/component, RR heater, LR heater, IMU standby heater [11:25:25] that makes a lot more sense to me now [11:26:09] so, if for some reason, you have the following configuration [11:26:29] K3 and K4 energized, xlunar bus tie CBs open, CM not docked [11:26:47] then those CBs using the xlunar bus are in trouble [11:27:11] yeah I think I get it now [11:27:18] took long enough :D [11:38:35] yep! [11:39:30] I think the big missing piece was realizing that cbs were on the xlunar bus, and that the xlunar bus had to be able to tie the negative busses as well as isolate from them [11:47:26] would probably take a bit of work redoing the power to make this more accurate [11:47:55] yeah, I think we really don't require grounding anywhere in the EPS [11:50:22] yeah [11:51:41] oh and I was doing the thing with the RJB connectors and pins to figure out how some signals work [11:51:47] the Systems Handbook has it wrong [11:52:19] all signals for LV taps on and HV/LV reset go through the RJB [11:52:24] HV on doesn't [11:52:57] so what I should probably do is move some logic from the ECA to the RJB [11:53:32] adds more code as I have to add stuff for each battery individually [11:55:04] but it would actually run less code over all, as some things are currently done 4 times, in each half of the descent ECAs [11:59:42] so HV on is generated in the ECA only when the switch is thrown? [12:00:52] yep, exactly [12:01:10] signals going through the RJB can have other sources like CM, GSE ro abort stage [12:01:12] or* [12:01:47] I guess that does mean that GSE can't switch HV on [12:01:53] but I guess it doesn't really have to [12:02:10] the only configuration with the LM on the pad and lots of LM systems powered on is with someone in the LM present [12:02:37] and the batteries would rarely be used anyway [12:10:38] yeah I dont think HV was needed to be switched on at all to begin with as the battery voltage was high as it is [12:12:51] and too high for us right now, but that's another story haha [12:13:01] yeahhh [12:13:27] ok so what's our plan right now. Still trying to get LM to CM power to work? Then merge the update with your branch and have one big update that breaks a few things? [12:14:01] I still want to see if we can get the power to work before breaking anything, as our branches really arent bug critical yet [12:14:13] And mine still needs connection to PAMFD for the hoses [12:14:52] right [12:16:42] Ok so what is in place currently [12:26:55] for what? [12:27:55] facilitating power transfer [12:28:12] let me rephrase..how does CM->LM power work currently [12:29:58] there is a bunch of bus feeds wired together in the LM, all one directional [12:30:12] one of its sources is a class that gets power from the CM [12:30:19] that checks if voltage is there etc. [12:31:10] all works according to our usual system [12:31:17] e-systems having one source [12:31:24] and they get their power from there [12:31:44] the CM has a PowerMerge with two LM power CBs [12:32:14] that gets wired to the CM/LM connection in the class for the LM power switch [12:33:36] right now I only see one real chance to get LM to CM power working [12:33:44] implement it like battery chargers [12:34:59] using a separate wiring from CM to LM power [12:35:59] the better option would be a total overhaul how our power systems work, not one directional etc. [12:41:03] hey guys [12:42:32] a major paradigm shift in how esystem works would open up a lot of possibilities. [12:44:04] yes it would [12:44:33] make esystem work like hSystem, where pressure is analogous to voltage, and mass flow rate is analogous to current [12:44:36] I am up for analyzing the power systems [12:46:34] we need to look at it as a whole though, where do we start without gutting the whole thing [12:46:49] in that case, why don't we skip LM to CM power for now and get these updates merged [12:47:00] damn ok :P [12:47:20] So mine just needs something to connect or disconnect the hose from the LM [12:47:53] The suit flow valves work now though at least for the o2 hose (I didnt do the rest of the plumbing as that would be a lot of rework and I will when I tackle the CSM ECS [12:49:55] ok, I think I'll do this: Make the RJB changes that I want to do, although I might skip that. Then I'll switch to your branch and make a PR for it. [12:50:14] And then you merge your branch into Orbiter2016 and I quickly merged mine into it after that [12:50:44] do you have any scenario editing to do? [12:50:54] what exactly was it that your update is breaking? [12:51:09] let me see if launching a new one adds the tanks [12:51:32] I think I got it so it doesnt need editing [12:53:28] great [12:53:37] oh btw [12:53:48] are the current scenarios outdated for the LM ECS already? [12:53:55] like Apollo 11 pre PDI [12:54:05] is that is what is causing the master alarm? [12:55:40] Its possible, glycol was changed as well as all those new cold plates are added and they are cold when initialized [12:55:47] let me jump in and check a few [12:56:05] my CSM O2 hose looks ok though it adds the necessary parts [13:00:09] yeah they are outdated [13:00:15] they might need some tweaks [13:12:31] correction, they will need them [13:18:10] I can make those changes [13:23:23] how necessary is editing the scenarios though [13:23:29] for me it was definitely required [13:23:37] as old scenarios with the descent stage are in LV [13:23:42] which can be close to not working right [13:23:48] and ascent stage would just be off [13:25:43] for the merged LM ECS changes very [13:26:15] I am working on that now [13:34:06] don't edit old scenarios [13:34:11] I have done that in my branch [13:34:27] I'm not sure if git can merge those [13:35:44] it could work because it is text [13:36:43] ah I didnt think about that [13:38:03] hmm [13:38:09] I feel like it should be fine [13:38:13] it's not like git understand C++ or so [13:38:21] and git does detect the files [13:38:31] text files as text, not binary [13:38:47] this wouldn't work with the checklist Excel files for example [13:38:56] but I think git might be able to auto merge scenarios [13:39:38] yeah I think it can, as it does with the cfg files [13:40:50] we should probably check the scenarios afterwards, but it will probably be fine [13:45:29] yeah that was my goof for not doing so even though I knew it would break old ones lol [13:59:20] yeah, git shouldn't care about what type of text file. as long as the diff looks right it should be fine. [14:09:30] this is going to be a pain to edit lol [14:12:25] I need to edit every single one because of the CSM changes [14:19:08] sounds familiar [15:00:31] oh well, needs to be done haha [16:15:30] Almost done with 11 missions lol [17:01:23] morning! [17:04:11] hey mike [17:06:21] what's up? [17:09:43] editing scn files [17:11:14] lol fun times [17:17:19] mike, is their a tried and true method for reading through looooong assembly listings without going crazy? [17:17:44] unfortunately I think you are asking somebody that has gone crazy [17:17:52] what is this for? [17:18:27] 7094 stuff [17:20:53] do you have a link I can look at? to see if it jogs any ideas [17:21:55] https://sky-visions.com/ibm/7090/ibsys/src/text/ [17:24:00] oof [17:24:03] I have the same problem with agc assembly. it's easy to see what each line does, and what very sections of code do, but picking out medium sized structural things doesnt come naturally for me [17:24:13] yeah syntax highlighting will go a long way [17:24:29] hmmm [17:25:20] are there logical dividers for these things, like log sections in AGC assembly? [17:27:11] I'm not 100% sure. [17:28:33] so, the two big listing types I've had to deal with are AGC and Honeywell 1800 (for Yul) [17:29:14] the former I learned my way around through extreme exposure, by transcribing all of Don's listings [17:29:55] which involved reading through the same sections of code over and over again looking for differences between versions... so I kind of slowly picked up the general structure that way [17:30:31] the latter, I was completely unable to understand until I started trying to port it to python for pyul [17:31:15] I don't know if I would recommend either in this case though, since (a) the code is already in a nice digital format and (b) there already exists a working assembler/emulator [18:04:02] Got a reply on the drawings [18:04:25] Apparently there are over 200 and they are 4 bucks a piece to scan? [18:04:43] I feel scammed [18:07:07]