[12:41:27] NASSP Logging has been started by n7275 [12:41:29] Thymo, so I spoke to Tschachim and he is going to look into whether ot not he still has access to the NASSP twitter account. [13:19:45] hey [13:51:45] hey Matt [14:02:15] how's it going today? [14:03:06] just checking why Ryan had a large corridor control burn [14:03:28] can't reproduce it [14:04:31] but I discovered one small bug and one thing I am unsure about [14:06:44] want my scn? [14:06:58] I could have screwed up of course [14:06:59] I have a scenario just after MCC-2 [14:07:11] but you might be able to rule out operator error [14:07:27] do you have a scenario saved with flyby and PC+2 on the MPT? [14:07:51] https://www.dropbox.com/s/fs31ra6gbzorlz8/Apollo%2013%20-%20RTE%20Work.scn?dl=0 [14:07:52] so that I could better reproduce it [14:08:05] should be there [14:08:33] the AST solution already had the 18 ft/s, right? [14:08:47] Yeah I saved that shortly after I took the screenshot [14:09:04] the L in "LFCUA" was only a display bug btw [14:09:15] it checked the wrong state vector for Earth vs. lunar reference [14:09:49] but not for the calculation [14:10:10] so the math was good haha [14:10:12] also, I am not getting a 815 ft/s burn [14:10:18] I get 840 [14:10:42] I dont know what to tell you there lol [14:10:45] back in a sec [14:13:26] the flyby maneuver doesn't reenter. Perige of 200NM. [14:14:46] that will probably make the difference [14:17:07] if I recalculate it then it's fine [14:17:24] 41.1 vs 41.7 ft/s [14:17:47] not sure what the cause of that is. Maybe you calculated the flyby burn before updating the state vector? [14:18:22] maybe it was using the post MCC-2 state vector [14:19:03] I think that's the most plausible explanation [14:19:13] that 0.6 ft/s difference growing to 18 ft/s by 105 hours [14:19:35] well I computed an anchor vector right before starting all of these [14:20:01] so i assumed that was current [14:20:12] and using the TUP button. All that before even starting with the flyby calculation? [14:20:40] maybe I can recreate it with the scenario directly after MCC-2 [14:21:51] hmm [14:21:53] not exactly [14:22:13] yep [14:22:27] you can look at the time on the anchor vector [14:22:51] where? [14:26:02] the order I think happened is: MCC calculation -> anchor vector update and MCC transfer to MPT -> PC+2 calculation [14:26:24] so when I make it calculate a corridor control burn it has the current, actual trajectory [14:26:38] but that wasn't used for the flyby and therefore it's a little bit off free return [14:28:07] on the page where you do the TUP [14:28:17] doesnt it timestamp the vector in the top after a TUP? [14:28:29] yes [14:28:30] and the vector was the very first thing I did, that much I am sure of haha [14:28:39] well I can't really check that haha [14:28:50] why not? [14:28:50] the scenario you just send me has the updated vector for sure [14:29:02] ok [14:29:07] that is the entire problem [14:29:13] the flyby was calculated with a different vector [14:29:15] I think [14:29:17] I am confused [14:29:29] I did the anchor vector before computing anything [14:29:47] or maybe you had the MPT mode not activated? [14:30:42] first steps were activate MPT, delete the old burns, initialize, and did the anchor vector [14:30:43] I am fairly sure the flyby maneuver was not calculated with the anchor vector in the scenario you sent me [14:31:01] and so the DV was slightly different [14:31:05] thats really odd [14:31:24] and after the state vector update the trajectory isn't free return anymore [14:31:31] close [14:32:35] hmmm [14:32:50] I updated the anchor vector before clearing the MPT of old burns [14:33:13] hmm interesting. Shouldn't cause problems, but it might [14:33:14] I think that was the order I did it [14:33:39] I'll try to reproduce it with that [14:33:55] were you using 40 or 60NM as the lower pericynthion limit? [14:34:38] whatever was default [14:34:41] 40 [14:34:46] oh and did you delete maneuver 1 first [14:34:47] or 2 [14:34:50] 2 [14:34:53] ok [14:35:52] nah, I'm getting the 41.1 ft/s solution [14:36:03] and not the 41.7 one you have on the MPT which doesn't reenter [14:36:09] transfer options? [14:36:15] ullage and DPS settings? [14:38:25] So I wrote down what I did: [14:40:00] Initialize MPT, set anchor vector, delete old burns in MPT, TLMCC Option 9, VTI & TIM 61:30, Constraints F29 upper 135NM, tradeoff table CLC, ENG, CSM, dont replace, 1, DPS, PGNS, 4 10, iterate, 5s, 0.40, optimum tig, CLC [14:40:08] thats what I wrote down last night [14:40:51] hmm [14:41:09] I wonder if that should be -5 seconds [14:41:27] but when to do that or not is quite confusing :D [14:41:35] yeah I am still a touch lost on it [14:42:44] maybe that's how they did 3 step burns [14:42:53] using 5 seconds at 50% makes it go [14:42:57] 10% for 5 seconds [14:43:04] 40% for 21 seconds [14:43:14] and then it automatically throttles up if the burn isn't over yet [14:43:40] I'll have to think about that [14:43:56] anyway, I don't think we'll fully figure out what happened there [14:44:05] but if I start from scratch in your scenario it all works out [14:44:18] so, here is one interesting thing I am unsure about [14:44:26] flyby and PC+2 burn on the MPT [14:44:45] calculating a corridor control burn at 105h using a vector time from before PC+2 [14:44:55] that's what you did yesterday [14:45:12] when it comes to the RTE Digitals, what weight should it use? [14:45:20] pre or post PC+2 weight? [14:45:27] post [14:45:28] vector time was before, but TIG is after PC+2 [14:45:38] yeah, that's what it's doing [14:45:53] that was the first thing I noticed here: https://www.dropbox.com/s/2l6r3wktnvy4w11/Screenshot%202021-05-26%20182100.jpg?dl=0 [14:46:06] 90055 lbs, post PC+2 weight [14:46:33] I could make it use the weight at the vector time, but it's probably better to use the weight at TIG [14:47:02] I guess it's up to the user to enter consistent vector times for calculations [14:47:07] yeah weight at vector time could be problematic, especially if theres a large burn [14:47:25] but I see where both could be used [14:47:55] just need to make sure it's all consistent when you used a vector time that wasn't the same as TIG [14:48:26] so I leave that as it is [14:51:04] yeah I still need a lot of practice with all of this [14:51:19] yeah it's a lot haha [14:51:28] and definitely not bug free [14:51:43] so always good to chase something like this [14:53:36] absolutely [14:53:49] 13 makes a pretty fun case to test as well [14:54:41] yep [15:26:33] I've also started to remove the old lunar launch time calculation, still used by the MCC [15:27:32] and that issue that happened to someone where it calculated the time for the wrong rev really shouldn't happen anymore [15:33:21] unless the TPI time estimate is off by an hour :D [15:59:34] haha great [16:25:10] so I guess what's next on the docket [16:27:16] for me a few smaller RTCC things that I put off until after the RTE update [16:28:26] I know theres a bunch of things like the power project on the horizon..but are we looking to support Apollo 12 or beyond with NASSP 8? [16:29:20] I'd rather not do it, not until we have really run out of things to do [16:29:24] not for the MCC at least [16:29:37] makes sense [16:29:53] I still have a bunch of updates I want to do for the Apollo 7-11 MCC [16:30:04] oh like what? [16:30:36] like the new deorbit targeting [16:30:45] used by the RTCC MFD right now, but not the MCC [16:33:01] and when he have the more realistic drag some stuff will need to be adjusted and tested as well [16:34:33] Oh thats right they are separate computations [16:35:42] I'd love to get ggalfi back in here, I need to pick his brain further on the VESIM stuff I really want to get my sticks set up...keyboard is expensive fuel wise :P [17:40:58] Evening! [17:41:43] n7275: Damn, didn't know he was even alive still. I tried to contact him years ago but never got any signs of life back. Nice one [18:07:48] So I have been thinking about the LM/CM power thing...its only one way right now but how do we make it share a bus? because that's essentially what its doing in this case [19:03:28] so in terms of circuit breakers and connections, how did the LM to CM power work? [19:04:12] the only chance we have is to put a negative power load on the CM DC Bus, coming from the LM [19:04:29] otherwise we would have to change fundamentally how our power distribution works [19:10:01] You mean how it actually worked? [19:12:20] yes [19:12:55] and do you think we might want to try and make the ECA stuff better as the first step? Would that help? [19:16:02] So in the CM, main bus B powered the 2 LM PWR cbs which went to the LM PWR CSM switch, from there, when enabled, logic disabled the LV and HV taps on the LM batteries and power from the CM Main B went through the umbilicals to the LM ECAs and from there to the x lunar busses [19:16:35] so at that point, the xlunar bus essentially was a load on the CM main B [19:17:43] which is why it worked in reverse, the LM busses were energized with the batteries and the CM main B was a load on that in simple terms [19:18:15] so when hooked up, the buss voltage in the LM was essentially seen by the CM Main B and was able to be sent to the battery charger etc etc [19:18:33] right, from bus B to the charger it worked normally [19:18:34] And yes I think the ECA would be a good first step as it controls the logic [19:18:35] Didn't the ECA breakers also get pulled after setting it up in a certain way to prevent the LM buses being disconnected when CM power was applied? That's what I recall from when I looked at it. [19:19:10] only the ascent ecas [19:21:43] so what they did was put ascent batteries on the line and shut down the descent batteries, connected the umbilical and closed the LM pwr breakers in the csm, closed the batt b entry/pl cb, sig sensor main b cb, and main b bat buss b cb [19:22:05] then LM pwr csm switch was thrown, and this would have normally brought the des bats offline but they were already [19:22:44] then batt b was taken back offline and the des bats in the LM were brought back [19:23:15] the ECA breaker was only used when working the ascent ECAs [19:24:41] the principle was of course energizing the CM MNB with the LM BUS [19:25:46] After MNB had power from the LM they simply fired up the battery charger with a small procedure to get the inverter up on MNB and subsequently the charger connected to a battery (A first) [19:26:02] the two LM power breakers in the CSM are set up as a PowerMerge [19:26:20] which I don't think is correct [19:26:27] it is separate power lines [19:26:30] going to the LM [19:26:44] so that might also be an early step to get this working [19:27:03] PowerMerge checks its source voltage [19:27:11] yeah both breakers connect to the LM umbilical from MNB via the switch [19:27:21] I think they are redundant [19:27:33] so if we don't have to rewrite the PowerMerge class then that already helps a bit [19:27:54] absolutely [19:28:18] the code side I am not well versed with but I think I understand the actual hardware part pretty well [19:33:02] yeah the problem is that our power system is build very one directional when it comes to the power flow [19:33:05] it is usually [19:33:11] has source voltage? [19:33:15] if yes draw power [19:33:19] if no system doesn't work [19:33:44] that's why the battery charger work in a bit of a cheaty way [19:33:48] right [19:34:01] which might be the solution we have to do as well, we will have to see [19:35:00] oh another little gotcha, I dont know how its handled, but I dont think the LM PWR CSM switch will actually send the command to the RJB in the LM without power on it...which would explain the procedure putting BATT B onto MNB before throwing the switch and then taking that battery off the line [19:35:08] I need to look at that further [19:36:16] right, that shouldn't be too difficult [19:36:37] hmm is the RJB part of the ECA or is that its own animal? [19:37:02] we don't really have a good version of that [19:37:06] because it looks like the RJB controls the LV/HV OFF command or LV ON command [19:37:09] but it's a separate system [19:37:35] that job is currently done by [19:37:36] int csm_power_latch; [19:37:43] in the LEMPowerConnector class [19:38:19] but I will add a RJB class with relays [19:39:33] It looks like just that circuit being energized from the CM sends that signal? [19:40:11] for csm_power_latch? [19:40:14] It also looks like the RJB is separate from the ECAs but just communicates with them [19:40:24] in the actual hardware [19:41:01] I said that wrong actually [19:41:22] I believe csm_power_latch in the real LM is two relays located in one of the panels [19:41:35] the relay is energized just by virtue of getting power from the switch correct? [19:41:36] I think it's those 4K3 and 4K4 [19:41:41] yes [19:42:18] I forgot if something in the LM also needs to be set [19:42:30] I believe the Grumman schematics are clearer than the Systems Handbook about this [19:42:47] I need to look at that [19:43:09] which one? [19:43:14] I forgot the naming convention [19:43:25] archived NTRS [19:43:26] 19710070889 [19:43:35] 19710070891 [19:43:48] it's called elementary functional schematics [19:44:14] yep I have them [19:49:03] now where are they somewhere in the 4- section [19:51:15] I see CSM control going direct into the RJB as expected [19:53:38] ah 889 doc pdf 291 [20:59:15] night! [21:02:29] see ya! [22:18:44] I PMed Xyon today since I wasn't able to add prefixes to forum threads anymore. Turns out they weren't enabled on the NASSP forum when it they updated the software. They're enabled again now. :) [12:12:43] .tell indy91 any idea why the line: //LMPIsolValve.Init(this, &LMPSuitIsolValve, &LMPActuatorOvrd); was commented out in the following PR? [12:12:56] .tell indy91 https://github.com/orbiternassp/NASSP/pull/595/files [12:44:31] hey Ryan [12:44:41] morning [12:45:38] yeah, that's an odd one [12:47:00] It was done with a lot of VC stuff I am wondering if it was an accident [12:47:28] I dont think Alex is on the Libera yet [12:50:30] https://github.com/orbiternassp/NASSP/blob/e16292a728aa7dd1bf06edbafdd902f76308e70f/Orbitersdk/samples/ProjectApollo/src_lm/lm_ecs.cpp#L747 [12:50:48] Looks like it controls the disconnect when you press the actuator override. [12:51:05] Haha I know what it does...I helped design it in here :P [12:51:20] Not sure why that would be commented out. [12:51:26] I am wondering why Alex commented that out, I am thinking its a mistake [12:51:39] it's almost like he was going to change the definition of the init function, had it commented out while testing and then never uncommented [12:52:18] there are two other changes to lemsystems.cpp in that commit [12:52:26] yeah thats when a lot of LM ECS stuff was added to the VC..unless it breaks something in the VC it should not be commented out [12:53:37] worth a try uncommenting [12:53:45] see what happens [12:58:36] Haha I already have [12:58:46] I havent seen anything break in VC [12:59:21] I just wanted to check with Nik/Alex to make sure it was an accident [13:07:27] Its just the logic for the override though [13:07:37] It should have no effect on the valve itself [13:20:52] probably wouldn't hurt to message Alex and Jordan on github/orbiteforum about the switch to Libera [13:41:26] I shot him a message [14:12:08] hey [14:12:24] Oh hey haha yeah that ^ [14:17:30] Looks like it was something Alex left commented out by mistake...I believe its just the actuator (disconnect) code [14:17:31] hmm, probably something Alex did by accident [14:17:49] it shouldnt effect anything but the disconnect logic [14:19:29] right [14:19:48] we should ask him, but I'm sure we can simply uncomment it [14:21:18] yeah theres a PR sitting there with it uncommented, but we can ask first [14:22:35] I was researching the ECAs and found something interesting [14:22:39] Oh? [14:22:55] to accomodate the lunar battery they didn't actually change the descent ECAs, which I had assumed before [14:23:31] they wired it differently, so that the lunar battery uses the low voltage wiring from batteries 2 and 3 [14:23:56] and to make the new switches work they added a battery control relay assembly [14:24:42] so instead of changing the ECAs they added a system on top of them for the new control logic [14:25:08] I think that will make it easier for us to have both version eventually [14:26:32] Oh interesting [14:26:45] I always thought the Grumman schematics document with the ending 891 had changes while 889 has the original version [14:26:51] but it seems to be the other way around [14:27:11] 889 has the battery control relay assembly and lunar battery [14:27:15] 891 doesn't yet [14:27:15] I havent looked into the stay battery much, did it have LV/HV taps or just LV [14:27:41] Or rather, was it like the ascent batts where it didnt use taps [14:27:46] two switches, but you could choose CDR vs. LMP DC bus with that [14:27:48] and not taps [14:27:59] so put the battery on either bus [14:28:46] oh I see [14:29:46] I guess it simply uses the LV circuitry that were used for batteries 2 and 3 [14:29:50] in the ECAs [14:29:58] and that's what you are switching on/off [14:30:40] and only HV of course then [14:30:59] no option to switch between LV or HV for the lunar battery [15:17:01] Was the lunar battery the same size as a des bat? [15:20:51] also 400 Ampere hours, yes [15:24:59] I'm working on the logic for the descent ECAs [15:25:02] 415? [15:26:06] 400Ah were pre J missions [15:26:43] then they didn't update that in the flown Apollo 15 Systems Data [15:26:54] which is Systems Handbook pages [15:29:26] hmmm [15:30:32] Maybe LM-9 used 400Ah? [15:30:37] I know LM-10 used 415 [15:32:08] hmm [15:32:35] "Manufacturing [15:32:36] processes were altered and additional flight battery cells were fabricated [15:32:37] for use in ground tests to refine battery ampere-hour capacity predictions." [15:32:48] Apollo 16 [15:32:59] Interesting [15:33:26] maybe they didn't actually change the batteries, just 415 being closer to the actual [15:36:49] This has me intrigued [15:38:56] ah no [15:38:58] so the cell count remained the same, so I guess as that states, the batteries were improved [15:39:09] they just didn't properly update the documentation [15:39:12] for Apollo 15: [15:39:13] ahhh [15:39:20] In addition to the four descent batteries (par. A.2.1), a fifth bat- [15:39:20] tery (called the lunar battery) was provided to increase lunar stay time [15:39:21] capability. The capacity of each battery was 415 ampere-hours compared [15:39:22] with 400 ampere-hours for previous missions. [15:40:08] thats what I thought [15:44:46] I still want to better understand how our batteries work though, like the voltage in the cfg file, how the CSM did the Ah computations etc [15:45:59] I computed the LM bats using 30V [15:46:17] based on the "nominal" voltage of 30V [15:47:23] and in the LM's case, we should never see a voltage >32.5 or so with a load applied to the batteries [15:53:49] CM batteries are supposed to have 40Ah, and if I back calculate the voltage they were computed using 38.25V [20:43:18] night! [13:41:15] good morning [13:58:32] morning! [14:25:16] I am trying to figure out how our batteries actually work and the C++ is just enigmatic to me :( [14:25:34] The voltage things bother me especially with how amp hours are computed etc [16:33:24] amp hours are a weird unit. [16:33:39] basically just charge [17:25:13] morning! [18:20:28] hey mike [13:58:56] hey Ryan [13:59:20] sorry I haven't been much help on the batteries [14:02:20] storing their capacities as amp-hours is basically just storing the total number of electrons that will flow from then (AH*3600*faraday, if you wanted an exact number) but that doesnt explicitly tell you joules [14:03:28] I think calculating a volts(amps) function from the databook would be a good start [14:04:16] I usually use webplotdigitizer [14:05:04] I can help you impliment an iterative loop [14:14:12] haha well I know how battery chemistry works [14:14:35] I mean why the CSM cfg file used 38.25V to compute the stored capacity [14:14:43] instead of a normal load [14:16:24] I just used 30V as the nominal online voltage for the LM bats, converted Ah into W/s which is joules [14:17:05] yeah I think part of the issue is we have a very cheaty way of displaying voltage [14:17:41] Many of our batteries (LM specifically) show like 37 volts for a long time when it should be closer to 30 [14:20:35] I think this also affects the battery capacity as well, since we are using higher voltage than nominal in the LM [14:24:57] hey [14:38:52] hey Niklas [14:39:14] rcflyinghokie, yeah that definitely affects the capacity [14:39:22] exactly [14:39:56] I think a better load curve wouldn't necessitate such a high voltage [14:40:00] I have implemented most of the new ECA control logic, including connections to the CM [14:40:21] I'll make a branch for you to try once it actually does some work [14:41:17] excellent [14:41:50] n7275 yeah, I mean the open circuit voltages are high but the loaded voltages shouldnt be that high (speaking of the LM in this case) [14:42:47] that coupled with the fact that I computed the capacity using 30V means we are depleting faster [15:02:47] indy91 did you see this? https://www.orbiter-forum.com/threads/nassp-8-apollo-7-flightplan-question.39915/ [15:03:05] ah yeah, I'll respond [15:03:10] he makes a good point pulling up the flight plan for that time was a rest period (I havent flown 7 in a very very long time) [15:08:10] we do the 2nd phasing maneuver where the actual mission did a second, unscheduled phasing maneuver [15:08:37] turns out they didn't predict the drag of S-IVB or CSM right, something that can happen to us soon as well haha [15:21:57] I'm very excited for the new drag model [15:24:57] I mean the actual drag is easy. I think I'll make it a fixed CD of 2 in all orientations [15:25:08] it gets complicated in the RTCC... [15:29:11] I bet [15:36:36] when I change the drag I also want to quickly work on propulsive LH2 venting for the S-IVB [15:37:01] that effect was stronger than the drag actually [15:37:24] so before TLI the altitude was slowly rising all the time [15:38:03] so with realistic drag and without any propulsive venting the drag update makes the trajectories (at least of the Saturn Vs) less realistic and not more [15:55:16] I managed to actually open visual studio today, now I have to figure out what exactly I was working on last time [16:14:12] ahh, making the fuel cells properly die with low pressures [19:08:43] afternoon! [19:08:52] yo [19:09:01] what's up? [19:13:14] trying to work on some fuel cell code, but keep getting destracted by simh [19:17:14] how's the DSKY project [19:17:36] going pretty well -- very happy with the prototype keycap, although I have since accidentally killed it [19:17:53] oh no [19:17:58] ...at the moment I'm fiddling with fontforge to get the letters exactly right [19:18:04] that's what prototypes are for, learning :D [19:19:02] turns out acrylic paint dries quickly, but has a longer cure period after that, and you should wait to sand it until after it's fully cured [19:20:12] ahh, yep [19:21:31] also part of the issue was that the primer let go of the surface, so for this next prototype round I also gave the cap a pass with coarse sandpaper to rough it up a bit [19:21:41] I've got four more prototypes primed and ready for painting tonight :) [19:29:10] hey Mike [19:33:31] yo [20:00:41] I really wish our pressures were [more] stable [20:05:45] not going to happen unless we change to a different numerical method [20:07:00] yep, unfortunately [20:07:22] or branching out a bunch of the physics calculations and run them at a steady rate, 100Hz or so [20:12:58] yeah, that would be a lot of rewriting [20:14:04] I think Flightgear does something like that though [20:31:54] okay, I have a simple solution to the Apollo 13 "Eternal Fuel Cell" problem, in a branch called "FuelCellReactantPower" [20:32:25] not sure I'm 100% happy with how the actual shutdown occurs, but it's a start [20:42:06] I'll take a look [21:00:54] night! [16:16:50] hey [16:18:57] morning! [17:25:03] hi folks [17:28:30] haven't done anything NASSP related yet, weather was too nice :) [17:29:16] but I am at the point where I am looking at the power flow between CSM and LM and not just the controlling logic for it [18:03:56] I've been having the same problem with the weather. I have time again to work on projects, but summer's starting and it's nice to be able to see people again, lol [20:51:36] night! [14:36:41] hey [14:48:42] morning [14:55:50] my NASSP builds again [14:56:06] so I am done with the first phase of the LM EPS update. Now just to see if it works like before [15:03:39] oh excellent [15:03:54] so what has been changed internally? [15:04:17] relay by relay implementation of the ECAs, relay junction box and deadface junction box [15:04:56] and the way it can be controlled from the CM [15:05:12] didn't touch the power flow in any way yet [15:07:49] so the slightly weird procedure at the start of LM to CM power should work with that [15:08:16] which procedure? [15:08:53] where you first have to power the CM Main Bus B with CSM power to set relays in the LM, followed by the LM powering the CM bus [15:10:59] Oh yeah [15:11:18] and wasn't there an issue with the CM forcing the ECAs off or something [15:11:51] So the switch sends a command to the RJB which issues either a HV/LV off command or LV on command [15:12:02] its a single command and isnt held [15:12:10] yep [15:12:16] I implemented that [15:12:44]