[16:42:26] NASSP Logging has been started by n7275 [16:42:29] i like that document. [16:43:08] was you mentioned worksheets the other day and I'd been meaning to ask [16:52:58] I presume the correct procedure for maneuvers you've completed is just to delete them? [17:31:42] hey Thymo [17:31:47] n7275, not necessarily [17:32:06] first you would confirm the maneuver with residuals (or total IMU velocity gained) [17:32:17] that gets you the most accurate cutoff state vector [17:32:36] I didn't really implement confirming maneuvers yet, because getting a perfect SV is just a mouse click [17:32:54] and old maneuvers are just treated as "history maneuvers", no problem leaving them in the MPT [17:33:10] sometimes it can even be usefull still for processing old tracking data or so [17:33:55] but then, for example the new flight controllers shift after the Apollo 11 LOI-2 comes around, and the new FIDO looks at the MPT and says "let's start clean, remove all maneuvers from the MPT" [17:33:59] so that definitely happened, too [17:46:56] oh okay [17:50:57] the only thing in the RTCC timestep function, that gets checked all the time, is if the ignition time of a maneuver on the MPT has passed [17:51:17] the maneuver then gets marked as a history maneuver and some data are printed on the online monitor [17:51:33] in our RTCC of course haha [17:55:34] I recently discovered the online monitor. very helpful [17:56:04] yeah took a while to get that going, but now a lot of error and status messages are displayed on it [17:57:33] we have an example of it with some PDI calculations [17:57:35] https://i.imgur.com/qhYjmEP.png [17:58:13] oh nice [17:58:36] and an ascent it seems [17:58:43] a few days ago you shared a screenshot of some MEDs from a document. I have the one with all the tables from (AS 500), but I can't find that specific one [17:59:43] wanted to make sure I bookmarked it. I'm sure it's in one I have [18:00:33] I don't remember which MED that was, but I think it was from PROJECT APOLLO 500 [18:00:34] RTCC OPERATIONS SUPPORT PLAN [18:00:35] FOR [18:00:36] MISSION G" [18:01:03] https://i.imgur.com/uC8Ojan.png [18:01:08] this is definitely from that document [18:02:01] there is also a more long form MED description in an IBM Apollo Programming Systems document [18:04:01] which one did you mean? [18:05:51] yep that's it [18:06:03] PDF page 418 [18:06:48] thanks [18:21:00] speaking of MPT, if you have maneuvers on the MPT (far in the future) can you update the DC vector periodically without deleting and recalculating and re-adding the maneuvers? [18:22:49] in other words, will those future maneuvers automatically incorporate the updated DV vector? [18:22:55] DC* [18:24:19] in theory yes [18:24:35] the problem is, those maneuvers were calculated using the original state vector [18:24:50] so the TIG or DV might not be the same if they were calculated with an updated state vector [18:25:27] if you don't think that is a problem (no trajectory change, or TIG and DV was manually input or so) then you don't need to delete the maneuvers [18:25:56] right [18:26:00] most of the maneuvers on MPT are External DV [18:26:19] so with an updated SV it just coasts to TIG, simulate burn like External DV, coasts further etc. [18:26:42] originally they wanted to have iterable maneuvers [18:27:15] I believe for LOI and GMP maneuvers there is some code in place that would achieve the desired trajectory again after a changed state vector [18:27:35] but it wasn't really used like that, not sure if that was still really possible on the actual missions [18:28:31] so it's like the opposite problem if doing e.g. a burn with an old state vector, but fresh P30 [18:28:33] of* [18:28:44] new state vector, but outdated P30 solution [18:35:28] makes sense [18:35:34] Orion has landed [18:36:00] and fell into a crater :( [18:36:27] I have a love/hate relationship with ggalfi's scenery :D [18:37:38] the true culprit is the TD points [18:38:09] still needs further refinement but its hard to find a balance between stability and higher friction [18:38:21] I blame the pilot landing too close to a crater [18:39:56] is it really worse with the detailed scenery? [18:39:57] wasn't there a mission that had one leg partially in a crater? 15? [18:40:13] well its just that the craters are hard to see [18:40:49] hmm right [18:43:11] the landing site seems to be on a slightly uphill part of the terrain [18:43:27] so I think that makes the crater shadows less pronounced [19:16:50] or and forgot to mention indy91, the SIVB impacted very close to target [19:17:12] and I didn't do the MCC-2 [19:22:23] great [19:28:46] that targeting is a bit of a Frankenstein's TLMCC option 1 [19:29:10] in the rare case that you get a converged solution it is usually fine :D [19:29:17] tbh I couldn't get it to give an MCC-2 solution. I read on Discord that it can be found by trying different "random" inputs [19:31:38] yeah it's kind of counterintuitive, if your current trajectory is already close to correct then it has problems [19:31:57] because then the DV converges fine "small" but pitch and yaw jump around [19:32:11] and pitch and yaw don't have much power because the DV is small [19:32:30] pitch and yaw don't change much I mean [19:32:42] I should change all that and make it more like the TLMCC [19:32:48] and then convert to pitch and yaw afterwards [19:35:39] right [10:48:13] good morning [10:49:14] hello hello [10:54:24] I think I've found an animation bug with the HGA. [10:57:28] if you reload current state while it's tracking it ends up pointing in very different direction [10:58:18] seemed to be identical behavior in my branch and Orbiter2016 [10:59:09] that is if you don't close Orbiter in-between reloading? [10:59:25] yes [11:00:09] it's like some memory isn't being freed [11:00:15] yeah I have always thought that something in NASSP is buggy in that regard, I am always closing Orbiter completely. Something we need to figure out. [11:14:18] one of those automatic habits, reloading Orbiter, and you stop thinking "hey, maybe I shouldn't do this but try to fix it instead" :D [11:34:07] I had a few instances with my multithreading project where I was restarting my computer just to be safe [11:35:46] restart your computer also increases the chances to get the SM panel bug [11:42:40] that is the strangest bug [12:00:33] so. do MCC get added to the MPT? I followed the input guide and manual and managed to calculate MCC1 and add it to the SFP [12:03:43] not sure I understand that question. If you use the MPT then all maneuvers are usually added to it. [12:04:08] SFP is just a table (or multiple tables really) with some constraints and initial guesses for further MCC calculations [12:04:29] would be too much to save those SFP data on the MPT, too [12:06:18] if you don't want to do MCC-1 then don't add it to the MPT though [12:06:54] or at least there is no point in doing that. You usually do a lot of advanced planning with LOI-1 and such, but if you do MCC-2 instead of MCC-1 then MCC-2 would be on the MPT [12:07:06] rereading my question. "how do MCCs get added to the MPT" [12:07:55] oh I see, this is your first normal maneuver [12:07:59] TLI is different [12:08:07] and so are the manually input maneuvers [12:09:40] after you calculate the maneuver, you use the ENG button to select an engine and some other parameters [12:10:58] there is two categories of maneuver types with regard to the MPT [12:11:39] there are direct inputs where all parameters for the burn are defined outside of the MPT and then moved as a whole to the MPT [12:12:07] that would be TLI, lunar ascent and descent, RTE maneuvers and manually input ones [12:12:20] all others are defined as an impulsive TIG and DV [12:12:50] and only when they are moved to the MPT do you decide on an engine, and the TIG will move forward [12:13:21] before moving it to the MPT the maneuver is only defined as an instant velocity change [12:14:30] and then when selecting thruster, ullage, the MPT logic will make a finite burn out of it that follows the same trajectory as the instant velocity change [12:14:54] rule of thumb, TIG will be half the burn time earlier than the impulsive TIG [12:16:04] that makes sense. I think I just missed the transfer to MPT part last night [12:18:07] the half the burn time earlier is with the optimum TIG option [12:18:32] that does a simplified calculation where half the DV is before and after the impulsive TIG each [12:18:36] the iterate option goes further [12:18:50] it fully simulates the burn and then converges on the desired trajectory [12:19:00] you only need iterate for really long burns like LOI-1 [12:19:19] in fact, burns shorter than 6 seconds are a bit buggy with the iterate option right now [12:21:18] I will keep that in mind [12:21:43] my MCC-1 is 59.9 ft/sec [12:22:16] which mission are you flying again? [12:23:11] 12 [12:23:38] that was with option 5 [12:24:08] that seems normal [12:24:19] MCC-2 will be a bit more, but it's that way in the flight plan [12:24:29] you got a really high flyby pericynthion [12:24:58] you can do an option 9 calculation in another column to see how free-return you are [12:30:42] what's the best way to see the effect of not doing MCC-1 on the MCC-2 DV? [12:31:29] calculate MCC-2 [12:34:27] they would only do MCC-1 or 3 under off-nominal circumstances [12:42:00] hey guys [13:04:03] hey Alex [14:20:50] indy91, do Apollo 7,9,10 have full launch window support in the LVDC presettings? I can't remember off hand [14:21:02] I know 8,11,14 do [14:37:11] oh yeah, Apollo 7 and 9 are fully supported with LVDC presettings [14:37:22] ... because they would have launch to 72° azimuth no matter what [14:37:38] 10, not fully supported [14:40:21] in fact, I believe Apollo 7 had delay [14:40:30] which we simulate [14:41:38] launch window open at 15h GMT, launch at 15:02:45 [14:45:40] ah [14:46:20] and I think the MCC tracking does support late launches if I am not mistaken [14:47:52] I have not tested that much, but in theory yes. Saves the correct launch time in the RTCC etc [14:48:10] well thats where I come in :D [14:48:30] my next mission I think will be a late Apollo 8 launch, 2n opp TLI [14:51:13] I think if there is a problem with the MCC then it wouldn't require much tweaking to be fixed [14:51:24] unless the SFP is not good enough [14:51:29] then there is a big problem :D [14:52:15] I already tested an MCC calculation after a 2nd opp TLI on the MPT, in a Apollo 8 post earth orbit insertion scn [14:52:24] worked fine [14:52:32] gives an LOI a few hours later [14:52:41] which is expected [14:53:47] not a late launch though [14:53:57] so that might stretch it a bit more [14:54:53] yeah [14:57:38] one thing though while the LOI itself can be calculated from EPO, it does not transfer to the MPT [14:57:49] gave nonsense data [14:58:01] ah you did find a current shortcoming [14:58:07] but I guess that is pretty optimistic from EPO, with TLI+MCC on the MPT :D [14:58:17] ephemeris can't store infinite state vectors [14:58:32] in Earth orbit, it limits the ephemeris to 48 hours [14:58:46] in TLC/TEC it is 10 days because the steps between state vectors are a lot bigger [14:58:55] ah [14:59:25] now, I believe what happens in reality is, even if it doesn't save any more state vectors, it would still propagate a state vector to the maneuvers after that 48 hour limit and simulate the burn [14:59:40] but I haven't implemented that yet [15:00:26] so once you do a trajectory update after TLI, you get the 10 day constraint instead and LOI should work fine on the MPT [15:00:46] right [15:01:03] and it determines that based on your current state vector [15:01:24] there was also a number limit on the ephemeris, but I have no idea what that is [15:01:43] So if you are e.g. shortly before LOI-1 but with LOI-1 on the MPT then it will still have the 10 day limit [15:01:57] and store quite a few vectors on the ephemeris in low lunar orbit, shorter step size [15:02:12] because I don't have set any limit [15:22:03] I guess the MCC relies on REV # and not GET in lunar orbit? So 2 hours late would not change anything [15:24:47] yes, everything is rev based [15:25:01] and then TEI + X hours [15:25:10] hmm [15:25:16] not sure if the TEI PADs will be right [15:25:18] need to check [15:25:24] their initial guesses might be hardcoded [15:31:21] what's also hardcoded is the estimated splashdown times for RTE maneuvers [15:32:19] not sure if that is a problem [15:32:23] maybe for TEI [15:33:18] ah, but it's actually not a problem with the TIGs for the TEI PADs [15:33:28] that is based on the time when the PAD is getting calculated [15:36:17] hmm, so I am looking at a chart of time from TEI to EI for all launch days and TLI opportunities [15:36:41] for very late launch and second TLI opportunitiy there is a discontinuitity [15:36:57] that means, TEI DV becomes too large and the return time would need to be 24 hours more [15:37:44] for that the TEI calculation logic would need to check that the calculation fails for some reason and try again with 24h later landing. But it doesn't right now. [15:38:01] ah [15:38:30] it's only a problem for about 106-108° launch azimuth [15:38:35] second TLI opportunity only [15:38:45] Apollo 8? [15:40:24] yes [15:41:01] https://web.archive.org/web/20100519184718/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19750064240_1975064240.pdf [15:41:07] PDF page 7 [15:44:12] if it is a DV constraint our RTCC won't fail [15:44:18] but could be reentry speed [15:45:05] almost makes me want to test it [15:46:02] yeah I think it's actually reentry speed [15:46:06] I can quickly launch Apollo 8 108 degrees 2nd opp TLI, and post TLI I will put it all on the MPT [15:46:44] and RTCC MFD and MCC are using the same RTCC [15:47:01] so if the calculation fails you can at least put the reentry speed constraint higher and it would work [15:47:21] ah is it? [15:47:46] its not using its own calculations separate from RTCC MFD anymore? [15:48:15] I mean I knew it was so for TLC but thought TEI still used the old way [15:48:55] TEI/TEC* [15:50:47] the main reason I fully integrated them is the External MFD not saving in the scenario [15:50:59] so I needed to save the RTCC MFD parameters somewhere [15:51:12] and the best place for it really was the RTCC in the MCC vessel [15:51:28] so since then MCC and RTCC MFD share the same instance of the RTCC class [15:51:37] ah [15:51:40] there are still some calculations only the MCC or the RTCC MFD are using [15:52:06] but in many cases you can even see a display on the RTCC MFD when the MCC did a calculation [15:52:37] so say I modify some RTE constants in RTC MFD [15:52:59] that will be reflected by the MCC calculated TEI/MCC's? [15:54:33] yes and no, I am seeing some cases where the MCC overwrites RTE constraints to make sure the right one is used [15:54:49] right [15:54:50] for Apollo 8 at least the entry range [15:54:55] ah [15:55:36] thats funny because in the test I just did, it was the range I modified [15:55:40] but reentry speed limit should be used like the RTCC MFD sees it [15:55:42] RRBIAS [15:55:49] but I guess that will be overwritten [15:55:50] also Apollo 8? [15:56:06] actually I was testing with the Apollo 11 MCC-5 scn [15:56:29] I think they changed it in the real mission [15:57:07] true [15:57:08] oh [15:57:19] hmm [15:57:54] yeah the range is overwritten [15:58:00] but the other constraints apply [15:58:13] so you might set up the TEI calculations for failure if you put DVMAX to 2000 or so [15:58:25] right [15:59:41] I'm kind of wondering if you can get the real splashdown coordinates by manipulating the RRBIAS during TEC [15:59:47] because there the 1285 NM isn't set [15:59:50] for Apollo 11 [16:02:12] hmm sadly no [16:02:17] a different variable is used [16:02:34] that applies for Earth centered RTE maneuvers [16:03:02] and for TEI it gets overwritten, so, no chance to change that with the RTCC MFD on a MCC controlled mission [16:03:19] that applies for Earth centered RTE maneuvers as calculated by the MCC only* [16:03:44] was it uplinked as part of MCC-5, or as a separate uplink later? [16:04:33] the splashdown coordinates? [16:04:36] yeah [16:04:59] I mean the modified ones [16:05:23] I think the decision came later [16:05:47] real TEI PAD was 1180.6 [16:06:13] entry PAD 1,404.5 [16:06:17] yeah, that is equivalent to 1285 NM [16:06:22] 1285 is EI to splash [16:06:28] 1180.6 is 0.05g to splash [16:06:35] I believe they changed the RTE constraint to 1500 [16:08:10] I was searching for that in the RETRO audio actually [16:08:54] 189:58:30: Is the target off the groundtrack now? It is on. Downrage 1500NM. Nominal 1285. 215NM difference. [16:09:32] I guess one could input that in the splashdown update page [16:09:38] and uplink [16:09:54] but only the CMC would know about it, and not the entry PAD [16:10:20] RTCC MFD Entry PAD would know about it [16:10:27] or does the entry PAD downlink the CMC ones? [16:10:41] hmm [16:10:44] right RTCC MFD entry PAD [16:11:05] MCC stores its own splashdown coordinates [16:11:39] you would need to uplink after the final uplink, because there it gets Entry PAD, 2 state vectors, final splashdown target [16:12:54] right\ [16:12:55] probably makes more sense to disable the MCC early in the reentry preparations [16:13:02] and be your own flight controller for the last few hours [16:15:09] another way I guess to update the splashdown location before re-entry: calculate MCC-7 with RRBIAS 1500 and transfer its splashdown location [16:15:32] but then ideally you'd have to also burn MCC-7 to have it most accurate [16:30:20] well, the MCC doesn't do it any differently [16:30:34] if a maneuver is so small that it gets scrubbed then there is not much risk doing that [16:30:35] but [16:30:49] it's one topic of confusion for me. When were the splashdown coordinates fixed [16:31:10] you have to tell the ships waiting for the CM coordinates at some point [16:43:20] im doing a 107.3 degree launch [16:43:24] 4h35 delay [16:43:49] make the SFP sweat a bit [16:46:10] and me [16:46:32] you could do worse though [16:46:37] hehe [16:46:42] try the Apollo 11 July 18 or 21 launch scenarios [16:47:10] flew the July 21st one already I think [16:47:16] not with MCC though [16:47:21] or did I [16:47:32] I doubt it [16:47:53] that's not even free return [16:47:59] MCC can't keep up :D [16:48:00] right [16:48:18] I liked that scenario since its kind of like Apollo 12 [16:49:05] for the TLC profile [16:49:15] right [16:49:19] and a new landing sites [16:49:22] and we have the full launch window for it [16:49:32] just as flat as the actual one I guess haha [16:49:38] yep [17:23:26] indy91, is your sweat ready? [17:23:39] TLI+90 : -46928.2 DVZ [17:23:56] oh that's nice [17:24:09] and nans in RTGO and VIO [17:24:10] haha [17:24:15] but TEI-4 is perfect [17:24:21] TLI+90 is very sensitive [17:24:40] wait, how do you have a TEI+4 [17:24:47] oh TLI [17:25:01] ah sorry TLI+4 [17:25:18] TLI (1st op) PAD also good [17:25:33] it's possible that the same splashdown zone can't be used [17:25:42] because TLI happens in a slightly different location [17:25:51] I wonder if I have any data about that [17:26:11] this is TLI 1st opportunity, 107 something DEG? [17:28:11] yeah [17:28:18] im going to fly 2nd though [17:31:00] what's the TLI PAD TB6? [17:31:40] 2:26:23 [17:32:56] hmm [17:33:15] Apollo 10 had 002:24:23 and still landed on the AOL for TLI+90 [17:34:38] maybe the initial guess for the landing time is too far off [17:34:54] 17:47h GET for nominal Apollo 8 [17:35:10] it would be a few hours earlier with your TLI [17:35:37] but that's strange [17:35:48] but then the RTE targeting is not perfect [17:44:10] scn? [17:45:51] no, I think in general I know why it happens [17:46:03] ok [17:48:58] a dang [17:49:37] it tried to do something at 3:10 but never finished :D [17:50:32] poor MCC im really being hard on it today [17:51:33] hmm, that's when it switches over to the 2nd TLI opportunity [17:51:39] I've tested that in the past [17:53:00] yeah that's strange that it fails, that's the TLI simulation [17:53:14] can you try if the TLI PAD in the RTCC MFD works [17:53:19] well looking at the MPT, it seems to have succesfully added it to the MPT [17:53:25] it was already there [17:53:37] oh the TLI PAD [17:53:59] yes it does [17:54:12] TB6 3:54:16 [17:55:00] all it does after adding TLI to the MPT is dummy, CSM sep maneuver to the MPT [17:55:27] the maneuver on the MPT, does that have a reasonable TIG? [17:55:44] yep [17:55:50] 4:03:54 [17:55:53] but no second maneuver? [17:55:57] and the dummy maneuver is on there too [17:56:03] oh [17:56:09] 4:24:13 [17:56:13] maybe a broken maneuver though [17:56:32] after adding that to the MPT it is done [17:56:50] hmm [17:57:06] it would immediately try to give you the TLI+90 PAD [17:57:15] maybe the TLI task was successful? [17:57:19] But it failed in the TLI+90 [17:58:16] ah and one thing to add [17:58:33] it did thread started, thread completed, thread started [17:58:40] and then nothing [17:59:11] ah yeah [17:59:22] the first thead was the TLI sim, adding TLI and the sep maneuver to the MPT [17:59:34] the second task was the TLI+90, that is what properly failed this time then [18:00:10] it probably tried to calculate a 70000 ft/s abort [18:00:14] if anything the desired landing time should be closer for that one [18:01:10] maybe I want a scenario after all [18:01:16] sure [18:01:23] heres one 10 minutes before the thread [18:02:12] https://www.dropbox.com/s/i0ctvcjg8dt4hmn/Apollo%208%20-%20Late%20TLI%20test.scn?dl=0 [18:03:44] I hope I can use debug mode [18:04:19] the logic that checks which vehicle configuration you have doesn't work right with debug mode [18:04:41] well not if the Saturn class is in release mode, but MCC in debug [18:07:34] yeah, I'll need to do a bit of trickery, shouldn't be too difficult [18:08:24] ah, just a short delay between TLI sim and TLI+90 calc [18:20:12] in code? [18:20:35] yeah, I just changed it so there was a delay, and doesn't go immediately from TLI sim to TLi+90 calc [18:20:50] it fails in the most ugly code of the Earth-centered RTE :D [18:21:47] I gave the TLI+90 maneuver a maximum DV of 7000 ft/s [18:22:10] maybe I should increase that [18:22:23] no chance that the nominal TLI+90 finds a solution 24 hours too early [18:22:31] as there isn't even 24 hours between TIG and reentry [18:23:31] Apollo 10 had a similar TLI+90 and there it was 6600 ft/s [18:34:59] the TLI+4 was 6646.7 on for the 1st TLI [18:35:31] targeting the mid pacific [18:37:14] does that delay allow the calculation to finish? if so maybe I can add it in my copy [18:37:34] haha no, the delay was just so I could debug this [18:37:43] oh lol ok [18:37:45] run TLI sim in release mode, because it doesn't work otherwise [18:37:48] save scenario [18:37:50] debug mode [18:37:56] wait 5 seconds and TLi+90 calculation [18:38:08] I feel like it's trying to solve an impossible task [18:38:20] maybe like Apollo 16, you can't target the AOL [18:38:46] right [18:40:10] maybe it should find a solution 24h slower [18:40:15] but that's where it fails [18:42:46] so I am doing a TLI+90 myself with TLI 2 on the MPT [18:43:02] 5:33 TIG and DV 8108 [18:43:06] AOL [18:43:11] right [18:43:16] and EI 12:35:35 [18:43:26] Apollo 8 Operational Abort Plan says, maximum DV of 7000 ft/s for the TLI+90 [18:43:33] and for TZ I used 20:0:0 [18:43:39] so Ill try 30:0:0 [18:44:10] calculation fail? [18:44:21] no [18:44:29] DV 2316 [18:44:37] EI 37:53 [18:44:45] still AOL [18:44:47] I don't get why the MCC doesn't find that [18:44:55]