[15:35:17] NASSP Logging has been started by thymo [15:38:43] what's the bug? [15:43:57] in the cutoff loop, it uses a time-to-go until cutoff that didn't get updated [15:44:13] TLI VELOCITY: Tt_T: 3.370208, eps_4: 3.590000, V: 10806.069233, V_TC: 150.000000, V_T: 10851.716191 [15:44:17] look at V_T [15:44:20] that should converge [15:44:27] TLI VELOCITY: Tt_T: 3.370208, eps_4: 3.590000, V: 10823.047609, V_TC: 150.000000, V_T: 10850.302789 [15:44:33] TLI VELOCITY: Tt_T: 3.370208, eps_4: 3.590000, V: 10840.114951, V_TC: 150.000000, V_T: 10848.876073 [15:44:49] three cycles of the cutoff loop [15:44:58] the first V_T, target velocity, is close to correct [15:45:06] and the closer it got to cutoff it got worse [15:46:12] so the cutoff error is roughly the different between the first and last V_T [15:46:17] quite a bit [15:46:22] difference* [15:47:30] and previously the length of one guidance cycle was longer in this time period before cutoff. So maybe it only called the cutoff loop twice. That made the bug less worse, as it wasn't called again so close to cutoff [15:48:36] less bad* [15:49:27] if you compare that with the TLI I just did (also changed the debug line) [15:49:31] TLI VELOCITY: R 6685464.347419 dotR 1297.594952 T_GO 3.363794 dt_c 1.300000 R_T 6688142.316613 V_T: 10851.723337 [15:49:41] TLI VELOCITY: R 6687159.492607 dotR 1310.339915 T_GO 3.296305 dt_c 1.300000 R_T 6689775.330586 V_T: 10850.382605 [15:49:49] TLI VELOCITY: R 6688871.280976 dotR 1323.199948 T_GO 1.892878 dt_c 1.300000 R_T 6689655.777229 V_T: 10850.480744 [15:50:26] actually, I see another small error in the first iteration there [15:50:32] but it's already much better [15:50:40] nearly constant in the last two cycles [16:33:12] makes sense, I think [16:39:28] seems like that Boeing document from 1967 is where the equations were from [16:39:36] and it has it wrong, or at least incomplete [17:23:04] ahh, okay. [17:25:12] evasive maneuver done [17:25:21] 8.6 ft/s for MCC-2 sounds better than 58.3 [17:43:30] oh nice [17:53:35] I was all set to start flying Apollo 8 last night, and discovered I still have a weird O2 problem [18:11:59] bad problem to have on a mission to space that relies on fuel cells [18:14:43] very [18:15:14] it reeeally wants to cool off all the time, and I can't figure out where the heat's going [18:15:28] space? [18:15:45] tanks are thermal objects [18:16:00] if their isolation isn't good enough they loose heat [18:18:25] it's 0.0 [18:19:43] what's weird is that I have some Hydrogen tanks that do exactly what I want [18:20:34] they're heated by fuel cells directly [18:20:39] do you have your current state on Github? [18:22:24] I can push it. [18:28:49] morning! [18:29:34] and pushed [18:29:37] hey! [18:32:19] what's up? [18:43:48] n7275, can't see anything obviously wrong in the config [18:43:50] trying to solve a mystrey: is there something wrong with the thermodynamics in our O2, or did I just forget a negative sign or misspell something again... [18:43:51] hey Mike [18:50:15] I think it's just going to take some extra debug strings to figure it out [19:19:51] thewonderidiot, figured out a LVDC bug that I have been suspecting for years [19:20:00] was bad for TLI cutoff accuracy [19:20:16] my recent big LVDC update made the bug worse and that's how I found it [19:20:52] I was first suspecting the midcourse correction processor. Terrible feeling, the main point of flying Apollo 11 right now is because I got enough confidence in that to replace the old function :D [19:21:18] and there is still something a bit wrong with that [19:21:33] the mass optimization is able to overpower constraint that have to be met [19:22:02] pericynthion is only allowed to be 60 +/- 0.5NM [19:22:10] but it results in 61.6 [19:22:48] oh nice [19:22:51] I can put a weight on all variables. If I put a 0.5x factor on the mass it goes down to 60.8. So 0.25 is probably getting it into the constraint zone [19:22:52] good way to find a bug :D [19:23:03] but only in that case... [19:23:11] huh [19:23:36] the RTCC Requirements documents are very inconsistent [19:23:56] some don't even show the ability to have weights on variables that are to be optimized [19:24:22] and then other documents have weights, but actually show two values, one for the "in-house version" [19:24:36] I guess that would be IBM RTCC vs. MSC [19:27:06] but at least it was a one line bug fix [19:27:20] in the LVDC [19:27:30] RTCC would have been much more complicated [20:55:21] hmm well it works with the euler heating model...something odd is going on here [21:47:10] night! [00:23:24] yay! i fixed it [00:24:05] tanks aparently never set their own specific heat capacity [00:24:13] so it's always zero [00:37:48] that sounds wrong :D [00:56:01] doesn't look like anything needed to use it before now, so not surprised [15:28:51] hey [15:42:58] hello [15:43:34] figured out my issue with the oxygen [15:58:22] Tanks know what the mass of their contents is, but aparently they didn't know their heat capacity [15:58:33] easy fix [16:05:42] ok, where did you change that? In the h_Tank class? [16:07:42] I'm afraid of every change to those base classes, due to our experience with NaNs :D [16:10:54] yeah in the h_Tank [16:11:17] what's the change? [16:11:54] theres a place where it sets the mass and energy: space.m, space.Q or something like that [16:13:35] the tank class has a h_volume member that runs ThermalComps [16:14:19] yes [16:14:58] thermalcomps has an AvgC, that it computes every timestep [16:15:18] only uses it internally though [16:15:40] so the "c" from thermalobj is always zero [16:16:35] so all I did is set c=AvgC at the end of thermalcomps [16:16:54] and then in the tank class, c = space.c [16:17:10] the were both always zero by default [16:17:52] space is a h_volume [16:18:12] and it has a variable called c? [16:18:14] is that new? [16:19:34] hang on. bad info [16:20:31] I added: double AverageC to the h_volume class [16:20:57] so its space.AverageC [16:21:09] and how is that used in the tank class? [16:23:59] so the tank class is derived from thermal_obj, which has the heat capacity member, c [16:24:47] my new heating model needs to be able to look at someTank->c [16:25:02] heating model for all tanks? [16:25:12] or just some fuel cell specific code/class [16:25:34] no no, just fuel cell specific tanks [16:25:41] ok [16:25:43] I'm just trying to figure out what is all affected by your changes [16:25:58] which determines the scope of required testing [16:26:33] which in any case should be more than for the VHF ranging haha [16:26:40] thermic still gets called in the the revised Cooling code [16:26:45] yes, lol [16:27:30] I'll be flying *all* of the missions before I even think about pull requesting it [16:27:56] I better help with that or you won't be finished this year lol [16:28:25] did we have the Cooling class before or did you add that? [16:29:09] we had it before, all it was used for was the eps cooling system, and it was very hacky [16:30:03] at least it's fairly clear what we have to test for fuel cells changes [16:30:10] mainly long term stability [16:32:11] and I saw you went ahead with the smaller number of tanks [16:32:24] yeah, much simpler [16:32:27] but still 8 radiators, did I see that right? [16:32:59] yes, still on the fence about that [16:33:42] not sure I could do realistic solar heat flux with just 2 [16:33:58] right [16:34:07] unless I made a curved radiator class [16:34:31] radiator class if fairly light weight [16:34:36] no big deal if it stays at 8 [16:34:39] yeah [16:34:39] is* [16:34:55] just stefan boltzman [16:37:38] so something else. thermal engine calculates radiation from (as well as to them from the earth, moon and sun) all thermal objects (of which radiator is one) and then radiator does it again [16:37:52] we might want to look at that [16:37:57] at some point [16:39:43] yeah [16:39:47] I remember that [16:39:55] it's weird, there are some duplications like that [16:40:25] like therm_obj:energy [16:40:38] so in theory, area needs to be set to half of what we set in the systems config [16:40:55] and h_volume:Q [16:41:22] but everything is tuned to that model at the moment, so no need to break it. [16:41:54] yeah, that's one of those changes that need an approach that looks at everything [16:42:13] like if I ever change the RTCC to use the right coordinate system (again)... [16:50:01] yeah, some things in the systems code need some major cleanup...and them months of testing [16:50:24] which is why nobody has attempted it [16:50:51] I could probably spend a whole month just fixing whitespace things that annoy me [16:51:15] last year, or was it 2019, someone was interested in writing a thesis about the LM ECS and wanted to implement a whole new one for NASSP in the process [16:51:28] but it didn't work out. I'm not blaming them [16:51:51] oh wow [16:51:52] too much effort or too much NASSP specific things to deal with, probably something like that [17:14:23] Apollo 11 MCC-2 less than 10 ft/s, no additional MCCs required as it looks right now. That's what I like to see :D [17:19:16] I turned down how much the DV optimization affects the calculation of the midcourse calculations to 25%. I don't understand why I have to do that, but it works. Always a good approach... [17:38:14] oh yeah! [18:34:34] morning! [18:41:47] hey Mike [19:30:47] hey Mike, what's up? [19:34:50] not a whole lot [19:35:01] work and Luminary 99/1 research [19:35:33] as far as I can tell the earliest they would have released the module for manufacturing would have been June 20 or so [19:38:22] and the usual manufacturing cycle was ~45 days [19:38:32] for a single module, according to R-700 [19:45:07] so that must've been a bit of a rush to get the update [19:47:40] yeah for sure [19:50:49] oh wow, so late [19:59:57] almost unbelievably late [20:14:32] I wonder if it would come up in something like this [20:14:33] 19700081646 Headquarters flight readiness review. Apollo 11, lunar module 1969 [20:19:27] maybe [20:19:34] is that restricted? [20:20:06] yeah, can't access it [20:20:21] apparently each center did their own FRR [20:20:32] so the one from HQ might not be very useful [20:20:58] but surely a LM can't pass a FRR, at least not without asterisk, if it doesn't even have all the software to fly yet [20:22:20] well [20:22:33] I guess it had Luminary 99 R0 until the switched the banks [20:22:41] probably ran some tests and that was it [20:24:43] yeah, once they were sure the module worked they could do very pointed testing [20:24:47] probably similar to what we did [20:25:59] I was more thinking of "banksum checks out" [20:26:26] why would they run the LNY-77 tests with the manufactured rope? [20:29:11] hmm, yeah that's fair [20:29:37] I'm sure with that little time they did less testing than they should though haha [20:32:36] but that sounds like an interesting story in any case, how they got the rope manufactured so quickly [20:32:40] damn, according to my notes, Don has FSRR material for 12, 13, 14, 16, and 17 [20:32:57] flight software readiness review? [20:33:01] yeah [20:37:48] Purdue has "Apollo 11 Flight Readiness Review", June 1969 [20:37:58] was just looking at the same [20:38:27] also "Minutes of Meeting LM-5 Flight Readiness Review Board" [20:38:32] yeah [20:38:44] I heard you have some connections to Purdue now :D [20:38:51] haha yeah, maybe I should email Mark [20:41:12] oh god I just remembered all the talk we had about a Luminary 99 revision 2 based on something James Kernan had said [20:43:35] haha yeah [20:43:40] he thought it was ephemeris [20:44:39] not too bad of a memory, as ephemerides came up very closely after [20:53:54] saerching for "readiness review" in the JSC History Collection [20:53:57] 1 - 100 of 922 Records found [20:54:00] oooookay [20:55:37] 38167 06/09/1969 MSC ( NASA MANNED SPACECRAFT CENTER ) FLIGHT readiness review Apollo 11 PART I LUNAR MODULE APOLLO 071-42 [20:56:42] hahaha [20:56:56] also something in the archive search [20:57:03] CENTER SERIES ALECK C. BOND PAPERS LM-5 Flight readiness review (FRR) Section 117 18 June 9, 1969 [20:57:08] CENTER SERIES ALECK C. BOND PAPERS LM-5 Flight readiness review (FRR) Agenda Section 117 18 June 9, 1969 [20:57:53] June 9 is kind of too early haha [20:58:16] how did you arrive at June 20 for release to manufactuing? [21:03:08] maybe it's not... [21:03:11] hmm [21:03:31] going off of the master deck drawing for Luminary (the one that lists checksums) [21:03:55] that was consistently updated 6-7 days after manufacturing release, for the ropes we know the release dates of [21:04:07] and it was updated in June 27 for 99/1 [21:05:12] I can believe in June 27 for the module to be released by Raytheon [22:08:23] night! [03:25:09] Guenter! [03:25:11] :D [03:26:53] .tell indy91 I found two more promising things at UHCL and requested them: MISSION G SOFTWARE FRR ( FLIGHT READINESS REVIEW ) PRESENTATIONS (dated July 7) and JUNE 5TH APOLLO SPACECRAFT SOFTWARE CONFIGURATION CONTROL BOARD MEETING