[12:59:49] NASSP Logging has been started by indy91 [14:29:59] hey [14:32:09] hey Alex [14:35:31] I'm figuring out some open questions [14:35:50] The ephemeris that is generated depends on the initial orbit [14:36:12] low orbit and the ephemeris is generated for 2 days, high orbit (translunar etc.) it is 10 days [14:36:26] so what happens if you want to e.g. calculate a MCC-4 in Earth orbit already [14:36:32] that is more than 48 hours away [14:37:42] the calculation should definitely work. I had to fix something for that, but it will just take the last state vector on the ephemeris if the maneuver is so far away [14:39:37] but the MPT and DMT might not have all the values for the maneuver, as it won't integrate the trajectory that far [14:47:34] and I am adding the On-Line Monitor, that's basically the display for all status and error messages in the RTCC [14:47:52] should be quite useful once many functions are writing some error messages for that [14:52:27] sounds good [14:53:27] I will definitely need you to walk me through some of the RTCC new stuff on next mission :D (probably Apollo 12) [14:53:56] but for the most part I think Ill get the hang of it quickly [14:55:26] yeah, I can make some stuff more user friendly, but in general it will be a manual [14:55:57] and some guides for specific mission phases [14:56:15] oh [15:20:28] oh nice [15:20:33] Ill take a look [16:23:37] wow very nice LUT [16:35:00] indy91, what are the animations that need work? [16:40:32] he says the service arms are ok [16:40:39] not necessarily perfect I guess [16:41:25] tail service masts are the worst apparently [16:43:07] the animations are defined in ML::DefineAnimations in ML.cpp [16:43:25] if you want to take over the job of fixing them, feel free [16:43:44] Jordan says he would try, but is very inexperienced with any coding [16:49:44] and you have the most experience of us with animations in Orbiter [18:07:04] morning! [18:24:58] hey [18:31:27] what's up? [18:32:49] bugs [18:33:31] also, I requested a document from UHCL that had already been scanned, but apparently that also takes multiple days [18:33:44] boo [18:33:57] the confirmation email of my request probably was more work than finding the document on their servers :D [18:34:09] hahaha [19:08:19] I'm making good progress on BLK2 support for Yul [19:08:38] ah, great [19:08:42] I think pass 1 is basically done, and pass 2 is properly processing all of the implied address instructions as far as I can tell [19:09:33] but holy cow the interpretive opcode processing is complicated [19:09:49] I'm considering just not doing it until after I have RETRED totally transcribed and working [19:10:00] since it doesn't have any interpreted code at all [19:11:10] it's going to be really nice to have it all done for disassembling Sundial and Sundance though [19:11:23] because it's way way way more pedantic about correctness than yaYUL is [19:12:06] haha, I was looking at my Sundial video earlier [19:12:13] from 5 months ago [19:12:13] I kind of hit a stopping point with Sundial because I was trying to disassemble something totally new, but yaYUL was totally happy to let me reference things in the wrong bank, or do illegal things [19:12:22] and I wrote in the description [19:12:34] "The deassembly of Sundial E, to create readable assembly code from the rope, is in progress but not yet finished." [19:12:36] :D [19:12:41] that is still true :D [19:12:53] finishing that will be the next thing after Yul [19:12:53] thanks for not making me update the video descriptions [19:12:54] probably [19:12:57] hehehe [20:24:32] I hate bugs [20:35:16] I calculate MCC-2, all good, calculate a burn just after it as a test, 0 DV, all good. Calculate MCC-4 at the normal time, 10 ft/s. The errors accumulate over time, but not that much... [20:35:40] will be very annoying to figure this one out I fear [20:36:29] :( [21:19:14] night! [17:50:20] morning! [17:54:29] hey [17:54:38] any luck on your bug? [17:54:54] yes [17:54:56] found it [17:55:00] terrible, terrible bug [17:55:01] nice! :D [17:55:04] hahaha how so? [17:55:05] and has been in there for so long [17:55:25] well, it kind of randomizes the direct of the sun for gravitational calculation purposes [17:55:29] direction* [17:55:34] oh man [17:56:22] the effects were interesting [17:56:35] because the position of the sun is calculated at the midpoint of the integration duration [17:56:58] that's why there was a difference when I had a planned MCC-4 in there in addition to MCC-2 [17:57:09] integrated from MCC-2 to MCC-4 and take the midpoint of it [17:57:11] versus [17:57:22] integrate from MCC-2 to Earth reentry (if it does so) [17:57:46] so it gave different sun positions for these two cases [17:58:32] I guess it randomly made all MCC and TEI calculations worse by up to a few ft/s [17:58:43] and has done so everywhere, RTCC MFD, MCC... [17:58:51] oh wow [17:58:54] that's crazy [17:59:44] but it's quite random, possible that it had more often a not so large effect [18:00:31] but it was very noticable how the DV of MCCs seemingly randomly varied with mission planning features enabled [18:01:34] there is still some issue with TEIs, always need a course correction of a few ft/s. But I believe that might be unrelated [18:02:17] thinking about it, when I gave you a scenario to try with the real AGC, for P37 calculations [18:02:25] and I then compared to RTCC MFD [18:02:48] there was a bit of a difference and I thought "didn't it use to be almost exactly the same?" [18:10:58] and now I get the result I want to see, if I have a MCC-2 planned then any MCC following it up to LOI would only be 0.1 ft/s at most [18:34:21] hah, awesome [18:34:34] I remember that [21:13:12] night! [15:42:32] hey [16:24:18] hey Niklas [16:25:04] lots of good news [16:25:15] I finally merged the NewMPT branch [16:26:13] working on also merging the NewTLMCC branch now, so that I am not stuck in development branches anymore [16:26:39] also, there is going to be a Apollo in Realtime website for Apollo 13 as well [16:26:47] for the Apollo 13 launch anniversary [16:26:59] and it will have all the same mission control loops as Apollo 11 [16:27:16] and through some Internet magic I already have access to it :D [16:27:40] oh nice! [16:27:49] im sure that will give many clues [16:28:20] yeah [16:28:30] RETRO probably was a busy guy throughout the mission [16:28:49] but I am particularly interested about MCC planning for the hybrid trajectory [16:31:50] but there will be a lot of interesting stuff for sure [16:32:13] I am not even done listening to the most interesting mission phases on 11! [16:32:27] I see the TLMCC options now have the thruster selection setp [16:32:33] step* [16:32:44] yeah, one of the last minute additions [16:32:56] MCC and LOI, they share a MED [16:40:29] TEI and the other RTE options calculate this stuff internally [16:40:52] so you would choose the thruster etc. already when calculating the maneuver [16:41:10] well it's kind of split in two steps [16:46:04] or will be for us at least [16:46:19] the generalized iterator will be used for RTE as well [16:47:02] had you tried the RTE Tradeoff display yet? [16:47:15] did I merge that before? [16:50:53] ah yes I did see that but didnt have time to try it yet [16:51:39] it generates some nice graphs [16:53:34] only works with the MPT enabled [18:07:43] NewTLMCC branch merged. I'll make TLMCC option 1 work with the new TLMCC before I'm going to push it to Github though [18:09:47] finally not stuck in those development branches anymore \o/ [18:36:07] random first FIDO loop from Apollo 13, 4 minutes in and there are already two people betting against each other for the prize of a bottle of Jack Daniels... [20:02:04] nice [20:05:56] and I think I'll finally make the inputs for TLMCC option 1 in EMP coordinates (as it should be) instead of selenographic coordinates [20:06:16] I'll add a small utility function so that you can convert them [20:06:27] e.g. mission report latitude and longitude to TLMCC option 1 inputs [20:10:58] right [20:14:04] maybe a tool to convert back and forth, because I'll first have to convert all the nodal targets we have as initial values from selenographic to EMP [20:33:25] cya later! [18:02:23] hey [18:03:58] hey Alex [18:05:29] as usual I am adding some more RTCC MFD pages, this time for TLMCC inputs and displays [18:06:17] and I think that there also will be no confusion anymore about which pericynthion parameters to use for which TLMCC mode [18:07:09] great [18:08:24] the RTCC Requirements documents differentiate between "TLI perilune" and "LOI Perilune" parameters [18:08:53] which would be hybrid trajectory only terminology I guess [18:09:02] for free-return missions they will be the same [18:09:54] for Apollo 12 to 14 the TLI perilune parameters will be return to nominal after TLI [18:09:58] so higher than 60 NM perilune [18:10:29] and LOI perilune will be the post MCC-2 numbers [18:10:45] but for Apollo 15+ it might actually be the other way around, kind of [18:11:00] after TLI it will on track to the "LOI perilune" [18:11:44] but "TLI perilune", so a flyby perilune, should then be some good initial guess for getting back to free return [18:12:11] that set of numbers is only used by the TLMCC flyby modes anyway [18:22:15] makes sense [18:24:12] the midcourse tradeoff display can show 6 MCC calculation results at once [18:24:23] oh wow [18:24:24] let's see if I can fit that all on one page :D [18:25:18] I guess the Apollo 13 tapes are helping with this [18:25:30] annoying that the MFDs in Orbiter have the wrong aspect ratio [18:25:44] 1:1 instead of 4:3 I guess [18:26:09] I think the Apollo 13 audio should tell me some interesting things about MCC planning with the hybrid trajectory, yeah [18:26:23] I believe Apollo 13 had planned a DOI as LOI-2, maybe the new tapes will give clues to that, provided they had started planning it before the accident? [18:27:27] they might have, yeah [18:27:38] they started planning things very early in the Apollo 11 tapes [18:27:58] actually made it difficult to track some things down because of that [18:28:06] because it happened so much earlier than I would have thought [18:28:43] right [18:31:18] annoying that I haven't been able to find some example of that MCC planning display [18:31:42] I have the RTACF version, which probably has most of the same numbers, but only 1 solution [18:31:50] so very different layout I guess [18:38:53] so all the TLMCC options will use the new iterator? [18:39:06] yes [18:39:14] I have option 1 already integrated into the MFD [18:39:21] minus a bunch of display stuff [18:39:31] then I'll integrate all the flyby modes [18:39:56] mode 6 and 7 were basically abandoned by Apollo 10, and they only used modes 8, 9A and 9B, as those are doing optimization [18:40:23] up to now we only had 7 and 8 basically [18:40:44] only difference between 6 and 7 is the location from where the pericynthion height is taken [18:41:06] 6 gets it from the nominal data table, in mode 7 the height is a manual input [18:41:34] mode 1 and the flyby modes are not that complex [18:41:59] I have mostly implemented mode 4 for Apollo 14, but had a lot of issues with it [18:42:24] then I tried mode 2 for Apollo 11, but haven't really tested it yet with the new iterator [18:42:55] mode 3 and 5 didn't change much even with the switch to LOI/DOI [18:43:07] shouldn't be too hard to implement them right [18:49:12] should be fun to try Apollo 12 with the new functions [18:50:15] yeah, should give some good and fast results [19:28:34] hmm [19:28:36] well [19:28:44] I don't think 6 MCC solutions will fit :D [19:29:01] haha [19:29:45] 4 should be no problem [19:29:50] even 5 maybe, but not 6 [19:30:10] I can make the font even smaller [19:30:16] not sure that is a good idea though... [20:07:01] yeah I would agree not making it too small [20:07:14] or I fear I may have to eat more carrots :D [20:09:42] yeah, indeed [20:33:00] https://i.imgur.com/79GNl7L.png [20:35:26] oh nice [20:35:55] will that have the info to replace things like the meridian time crossing on option 4? [20:36:34] that's probably going to be more of a MPT thing [20:36:47] FIDO Orbit Digitals has a longitude crossing calculation option [20:37:02] you'll probably only have to do that once [20:37:30] hmm [20:42:08] the real option 4 doesn't even have a time input option [20:42:12] so how was that done... [20:43:56] might actually be with option 1 then [20:44:14] hmm, no [20:45:15] afternoon! [20:45:44] but the Apollo 13 FIDO loop might help with that as well [20:45:46] hey Mike [20:46:57] one possible technique could be running a mode 4 and then a mode 1 with adjusted time at the node [20:49:15] oh [20:49:39] there are usually some loose limit (+/- 2 hours) on the time at the node [20:49:56] but you can adjust those, so that's definitely a way to guarantee you arrive at the Moon at the right time [20:52:33] thewonderidiot, I merged some branches and Apollo 13 mission control audio loops are now available! [20:52:46] oh sweet! [20:53:13] will be available here soon: https://apolloinrealtime.org/ [20:53:44] maybe eventually they will be available for all missions [20:54:06] unless there was a policy change all missions up to Apollo 13 were definitely recorded and still exist on tapes [20:54:33] unless there was a policy change even Apollo 14+ should exist, I mean [21:00:08] what have you been up to, Mike? [21:08:38] super duper busy at work [21:08:54] of the past 5 nights I have worked until 1:30am on 3 of them and 11:30pm on two [21:09:07] so I've sort of shifted back a bit and have been getting into the office after you guys have left for the day [21:17:55] oh, so I could easily come online in the morning and talk to you for a few hours :D [21:33:48] indy91, so did the real option 4 just optimize the best arrival GET I guess? [21:37:48] since there is no GET input option as you said [21:39:58] yeah [21:40:10] with the added geometrical constraints of LOI/DOI for the later missions [21:42:16] right [21:48:11] good night! [15:13:43] morning [15:21:15] hey [15:21:20] https://i.imgur.com/YchnJZI.png [15:21:25] the current state [15:21:32] 4 options are now working [15:21:54] all the options that have no optimization [15:22:23] column 1 has an option 1 to the nominal node [15:22:41] column 2 has a flyby option 6 to nominal pericynthion state [15:22:56] column 3 is option 7 with specified pericynthion height of 200NM [15:22:59] nice [15:23:09] and column 4 has an option 4 with specified inclination of 40° [15:23:12] option 8* [15:24:08] I FR is inclination free return, I PR is powered return [15:24:14] for options 2-5 which simulate TEI as well [15:26:17] I did have to change that MCC inputs page so much, that I can't really keep the old and new methods around at the same time [15:26:30] so I'll try to get all modes working before pushing the update [15:28:00] yeah im for only the new method [15:28:16] looks really fantastic [15:29:17] whats SFP 1? [15:29:19] thanks! While I haven't found a picture of the real display there I think it's definitely in the spirit it [15:29:27] spirit of it* [15:29:37] SFP is skeleton flight plan [15:29:47] that has a lot of the input values [15:30:01] nodal state, nominal state at pericynthion etc. [15:30:32] and there are at least 2 blocks of them [15:30:42] block 1 is the prelaunch numbers [15:30:52] the initial guess so to speak, generated from prelaunch data [15:31:18] they would have a large number of different values, depending on TLI opportunity, launch azimuth etc. [15:31:41] and block 2 contains the output values from an option 2-5 calculation [15:31:56] ah ok [15:32:07] the only time you need to interact with the skeleton flight plan page is when you have calculated an option 2-5 [15:32:11] so each TLMCC mode can select the skeleton flight plan? [15:32:18] yeah [15:32:37] after an e.g. option 2 calculation you look at the midcourse tradeoff page and are happy with the results [15:32:37] ok [15:32:47] in the background it has stored the new nodal targets for mode 1 [15:33:17] so the EMP coordinates is whats stored in the SFP [15:33:29] so the one time you need to interact with the SFP is to move a set of values from one of the 4 columns to block 2 of the SFP [15:33:39] and then if you want to calculate a mode 1 you have the option [15:33:47] use SFP 1, prelaunch data [15:33:56] or the updated numbers in block 2 [15:34:07] that's what you then would usually use for a mode 1 [15:34:31] are the real prelaunch data SFP numbers available in the documentation? [15:34:42] I'll probably change it to say "prelaunch" instead of 1 and "updated values" or so for 2 [15:34:57] most of it can be derived [15:35:01] from some documents [15:35:08] in fact that is what we have been doing anyway [15:35:24] not all of them, we never had any TEI capability in the TLMCC before [15:35:39] so now it does? [15:36:14] yeah, needs a bunch more work but in general I have implemented that [15:36:23] for modes 2-5 only of course [15:37:31] in the Apollo 14 TLMCC requirements they don't need as many initial guesses anymore [15:37:59] being dependent on many prelaunch generated numbers is not so great [15:38:15] https://i.imgur.com/WkaP9HW.png [15:38:30] that's all the values in a SFP block [15:38:46] basically all you need to simulate a mission in the TLMCC processor [15:39:30] there is one or two I have left out, as I don't really know what they are [15:40:52] and this is already the expanded table for hybrid missions [15:41:14] the Apollo 11 RTCC support plan has this same list, but without the TLI vs. LOI pericynthion stuff I talked about yesterday [15:41:18] has only one set of data there [15:42:23] right [15:42:37] very fascinating I must say [15:42:41] looking forward [15:42:56] with each iteration it gets closer to the real thing :D [15:43:03] and this time it is really, really close [15:45:12] ok, modes 9A and 9B next, we didn't have those before [15:45:23] it's basically a fully optimized flyby [15:45:49] with 9B having the option to specify a return inclination [15:45:58] I bet some of those Apollo era FIDO guys's jaws would drop to the floor if they knew about the progress of NASSP [15:46:29] I already impressed a Shuttle FIDO with the Shuttle FIDO MFD, haha [15:46:37] but the RTCC MFD is much more advanced of course [15:47:52] rather than impressing a Apollo FIDO I would be ok with just getting all the documentation they might have in their basement [15:49:13] hahaha [15:50:13] speaking of, I've listened a bit to the postlaunch Apollo 13 FIDO loop [15:50:20] and it's very much the same as Apollo 11 so far [15:50:47] TLI in the MPT, then a 0 DV maneuver at the time the S-IVB starts maneuver to the sep attitude [15:51:04] just to get the sep maneuver attitude I think [15:51:20] using some LVLH attitude angles I don't fully understand [15:51:30] but they are basically identical for Apollo 11 and 13 [15:51:50] -120.8°, 41.6°, -131.9° [15:52:08] the sep attitude is usually 120° pitched up and 40° yaw to the left or right, so those numbers are close [15:52:18] but where the -131.9° comes from, no idea [17:20:26] so with the new TLMCC, is the LOI processor going to need updates too? I am guessing since the TLMCC can calculate an LOI solution, both will have to match [17:32:32] yes and no [17:33:06] no, the LOI targeting works very much on its own, it finds the node for the burn itself [17:33:25] yes for the LOI/DOI geometry stuff, as that will require some updates to it [17:33:30] well [17:33:47] I guess most of the work should be done by the TLMCC processor [17:33:51] so mosty no [17:33:53] mostly [17:34:37] we have a LOI targeting RTCC Requirements document [17:34:39] for Apollo 14 [17:35:19] https://archive.org/details/69FM327Images/page/n9 [17:35:23] it's this handwritten mess... [17:36:06] yeah I remember you having issues with it [17:36:20] I could ask Ron to get the updated version of it [17:36:28] also for Apollo 14, but Revision I [17:36:36] I didn't seen that there was a revision 1 at first [17:36:43] otherwise I would have requested it [17:36:52] NARA has lots more LOI targeting documents actually [17:38:52] ok, I have figured out the strange attitude they use for the maneuver they add to the MPT to get the sep attitude [17:39:05] it's just a different Euler angle convention [17:43:44] so in a MPT planning guide I would just give the angles as used during the mission [18:26:34] Mode 9 with DV optimization seems to converge very well! [18:26:56] in my Apollo 11 pre MCC-2 it gives 11 ft/s, with a 80NM pericynthion [18:37:49] nice [18:38:21] is that the mode Apollo 13 would of used for the flyby burn? [18:38:33] probably now possible to check [18:39:23] yeah definitely, looking forward to which modes of the TLMCC and RTE processors were all used [18:39:33] but I think Apollo 13 would have used RTE modes [18:39:41] ah right [18:39:52] you would use the TLMCC flyby modes instead of e.g. MCC-2 [18:40:19] but it does work up to very late in translunar coast [18:45:23] so in the SFP table, I see the values for GET of TLI/LOI pericynthion. Would they manually update these numbers if there was a late launch? Or does the optimization routine automatically find the most efficient GET based on the post TLI trajectory, then update the SFP once option 2-5 is done? [18:47:15] if that makes any sense lol [18:51:52] the only place I have seen the TLI ignition time being used for is the polynomial that calculates an optimal translunar flight time for non-free return trajectories [18:51:59] I think that is the only use for it there [18:52:16] and only as an initial guess there [18:52:34] oh [18:52:36] not "GET of TLI" [18:52:43] but "GET of TLI/LOI pericynthion" [18:53:31] the SFP table 1 is initialized with an MED that wants launch azimuth as an input [18:53:51] the table data is calculated from some polynomials for each data point [18:54:21] so they would have a e.g. pericynthion time stored for 72°, 90° and 108° or something like that [18:54:36] and that would be interpolated when the SFP table block 1 gets initialized [18:56:09] so the answer is: lots and lots of prelaunch targeting data [18:56:33] so many that they haven't printed it in the RTCC Preflight Information documents for each mission, but it got sent by tape from MSFC to MSC [19:01:00] a TLMCC option 2-5 can update the SFP values though [19:01:26] https://archive.org/details/70FM15Images/page/n35 [19:01:32] right side there [19:01:42] X means it gets updated [19:02:35] so new LOI pericynthion data would be stored together with the data in a Midcourse Tradeoff column [19:02:48] and then there is an additional step to copy that data to SFP block 2 [19:02:57] from where it can be used in e.g. the next TLMCC option 1 [19:09:20] it's not easy, but I think it's also a quite logical process [19:09:24] is the current SFP implementation going to support the full launch window already, provided it is fed with all of the necessary data [19:15:29] I have not implemented the function that generates the SFP prelaunch block [19:15:45] so far I have only added the numbers for Apollo 11, nominal launch [19:16:01] a lot of them of course were already in the RTCC MFD, in some form or another [19:16:56] I could probably add support for the full launch window for all mission where I have the relevant volume of the SCOT [19:17:04] which is not many [19:17:45] it should be a good initial guess even for launches that are not on time though [19:51:58] https://i.imgur.com/uSXZYyD.png [19:52:02] a happy flyby family [19:52:08] modes 7, 8, 9A and 9B [19:53:02] MCC-1 this time, a bit more of a challenge for the generalized iterator, but still worked without any issues really [20:06:06] very nice [20:59:07] do you think mode 2-5 should be up and running soon as well? [21:03:23] they will take a bit more time [21:03:27] maybe 2 weeks or so [21:06:27] ok [21:07:12] difficult to say [21:07:43] once thats done Ill fly Apollo 12. In the mean time I think I am going to practice with the LDPP in lunar orbit [21:08:25] maybe tomorrow Ill fly an entire Apollo 11 undocking, PDI, and then ascent and rendezvous [21:08:43] and get used to the new way of using the MPT and all [21:09:41] sounds good [21:10:05] I might have questions, btw :D [21:10:13] for sure [21:24:22] whats iterate vs. non-iterate in the MCC Transfer (MED 78) display? [21:31:39] when you use iterate it will do an iteration to more closely math the finite burn to the desired trajectory [21:31:45] match* [21:32:07] using a scheme very similar to the generalized iterator, but I haven't implemented it that way yet [21:32:21] right now it uses the old RTCC MFD method to the same thing [21:32:37] I would say you should use that option for LOI, because it's such a long burn [21:32:51] for anything else it's not really required [21:34:17] the optimum TIG option already mostly takes care of that [21:34:45] hmm, having trouble to get the MCC-2 solution for Apollo 11 to go to the MPT [21:35:22] when I push CLC on the MCC transfer page, it gives an empty string on the MPT [21:35:36] DELTA-V 0 [21:35:52] and blank for GETBI, DT [21:37:33] hmm, I've seen that before [21:39:40] false alarm [21:40:00] I had forgotten to press CLC on the TLMCC opt 2 page [21:40:05]